Ollama не использует GPU: как найти причину и проверить исправление

Как убедиться, что проблема именно в размещении модели?

Маршрут проверки: запрос → точный тег модели → ваш GPU и драйвер → Ollama на хосте или в контейнере → ollama ps → серверный журнал → повторный запрос. Начните с небольшой тестовой модели, чтобы отличить обнаружение видеокарты от нехватки памяти на крупной модели. В официальной библиотеке есть тег qwen3:0.6b; он выбран только для диагностики, не как гарантированный минимум памяти или оценка качества s8s2.

После установки и запуска сервера Ollama в терминале ОС или в том окружении, где работает ваш клиент, выполните s7s8:

ollama -v
ollama run qwen3:0.6b "Ответь одним словом: столица Франции?"
ollama ps

Сразу после ответа смотрите PROCESSOR: 100% GPU означает, что модель полностью загружена на GPU; 100% CPU — в системной памяти; смешанный процент означает распределение. Пустой ollama ps не доказывает CPU fallback: в нём перечислены только ещё загруженные модели. Повторите запрос и проверку без паузы; если клиент обращается к другой Ollama (контейнер или удалённый сервер), запускайте ps именно там. Показатель PROCESSOR не идентифицирует библиотеку ускорения, не замеряет скорость и не доказывает, что конкретный запрос исполнялся только на одном GPU s2s3.

Зафиксируйте ОС, GPU, драйвер, ollama -v, точный тег, PROCESSOR и фрагмент лога без пользовательских запросов и токенов. Пока этих данных нет, ответ «GPU не используется» — только гипотеза. Если маленькая модель показывает 100% GPU, а крупная — смешанное размещение, начните с оценки памяти и контекста, а не с переустановки драйвера s2.

Где посмотреть ошибку обнаружения GPU?

Журнал принадлежит процессу сервера. На Linux при штатном systemd-сервисе используйте journalctl -u ollama --no-pager --follow --pager-end; на macOS-приложении — ~/.ollama/logs/server.log; в Windows — server.log в %LOCALAPPDATA%\Ollama; в контейнере — docker logs <имя-контейнера>. Если ollama serve запущена вручную, ищите сообщения в её терминале. Команда ollama ps и nvidia-smi отвечают на разные вопросы: первая — о размещении модели в сервере, вторая — о состоянии NVIDIA/драйвера, а не о маршруте запроса s3s5s6.

journalctl -u ollama --no-pager --follow --pager-end
nvidia-smi

На Windows перед экспериментом с переменными завершите приложение Ollama через значок в трее и запустите его заново: новое окно PowerShell само по себе не меняет окружение уже работающего сервера. На Linux systemctl edit ollama.service и перезапуск службы изменяют именно серверный процесс. Сохраняйте исходные значения переменных и не делайте такие изменения посреди чужого активного сеанса s2s5s6.

GPU виден системе, но Ollama его не выбирает: что проверить?

