ColPali und ColQwen2 für die visuelle Dokumentsuche: GPU, Indexgröße und Vektordatenbank

Seitenbilder statt OCR-Text

ColPali findet gescannte PDF-Seiten voller Tabellen oder Diagramme über ihr Bild, ohne OCR, Layouterkennung und Chunking: Ein Vision-Language-Modell macht aus jeder Seite eine Menge kleiner Vektoren, einen je Bildausschnitt (Patch), und eine Anfrage wird per Late Interaction mit allen verglichen. Für die Indexierung genügt ein Vorwärtsdurchlauf eines Modells mit 2B bis 3B Parametern je Seite, den eine L4 oder L40S bewältigt. Was wächst, ist der Index: rund 264 GB je Million Seiten für ColPali in 16 Bit, gegenüber rund 9 GB für einen Textvektor je Chunk.

Das ColPali-Paper (arXiv 2407.01449, Version 6 vom 28. Februar 2025) baut auf PaliGemma-3B auf. Seine Modellkarte zeigt die Form der Einbettung einer Seite als (1030, 128): 1.024 Bild-Patches, die ein Eingabebild von 448 × 448 Pixeln in Patches zu 14 × 14 Pixeln ergibt, plus 6 Text-Token, jeweils auf 128 Dimensionen projiziert. Das Paper nennt dafür „a memory footprint of 257.5 KB per page“ und rechnet dabei mit 1.024 Byte je Kilobyte; in Dezimaleinheiten sind es 263,7 KB, der Wert unserer Tabellen.

Die Bewertung folgt ColBERT: Für jeden Anfragevektor wird der ähnlichste Seitenvektor gesucht, und diese Maxima ergeben in Summe die Punktzahl der Seite, was Qdrant und Milvus MaxSim nennen. Unser Leitfaden zu Embedding- und Reranker-Servern für RAG dimensioniert den Textweg, und Vision-Language-Modelle für Dokumenten-KI dimensioniert OCR und Extraktion mit VLMs. Dieser Artikel dimensioniert die Suche über Seitenbilder, die beide nicht abdecken.

Visuelle Retriever und ihre Lizenzen

Hugging-Face-Modellkarten von vidore/colpali-v1.3, vidore/colqwen2-v1.0, vidore/colqwen2.5-v0.2 und nvidia/llama-nemotron-colembed-vl-3b-v2 sowie die LICENSE-Datei von Qwen2.5-VL-3B-Instruct, gelesen am 24. Oktober 2026; NVIDIAs Kachelzahl ist ein Maximum (8 Kacheln plus ein Vorschaubild), das Produkt 2.304 ist unsere Rechnung.

Für die Nutzung im Unternehmen entscheidet die Lizenz des Backbones. ColQwen2 v1.0 gibt an, sein Backbone „is under apache2.0 license“ und seine Adapter unter MIT; eine kommerzielle Einschränkung besteht also nicht. ColPali v1.3 schreibt, sein Backbone „is under gemma license as specified in its model card“. Das Backbone von ColQwen2.5 steht unter dem Qwen Research License Agreement vom 19. September 2024, das Rechte „FOR NON-COMMERCIAL PURPOSES ONLY“ gewährt und festhält: „If you are commercially using the Materials, you shall request a license from us.“ NVIDIAs llama-nemotron-colembed-vl-3b-v2, veröffentlicht am 26. Januar 2026, „is for non-commercial/research use only“. Ob eine bestimmte Nutzung unter eine dieser Lizenzen fällt, klärt Ihre Rechtsabteilung.

ColQwen2 und ColQwen2.5 verarbeiten dynamische Auflösungen, und ihre Karten setzen das Maximum so, dass „768 image patches are created at most“; das Qdrant-Tutorial setzt für eine typische Seite rund 700 an. Beide Karten weisen darauf hin, dass die Modelle sich auf „PDF-type documents and high-ressources languages“ konzentrieren; testen Sie sie also an eigenen deutschen, polnischen oder tschechischen Seiten, bevor Sie einen Index dimensionieren.

Indexgröße je Million Seiten

Unsere Rechnung: Vektoren × Dimensionen × Byte, GB = 10^9 Byte; 2,1 Chunks je Seite aus dem ColPali-Paper; Pool-Faktor 3 verringert die Vektoren laut Paper um 66,7 Prozent; Indexstrukturen, Metadaten und Replikate nicht enthalten.

Das Paper berichtet, dass Token-Pooling mit dem Faktor 3 „maintains 97.8% of the original performance“, wobei ein textlastiger Datensatz stärker nachlässt. Mit 1 Bit je Dimension speichert die binäre Quantisierung einen Vektor, wie unser Vergleich der Vektordatenbanken für Qdrant beschreibt; prüfen Sie, ob Ihre Datenbank das auf Multi-Vector-Felder anwendet, bevor Sie mit der Zeile von 16,5 GB planen. Die NVIDIA-Zeile zeigt, wie schnell der Index mit den Dimensionen wächst: Mit 3.072 Dimensionen je Token überschreitet eine volle Seite nach unserer Rechnung Qdrants Grenze „number_of_sub_vectors * vector_size < 1,048,576“ je Punkt, während ColPali mit 131.840 Werten deutlich darunter bleibt.

