100M 규모 벡터 검색: FAISS 1.9의 2.1ms p99 성능 및 Pinecone 대비 11배 비용 절감

Context

100M 규모의 768차원 임베딩 데이터셋 처리 시 발생하는 Latency 증가와 인프라 비용 상승 문제 분석. Managed 서비스의 운영 편의성과 Self-hosted 솔루션의 성능 및 비용 효율성 사이의 극명한 Trade-off 존재.

Technical Solution

• IVF1024, PQ48 인덱싱 조합을 통한 메모리 효율 극대화 및 쿼리 속도 최적화
• nprobe=32 설정을 통한 Recall@10 98.7% 확보와 p99 Latency의 균형 설계
• 100k-vector 단위의 Batch 처리 방식을 도입하여 100M 데이터 적재 시 OOM 발생 방지
• DuckDB 기반 HNSW 구조를 통한 Chroma 0.6의 네이티브 Metadata Filtering 구현
• Pinecone s1.xlarge Pod 기반의 Managed Hybrid Search로 운영 공수 제거 및 가용성 확보
• AWS c6i.8xlarge 인스턴스(128GB RAM) 활용을 통한 고부하 QPS 처리 환경 구축

Impact

• FAISS 1.9: p99 Latency 2.1ms, Max Throughput 142k QPS 달성 및 월 비용 $972 유지
• Chroma 0.6: FAISS 대비 p99 Latency 3.8배 증가 및 Recall 성능 저하 확인
• Pinecone 1.6: Recall@10 99.1%의 최고 정확도를 기록했으나 월 비용 $10,920로 FAISS 대비 11배 높음

Key Takeaway

초대규모 벡터 데이터셋에서는 단순 도구 선택보다 비용-성능-운영 공수의 Trade-off 분석이 핵심. 극한의 성능과 비용 최적화가 필요할 경우 FAISS와 외부 Metadata Store를 조합한 Hybrid 구조 설계가 가장 효율적임.