로컬 LLM은 연산 능력 문제가 아닌 VRAM 용량 문제다

매주 누군가 자신의 GPU가 로컬 모델을 실행하기에 '충분히 빠른지' 묻습니다. 이 질문은 거의 항상 틀립니다. 로컬 추론(local inference)의 경우, 속도(throughput)가 막는 제약 조건이 아니라 용량(capacity)입니다. 가중치(Weights)는 VRAM에 들어맞아야 합니다. 일단 들어가면, 5년 된 카드라도 읽기 속도로 토큰을 생성하며 아무도 알아차리지 못합니다.

따라서 중요한 수치는 메모리에 관한 것이며, 이 두 가지를 분리하면 계산하기 쉽습니다.

VRAM의 두 가지 소비 요소

1. 가중치(Weights) — 선택한 양자화(quantization)에 따른 모델 자체입니다.
2. KV 캐시(KV cache) — 컨텍스트 창(context window) 내 토큰들의 어텐션 키(attention keys)와 값(values)입니다. 이는 컨텍스트 길이, 배치 크기(batch size), 모델 아키텍처에 따라 확장되며, 사람들이 잊어버리는 수치입니다.

KV 캐시에 대한 대략적인 계획 공식 (fp16, 특별한 트릭 없음):

KV bytes ≈ 2 × layers × kv_heads × head_dim × 2 bytes × seq_len × batch

여기서 중요한 항은 seq_len입니다. 4K 컨텍스트에서 편안하게 작동하는 모델이라도 32K에서는 급격히 성능이 떨어질 수 있으며, 디스크에 있는 GGUF 파일 크기는 이와 아무런 관련이 없습니다. 실제 실행되는 용량의 약 3분의 2 정도만 알려줄 뿐입니다.

4비트 기준 모델 크기 추정치

7B   → ~4–5 GB 가중치   → 충분한 컨텍스트 여유 공간이 있는 거의 모든 것을 수용 가능
14B  → ~8–9 GB 가중치   → 적당한 컨텍스트에서 12 GB 카드에 편안함
32B  → ~18–20 GB 가중치 → 실제 컨텍스트 창을 위한 공간이 있는 24 GB의 최적 지점
...

이는 오직 가중치만을 계산한 것입니다. 여기에 KV 캐시, CUDA 컨텍스트 및 프레임워크 오버헤드를 더하고 여유 공간(headroom)까지 고려해야 합니다. 왜냐하면 모델이 실제로 필요할 때가 800 MB가 부족하다는 것을 발견하는 순간일 수는 없기 때문입니다.

실제 보유 용량 확인 방법

하드웨어를 구매하기 전에 다음을 측정하세요:

nvidia-smi --query-gpu=name,memory.total,memory.used --format=csv
nvidia-smi --query-compute-apps=pid,used_memory --format=csv

모델을 '충분히' 담아야 할 장비에서 그렇지 못한 경우, 보통 두 가지 명령이 그 원인을 설명합니다: 하드웨어 가속 기능을 사용하는 브라우저, 또 다른 추론(inference) 서버, 또는 잊고 있던 기가바이트를 점유하고 있는 잔여 프로세스입니다.

양자화(Quantization)는 메모리 결정이지, 디스크 결정이 아니다

표준 4비트 포맷(GGUF/AWQ 스타일)은 가중치(weight) 메모리를 대략 4분의 1로 줄여주며, 이 과정에서 발생하는 품질 저하가 초안 작성, 요약 및 개인 문서 검색 등 대부분의 작업에서는 감지하기 어려울 정도입니다. 하지만 비례적으로 줄어들지 않는 것이 바로 KV 캐시(KV cache)입니다. 따라서 긴 컨텍스트 워크로드(long-context workloads)의 경우, 양자화는 파일 크기가 암시하는 것보다 적은 여유 공간을 제공합니다.

양자화 수준을 선택할 때는 디스크 공간이 아니라 목표 컨텍스트 길이(target context length)를 기준으로 결정해야 합니다. '디스크에 들어간다'와 '내가 필요한 컨텍스트에서 작동한다'는 서로 다른 질문이며, 그 답도 다릅니다.

하드웨어 선택에 대한 시사점

• 24GB 카드 1장 (중고 RTX 3090이 2026년에도 여전히 기본 답변입니다)은 7B–14B 모델을 빠르게 구동하고, 4비트 환경에서 32B 모델을 편안하게 처리하며, 이미지, 음성 및 비전 작업도 수행할 수 있습니다.
• 이 카드 2장이면 70B급 영역에 진입할 수 있으며, 현실적으로는 이미 하드웨어를 구매할 계획이었다면 'TCO(총 소유 비용)가 임대료보다 저렴한' 구간에 도달하는 것입니다.
• MoE 모델은 산술적인 측면을 다시 변화시킵니다: 총 파라미터 수와 활성 파라미터 수가 더 이상 같지 않으므로, 메모리 압박과 컴퓨트(compute) 압박이 분리됩니다. 따라서 어떤 모델이 범접하기 어렵다고 결론 내리기 전에 확인해 볼 가치가 있습니다.
• **CPU 오프로드(offload)**는 작동하지만, 성능이 좋지는 않습니다. 이 기능을 사용하면 모델을 한 번 구동하여 마음에 드는지 확인할 좋은 방법이지만, 매일 사용하는 데에는 끔찍한 방식입니다.

솔직히 말해 분산 처리 관점은...

이 질문 밑바탕에는 실제적인 의문이 있습니다. VRAM이 제약이라면, 왜 여러 기기(machine)에 걸쳐 VRAM을 풀링(pool)하지 못하는가? 이것이 바로 Omniverse Compute와 같은 분산형 GPU 네트워크의 핵심 논지입니다 (솔직히 말하자면, 저는 이 분야에서 일하고 있습니다). 풀링은 작업이 샤딩(sharded)될 수 있는 경우—배치 렌더링, 특정 트레이닝 패턴, 에머싱글리 병렬 추론(embarrassingly parallel inference)—에 도움이 됩니다. 하지만 노드 간 왕복 시간(inter-node round trips)이 이점을 상쇄하는 단일의 지연 시간에 민감한 채팅 세션에는 도움을 거의 주지 못합니다. 네트워크가 '노트북에 VRAM을 추가해준다'고 말하는 사람은 이 구분을 건너뛰는 것입니다.

요약하자면

모델 크기를 디스크 용량이나 벤치마크상의 부러움에 맞춰가 아니라, 필요한 컨텍스트 길이(context length)를 기준으로 VRAM에 맞추어 측정하십시오. 무언가를 구매하기 전에 실제로 상주하는 메모리 양을 측정하세요. 그리고 '더 빠르다'는 것을 구매 문제가 아닌, 양자화(quantization), 배치 처리(batching), 플래시 어텐션(flash attention), 컨텍스트 관리 등 튜닝 문제로 다루십시오.

원문은 Decentralized Compute Forum(https://forum.omc.network)에 게시되었습니다 — GPU 시장과 AI 컴퓨팅 경제학에 대한 에디토리얼 사이트로, OMC 팀이 운영합니다. 출처 글: "양자화는 디스크 문제가 아니라 VRAM 문제" → https://forum.omc.network/posts/quantizing-local-llm-vram-math-2026