GGUFs für Decoder-Only 向量模型 optimieren

tagBase- und quantisierte GGUFs

Multi-modal embeddings for jinaai/jina-embeddings-v4 · ggml-org llama.cpp · Discussion #14851

Hey folks! I’m working on getting multimodal embeddings working with jina-embeddings-v4 (based on Qwen 2.5 VL) through llama.cpp server. I’ve hit an issue with mtmd inconsistencies and was hoping s…

GitHubggml-org

Multi-Vektor-向量模型-Ausgabe wird auch nicht ohne Weiteres unterstützt, aber es ist kein so großes Problem wie die Vision Transformers. Die Multi-Vektor-Ausgabe stammt von einem trainierten MLP am letzten Transformer-Block, sodass wir diesen MLP schlimmstenfalls immer separat nach Numpy exportieren und anwenden können, nachdem wir die 词元-Level-向量模型n von llama.cpp erhalten haben – was wir für jina-reranker-m0-GGUF getan haben. Sicher, es ist nicht sehr effizient, aber es funktioniert, ohne dass wir llama.cpp modifizieren und neu kompilieren müssen.

Um also die bestehende Qwen2.5-VL-3B-Graph-Implementierung von llama.cpp vollständig zu erfüllen, haben wir den Vision Transformer und den Multi-Vektor-Projektor am letzten Transformer-Block entfernt und alle LoRA-Adapter wieder in das Basis-Sprachmodell integriert. Dies ergab uns drei aufgabenspezifische v4-Modelle mit jeweils 3,09 Milliarden Parametern – gegenüber den ursprünglichen 3,75 Milliarden Parametern von v4:

Dann verwendeten wir calibration_data_v5_rc.txt (die hier zu finden ist und von Unsloth empfohlen wird), um alle drei Basis-GGUF-Modelle zu kalibrieren und drei imatrix-Dateien zu erhalten. Anschließend verwendeten wir llama-quantize mit imatrix, um die Modelle wie folgt von float16 zu quantisieren:

# build imatrix
llama-imatrix -m jina-embeddings-v4-text-retrieval-F16.gguf -f calibration_data_v5_rc.txt -ngl 99 --no-ppl -o imatrix-retrieval-512.dat

# quantize
./quantize.sh jina-embeddings-v4-text-retrieval-F16.gguf retrieval-i3 imatrix-retrieval-512.dat jinaai/jina-embeddings-v4-text-retrieval-GGUF
Kopieren

Das quantize.sh-Skript ist unten dargestellt:

#!/bin/bash

F16_MODEL_FILE="$1"
OUTPUT_DIR="$2"
IMATRIX="$3"
HF_REPO="$4"

FILENAME="$(basename "$F16_MODEL_FILE")"
BASE_NAME="${FILENAME%-F16.gguf}"
BASE_NAME="${BASE_NAME%.gguf}"

mkdir -p "$OUTPUT_DIR"

# Array of quantization types
QUANT_TYPES=("IQ1_S" "IQ1_M" "IQ2_XXS" "IQ2_M" "Q2_K" "IQ4_NL" "IQ4_XS"  "IQ3_XXS" "IQ3_S" "IQ3_M" "IQ3_XS" "Q3_K_M" "Q4_K_M" "Q5_K_S" "Q5_K_M" "Q6_K" "Q8_0")

for quant_type in "${QUANT_TYPES[@]}"; do
    llama-quantize --imatrix "${IMATRIX}" "$F16_MODEL_FILE" "${OUTPUT_DIR}/${BASE_NAME}-${quant_type}.gguf" $quant_type 8
done
Kopieren

Schließlich haben wir alle Quantisierungen auf HuggingFace hochgeladen.

tagVerwendung und Vorbehalte

Wir können jetzt llama-server und llama-embedding verwenden, um GGUFs für die Einbettung bereitzustellen. Im Gegensatz zu Transformer-Bibliotheken, bei denen wir die Flexibilität haben, benutzerdefinierten Eingabe-Preprocessing-Code zu schreiben, müssen wir diesen Teil manuell bearbeiten (es sei denn, wir möchten llama-server und llama-embedding neu kompilieren). Um Ergebnisse zu erhalten, die vollständig mit der Verwendung von AutoModel.from_pretrained("jinaai/jina-embeddings-v4")... übereinstimmen, müssen Sie sehr vorsichtig mit Präfixen sein und diese manuell zu Ihren GGUF-Modelleingaben hinzufügen. Hier ist eine Referenztabelle:

