Multimodale Vektormodelle in Llama.cpp und GGUF

Wir haben mehrere Fehler in unserem Fork von llama.cpp behoben, sodass es mit jina-embeddings-v4 auf multimodalen VektorModellen funktioniert.

jina-embeddings-v4 führt hochmoderne multimodale VektorModelle ein, die Text, Bilder und komplexe visuelle Dokumente für die Vektorsuche verarbeiten können. Vor einigen Wochen haben wir v4's GGUFs und dynamische Quantisierungen für reine Textaufgaben veröffentlicht, die einen geringeren VRAM-Bedarf und eine verbesserte Leistung bieten. Die Unterstützung für multimodale VektorModelle auf GGUF fehlte jedoch noch. Um das Bild zu vervollständigen, haben wir nun herausgefunden, wie man multimodale VektorModelle mit llama.cpp und GGUF generiert. Weitere Informationen finden Sie in dieser README-Datei.

Fairerweise muss man sagen, dass llama.cpp Upstream einige Unterstützung für multimodale Eingaben bietet, aber da sich der Großteil der llama.cpp-Community auf LLMs und Textgenerierung konzentriert, fehlt die Unterstützung für die multimodale VektorModell-Ausgabe vollständig. In diesem Artikel erklären wir, wie wir multimodale VektorModelle in llama.cpp implementiert haben, und untersuchen, wie sie (zusammen mit zwei quantisierten Versionen) im Vergleich zur PyTorch-Version von jina-embeddings-v4 abschneidet. In diesem Artikel bezeichnen wir die PyTorch-Version als unser "Referenzmodell".

tagBild-Eingabe in Llama.cpp verstehen

Lassen Sie uns zunächst zusammenfassen, wie multimodale VektorModelle mit unserem Referenzmodell erstellt werden. Zuerst paaren Sie jede Bildeingabe mit einem speziellen Prompt:

<|im_start|>user\n<|vision_start|><|image_pad|><|vision_end|>Describe the image.<|im_end|>\n

Dann verarbeitet das Modell das Bild vor, codiert es (über sein ViT) und verarbeitet dann die gesamte verschachtelte Sequenz in einem einzigen Vorwärtsdurchlauf.

Bei llama.cpp sind die Dinge jedoch komplizierter. Obwohl es Bildeingaben für die Chat-Vervollständigung unterstützt, unterstützt es keine multimodalen Eingaben – nämlich Eingaben (wie die obige), die sowohl Text als auch ein Bild kombinieren. Das ist genau der Grund, warum wir llama.cpp geforkt haben und den Embedding-Handler so geändert haben, dass er Base64-codierte Bilder akzeptiert, wodurch wir multimodale Inhalte auf ähnliche Weise wie den Chat-Vervollständigungs-Handler verarbeiten können.

Um nun mit multimodalen Eingaben in llama.cpp zu arbeiten, können wir mit einem Prompt beginnen, der dem des Referenzmodells ähnelt:

<|im_start|>user\n<__image__>Describe the image.<|im_end|>\n

Der Prozess funktioniert wie folgt:

llama.cpp umgibt den <__image__> Token mit Visionsmarkierungen <|vision_start|> und <|vision_end|>, wodurch wir so etwas wie dieses erhalten: <|im_start|>user\n<|vision_start|><__image__><|vision_end|>Describe the image.<|im_end|>\n
Der Tokenizer ersetzt das spezielle <__image__> Token durch -1, wenn er den Prompt tokenisiert, wodurch intern signalisiert wird, dass die Sequenz ein Bild enthält, das zuvor codiert werden sollte (und später verarbeitet wird).
Die Text-Tokens vor der <__image__> Markierung (nämlich <|im_start|>user\n<|vision_start|>) werden über das LLM decodiert und in den KVCache injiziert.
Das Bild wird über die ViT-Komponente codiert, wobei eine Reihe von Bild-Tokens ausgegeben werden, die über das LLM decodiert werden. Obwohl diese Tokens getrennt von den Tokens in Schritt eins verarbeitet werden, können die Aufmerksamkeits-Layer über den KVCache weiterhin auf diese Text-Tokens zugreifen. Zu diesem Zeitpunkt können die Aufmerksamkeits-Layer jedoch nicht auf spätere Text-Tokens (<|vision_end|>Describe the image.<|im_end|>\n) zugreifen.
Das LLM decodiert alle verbleibenden Text-Tokens (<|end_vision|>Describe the image.<|im_end|>\n). Jetzt können die Aufmerksamkeits-Layer über den KVCache auf alle früheren Tokens (sowohl Text als auch Bild) zugreifen.

