벡터 데이터베이스 메모리 크기 산정 및 비용 계산: 벡터 100만 개는 RAM을 얼마나 필요로 할까?

임베딩 차원, 정밀도(precision), 메타데이터, 인덱스 오버헤드, 복제본(replicas), 용량 계획 등을 통해 벡터 데이터베이스의 메모리, 디스크 및 비용을 추정할 수 있습니다.

첫 번째 벡터 데이터베이스 메모리 공식은 다음과 같습니다: 순수 벡터 바이트 = N × D × B. 여기서 B는 float32의 경우 4바이트, float16의 경우 2바이트, int8/SQ8의 경우 1바이트를 사용합니다. N은 벡터 개수이고 D는 차원(dimension) 수입니다. 결과를 소수점 GB로 나타내려면 $10^9$로 나누고, 이진 GiB로 나타내려면 $2^{30}$으로 나눕니다. 따라서 1536차원의 float32 벡터 100만 개는 1,000,000 × 1536 × 4 = 6,144,000,000 bytes, 즉 순수 벡터 저장 공간으로 6.144 GB / 5.72 GiB가 필요합니다.

OpenAI text-embedding-3-small 벡터 100만 개에 대한 간단한 답변: 기본 1536 차원 및 float32 저장 방식을 사용하면 순수 벡터는 6.14 GB를 차지합니다. M=16 HNSW 그래프와 25% 작업 여유 공간(working headroom)을 고려할 때, 벡터 검색에 필요한 메모리 집합(resident set)은 약 7.9 GB입니다. PostgreSQL 또는 데이터베이스 프로세스, 메타데이터, 필터 인덱스, 쿼리 동시성(query concurrency), 운영체제 등을 포함하여 최소 12 GB의 호스트를 계획해야 하며, 더 안전한 프로덕션 환경에서는 16 GB RAM을 권장합니다. 만약 SQ8이 RAM에 유지되고 원본 벡터가 디스크에 남아 있는 경우, 검색 계층은 측정된 재현율(recall) 및 p95 지연 시간(latency)에 따라 대략 2.1–2.5 GB까지 낮아질 수 있습니다.

1. 올바른 단위를 사용하세요: GB와 GiB는 상호 교환할 수 없습니다

클라우드 가격 책정 및 제품 페이지에서는 종종 GB를 사용하지만, 운영체제 도구에서는 종종 GiB를 표시합니다. 같은 바이트 개수라도 약 7%의 차이로 6.144 GB 또는 5.72 GiB입니다. 임베딩 API의 JSON 응답 크기가 저장 공간 크기와 같지는 않습니다. 텍스트 숫자와 프로토콜 프레이밍은 전송에 영향을 미치지만, 데이터베이스의 물리적 자료형(datatype)이 저장 공간을 결정합니다.

OpenAI의 공식 임베딩 가이드에 따르면 text-embedding-3-small은 기본 길이로 1536을, text-embedding-3-large는 3072를 제공하며, dimensions 매개변수를 통해 더 짧은 출력을 지원합니다. 따라서 모델 이름만으로는 용량을 증명할 수 없으며, 애플리케이션이 실제로 요청하고 저장하는 D 값을 측정해야 합니다.

Memory sizing layers for raw vectors, the HNSW graph, working headroom, and host RAM for one million embeddings

2. 벡터와 분리하여 HNSW 그래프 크기 산정하기

HNSW는 다층 근접 이웃 그래프(multilayer nearest-neighbour graph)를 통해 포인트를 연결합니다. 그래프 메모리는 주로 벡터 개수, 연결성 M, 식별자 너비, 엔진 레이아웃에 따라 규모가 결정되며, 순수 벡터 메모리는 N × D에 비례하여 규모가 결정됩니다. HNSW 논문에서는 벡터 데이터를 제외하고 객체당 약 60–450 바이트의 구현 의존적 그래프 비용을 논의합니다. HNSW가 항상 순수 벡터 크기의 20–50%라는 보편적인 규칙은 없으며, 이 비율은 낮은 차원(low dimensions)에서 더 크게 보이고 3072 차원에서는 더 작아집니다.

