Embedding- und Reranker-Server für RAG: welche GPU, und wie viele für Millionen von Dokumenten

GPU-Anforderungen für Embedding-Modelle und Reranker bei RAG

Die GPU-Anforderungen eines Embedding-Modells und eines Rerankers sind gering im Vergleich zu denen des Sprachmodells in einem RAG-System. Qwen3-Embedding-0.6B braucht in BF16 rund 1,2 GB für seine Gewichte und das 8B-Modell rund 16 GB, deshalb fasst eine Karte mit 24 GB wie die NVIDIA L4 die kleinen Modelle mit reichlich Reserve. Die GPU wird nach dem Durchsatz ausgelegt: Token pro Sekunde, wenn das Korpus eingebettet wird, und Anfragen pro Sekunde mal Passagen je Anfrage, wenn der Reranker Suchergebnisse bewertet.

Nach unserer Rechnung aus NVIDIAs Werten dauert das Embedding von 3 Millionen Chunks mit 512 Token mit einem 1B-Embedding-Modell auf einer L4 rund 17 Stunden und auf einer L40S rund 5,8 Stunden. Bei 40 Passagen je Anfrage und drei parallelen Anfragen bewältigt eine L4 im Reranking rund 1,3 Anfragen pro Sekunde und eine L40S rund 4,5. Ein Korpus mit einigen Millionen Chunks und einigen Anfragen pro Sekunde kann beide Modelle deshalb auf einer kleinen Karte oder einer MIG-Instanz neben dem LLM betreiben. Ein eigener Retrieval-Server lohnt sich bei Dutzenden Millionen Chunks oder bei einer vollständigen Neuindexierung, die innerhalb eines Wartungsfensters abgeschlossen sein muss.

Unser Leitfaden zu RAG auf Unternehmensdaten behandelt Zerlegung in Chunks, Berechtigungen und Evaluierung; dieser Artikel behandelt die Hardware der RAG-Infrastruktur.

Embedding- und Reranker-Modelle: Parameter, Dimensionen, Sprachen

Die folgenden Modelle sind mit Stand Oktober 2026 für mehrsprachige Korpora dokumentiert. NVIDIAs Embedding-Modell nennt 26 evaluierte Sprachen, darunter Deutsch, Französisch, Polnisch, Tschechisch und Ungarisch.

Model Cards von Qwen, BAAI, Google und NVIDIA auf Hugging Face, abgerufen am 10. Oktober 2026; die 568M Gesamtparameter von bge-m3 aus NVIDIAs Support-Matrix für den Embedding-NIM, aktualisiert am 3. Oktober 2026. MRL: Der Vektor lässt sich kürzen (Matryoshka Representation Learning).

In BF16 belegen die Gewichte zwei Byte je Parameter, rund 1,2 GB für ein 0,6B-Modell, 8 GB für ein 4B-Modell und 16 GB für ein 8B-Modell. Eine Serving-Engine reserviert zusätzlich Speicher für ihre Batches: NVIDIAs Support-Matrix nennt 3,6 GB GPU-Speicher für das nicht optimierte Profil von llama-nemotron-embed-1b-v2 und 33 GB für bge-m3, dessen Gewichte nach unserer Rechnung in FP16 rund 1,1 GB belegen.

Eine Million float32-Vektoren mit 1.024 Dimensionen belegen vor jedem Index 4,10 GB, wie unser Vergleich der Vektordatenbanken für RAG zeigt, und 4.096 Dimensionen das Vierfache. Qwen3 Embedding, EmbeddingGemma und NVIDIAs Modell liefern auf Anforderung kürzere Vektoren; testen Sie eine kürzere Länge mit Ihrem Testsatz, bevor Sie den Index auslegen.

Serving-Engines: Text Embeddings Inference, vLLM und NVIDIA NIM

Text Embeddings Inference (TEI) von Hugging Face stellt Embedding-Modelle mit Qwen3-, Gemma3-, XLM-RoBERTa-, BERT- und weiteren Architekturen bereit und als Re-Ranker Modelle zur Sequenzklassifikation auf Basis von CamemBERT und XLM-RoBERTa. Jede GPU-Architektur hat ihr eigenes Image, mit Stand Oktober 2026 in Version 1.9: das Image 89- für Ada-Karten wie die L4 und L40S, hopper- für Hopper und 120- für Blackwell 12.0, als experimentell gekennzeichnet und mit GeForce-Beispielen aufgeführt. NVIDIAs Liste der CUDA-GPUs nennt Compute Capability 12.0 für jede RTX-PRO-Blackwell-Karte, die wir liefern, deshalb läuft TEI auf diesen Karten aus diesem experimentellen Image.

Für die Auslegung zählt --max-batch-tokens mit dem Standardwert 16.384, und die Dokumentation nennt den Parameter „eine entscheidende Stellgröße, um die maximale Nutzung der verfügbaren Hardware zu ermöglichen“, die TEI nicht automatisch setzen kann. --auto-truncate steht standardmäßig auf true; ein Chunk, der länger als die maximale Eingabe des Modells ist, wird also gekürzt statt abgewiesen, was bei EmbeddingGemma mit 2.048 Token ins Gewicht fällt.