Ein Index von einigen Hundert GB liegt auf NVMe, nur der Teil, den die erste Stufe durchsucht, im Arbeitsspeicher. Unser Leitfaden zu NVMe-Speicher für einen LLM-Server behandelt die Laufwerke. Wir liefern die GPUs und Server für einen solchen Index; schicken Sie uns Seitenzahl, Zuwachs pro Jahr und Suchlast, und unser Team antwortet mit einer Dimensionierung von Speicherplatz, Arbeitsspeicher und GPUs.

GPU für die Indexierung: ein Durchlauf je Seite

Beim Indexieren wird jede Seite auf dem Prozessor zu einem Bild gerendert und einmal durch den Encoder geschickt. Eine Textgenerierung gibt es nicht, und genau sie macht OCR mit einem VLM langsam: Ein OCR-Modell schreibt Hunderte bis Tausende Token je Seite nacheinander, wie unser VLM-Leitfaden zeigt. ColQwen2 v1.0 hat 4,42 GB BF16-Gewichte, rund 2,2B Parameter, und passt damit auf jede Karte, die wir liefern, mit Platz für große Batches.

Nach der üblichen Zählung kostet ein Vorwärtsdurchlauf mindestens 2 Operationen je Parameter und Token; eine ColQwen2-Seite mit 768 Token kostet also mindestens rund 3,4 × 10^12 Operationen, und die Arbeit des Vision-Encoders an den Bild-Patches kommt hinzu. Teilt man die von StorageReview gemessenen BF16-Matrixraten durch diesen Wert, ergibt sich nach unserer Schätzung eine Obergrenze.

Unsere Schätzung für Seiten mit dem Maximum von 768 Patches bei ColQwen2: 2 × 2,2B Parameter × 768 Token je Seite, geteilt durch die BF16-MAMF-Werte von StorageReview vom 14. Oktober 2026; Seiten mit weniger Patches kosten weniger; Rendern der Seiten, die zusätzliche Arbeit des Vision-Encoders und Schreibvorgänge in der Datenbank sind nicht enthalten, gemessene Raten liegen also niedriger.

Das ColPali-Paper hat die Indexierung auf einer NVIDIA L4 gemessen, gemittelt über 100 Seiten, und zeigt in seiner Abbildung 2, dass der Verzicht auf OCR und Layouterkennung sie deutlich beschleunigt; die Zeiten je Seite stehen nur in der Abbildung, nicht im Text, deshalb zitieren wir sie nicht. OpenSearchs eigener Benchmark vom 21. April 2026 auf OpenSearch 3.5.0 mit ColPali an einem entfernten GPU-Endpunkt nennt rund 9 Sekunden je Dokument für die Aufnahme, ein Wert, der die ganze Pipeline und die Dokumentgröße enthält. Messen Sie an einer Stichprobe Ihrer eigenen Dokumente: Eine Seite mit 768 Patches und eine mit 300 unterscheiden sich im Aufwand um mehr als die Hälfte.

ColPali v1.3 mit 1.030 Token und einem Modell von rund 3B Parametern kostet nach derselben Zählung mindestens rund 6 × 10^12 Operationen je Seite; planen Sie also etwa die halbe ColQwen2-Rate. Eine Neuindexierung nach einem Modellwechsel wiederholt den ganzen Lauf; dimensionieren Sie die Karte also für dieses Zeitfenster ebenso wie für den täglichen Zuwachs.

GPU und Speicher bei der Suche

Eine Anfrage läuft durch dasselbe Modell: Das Paper nennt rund 30 ms auf einer L4 zum Kodieren einer Anfrage, gegenüber rund 22 ms für ein Text-Embedding-Modell, bei Batchgröße 1. Die Anfrage wird dann zu rund 25 bis 30 Vektoren, wie die Beispiele der Modellkarten mit den Formen (25, 128) und (28, 128) zeigen. Der Encoder muss für den Suchdienst geladen bleiben, auf einer eigenen kleinen Karte oder einer MIG-Instanz auf einer größeren.

Die Bewertung ist rechnerisch billig, liest aber jede Kandidatenseite vollständig. Das Paper nennt für die Bewertung „≈1 ms per 1000 pages in the corpus“. Bei ColPalis 263,7 KB je Seite liest ein vollständiger Durchlauf über eine Million Seiten 264 GB, was nach unserer Rechnung mit den 300 GB/s der L4 mindestens 0,9 Sekunden dauert und mit den 864 GB/s der L40S 0,3 Sekunden; das passt zur Rate des Papers. Für eine Anfrage pro Sekunde über eine Million Seiten belegt ein vollständiger Durchlauf also den größten Teil einer L4 und ein Drittel einer L40S.

