«Модель отвечает медленно» — жалоба, за которой стоит шесть-семь разных причин с разными решениями. Совет «возьмите модель поменьше» решает одну из них, а в остальных случаях означает, что вы отказались от работающей модели, не разобравшись.
Разбираться нужно по дереву: каждый узел — один замер, который отсекает часть гипотез. Порядок узлов не случаен, они выстроены от самых частых причин к самым редким.
#Быстрая проверка
Две команды перед тем, как что-либо менять.
ollama ps
nvidia-smi --query-gpu=memory.used,memory.total,utilization.gpu --format=csv
Первая показывает, на чём считается модель. Вторая — сколько видеопамяти занято и загружена ли карта. В сумме они закрывают примерно две трети обращений: в большинстве случаев ответ виден уже здесь.
#Узел 1: медленно ли на самом деле
Прежде чем искать причину, убедитесь, что проблема есть. Разделите пропускную способность памяти вашего устройства на вес модели в гигабайтах и умножьте на 0,5 — это ориентир достижимой скорости.
Для карты с 360 ГБ/с и модели 8B в Q4_K_M весом 4,9 ГБ получится около 36 токенов в секунду. Если вы наблюдаете 30 — всё в порядке, вы упёрлись в физику, и никакие настройки этого не изменят.
Что считать нормой в человеческих терминах — в материале о том, сколько токенов в секунду это нормально.
Если результат близок к расчёту — диагностика окончена, дальше только смена модели или железа. Если заметно ниже — идём к узлу 2.
#Узел 2: все ли слои на видеокарте
Самая частая причина с большим отрывом.
ollama ps
Колонка PROCESSOR: значение 100% GPU — хорошо, любое другое — найдена причина. В llama.cpp то же самое видно в логе запуска строкой о числе выгруженных слоёв.
Почему это стоит так дорого: уже десятая часть слоёв на процессоре съедает около трети скорости, половина — три четверти. Подробности — в материале о выгрузке слоёв в оперативную память.
Если часть слоёв на процессоре — идём к узлу 3, чтобы понять почему. Если все на видеокарте — к узлу 5.
#Узел 3: чем занята видеопамять
nvidia-smi
Смотрите не только суммарную занятость, но и список процессов внизу вывода. Типичные потребители: браузер с аппаратным ускорением, ранее загруженная и не выгруженная модель, зависший процесс после аварийного завершения.
Автоподбор числа слоёв делается в момент загрузки модели по фактически свободной памяти. Если в этот момент было занято два гигабайта, часть слоёв ушла на процессор и останется там до перезагрузки модели — даже если память освободилась через минуту.
Решение: освободить память, выгрузить модель и загрузить заново.
#Узел 4: не переполнена ли память
Отдельный случай, который выглядит иначе: ошибки нет, все слои формально на видеокарте, но скорость упала в разы.
Проверка — занятость близка к 100% от общего объёма. При переполнении драйвер начинает вытеснять данные в системную память прозрачно для приложения. Ошибки не будет, будет обвал производительности.
Решение: освободить 10–15% видеопамяти, сократив контекст или взяв квантизацию пожёстче. Работать с памятью, заполненной под завязку, и медленно, и нестабильно.
#Узел 5: какой выставлен контекст
Если все слои на видеокарте и памяти хватает, следующий подозреваемый — размер контекста.
Он влияет двояко. Во-первых, занимает память, из-за чего автоподбор мог отдать слои процессору (см. узел 2). Во-вторых, замедляет генерацию сам по себе: чем длиннее накопленный кэш, тем больше данных читается на каждом новом токене. Разговор на двадцать тысяч токенов идёт заметно медленнее, чем на двух тысячах, на той же модели и том же железе.
Проверка: замерьте на коротком и длинном контексте:
llama-bench -m model.gguf -ngl 99 -p 512,8192 -n 128
Решение: если проседание сильное, сократите контекст до реально необходимого и включите квантизацию KV-кэша. Механику разбирает материал о том, почему большой контекст съедает видеопамять.
#Узел 6: медленно генерация или медленно первый токен
Две разные величины, и жалоба «тормозит» относится к ним примерно поровну.
llama-bench -m model.gguf -ngl 99 -p 512 -n 128
Вывод содержит pp (обработка запроса) и tg (генерация). Если низкое tg — вы в области пропускной способности памяти, вернитесь к узлу 1. Если низкое pp при нормальном tg — узкое место в вычислительной мощности, и это типично для запуска на процессоре, для Apple Silicon и для встроенной графики.
Проблема «долгая пауза перед первым словом при бодрой генерации после» — это всегда pp, и лечится она не тем же, чем медленная генерация. Разбор обеих фаз — в материале о том, от чего зависит скорость LLM на процессоре.
#Узел 7: троттлинг и режим питания
Последний узел, потому что он самый редкий и самый заметный при правильном замере.
Признак: первые двадцать секунд генерации быстрее последующих. Проверяется длительным прогоном, а не коротким.
Причины: перегрев видеокарты или процессора при длительной полной нагрузке, режим энергосбережения на ноутбуке, работа от батареи, ограничение мощности в настройках драйвера.
Проверка:
nvidia-smi --query-gpu=temperature.gpu,clocks.sm,power.draw --format=csv -l 5
Команда выводит температуру, частоту и потребление каждые пять секунд. Падение частоты при росте температуры — это троттлинг.
#Таблица: симптом, причина, проверка
| Симптом | Вероятная причина | Проверка |
|---|---|---|
| Скорость близка к расчётной | нет проблемы, это предел | ПСП / вес модели |
| Скорость в разы ниже расчётной | слои на процессоре | ollama ps |
| Было быстро, стало медленно | память заняли другие процессы | nvidia-smi со списком процессов |
| Замедляется по ходу разговора | растёт KV-кэш | замер на разной длине контекста |
| Долгая пауза, потом бодрый текст | медленная обработка промпта | llama-bench, колонка pp |
| Первые секунды быстрее остальных | троттлинг или режим питания | nvidia-smi -l 5 |
| Медленно только в контейнере | не пробросилась видеокарта | nvidia-smi внутри контейнера |
Что здесь смотреть: первая строка. Она чаще всего и есть ответ, а вся остальная таблица нужна, чтобы к ней прийти обоснованно, а не на веру.
#Если ничего не помогло
Сделайте корректный замер по протоколу — с прогревом, фиксированной длиной, тремя повторами и медианой. Значительная часть «загадочных» замедлений оказывается артефактом методики: сравнивали холодный запуск с прогретым или разные длины запроса. Протокол — в материале о том, как измерить скорость локальной модели правильно.
Проверьте версию движка: изменения производительности между релизами бывают заметными в обе стороны, и «вчера было быстрее» после обновления — реальный сценарий.
Проверьте, не выставлено ли несколько параллельных слотов: они делят и контекст, и память, а для одного пользователя не дают ничего.
Наконец, если ошибок нет и все проверки пройдены, а скорость всё равно не устраивает — вопрос переходит из плоскости настройки в плоскость выбора: модель меньшего класса на том же железе будет быстрее ровно во столько раз, во сколько она легче. Диагностика сообщений об ошибках, если они всё-таки появляются, — в справочнике по ошибкам Ollama.
#Частые вопросы
#С чего начать, если модель тормозит?
С команды ollama ps и проверки, что все слои на видеокарте. Это самая частая причина, и она обнаруживается за пять секунд.
#Почему модель стала медленнее, хотя ничего не менялось?
Чаще всего в момент загрузки модели видеопамять была занята чем-то ещё, и автоподбор отдал часть слоёв процессору. Выгрузите модель, освободите память, загрузите заново.
#Почему ответ начинается с большой паузой?
Это обработка запроса — отдельная фаза, ограниченная вычислительной мощностью, а не пропускной способностью памяти. Пауза растёт с длиной запроса и особенно заметна на процессоре, на встроенной графике и на Apple Silicon.
#Влияет ли уровень квантизации на скорость?
Влияет прямо: файл вдвое меньшего размера читается вдвое быстрее. Переход с Q8 на Q4 заметно ускоряет генерацию — при условии что оба варианта помещались в память целиком.
#Может ли антивирус замедлять работу модели?
Может — за счёт проверки крупных файлов при загрузке весов с диска. На саму генерацию после загрузки он не влияет. Признак: долгий старт при нормальной скорости после него.
#Как понять, что дальше улучшать нечего?
Если замеренная скорость составляет 50–70% от расчётного потолка (пропускная способность памяти, делённая на вес модели), вы близки к пределу конфигурации. Дальше только более лёгкая модель, более жёсткая квантизация или другое железо.