용량 계획을 위해서는 엔진별 근사치가 필요합니다. Qdrant의 용량 계획 가이드는 HNSW 그래프에 대해 N × M × 2 × 4 bytes × 1.2를 사용합니다. 이 요소들은 양방향 링크, 4바이트 포인트 식별자, 그리고 레이어링/관리 여유분을 나타냅니다. 백만 개의 포인트를 기준으로 할 때, 이는 M=16의 경우 153.6 MB와 M=32의 경우 307.2 MB를 추정합니다. 다른 엔진은 서로 다른 포인터, 정렬(alignment), 세그먼트, 복사본을 사용할 수 있습니다.

3. 백만 개 벡터 비교표

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

4. 작업 예시: 1536차원 RAG 컬렉션

호스트 계산은 여기서 끝나지 않습니다. 평균 1 KB의 페이로드를 가진 백만 개의 포인트는 1 GB의 원본 페이로드를 추가합니다. 이 모든 것이 메모리에 상주할 필요는 없지만, '핫' 필터 인덱스는 그럴 수 있습니다. PostgreSQL 세션은 work_mem을 소비할 수 있고, Qdrant 최적화 도구(optimizer)는 새로운 세그먼트를 생성할 수 있으며, Milvus 쿼리 노드는 로딩 및 압축을 위한 임시 공간이 필요합니다. 7.9 GB의 작업 집합(working set)을 정확히 8 GB의 물리적 RAM에 배치하는 것은 용량 계획이 아니라 지속적인 메모리 압박입니다.

5. 양자화 (Quantization): 75% 작아진 것이 실제이며, 고정된 품질 손실은 아니다

스칼라 양자화(Scalar quantization)는 일반적으로 각 float32 구성 요소를 하나의 int8 바이트로 표현하여 벡터 복사본을 약 75% 축소합니다. 시스템은 여전히 재점수 지정(rescoring)을 위해 원본 데이터를 유지할 수 있으므로, RAM은 감소할 수 있지만 디스크에는 원본 + 양자화된 복사본이 저장됩니다. Qdrant의 양자화 문서는 디스크에 원본을 두고 RAM에 고정하는 하이브리드 레이아웃을 설명합니다.

• SQ8 / int8: 벡터당 D 바이트. SIMD 친화적이며 일반적으로 테스트하는 첫 번째 압축 프로파일입니다.
• float16 / half precision: 벡터당 2 × D 바이트. 대략 50% 작으며, pgvector는 halfvec을 사용하여 최대 4000 차원까지 인덱싱할 수 있습니다.
• Binary quantization: 벡터당 D/8 바이트. 매우 높은 압축률로, 종종 후보 생성(candidate generation) 후 전체 정밀도 재순위 지정(reranking)에 사용됩니다.
• Product quantization: 벡터당 ceil(subquantizers × bits / 8) 바이트와 코드북이 필요합니다. 학습(training), 조정(tuning), 품질 검증이 필요합니다.

'재현율(recall)이 단지 1–2% 하락한다'는 주장은 보편적이지 않습니다. 임베딩 분포, 거리 메트릭, 분위수(quantile), 코드 길이, ef_search/nprobe, 필터, 그리고 재점수화 깊이(rescoring depth)가 결과에 영향을 미칩니다. Faiss 인덱스 테이블은 저장 모델을 명확히 보여줍니다: HNSW Flat은 대략 4D + links이며, SQ8은 D이고, PQ는 벡터당 구성된 코드 길이를 사용합니다.

Memory and quality trade-offs across float32, float16, SQ8, product quantization, and binary quantization

6. pgvector 메모리: shared_buffers가 유일한 캐시는 아니다