Eine zweistufige Suche vermeidet das. Qdrants Tutorial zur PDF-Suche im großen Maßstab wendet Mean Pooling auf die Ausgabe von ColPali oder ColQwen2 für eine erste Suchstufe an, schaltet HNSW für die ursprünglichen Multi-Vektoren ab (m=0) und nutzt sie nur „to rerank the results retrieved in the first stage“, mit einer Indexierung „faster by an order of magnitude“ und „Retrieval quality comparable to the original model“. Ein Text-Reranker auf dem OCR-Text der besten Seiten, wie in unserem Reranker-Leitfaden, kann als weitere Stufe folgen.

Vektordatenbanken mit Multi-Vector-Unterstützung

Von den vier Datenbanken unseres Vergleichs dokumentieren zwei Late Interaction direkt. Qdrant speichert „a variable amount of same-shaped dense vectors in a single point“, wenn ein Dense-Vektor mit einem Multivector-Komparator angelegt wird; sein Komparator max_sim ist „defined as a sum of maximum similarities between each pair of vectors in the matrices“, und „MaxSim returns a single combined score per point“. Milvus 2.6.4, vorgestellt am 5. Dezember 2025, hat Array-of-Structs-Felder mit dem Metriktyp MAX_SIM eingeführt, mit MAX_SIM_IP im ColPali-Beispiel und einem HNSW-Index auf dem Vektorfeld der Struktur.

Das README von pgvector, Version 0.8.7, beschreibt weder einen Multi-Vector-Typ noch Late Interaction oder MaxSim; die Seitenvektoren müssten als Zeilen gespeichert und von der Anwendung bewertet werden, womit der Index der Datenbank für die zweite Stufe entfällt. OpenSearch hat am 21. April 2026 einen Benchmark dreier multimodaler Ansätze veröffentlicht, mit ColPali bei rund 1.683 ms je Anfrage auf seinem Testcluster, sechs- bis siebenmal langsamer als die beiden anderen Ansätze dort. Unser Engineering-Partner Vixen.UNO baut RAG-Plattformen in unserem Service Private AI/ML; beschreiben Sie Ihre Dokumente und wo sie liegen, und wir schlagen den Aufbau der Suche vor.

ColPali, OCR oder beides

ColPali findet die Seite; es macht aus der Seite keinen Text. Eine RAG-Antwort braucht dann ein Modell, das die gefundenen Seitenbilder liest, also ein VLM im Antwortschritt mit seinen Bild-Token je Seite, oder OCR-Text der besten Seiten für ein Text-LLM. Die Werte des VLM-Leitfadens gelten für diesen Schritt, aber nur für die wenigen Seiten je Antwort, nicht für den ganzen Bestand.

Unsere Empfehlungen aus den Werten oben und aus unseren Leitfäden zu Embeddings, VLMs und Vektordatenbanken.

Behalten Sie den OCR-Weg, wo Antworten genaue Zahlen zitieren müssen oder Nutzer nach Teilenummern und Codes suchen, denn Stichwortsuche braucht Text. Die Stärke von ColPali ist die Seite, deren Bedeutung im Layout steckt: ein Diagramm, ein ausgefülltes Formular, eine Tabelle ohne sauberen Text. Unser Artikel zum Fine-Tuning von Embedding-Modellen für RAG behandelt die Anpassung eines Retrievers an eigene Dokumente, und RAG auf Unternehmensdaten die Berechtigungen, die für Seitenvektoren ebenso gelten wie für Text-Chunks. Seitenbilder von Rechnungen oder Personalakten enthalten personenbezogene Daten; der Index braucht also dieselbe datenschutzrechtliche Bewertung wie die Dokumente, die Einzelheiten bestätigt Ihr Datenschutz­beauftragter.

Konfigurationen nach Archivgröße

Unsere Schätzungen aus den Tabellen oben; GPU-Zeiten sind Untergrenzen bei den Obergrenzen der Seitenrate; Datenbankserver, Replikate und NVMe werden getrennt dimensioniert.

Eine Retrieval-Karte sitzt oft neben den LLM-Karten. In einem Server mit RTX PRO 6000 Server Edition nimmt eine Karte, in MIG-Instanzen zu 24 GB geteilt, den Retriever, einen Reranker und das Embedding-Modell auf, wie unser Reranker-Leitfaden beschreibt; L4 und L40S haben kein MIG. Wir bauen diese Server mit L4, L40S oder RTX-PRO-Karten für die Suche neben dem LLM, dimensioniert nach Seitenzahl und Suchlast.

Was wir liefern

Wir liefern die L4, die L40S und die RTX-PRO-Karten für Retrieval-Modelle, als Karten für Ihre Server oder in KI-Servern auf Bestellung, vor der Lieferung montiert und getestet, mit einem EU-Vertrag und einer Rechnung und mit Herstellergarantie auf jede Komponente. Die Suchplattform selbst, mit Seitenbildsuche, Berechtigungen und einem Antwortmodell, das seine Quelle nennt, ist unser Service Private AI/ML, mit Engineering durch unseren Partner Vixen.UNO.

FAQ