Почему coding agent 'глупеет' на длинном контексте: диагностика и решение проблемы с KV cache quantization

Вы запускаете свой локальный coding agent на Qwen3-Coder-32B. Первые пять файлов он обрабатывает блестяще. Но на шестом начинает выдавать откровенный бред. Функции теряют логику, переменные путаются, а код выглядит так, будто его писал стажёр после бессонной ночи. Знакомо? Виновник чаще всего не в модели, а в её «оперативной памяти» — KV cache. И его квантование, которое должно экономить VRAM, методично убивает качество на длинных диалогах.

Когда экономия памяти становится самоубийством

Всё началось с простой идеи: чтобы ускорить генерацию и сэкономить память, ключи (K) и значения (V) из предыдущих токенов кэшируют. Без этого каждый новый токен требовал бы пересчёта всей истории — чистое безумие с квадратичной сложностью. Но этот кэш жрёт гигабайты. Решение? Квантовать его, как и веса модели, до 8, 6 или даже 4 бит. Логично звучит, да? Вот только веса модели статичны — их квантовали один раз при конвертации. А KV-cache динамичен, он живёт и меняется в реальном времени в процессе генерации.

Это особенно болезненно для coding agents вроде Qwen3-Coder-32B-Instruct или GLM 4.7 128K (актуальные на март 2026 года). Они заточены под многошаговые рассуждения (chain-of-thought), где точность передачи зависимостей между шагами — всё. Если в середине цепочки ключевой токен исказился, вся последующая логика летит под откос. Подробнее о механике долговременной памяти LLM мы писали в статье «KV-cache в долговременной памяти: почему всё ломается и как это починить».

Диагностика: как найти виновника деградации

Прежде чем лезть в настройки, убедитесь, что проблема именно в квантовании KV-cache, а не в чём-то другом (перегрев, нехватка системной RAM, кривой промпт).

1 Профилируем потребление памяти

Запустите своего агента с мониторингом VRAM. В llama.cpp это делается через флаг --verbose, в ExLlamaV3 смотрите логи. Вам нужны две цифры: пиковое использование до начала генерации (загрузка модели) и рост во время обработки длинного контекста. Если рост линейный и съедает больше 2-3 ГБ на 10k токенов — KV-cache, скорее всего, в полной точности (FP16). Если рост скромный (например, 500 МБ на 10k токенов), но качество падает — он квантованный.

# Пример для llama.cpp с мониторингом (Linux)
./main -m qwen3-coder-32b-instruct-q4_k_m.gguf \
  -p "Write a Python function to parse this JSON..." \
  -n 1024 --verbose 2>&1 | grep -E "kv cache|VRAM usage"

# Для ExLlamaV3 через текстовый UI смотрите статистику в интерфейсе.

2 Тест на перплексию с нарастающим контекстом

Возьмите небольшой датасет кода (например, несколько Python-файлов из проекта). Измерьте перплексию модели на первом файле, затем на конкатенации первого и второго, и так далее. Если перплексия начинает нелинейно взлетать после 4-5 файлов при квантованном KV-cache — диагноз подтверждён. Более глубокий разбор этой методики есть в материале «Почему Post-Training Quantization ломается на длинных chain-of-thought рассуждениях».

Лечение: настройка llama.cpp и ExLlamaV3 в 2026 году

Инструменты не стоят на месте. На март 2026 и llama.cpp, и ExLlamaV3 получили тонкий контроль над квантованием KV-cache. Вот как им пользоваться.

1 Llama.cpp: уходим от --kv-cache-type q4_0

Раньше по умолчанию ставили --kv-cache-type q4_0 — это было слишком агрессивно для coding. В последних версиях появились более щадящие типы. Порядок от наименее до наиболее точных: q4_0 < q6_k < q8_0 = f16. Для coding agent с контекстом до 32k токенов минимально допустимый вариант — q6_k. Если VRAM позволяет, используйте q8_0. Полная точность (f16) редко нужна, но для задач в 128k контекста (как у GLM 4.7) стоит рассмотреть.

# Правильный запуск для баланса память/качество
./main -m glm-4-7-128b-q4_k_m.gguf \
  --prompt "Your coding task here..." \
  -n 2048 \
  --ctx-size 32768 \
  --kv-cache-type q8_0 \
  --threads 16 \
  --batch-size 512