Einige Benutzer werden es vielleicht überraschend finden, dass ⚠️ prompt_name='passage' bei Verwendung von text-matching im ursprünglichen AutoModel.from_pretrained("jinaai/jina-embeddings-v4").... in "Query: " überschrieben wird. Dies ist jedoch sinnvoll, da text-matching eine Satzähnlichkeitsaufgabe ohne linke/rechte Rollen ist – die Eingaben sind symmetrisch.

tagVia llama-server

Nach der Installation von llama.cpp können Sie llama-server ausführen, um das Einbettungsmodell als OpenAI API-kompatiblen HTTP-Server zu hosten. Um beispielsweise text-matching mit F16 zu verwenden, können Sie Folgendes tun:

llama-server -hf jinaai/jina-embeddings-v4-text-matching-GGUF:F16 --embedding --pooling mean -ub 8192
Kopieren

Senden Sie dann eine Anfrage über:

curl -X POST "http://127.0.0.1:8080/v1/embeddings" \
  -H "Content-Type: application/json" \
  -d '{
    "input": [
      "Query: A beautiful sunset over the beach",
      "Query: Un beau coucher de soleil sur la plage",
      "Query: 海滩上美丽的日落",
      "Query: 浜辺に沈む美しい夕日"
    ]
  }'
Kopieren

Wenn Sie retrieval- und code-Modelle verwenden, fügen Sie Query: oder Passage: vor Ihrer Eingabe hinzu, wie folgt:

curl -X POST "http://127.0.0.1:8080/v1/embeddings" \
  -H "Content-Type: application/json" \
  -d '{
    "input": [
      "Query: A beautiful sunset over the beach",
      "Query: Un beau coucher de soleil sur la plage",
      "Passage: 海滩上美丽的日落",
      "Passage: 浜辺に沈む美しい夕日"
    ]
  }'
Kopieren

tagVia llama-embedding

Für eine schnelle Plausibilitätsprüfung können Sie auch die vorkompilierte llama-embedding für die einmalige Einbettung verwenden. Wir empfehlen nicht, sie für die Masseneinbettung zu verwenden, da sie einige Leistungsprobleme aufweist, die wir im nächsten Abschnitt besprechen werden:

llama-embedding -hf jinaai/jina-embeddings-v4-text-matching-GGUF:F16 --pooling mean -p "Query: jina is awesome" --embd-output-format json  2>/dev/null
Kopieren

tagZusammenfassung der Vorbehalte

Bevor wir zu einer performanteren Implementierung übergehen, fassen wir die Vorbehalte von GGUF-Modellen zusammen:

• Sie müssen manuell Query: oder Passage: vor den Texteingaben hinzufügen.
• Sie können derzeit keine Bildeingaben verarbeiten, da wir die Vision-Transformer aus dem GGUF-Modell entfernt haben. Wir mussten sie aufgrund von Fehlern in der Vision-Transformer-/mmproj-Implementierung von Qwen2.5-vl-3b in llama.cpp entfernen, an deren Behebung wir mit Upstream arbeiten.
• Sie können keine Multi-Vektor- Einbettungen ausgeben, da dies nicht Teil der Qwen2.5-vl-3b-Graphenimplementierung von llama.cpp ist. Die einfachste Problemumgehung, ohne llama.cpp neu zu kompilieren, besteht darin, das MLP zu exportieren und separat auszuführen, nachdem Vektorabbildungen auf Token-Ebene abgerufen wurden, indem --pooling none in llama-embedding festgelegt wird.
• v4 ist mit Matryoshka-Darstellungslernen trainiert, und die Konvertierung in GGUF behält dieses Merkmal bei. Wenn Sie Vektorabbildungen mit der Form NxD erhalten, können Sie einfach embeddings[:, :truncate_dim] verwenden, um kleinere, abgeschnittene Vektorabbildungen zu erhalten. Allerdings wird nicht jede Dimension trainiert. Für v4 haben wir truncate_dim für diese spezifischen Werte trainiert: [128, 256, 512, 1024, 2048]. Dies bedeutet, dass die Qualität von embeddings[:, :131] keine Interpolation zwischen der Qualität von embeddings[:, :128] und embeddings[:, :256] ist, sondern deutlich schlechter als entweder 128-dim- oder 256-dim- Vektorabbildungen, da 131-dim nicht trainiert ist.
• Spätes Chunking kann weiterhin als Teil der Nachbearbeitung funktionieren, nachdem Vektorabbildungen auf Token-Ebene über --pooling none abgerufen wurden. So wie wir das MLP vom llama.cpp-Graphen getrennt haben, ist dies nicht besonders effizient, erfordert aber keine Neukompilierung. Es gibt jedoch einen weiteren Vorbehalt: Da v4 ein kausales Modell ist, wird spätes Chunking nicht mehr bidirektional sein – frühere Chunk- Vektorabbildungen enthalten keine Kontextinformationen aus nachfolgenden Chunks. Denken Sie daran, dass in v3 jede Chunk- Vektorabbildung globale Kontextinformationen enthielt, da wir bidirektionale Aufmerksamkeitsmasken in den Transformer-Blöcken verwendet haben. Intern haben wir diskutiert, ob Kausalität spätes Chunking überflüssig macht: Einige argumentieren, dass "Kontext auch kausal ist" – das heißt, ein Leser verarbeitet Text von links nach rechts, sodass der Kontext, der zur Interpretation eines Satzes benötigt wird, aus dem vorhergehenden Text stammen sollte. Andere sagen, dass die Beschränkung von spätem Chunking auf unidirektionale Blöcke die gemeinsame Nutzung von Kontexten zwischen Chunks verhindert. In jedem Fall bleibt die Wirksamkeit von spätem Chunking in v4 fraglich und bedarf weiterer Untersuchungen.

tagEffiziente Vektorabbildungen über llama-embedding

llama-embedding ist ein relativ einfacher C++-Wrapper auf Basis von llama.cpp zur Einbettung von Text mit sehr sauberem I/O: stdin, stdout. Wir konzentrieren uns im Moment darauf, dies zu verbessern, anstatt llama-server, da es unzählige andere Probleme wie Netzwerk-Queuing, Lastverteilung, Multi-Tenancy und Serialisierung gibt, die unserer Meinung nach an dieser Stelle nicht relevant sind. Unsere Frage ist einfach: Wie viel Geschwindigkeit können wir von einer L4 24GB GPU bekommen und wie hoch ist die maximale VRAM-Auslastung für die Einbettung langer Dokumente?

Aber warum L4? Hauptsächlich, weil GCP recht praktische Cloud Run-Funktionen darauf anbietet und es der am weitesten verbreitete und wirtschaftlichste GPU-Typ ist, den Sie für serverlose Inferenz-APIs erhalten können. GCP bietet auf Anfrage A100 und H100 auf Cloud Run an, und wir werden von Zeit zu Zeit vom GCP-Team angesprochen, bessere GPUs zu verwenden. Aber unsere Philosophie ist einfach: Wenn wir A100/H100 benötigen, um ein 3B-Modell zu bedienen, ist das eindeutig ein Problem unsererseits.

Für einige Hintergrundinformationen: In llama.cpp ist die logische Batch-Größe (-b) stellt die maximale Anzahl an Tokens dar, die dem Modell in einem einzelnen Auswertungsvorgang übermittelt werden. Bei der Verarbeitung langer Eingaben werden diese in Abschnitte bis zu dieser Größe aufgeteilt. Die physische Batch-Größe (-ub) ist die tatsächliche Anzahl an Tokens, die gleichzeitig in einem Vorwärtsdurchlauf durch die Hardware verarbeitet werden, begrenzt durch den verfügbaren Speicher. Die KV-Cache-Aktualisierungen erfolgen nach Abschluss jedes physischen Batches. Das Kontextfenster (-c) ist die harte Grenze für die Anzahl der Tokens, die das Modell gleichzeitig "sehen" kann - für v4-Modelle sind dies 32.000 Tokens, die die maximale Aufmerksamkeitsspanne des Modells darstellen. Alle Tokens müssen in dieses Kontextfenster passen, um eine kohärente Aufmerksamkeit über die gesamte Sequenz aufrechtzuerhalten. Die folgende Abbildung veranschaulicht ihre Beziehungen.

