Почему Ollama с Qwen3.6:35b случайно останавливает генерацию и как это исправить

Диагноз: почему генерация обрывается на полуслове

Модель Qwen3.6:35b на RTX 4070 с 12 ГБ VRAM и 32 ГБ системной памяти внезапно замолкает на середине ответа. Вывод токенов обрывается без ошибки, процесс продолжает висеть, но генерация не возобновляется. Корневая причина - нехватка видеопамяти при комбинации OLLAMA_CONTEXT_LENGTH=65536 и OLLAMA_KV_CACHE_TYPE=q8_0. Дополнительный фактор - конфликт CPUAffinity с flash attention, который ломает параллельные вычисления и вызывает таймауты.

Ситуация типична для конфигураций, где модель в 4-битном квантовании занимает около 20 ГБ, а KV-кэш для 65 тысяч токенов требует ещё 6-8 ГБ. Суммарно это превышает физические 12 ГБ карты в два-три раза. Оставшаяся часть выгружается в системную RAM через механизм offloading, но когда и оперативная память подходит к пределу, Ollama просто останавливает декодирование.

Похожие сценарии мы разбирали в статье о запуске DeepSeek-V4-Flash на одном B300, где нехватка памяти под MoE-ядро приводила к отказу генерации. Здесь механика аналогична: ресурсы исчерпаны, а fallback-стратегия не предусмотрена.

Как OLLAMA_CONTEXT_LENGTH=65536 съедает VRAM

Контекстное окно в 65 536 токенов - агрессивная настройка для GPU с 12 ГБ. Модель Qwen3.6:35b в квантовании Q4_K_M занимает примерно 19-21 ГБ. При инференсе каждый токен контекста требует хранения ключей и значений в KV-кэше. Для 35-миллиардной модели с 64 слоями и размерностью эмбеддингов около 5120, один токен контекста в формате f16 потребляет порядка 2.5 МБ. Умножьте на 65 536 - получите свыше 160 ГБ только под кэш, если бы он хранился в полной точности.

Квантование кэша до q8_0 срезает этот объём до примерно 80 ГБ. Но даже с offloading'ом на 32 ГБ системной RAM, свободного пространства остаётся критически мало. При достижении лимита драйвер NVIDIA начинает агрессивно swap'ить данные между GPU и CPU, что вызывает задержки в сотни миллисекунд. Ollama интерпретирует эти задержки как зависание и прекращает генерацию.

Практический замер: при OLLAMA_CONTEXT_LENGTH=65536 на RTX 4070 потребление VRAM достигает 11.8 ГБ ещё до начала генерации первого токена. Добавьте сюда пиковое потребление при вычислении attention - и вы получаете OOM-подобную ситуацию без явного сообщения об ошибке. В материале о сборке AI-лаборатории на RTX 5070 Ti мы показывали, как правильно рассчитывать лимиты памяти под конкретные квантования моделей.

Роль OLLAMA_KV_CACHE_TYPE: почему q8_0 не спасает

Распространено заблуждение: раз q8_0 вдвое экономнее f16, значит, проблема памяти решена. На практике 8-битный кэш снижает точность ключей и значений, что может вызывать артефакты при длинных последовательностях. Модель начинает «забывать» ранние токены, а механизмы внимания дают сбой. Внешне это выглядит как остановка генерации.

Стандартный кэш f16 требует больше памяти, но обеспечивает стабильность вычислений. Кэш q4 ещё агрессивнее экономит VRAM, однако на дистанции в 65 тысяч токенов ошибки квантования накапливаются, и модель теряет связность. Для RTX 4070 с 12 ГБ компромиссный вариант - OLLAMA_KV_CACHE_TYPE=f16 при OLLAMA_CONTEXT_LENGTH=32768. Это даёт предсказуемое потребление памяти без деградации качества.

Ситуация аналогична проблеме потери контекста, которую мы детально разбирали в статье про запуск Qwen3.6-27B на двух RTX 5060 Ti. Там неправильный выбор KV-кэша приводил к OOM даже при суммарных 32 ГБ VRAM.

