S4 Embed
Vector-search FinOps gateway
기존 vector database를 더 저렴하게 유지하면서 recall target을 맞추는 FinOps layer입니다. embedding을 quantize(binary + int8)하고 OpenSearch, pgvector, Qdrant, Milvus 앞단에서 two-stage search(1-bit Hamming coarse stage + exact rescore)를 실행해 in-RAM ANN graph를 최대 32× 축소합니다. 자체 VPC 안의 Amazon Linux 2023 AMI로 실행되며, usage unit(texts embedded, documents indexed, searches served) 기준으로 과금됩니다.
S4 Embed는 recall target을 만족하는 low-cost vector-search configuration을 찾고 운영하도록 돕습니다. 30k-vector benchmark에서 binary Hamming + float rescore는 store 및 over-fetch에 따라 recall@10 0.976–1.000에 도달했습니다 — operating point는 직접 선택합니다. FinOps tool이 제품의 핵심입니다: s4embed prove(recall/cost/latency frontier 추정), compare(store 간 live recall 측정), tune(recall + latency + RAM budget을 만족하는 deployable config 생성), gateway shadow mode(cutover 전 dual-write 및 shadow-compare), drift(embedding drift 감시). OpenSearch, pgvector, Qdrant, Milvus 전반에서 store-agnostic입니다.
해결하고자 하는 과제
벡터 검색은 ANN 그래프를 RAM에 유지하므로 코퍼스 규모가 확장됨에 따라 벡터 데이터베이스의 메모리 사용량 — 그리고 비용 — 도 함께 증가하며, 이러한 비용 지출은 사전에 예측하기 어렵습니다. 비용 절감을 위해 recall을 희생할 수는 없기 때문에 결국 비용과 품질 중 하나를 취사선택해야 하는 고민에 빠지게 됩니다. 또한 운영 환경에 배포하기 전에 OpenSearch, pgvector, Qdrant, Milvus 등 여러 옵션 중 어떤 저장소와 설정이 가장 비용 효율적인지 검증할 좋은 수단도 마땅치 않습니다.
작동 원리
- 1
임베딩 양자화
S4 Embed는 임베딩을 바이너리(인메모리 ANN 그래프 최대 32x 축소) 및 int8 잔차(디스크 내 벡터 약 4x 축소)로 양자화하여 벡터 데이터베이스가 유지해야 하는 RAM을 감소시킵니다.
- 2
recall 유지를 위한 2단계 검색
1-bit Hamming coarse 단계에서 짧은 shortlist를 구성한 후, 정확한 rescore를 통해 순서를 재정렬합니다. over-fetch와 rescore의 작동 시점(operating point)을 조정함으로써 목표 recall을 만족하는 동시에 RAM 사용을 억제합니다.
- 3
전환 전에 데이터로 검증
s4embed prove, compare, 및 tune 명령어는 귀하의 벡터 데이터를 바탕으로 recall/비용/레이턴시의 한계(frontier)를 정밀하게 측정하고 바로 디플로이할 수 있는 config를 추출합니다. 게이트웨이의 shadow 모드는 실시간 읽기 요청을 복제(dual-writes)하고 shadow-compare하여, 최종 전환을 시작하기 전 압축 경로가 기존 기본 경로의 결과를 그대로 재현해 내는지 모니터링할 수 있게 해줍니다.
주요 특징
Binary quantization으로 in-RAM ANN graph를 최대 32× 축소합니다. 30k-vector benchmark에서 recall@10은 0.976–1.000(store / over-fetch별) — recall target에 맞는 operating point를 선택합니다.
Store-agnostic(OpenSearch / pgvector / Qdrant / Milvus). shadow mode가 cutover 전에 compressed path를 primary와 대조해 검증합니다.
FinOps CLI — prove / compare / tune / drift — 가 cost, recall, latency를 측정하고 deployable config를 출력합니다.
포함 사항
- Amazon Linux 2023 AMI (x86_64) — 귀하의 VPC 내부에서 로드 밸런서 후면에 배치되어 실행되는 벡터 검색용 FinOps 게이트웨이
- 1비트 Hamming 대략적 단계 및 exact rescore를 포함하는 2단계 검색 파이프라인을 적용한 Binary + int8 양자화로, RAM 내 ANN 그래프를 최대 32배까지 축소
- OpenSearch, pgvector, Qdrant, Milvus 전반에 걸쳐 락인이 없는 스토어 독립적 파이프라인
- FinOps CLI — s4embed prove(재현율/비용/지연 시간 프론티어 추정), compare(여러 스토어의 실시간 ANN 재현율 측정), tune(재현율 + 지연 시간 + RAM 예산을 충족하는 설정 생성), drift(임베딩 드리프트와 재현율을 모니터링하고 재튜닝 권장)
- 게이트웨이 shadow 모드 — 실시간 읽기를 이중 쓰기 및 shadow 비교하여, 실제 전환 전에 압축 경로가 기존 primary 결과를 재현하는지 확인
- OpenSearch 및 pgvector 경로를 프로비저닝하는 CloudFormation quick-start (Qdrant와 Milvus는 게이트웨이가 기존 엔드포인트를 가리키도록 하여 연결)
- 운영 기능 — API 키 인증(설정 시), 요청 크기 및 동시성 제한, 결제 또는 스토어 문제 시 fail-closed되는 readiness 프로브, Prometheus 메트릭, 사용량 기준 요금 청구(임베딩된 텍스트, 인덱싱된 문서, 처리된 검색 기준)
주요 활용 사례
코퍼스가 커짐에 따라 벡터 데이터베이스의 RAM 비용이 늘어나는 대규모 검색 및 RAG 워크로드
목표 재현율을 유지하면서 벡터 검색 비용을 절감하고자 하는 팀
운영 환경 전환 전에 OpenSearch, pgvector, Qdrant, Milvus 중 어떤 스토어와 설정이 가장 비용 효율적인지 측정하고 싶은 경우
데이터와 벡터 데이터베이스를 자체 계정 내에 유지하면서 사용량 요금제로 벡터 검색을 운영하고 싶은 경우
자주 묻는 질문
압축하면 재현율이 떨어지지 않나요?
동작 지점은 사용자가 선택할 수 있습니다. 30k 벡터 벤치마크에서 binary Hamming + float rescore는 recall@10 기준 0.976에서 1.000에 도달했습니다(OpenSearch 0.995, pgvector 0.996, Qdrant 1.000, Milvus 0.976). 이는 모두 32배 RAM 절감 상태에서 얻은 결과입니다. over-fetch가 늘어남에 따라 재현율도 올라가므로 목표 재현율에 맞춰 동작 지점을 튜닝할 수 있습니다. 재현율은 over-fetch에 따라 확장되며, 최적의 동작 지점은 워크로드별로 결정됩니다.
RAM은 얼마나 절약되나요?
Binary 양자화를 통해 RAM 내 ANN 그래프를 최대 32배까지 축소할 수 있으며, int8 residual을 사용하면 온디스크(on-disk) 벡터를 약 4배가량 줄일 수 있습니다. 정확한 감소 폭은 코퍼스, 스토어 및 선택한 동작 지점에 따라 달라지므로, s4embed prove 및 tune을 사용해 실제 데이터에서 직접 측정해보는 것이 가장 확실합니다.
어떤 벡터 스토어를 지원하나요?
파이프ライン은 OpenSearch, pgvector, Qdrant, Milvus 전반에 걸쳐 스토어 독립적(store-agnostic)입니다. OpenSearch 및 pgvector 경로는 번들로 제공되는 CloudFormation quick-start를 통해 프로비저닝할 수 있으며, Qdrant와 Milvus는 게이트웨이가 기존 엔드포인트를 가리키도록 지정하여 연동할 수 있습니다. s4embed compare를 사용하면 여러 스토어의 실시간 ANN 재현율을 측정할 수 있습니다.
운영 환경으로 전환하기 전에 검증할 수 있나요?
네, 가능합니다. s4embed prove 및 tune을 통해 실제 벡터 데이터 기반으로 설정을 추정하고, compare로 각 스토어의 실시간 ANN 재현율을 측정합니다. 게이트웨이 shadow 모드는 실시간 읽기를 이중 쓰기 및 shadow 비교하므로, 전환 전에 압축 경로가 기존 primary 결과를 재현하는지 직접 확인할 수 있습니다. 이후 s4embed drift가 임베딩 드리프트와 재현율을 모니터링하여 재튜닝을 제안합니다.
데이터는 어디에 저장되며 요금은 어떻게 청구되나요?
S4 Embed는 자체 VPC 내부에서 고객 본인의 로드 밸런서 뒤에 표준 Amazon Linux 2023 AMI로 실행됩니다. 데이터와 벡터 데이터베이스는 고객의 계정을 벗어나지 않으며 락인도 없습니다. 요금은 사용량 기준으로 청구되며, 임베딩된 텍스트, 인덱싱된 문서, 처리된 검색 건수 단위로 측정되어 AWS Marketplace Metering Service를 통해 매시간 보고되고 AWS 청구서에 반영됩니다.
요금제 모델
Usage-metered(texts embedded, documents indexed, searches served) + 자체 VPC 내 EC2(Amazon Linux 2023 AMI).