Der VektorModell-Inferenzprozess (Bildcodierung und Text-/Bild-Token-Decodierung) ist in der folgenden Abbildung dargestellt:

Abbildung 1: VektorModell-Inferenzprozess der jina-embeddings-v4 llama.cpp Version.

tagAufmerksamkeit auf Bild-Tokens

Aufgrund des Aufmerksamkeitsmechanismus kann dieser mehrstufige Prozess für einige Modelle problematisch sein. Lassen Sie uns kurz die verschiedenen Arten von Aufmerksamkeit zusammenfassen, die in Modellen verwendet werden:

Kausale Aufmerksamkeit - der Aufmerksamkeitsmechanismus für ein Token an Position k achtet nur auf vorherige Tokens an den Positionen [0:k-1].
Nicht-kausale Aufmerksamkeit - der Aufmerksamkeitsmechanismus für ein Token an Position k achtet auf alle Tokens in der Sequenz [0:n].

Die folgende Abbildung zeigt die Tokens, auf die der Aufmerksamkeitsmechanismus bei der Verarbeitung von img_tok_n im zweiten Schritt achten würde:

Abbildung 2: Kausale vs. nicht-kausale Aufmerksamkeit

Bei der Verarbeitung von img_tok_n ist der Zustand des Modells wie folgt:

Alle vorherigen Text-Tokens (<|im_start|>, user, \n, <|vision_start|>) wurden bereits verarbeitet und im KVCache gespeichert.
Alle Bild-Tokens (img_tok_1 bis img_tok_n) werden zu diesem Zeitpunkt als Teil derselben Sequenz verarbeitet.
Alle folgenden Text-Tokens (<|vision_end|>, Describe usw.) werden später verarbeitet.

Im Fall von kausaler Aufmerksamkeit werden nur vorherige Tokens bei der Berechnung von Aufmerksamkeitswerten berücksichtigt, wobei vergangene Tokens über den KVCache abgerufen werden.

Im Fall von nicht-kausaler Aufmerksamkeit sollten alle Tokens berücksichtigt werden. Zukünftige Text-Tokens (<|vision_end|>, Describe usw.) wurden jedoch noch nicht verarbeitet. Sie werden in einem zukünftigen Schritt verarbeitet, sodass die Dinge schnell kaputt gehen.

Da jina-embeddings-v4 kausale Aufmerksamkeit verwendet, funktioniert der mehrstufige Prozess problemlos, aber für andere Modelle ist dies möglicherweise nicht der Fall.

In Bezug auf VektorModelle werden die verborgenen Zustände jedes Tokens genau dann erfasst, wenn sie verarbeitet und am Ende zu einer einzigen Sequenz zusammengefasst werden. Derzeit werden Normalisierung und Pooling in Python behandelt, aber (mit etwas mehr Aufwand) könnte dies auch auf der llama.cpp-Seite erfolgen.

tagUnsere Fehlerbehebungen

Nachdem wir Bildeingaben für den VektorModell-Endpunkt im llama.cpp-Server aktiviert hatten, begannen wir mit dem Testen der Implementierung mit Benchmarks und stellten überraschend große Unterschiede im Vergleich zu unserem Referenzmodell fest. Wir vermuteten, dass etwas mit der Implementierung des ViT von llama.cpp nicht stimmte, das von Qwen2.5-VL verwendet wird, um Bilder in Bild-Patch-VektorModelle (dichte Vektordarstellung von Bildquadraten) zu codieren, die Qwen2.5 LLM verarbeiten kann.

