Schluss mit Speicherkosten für Embeddings: Der CTO‑Leitfaden zur asymmetrischen Quantisierung

Sie bezahlen dafür, Luft zu speichern. Ein 1.536‑dimensionales float32‑Embedding sind ~6 KB. Bei 50 Millionen Items sind das 300 GB rohe Vektoren – noch bevor Index‑Overhead und Replikate dazukommen. Die meisten Teams legen für Geschwindigkeit außerdem einen HNSW‑Graphen im RAM an, wodurch der Speicherbedarf in die hohen Hunderte von Gigabyte explodiert. Entsprechend steigen die monatlichen Cloud‑Rechnungen. Gleichzeitig zeigen aktuelle Ergebnisse zur asymmetrischen Quantisierung, dass sich dieser Footprint um 90–97 % bei nahezu verlustfreier Retrieval‑Qualität schrumpfen lässt. Übersetzung in Praxis: weniger und günstigere Maschinen, schnellere Cold‑Starts und die Option, auf Commodity‑CPUs oder sogar am Edge zu laufen.

Das ist keine akademische Kuriosität. 2026 ist es produktionsreif – mit ausgereiften Bibliotheken wie FAISS und ScaNN und Unterstützung in gängigen Vector‑Systemen. Wenn Sie ein RAG‑System, Similarity Search, Empfehlungen oder Deduplizierung in großem Maßstab betreiben, gehört asymmetrische Quantisierung (AQ) auf Ihre kurzfristige Roadmap.

Was asymmetrische Quantisierung tatsächlich ist (und warum sie funktioniert)

Quantisierung komprimiert hochdimensionale Float‑Vektoren in kompakte Codes. Bei der asymmetrischen Quantisierung bleibt die Query im Float‑Format, während die Vektoren der Datenbank als komprimierte Codes gespeichert werden; die Distanzen werden anschließend per Asymmetric Distance Computation (ADC) berechnet. Weil die Query nicht quantisiert wird, vermeiden Sie den größten Genauigkeitsabfall und erhalten dennoch nahezu den gesamten Speicher‑ und Bandbreitengewinn.

Die Arbeitspferde sind:

• Product Quantization (PQ): Zerlege einen D‑dimensionalen Vektor in m Untervektoren; lerne pro Teilraum ein kleines Codebook (z. B. 256 Zentroiden = 8 Bit). Ein Vektor wird zu m Bytes an Codes. Typische Konfigurationen: D=1.536, m=96, 8 Bit → 96 Bytes pro Vektor.
• Optimized PQ (OPQ): Lerne eine Rotation des Raums, um das Signal gleichmäßiger über die Teilräume zu verteilen und bei gleicher Codegröße den Recall zu verbessern.
• IVF‑PQ: Ein zweistufiger Index: Ein grober Quantizer (IVF) verengt die Suche auf wenige Cluster; innerhalb dieser komprimiert PQ die Residuen. Das liefert CPU‑freundliche Latenzen bei sehr großem Scale.

Aktuelle öffentliche Ergebnisse zeigen bis zu ~97 % weniger Speicher bei minimalem Recall‑Verlust auf Standard‑Retrieval‑Tasks. In der Praxis sehen wir regelmäßig 90–95 % Reduktion bei 0,95–0,99 Recall@10 gegenüber dem Float‑Baseline‑Index, wenn Sie:

• OPQ mit ausreichend Daten trainieren (≥1–5 Mio. repräsentative Samples).
• Anzahl der IVF‑Listen und Probes an Ihr Latenzbudget anpassen.
• Reranking auf den Top‑K‑Kandidaten einsetzen (z. B. Dot‑Product oder ein Cross‑Encoder).

Warum das für Ihre TCO zählt

Nehmen wir ein langweiliges, gängiges Setup, um die Rechnung zu illustrieren:

• Embedding: 1.536‑d float32 (≈6 KB/Vektor).
• Korpus: 50 Mio. Items → 300 GB rohe Vektoren.
• HNSW‑Index‑Overhead: häufig das 1–2‑Fache der Vektorgröße, abhängig von M/ef. Angenommen 1,5× → 450 GB im RAM.
• HA/Replikationsfaktor 2–3× über Knoten hinweg → 900–1.350 GB effektiver Footprint.

Das Ergebnis: Sie mieten ganzjährig mehrere 256–512‑GB‑RAM‑Instanzen (CPU oder GPU), um die Latenz unter 100 ms unter Last zu halten. Je nach Region und Generation sind das leicht $6k–$12k/Monat allein für Compute – oft mehr als die Vector‑DB‑Speicherkosten.

Drehen wir das Design um:

• PQ mit m=96, 8 Bit → ~96 Bytes/Vektor (plus wenig IVF‑Metadaten). Das sind ~4,8 GB für 50 Mio. Vektoren (Roh‑Codes), typischerweise 10–20× kleiner als die Float‑Baseline, wenn man Index‑Overheads einrechnet.
• IVF‑PQ auf der CPU einsetzen. Halten Sie die Codes auf NVMe; cachen Sie heiße Listen und LUTs im Speicher. Mit sinnvoller Tuning‑Konfiguration sind p95‑Latenzen unter 20–40 ms auf modernen CPUs bei 95 % Recall@10 im Bereich 50–200 Mio. realistisch.
• Der Compute‑Footprint sinkt auf ein bis zwei 64–128‑GB‑Instanzen pro Replikat, oft $1,5k–$3k/Monat pro Knoten. Cold‑Starts sind schneller; Rebuilds benötigen keine petabyte‑klassigen flüchtigen Volumes.

Nicht jeder Workload folgt exakt dieser Kurve, aber die Richtung ist konsistent: PQ verschiebt Sie von RAM‑gebundenen zu Cache‑/Storage‑balancierten Designs – günstiger, elastischer und leichter über Regionen (oder on‑prem) zu betreiben, ohne GPU‑Knappheit.

Wann Sie asymmetrische Quantisierung einsetzen sollten (und wann nicht)

Adopt AQ, wenn Folgendes weitgehend zutrifft:

• Korpus ≥ 10 Mio. Items oder Multi‑Tenant‑Suche mit vielen aktiven Mandanten.
• Latenz‑SLOs ≥ 20 ms p95 in der Vektorstufe (mehr geht mit Caching und engeren Probes).
• Stabiles Embedding‑Modell für mindestens 3–6 Monate. Häufiger Modellwechsel erhöht die Codebook‑Wartungskosten.
• Dot‑Product oder L2 als Distanz. Bei Spezialmetriken Bibliotheks‑Support prüfen.
• Reranking‑Schritt verfügbar, um Long‑Tail‑Qualität zurückzugewinnen (z. B. Top‑200 Kandidaten → Cross‑Encoder@K=50).

Und Sie sollten zweimal nachdenken, wenn:

• Sie kleine (≤1 Mio.) Korpora betreiben, die bereits mit HNSW zu trivialen Kosten in den RAM passen.
• Ihr SLO Ultralow‑Latency (z. B. 5 ms p95) verlangt und Sie sich GPU/handgetunte RAM‑Indizes leisten können.
• Ihre Embeddings sich wöchentlich ändern und Sie sich keine Dual‑Index‑Rebuilds leisten können.

Die Architektur: IVF‑PQ mit ADC plus Reranking

Für die meisten CTOs sieht ein sicherer Default 2026 so aus:

1. Grobes Partitionieren (IVF): k‑Means mit k im Bereich 16k–262k je nach Korpusgröße trainieren. Faustregel: Start bei k ≈ sqrt(N) und basierend auf Probes/Latenz nachschärfen.
2. Residual‑Kodierung mit OPQ+PQ: Eine OPQ‑Rotation lernen; PQ auf den Residuen trainieren, m so wählen, dass m Bytes/Vektor Ihr Speicherziel treffen. Üblich sind m=64–128 mit 8‑Bit‑Codes.
3. Asymmetric Distance Computation: Die Query als Float belassen; für jede geprobte Liste eine Lookup‑Table (LUT) der Distanzen zwischen Query und jedem Sub‑Quantizer‑Codebook aufbauen. ADC‑Distanzen reduzieren sich auf LUT‑Additionen, was auf CPUs cache‑freundlich ist.
4. Kandidatenset + Rerank: 500–2.000 Kandidaten aus dem ADC zurückgeben; mit den originalen Floats reranken, wenn Sie für Head‑Items einen kleinen Float‑Cache halten, oder einen Cross‑Encoder für Precision@K nutzen.

Dieses Muster ist in FAISS (IndexIVFPQ, IndexIVF{HNSW,PQ}) und im Partitioning + Asymmetric Hashing‑Flow von ScaNN implementiert. Viele Vector‑DBs setzen es unter der Haube ein. Sie müssen Ihren Stack nicht neu schreiben.

Ein konkreter 60–90‑Tage‑Rollout‑Plan

Tage 0–15: Baseline und Zielbild

• Definition der Messlatte: Einen repräsentativen Benchmark festzurren: 10–20 echte Queries pro Head‑Thema, 10k–100k annotierte Paare, Auswertung als Recall@10 und nDCG@10.
• Aktuelle Kosten erfassen: RAM‑Footprint von HNSW (oder aktuellem ANN), Instanz‑SKUs, QPS, p95/p99‑Latenz sowie monatliche $/QPS.
• Risikobudget festlegen: z. B. ≥0,97 Recall@10 der Baseline und ≤10 ms zusätzliche p95 in der Vektorstufe. Schriftlich fixieren.

Tage 15–45: Trainieren, bauen, tunen

• Trainingsdaten samplen: 1–5 Mio. Vektoren über Mandanten/Regionen hinweg; ein Hold‑out‑Set zurückhalten.
• OPQ und IVF trainieren: Start mit OPQ m=96 (8‑Bit). Für IVF bei k ≈ sqrt(N) starten; nprobe 10–200 testen.
• IVFPQ bauen: Codes auf NVMe speichern; per‑Liste‑Statistiken vorkomputieren; mmap aktivieren, wo verfügbar.
• Trade‑offs messen: m ∈ {64, 96, 128}, Code‑Bits ∈ {6, 8}, nprobe ∈ {8, 16, 32, 64, 128} sweepen. Recall vs. p95 vs. CPU% plotten.
• Rerank‑Strategie: Zweistufig testen: IVFPQ@1k → Cross‑Encoder@50 (oder Float‑Dot‑Product, wenn Sie Floats für Head‑Items cachen können). Lift auf Long‑Tail‑Queries validieren.

Tage 45–75: Shadow und Safety

• Dual‑Run: Nutzer über den Baseline‑Pfad bedienen; parallel den PQ‑Pfad für zufällige 5–10 % des Traffics shadown. Interleavte Ergebnisse loggen, um Online‑Recall und Click‑Through‑Deltas zu schätzen.
• Drift‑Monitore: Auf Verschiebungen der Kosinus‑Ähnlichkeitsverteilung zwischen Query und Top‑K alarmieren; das ist ein Frühindikator für alternde Codebooks.
• Hot‑Rebuild‑Plan: Codebooks wöchentlich seitlich bauen; Traffic per Feature‑Flag umschalten. Die letzten zwei Codebooks für ein Rollback live halten.

Tage 75–90: Cutover und Einsparungen realisieren

