RTX 5060 Ti 16GB에서 직접 돌려 본 로컬 LLM — Ollama로 잰 속도와 CanRun 추정

시스템 RAM 32GB 데스크톱에 꽂은 GeForce RTX 5060 Ti 16GB에서 많이 쓰는 8B~14B 모델 네 개를 Ollama로 직접 돌려 봤습니다. 네 모델 모두 그래픽카드에 다 올라갔고, 생성 속도는 모두 CanRun의 8k 추정보다 빨랐습니다. 그중 Llama 3.1 8B와 Gemma 3 12B는 CanRun이 Q4_K_M 행에 올려 둔 파일과 같은 파일이라, 이 카드의 두 조합 페이지에는 이제 이 결과가 ‘실측’ 라벨로 나옵니다.

직접 잰 결과

아래 상자에는 모델마다 결과가 하나씩 있습니다. 세 번 잰 값의 가운데 값이고, 그 뒤에 CanRun이 8k 컨텍스트 기준으로 낸 추정과 범위, 신뢰 라벨이 붙습니다.

결과 옆의 컨텍스트는 측정 중에 실제로 채워진 깊이입니다. 프롬프트가 400토큰쯤이고 답은 최대 256토큰이라, KV 캐시에는 650토큰 정도까지만 쌓였습니다. 대화를 막 시작한 정도의 길이입니다. CanRun이 판정할 때 가정하는 8k를 꽉 채운 대화와는 거리가 있습니다. 어느 기준으로 봐도 두 모델은 이 카드에서 쾌적하게 돌아갑니다.

Qwen3 8B와 Qwen3 14B도 같이 쟀습니다. 둘 다 GPU에 다 올라갔고 CanRun 추정보다 비슷한 정도로 빨랐지만, 위 상자에는 넣지 않았습니다. Ollama에서 받는 qwen3:8b·qwen3:14b는 같은 Q4_K_M이어도 CanRun이 올려 둔 파일과 만든 방식이 다르기 때문입니다. 어텐션 가중치 가운데 attn_v를 16비트로 두어서 파일이 몇 퍼센트 더 큽니다. 다른 파일로 잰 결과로는 CanRun 행을 제대로 확인할 수 없어서 카탈로그에는 넣지 않았습니다. 두 모델의 숫자는 아래에 링크한 원본 기록에 있습니다. 같은 기록에는 Gemma 4 E2B를 구글의 QAT Q4_0 파일로 한 번 돌려 본 결과도 있는데, 이 파일 역시 CanRun 목록에 없는 파일입니다.

파일이 같은지는 Ollama 레지스트리의 태그별 매니페스트와 CanRun이 쓰는 Hugging Face 파일을 비교해서 확인했습니다. Llama 3.1 8B와 Gemma 3 12B는 텐서마다 양자화 형식이 같고, 텐서를 모두 더한 크기도 같습니다. 다른 곳은 메타데이터뿐입니다. Gemma 3의 이미지 처리 부분은 Ollama가 별도 파일로 두는데, 글만 넣는 이번 측정에는 쓰이지 않습니다.

측정한 PC와 소프트웨어

• 그래픽카드: RTX 5060 Ti 16GB입니다. VRAM은 16GB, 메모리 대역폭은 448 GB/s입니다. CanRun은 이런 카드가 Windows 화면 출력도 맡는다고 보고, 그중 15.4GB를 쓸 수 있는 양으로 셉니다.
• Windows 11, NVIDIA 드라이버 591.86을 썼습니다.
• CPU는 6코어 데스크톱용 AMD Ryzen 5 9600X이고, 시스템 RAM은 32GB입니다.
• Ollama 버전은 0.40.7입니다. Ollama는 GGUF 파일을 안에 들어 있는 llama.cpp 코드로 돌리지만, 그 llama.cpp가 어느 빌드인지는 API가 알려 주지 않습니다. 그래서 여기서는 Ollama 버전만 적습니다.

스크립트는 모델마다 측정하는 동안 모델 전체가 VRAM에 올라가 있었다는 것도 기록했습니다.

측정 방법 — 내 PC에서 따라 해 보기

측정에 쓴 것은 CanRun 저장소에 있는 PowerShell 스크립트 scripts/own-bench/ollama-bench.ps1입니다. 켜져 있는 Ollama에 로컬 API로 요청을 보내고, 모델마다 다음 순서로 잽니다.

