Ollama가 GPU를 안 쓴다면? Linux·Windows·WSL에서 고치기

TL;DR

모델을 로드한 상태로 ollama ps를 실행하세요: PROCESSOR 열이 진실을 말합니다. 100% GPU면 GPU는 정상이고, 더 읽을 필요 없습니다. 40%/60% CPU/GPU 같은 분할은 모델이 VRAM에 다 들어가지 못했다는 뜻 — 더 작은 quant를 쓰세요. 100% CPU면 Ollama가 쓸 수 있는 GPU를 찾지 못한 것입니다: 대개 오래된 드라이버, 빠진 그룹 멤버십(리눅스의 AMD), 고정된 OLLAMA_LLM_LIBRARY, 또는 GPU 접근 없이 시작된 컨테이너 중 하나입니다. 로그가 지목하는 원인을 고치세요. 원인은 다섯 개쯤 안 됩니다.

Ollama가 실제로 GPU를 쓰고 있는지 확인하려면?

명령 두 개면 추측이 필요 없습니다.

# 한 터미널에서: 모델 로드
ollama run llama3.2 "hello"

# 다른 터미널에서: 어디서 도는지 확인
ollama ps

NAME            ID          SIZE     PROCESSOR        UNTIL
llama3.2:latest a80c4de17cd9 3.3 GB   100% GPU         4 minutes from now

PROCESSOR 열의 상태는 셋입니다:

• 100% GPU — 모든 레이어가 오프로드됨. 끝.
• 48%/52% CPU/GPU — 부분 오프로드. GPU는 일하고 있지만 모델과 컨텍스트가 VRAM에 다 들어가지 못한 것입니다. 아래 VRAM 섹션을 보세요.
• 100% CPU — 추론이 CPU에서 돌고 있습니다. GPU가 감지되지 않았거나 의도적으로 꺼져 있는 상태입니다.

이어서 서버 로그를 읽으세요. 시작 시점에 Ollama가 실제로 찾은 하드웨어를 이름으로 적어 둡니다:

journalctl -u ollama --no-pager | grep -i "inference compute"

정상인 NVIDIA 머신에서는 이런 줄이 보입니다:

inference compute id=GPU-xxxx library=CUDA compute=8.9 driver=12.4 name=NVIDIA GeForce RTX 4070

그런 줄이 아예 없거나 CPU 전용 폴백 메시지로 끝난다면, 문제를 찾은 겁니다. 이 글의 나머지는 다섯 가지 원인입니다. 가능성 높은 순서입니다.

Ollama가 “no compatible GPU discovered”라고 말하는 이유는?

NVIDIA에서는 CUDA가 아니라 드라이버가 범인인 경우가 대부분입니다. Ollama는 자체 CUDA 런타임 라이브러리를 갖고 오므로 CUDA 툴킷이 설치돼 있을 필요는 없습니다 — 다만 번들된 런타임이 대화할 만큼 새 드라이버는 필요합니다. nvidia-smi가 돌아가는 건 증거가 아닙니다; 드라이버가 존재한다는 것만 증명하지, 충분히 새롭다는 건 증명하지 않습니다.

nvidia-smi --query-gpu=driver_version --format=csv,noheader

버전이 몇 년 된 것이면 업데이트하고 재부팅하세요:

# Debian/Ubuntu 계열
sudo apt install nvidia-driver-570
# Arch 계열
sudo pacman -S nvidia

드라이버 업데이트 후에는 Ollama 서비스를 재시작해 디바이스를 다시 감지하게 하세요 — 감지는 요청마다가 아니라 시작 시점에 한 번 일어납니다:

sudo systemctl restart ollama

로그가 이제 GPU를 library=CUDA와 함께 출력한다면 끝입니다. 여전히 거부한다면 OLLAMA_LLM_LIBRARY가 어디에도 설정돼 있지 않은지 확인하세요 — 아래 “업데이트 이후” 섹션을 보세요.

Ollama가 모델 일부에만 GPU를 쓰는 이유는?

부분 오프로드는 버그가 아니라 산수입니다: 모델 가중치에 컨텍스트 창의 KV 캐시를 더한 것이 VRAM에 들어가야 합니다. Q4의 7B 모델은 대략 4–5 GB; 컨텍스트를 8K로 주면 캐시가 그 위에 얹힙니다. 8 GB 카드에서는 뭔가가 CPU에 남아야 하고, ollama ps가 그 분할을 보여줍니다.

격차를 좁히는 방법 셋, 싼 것부터:

1. 더 작은 quant. Q8에서 Q4로 내리면 가중치 크기가 절반이 되고, 품질 비용은 적당합니다. 트레이드오프는 GGUF quantization levels explained에 정리돼 있습니다.
2. 더 짧은 컨텍스트. num_ctx가 캐시 크기를 지배합니다. 8 GB 카드에서 32K 컨텍스트는 대부분의 레이어가 CPU에 남는다는 뜻입니다.
3. 더 적은 GPU 레이어. num_gpu 옵션은 오프로드할 레이어 수를 제한합니다. 레이어 수보다 낮게 설정하면 분할이 보장됩니다 — 누군가 Modelfile이나 API 호출에 넣어 뒀다면 빼세요.

역방향 함정도 알아두세요: 100% GPU로 나오는데 기대보다 느린 GPU는 시스템 RAM으로 스와핑 중일 수 있습니다. ollama ps의 SIZE를 실제 VRAM과 대조하세요.

Ollama가 AMD GPU를 안 쓰는 이유는?

리눅스의 AMD는 세 가지가 필요하고, 셋 모두 확인 가능합니다:

1. 빌드에 ROCm 지원이 포함돼 있는가. 공식 리눅스 설치 스크립트는 ROCm 빌드를 포함합니다. 서버가 감지한 것을 확인하세요:

journalctl -u ollama --no-pager | grep -iE "rocm|inference compute"

2. 그룹 멤버십. ROCm 런타임은 /dev/kfd와 /dev/dri 접근이 필요하고, 이는 render와 video 그룹을 의미합니다:

sudo usermod -aG render,video $USER
# 로그아웃 후 재로그인, 그다음:
sudo systemctl restart ollama

이 그룹 하나가 빠진 것만이 모든 포럼의 “Ubuntu에서 Ollama가 GPU를 안 씀” 글의 최다 원인이고, 드라이버를 재설치해도 사라지지 않습니다 — 문제는 애초에 드라이버가 아니었으니까요.

3. 지원되는 GPU — 또는 우회. 지원되지 않는 RDNA2 소비자 카드(gfx1031, gfx1032)는 ROCm 스택이 정상이어도 감지에 실패합니다. 표준 우회법은 호환되는 타깃을 자칭하는 것입니다:

sudo systemctl edit ollama

[Service]
Environment="HSA_OVERRIDE_GFX_VERSION=10.3.0"

그다음 sudo systemctl restart ollama. 공식 지원은 아니지만 널리 쓰이는 오버라이드입니다; 말썽을 부리면 지우면 공식 지원 영역으로 돌아갑니다. 자동 감지와 싸우느니 백엔드를 직접 통제하고 싶다면, 그것이 llama.cpp vs Ollama가 다루는 핵심 차이입니다.

Windows에서 AMD 지원은 더 좁습니다 — 설치가 깨졌다고 단정하기 전에 Ollama의 지원 GPU 목록에서 카드를 확인하세요.

업데이트 후에 Ollama가 GPU 쓰기를 멈췄다면?

업데이트는 셋 중 하나를 바꿉니다. 가능성 순서입니다:

1. 고정된 백엔드 라이브러리. OLLAMA_LLM_LIBRARY는 특정 러너(cuda_v11, rocm, 심지어 cpu)를 강제합니다. 디버깅용으로 만들어진 것인데 자동 감지를 조용히 무시하고, 이유가 잊힌 지 오래된 뒤에도 셸 프로필과 서비스 파일에 남습니다. 찾아서 지우세요:

systemctl show ollama --property=Environment | grep -i llm_library
env | grep OLLAMA

2. 드라이버가 런타임 뒤처짐. Ollama 업그레이드는 더 새로운 CUDA 런타임을 실어 옵니다; 드라이버는 당신이 움직이기 전까지는 움직이지 않습니다. 위 드라이버 섹션과 같은 해결책입니다.
3. 서비스가 컨테이너고 플래그가 사라짐. GPU 플래그 없이 재생성된 컨테이너는 CPU 전용 컨테이너입니다. NVIDIA의 실행법은:

docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 ollama/ollama

AMD 컨테이너라면 같은 자리에 디바이스 패스스루와 그룹 추가가 옵니다:

docker run -d --device=/dev/kfd --device=/dev/dri 
  --group-add video --group-add render 
  -v ollama:/root/.ollama -p 11434:11434 ollama/ollama

--gpus=all이 없으면 GPU도 없습니다 — Docker는 관대할 이유가 없습니다.

Ollama는 WSL2에서 동작하나?

네, 올바른 드라이버가 올바른 자리에 있다면요: Windows용 NVIDIA 드라이버를 설치하세요, 배포판 안에 리눅스용 드라이버는 절대 — WSL 안의 드라이버는 CUDA 패스스루를 고치는 게 아니라 부숩니다. 이어서 WSL 자체를 업데이트하고 패스스루 디바이스가 있는지 확인하세요:

wsl --update   # PowerShell에서
ls /dev/dxg    # WSL 내부 — GPU 사용에 반드시 존재해야 함

/dev/dxg가 있고 Windows 드라이버가 최신이면, WSL2의 Ollama는 네이티브 설치처럼 GPU에 오프로드합니다. 우회 자체를 건너뛰고 싶다면 Windows 빌드의 Ollama가 네이티브로 돌며 WSL 없이 GPU를 봅니다.

Ollama에 GPU는 꼭 필요한가?

아니요 — CPU 전용 실행도 기능은 동일합니다, 느릴 뿐이고, 빠른 CPU의 작은 모델이라면 충분히 쓸 만합니다. Apple Silicon에서는 질문 자체가 사라집니다: Metal이 통합 메모리를 자동으로 쓰고, 유일한 제한은 모델에 얼마나 많은 RAM을 내어줄 의향이 있는가입니다.

5분 체크리스트

증상	유력한 원인	해결
ollama ps에서 100% CPU, NVIDIA 카드는 있음	번들 CUDA에 비해 드라이버가 너무 오래됨	드라이버 업데이트, 재부팅, 서비스 재시작
100% CPU, 리눅스의 AMD	빠진 render/video 그룹	usermod -aG render,video, 재로그인
100% CPU, 미지원 AMD 카드	ROCm이 gfx 타깃을 거부	HSA_OVERRIDE_GFX_VERSION=10.3.0
40%/60% CPU/GPU 분할	모델 + 컨텍스트가 VRAM 초과	더 작은 quant 또는 더 짧은 num_ctx
어제는 GPU, 오늘은 CPU	고정된 OLLAMA_LLM_LIBRARY 또는 오래된 드라이버	env 변수 찾아 제거; 드라이버 업데이트
네이티브는 GPU, Docker는 CPU	GPU 플래그 없이 시작된 컨테이너	--gpus=all(또는 AMD 디바이스)로 재생성

이 순서로 확인하세요: 상태는 ollama ps, 감지 목록은 서버 로그, 그다음은 표. 열 번 중 아홉은 로그 줄이 이미 어느 칸에 있는지 알려준 상태입니다.