• Schrittweiser Cutover: 10 % → 50 % → 100 % der Mandanten. Den Baseline‑ANN für ein definiertes Zeitfenster als Fallback behalten.
• Instanzen right‑sizen: Von 512 GB RAM auf 64–128 GB gehen; horizontal für QPS skalieren, nicht wegen Speicherdruck.
• Einsparungen realisieren: $/QPS‑Reduktion tracken. Nach unserer Erfahrung reduziert gut getuntes PQ Compute für Vector Search um 2–5× und Storage um 10–30× – ohne messbaren Nutzerschaden.

Häufige Fehlermuster (und wie man sie vermeidet)

• Training auf der falschen Verteilung: Ihre Codebooks lernen, was Sie einspeisen. Wenn Sie bestimmte Sprachen, Mandanten oder Modalitäten ausschließen, erwarten Sie Recall‑Abstürze in Produktion. Fix: stratifiziertes Sampling und periodisches Retraining.
• Unterdimensioniertes IVF: Zu wenige Listen oder zu wenige Probes würgen den Recall ab. Fix: k oder nprobe erhöhen; LUTs und heiße Listen cachen; NUMA‑Pinning prüfen.
• Rerank bei hoher Kompression weggelassen: Unter ~64–96 Bytes/Vektor steigt der Approximationsfehler. Fix: immer ein kleines Kandidatenset reranken.
• Model‑Churn ohne Dual‑Indexing: Wechselnde Embedding‑Modelle invalidieren Codebooks. Fix: zwei vollständige Indizes pflegen; im Hintergrund neu aufbauen; per Flags umschalten.
• MIPS‑ vs. L2‑Mismatch: Wenn Sie Dot‑Product‑Similarity nutzen, sicherstellen, dass Index und Bibliothek für MIPS (Maximum Inner Product Search) optimiert sind. Manche Stacks konvertieren MIPS→L2 mit Tricks (z. B. Normaugmentation). Verifizieren.

Tool‑Entscheidungen, die nicht schnell veralten

• FAISS: Bewährt, GPU und CPU, tiefgreifender PQ/IVF‑Support, HNSW‑Hybride. Für maximale Kontrolle und Portabilität.
• ScaNN: Stark bei CPU‑Performance mit Partitioning + Asymmetric Hashing; gute Defaults.
• Vector DBs: Milvus, Qdrant, Weaviate und kommerzielle Services exponieren IVF‑PQ/HNSW‑PQ. Achtung vor versteckten Konfig‑Limits (z. B. maximale Codebook‑Größen) und intransparentem Recall.
• Reranker: Für mehrsprachige oder fachdomänenlastige Queries holt ein kleiner Cross‑Encoder (z. B. MiniLM‑Klasse) bei K=50–200 oft die letzten 1–2 Punkte Präzision für wenige Millisekunden zurück.

Ein einfaches Kostenmodell, das Finance versteht

Den Business Case klar rahmen:

• Baseline: 3× r5b.16xlarge (512 GB) für HNSW + 2× m6i.8xlarge für API + Storage‑Replikation → $8k–$14k/Monat all‑in, plus Gebühren für Managed Vector DBs.
• Mit PQ: 2× m7i.4xlarge (64 GB) für IVFPQ + 2× m6i.8xlarge für API → $3k–$6k/Monat, Storage 10–30× kleiner. Gleiches Traffic‑Volumen, gleiche User‑Metriken.
• Amortisation: 30–60 Tage inkl. einmaligem Engineering‑Aufwand, bei einer 2–5× Compute‑Reduktion und moderatem Infra‑Umbau.

Selbst wenn Ihre genauen SKUs und Preise abweichen, versteht Finance den Schritt von speichergebundenen Replikas zu speicher‑balancierten Nodes mit den gleichen oder besseren SLOs.

Und die GPUs?

GPUs glänzen, wenn Sie Ultralow‑Latency bei sehr hohem QPS brauchen oder ohnehin on‑GPU für vorgelagerte Tasks sind. Aber mit IVFPQ+ADC erreichen moderne CPUs p95 unter 40 ms für zig bis hunderte Millionen Vektoren. Wenn Sie GPUs behalten, können Sie dennoch quantisieren, um größere Korpora in den Gerätespeicher zu bekommen oder die PCIe‑Bandbreite zu reduzieren.

