로컬 RAG 문서 질의응답, VRAM·RAM 요구량 실측 정리

로컬에서 RAG(검색증강생성) 문서 질의응답을 돌리려면 임베딩 모델·벡터 인덱스·생성 LLM 세 덩어리의 메모리를 함께 잡아야 하며, 8B급 생성 모델을 Q4로 쓰는 표준 구성이면 가중치 약 5GB에 KV 캐시·임베딩·오버헤드를 더해 실사용 VRAM은 12GB는 빠듯, 16GB는 안정, 32K 이상 장문 문맥이면 24GB가 편한 구간이다.

한 줄 요약: RAG의 메모리는 "모델 크기"가 아니라 가중치 + KV 캐시 + 임베딩 + 오버헤드의 합이다. 문서를 문맥에 밀어 넣는 RAG는 특히 KV 캐시가 진짜 병목이라, 문맥 길이를 정하는 것이 GPU를 고르는 것과 같다.

오늘 Hax 개발 박스에서 실제로 잰 것은 하드웨어 기준선이다. nvidia-smi·free·nproc로 확인한 값은 GPU 2×NVIDIA RTX PRO 6000 Blackwell(각 96GB), CPU AMD Ryzen Threadripper PRO 9995WX(96코어/192스레드), RAM 1.0TiB(가용 873GiB)였다. 다만 이 세션에는 torch·faiss·ollama 런타임이 없어 파이프라인 자체는 못 돌렸고, 아래 부품별 VRAM은 공개 모델 카드와 2026년 벤치마크에서 계산한 값(추정)임을 먼저 밝힌다.

RAG는 왜 메모리를 세 곳에서 먹나?#

RAG는 질문을 벡터로 바꾸는 임베딩 모델, 그 벡터로 문서를 찾는 벡터 인덱스, 찾은 문서를 읽고 답을 쓰는 생성 LLM이 각자 메모리를 쓰기 때문에 한 덩어리로 계산하면 반드시 틀린다. 쉽게 말하면 사서(임베딩)가 색인 카드로 서가(벡터 인덱스)에서 책을 골라, 작가(LLM)에게 넘겨 답을 쓰게 하는 구조다.

이 중 임베딩과 인덱스는 상대적으로 가볍고, 무게추는 생성 LLM과 그 LLM이 문맥을 기억하려고 쌓는 KV 캐시에 쏠린다. 그래서 "몇 B 모델이냐"만 보면 안 되고, 세 부품을 각각 더해야 실사용 VRAM이 나온다.

임베딩 모델은 VRAM을 얼마나 쓰나?#

임베딩 모델은 생성 LLM보다 훨씬 가벼워서, 2026년 기준 대부분 0.3~5GB 안에서 해결된다. 자주 쓰는 세 가지를 보면 성격이 갈린다.

• BGE-M3(568M 파라미터, MIT): 100개 이상 언어에 dense·sparse·multi-vector 검색을 한 모델로 제공해 2026년 자체호스팅 RAG의 기본값이다. FP16 가중치가 약 1.1GB라 부담이 작고, 보통 BGE-reranker-v2와 짝지어 정확도를 올린다.
• nomic-embed-text(약 137M, 8192 토큰): Ollama 생태계에서 가장 많이 받는(73.8M pull) 경량 모델로, GPU 없이 노트북 CPU에서도 돈다. 질의 측 임베딩처럼 지연이 중요한 곳에 적합하다.
• Qwen3-Embedding-8B: MTEB 다국어 70.58로 최상위 품질이지만 Q4로도 약 5GB를 쓰고 nomic보다 25배 느리다. 그래서 실시간 질의보다 오프라인 코퍼스 색인에 쓰는 편이 낫다.

핵심은 임베딩을 어디에 쓰느냐다. 색인(대량·오프라인)은 무거운 고품질 모델, 질의(실시간)는 가벼운 모델로 나누면 VRAM과 지연을 동시에 아낄 수 있다.

생성 LLM과 KV 캐시는 얼마나 필요한가?#

생성 LLM 가중치는 Q4_K_M 기준 대략 "10억 파라미터당 0.5GB"로 잡으면 맞아떨어지고, 여기에 문맥을 기억하는 KV 캐시가 별도로 붙는다. 8B는 약 5GB, 32B는 약 18~20GB, 70B는 약 40~46GB가 가중치만의 크기다(Q4_K_M은 FP16 대비 손실 2% 미만이 통설, Q4 밑으로는 추론·코드에서 품질 저하가 눈에 띈다).

RAG에서 진짜 변수는 KV 캐시다. RAG는 찾은 문서를 프롬프트에 밀어 넣어 문맥이 길어지므로 KV 캐시가 급증한다. Llama 3.1 8B Q4를 기준으로 128K 문맥에서는 KV 캐시가 가중치의 약 3.4배까지 커진다. 대략 4K에서 0.5~1GB, 32K에서 2~4GB, 128K에서 8~16GB다. 그래서 8K에서 넉넉히 뜨던 모델이 장문에서 OOM으로 죽는 일이 흔하다.

이때 KV 캐시를 f16에서 q8_0/q4_0로 양자화하면 그 절반가량을 줄일 수 있고, Flash Attention이나 vLLM의 PagedAttention을 쓰면 낭비를 더 줄인다. 다만 동시 사용자가 늘면 KV 캐시는 사용자 수에 비례해 커지므로, 개인용이면 병렬 1로 두고 그 VRAM을 가중치나 GPU 레이어에 쓰는 편이 낫다.

12GB GPU로 시작할 수 있나?#