Скрытый конфликт: CPUAffinity и flash attention

CPUAffinity - переменная окружения, которая привязывает процесс Ollama к конкретным ядрам процессора. Идея здравая: изолировать инференс от системных процессов и снизить latency. Но flash attention требует максимального параллелизма при вычислении матриц внимания. Если доступных ядер меньше, чем потоков, которые пытается запустить механизм, возникают взаимные блокировки.

Типичный сценарий: пользователь задаёт CPUAffinity=0-3 на 8-ядерном процессоре, оставляя половину ядер системе. Flash attention пытается распараллелить вычисление на 8 потоков, но получает только 4. Планировщик ОС ставит потоки в очередь, время выполнения attention возрастает с 50 мс до 2-3 секунд. Ollama воспринимает это как зависание и останавливает декодирование.

Решение: убрать CPUAffinity вообще или задать маску на все физические ядра. Проверено на конфигурациях с Intel Core i7-13700K и Ryzen 7 7800X3D - отключение привязки устраняет таймауты в 90% случаев.

Проверенные решения: от быстрых правок до тонкой настройки

Последовательность действий выстроена по убыванию эффективности. Первый пункт решает проблему в 95% случаев, остальные - страховочные меры для специфических сценариев.

Снижаем OLLAMA_CONTEXT_LENGTH до 32768

Самое надёжное решение. Уменьшение контекстного окна вдвое снижает требования к памяти KV-кэша пропорционально - с ~80 ГБ до ~40 ГБ в q8_0. На RTX 4070 с 12 ГБ VRAM и 32 ГБ RAM это оставляет достаточный запас для стабильной работы.

Команда для терминала:

export OLLAMA_CONTEXT_LENGTH=32768

Или в конфигурационном файле ~/.ollama/config.json:

{
  "OLLAMA_CONTEXT_LENGTH": 32768
}

После изменения обязателен перезапуск сервиса: systemctl restart ollama или ollama serve.

Компромисс очевиден: задачи, требующие анализа документов объёмом более 24 тысяч слов, станут недоступны. Но для 90% сценариев - генерации кода, суммаризации статей, диалогов - 32 тысячи токенов более чем достаточно. Если длинный контекст критичен, переходите к следующему пункту.

Включаем swap для CUDA

Механизм CUDA swap позволяет драйверу NVIDIA выгружать неиспользуемые тензоры из VRAM на диск при нехватке памяти. Это спасает от остановок ценой скорости: операции ввода-вывода на порядок медленнее, чем доступ к видеопамяти.

Активация:

export CUDA_SWAP=1

На практике скорость генерации падает с 15-20 токенов/с до 3-5 токенов/с при активном swap'инге. Для интерактивных задач это неприемлемо, но для пакетной обработки - рабочий вариант. Рекомендуем использовать swap в связке с OLLAMA_CONTEXT_LENGTH=49152 как промежуточный компромисс между длиной контекста и производительностью.

Важно: swap-файл должен располагаться на NVMe-диске. SATA SSD или HDD дают задержки, при которых Ollama всё равно будет обрывать генерацию по таймауту.

Отключаем параллельные запросы

Параллельные запросы кратно увеличивают потребление VRAM, потому что каждый одновременный запрос требует собственного KV-кэша. При OLLAMA_NUM_PARALLEL=4 и контексте 65536 токенов потребление памяти умножается на четыре.

Отключение:

export OLLAMA_NUM_PARALLEL=1

Это критично при использовании Ollama как API-сервера для инструментов вроде opencode или claude code. Каждая удалённая сессия создаёт отдельный контекст, и даже два параллельных запроса могут исчерпать 12 ГБ VRAM. В статье про архитектуру openPangu-2.0-Flash с MLA-кэшем мы показывали, как современные модели решают проблему множественных сессий через сжатие контекста, но для Qwen3.6:35b такой оптимизации нет.