Edge und On‑Device: die Optionalitäts‑Dividende

Kompression ist eine Architekturentscheidung, nicht nur ein Kosten‑Hack. Bei 96 Bytes/Vektor ist ein 5‑Mio.‑Index ≈480 MB an Codes. Plötzlich:

• Multi‑Region‑Replikation wird machbar – ohne Cross‑Region‑Datentransfer‑Drama.
• Private On‑Prem‑Deployments in regulierten Accounts passen auf 1–2 Commodity‑Server.
• On‑Device oder In‑Browser‑Search für kleine Korpora (≤500k) wird mit WASM oder mobilen NN‑Bibliotheken realistisch – und eröffnet neue, datenschutzfreundliche Produktoberflächen.

Brazilian Nearshore‑Angle: Wer macht die langweilige Tuning‑Arbeit wirklich?

Nichts davon ist Raketenwissenschaft, aber es ist Systems‑Engineering: samplen, trainieren, Indizes bauen, Observability verdrahten und iterieren, bis die Recall/Latenz‑Frontier passt. Es ist auch genau die Art von Engineering, die so lange nachrangig behandelt wird, bis die Rechnung kommt. Nearshore‑Teams mit FAISS/ScaNN‑Erfahrung liefern Ihnen in 6–10 Wochen einen funktionierenden PQ‑Rollout und bleiben danach quartalsweise dran, um Codebooks neu zu trainieren und Cluster mitwachsend right‑zusizen. Sie realisieren die Einsparungen, ohne ein permanentes „Vector‑Infra“‑Team aufzubauen.

Compliance und Datenschutz: Kleiner kann sicherer sein

Komprimierte Codes leaken weniger Rohsignal als Floats. Das ist keine Compliance‑Wunderwaffe, reduziert aber die Angriffsfläche für Vektor‑Exfiltration. Sie sollten trotzdem:

• Verschlüsselung at rest und in transit; Schlüssel pro Mandant managen.
• PII vor dem Embedding entfernen, wo möglich.
• Lösch‑Pipelines bauen, die sowohl Float‑Caches als auch PQ‑Stores durchlaufen.

Ein Wort zu Hype vs. Realität

Hacker News ist begeistert von „97 % Speicherreduktion bei nahezu verlustfreiem Retrieval“. Das ist erreichbar – aber nur, wenn Sie es wie ein Produktions‑Feature behandeln, nicht wie einen Benchmark‑Partytrick. Der Unterschied liegt in Ihrem Sampling, Drift‑Monitoring und einem Reranker, der die letzte Meile abdeckt. Tun Sie das, und Sie fragen sich, warum Sie jemals 600 GB Floats heiß im RAM gehalten haben.

Wichtigste Erkenntnisse

• Asymmetrische Quantisierung (IVF‑PQ + ADC) kann den Vektor‑Storage um 90–97 % verkleinern – bei 0,95–0,99 Recall@10 der Float‑Baseline.
• Erwarten Sie 2–5× Compute‑Einsparungen und den Wechsel von RAM‑gebundenen Clustern zu CPU‑freundlichen, NVMe‑gestützten Nodes.
• Einführen mit einem 60–90‑Tage‑Plan: Baseline, OPQ/PQ trainieren, Shadow‑Dual‑Run und Cutover mit Reranking.
• Auf Distribution Drift, unterdimensioniertes IVF und Model‑Churn achten; mit stratifiziertem Sampling, Probe‑Tuning und Dual‑Index‑Rebuilds beheben.
• Kompression eröffnet Edge/On‑Prem‑Optionen und kann das Datenabfluss‑Risiko gegenüber rohen Floats reduzieren.