vLLM betreibt Embedding- und Scoring-Modelle in seinem Pooling-Runner, mit den Endpunkten /v1/embeddings, /score und /rerank. Die Model Cards von Qwen verlangen für beide Qwen3-Serien vLLM 0.8.5 oder neuer. Der Qwen3-Reranker ist ein Sprachmodell, das jedes Paar aus Anfrage und Passage über die Wahrscheinlichkeit der Token „yes“ und „no“ bewertet; er gehört nicht zu den aufgeführten Re-Ranker-Architekturen von TEI und läuft deshalb auf vLLM.

Die NIM-Container von NVIDIA NeMo Retriever bieten eine OpenAI-kompatible API. Für llama-nemotron-embed-1b-v2 und die Modelle rerank-1b-v2 und 500m-v2 nennen die Support-Matrizen optimierte FP16- und FP8-Profile nach Compute Capability 12.0, 10.0, 9.0 und 8.9, was die L4, die L40S und die RTX-PRO-Blackwell-Karten abdeckt. NVIDIAs NIM-FAQ hält fest: „Die Nutzung von NIM in der Produktion erfordert eine Lizenz für NVIDIA AI Enterprise.“

Veröffentlichter Durchsatz auf L4, L40S und RTX PRO 6000

Die Werte, die wir für Embedding und Reranking auf den Karten gefunden haben, die wir liefern, stammen von NVIDIAs NIM-Performance-Seiten. Die aktuelle Embedding-Seite, aktualisiert am 3. Oktober 2026, verwendet „eine separate synthetische AIPerf-Benchmark-Matrix“ und führt die L4 nicht mehr auf; die Zeilen für L4 und L40S zum 1B-Textmodell, das jene Seite Llama Nemotron Embed 1B nennt, stammen deshalb aus der Dokumentation der NIM-Version 1.14.0, aktualisiert am 30. September 2026. Vergleichbare veröffentlichte Werte für die Qwen3- oder BGE-Modelle auf diesen Karten haben wir nicht gefunden.

Performance-Seiten des NVIDIA NeMo Retriever Embedding NIM für Version 1.14.0 (aktualisiert am 30. September 2026, Zeilen Embed 1B) und latest (aktualisiert am 3. Oktober 2026, übrige Embedding-Zeilen) sowie Performance-Seite des Reranking NIM (aktualisiert am 17. August 2026), abgerufen am 10. Oktober 2026; jeweils eine Anfrage zur Zeit.

Beim Embedding mit 512 Token verarbeitet die L40S 2,9-mal so viele Texte wie die L4 und beim Reranking 3,3-mal so viele Passagen. Die RTX PRO 6000 Server Edition liegt mit gemischter Präzision beim VL-Modell gleichauf mit der L40S. Mit Nemotron 3 Embed 1B in NVFP4 verarbeitet sie 511,4 Texte pro Sekunde, rund das 3,5-Fache der L40S-Zeile für Embed 1B, wobei die beiden Zeilen unterschiedliche Modelle verwenden. Das Embedding einer Suchanfrage ist eine leichte Last, und die L4-Tabelle nennt 13 ms für eine Anfrage mit 20 Token.

Wie lange die Indexierung dauert: Dokumente, Chunks und Token

Die Indexierung ist eine einmalige Spitze, die vollständig wiederholt wird, sobald sich das Embedding-Modell ändert, und sie wird in vier Schritten geschätzt.

1. Lassen Sie Ihren Chunker über eine Stichprobe laufen und ermitteln Sie die durchschnittliche Zahl der Chunks je Dokument.
2. Zählen Sie die durchschnittlichen Token je Chunk mit dem Tokenizer des Embedding-Modells.
3. Teilen Sie die Gesamtzahl der Chunks durch den Durchsatz Ihres Modells auf der infrage kommenden Karte, aus einem veröffentlichten Wert oder einem Test mit Ihren eigenen Chunks.
4. Rechnen Sie das Parsing der Dokumente und OCR hinzu, die separat laufen und oft länger dauern, sowie die Schreibvorgänge in die Vektordatenbank.

Wie in unserem Vergleich der Vektordatenbanken ergeben 300.000 Dokumente mit je zehn Chunks 3 Millionen Chunks. Bei je 512 Token sind das 1,54 Milliarden Token. Nach unserer Schätzung aus dem Durchsatz oben dauert der vollständige Lauf mit Embed 1B in FP8 auf einer L4 rund 17 Stunden und auf einer L40S 5,8 Stunden. Eine RTX PRO 6000 Server Edition braucht mit dem VL-Modell bei gemischter Präzision rund 5,3 Stunden und mit Nemotron 3 Embed 1B in NVFP4 rund 1,6 Stunden.

Ein 8B-Embedding-Modell leistet je Token ein Mehrfaches der Rechenarbeit dieser 1B-Modelle; planen Sie seinen vollständigen Lauf deshalb in Tagen statt in Stunden und testen Sie es vorher. Nach dem ersten Lauf werden nur neue und geänderte Dokumente eingebettet, eine kleine Last für jede dieser Karten.