Hier ist ein Beispiel dafür, wie sich die ViT-Ausgaben zwischen dem Referenzmodell und der llama.cpp-Implementierung unterscheiden:

=== vit_out reference === Shape: [1008, 1280]
Logging patch 0, dimensions 0-9
Patch 0: -0.375000 -0.250000 -4.281250 -5.968750 2.953125 -8.125000 8.625000 -9.250000 8.937500 -0.332031 ... (dims 10-1279)
... (patches 1-1007 not shown)

=== vit_out llama.cpp === Shape: [1280, 1008, 1, 1]
Logging patch 0, dimensions 0-9
Patch 0: -2.998136 -2.226554 0.233671 -7.486460 0.596918 -12.889042 8.904849 -8.6
... (patches 1-1007 not shown)

Wie Sie sehen können, sind die Unterschiede recht deutlich. Um zu bestätigen, dass dies das einzige Problem war, haben wir die Bild-Tokens in Python vorab berechnet und sie dann mit der Implementierung von Qwen2.5 durch llama.cpp (nur mit dem LLM) decodiert, in der Hoffnung, dass die resultierenden VektorModelle viel enger mit den Werten des Referenzmodells übereinstimmen würden – dies war jedoch nicht der Fall.

tagFehlerbehebung Nr. 1: Kausale Aufmerksamkeitsmaske für Aufmerksamkeits-Layer

Wir haben das Debugging fortgesetzt, indem wir uns die Aufmerksamkeits-Layer angesehen haben – die wahrscheinlichste Ursache für die Zahlenunterschiede. Wir stellten fest, dass die von den Aufmerksamkeits-Layern verwendete Aufmerksamkeitsmaske für Bild-Tokens nicht korrekt berechnet wurde. Um dies zu sehen, können wir zu unserer Beispielsequenz zurückkehren:

<|im_start|>user\n<|vision_start|><__image__><|vision_end|>Describe the image.<|im_end|>\n

Bei der Verarbeitung von Bild-Tokens wird die <__image__> Markierung in so etwas wie img_tok_1 img_tok_2 .... img_tok_last entpackt. Die vollständige Sequenz wäre also:

<|im_start|>user\n<|vision_start|> img_tok_1 img_tok_2 ... img_tok_last <|vision_end|>Describe the image.<|im_end|>\n

⚠️

Hinweis: Zu diesem Zeitpunkt in der Pipeline sind sowohl die Text-Tokens (<|im_start|>, user usw.) als auch die Bild-Tokens (img_tok_1,img_tok_2 usw.) sind dichte Vektoren und keine tatsächlichen Text-Tokens. Wir verwenden diese Form der Sequenz, um die Erklärung zu vereinfachen. Beim Dekodieren von img_tok_2 *sollte* der Aufmerksamkeitsmechanismus auf alle vorherigen Tokens achten, nämlich:

<|im_start|>user\n<|vision_start|> img_tok_1

Ein Fehler in der Aufmerksamkeitsmaske führte jedoch *stattdessen* dazu, dass der Mechanismus auf die gesamte Bildsequenz achtete, wie folgt:

 <|im_start|>user\n<|vision_start|> img_tok_1 img_tok_2 ... img_tok_last