pgvector는 PostgreSQL의 페이지 및 인덱스 메커니즘 내에서 작동합니다. 모든 HNSW 바이트가 shared_buffers 안에 고정(pinned)되어야 하는 것은 아닙니다. PostgreSQL의 버퍼와 운영체제 페이지 캐시 모두 참여합니다. PostgreSQL 리소스 문서는 전용 서버에서 shared_buffers를 시작점으로 RAM의 25%로 권장하며, PostgreSQL이 OS 캐시에 의존한다는 점을 설명합니다. effective_cache_size는 예약된 메모리가 아니라 플래너(planner)의 가정치입니다.

만약 hot HNSW 페이지가 결합된 캐시 예산을 초과하면, 랜덤 페이지 폴트(random page faults)와 스토리지 읽기(storage reads)가 증가합니다. 5ms에서 400ms로 급증할 수 있지만 보편적인 현상은 아닙니다. 이는 NVMe 지연 시간(latency), 캐시 적중률(cache hit rate), ef_search, 필터, 그리고 동시성(concurrency)에 따라 결정됩니다. 공식 pgvector 문서에 따르면 HNSW는 IVFFlat보다 더 많은 메모리를 사용하며, 그래프가 maintenance_work_mem 내부에 들어갈 때 훨씬 빠르게 구축되고, 기본값은 M=16, ef_construction=64입니다.

pgvector에는 또한 중요한 차원 제한이 있습니다. vector 타입은 HNSW/IVFFlat에 대해 최대 2000차원을 지원하는 반면, halfvec는 최대 4000차원을 지원합니다. 따라서 기본값인 3072차원의 text-embedding-3-large 결과는 HNSW를 사용하여 vector(3072)로 직접 인덱싱할 수 없습니다. OpenAI에 요청하여 2000차원 이하의 차원을 받거나, 하프 정밀도(halfvec(3072)) 인덱스를 구축한 다음 동일한 평가 세트에서 검색 품질을 다시 측정해야 합니다.

7. Qdrant와 Milvus는 배치를 설계 선택으로 만듦

전용 벡터 데이터베이스는 ANN 알고리즘뿐만 아니라 벡터, HNSW, 양자화된 복사본(quantized copies), 페이로드(payloads), 그리고 페이로드 인덱스에 대한 배치 제어를 통해 차별화됩니다. Qdrant의 현재 메모리 계층은 구조를 pinned, cached, 또는 cold로 분류합니다. Cached와 cold 구조는 mmap을 사용하며, 주요 차이점은 시작 시 워밍업(warmed)되는지 여부입니다. cold HNSW 그래프는 그래프 순회가 작은 랜덤 읽기를 수행하기 때문에 주의가 필요합니다. 양자화된 복사본을 상주시키고 원본은 최상위 후보 재점수화(top-candidate rescoring)에만 읽는 것이 종종 더 균형 잡힌 접근 방식입니다.

Milvus 역시 벡터 필드와 벡터 인덱스에 대해 별도의 mmap 제어 기능을 제공합니다. 이러한 기능들이 ‘RAM이 10배 적어도 동일한 성능’을 보장하지는 않습니다. 작업 집합(working set)이 메모리를 초과하면 페이지 폴트(page faults), 디스크 큐(disk queues), 그리고 긴 지연 시간(tail latency)이 증가할 수 있습니다. 방어 가능한 주장은 전용 엔진들이 더 세밀한 상주 메모리 대 디스크 배치(resident-versus-disk placement)를 제공한다는 것입니다. 실제로 달성되는 비율은 SSD, 쿼리 분포, 그리고 목표 품질에 따라 달라집니다.

8. IVFFlat이 HNSW보다 메모리를 적게 사용하는가?

