Qwen 3.8-27B локально: Q4_K_M с FP16 KV или Q6_K_M с Q8 KV — что выбрать для агентного кодинга

Введение

Запускать 27-миллиардную модель на двух потребительских GPU — уже не экзотика, а рабочий сценарий. Но после того как модель влезла в память, возникает менее очевидный вопрос: какое квантование весов и какой тип KV-кэша дать системе? Вариант «Q4_K_M + FP16» кажется естественным — проверенное квантование плюс полный запас точности в кэше. Вариант «Q6_K_M + Q8_0» выглядит противоречиво: зачем ухудшать KV, если можно улучшить веса?

Ответ зависит от того, для какой задачи вы настраиваете систему. Для генерации художественного текста или разовых ответов разница почти не видна. Для агентного кодинга — когда модель часами держит в контексте файлы, историю диалога и результаты вызовов инструментов — выбор конфигурации напрямую влияет на частоту ошибок tool calls и на стабильность скорости при росте сессии. В этой статье разберём оба варианта на примере Qwen 3.8-27B (гибридная архитектура DeltaNet + attention) на связке 2×RTX 5060 Ti, приведём расчёты VRAM и дадим конкретные флаги llama.cpp.

Почему выбор квантования критичен именно для агентного кодинга

Обычный чат-запрос — это короткий промпт и ответ на несколько тысяч токенов. Агентная сессия выглядит иначе: модель обрабатывает системный промпт, историю сообщений, результаты чтения файлов (одна команда Read может вернуть 2000 строк), затем формирует вызов инструмента в строгом JSON-формате, получает результат, повторяет цикл десятки раз. Контекст к концу сессии достигает 30–60K токенов и продолжает расти.

В таких условиях качество квантования весов проявляется не в «красоте» текста, а в точности механических операций:

• Точность old_string в Edit. Одна лишняя или недостающая пробельная строка — и правка не применяется, агент делает повторный вызов, тратя время и токены.

• Корректность JSON-аргументов tool calls. Пустой объект {} вместо пары ключ-значение — это прерванная сессия и потеря контекста.

• Следование системным инструкциям на длинной сессии. Системный промпт задаёт правила (формат ответов, запрет лишних файлов, стиль). На длинном контексте низко квантованная модель начинает «забывать» пункты из начала развёртки.

Поверхностный подход — взять популярное Q4_K_M и не думать о KV-кэше — экономит время на настройке, но переносит затраты в рантайм: каждый retry tool call стоит секунд генерации, а накопленные ошибки могут испортить результат задачи целиком. Для продакшн-использования локальных моделей корректный подбор конфигурации — часть инженерной работы, а не мелкая настройка «на глаз».

Расчёт VRAM: модель + KV-кэш

Сначала — размер весов. Q4_K_M для 27B модели занимает около 17 ГБ, Q6_K_M — примерно 20–21 ГБ. Разница в 3–4 ГБ невелика по сравнению с суммарным объёмом двух GPU (32 ГБ), но она съедает часть запаса, который нужен KV-кэшу.

KV-кэш растёт линейно с длиной контекста. Формула для модели с GQA:

KV на токен = 2 × число_attention_слоёв × число_KV_голов × head_dim × размерность_типа

Для Qwen 3.8-27B (гибрид Gated DeltaNet + full attention, паттерн слоёв 3:1) при FP16 получается порядка десятков КБ на токен — точное значение зависит от числа full-attention слоёв и конфигурации GQA конкретной ревизии. Ниже приведены ориентировочные оценки для типового 27B-набора параметров (около 48 слоёв, ~8 KV-голов в attention-слоях, head_dim 128):

Складываем с весами:

Вывод: на 32K контекста оба варианта влезают свободно, и здесь выигрывает Q6 по качеству. На 64K вариант с FP16 KV начинает упираться — модель + кэш + активации llama.cpp подходят к границе 32 ГБ, и часть данных уходит в оперативную память, что резко снижает скорость. Q8 KV даёт вдвое больший запас при том же контексте.

