RAG-Retrieval-Mathematik: Embedding-Speicher, Vektorindex-Größe und das Latenzbudget, das niemand rechnet

Jede Entscheidung „wir bauen einfach RAG dazu" ist eine Reihe von Rechenaufgaben im Trenchcoat: wie viel VRAM das Embedding-Modell braucht, wie viele Bytes der Vektorindex frisst, wie viele Distanzberechnungen eine Query kostet und ob die ganze Pipeline in Ihr Latenzbudget passt. Dieser Guide rechnet das mit Zahlen aus Primärquellen durch — Hugging-Face-Model-Karten, NVIDIA-Datenblätter, Qdrants offizielle Dokumentation und aktuelle API-Preise — damit Sie die Infrastruktur dimensionieren, bevor Sie der Demo glauben.

Das Embedding-Modell ist der günstige Teil — bis es das nicht ist

Drei offene Embedding-Modelle über klein, mittel und groß verteilt; die Parameterzahlen direkt aus den Hugging-Face-Repositories gelesen (fp16 = 2 Bytes pro Parameter, dieselbe Konvention wie in unserem Quantisierungs-Guide):

Die Modelldatei von bge-m3 ist 2.271.145.830 Bytes groß⁴. Durch vier geteilt ergibt das ungefähr 567,8 Mio. fp32-Werte; die serialisierte Dateigröße enthält aber Metadaten und ist keine exakte Parameterzahl. Das e5-mistral-Checkpoint liefert fp16-Safetensors mit insgesamt etwa 14,2 GB³.

Die GPU-Klassen-Folgen bei fp16:

• bge-base (0,22 GB) läuft überall — Laptop-GPU, CPU, Jetson. Speicher ist nicht die Grenze; Durchsatz ist es.
• bge-m3 (1,14 GB) passt auf jede Datacenter-GPU mit reichlich Reserve; selbst 8-GB-Karten tragen das Modell plus große Batches.
• e5-mistral-7b (14,22 GB) benötigt zusätzlich zu Gewichten Speicher für Aktivierungen und Batches. Eine RTX 4090 oder A30 mit 24 GB, eine L40S mit 48 GB oder eine A100 mit 40/80 GB bietet mehr Spielraum als eine 16-GB-Karte; prüfen Sie Sequenzlänge und Batch.

Die teure Klasse entscheidet nicht über Qualität pro Euro im Betrieb — sondern über die Vektorbreite, die sie erzeugt. Ein 4096-Dim-Modell vervierfacht jede nachgelagerte Speicherrechnung gegenüber 1024-Dim-bge-m3, bei Benchmark-Scores, die sich um einstellige Punkte verbessern⁵.

Bytes pro Vektor: wo die echte Speicherrechnung lebt

Modellspezifischen Kontext zu Pooling und Vektordimensionen bietet der Architekturleitfaden zu EmbeddingGemma 2. Nemotron 3.5 Embed zeigt, wie ein eingefrorener Text-Tower einen bestehenden Textindex bewahren kann, während ein trainierter visueller Pfad in denselben Raum gelangt; beide Single-Vector-Designs lassen sich mit dem pplx-embed-v2-Leitfaden zu asymmetrischem Retrieval und MaxSim vergleichen. Der OlmoEarth-v1.3-Guide zeigt einen anderen Produktionsfall: ein trainiertes 128-/64-dimensionales Präfix, dessen Zarr-Chunk-Geometrie entscheidet, ob Kürzung auch Netzwerk-I/O spart.

Rohe Embedding-Speicherung ist peinlich simple Arithmetik: Bytes pro Vektor = Dimensionalität × Bytes pro Komponente. Stand 2026 speichert Qdrant Vektoren intern standardmäßig als 32-Bit-Floats⁶.

Korpus-Dimensionierung — angenommen 512-Token-Chunks, also entsprechen 500 Mio. Tokens Quelltext ≈ 1 Mio. Chunks, 50 Mrd. Tokens ≈ 98 Mio. Chunks. Die Indexspeicher-Tabelle für bge-Klasse, 1024-Dim:

