S4 Embed
Vector-Search-FinOps-Gateway
Eine FinOps-Schicht, die Ihre bestehende Vector Database günstiger macht und Recall im Zielbereich hält. Sie quantisiert Embeddings (binary + int8) und führt eine zweistufige Suche (1-bit Hamming-Coarse-Stage + exaktes Rescore) vor OpenSearch, pgvector, Qdrant oder Milvus aus, wodurch der ANN-Graph im RAM um bis zu 32× schrumpft. Läuft als Amazon Linux 2023 AMI in Ihrer eigenen VPC, abgerechnet pro Nutzungseinheit (eingebettete Texte, indexierte Dokumente, bediente Searches).
S4 Embed hilft Ihnen, eine kostengünstige Vector-Search-Konfiguration zu finden und zu betreiben, die Ihr Recall-Ziel erfüllt. In einem 30k-Vector-Benchmark erreichte binary Hamming + float Rescore je nach Store und Over-Fetch recall@10 von 0.976–1.000 — Sie wählen den Operating Point. Die FinOps-Tools sind das Produkt: s4embed prove (Recall/Cost/Latency-Frontier schätzen), compare (Live-Recall über Stores messen), tune (eine deploybare Konfiguration ausgeben, die Recall + Latenz + RAM-Budget erfüllt), Gateway-Shadow-Modus (Dual-Write und Shadow-Compare vor dem Cutover) und drift (Embedding-Drift überwachen). Store-agnostisch über OpenSearch, pgvector, Qdrant und Milvus.
Das Problem
Die Vektorsuche hält ihren ANN-Graph im RAM. Mit wachsendem Korpus steigt also der Speicherbedarf — und damit die Kosten — Ihrer Vektordatenbank, was die Ausgaben schwer vorhersagbar macht. Sie möchten den Recall nicht opfern, um Geld zu sparen, wodurch Sie zwischen Kosten und Qualität gefangen sind. Und es gibt selten eine gute Möglichkeit herauszufinden, welcher Store und welche Konfiguration unter OpenSearch, pgvector, Qdrant oder Milvus am kosteneffizientesten ist, bevor Sie sich in der Produktion darauf festlegen.
Funktionsweise
- 1
Embeddings quantisieren
S4 Embed quantisiert Ihre Embeddings in Binärwerte (ein bis zu 32x kleinerer ANN-Graph im RAM) und ein int8-Residuum (ca. 4x kleinere Vektoren auf der Festplatte), was den RAM-Bedarf Ihrer Vektordatenbank verringert.
- 2
Zweistufige Suche zum Erhalt des Recalls
Eine grobe Phase mit 1-Bit-Hamming erstellt eine kurze Shortlist, die anschließend durch ein exaktes Rescoring neu sortiert wird. Durch die Anpassung des Arbeitspunkts für Over-Fetch und Rescoring halten Sie Ihr Recall-Ziel ein, während der RAM-Bedarf gering bleibt.
- 3
Vor dem Cutover mit Daten validieren
s4embed prove, compare und tune messen die Grenze von Recall, Kosten und Latenz auf Ihren eigenen Vektoren und geben eine bereitstellbare Konfiguration aus. Der Shadow-Modus des Gateways schreibt parallel und vergleicht Lesezugriffe im Hintergrund, sodass Sie beobachten können, wie der komprimierte Pfad Ihr Primärsystem nachbildet, bevor Sie den Cutover durchführen.
Highlights
Binary-Quantization verkleinert den ANN-Graph im RAM um bis zu 32×; recall@10 von 0.976–1.000 in einem 30k-Vector-Benchmark (je Store / Over-Fetch) — wählen Sie den Operating Point für Ihr Recall-Ziel.
Store-agnostisch (OpenSearch / pgvector / Qdrant / Milvus); Shadow-Modus validiert den komprimierten Pfad gegen Ihren Primary vor jedem Cutover.
FinOps CLI — prove / compare / tune / drift — misst Kosten, Recall und Latenz und gibt eine deploybare Konfiguration aus.
Lieferumfang
- Amazon Linux 2023 AMI (x86_64) — ein FinOps-Gateway für die Vektorsuche, das hinter Ihrem eigenen Load Balancer in Ihrer eigenen VPC läuft
- Binäre + int8-Quantisierung mit einer zweistufigen Suchpipeline (grobe 1-Bit-Hamming-Phase plus exakter Rescore), die den ANN-Graphen im RAM um bis zu 32x verringert
- Eine Store-agnostische Pipeline über OpenSearch, pgvector, Qdrant und Milvus hinweg, ohne Lock-in
- Ein FinOps-CLI — s4embed prove (Schätzung der Recall-/Kosten-/Latenz-Frontier), compare (Messung des Live-ANN-Recalls über die Stores hinweg), tune (Ausgabe einer Konfiguration, die ein Recall- + Latenz- + RAM-Budget einhält) und drift (Überwachung von Embedding-Drift und Recall sowie Empfehlung einer erneuten Abstimmung)
- Ein Gateway-Shadow-Modus, der Live-Lesezugriffe doppelt schreibt und per Shadow-Vergleich prüft, sodass Sie vor dem Cutover bestätigen können, dass der komprimierte Pfad das Primärsystem reproduziert
- Ein CloudFormation-Quickstart, der die Pfade für OpenSearch und pgvector bereitstellt (Qdrant und Milvus verbinden sich, indem das Gateway auf Ihren bestehenden Endpunkt verwiesen wird)
- Betriebsfunktionen — API-Key-Authentifizierung (falls konfiguriert), Limits für Request-Größe und Concurrency, eine Readiness-Probe mit Fail-Closed-Verhalten bei Abrechnungs- oder Store-Problemen, Prometheus-Metriken und nutzungsbasierte Abrechnung (pro eingebettetem Text, indiziertem Dokument und ausgeführter Suche)
Anwendungsfälle
Große Such- und RAG-Workloads, bei denen die RAM-Kosten der Vektordatenbank mit dem Korpus wachsen
Teams, die die Kosten für die Vektorsuche senken und gleichzeitig ihr Recall-Ziel einhalten möchten
Messung, welcher Store und welche Konfiguration über OpenSearch, pgvector, Qdrant und Milvus hinweg vor dem Übergang in die Produktion am kosteneffizientesten ist
Betrieb der Vektorsuche mit nutzungsbasierter Abrechnung, während Ihre Daten und Ihre Vektordatenbank in Ihrem eigenen Account verbleiben
FAQ
Verschlechtert die Komprimierung nicht den Recall?
Sie wählen den Betriebspunkt. In einem Benchmark mit 30k Vektoren erreichte binäres Hamming + Float-Rescore einen recall@10 von 0.976 bis 1.000 (OpenSearch 0.995, pgvector 0.996, Qdrant 1.000, Milvus 0.976) — und das bei einer 32x-RAM-Reduzierung. Da der Recall mit dem Over-Fetch steigt, stimmen Sie den Betriebspunkt auf Ihr Recall-Ziel ab. Der Recall skaliert mit dem Over-Fetch, und der beste Punkt wird je nach Workload ausgewählt.
Wie viel RAM spart es?
Die binäre Quantisierung macht den ANN-Graphen im RAM um bis zu 32x kleiner, und das int8-Residual macht die Vektoren auf der Festplatte ca. 4x kleiner. Die genaue Reduzierung hängt von Ihrem Korpus, dem Store und dem gewählten Betriebspunkt ab. Der zuverlässigste Weg zur Dimensionierung ist eine Schätzung auf Basis Ihrer eigenen Daten mit s4embed prove und tune.
Welche Vektor-Stores werden unterstützt?
Die Pipeline ist Store-agnostisch für OpenSearch, pgvector, Qdrant und Milvus. Die Pfade für OpenSearch und pgvector können mit dem mitgelieferten CloudFormation-Quickstart bereitgestellt werden, während Qdrant und Milvus funktionieren, indem das Gateway auf Ihren bestehenden Endpunkt verwiesen wird. Mit s4embed compare können Sie den Live-ANN-Recall über die verschiedenen Stores hinweg messen.
Kann ich vor dem Produktions-Cutover validieren?
Ja. s4embed prove und tune schätzen eine Konfiguration anhand Ihrer eigenen Vektoren ab, und compare misst den Live-ANN-Recall über die Stores hinweg. Der Gateway-Shadow-Modus schreibt Live-Lesezugriffe doppelt und führt Shadow-Vergleiche durch, sodass Sie vor dem Cutover bestätigen können, dass der komprimierte Pfad Ihr Primärsystem reproduziert. Anschließend überwacht s4embed drift den Embedding-Drift sowie den Recall und empfiehlt bei Bedarf eine erneute Abstimmung.
Wo liegen meine Daten und wie erfolgt die Abrechnung?
S4 Embed läuft als standardmäßiges Amazon Linux 2023 AMI hinter Ihrem eigenen Load Balancer in Ihrer eigenen VPC. Ihre Daten und Ihre Vektordatenbank verlassen niemals Ihr Konto, und es gibt keinen Lock-in. Die Abrechnung erfolgt nutzungsbasiert über Ihre AWS-Rechnung — pro eingebettetem Text, indiziertem Dokument und ausgeführter Suche — stündlich gemeldet über den AWS Marketplace Metering Service.
Preismodell
Nutzungsabhängige Abrechnung (eingebettete Texte, indexierte Dokumente, bediente Searches) + EC2 in Ihrer eigenen VPC (Amazon Linux 2023 AMI).
Weitere S4-Produkte
S4 — Squished S3
Transparenter GPU S3-Komprimierungs-Gateway
S4 Logs
CloudWatch Logs nach zstd S3 archivieren
S4 Metrics
CloudWatch Metric-Cardinality steuern