tagUnsere Korrekturen

GitHub - hanxiao/llama.cpp: LLM inference in C/C++

LLM inference in C/C++. Contribute to hanxiao/llama.cpp development by creating an account on GitHub.

GitHubhanxiao

In unserem obigen Fork haben wir mehrere Optimierungen vorgenommen, um llama-embedding effizienter zu gestalten:

• Vereinfachte Batch-Verarbeitung: Wir setzen -b automatisch gleich -c, wodurch dieser Parameter faktisch hinfällig wird. Benutzer müssen -b nicht mehr angeben, da wir immer die volle Kontextlänge des Modells für die logische Batch-Verarbeitung nutzen.
• Flexible Speichersteuerung: Im Gegensatz zur ursprünglichen Implementierung, bei der -ub gezwungen war, gleich -b zu sein (da sie davon ausgingen, dass Einbettungsmodelle nicht kausal sein können), erlauben wir Benutzern, -ub unabhängig festzulegen. Dies ermöglicht eine feinkörnige Kontrolle über die maximale VRAM-Auslastung beim Codieren langer Kontexte - Sie können einen 32K-Kontext mit einem kleinen physischen 512-Token-Batch verarbeiten, um dank der KV-Cache-Implementierung innerhalb der VRAM-Grenzwerte zu bleiben. Beachten Sie, dass diese Änderung nur für kausale Einbettungsmodelle wie jina-embeddings-v4 korrekt ist - für reine Encoder-Architekturen wie v3 wäre dies die falsche Implementierung.
• Korrigiertes Mean Pooling: Wir haben die Mean-Pooling-Berechnung für Vektormodelle korrigiert, wenn ub < b, die zuvor in der ursprünglichen Implementierung fehlerhaft war.

Diese Änderung erleichtert die Arbeit mit Decoder-only Vektormodellen mit langer Kontextlänge und gleichzeitig effektiver Verwaltung von Speicherbeschränkungen erheblich. Benutzer müssen jetzt nur noch zwei Parameter konfigurieren:

• -c: Die maximale Kontextlänge (wie viele Tokens das Einbettungsmodell verarbeiten kann)
• -ub: Die physische Batch-Größe (wie viele Tokens die GPU gleichzeitig verarbeitet)

Der genaue Code für die Ausführung unseres Forks auf L4 lautet wie folgt:

# Compile
git clone https://github.com/hanxiao/llama.cpp.git
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j 8

# Run
INPUT_PREFIX="Query: "  # or "Passage: "

cat big_input.txt | sed "s/^/${INPUT_PREFIX}/" | \
./llama.cpp/build/bin/llama-embedding -f /dev/stdin \
    -hf "jinaai/jina-embeddings-v4-text-retrieval-GGUF:FP16" \
    --pooling mean \
    --no-escape \
    --embd-output-format array \
    --ubatch-size 512 \
    --ctx-size 8192 \
    --flash-attn \
    -ngl 99 \
    > "embeddings.txt" 2> "error.log"
Kopieren

tagBenchmark

Wir möchten durch Benchmarking die folgenden Fragen beantworten:

• Wie gut ist unsere Quantisierung im Vergleich zum ursprünglichen v4 Float16? Ab welchem Punkt verschlechtert sie sich so stark, dass wir besser dran wären, nur v3 Vektormodelle zu verwenden?
• Wie schnell kann jede Quantisierung auf L4 laufen und wie hoch ist die maximale VRAM-Auslastung?
• Wie beeinflussen die physische Batch-Größe -ub und die Kontextlänge -c die Geschwindigkeit und die maximale VRAM-Auslastung?

Datensätze, die wir im Benchmarking verwendet haben, sind:

Wir haben unseren benutzerdefinierten Build von llama-embedding für das Benchmarking verwendet.