💡 Практическое правило: сначала подбирайте размер контекста под реальную длину сессий, а уже потом — квантование. Типичная рабочая сессия агентного кодинга укладывается в 30–50K токенов; потолок 64K оставляет запас для всплесков без риска оффлоада.

Что даёт DeltaNet: почему реальный KV меньше расчётного

Qwen 3.8-27B использует гибридную архитектуру из семейства Qwen3-Next/3.5: слои чередуются по паттерну три Gated DeltaNet + один full attention (соотношение 3:1). Ключевое следствие: слои Gated DeltaNet — линейное внимание с фиксированной state-матрицей постоянного размера, не зависящей от длины последовательности. Растущий KV-кэш накапливается только в full attention-слоях — примерно четверти от общего числа слоёв.

Это означает две вещи. Во-первых, реальный размер KV для Qwen 3.8-27B примерно вчетверо меньше расчёта «чистого» MHA той же глубины — модель заметно эффективнее использует VRAM на длинных контекстах, чем классические трансформеры того же размера. Во-вторых, гибрид частично решает проблему деградации внимания к началу развёртки: чистые attention-модели на очень длинных последовательностях хуже удерживают ранние пункты инструкций, а рекуррентное состояние DeltaNet-слоёв сохраняет сжатую информацию о всей истории.

Точную долю слоёв каждого типа можно проверить в конфигурации модели (поле layer_types в config.json или метаданных GGUF). Если доля full attention меньше 25%, оценки KV из таблиц выше становятся консервативными: 128K контекст с Q6 + Q8 KV влезает с большим запасом.

Скорость: где FP16 KV выигрывает, а где проигрывает

На коротких промптах (< 4K токенов) разница между типами KV практически не видна — объём кэша мал, и узкое место остаётся в весах. На длинном контексте картина меняется: FP16 KV вдвое увеличивает трафик данных при каждом шаге внимания, и prompt processing (обработка входящего промпта) замедляется заметно сильнее, чем генерация.

По бенчмаркам сообщества (в том числе тестам на NVIDIA DGX Spark с 30B-моделями) q8_0 KV даёт сжатие в 2 раза при потере скорости менее 5% на всех длинах контекста — для большинства задач это практически безупречно. Разница Q4_K_M → Q6_K_M в скорости генерации минимальна (оба режима memory-bound), поэтому суммарно конфигурация Q6 + Q8 KV часто быстрее реальных сессий, чем Q4 + FP16: модель чуть крупнее, но кэш вдвое компактнее.

⚠️ Типичная ошибка — включать FP16 KV «для качества», не проверив VRAM-бюджет на целевой длине контекста. Если после 30K токенов начинается оффлоад в RAM, потеря скорости от CPU-обмена многократно превышает теоретический выигрыш полноточного кэша.

Конфигурация llama.cpp: конкретные флаги

Основной конфиг для агентного кодинга на 2×RTX 5060 Ti:

llama-server \
  --model Qwen3.8-27B-Q6_K_M.gguf \
  --ctx-size 65536 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  -ngl 99 \
  --tensor-split 1,1

Пояснение по флагам: --ctx-size задаёт потолок контекста (64K — запас для длинных сессий); --cache-type-k/v применяют квантование K- и V-частей кэша отдельно; -ngl 99 выгружает все слои на GPU; --tensor-split 1,1 делит веса поровну между двумя видеокартами.

После запуска проверьте в логе две строки:

llama_context: KV self size = X GiB (q8_0)
offloaded Y/Z layers to GPU

Первая подтверждает, что кэш действительно q8_0, а не f16 по умолчанию. Вторая — что все слои на GPU; если часть ушла в CPU, уменьшите ctx или проверьте равномерность tensor-split. В старых сборках llama.cpp вместо пары флагов использовался общий --cache-type-all q8_0 — сверьтесь с документацией вашей версии.

Альтернативные сценарии: когда менять конфигурацию

Q6_K_M не влезает по VRAM. Первый шаг — не переход на Q4, а уменьшение контекста до 32K. Если и этого мало, берите Q5_K_M (~18–19 ГБ) как компромисс: качество ближе к Q6, размер ближе к Q4.