Nachdem wir diesen Fehler behoben hatten, stimmten die Embeddings unseres llama.cpp-Modells (unter Verwendung der vorab berechneten Bild-Tokens aus dem ViT des Torch-Modells) endlich mit den Referenzmodell-Embeddings überein (innerhalb einer kleinen Fehlermarge). ### Fehlerbehebung Nr. 2: Bildverarbeitung und Patch-Embeddings Der ViT-Encoder von llama.cpp erzeugte auch unterschiedliche Bild-Embeddings als das Referenzmodell, wobei die Zahlen unmittelbar nach der Vorverarbeitung abwichen. Dies zeigte sich besonders während des anfänglichen Patch-Erstellungsschritts, bei dem sowohl unser Referenzmodell als auch llama.cpp das Rohbild (Pixelwerte) in Patches aufteilten, die über Faltungsschichten kodiert werden. Die Unterschiede zwischen den Roh-Patches (vor der ViT-Verarbeitung) sind unten zu sehen: ```text === raw_patches reference === Shape: [1008, 1176] Logging patches 0-4, dimensions 0-9 Patch 0: 0.484375 0.484375 0.500000 0.500000 0.470703 0.470703 0.470703 0.484375 0.470703 0.484375 ... (dims 10-1175) ... (patches 1-1007 not shown) ``` ```text === raw_patches llama.cpp === Shape: [1176, 1008, 1, 1] Logging patches 0-4, dimensions 0-9 Patch 0: 0.455895 0.455895 0.455895 0.455895 0.455895 0.455895 0.470494 0.470494 0.470494 0.470494 ... (dims 10-1175) ... (patches 1-1007 not shown) ``` Unser Referenzmodell und llama.cpp verarbeiten diese Patches auf unterschiedliche Weise: * Das Referenzmodell gruppiert die Pixelwerte mithilfe von Reshape-Operationen und verwendet dann eine einzelne conv3d-Schicht, um die vorab gruppierten Pixel-Patches zu kodieren. * Das llama.cpp-Modell erstellt und kodiert diese Patches mit zwei conv2d-Schichten. Um die Embeddings des llama.cpp-Modells denen des Referenzmodells anzunähern, hielten wir es für einfacher, die exakten Operationen des Referenzmodells zu verwenden, anstatt den Ansatz von llama.cpp zu debuggen. Unser Referenzmodell generiert Pixel-Patches mithilfe komplexer Reshape- und Transpose-Operationen, die 9-dimensionale Tensoren erfordern. Die in llama.cpp verwendete Low-Level-Tensorverarbeitungsbibliothek — [ggml](https://github.com/ggml-org/ggml) — kann diese nicht unterstützen. Um dies zu umgehen, haben wir die Patches mithilfe eines separaten Python-Dienstes generiert, der den llama.cpp-Server über HTTP aufruft. ggml unterstützt auch keine conv3d-Schichten. In unserem Referenzmodell sieht die conv3d-Schichtkonfiguration wie folgt aus: ```python kernel_size = [ 2, # temporal_patch_size, 14, # patch_size 14 # patch_size ] proj = nn.Conv3d( 3, # in_channels 1152, # embed_dim, kernel_size=kernel_size, stride=kernel_size, bias=False ) ``` Sie können sehen, dass stride und kernel_size identisch sind, was bedeutet, dass wir einfach die Eingaben und die Gewichte der conv3d-Schicht reduzieren und stattdessen eine einfache Matrixmultiplikationsoperation durchführen können. Zu diesem Zweck haben wir das Konvertierungsskript in llama.cpp (convert_hf_to_gguf.py) geändert, um eine reduzierte Version der conv3d-Gewichte für die Patch-Projektionsschicht zu exportieren: ```python if 'patch_embed.proj.weight' in name: c1, c2, kt, kh, kw = data_torch.shape # Note: this part of the script also exports other versions of this layer # Only showing the relevant parts # Flat matmul weight: row-major [out, in*kT*kH*kW] = [embed_dim, 1176] W_flat = data_torch.contiguous().view(c1, -1) outputs.append(("v.patch_embd.weight_flat", W_flat)) ``` Um die Matmul-Operation anstelle der beiden conv2d-Schichten in llama.cpp anzuwenden, haben wir den Code geändert, der den Graphen des Qwen2.5-VL ViT erstellt: ```cpp ggml_tensor * build_inp_raw_precomputed() { ggml_tensor * inp_raw = ggml_new_tensor_2d( ctx0, GGML_TYPE_F32, img.p_dim, img.npx * img.npy ); ggml_set_name(inp_raw, "inp_raw"); ggml_set_input(inp_raw); return inp_raw; } ggml_cgraph * build_qwen2vl() { // NOTE: only showing the code we've added for using pre-arranged image patches const bool uses_precomputed_image = img.is_precomputed; ggml_tensor * inp = nullptr; if (uses_precomputed_image) { ggml_tensor * inp_raw = build_inp_raw_precomputed(); cb(inp_raw, "inp_raw", -1); inp = ggml_mul_mat(ctx0, model.patch_embeddings_flat, inp_raw); } else { // Usual 2x conv2d path } // rest of the code } ``` Mit diesen letzten Änderungen lagen die endgültigen Bild-Embeddings innerhalb einer Fehlermarge von 2 % im Vergleich zum Referenzmodell (wie in der Bewertungstabelle im nächsten Abschnitt zu sehen ist). ## Bewertung Nachdem wir diese Änderungen vorgenommen hatten, haben wir das llama.cpp-Modell anhand unseres Referenzmodells für [ViDoRe-Aufgaben](https://huggingface.co/spaces/vidore/vidore-leaderboard) unter Verwendung des [MTEB-Benchmarks](https://huggingface.co/spaces/mteb/leaderboard) bewertet. Sie können das [Skript und die Anweisungen](https://github.com/jina-ai/llama.cpp/tree/master/jina_embeddings) finden, um diese Ergebnisse in unserem llama.cpp-Fork sowie zwei quantisierten Versionen zu replizieren.