• 모델을 불러온 뒤 데우기용 요청을 한 번 보내고, 그 결과는 버립니다.
• 같은 긴 프롬프트로 세 번 요청합니다. 매번 첫 줄을 바꿔서 Ollama가 캐시해 둔 프롬프트를 다시 쓰지 못하게 합니다.
• 컨텍스트는 8k(num_ctx 8192), 새로 만드는 토큰은 최대 256개(num_predict 256), temperature는 0으로 둡니다. 생각 모드가 있는 모델은 생각 모드를 끕니다.
• 생성 속도는 eval_count를 eval_duration으로, 프롬프트 처리 속도는 prompt_eval_count를 prompt_eval_duration으로 나눠 구합니다. 둘 다 Ollama가 응답마다 붙여 주는 시간 정보입니다.
• 모델이 VRAM에 얼마나 올라갔는지도 적습니다. 일부가 시스템 RAM으로 넘어가면 속도가 크게 떨어지기 때문입니다.
• 다음 모델로 넘어가기 전에 모델을 메모리에서 내립니다.

내 PC에서 돌려 보려면 Ollama를 켜 두고 PowerShell을 엽니다.

git clone https://github.com/sejong00/canrun
cd canrun
powershell -ExecutionPolicy Bypass -File scripts\own-bench\ollama-bench.ps1 -Models llama3.1:8b,gemma3:12b -Pull -RemoveAfter

-Pull을 붙이면 아직 없는 모델을 내려받습니다. -RemoveAfter를 붙이면 스크립트가 내려받은 모델만 측정 뒤에 지웁니다. 원래 있던 모델은 그대로 둡니다. -Models를 빼면 이미 받아 둔 모델을 모두 잽니다. 결과는 data\own-bench\raw 아래 새 폴더에 저장됩니다. results.json에는 측정마다 한 줄씩, summary.csv에는 같은 내용이 표로 들어갑니다. system.json에는 그래픽카드·CPU 이름과 RAM 용량, Ollama 버전이 들어갑니다. 사용자 이름이나 파일 경로는 기록하지 않습니다.

이 글에 나온 측정의 원본 기록도 저장소에 올려 두었습니다. results.json과 system.json입니다.

CanRun 추정보다 빨랐던 이유

차이는 두 가지에서 왔습니다. 그중 CanRun이 틀린 것은 하나입니다.

첫째는 컨텍스트입니다. CanRun은 모든 모델을 8k 컨텍스트 기준으로 판정합니다. 대화가 길어질수록 토큰을 하나 만들 때마다 KV 캐시를 더 많이 읽어야 해서 느려집니다. 이번 측정은 650토큰쯤에서 끝났습니다. CanRun 공식으로 계산하면 그 깊이에서 Llama 3.1 8B는 8k일 때보다 5분의 1쯤 빠릅니다. Qwen3 8B는 그보다 조금 더 빠르고, Gemma 3 12B는 차이가 훨씬 작습니다. Gemma 3는 층 대부분이 짧은 구간만 보는 슬라이딩 윈도 방식이라 KV 캐시가 작기 때문입니다. 같은 공식은 이 카드의 4k·16k 공개 벤치마크와도 잘 맞았습니다. 공식이 예상한 두 깊이 사이의 감소 폭이 실제 결과와 비슷했습니다. 그러니 차이의 일부는 짧은 대화가 긴 대화보다 빠르다는 당연한 사실입니다.

둘째는 효율 계수입니다. 실제 깊이와 정확한 파일 크기를 공식에 넣어도, CanRun 추정은 Gemma 3 12B 결과보다 15%, 나머지 세 모델보다 23~24% 낮았습니다. NVIDIA 카드의 보정된 추정에 CanRun이 붙이는 ±12% 범위를 벗어납니다. CanRun은 NVIDIA 카드 전체에 효율 계수를 하나만 씁니다. 그 계수를 맞출 때 쓴 공개 결과에서도 대역폭이 작은 카드일수록 표기 대역폭에 더 가깝게 나왔습니다. RTX 4090 같은 빠른 카드보다 그랬고, RTX 5060 Ti 16GB는 느린 쪽에 속합니다. 2025년 8월 llama.cpp 빌드로 이 카드를 잰 공개 llama-bench 결과도 CanRun 추정보다 높았지만, 범위 안이었습니다. 훨씬 새 Ollama로 잰 이번 결과는 그보다 더 위에 있습니다.