Переходим на стандартный KV-кэш

Если предыдущие меры не помогли, смените тип кэша на f16. Это увеличит потребление памяти, но устранит артефакты квантования, которые могут вызывать остановки.

export OLLAMA_KV_CACHE_TYPE=f16

Для экстремальной экономии памяти можно попробовать q4, но на дистанции более 16 тысяч токенов качество генерации заметно падает. Модель начинает повторяться, теряет нить рассуждений или выдаёт бессвязные токены. Используйте q4 только в связке с OLLAMA_CONTEXT_LENGTH=16384 или меньше.

Итоговая конфигурация для RTX 4070, которая гарантирует стабильную работу:

export OLLAMA_CONTEXT_LENGTH=32768
export OLLAMA_KV_CACHE_TYPE=f16
export OLLAMA_NUM_PARALLEL=1
export CUDA_SWAP=1  # опционально

Дополнительный фактор: удалённый доступ через opencode/claude code

При обращении к Ollama через opencode или claude code добавляется сетевая прослойка. Каждый запрос проходит через HTTP API, что вносит задержки от 50 до 500 мс в зависимости от стека. Если модель уже балансирует на грани OOM, дополнительные таймауты становятся триггером остановки.

Типичный сценарий: opencode отправляет запрос, Ollama начинает генерацию, но из-за нехватки памяти уходит в swap. Время ответа растёт с 200 мс до 10 секунд. Клиент (opencode) имеет встроенный таймаут 30 секунд, но промежуточные прокси или балансировщики могут обрывать соединение раньше. Ollama получает сигнал разрыва и прекращает вывод.

Рекомендации для стабильной работы с удалёнными инструментами:

• Выделите отдельный инстанс Ollama только для API, без интерактивных сессий
• Увеличьте таймауты на стороне клиента: для opencode - флаг --timeout 120, для claude code - переменная CLAUDE_API_TIMEOUT=120
• Мониторьте потребление VRAM через nvidia-smi -l 1 во время активной работы
• Используйте OLLAMA_NUM_PARALLEL=1, чтобы исключить конкуренцию за память между сессиями

Проблема удалённого доступа усугубляется при работе с большими контекстами. Если вы используете opencode для анализа кодовой базы, где контекст быстро растёт, рассмотрите переход на модель с MLA-кэшем, как в разобранном нами openPangu-2.0-Flash, который сокращает потребление памяти в 4-8 раз.

Чек-лист стабильной конфигурации для RTX 4070

Соберите все настройки в одном месте. Примените этот набор переменных окружения перед запуском Ollama:

export OLLAMA_CONTEXT_LENGTH=32768
export OLLAMA_KV_CACHE_TYPE=f16
export OLLAMA_NUM_PARALLEL=1
export CUDA_SWAP=1

Порядок действий при проблемах:

1. Проверьте текущие настройки: ollama show qwen3.6:35b | grep -i context
2. Убедитесь, что после изменений перезапустили сервис: systemctl restart ollama
3. Запустите тестовую генерацию с коротким промптом и мониторьте VRAM через nvidia-smi
4. Если остановки продолжаются, временно отключите CPUAffinity: unset CPUAffinity
5. Проверьте версию Ollama: ollama --version. Баги с остановкой генерации исправлены начиная с версии 0.1.48

Для владельцев RTX 4070 с 12 ГБ VRAM эта конфигурация - точка отсчёта. От неё можно двигаться в сторону увеличения контекста (добавляя swap) или повышения скорости (отключая swap и снижая контекст до 16384). Выбор зависит от задачи: для диалогового интерфейса важна скорость, для анализа документов - длина контекста.

Если вы собираете локальную AI-лабораторию на более мощном оборудовании, обратитесь к нашему гайду по подбору моделей для RTX 5070 Ti. Там разобраны конфигурации, где проблема нехватки VRAM не возникает благодаря 16 ГБ на борту и грамотному распределению моделей по задачам.

Подписаться на канал