IVFFlat은 그래프 링크를 저장하지 않기 때문에 일반적으로 인덱스 오버헤드가 더 낮습니다. 이는 벡터들을 거친 중심점(coarse centroids) 주변의 리스트로 그룹화하고, 쿼리당 nprobe 리스트를 스캔합니다. 만약 전체 벡터를 저장한다면, 순수한 4D 비용은 그대로 유지됩니다. Faiss는 IVFFlat을 대략 4D + 벡터당 8 바이트로 요약하며, HNSW Flat은 4D + 그래프 링크입니다. pgvector의 IVFFlat은 대표 데이터와 적절한 lists 값을 필요로 하며; 분포가 크게 변하면 재콜(recall)을 다시 측정해야 하고 인덱스를 재구축해야 할 수도 있습니다.

HNSW는 일반적으로 인터랙티브 검색에 대해 더 강력한 속도-재콜 트레이드오프를 제공하며, 그래프 메모리, 느린 빌드 시간, 비용이 많이 드는 삽입(insert)을 감수하는 대신 온라인으로 훈련 단계 없이 성장합니다. IVFFlat은 인덱스 오버헤드가 작아 대규모 배치 지향 컬렉션에 적합할 수 있습니다. 동일한 필터 조건 하에서 Recall@10, p50/p95/p99, 빌드 시간, 삽입 처리량, 그리고 재인덱싱 비용을 비교하십시오.

9. 인덱스가 RAM에 맞지 않을 때 실제로 무슨 일이 발생하는가?

데이터베이스가 반드시 멈추는 것은 아닙니다. mmap이나 페이지 캐시를 사용하는 엔진은 디스크에서 필요한 페이지를 가져와 더 오래된 페이지를 제거합니다(evict). HNSW 탐색 과정에서는 분산된 이웃을 건드리므로, 캐시 미스(cache miss) 자체가 저장 지연 시간(storage latency)을 추가할 수 있습니다. 작업 집합(working set)이 RAM보다 실질적으로 크고 쿼리가 광범위하게 분산될 경우, 주요 페이지 폴트(major page faults), 큐 깊이(queue depth), 그리고 p99 지연 시간이 함께 증가합니다. 스왑(swap)이 활성화되어 있다면, 데이터베이스 히ープ 페이지가 스왑될 수도 있어 실패 모드를 더욱 악화시킵니다.

• 캐시 적중률(cache hit ratio)에만 의존하지 말고, 주요 페이지 폴트, 읽기 IOPS, 큐 깊이, 디스크 지연 시간을 모니터링하세요.
• p50은 건강하게 유지되더라도 p99는 급격히 떨어질 수 있습니다. 용량 결정 시에는 테일 레이턴시(tail latency)를 고려해야 합니다.
• 필터링된 ANN(Filtered ANN)은 후보군을 줄이거나 필터링 후 재현율(recall)을 낮출 수 있으므로, 테넌트 및 카테고리 분포를 재현해 보세요.
• 콜드 스타트(cold start), 웜 캐시(warm cache), 그리고 안정 상태(steady state)를 별도로 보고하세요.
• 재구축(rebuild), 압축(compaction), 스냅샷(snapshot), 백업 과정 중 일시적인 RAM 및 디스크 피크를 연습해 보세요.

10. 복제본 및 샤드 계산 (Replication and shard math)

복제 계수(replication factor)가 두 배라는 것은 클러스터 전체의 벡터 및 인덱스 사본이 대략 두 배가 된다는 의미일 뿐, 노드 두 개가 자동으로 노드당 데이터를 절반으로 줄여주지는 않습니다. 샤드는 데이터를 분산시키고, 복제본은 탄력성(resilience)을 제공합니다. 장애 발생 후 남은 노드들이 쿼리와 재조정 부하를 흡수해야 합니다. 관리형 서비스 비용에는 명목상의 데이터 크기뿐만 아니라 복제본, 최소 노드 수, 스냅샷, 네트워크 이그레스(network egress), 그리고 재인덱싱 시간까지 포함되어야 합니다.

11. 바이트를 월별 비용으로 변환하기 (Turn bytes into monthly cost)