# Если VRAM мало, но хочется стабильности, пробуем q6_k
--kv-cache-type q6_k

Обратите внимание на --batch-size. Большой батч уменьшает количество перезаписей в кэше, что может снизить накопление ошибок. Но требует больше памяти. Экспериментируйте.

2 ExLlamaV3: копаемся в config.json

ExLlamaV3 (актуальная версия 3.2.1 на март 2026) хранит настройки квантования в файле конфигурации модели. Найдите параметры cache_8bit и cache_4bit. По умолчанию они часто включены для экономии. Для coding agent выключайте cache_4bit напрочь. cache_8bit можно оставить, но проверьте качество. Лучший вариант — использовать групповое квантование (GPTQ) для весов модели, но оставить KV-cache в FP16.

// Пример config.json для ExLlamaV3 (фрагмент)
{
  "name": "qwen3-coder-32b-instruct",
  "format": "gptq",
  "gptq_bits": 4,
  "gptq_groupsize": 128,
  // Критичные настройки KV-cache:
  "cache_8bit": false,
  "cache_4bit": false,
  "max_seq_len": 32768,
  "compress_pos_emb": 2.0
}

После изменения config.json перезапустите сервер ExLlamaV3. Памяти будет есть больше, но агент перестанет терять нить рассуждений. Если вы боретесь за каждый гигабайт, прочтите наше руководство «12 ГБ VRAM — не приговор: какой кодер и математик поместится в вашу видеокарту в 2026 году».

Подводные камни, о которых молчат документации

• Температура усиливает шум. Если вы используете temperature > 0.8, ошибки квантования KV-cache «раскачиваются» сильнее. Модель становится творческой в плохом смысле. Для детерминированного кодинга держите temperature в районе 0.1-0.3.
• Контекстное окно не равно эффективной памяти. Модель с заявленным 128k контекстом в квантованном KV-cache может реально «помнить» только первые 30-40k токенов с приемлемой точностью. Не доверяйте цифрам на упаковке.
• Разные слои — разная чувствительность. Исследования 2025 года показали, что нижние и верхние слои трансформера по-разному реагируют на квантование кэша. Некоторые продвинутые форки llama.cpp позволяют задавать разную точность для разных слоёв, но это уже высший пилотаж.

Вопросы, которые вы боялись задать

Можно ли вообще отключить квантование KV-cache?

Да, но это дорого. В llama.cpp укажите --kv-cache-type f16, в ExLlamaV3 установите "cache_8bit": false, "cache_4bit": false. На модели 32B с контекстом 32k это может съесть дополнительно 4-6 ГБ VRAM. Стоит ли оно того? Для финальной сборки проекта — да. Для экспериментов — нет.

Почему на vision-моделях эта проблема менее заметна?

Потому что изображения уже «зашумлены» с самого начала (пиксели). Там нет такой жёсткой логической структуры, как в коде. Но и там есть границы — читайте наш разбор «Q8 KV cache для vision-моделей: ломает ли качество или можно экономить память?».

А если я использую API к облачной модели?

Проблема никуда не делась. Провайдеры (вроде Together AI, Anyscale) тоже квантуют KV-cache для экономии. Спрашивайте у них, какие настройки используются по умолчанию для длинных контекстов. Часто можно указать параметр quantization: "none" в запросе, но это будет дороже.

Есть ли будущее у квантования KV-cache?

Да, но не в текущем виде. Подходы смещаются к выборочному кэшированию (cache pruning) и спарсным методам, где квантуются только «маловажные» ключи. К 2027 году, возможно, мы увидим встроенные в модели механизмы адаптивного квантования, обученные вместе с весами. А пока — ручная настройка, как описана выше, ваш лучший друг.

И последний совет, который вы не найдёте в мануалах: периодически сбрасывайте контекст. Если ваш агент работает над задачей в 50 тысяч токенов, искусственно разбейте её на сессии по 15-20 тысяч. В начале каждой новой сессии подведите итог предыдущей в 2-3 предложениях и вставьте в промпт. Это грубый хак, но он работает надёжнее любого квантования. Иногда старые методы переигрывают сложные технологии.

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