S4 Embed
Gateway FinOps para búsqueda vectorial
Una capa FinOps que abarata su base de datos vectorial existente mientras mantiene el recall en el objetivo. Cuantiza embeddings (binary + int8) y ejecuta una búsqueda en dos fases (etapa gruesa Hamming de 1 bit + rescore exacto) delante de OpenSearch, pgvector, Qdrant o Milvus, reduciendo el grafo ANN en RAM hasta 32×. Se ejecuta como una AMI Amazon Linux 2023 en su propia VPC, facturada por unidad de uso (textos embebidos, documentos indexados, búsquedas servidas).
S4 Embed le ayuda a encontrar y operar una configuración de búsqueda vectorial de bajo coste que cumpla su objetivo de recall. En un benchmark de 30k vectores, binary Hamming + float rescore alcanzó recall@10 de 0.976–1.000 según el store y el over-fetch — usted elige el punto operativo. Las herramientas FinOps son el producto: s4embed prove (estimar la frontera recall/coste/latencia), compare (medir el recall en vivo entre stores), tune (emitir una configuración desplegable que cumpla un presupuesto de recall + latencia + RAM), un modo shadow de gateway (dual-write y shadow-compare antes del cutover) y drift (vigilar el drift de embeddings). Independiente del store en OpenSearch, pgvector, Qdrant y Milvus.
El problema
La búsqueda vectorial mantiene su grafo ANN en RAM, por lo que a medida que crece su corpus, la huella de memoria —y el costo— de su base de datos vectorial aumenta a la par, lo que hace difícil predecir dicho gasto. No querrá renunciar al recall para ahorrar dinero, lo que le obliga a elegir entre costo y calidad. Y rara vez existe una buena manera de averiguar qué base de datos y qué configuración entre OpenSearch, pgvector, Qdrant o Milvus es la más rentable antes de ponerla en producción.
Cómo funciona
- 1
Cuantifique los embeddings
S4 Embed cuantifica sus embeddings a binario (un grafo ANN en RAM hasta 32x más pequeño) y un residual int8 (vectores en disco unas 4x más pequeños), reduciendo la RAM que debe mantener su base de datos vectorial.
- 2
Búsqueda en dos etapas para mantener el recall
Una fase preliminar con Hamming de 1 bit crea una lista de candidatos corta, que luego se reordena con un rescore exacto. Al ajustar el punto de operación de over-fetch y rescore, mantiene su objetivo de recall a la vez que reduce el uso de RAM.
- 3
Valide con datos antes de la transición
s4embed prove, compare y tune miden el límite de recall/costo/latencia en sus propios vectores y generan una configuración lista para desplegar. El modo shadow de la gateway realiza escrituras duales y comparaciones en la sombra de las lecturas en tiempo real para que pueda verificar cómo la ruta comprimida reproduce su base de datos principal antes de realizar la transición.
Características destacadas
La cuantización binary reduce el grafo ANN en RAM hasta 32×; recall@10 de 0.976–1.000 en un benchmark de 30k vectores (según store / over-fetch) — elija el punto operativo para su objetivo de recall.
Independiente del store (OpenSearch / pgvector / Qdrant / Milvus); el modo shadow valida la ruta comprimida frente a la principal antes de cualquier cutover.
FinOps CLI — prove / compare / tune / drift — mide coste, recall y latencia, y emite una configuración desplegable.
Qué incluye
- AMI de Amazon Linux 2023 (x86_64) — una gateway de FinOps para búsqueda vectorial que se ejecuta detrás de su propio balanceador de carga, dentro de su propia VPC
- Cuantización binaria + int8 con un pipeline de búsqueda en dos etapas (etapa aproximada de Hamming de 1 bit más rescore exacto), lo que reduce el grafo ANN en RAM hasta en 32x
- Un pipeline agnóstico del almacenamiento compatible con OpenSearch, pgvector, Qdrant y Milvus, sin lock-in
- Una CLI de FinOps — s4embed prove (estima la frontera de recall/coste/latencia), compare (mide el recall de ANN en vivo en los distintos almacenes), tune (genera una configuración que se ajusta a un presupuesto de recall + latencia + RAM) y drift (monitorea la desviación del embedding y el recall, y recomienda volver a ajustar)
- Un modo shadow del gateway que realiza doble escritura y comparaciones shadow de las lecturas en vivo, lo que le permite confirmar que la ruta comprimida reproduce la primaria antes de realizar cualquier transición
- Un quick-start de CloudFormation que aprovisiona las rutas de OpenSearch y pgvector (Qdrant y Milvus se conectan apuntando el gateway a su endpoint existente)
- Funciones operativas — autenticación mediante clave API (cuando esté configurada), límites de tamaño de solicitud y de concurrencia, una readiness probe que responde con fail-closed ante problemas de facturación o de almacenamiento, métricas de Prometheus y facturación medida por uso (por texto embebido, documento indexado y búsqueda servida)
Casos de uso
Cargas de trabajo de búsqueda y RAG a gran escala donde el coste de RAM de la base de datos vectorial crece con el corpus
Equipos que quieren reducir el coste de la búsqueda vectorial manteniendo su objetivo de recall
Medición de qué almacenamiento y configuración entre OpenSearch, pgvector, Qdrant y Milvus es el más eficiente en costes antes de la transición a producción
Ejecución de búsquedas vectoriales con facturación medida por uso mientras mantiene sus datos y base de datos vectorial dentro de su propia cuenta
Preguntas frecuentes
¿No perjudica la compresión al recall?
Usted elige el punto de operación. En un benchmark de 30k vectores, la combinación de Hamming binario + rescore float alcanzó un recall@10 de 0.976 a 1.000 (OpenSearch 0.995, pgvector 0.996, Qdrant 1.000, Milvus 0.976) — todo ello con una reducción de RAM de 32x. El recall aumenta con el over-fetch, por lo que puede ajustar el punto de operación a su objetivo de recall. El recall escala con el over-fetch, y el mejor punto se elige por carga de trabajo.
¿Cuánta RAM ahorra?
La cuantización binaria hace que el grafo ANN en RAM sea hasta 32x más pequeño, y el residuo int8 hace que los vectores en disco sean aproximadamente 4x más pequeños. El ahorro exacto depende de su corpus, del almacenamiento y del punto de operación elegido, por lo que la forma más fiable de calcular el tamaño es estimarlo a partir de sus propios datos con s4embed prove and tune.
¿Qué almacenes de vectores están soportados?
El pipeline es agnóstico del almacenamiento y compatible con OpenSearch, pgvector, Qdrant y Milvus. Las rutas de OpenSearch y pgvector se pueden aprovisionar con el quick-start de CloudFormation incluido, mientras que Qdrant y Milvus funcionan apuntando el gateway a su endpoint existente. s4embed compare le permite medir el recall de ANN en vivo en los distintos almacenes.
¿Puedo realizar la validación antes de pasar a producción?
Sí. s4embed prove y tune estiman una configuración con sus propios vectores, y compare mide el recall de ANN en vivo en los distintos almacenes. El modo shadow del gateway realiza doble escritura y comparaciones shadow de las lecturas en vivo para que pueda confirmar que la ruta comprimida reproduce la primaria antes de la transición, y después s4embed drift monitorea la desviación del embedding y el recall y recomienda un nuevo ajuste.
¿Dónde residen mis datos y cómo se facturan?
S4 Embed se ejecuta como una AMI de Amazon Linux 2023 estándar detrás de su propio balanceador de carga, dentro de su propia VPC. Sus datos y su base de datos vectorial nunca salen de su cuenta y no hay lock-in. La facturación se mide por uso a través de su factura de AWS — por texto embebido, documento indexado y búsqueda servida — y se reporta cada hora a través de AWS Marketplace Metering Service.
Modelo de precios
Medido por uso (textos embebidos, documentos indexados, búsquedas servidas) + EC2 en su propia VPC (AMI Amazon Linux 2023).
Otros productos S4
S4 — Squished S3
Gateway transparente de compresión S3 con GPU
S4 Logs
Archiva CloudWatch Logs en S3 con zstd
S4 Metrics
Gobierna la cardinalidad de métricas de CloudWatch