Bei 4096 Dimensionen erreicht dieselbe Tabelle 1,64 TB rohe Vektordaten für 100 Mio. Chunks, also das Vierfache. Dazu kommt der HNSW-Graph: Bei 4-Byte-Nachbar-IDs und bis zu 2 × m Links auf Ebene 0 ergeben sich für M=16 grob 128 B pro Vektor allein für diese Links, also 12,8 GB bei 100 Mio. Vektoren. Weitere Ebenen, Allocator-Overhead und Payload benötigen zusätzlichen Speicher; das ist ein Größenbeispiel, kein exakter Qdrant-Footprint⁷.

Für reine Vektordaten komprimiert Skalarquantisierung von float32 auf uint8 um 4×. Binärkodierung kann 32× erreichen; Produktquantisierung hängt von ihrer Konfiguration ab⁶. Die Faktoren enthalten weder Index-Overhead noch originale Vektoren, die für Rescoring behalten werden. Weaviate dokumentiert PQ zur Speicherreduktion⁸, und Milvus bietet mehrere quantisierte Indextypen⁹. Effekte auf Recall und Latenz hängen von Datensatz, Queries, Sucheinstellungen und Rescoring ab; messen Sie mit Ihrem Korpus.

Latenz-Zerlegung: Flat Brute Force vs. HNSW

Bei einer Flat-Suche wird der Query-Vektor mit jedem Vektor verglichen: Die Zahl der Vergleiche ist N. HNSW durchsucht approximativ nur einen Teil des Graphen. ef × log₂(N) ist aber keine belastbare Formel für Distanzberechnungen oder Latenz. Aufwand und Recall hängen von Graph, Dimensionen, Suchparametern und Daten ab; konstruierte Fälle benötigen sogar linearen Aufwand¹⁰.

Bei 1 Mio. Vektoren mit 1024 float32-Dimensionen braucht eine exakte Suche grob 1 Mio. × 2 × 1024 ≈ 2 GFLOP und liest etwa 4,1 GB Vektordaten. Selbst bei angenommenen 100 GB/s dauerhaft erreichter Speicherbandbreite dauert allein das Lesen mindestens ~41 ms; CPU-SIMD beseitigt den Speichertransport nicht. Qdrants full_scan_threshold_kb wählt Brute Force für kleine Kandidatenmengen⁷. Ob exakte Suche bei 1 oder 10 Mio. Vektoren sinnvoll ist, hängt von Hardware, Filtern, Parallelisierung, QPS und Latenzzielen ab.

Absolute QPS-Zahlen zitieren wir nur herstellerseitig und als solche gekennzeichnet: Qdrant veröffentlicht ein eigenes HNSW-Benchmark-Repository genau für diesen Zweck¹¹, und ihr Large-Scale-Tutorial — 400 Mio. CLIP-Vektoren, Binärquantisierung, M=6 — liefert eine konkrete, reproduzierbare Ressourcenaufstellung (23,8 GB quantisierte Vektoren + 17,9 GB HNSW-Graph im RAM für alle 400 Mio.)¹². Jede „einstellige Millisekunden pro Query"-Zahl aus einem ungebremsten Benchmark verdient Skepsis, solange Hardware, ef und Recall nicht mit angegeben sind.

Embedding ist Prefill, nicht Decode — und das ändert die Rechnung

Die KV-Cache-Intuition aus unserem KV-Cache-Guide führt hier in die Irre, also präzise formuliert: Ein Embedding-Forward-Pass über einen 512-Token-Chunk ist reiner Prefill. Ein Durchgang, alle Positionen gleichzeitig, keine Decode-Schritte, kein gespeicherter KV-Cache, keine speicherbandbreiten-gebundene Token-für-Token-Schleife. Embedding-Durchsatz ist in einer Weise compute-gebunden, wie es Generierung nie ist.

Die FLOPs pro Chunk folgen der Standard-Forward-Pass-Schätzung 2 × Parameter × Tokens:

• bge-m3 (568 Mio. Parameter), 512-Token-Chunk: 2 × 567.755.777 × 512 ≈ 581 GFLOP
• e5-mistral-7b (7,11 Mrd. Parameter), 512-Token-Chunk: 2 × 7.110.660.096 × 512 ≈ 7.281 GFLOP

Obergrenzen bei Spezifikations-TFLOPS aus NVIDIA-Datenblättern — dichtes fp16, mit ehrlich angenommenen 50 % der Spitzenleistung (Model-Kernel-MFU auf gut gebatchten Encoder-Inputs):

Die L40S-Zahl verdient Skepsis: 362 TFLOPS ist der dense-fp16-Wert; 1.466 TFLOPS bezieht sich auf Sparse-FP8¹³. Bei angenommener 50-%-Auslastung und der Näherung für lineare Schichten ergibt sich für einen Korpus mit 1 Mio. Chunks (500 Mio. Tokens) eine Rechenuntergrenze von ~52 Minuten (500 × 10⁶ / 159.400 ≈ 52 Minuten). Attention, Tokenisierung, I/O und ineffizientes Batching verlängern die reale Laufzeit.

Reranker: die zweite Stufe, die still Ihr Budget besitzt

Hybrides Sparse-plus-Dense-Retrieval ist 2026 der Standard, weil es funktioniert — dense Vektoren verpassen exakte Keywords, BM25-artiges Sparse verpassen Paraphrasen, bge-m3 liefert beides aus einem Forward-Pass². Aber der Qualitätshebel, den Leute tatsächlich spüren, ist der Cross-Encoder-Reranker — und er ist die am schlechtesten budgetierte Komponente in RAG.

Ein Cross-Encoder bewertet jedes Paar einzeln: voller Forward-Pass über konkatenierte Query plus Kandidat. Pro Kandidatenpaar mit einem Reranker der 280-Mio.-Klasse (bge-reranker-base, 278.044.931 Parameter¹⁵) über 32 Query-Tokens + 512 Dokument-Tokens:

2 × 278 Mio. × 544 ≈ 302 GFLOP pro Paar

Die Top-100-Kandidaten zu bewerten kostet unter dieser Näherung für lineare Schichten 100 × 302 GFLOP ≈ 30,3 TFLOP. Auf einer L40S bei angenommenen 50 % von 362 TFLOPS ist das eine untere Rechengrenze von ~167 ms, vor Overhead und Attention. Tatsächliche GPU- und CPU-Zeiten müssen gemessen werden; wählen Sie die Kandidatenzahl nach den gemessenen Latenz- und Qualitätszielen.

Das zweistufige Latenzbudget pro Query bei realistischer Skalierung:

• Query-Embedding: Batching, Tokenizer- und Modelllatenz messen
• Vektorsuche: Index, Filterselektivität, Suchbreite und Recall zusammen messen
• Reranking von 100 Kandidaten @ 278 Mio. Parameter: ~167 ms Rechenuntergrenze unter der genannten L40S-Auslastungsannahme
• Generierung: Prefill und Decode bei der geplanten Kontextlänge getrennt messen

In diesem Rechenbeispiel kann Reranking die Retrieval-Latenz dominieren. Ein anderer Index, eine andere Kandidatenzahl oder ein anderes Modell können die Reihenfolge verändern. Messen Sie jede Stufe der realen Pipeline.

API vs. Self-Hosting: Der Break-even liegt nicht, wo Sie denken

Aktuelle Preise pro 1 Mio. Input-Tokens: OpenAI text-embedding-3-small bei 0,02 USD, text-embedding-3-large bei 0,13 USD¹⁶. Die Batch API halbiert beide¹⁶. Embeddings berechnen nur Input — keine Output-Tokens, weil es keine gibt.

Für eine beispielhaft gemietete L40S zu angenommenen 1,20 USD/Stunde entspricht die zuvor idealisiert berechnete bge-m3-Rate von ~159.400 Tok/s (50 % der genannten Rechenleistung) 574 Mio. Tokens pro Stunde, noch vor Tokenisierung, I/O, Padding und Attention-Overhead. Daraus ergäben sich reine Rechenkosten pro 1 Mio. Tokens von:

1,20 USD / 574 ≈ 0,0021 USD

Dieser hypothetische Rechenpreis liegt unter beiden API-Preisen, ist aber weder ein Angebot noch ein gemessener Preis. Stundentakt, Startzeiten, CPU-/Host-Kosten, Auslastung und Modellqualität können das Ergebnis umkehren.

Die Tabelle verwendet diese Annahmen mit anteiliger Stundenabrechnung. Bei einer Mindeststunde wären die GPU-Kosten für 10 Mio. Tokens dagegen 1,20 USD:

Die Tabelle ohne Wunschdenken gelesen:

• Eine gemietete GPU kann günstiger sein, wenn Arbeit auf bezahlte GPU-Zeit gebündelt werden kann, der gemessene Modelldurchsatz die angenommene Rate annähert und zusätzliche Hostingkosten gering sind. Anforderungen an die Datengrenze können die Wahl unabhängig vom Preis bestimmen.
• Die API kann bei gelegentlicher Arbeit einfacher und günstiger sein. Bei den derzeit gelisteten Preisen kosten 500 Mio. Tokens mit text-embedding-3-small regulär 10 USD oder über Batch 5 USD. Vergleichen Sie das mit einem echten GPU-Angebot und dessen Mindestabrechnung.
• Bei 10 Mio. Tokens/Monat beträgt die idealisierte Rechenzeit in der Tabelle etwa eine Minute; eine dauerhaft gemietete GPU wird hingegen für den ganzen Monat berechnet. Der Abrechnungstakt ist entscheidend.

Und der Qualitätsvorbehalt: Qualitätsparität ist modellabhängig. Wer bge-base self-hostet, weil es gratis ist, und als Baseline 3-large vergleicht, frisst jeden Infra-Sparkauf durch die Retrieval-Qualitätseinbuße. Erst Modelle angleichen, dann Preise vergleichen.

Fazit, mit ausbuchstabierten Fallstricken

Es gibt keine allgemeingültige Token-Schwelle. Die Tabelle selbst ergibt bei kurzen GPU-Mieten hypothetisch schon bei 10 Mio. Tokens geringere GPU-Kosten als API-Kosten; eine dauerhaft gemietete GPU kann hingegen deutlich teurer sein. Vergleichen Sie tatsächliche Preise, Abrechnungstakt, gemessenen Durchsatz und Retrieval-Qualität für denselben Datensatz. Anforderungen an die Datengrenze können eine API unabhängig vom Preis ausschließen.

Die ehrlichen Fallstricken:

• „RAG behebt Halluzinationen" ist ein Kategorienfehler. Retrieval erdet die Generierung in dem, was indexiert ist; wird der korrekte Chunk nicht gefunden, halluziniert das Modell trotzdem — nur selbstbewusster. RAG verschiebt das Fehlerbild von „das Modell weiß es nicht" zu „das Retrieval hat es verpasst" — gebunden durch Recall auf Ihrem Korpus, nicht durch MTEB-Benchmark-Scores.
• Recall-Verlust wird doppelt bezahlt: Approximatives HNSW (ef zu niedrig) senkt Recall, Quantisierung senkt ihn weiter, und jeder Verlust summiert sich lautlos, weil die Fehleroberfläche exakt so aussieht wie „das Modell hat es erfunden".
• Chunking und Modellwahl wirken zusammen. Testen Sie Chunk-Größe, Überlappung sowie lexikalisches und dichtes Retrieval mit einem beschrifteten Query-Satz.
• Die 4096-Dim-Vektoren des 7B-Embedders kosten für immer 4× Speicher und 4× Flat-Suchzeit. Qualität wird gemietet; die Vektorbreite wird gekauft.

Die Mathematik hier ist der einfache Teil. Jede Zahl oben ist ein Boden, keine Prognose — echte Pipelines verlieren an Netzwerk-Hops, Serialisierung und Leerlauf. Rechnen Sie die Böden zuerst, und messen Sie dann die Realität gegen sie.

Fußnoten