GPU VRAM(GPU 전용 비디오 메모리)

한 줄 정의

GPU VRAM은 로컬 LLM을 돌릴 때 GPU 쪽에 실제로 남는 빠른 메모리 예산을 뜻해. VRAM이 그래픽카드의 전용 메모리라는 일반 하드웨어 설명이라면, GPU VRAM이라는 표현은 보통 “이 모델 가중치와 키-값 캐시(KV cache)와 작업 버퍼를 GPU에 어디까지 남길 수 있나”를 묻는 운영 문맥에 더 가까워.

그래서 이 말은 단순한 스펙표 숫자보다 배치 문제에 가깝다. GPU가 칩 전체를 가리키는 말이고 VRAM이 그 칩 옆의 전용 메모리 자체를 가리킨다면, GPU VRAM은 그중에서도 추론에서 실제로 남는 몫을 읽는 표현이야. 또 양자화는 이 예산을 줄이거나 늘리는 방법이고, context-window는 그 예산을 계속 먹는 쪽이야. 같은 24GB나 32GB 카드라도 이 조건과 런타임의 오프로드(offload) 방식에 따라 “된다/안 된다” 경계가 달라진다.

비교축을 더 짧게 잡으면 이래. local-llm은 배포 방식이고, GPU VRAM은 그 배포에서 먼저 막히는 하드웨어 예산이야. llama.cpp는 그 예산을 실제로 쪼개고 넘기는 런타임이고, quantization은 같은 예산 안에 더 큰 모델을 넣으려는 압축 방식이야.

어떻게 작동하나

로컬 추론에서는 먼저 모델 가중치 일부나 전부가 GPU VRAM에 올라가고, 생성 중에는 키-값 캐시(KV cache)와 중간 작업 버퍼가 같은 공간을 같이 먹어. 예전에는 이 숫자를 거의 “모델 파일이 전부 들어가야 하는가” 기준으로 읽는 경우가 많았는데, 지금은 그 해석이 자주 너무 단순해.

공식 llama.cpp 문서를 보면 --fit은 기본값이 on이고, unset된 인자를 device memory에 맞게 조정하게 되어 있어. 쉽게 말해 auto-fit은 장치 메모리에 맞게 컨텍스트와 배치 같은 미설정 값을 자동으로 조정하는 기능이야. --fit-target 기본값은 1024 MiB, --fit-ctx 기본값은 4096이라서, 런타임이 여유 공간과 최소 컨텍스트를 같이 보며 타협선을 잡는 구조야. 같은 문서의 tensor-split은 모델 텐서를 여러 GPU에 나눠 올리는 방식이고, split-mode는 레이어와 KV를 어떤 식으로 분할할지 고르는 경로를 제공해. 즉 GPU VRAM은 “넘치면 끝”이라기보다, GPU 안에 무엇을 남기고 무엇을 다른 장치로 밀어낼지 정하는 빠른 티어라고 보는 편이 맞아.

llm-server 같은 상위 도구는 이 감각을 더 노골적으로 드러내. README는 VRAM 크기가 제각각인 여러 NVIDIA GPU를 가중치를 달리해 배치하고, MoE(Mixture of Experts, 전문가 혼합) 자동 배치는 실제로 측정한 VRAM을 기준으로 시작한 뒤 최적화를 캐시한다고 적어. 여기서 GPU VRAM은 단순 용량표가 아니라, 모델 분배와 속도 튜닝의 입력값이 된다.

왜 중요한가

이 표현이 중요한 이유는 로컬 추론에서 가장 흔한 오해를 바로 건드리기 때문이야. LocalLLaMA의 한 사용자는 32GB VRAM이면 보통 20GB 안팎 모델까지만 실용적일 거라고 생각했는데, llama.cpp의 auto-fit인 --fit으로 Qwen3.6 Q8을 256K 컨텍스트에서 돌렸고 57 t/s가 나왔다고 적었어. 원문도 “weights alone are bigger than my VRAM”이라고 적고 있어서, GPU VRAM을 모델 파일 크기와 1대1로 묶는 읽기가 언제 틀리는지 잘 보여 줘.

다른 사례에서는 multi-GPU와 튜닝이 GPU VRAM의 의미를 더 바꿔. llm-server 작성자는 3090 Ti + 4070 + 3060 + 128GB RAM 조합에서 Qwen3.5-27B Q4_K_M이 18.5에서 40.05 tok/s, 122B 모델이 4.1에서 17.47 tok/s로 올랐다고 보고했어. 그리고 댓글에서는 tensor split, 그러니까 모델 텐서를 여러 GPU에 나눠 올리는 방식을 실제로 측정한 VRAM을 기준으로 보수적으로 채운 뒤 더 조여 간다고 설명했어. 숫자 자체보다 중요한 건, GPU VRAM이 한 장짜리 한계선이 아니라 여러 GPU와 RAM 사이에서 조정되는 예산으로 다뤄진다는 점이야.

실무 장면도 두 갈래로 자주 갈린다. 하나는 작은 개인 장비에서 더 큰 모델을 억지로 돌릴 수 있느냐의 문제고, 다른 하나는 여러 GPU가 있어도 카드마다 VRAM과 대역폭이 달라서 어떤 분할이 가장 빠르냐의 문제야. 둘 다 결국 GPU VRAM을 독립 숫자보다 배치와 병목의 언어로 읽게 만든다.

주의해서 볼 점

첫째, GPU VRAM은 VRAM과 같은 물리 자원을 가리키지만, 기사나 커뮤니티에서 이 표현이 나오면 뜻이 더 좁아진다. 대개는 “GPU 전용 메모리가 몇 GB냐”보다 “그중 얼마를 모델 가중치, 키-값 캐시(KV cache), 버퍼, 다른 앱이 나눠 쓰느냐”를 묻는 말이야.

둘째, offload가 가능하다고 해서 GPU VRAM이 덜 중요해지는 건 아니야. VRAM을 넘는 부분을 RAM이나 다른 GPU로 넘기면 실행은 될 수 있어도, 첫 토큰 지연시간이나 긴 문맥 안정성은 크게 달라질 수 있어. 된다와 쓸 만하다는 다른 말이야.

셋째, 이 숫자를 읽을 때는 최소한 아래 네 가지를 같이 봐야 해.

• 모델 양자화가 Q4인지 Q8인지
• 컨텍스트가 4K인지 256K인지
• KV cache 타입을 건드렸는지
• 런타임이 --fit, tensor-split, CPU offload, multi-GPU split을 어떻게 처리하는지

이 조건이 빠진 GPU VRAM 숫자는 방향만 보여 주는 반쪽 정보에 가깝다.