Вы запустили агента на Q4_K_M. Он красивый, быстрый, жрет всего 12 гигов памяти. Первые 10 вызовов — идеально. На одиннадцатом он вместо вызова функции get_balance(user_id) вдруг генерирует ответ: «Ваш баланс: 0.000034 BTC». Или, что хуже, вызывает transfer_funds() с неправильными параметрами.
Спойлер: это не баг модели, это баг квантования. точнее — вашего выбора Q4_K_M вместо Q6.
Я перепробовал десятки квантов на агентских задачах. И наконец могу сформулировать, почему Q4_K_M ломает агентов, а Q6 — пока нет. Без воды, с цифрами, матчастью и ссылками на реальные кейсы.
Миф о «достаточно хорошем» квантовании
Вы наверняка читали бенчмарки: Q4_K_M теряет всего 2-3% перплексии. Для генерации текста — да, незаметно. Но агентные сценарии — это не текст. Это последовательность строгих логических шагов: распарсить запрос → выбрать инструмент → подставить параметры → распарсить ответ → решить, что делать дальше.
Одна ошибка на раннем этапе размножается как цепная реакция. В недавнем разборе инцидента с Replit показано: 85% точности одного шага за 5 шагов превращаются в 44% успеха. Квантование вносит свой вклад в этот процент ошибок.
| Характеристика | Q4_K_M | Q6 |
|---|---|---|
| Размер на модель 7B | ~4.2 GB | ~5.6 GB |
| Размер на модель 70B | ~42 GB | ~56 GB |
| Разрядность весов | 4.5 бита (в среднем) | 6 бит (равномерно) |
| Квантование важных слоев (attention, lm_head) | часто 4 бита или хуже | стабильно 6 бит |
| Потери perplexity (LLaMA-4 8B, 27.05.2026) | +2.1% | +0.8% |
| Частота ошибок tool calling (наша выборка) | ~8-12% | ~1-3% |
Ошибка в битах — ошибка в деньгах
Давайте посчитаем. Возьмем задачу: агент должен вызвать search_flights(departure, destination, date) с JSON-параметрами.
В Q6 модель выдает правильный JSON с вероятностью ~99%. В Q4_K_M — ~92%. Кажется, разница копеечная. Но типичный агент делает от 8 до 15 вызовов инструментов для одного сложного запроса (бронирование, согласование, оплата).
import math
p_q6 = 0.99
p_q4 = 0.92
steps = 10
success_q6 = p_q6 ** steps
success_q4 = p_q4 ** steps
print(f"Q6: {success_q6:.2%}") # ~90.4%
print(f"Q4: {success_q4:.2%}") # ~43.4%
Видите? С каждым шагом разрыв растет. Уже на пяти шагах вероятность успеха на Q4_K_M — 65%, а на Q6 — 95%. Агент, который ошибается в каждом третьем запросе, — не агент, а генератор багов.
Это не гипотетика. В статье «Почему ломаются AI-агенты в продакшене» таксономия MAST показывает, что ошибки исполнения (execution errors) — одна из главных причин сбоев. Квантование Q4_K_M напрямую увеличивает долю этих ошибок.
Tool calling: почему Q4_K_M срезает углы
В LLM функция вызова инструмента — это не отдельный модуль. Модель генерирует специальные токены (например,
Я провел эксперимент: взял LLaMA-4-8B (актуальная на май 2026) в квантах Q4_K_M и Q6, прогонял 1000 запросов из набора BFCL v3 (Berkeley Function Calling Leaderboard). Результат:
| Метрика | Q6 | Q4_K_M |
|---|---|---|
| Точность выбора функции | 98.5% | 94.2% |
| Правильные параметры (тип + значение) | 97.1% | 89.3% |
| Числовые параметры (все верные разряды) | 99.2% | 91.5% |
| Галлюцинации несуществующих функций | 0.2% | 2.1% |
Особенно опасны галлюцинации несуществующих функций: когда модель «выдумывает» несуществующий инструмент, агент может попытаться выполнить невалидную операцию. Это прямой путь к крашу или логической ошибке.
Как я потерял агента из-за Q4_K_M (и вы потеряете)
История из продакшена. Мы строили мультиагентную систему для автоматизации техподдержки. Один из агентов отвечал за создание тикетов в Jira. Он должен был вызывать create_issue(summary, description, priority, assignee). На Q6 все работало неделями. Перешли на Q4_K_M ради экономии памяти на GPU — и через два дня получили тикет: «Приоритет: критический, исполнитель: null, описание: пустая строка». Почему? Модель сгенерировала JSON с неправильным ключом "priorty" вместо "priority".
Одна буква — и агент создает тикет, который невозможно обработать. Такие ошибки сложно отлавливать автоматически, потому что JSON синтаксически верен, но семантически неверен. Это напоминает кейс из статьи ODCV-Bench, где агенты нарушают правила ради KPI. Только здесь нарушение происходит не из-за мотивации, а из-за шума в весах.
Warning: Если ваш агент работает с финансами, медициной или любыми данными, где ошибка в одном байте приводит к реальному ущербу — Q4_K_M категорически противопоказан. Q6 — минимальный порог.
Практические советы: когда какой квант использовать
1 Q6 — для агентов, которые держат деньги
Если агент вызывает внешние API, управляет транзакциями, записывает в БД — ставьте Q6 или выше (Q8, FP16). Экономия памяти не стоит риска.
2 Q4_K_M — для внутренних черновиков и чат-ботов
Если агент просто отвечает на вопросы (без вызова инструментов) или его ошибки безопасны (например, генерация писем с возможностью редактирования) — Q4_K_M сойдет. Но обязательно валидируйте каждый вызов инструмента на стороне кода.
3 Гибридный подход: Q6 для критических шагов
В мультиагентной системе можно запустить «дешевого» агента на Q4_K_M для анализа, а «исполнителя» — на Q6 или выше. Как описано в статье об экономике мультиагентных систем, такое разделение снижает затраты без потери надежности.
А что насчет других квантов?
Мы не рассмотрели Q5_K_M, IQ4_NL, Q3_K_S. Каждый имеет свои особенности. Например, как показано на примере Minimax M2.5, некоторые модели крайне чувствительны к квантованию. Но общее правило: чем сложнее задача (tool calling, multi-step reasoning), тем выше должно быть качество весов.
Если вы хотите проверить свой квант — используйте простой тест: сгенерируйте 100 вызовов одной функции с разными параметрами и посчитайте точность. Разница между Q6 и Q4_K_M в 5-10% — это не абстракция, это ваши тикеты, биллинг и нервы.
Напоследок: в 2026 году появились новые методы квантования, которые частично решают проблему. Например, AQLM и QuIP#. Они сохраняют точность даже при 4 битах. Но пока они не так широко распространены в llama.cpp. Так что если вам нужен рабочий агент здесь и сейчас — выбирайте Q6. Не пожалеете.
Обновлено 27.05.2026. Тесты проводились на LLaMA-4-8B, LLaMA-4-70B, Qwen 3-32B с llama.cpp b4098.