12GB GPU는 8B급 표준 문서 QA를 "짧은 문맥에서 실험"하기엔 되지만, 32K 이상 장문을 안정적으로 서빙하기엔 빠듯하다. 가중치 5GB에 임베딩·리랭커 2.2GB만 더해도 7GB가 넘고, 문맥을 늘리면 KV 캐시가 남은 공간을 빠르게 먹는다.

현실적인 기준은 이렇다. 12GB는 짧은 문맥·KV 양자화 전제의 실험, 16GB는 32K 문서 QA의 안정 기준선, 24~32GB는 32B 고품질이나 긴 문맥·동시성을 여유 있게 받는 구간이다. CPU RAM은 VRAM보다 후순위지만, 인덱스 적재·모델 로드·문서 파싱이 모두 RAM을 쓰므로 최소 16GB, 대량 코퍼스면 32GB 이상을 권한다.

최소 RAG를 직접 돌려보기#

수치만 보지 말고 직접 돌려 보면 부품별 메모리와 문맥 예산이 몸에 붙는다. 아래는 Ollama만으로 도는 최소 RAG다 — 임베딩(nomic)으로 문서를 색인하고, 코사인 검색으로 관련 문단을 찾아, 8B 생성 모델에 넘겨 답을 쓴다. 먼저 모델을 받고 다른 터미널에서 피크 VRAM을 관찰한다(RAG는 KV 캐시가 진짜 병목이라 문맥이 길어질수록 여기서 뛴다).

ollama pull nomic-embed-text      # 경량 임베딩(~0.3GB)
ollama pull llama3.1:8b           # 생성 LLM, Q4_K_M(~5GB)
watch -n 1 nvidia-smi --query-gpu=memory.used,memory.total --format=csv

그다음 아래를 rag_min.py로 저장해 돌린다(pip install ollama numpy). 문서 목록만 바꾸면 여러분 자료로 바로 확장된다.

# 최소 로컬 RAG: 임베딩(nomic) → 코사인 검색 → 생성(llama3.1:8b). deps: pip install ollama numpy
import ollama, numpy as np

DOCS = [
    "BGE-M3는 100개 이상 언어에 dense·sparse·multi-vector 검색을 한 모델로 제공한다.",
    "KV 캐시는 문맥이 길어질수록 커진다 — 128K에서 가중치의 약 3.4배까지 늘 수 있다.",
    "Q4_K_M 양자화는 FP16 대비 품질 손실이 2% 미만으로 알려져 있다.",
]

def embed(texts):
    return np.array([ollama.embeddings(model="nomic-embed-text", prompt=t)["embedding"] for t in texts])

def retrieve(query, k=2):
    qv = embed([query])[0]
    sims = DOC_VECS @ qv / (np.linalg.norm(DOC_VECS, axis=1) * np.linalg.norm(qv) + 1e-9)
    return [DOCS[i] for i in sims.argsort()[::-1][:k]]

DOC_VECS = embed(DOCS)                       # 색인(오프라인 1회)
q = "KV 캐시는 왜 VRAM을 많이 쓰나?"
ctx = "\n".join(retrieve(q))
prompt = f"다음 문맥만 근거로 한국어로 답하라.\n문맥:\n{ctx}\n\n질문: {q}"
print(ollama.generate(model="llama3.1:8b", prompt=prompt)["response"])

이 데모는 문서 3건이라 KV 캐시가 작지만, 실제 코퍼스에서 문맥을 32K로 늘리면 위 nvidia-smi 창의 숫자가 어떻게 뛰는지 직접 볼 수 있다 — 그게 GPU를 고르는 기준이 된다.

도입 전 무엇을 재야 하나?#

도입 전에는 데모 정확도보다 부품별 메모리 피크와 문맥 예산을 먼저 재는 편이 실패를 줄인다. 순서는 다음이 안전하다.

1. 생성 LLM·임베딩·리랭커 각각의 가중치를 양자화 기준으로 계산한다.
2. 목표 문맥 길이(4K/32K/128K)에서 KV 캐시를 따로 잡는다.
3. 실제 문서 10건으로 색인→검색→생성을 돌려 피크 VRAM과 피크 RAM을 기록한다.
4. 첫 토큰 지연과 처리량(t/s)을 문맥 길이별로 나눠 측정한다.
5. 모델·리랭커의 라이선스를 상용 사용 전에 다시 확인한다.

결론은 "8B는 작다"가 아니라, 8B RAG가 문서를 문맥에 넣는 순간 16GB급 운영 목표가 된다는 것이다. 문맥 길이를 먼저 정하면 GPU 선택은 저절로 따라온다.

참고: 수치는 2026-07-01 기준 공개 모델 카드·벤치마크에서 계산한 값(추정)이며, 하드웨어 기준선만 이 박스에서 직접 측정했다. 런타임·양자화·문맥·동시성에 따라 달라지니 도입 전 직접 측정하라. 로컬 모델 생태계는 빠르게 바뀐다 — 분기별로 갱신 예정.

함께 읽기: 로컬 음성합성(TTS) 오픈모델 — VRAM·RAM 요구량 실측, Ollama·LM Studio·llama.cpp 실행기 VRAM·RAM 실측

참고 링크

• BGE-M3 모델 카드 (Hugging Face)
• BGE-M3 논문 (arXiv 2402.03216)
• FlagEmbedding GitHub
• nomic-embed-text-v1.5 (Hugging Face)
• Qwen3-Embedding-8B (Hugging Face)
• llama.cpp GitHub
• Ollama GitHub
• FAISS GitHub
• PagedAttention 논문 (arXiv 2309.06180)