RTX 5060 Ti 16GB vs 8GB, 로컬 LLM 돌릴 때 뭐가 다른가 (실측)

5060 Ti를 살 때 8GB와 16GB 중에 뭘 고를지 고민하셨다면, 로컬 LLM 용도로는 답이 꽤 명확해요.

저는 16GB를 쓰고 있는데, 그 16GB를 어떻게 쓰다가 어떻게 말아먹었는지 실측으로 정리해봤습니다.

먼저 결론

용량	현실적으로 올라가는 모델	비고
8GB	8B급 (약 5GB)	컨텍스트 길게 쓰면 빠듯함
16GB	14B급 (약 9GB)	7GB 여유. 실사용 구간
16GB	27B급 (약 16GB)	숫자만 맞고 실제로는 안 됨

로컬 LLM이 목적이면 16GB로 가세요. 8GB는 모델 선택지가 확 줄어듭니다.

그런데 16GB를 샀다고 27B가 돌아가는 건 아닙니다. 그 얘기를 하려고 합니다.

두 달 동안 느렸는데 원인이 엉뚱했습니다

로컬에서 LLM을 돌린 지 몇 달 됐는데, 어느 순간부터 모델이 너무 느렸어요. 응답이 120초를 넘겨서 타임아웃이 나기 일쑤였고요.

그래서 계속 더 좋은 모델을 찾아다녔습니다. 새로 나온 27B를 받아보고, 1비트 양자화 모델도 찾아보고요.

결론부터 말하면 모델 문제가 아니었습니다. 자리가 없었던 거예요.

먼저 카드 사양부터

RTX 5060 Ti 16GB입니다. nvidia-smi로 찍으면 정확히 16,311 MiB예요.

로컬 LLM 기준으로 나쁘지 않은 위치입니다. 대략 이렇게 나뉩니다.

• 14B급 Q4 (8~9GB): 여유 있게 GPU에 다 올라감
• 27B급 Q4 (16GB 내외): 카드 전체를 다 써야 겨우 들어감
• 그 이상: 안 됨

문제 1. 27B가 애초에 안 들어가고 있었어요

쓰고 있던 모델이 qwen3.6:27b, Q4_K_M으로 16.2GB였습니다.

카드가 16.3GB인데 모델이 16.2GB예요. 숫자만 보면 들어갑니다. 그런데 KV 캐시가 들어갈 자리가 없습니다.

컨텍스트를 처리하려면 KV 캐시 공간이 따로 필요한데, 그게 없으니 일부가 CPU로 넘어갑니다. 그래서 27B를 쓴다고 생각했지만 실제로는 반쯤 CPU로 새고 있었어요.

새 모델도 확인해봤는데 마찬가지였습니다.

모델	크기	결과
Ollama qwen3.8:27b	18GB	안 들어감 (최저 태그가 q4_K_M)
Qwen3.8-27B GGUF Q3_K_M	13.8GB	들어가지만 KV 여유 2GB, 같은 문제 반복
qwen3:14b	9.3GB	여유 7GB, 정상 동작

문제 2. 1비트 모델은 표준 Ollama로 안 돌아갔어요

27B급을 3.8GB로 줄인 1비트 모델이 있다고 해서 받아봤습니다. 공식 저장소에서 정상적으로 받아졌고요.

그런데 실행하니 이렇게 나왔습니다.

Error: 500 Internal Server Error: unable to load model

모델 카드를 다시 읽어보니 전용 llama.cpp 포크가 필요하다고 적혀 있었어요. 표준 Ollama(0.21.2)로는 안 됩니다.

받기 전에 모델 카드를 읽었어야 했는데 그냥 받았습니다.

여기서 크게 하나 실수했어요

ollama pull을 할 때 양자화 태그를 안 붙였습니다.

# 이렇게 하면 안 됩니다
ollama pull hf.co/<저장소>/<모델>-gguf

# 이렇게 해야 합니다
ollama pull hf.co/<저장소>/<모델>-gguf:Q1_0

태그를 빼면 기본값으로 F16 원본 53GB가 받아집니다. C드라이브 여유 공간이 78GB에서 27GB로 떨어졌어요. 지우고 다시 받아서 복구했습니다.

HuggingFace GGUF 저장소에서 받을 때는 반드시 양자화 태그를 붙이세요.

진짜 원인은 VRAM 점유였습니다

nvidia-smi로 실제 사용량을 찍어봤습니다.

사용 11,644 MiB / 여유 4,409 MiB

16GB 중 11.6GB가 이미 쓰이고 있었어요. 남은 게 4.4GB뿐이었습니다.

누가 쓰고 있었냐면 셋이었습니다.

1. llama-server — 27B 모델을 -ngl 35로 GPU에 상주시키는 중
2. Ollama — 8B 모델 하나를 6.8GB로 상주
3. ComfyUI — 같은 포트에 두 개가 중복 실행 중

qwen3:14b가 8.6GB, gemma3:12b가 7.6GB인데 남은 자리가 4.4GB였어요. 당연히 안 들어가고 CPU로 넘어가서 120초를 넘긴 겁니다.

재미있는 건 8B 모델 하나만 정상이었다는 건데, 이유는 단순했습니다. 그것만 이미 GPU에 올라가 있었어요.

정리하고 나서 측정한 결과

세 개를 정리했습니다. 중복 실행되던 ComfyUI를 내리고, 쓰지도 않으면서 27B를 물고 있던 llama-server를 껐습니다.

정리 전: 사용 11,644 MiB / 여유  4,409 MiB
정리 후: 사용  1,586 MiB / 여유 14,467 MiB

그리고 같은 모델을 다시 돌렸습니다.

모델	정리 전	정리 후
qwen3:14b	120초 타임아웃	8초, 40.9 tok/s
gemma3:12b	120초 타임아웃	6초

모델을 하나도 안 바꿨습니다. 원래 있던 그 모델들이에요.

배운 것

모델이 느리면 모델부터 의심하지 마세요. nvidia-smi로 VRAM 여유부터 보는 게 먼저입니다.

저는 두 달 동안 “모델이 느리다”고 생각하면서 더 좋은 모델을 찾아다녔는데, 정작 필요한 건 자리를 비우는 일이었어요. 새 모델 받느라 쓴 시간과 53GB 다운로드가 전부 헛수고였습니다.

그리고 하나 더. 안 쓰는 프로세스가 GPU를 물고 있는 걸 몰랐습니다. llama-server는 몇 달 전에 안 쓰기로 정해놓고 프로세스만 안 껐던 거였어요. 결정만 하고 실행을 안 하면 그대로 비용이 됩니다.

16GB 카드를 쓰신다면 14B급으로 가시고, 27B는 다른 걸 다 내려야 겨우 들어간다고 보시면 됩니다.