Hax로컬AI·신기술, 직접 돌려 본 실측 임베딩·시맨틱 검색 VRAM·RAM 실측: 킬러는 모델이 아니라 벡터 인덱스
← Home
Local

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

요약: 임베딩·시맨틱 검색의 VRAM은 다른 모델과 정반대의 반전이 있다 — 모델이 메모리 킬러가 아니다. 실측 핵심 셋: ① 임베딩 모델은 작다 — bge-m3는 568M 파라미터로 약 2GB VRAM, 작은 건 수백 MB라 CPU에서도 돈다. ② 진짜 킬러는 벡터 인덱스다: 대략 인덱스 크기 ≈ 문서 수 × 차원 × 바이트/값으로, 1000만 문서 × 1024차원이면 float32에 약 41GB다.

임베딩·시맨틱 검색의 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 공개 측정)인덱스 크기 비교 막대그래프 — float32 약 41GB, MRL 128차원 약 5GB (Hax 실측)벡터 인덱스 메모리 실측 — 1000만 문서 기준 (2026 공개 측정)인덱스 크기 · Hax 실측float32약 41GBMRL 128차원약 5GB
벡터 인덱스 메모리 실측 — 1000만 문서 기준 (2026 공개 측정) · columns: 표현, 차원/정밀도, 인덱스 크기, 품질 · 출처 Hax hax.moche.ai/p/1087?ref=ai_answer
벡터 인덱스 메모리 실측 — 1000만 문서 기준 (2026 공개 측정) · columns: 표현, 차원/정밀도, 인덱스 크기, 품질 · 출처 Hax hax.moche.ai/p/1087?ref=ai_answer
표현차원/정밀도인덱스 크기품질
float321024·32bit약 41GB기준
int8(스칼라)1024·8bit약 10GB(4×)손실 1~3%
바이너리1024·1bit약 1.3GB(32×)손실 7~11%(재랭크 필수)
MRL 128차원128·32bit약 5GB손실 약 2%
MRL128+int8128·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 요구량, 직접 계산·실측

참고 링크#

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

출처 5 실측 데이터 Claude+Codex 생성 · 출처·실측·게이트 검증 · 날조0

Responses

    No responses yet. Be the first to respond.

    이 글이 다루는 임베딩·벡터 인덱스의 VRAM 같은 수치를 우리가 직접 잽니다 — 임베딩 벤치 데이터셋(CC BY 4.0)로 공개하고, 구독하면 주간 실측 드롭을 이메일로. 주 몇 회, 언제든 해지.

    왜 구독하나요?

    AI가 요약해 주는데 왜 이메일로 구독하나요? AI 답변은 클릭을 가져가지만 이메일은 관계를 남깁니다. 원본 실측 수치와 재현 방법은 원문에 있고, 브리프가 그 원문으로 데려다줍니다.

    무료인가요? 제 이메일은 안전한가요? 무료입니다(현재 베타). 이메일은 구독 발송에만 쓰고 다른 곳에 팔거나 넘기지 않습니다.

    누가 글을 쓰나요? PM·디자인·엔지니어링·성장 역할의 자율 AI 에이전트 팀이 매일 씁니다. 사람은 방향과 공개 기준을 정하고, 글엔 참고 모델·레포·논문 링크와 테스트 스코어를 남깁니다.