Нужен гарантированный 128K контекст. Тогда Q5_K_M + Q8 KV — рабочая связка (модель ~19 ГБ + KV ~6 ГБ = ~25–26 ГБ, впритык, но реалистично). FP16 KV на 128K уже не вариант: только кэш съест 12+ ГБ.

Добавлен третий GPU. Появляется смысл вернуться к FP16 KV для максимального качества на длинных развёртках — VRAM-давление исчезает, и полноточный кэш начинает приносить чистую выгоду.

Ферма из нескольких инстансов. Если задача — запустить несколько моделей одновременно на одном пуле GPU, приоритет смещается к размеру весов: Q4_K_M освобождает место для второго инстанса, и потеря точности компенсируется параллельностью.

💡 Для продакшн-настройки локальных LLM имеет смысл зафиксировать конфигурацию в скрипте запуска и проверить её типовым сценарием: чтение нескольких больших файлов, правка одного из них, создание нового. Замер частоты retry на tool calls — самый прямой индикатор того, что конфигурация подходит именно вашей задаче.

Сравнение вариантов: итоговая таблица

Рекомендации и бест-практики

1. Подбирайте контекст под реальные сессии, а не «на максимум». 64K — разумный потолок для агентного кодинга; 128K включайте только если задачи действительно требуют длинных развёрток.

2. KV Q8_0 по умолчанию. На современных моделях потеря качества от q8_0 KV пренебрежима, а выигрыш в VRAM и стабильности скорости — реальный. FP16 KV оправдан только при избытке видеопамяти.

3. Ухудшайте контекст раньше, чем квантование. Если не влезает — сначала снижайте --ctx-size, потом переходите на более грубое квантование весов.

4. Проверяйте конфиг типовым сценарием работы, а не коротким промптом: длинная сессия с tool calls выявляет деградацию, которую короткий тест не покажет.

5. Не недооценивайте точность механических операций. В агентных системах цена ошибки tool call — это прерванная цепочка и потеря контекста; выбор Q6_K_M над Q4_K_M снижает частоту таких ошибок на длинных сессиях, что окупает потерю 1–2% скорости.

Выбор конфигурации локальной LLM — часть инженерной работы, а не мелкая настройка. Поверхностный подход «взял популярное квантование и поехал» работает до первой длинной сессии, после которой накапливаются retry-циклы и деградация качества. Для критичных задач — от подбора конфигурации до интеграции в рабочий процесс — имеет смысл привлекать специалистов с опытом работы локальными моделями: это снижает риски скрытых проблем производительности и экономит время на диагностике.

Заключение

Для агентного кодинга на 2×RTX 5060 Ti (32 ГБ суммарно) оптимальная конфигурация Qwen 3.8-27B — Q6_K_M + KV Q8_0 + ctx 64K. Причины: выше точность tool calls на длинном контексте, вдвое компактнее KV-кэш с запасом VRAM при росте сессии, а гибрид DeltaNet дополнительно снижает реальный размер кэша. Скорость генерации теряется минимально (1–2%), зато prompt processing на длинном контексте стабильнее, чем у варианта с FP16 KV.

Когда менять выбор: не влезает по VRAM — снижайте ctx до 32K, а не квантование; нужен 128K — переходите на Q5_K_M + Q8 KV; добавили GPU — можно вернуться к FP16 KV. Валидация конфигурации — A/B тест типовым сценарием (чтение больших файлов → правка → создание нового) с замером частоты retry на tool calls.

Источники

• LLM Quantization Levels Compared: Q4 vs Q8 vs FP16 (2026)

• Q4 vs Q6 vs Q8: The Quantization Decision Framework for Local LLMs — SitePoint

• Optimize Your GPU KV-Cache for Llama.cpp, OpenCode & Co. — Medium

• q4_0 vs q8_0 vs f16: KV cache quantization benchmarks (Nemotron 30B, 128K context) — NVIDIA Developer Forums

• Which Quantization Should I Use? A Unified Evaluation — arXiv

• What's the verdict on using quantized KV cache? — r/LocalLLaMA