tagQualität der Quantisierungen

Die am besten abschneidende quantisierte Version ist IQ3_M (3.84 BPW) - Quantisierungen unter 2 Bit schneiden schlechter ab als v3, daher ist es wenig sinnvoll, sie zu verwenden.

tagGeschwindigkeit und VRAM

Wir legen nun den Benchmark-Datensatz auf NanoHotpotQA fest und stellen alle Quantisierungen nach ihren Bits pro Gewichtung im Vergleich zur Geschwindigkeit (gemessen in Tokens pro Sekunde) und dem VRAM-Verbrauch dar. Wir haben festgestellt, dass GGUF-Versionen bei FP16 etwas schneller sind als die Vanilla-Version (2023 vs. 1865 Tokens/Sek.). Die meisten Quantisierungen gruppieren sich um 2000-2100 Tokens/Sek. Mit aktivierter Flash-Attention erhalten wir eine Geschwindigkeitssteigerung von ~77 % über alle Quantisierungen hinweg (3000+ vs. 2000+ Tokens/Sek.). Die am besten abschneidende Quantisierung Q8_0 mit etwa 3700 Tokens pro Sekunde liegt jedoch immer noch weit hinter Vanilla v3 (572M Parameter) zurück, die 16000 Tokens/Sek. erreicht. Quantisierte Versionen sparen erheblich VRAM und nähern sich mit IQ3 fast dem Niveau des v3 FP16-Modells.

tagOptimale physische Batch- und Kontextgröße

Wir legen nun den Quantisierungstyp auf IQ3_S fest und untersuchen, wie sich die physische Batchgröße (-ub) und die Kontextgröße (-c) auf die Geschwindigkeit und den VRAM auswirken. Die Ergebnisse auf der L4-GPU zeigen, dass -ub=512 mit -c=2048 die optimale Konfiguration darstellt, die 4.143 Tokens/Sek. liefert und dabei 2.025 MB VRAM verbraucht. Die Erkenntnis ist intuitiv: Wenn Sie die maximale Länge eines einzelnen Dokuments in Ihrer Eingabe kennen, verwenden Sie eine kleinere Kontextgröße, die gerade ausreicht, um es abzudecken. Für die physische Batchgröße scheinen 512 Tokens der Sweet Spot auf der L4-GPU zu sein.

Tokens pro Sekunde Leistung

Maximale VRAM-Nutzung (MB)

tagFazit

Für v4-Benutzer, die quantisierte GGUF effizient auf kostengünstigen GPUs ausführen möchten, wählen Sie IQ3_S oder IQ3_M mit unserem benutzerdefinierten Build von llama-embedding - dies sollte Ihnen 4000 Tokens/Sek. auf regulären Datensätzen (bei denen die Satzlänge <2048 Tokens beträgt) liefern. Um längere Dokumente einzubetten, erhöhen Sie die Kontextgröße -c und steuern Sie die physische Batchgröße -ub, um den VRAM-Fußabdruck zu reduzieren. Mit unserem benutzerdefinierten Build können Sie super lange Dokumente (>32K Tokens) mit nur 3 GB VRAM kodieren, indem Sie -ub auf eine kleine Zahl wie 1024 setzen - etwas, das mit der ursprünglichen Implementierung oder Vanilla-Transformern nicht möglich war.

Die Suche nach Geschwindigkeitsoptimierung endet nie. Es gibt immer Raum für schnellere, schlankere Implementierungen mit höherem Durchsatz. 4000 Tokens/Sek. sind wahrscheinlich nicht unsere Obergrenze - es gibt noch viel zu tun. Neben der Behebung der qwen2.5-vl-3b mmproj/Vision-Transformer-Implementierung in llama.cpp untersuchen wir auch tiefere Optimierungen auf Llama.graph- und KV-Cache-Ebene, verbessern die Batching-Logik von llama-serving und fügen Streaming-Optionen zu Embedding-APIs hinzu. Unser Ziel ist es, dass llama.cpp nativ moderne, reine Dekoder-Multimodal- Embeddings für unsere aktuellen und zukünftigen Reranker-Releases unterstützt.