Aufgabe	Referenzmodell	llama.cpp (F16)	llama.cpp (Q4_K_M)	llama.cpp (IQ4_XS)
VidoreArxivQARetrieval	83.55	85.00	84.38	84.34
VidoreDocVQARetrieval	50.53	52.02	51.93	51.57
VidoreInfoVQARetrieval	87.77	87.31	87.61	87.28
VidoreShiftProjectRetrieval	84.07	82.25	82.56	81.73
VidoreSyntheticDocQAAIRetrieval	97.52	96.71	97.28	97.15
VidoreSyntheticDocQAEnergyRetrieval	91.22	90.34	90.47	90.30
VidoreSyntheticDocQAGovernmentReportsRetrieval	91.61	93.84	93.47	94.47
VidoreSyntheticDocQAHealthcareIndustryRetrieval	95.42	96.08	95.67	96.05
VidoreTabfquadRetrieval	94.52	94.94	94.83	94.72
VidoreTatdqaRetrieval	65.52	64.85	64.63	64.76
Durchschnitt	84.17	84.33	84.28	84.23

Betrachtet man die Ergebnistabelle, so weichen das llama.cpp-Modell und seine quantisierten Varianten im Durchschnitt nicht wesentlich vom Referenzmodell ab. Um die Modelle detaillierter zu vergleichen, haben wir Bilder aus verschiedenen Bereichen und mit unterschiedlichen Auflösungen verwendet und den Abstand zwischen Bild-Patch-Embeddings (vor Pooling/Normalisierung) dargestellt. Je röter der Patch, desto größer ist der Cosinus-Abstand zwischen den Vektoren des Referenzmodells und des llama.cpp-Modells für diesen bestimmten Patch. Figure 3: Page from jina-embeddings-v4 technical report, 372 × 526 resolution (left), 2481 × 3508 resolution (right) Figure 4: Screenshot from Jina AI website, 594 × 428 resolution (left), 1982 × 1428 resolution (right) Figure 5: Tokyo, Shibuya by S K on Unsplash, 383 × 255 resolution (left), 5472 × 3649 resolution (right) Wir wollten Muster erkennen, die über numerische Präzisionsunterschiede hinausgehen – Muster, die weitere Fehler oder Unterschiede zwischen unseren Modellen aufdecken könnten. Es waren jedoch keine besonderen Muster erkennbar, außer dass die Anzahl der abweichenden Patches mit der Bildauflösung zunimmt. Diese Unterschiede treten höchstwahrscheinlich aufgrund von Backend-Unterschieden auf und nicht aufgrund von bestimmten Fehlern in der Implementierung von Qwen2.5-VL (dem Backbone-Modell von jina-embeddings-v4).