Den Reranker auslegen: Anfragen pro Sekunde und Passagen

Ein Reranker bewertet jede abgerufene Passage gegen die Anfrage; seine Last ist deshalb Anfragen pro Sekunde mal Passagen je Anfrage, bei der Tokenlänge von Anfrage plus Passage. In NVIDIAs Werten für 40 Passagen mit 512 Token bewältigt der 1B-Reranker auf einer L4 bei drei parallelen Anfragen (Concurrency 3) 52,7 Passagen pro Sekunde, rund 1,3 Anfragen pro Sekunde. Auf einer L40S sind es 181,6, rund 4,5 Anfragen pro Sekunde, und mit dem 500m-Modell auf der L40S 389, rund 9,7.

Unser Artikel zum privaten ChatGPT-Server nach Unternehmensgröße verwendet Beispielwerte, die für 500 Mitarbeiter 1.200 Anfragen in der Spitzenstunde und einen Spitzenfaktor von 2 ergeben. Mit einem Abruf je Anfrage sind das in der Spitze rund 0,67 Anfragen pro Sekunde, die eine L4 abdeckt. Für 2.000 Mitarbeiter ergeben dieselben Werte rund 2,7 Anfragen pro Sekunde, mehr als die L4 bewältigt und im Rahmen der L40S. Ein Agent, der je Antwort mehrmals sucht, vervielfacht die Rate.

Jede Antwort wartet außerdem auf den Reranker, bevor das LLM beginnt: in NVIDIAs Tabellen mit einer Anfrage zur Zeit 768 ms für 40 Passagen auf der L4 und 234 ms auf der L40S. Mit drei parallelen Anfragen, der Einstellung hinter den Anfragen pro Sekunde oben, nennen die Tabellen 2.254 ms und 652 ms. Weniger Passagen je Anfrage verringern Last und Wartezeit.

Wir liefern die L4, die L40S und die RTX-PRO-Karten für Retrieval-Modelle, als Karten für Ihre Server oder in nach Auftrag gebauten KI-Servern. Nennen Sie uns Ihre Dokumentenzahl, die Chunk-Länge und die Spitzenzahl der Anfragen pro Sekunde, und wir legen die Karten danach aus.

Eine eigene Karte oder eine MIG-Instanz auf der LLM-GPU

Die erste von drei Platzierungen gibt den Retrieval-Modellen eine eigene kleine Karte im LLM-Server: die passive Low-Profile-L4 mit 72 W, die RTX PRO 4000 SFF mit 70 W, die RTX PRO 2000 mit 16 GB und 70 W oder die RTX PRO 4500 mit 32 GB. Die zweite ist MIG auf der LLM-Karte. NVIDIAs MIG-Leitfaden nennt bis zu vier Instanzen mit 24 GB auf jeder Edition der RTX PRO 6000 und bis zu sieben auf der H200 NVL, jede mit eigenem Speicher und eigener Fehlerisolierung, wie unser Leitfaden zum GPU-Sharing mit MIG, Time-Slicing und MPS erklärt.

Die dritte ist der Betrieb der Engines nebeneinander auf einer Karte ohne Partitionierung. Jede Engine reserviert dann ihren eigenen Anteil am Speicher, und sie konkurrieren um Rechenleistung; lassen Sie eine vollständige Neuindexierung deshalb nachts oder auf einer separaten Karte laufen. NVIDIA veröffentlicht für diese Modelle keinen Durchsatz für eine MIG-Instanz oder für die RTX PRO 2000, 4000 und 4500; testen Sie Ihr Modell deshalb auf der Konfiguration, die Sie planen.

Beispielkonfigurationen nach Korpusgröße und Anfragelast

Unsere Schätzungen: Chunks mit 512 Token geteilt durch die oben veröffentlichten Texte pro Sekunde; Reranking bei 40 Passagen je Anfrage und drei parallelen Anfragen. Parsing, OCR und Schreibvorgänge in die Datenbank nicht enthalten. Die 32 GB BF16-Gewichte des 8B-Paars wie in unserem Artikel zur Unternehmensgröße.

Wir prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen, und liefern Konfiguration und Angebot innerhalb eines Werktages. Schicken Sie uns Korpusgröße und Anfragelast über das Formular unten; grobe Schätzwerte genügen.

Was wir liefern

Wir liefern die Karten für Retrieval-Modelle, die L4, L40S, RTX PRO 2000, 4000, 4000 SFF und 4500, sowie die RTX PRO 6000 und H200 NVL für MIG neben dem LLM, als professionelle NVIDIA-GPUs oder in nach Auftrag gebauten KI-Servern. Die Server sind im Burn-in getestet, mit Herstellergarantie auf jede Komponente, unter einem EU-Vertrag und auf einer Rechnung, und Lizenzen für NVIDIA AI Enterprise für NIM kommen auf dieselbe Rechnung. Die RAG-Plattform selbst, mit Assistenten, die die Quelle angeben und die Zugriffsrechte jedes Nutzers beachten, ist unsere Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