모델은 답변하는데 CPU만 바쁘고 GPU 사용률이 낮다면, 드라이버를 다시 설치하기 전에 ollama ps부터 확인해 보세요. GPU가 안 보이는 상황과 모델 일부가 CPU에 올라가는 상황은 원인이 다릅니다. 짧은 요청이 끝난 뒤의 GPU 사용률만 보고 CPU 실행이라고 판단하기도 쉬워요.
아래 절차는 Linux와 NVIDIA GPU 기준입니다. AMD ROCm, Apple Metal은 장치 확인 도구와 지원 조건이 다릅니다. 여기서는 운영체제의 장치 인식 → Ollama의 적재 상태 → 서버 실행 환경 순서로 확인합니다.
이 글의 목차
호스트가 GPU를 볼 수 있는지 먼저 확인합니다
nvidia-smi
nvidia-smi -L
ollama --versionnvidia-smi가 실행되지 않거나 드라이버와 통신할 수 없다는 오류가 나면 호스트의 드라이버·커널 모듈·장치 할당부터 확인합니다. 가상머신이라면 GPU가 게스트에 전달됐는지도 봅니다. 이 단계가 실패한 상태에서 Ollama 모델 설정만 바꿔서는 원인이 좁혀지지 않습니다.
GPU가 표시되면 이름, 드라이버 버전, 총 VRAM, 다른 프로세스의 메모리 사용량을 기록합니다. nvidia-smi 상단의 CUDA 버전은 드라이버가 지원하는 CUDA 버전을 나타내며, 그 숫자만으로 호스트에 같은 버전의 CUDA Toolkit이 설치됐다고 판단하지 않습니다.
GPU 모델과 드라이버가 현재 Ollama에서 지원되는지는 Ollama 하드웨어 지원표와 대조합니다. 지원 조건은 버전에 따라 달라질 수 있어요. 이 글은 특정 드라이버 번호를 모든 GPU의 공통 해법으로 제시하지 않습니다.
모델이 적재된 동안 ollama ps를 봅니다
먼저 ollama list에서 설치된 모델 이름을 확인합니다. 아래 MODEL_NAME에는 목록에 있는 이름과 태그를 그대로 넣으세요. 첫 번째 터미널에서 실행한 뒤, 모델이 적재되어 있는 동안 두 번째 터미널에서 상태를 조회합니다.
ollama list
# MODEL_NAME을 설치된 모델 이름으로 바꿉니다.
ollama run MODEL_NAMEollama ps
nvidia-smi| 확인한 상태 | 판단과 다음 확인 |
|---|---|
ollama ps에 모델이 없음 | 조회한 서버가 같은지, 적재가 끝났거나 모델이 이미 해제됐는지 확인 |
PROCESSOR가 100% GPU | GPU에 적재됨. 처리량이 낮은 원인은 요청 길이·적재 시간·동시 작업 등 별도 조사 |
100% CPU | 지원 GPU·드라이버·서버 환경 변수·장치 접근 여부 확인 |
| CPU와 GPU가 함께 표시 | 메모리 여유·모델 크기·컨텍스트 설정을 확인 |
PROCESSOR는 모델 적재가 CPU와 GPU에 어떻게 나뉘는지 보는 값입니다. 실시간 GPU 연산 사용률과 같은 숫자가 아니에요. 일부가 CPU에 적재됐다는 이유만으로 GPU 인식 실패라고 부르면 다음 조치가 어긋날 수 있습니다.
CLI의 OLLAMA_HOST가 원격 서버를 가리킨다면 ollama ps는 원격 상태를, 로컬의 nvidia-smi는 내 컴퓨터 상태를 보여줍니다. Docker에서도 호스트에 설치한 CLI와 컨테이너의 서버가 서로 다른 대상일 수 있습니다. 같은 서버를 관찰하는지부터 맞춰 주세요.
서버 로그에서 장치 검색과 메모리 적재를 확인합니다
systemd 서비스로 설치했다면 다음 명령으로 확인합니다. 수동으로 ollama serve를 실행했다면 그 터미널의 로그를, 컨테이너라면 docker logs를 봅니다. 설치 방식에 맞는 로그 한 곳을 선택하면 됩니다.
systemctl status ollama --no-pager
sudo journalctl -u ollama --since '30 minutes ago' --no-pager요청 시각 주변에서 GPU 검색 실패, 드라이버 초기화 오류, 사용 가능한 메모리와 모델 적재 관련 메시지를 확인합니다. 로그 문구는 버전마다 달라질 수 있으므로 특정 한 줄이 없다는 이유로 GPU 미사용을 확정하지 않습니다. ollama ps와 함께 판단합니다.
진단 자료를 남길 때는 GPU 모델·드라이버·Ollama 버전, 모델 이름·양자화, 컨텍스트 길이, 같은 시각의 로그를 묶어 두세요. 모델이 바뀌거나 다른 GPU 작업이 추가되면 같은 서버에서도 결과가 달라질 수 있습니다.
셸에 설정한 값이 서비스에 적용됐는지 확인합니다
systemctl cat ollama
systemctl show ollama --property=Environment --no-pager터미널에서 export한 환경 변수는 이미 실행 중인 systemd 서비스에 자동으로 들어가지 않습니다. 서비스의 drop-in 설정에 CUDA_VISIBLE_DEVICES가 잘못 지정되어 있는지, 테스트하며 강제한 백엔드 설정이 남았는지 확인합니다. 예를 들어 CUDA_VISIBLE_DEVICES=-1은 GPU를 사용하지 않게 만드는 값입니다.
환경 변수와 유닛 파일 출력에는 프록시 인증 정보 등 비밀 값이 섞일 수 있으므로 외부에 그대로 공유하지 않습니다. 문제를 만든 설정이 확인되면 해당 drop-in 파일의 해당 항목만 고칩니다. 모든 override를 지우면 모델 저장 경로나 서버 주소 설정도 함께 사라질 수 있어요.
변경이 필요한 경우 sudo systemctl edit ollama로 설정을 수정한 뒤 다음을 실행합니다. 서비스 재시작은 진행 중인 요청을 끊을 수 있으므로 사용 중인 작업을 먼저 확인합니다.
sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo journalctl -u ollama -n 80 --no-pagerDocker에서는 GPU를 컨테이너에도 전달해야 합니다
호스트의 nvidia-smi 성공과 컨테이너의 GPU 접근 성공은 별개입니다. NVIDIA Container Toolkit과 Docker 런타임 설정이 준비되어 있는지 확인한 뒤, 실제 Ollama 컨테이너가 GPU 장치를 요청했는지 봅니다. 아래 ollama는 실제 컨테이너 이름으로 바꿉니다.
docker inspect ollama --format '{{json .HostConfig.DeviceRequests}}'
docker logs --since 30m --tail 150 ollama
docker exec ollama ollama psDeviceRequests가 비어 있다면 일반적인 --gpus 방식으로 장치를 요청했는지부터 확인합니다. 다른 장치 전달 방식도 있으므로 이 값 하나로 모든 구성을 단정하지는 않습니다. 공식 Docker 설치 문서의 GPU 실행 예시와 현재 배포 설정을 대조하세요.
이미 만들어진 컨테이너를 재시작하는 것만으로 GPU 요청 설정이 추가되지는 않습니다. 설정을 반영해 재생성하기 전 모델 데이터 볼륨이 유지되는지 확인합니다. GPU 인식 문제 하나를 해결하기 위해 Docker 전체의 cgroup 드라이버를 바꾸거나 호스트 드라이버를 무작정 재설치하는 작업부터 시작하지 않습니다.
메모리 여유와 요청 조건을 바꿔 비교합니다
GPU가 인식되는데 일부가 CPU에 적재되면, 다른 작업의 VRAM 사용량과 모델·컨텍스트 설정을 봅니다. 우선 이미 설치된 더 작은 모델이나 짧은 컨텍스트로 같은 요청을 비교하면 원인을 좁히기 편해요. 메모리에는 모델 가중치 외에도 컨텍스트와 실행에 필요한 공간이 들어갑니다.
GPU를 사용하는 다른 프로세스를 임의로 종료하지 않습니다. 작업 소유자와 조정하고, 바꾼 조건을 하나씩 기록합니다. 모델 파일 크기만 보고 VRAM에 전부 들어갈 것이라고 판단하지 않는 이유는 토큰·컨텍스트·양자화와 메모리 사용량에서 이어서 볼 수 있습니다.
절전 복귀 후에만 문제가 발생한다면 그 시점의 드라이버 로그도 남깁니다. 공식 문서에 있는 모듈 재적재는 다른 GPU 작업에 영향을 줄 수 있으므로, 사용 중인 프로세스와 정비 시간을 확인한 뒤 검토합니다. 이 글은 공식 문서에 근거한 점검 절차이며 실제 GPU 장비의 장애 재현이나 성능 측정 결과를 제시하지 않습니다.