둘째 차이 가운데 얼마가 카드 자체 때문이고 얼마가 새 소프트웨어 때문인지는 아직 가를 수 없습니다. Ollama와 llama-bench는 시간을 재는 방식도 조금 다릅니다. 이를 나누려면 같은 PC에서 지금 빌드의 llama.cpp로 llama-bench를 돌려야 하고, 아래 목록의 첫 번째가 그 측정입니다. 그때까지 CanRun 추정은 그대로 둡니다. PC 한 대의 결과에 맞춰 계산을 바꾸지는 않았습니다. 이 카드의 계수를 다시 맞추기로 하면 그 결정은 계산 방법 페이지에 적습니다.

이 카드에 들어가는 모델

아래 판정은 8k 컨텍스트, f16 KV 캐시, 시스템 RAM 32GB를 가정한 CanRun 계산입니다. ‘실측’ 라벨이 붙은 두 칸은 위에서 본 결과이고, 나머지는 라벨이 붙은 추정입니다.

14B 안팎까지의 dense 모델은 Q4_K_M으로 다 들어가고, 컨텍스트를 늘릴 여유도 넉넉합니다. Qwen3 14B는 모델 전체가 GPU에 올라가 쾌적하게 돌아갑니다. gpt-oss-20b도 다 들어가고, 표의 gpt-oss-20b 칸에는 이 카드에서 잰 공개 벤치마크 결과가 들어 있습니다.

26B~30B쯤부터는 16GB라는 한계가 판정을 가릅니다. Gemma 4 26B-A4B는 Q4_K_M이면 카드가 쓸 수 있는 양을 넘습니다. 그래서 CanRun은 전문가 일부를 시스템 RAM에 두고 계산하고, 원활하게 돌아간다고 봅니다(이론 추정). IQ4_XS로 받으면 카드에 다 올라가 쾌적하게 돌아갑니다(보정된 추정). 양자화마다 이 카드에서 어떻게 되는지는 아래 표에 있습니다.

dense 27B 모델은 사정이 다릅니다. Qwen3.8 27B를 Q4_K_M으로 받으면 가중치 일부가 시스템 RAM으로 넘어가 느리게 돌아갑니다. IQ4_XS로도 다 들어가지는 않지만, GPU에 남는 몫이 커서 원활하게 돌아갑니다. Qwen3 30B-A3B는 토큰마다 읽는 가중치가 적은 MoE 모델입니다. 전문가 일부를 시스템 RAM에 두어도 원활하게 돌아간다고 봅니다(이론 추정). 이 크기의 모델을 불러왔다면 ollama ps로 확인해 보세요. CanRun이 다 들어간다고 한 모델이라면 100% GPU가 나와야 합니다.

다음에 잴 것

• 같은 PC에서 llama-bench: 지금 빌드의 llama.cpp로 -d 0,8192를 붙여 잽니다. 한 번에 빈 컨텍스트와 CanRun 판정 기준인 8k 깊이를 함께 볼 수 있습니다. 새 소프트웨어의 영향과 카드 자체의 차이를 가르고, 8k 추정도 바로 확인할 수 있습니다.
• CanRun과 같은 파일로 Qwen3 8B·14B: Ollama는 Hugging Face의 GGUF를 바로 받을 수 있습니다. 예를 들어 ollama pull hf.co/unsloth/Qwen3-8B-GGUF:Q4_K_M으로 받으면 CanRun이 올려 둔 그 파일입니다. 이렇게 잰 결과는 위 두 모델처럼 카탈로그에 넣을 수 있습니다.
• gpt-oss-20b: 조합 페이지의 공개 결과가 이 PC에서도 나오는지 봅니다.
• 전문가를 시스템 RAM에 두는 MoE 모델: Qwen3 30B-A3B 같은 모델입니다. 이 구성은 이론 추정 라벨이 붙어 있어 직접 잰 결과가 가장 필요합니다.
• 한국 모델: Kanana 1.5 8B처럼 공개 벤치마크가 거의 없는 모델입니다.

이 숫자는 얼마나 확실한가

‘실측’ 라벨은 같은 카드·모델·양자화의 벤치마크 결과가 있다는 뜻입니다. 이 글의 두 결과는 CanRun이 직접 재고 원본 기록까지 공개한 경우입니다. 그래도 PC 한 대의 결과입니다. 같은 RTX 5060 Ti 16GB라도 드라이버가 다르거나, 공장 오버클럭 제품이거나, 다른 프로그램이 GPU를 쓰고 있거나, 대화가 길면 다른 값이 나옵니다. 8k를 꽉 채운 대화는 이번 측정보다 느립니다. 모델마다 세 번 잰 값은 서로 1% 안쪽으로 붙어 있었습니다. 같은 PC에서 다시 재도 크게 달라지지 않는다는 뜻이고, 위에 적은 조건이 더 큰 차이를 만듭니다.

