임베딩·시맨틱 검색 VRAM·RAM 실측: 킬러는 모델이 아니라 벡터 인덱스

임베딩·시맨틱 검색의 VRAM은 다른 모델과 정반대의 반전이 있다 — 모델이 메모리 킬러가 아니다. 실측 핵심 셋: ① 임베딩 모델은 작다 — bge-m3는 568M 파라미터로 약 2GB VRAM, 작은 건 수백 MB라 CPU에서도 돈다. ② 진짜 킬러는 벡터 인덱스다: 대략 인덱스 크기 ≈ 문서 수 × 차원 × 바이트/값으로, 1000만 문서 × 1024차원이면 float32에 약 41GB다. ③ 그래서 레버는 '모델 양자화'가 아니라 차원 축소(Matryoshka)+벡터 양자화(int8·바이너리)다 — int8이면 4배, 바이너리면 32배 줄어든다. 즉 임베딩 메모리는 모델이 아니라 코퍼스 크기와 벡터 표현이 정한다.

한 줄 요약: 임베딩은 도서관 색인 카드다. 사서(모델)는 한 명이면 되지만, 책이 1000만 권이면 카드 상자(벡터 인덱스)가 방을 가득 채운다. 카드를 작게(차원↓) 또는 요약해(양자화) 만들면 같은 방에 훨씬 많은 책을 색인한다.

용어부터. 벡터 인덱스는 문서 임베딩(숫자 벡터)을 모아 검색 가능하게 저장한 자료구조, Matryoshka(MRL)는 한 벡터의 앞부분만 잘라 써도 뜻이 유지되게 학습한 것, 벡터 양자화는 각 숫자를 더 적은 비트(int8·1bit)로 저장하는 것이다.

임베딩 VRAM은 왜 반전인가?#

모델은 작고, 인덱스가 코퍼스에 비례해 커지기 때문이다. LLM은 모델(가중치)이 메모리를 먹지만, 임베딩은 모델이 한 번 인코딩하면 끝이고 결과 벡터를 전부 저장해야 검색이 된다. 그 저장량이 진짜 비용이다 — 벡터는 문서마다 하나씩, 차원만큼의 숫자다. 그래서 "bge-m3가 2GB니 2GB면 되겠지"가 아니라 몇 개 문서를, 몇 차원으로, 어떤 정밀도로 저장하나를 계산해야 한다.

벡터 인덱스 메모리 실측 — 1000만 문서 기준 (2026 공개 측정) · columns: 표현, 차원/정밀도, 인덱스 크기, 품질 · 출처 Hax hax.moche.ai/p/1087?ref=ai_answer

벡터 인덱스 메모리 실측 — 1000만 문서 기준 (2026 공개 측정) · columns: 표현, 차원/정밀도, 인덱스 크기, 품질 · 출처 Hax hax.moche.ai/p/1087?ref=ai_answer

표현 | 차원/정밀도 | 인덱스 크기 | 품질
float32 | 1024·32bit | 약 41GB | 기준
int8(스칼라) | 1024·8bit | 약 10GB(4×) | 손실 1~3%
바이너리 | 1024·1bit | 약 1.3GB(32×) | 손실 7~11%(재랭크 필수)
MRL 128차원 | 128·32bit | 약 5GB | 손실 약 2%
MRL128+int8 | 128·8bit | 약 1.3GB(약 78%↓) | 소폭

목차

벡터 인덱스는 얼마나 드나?

어떻게 줄이나?

그래서 어떻게 설계하나?

참고 링크

벡터 인덱스는 얼마나 드나?#

문서 수 × 차원 × 바이트/값 공식이 전부다. 1000만 문서 × 1024차원 기준 float32 41GB, int8 10GB, 바이너리 1.3GB(HNSW 그래프 오버헤드 별도)다. Sentence-Transformers 실측에선 바이너리 인덱스+int8 재점수가 메모리 5.2GB·디스크 52GB로, 일반 검색(메모리 200GB·디스크 200GB) 대비 극적으로 작다. 즉 코퍼스가 커질수록 모델은 그대로인데 인덱스만 폭증하므로, 처음부터 차원·정밀도를 정해야 한다.

어떻게 줄이나?#

차원 축소와 벡터 양자화, 둘은 직교라 함께 쓴다. 첫째 Matryoshka(MRL): bge-m3는 2048→256차원으로 잘라 쓸 수 있어, 128차원이면 품질 약 2% 손실로 저장을 절반 넘게 줄인다. 둘째 벡터 양자화: int8(스칼라)이 안전한 기본으로 4배 축소·손실 1~3%(384차원서 Recall 1.46%↓)다. 바이너리는 32배지만 손실 7~11%라 재랭크가 필수(저차원선 급락). 둘을 겹치면(MRL 128+int8) 약 78% 절감, 바이너리+int8 재점수는 최대 32배를 손실 약 3%로 낸다.

그래서 어떻게 설계하나?#

핵심은 모델이 아니라 인덱스를 설계하는 것이다.

기본: 모델은 bge-m3(약 2GB)면 충분, 인덱스는 int8을 기본으로(4×·손실 1~3%).

대규모: 바이너리 검색 → int8 재점수 → 크로스인코더 리랭크의 3단 파이프라인이 저메모리·고품질의 정석이다.

절감: 코퍼스가 크면 MRL로 차원부터 줄이고 양자화를 얹는다. 정확한 손실·크기는 내 코퍼스로 직접 재라.

함께 읽기: 에이전트 브라우저 제어, 직접 써보고 느낀 점과 한계, 로컬 LLM, VRAM은 얼마나 필요할까

함께 읽기: 4bit·8bit 양자화 VRAM·RAM 요구량, 직접 실측, 로컬 오픈 LLM VRAM·RAM 요구량, 직접 계산·실측

참고 링크#

BGE-M3/FlagEmbedding(다국어 임베딩)

sentence-transformers(임베딩·양자화)

임베딩 양자화(Hugging Face 블로그)

faiss(벡터 인덱스·HNSW)

임베딩 저장 최적화 논문(arXiv)

참고: GB·손실 수치는 2026년 공개 측정·추정이며 코퍼스·차원·인덱스(HNSW/IVF)·재랭크 유무에 따라 달라진다(영구 수치 아님). 바이너리는 저차원서 급락하니 재랭크와 함께만 써라. 정확한 메모리·정확도는 내 코퍼스·질의로 직접 재라(여기 수치는 출발점). 임베딩·벡터 검색 스택은 빠르게 바뀌니 분기별로 다시 본다.