1. Совместимость и драйвер. Для NVIDIA сверьте точную карту/compute capability и требования драйвера в документации вашей версии Ollama, затем проверьте nvidia-smi на хосте. Для AMD сверяйте карту и путь ROCm в отдельной таблице: закреплённая Linux-документация Ollama указывает драйвер ROCm v7, а наличие AMD GPU вообще не гарантирует ROCm-совместимость. Дополнительный путь Vulkan существует на Windows/Linux при доступном backend и драйвере. На Apple Silicon Ollama использует Metal, а не CUDA/ROCm. Для Intel Arc начинайте с отдельной проверки Vulkan-драйвера, не переносите на неё инструкции ROCm s1s5.
2. Исключающие переменные. Для NVIDIA Ollama допускает CUDA_VISIBLE_DEVICES, для AMD — ROCR_VISIBLE_DEVICES, для Vulkan — GGML_VK_VISIBLE_DEVICES. Неверный ID или -1 может скрыть карту. OLLAMA_VULKAN=0 отключает Vulkan GPU; это не команда «включить ускорение». Если настроена переменная OLLAMA_LLM_LIBRARY с принудительной CPU-библиотекой, уберите экспериментальное переопределение и вернитесь к автоматическому выбору, затем перепроверьте журнал. Не присваивайте всем системам GGML_VK_VISIBLE_DEVICES=1: номер нужно взять из обнаруженных устройств s1s3.
3. Память и конкурирующие загрузки. ollama ps помогает увидеть другие загруженные модели. FAQ Ollama связывает возможность параллельной загрузки с доступной памятью, а увеличение контекста/числа параллельных запросов — с дополнительным расходом памяти. Сравните тест маленькой и большой модели при одинаковых настройках и уменьшите ненужный контекст только для контролируемого эксперимента. Размер файла весов сам по себе не даёт минимальные RAM/VRAM: учитывайте контекст и рабочие буферы; не обещайте, что смена кванта гарантированно исправит обнаружение GPU s2.
4. Отдельный случай после сна Linux/NVIDIA. Документация Ollama описывает сбой обнаружения после suspend/resume и предлагает перезагрузку модуля nvidia_uvm (sudo rmmod nvidia_uvm && sudo modprobe nvidia_uvm). Делайте это только если журнал и время сбоя согласуются со сценарием, предварительно завершив процессы GPU и понимая, что операция может сорвать чужие вычисления. Это не универсальное лечение для AMD, Intel и Windows s1s3.

Не задавайте вслепую HSA_OVERRIDE_GFX_VERSION для неподдержанной AMD-карты: документация описывает экспериментальное принудительное сопоставление LLVM target, а не совместимость или безопасный штатный ремонт. Сначала сохраните ошибку обнаружения и точную конфигурацию s1.

Если Ollama работает в Docker, проверка другая?

Да. Официальная базовая команда Docker помечена CPU only. Для NVIDIA Ollama документирует NVIDIA Container Toolkit, настройку Docker runtime и запуск с --gpus=all. Для AMD вариант ollama/ollama:rocm передаёт /dev/kfd и /dev/dri; Linux-права к этим устройствам могут потребовать группы video/render или дополнительных --group-add с реальными числовыми GID. Не копируйте пример AMD на Intel: для Vulkan смотрите устройство и требования отдельного GPU-пути s4s3s1.

Сначала проверьте GPU на хосте, затем в контейнере. Для NVIDIA документация Ollama предлагает диагностический docker run --gpus all ubuntu nvidia-smi: если он не видит карту, исправлять модель Ollama преждевременно. Смотрите docker logs ollama (или фактическое имя) и запускайте docker exec ollama ollama ps, чтобы не принять ответ другого процесса за работу контейнера. Последняя команда показывает только ещё загруженные модели; сначала отправьте запрос через тот же сервер. Ollama отдельно описывает случай, когда GPU сначала работает в контейнере, а затем переключается на CPU после ошибки discovery; изменение cgroup-настроек Docker — потенциально общесистемная операция, не первый диагностический шаг s3s4s2.

На macOS Docker Desktop закреплённый FAQ не обещает GPU passthrough для Ollama в контейнере. Если нужен Metal, проверяйте нативное macOS-приложение Ollama, а не пытайтесь включить NVIDIA-флаг --gpus all в Docker Desktop s2s1.

Как понять, что исправление сработало, и что делать потом?

Сделайте тот же короткий запрос к тому же серверу с тем же тегом; сразу запишите новый ollama ps и соответствующий журнал. Результат 100% GPU у тестовой модели подтверждает её размещение на GPU в этом запуске, а не минимальную VRAM для любой модели или прирост скорости; смешанное размещение означает, что часть осталась в системной памяти. Если по-прежнему 100% CPU, приложите версии ОС/драйвера/Ollama, точный способ установки, выбранный GPU, переменные видимости устройств и очищенный лог к заявке о неисправности. Здесь приведены ожидаемые критерии проверки, не результаты собственного прогона Modelium s2s3.

Если тестовая модель переехала на GPU, а ваша рабочая — нет, переходите к оценке памяти модели и контекста. Для первоначальной установки пригодится гайд Ollama; для специфических веток — AMD Radeon и Intel Arc s1s2.