결과가 없는 칸의 속도는 범위와 신뢰 라벨이 붙은 CanRun 추정입니다. 보정된 추정의 범위는 NVIDIA·AMD 카드에 dense 모델을 다 올릴 때 ±12%, 그 밖의 구성에서 ±20%입니다. 이론 추정은 ±30%입니다. 이번 측정만 놓고 보면, 이 카드에서는 짧은 대화일 때 보정된 추정의 범위가 실제 속도보다 낮게 잡혀 있는 것으로 보입니다. 판정 기준은 아래와 같습니다.

자주 묻는 질문

Ollama로 잰 속도가 CanRun 추정보다 빠른 이유는 무엇인가요?

주로 컨텍스트와 효율 계수 때문입니다. 이번 측정은 프롬프트가 짧았고, CanRun은 더 느린 8k 꽉 찬 컨텍스트를 기준으로 판정합니다. 같은 깊이로 맞춰도 이 카드에서 CanRun 추정은 15~24% 낮았습니다. 보정 범위를 벗어난 차이라, NVIDIA 카드 전체에 하나만 쓰는 효율 계수와 새 소프트웨어 쪽에 원인이 있어 보입니다.

Ollama의 Q4_K_M은 Hugging Face의 Q4_K_M과 같은 파일인가요?

늘 같지는 않습니다. Ollama의 Llama 3.1 8B와 Gemma 3 12B는 CanRun이 쓰는 Hugging Face 파일과 텐서 하나하나까지 같았습니다. 하지만 Qwen3 8B와 Qwen3 14B는 attn_v 가중치를 16비트로 두어 몇 퍼센트 더 큽니다. CanRun 같은 사이트와 속도를 비교하려면 어느 파일인지부터 확인하세요. ollama show <모델>로 양자화 이름을 볼 수 있고, hf.co/<저장소>:<양자화> 형식으로 받으면 Hugging Face의 그 파일이 그대로 옵니다.

스크립트는 8192로 설정했는데 결과에는 왜 512 컨텍스트라고 나오나요?

num_ctx 8192는 Ollama가 컨텍스트용 메모리를 얼마나 잡아 둘지를 정할 뿐입니다. 속도는 그중 얼마나 채웠는지에 달려 있고, 이번 측정은 천 토큰도 채우지 않았습니다. CanRun은 이렇게 짧은 프롬프트로 잰 결과를 llama-bench의 짧은 기본 테스트와 같은 방식으로 512로 적습니다.

내가 잰 결과도 보낼 수 있나요?

보낼 수 있습니다. 스크립트를 돌린 뒤 만들어진 summary.csv와 system.json을 문의 페이지로 보내거나, GitHub 저장소에 이슈로 올려 주세요. 측정할 때 GPU를 쓰는 다른 프로그램이 있었는지도 알려 주시면 좋습니다. 결과는 CanRun 목록과 같은 파일로 잰 경우에만 페이지에 넣습니다.

출처

• 이 글에 나온 측정의 원본 기록: 측정마다 모델 digest와 파일 크기를 함께 기록
• CanRun 측정 스크립트: 이번 측정에 쓴 PowerShell 스크립트
• Ollama API 문서: /api/generate 응답의 eval_count·eval_duration·prompt_eval_count·prompt_eval_duration, /api/ps의 size_vram
• Ollama 레지스트리 매니페스트 llama3.1:8b·gemma3:12b·qwen3:8b·qwen3:14b: 태그마다 모델 파일과 그 크기
• bartowski/Meta-Llama-3.1-8B-Instruct-GGUF·bartowski/google_gemma-3-12b-it-GGUF·unsloth/Qwen3-8B-GGUF·unsloth/Qwen3-14B-GGUF: CanRun이 올려 둔 Q4_K_M 파일
• Hugging Face 문서: Hub의 GGUF 모델을 Ollama로 쓰기: hf.co/<저장소>:<양자화> 형식
• llama.cpp 토론 #15013: NVIDIA CUDA 성능: 2025년 8월 빌드로 잰 RTX 5060 Ti 16GB의 Llama 2 7B 공개 결과