Nichtsdestotrotz müssen wir wiederholen, dass diese Unterschiede minimal sind und die Benchmark-Ergebnisse dies ebenfalls widerspiegeln. Insgesamt schneiden die llama.cpp-Modelle genauso gut ab wie das Referenzmodell, obwohl sie etwas unterschiedliche Vektor-Modelle erzeugen.

tagVerbleibende Probleme

Es gibt mehrere potenzielle Verbesserungsbereiche für multimodale Vektor-Modelle in llama.cpp:

Quantisierung des Vision Encoders. Derzeit unterstützt llama.cpp nur die Quantisierung für LLMs, aber um eine bessere Skalierung zu erreichen, möchten wir auch den Vision Encoder quantisieren.

💡

Hinweis: llama.cpp unterstützte früher die Quantisierung von CLIP-Modellen mithilfe von llama-llava-quantize-cli, aber die entsprechenden Ressourcen wurden seit der Einführung der Bibliothek mtmd entfernt.

Auslagerung des Vision Encoders in einen dedizierten Dienst. Vision Encoder verwenden typischerweise nicht-kausale Maskierung, was bedeutet, dass jedes gegebene Bild innerhalb eines einzigen Forward-Aufrufs codiert werden muss. Daher können wir Continuous Batching nicht nutzen. Wir könnten jedoch in Erwägung ziehen, den Vision Encoder in einen separaten Dienst auszulagern, der mehrere Bilder (auch aus verschiedenen Quellen) zusammenfasst und alle in einem einzigen Forward-Pass codiert. Dies würde höhere vRAM-Anforderungen bedeuten, wäre aber auch viel schneller als die Codierung jedes Bildes einzeln. Diese Trennung würde auch bedeuten, dass wir den Vision Encoder unabhängig vom Sprachmodell automatisch skalieren könnten.
Aktivierung von Multi-Vektor-Modellen. In diesem Artikel haben wir nur mit Single-Vektor-Modellen gearbeitet. Um jedoch jina-embeddings-v4 voll auszuschöpfen, möchten wir auch Multi-Vektor-Modelle aktivieren, um eine höhere Genauigkeit bei komplexen Bildern zu erzielen. Dies wäre eine einfache Ergänzung, da diese Vektor-Modelle mit einer einzigen linearen Schicht auf dem Basismodell generiert werden.

tagFazit

Trotz anfänglicher Fehler und Rückschläge liefert die Integration multimodaler Vektor-Modelle in llama.cpp nun Ergebnisse, die eng mit unserem PyTorch-Referenzmodell übereinstimmen, auch bei einer Reihe von Benchmark-Aufgaben. Korrekturen der Aufmerksamkeitsmaske und der Bildpatch-Verarbeitung beseitigten die Hauptursachen für die Divergenz, und selbst die quantisierten Varianten erzielen eine ähnliche Genauigkeit bei weitaus geringerem Ressourcenverbrauch. Die verbleibenden Unterschiede bei höheren Bildauflösungen scheinen geringfügig zu sein und sind wahrscheinlich auf Backend-Variationen und nicht auf die Kernmodellimplementierung zurückzuführen.

Mit Blick auf die Zukunft würden die Erweiterung der Quantisierung auf den Vision Encoder, die Aktivierung der Batch-Verarbeitung über einen separaten Dienst und die Unterstützung von Multi-Vektor-Modellen sowohl die Effizienz als auch die Genauigkeit weiter verbessern. Diese Ergänzungen würden multimodale Vektor-Modelle in llama.cpp skalierbarer und besser für reale Anwendungsfälle geeignet machen.