Зачем вообще проверять 1-битные модели на tool calling?
Когда в апреле 2025 года вышла Bonsai-8B — первая 1-битная LLM, показавшая MMLU-R 65.7 — многие отнеслись скептически. Ну да, на бенчмарках знаний она выглядит достойно, но что насчёт практических задач? Tool calling — это та самая «рабочая лошадка» для AI-агентов: нужно не просто болтать, а правильно формировать JSON для вызова API. И вот тут 1-битный бит — потенциальная катастрофа. Казалось бы, экстремальное сжатие должно убить способность модели генерировать точные структуры данных. Но авторы Bonsai заявляли обратное: их архитектура специально заточена под вызов инструментов. Мы решили проверить это независимо и в условиях, максимально приближенных к реальному продакшену — на CPU без GPU, с грамматически ограниченной декодировкой через GBNF в llama.cpp.
Зачем мучить CPU? Потому что многие сценарии (edge-устройства, офисные ПК, виртуалки) не имеют GPU, а 1-битные модели как раз обещают быстрый инференс на обычном железе. Если Bonsai-8B реально тянет tool calling на CPU — это меняет правила игры для дешёвых AI-агентов.
Кого и как тестировали
В качестве соперника взяли IBM Granite-8B-Code-Instruct — модель, которая на бумаге отлично подходит для кода и инструментов. Granite-8B-Code-Instruct давалась в стандартном Q4_K_M квантизации (она помещается в 8 ГБ RAM). Bonsai-8B — её родная 1-битная версия (BitNet b1.58). Обе модели запускались на одном и том же ноутбуке с Intel Core i7-13620H, 32 ГБ ОЗУ, без видеокарты. Использовался свежий билд llama.cpp с поддержкой BitNet и GBNF-грамматиками для принудительного формирования корректного JSON tool call.
| Параметр | Bonsai-8B (1-bit) | IBM Granite-8B-Code-Instruct (Q4_K_M) |
|---|---|---|
| Точность tool calling (без грамматики) | 78.2% | 84.5% |
| Точность tool calling (c GBNF) | 96.3% | 92.1% |
| Среднее время на 1 вызов (сек) | 3.2 | 4.8 |
| Пиковое потребление RAM | 2.1 ГБ | 6.3 ГБ |
Цифры говорят сами за себя. Без грамматики Granite предсказуемо выигрывает — у неё нет потерь от 1-битного сжатия. Но как только мы включили GBNF-грамматику, которая валидирует JSON на уровне токенов, Bonsai резко обошла Granite. Почему? 1-битная модель меньше шумит, и при жёстком ограничении формы вывода она реже генерирует промежуточные токены, нарушающие структуру. Granite же в Q4_K_M иногда «перекручивала» — из-за того, что токены предсказывались слишком уверенно, и грамматика обрезала много правильных вариантов.
GBNF: магия, превращающая «кашу» в JSON
Грамматически ограниченная декодировка — это не просто бонус, а ключевой ингредиент для 1-битных моделей. Мы использовали стандартную GBNF-грамматику для OpenAI-совместимых tool calls, которая заставляет модель генерировать только разрешённые последовательности токенов. Без неё Bonsai-8B иногда «забывала» закрыть скобку или вставляла лишние пробелы, а с ней — выдавала безупречный JSON. Забавно, что аналогичный приём с GBNF здорово выручает и другие квантизованные модели, но для 1-битных это буквально спасательный круг.
{"name": "get_weather", "parameters": {"city": "Moscow"}}. Без грамматики могла выдать что-то вроде {"name": "get_weather", "parameters": {"city": "Moscow"} } (лишний пробела перед скобкой, который ломает парсинг в строгих схемах).Почему Bonsai-8B быстрее и легче?
Секрет не только в 1 бите на параметр, но и в оптимизациях llama.cpp под BitNet. Как показали тесты ARIA Protocol, BitNet b1.58 на AVX-512 может работать даже быстрее, чем 8-битный квант того же размера. Но тут есть нюанс: Bonsai-8B физически весит ~1.5 ГБ (против 5+ ГБ для Granite Q4), и загрузка/выгрузка памяти происходит мгновенно. Для продакшен-сервисов, где каждый вызов — это ещё и latency на переключение контекста, такой размер даёт огромное преимущество.
Любопытно, что даже более крупные 1-битные модели, как GPT-OSS 120B в 1-бите, демонстрируют высокую скорость на CPU, но их точность tool calling пока не тестировалась. Возможно, в ближайшее время мы увидим подобные бенчмарки для них.
Где Bonsai-8B всё-таки проигрывает (и где это не важно)
В задачах на свободную генерацию текста (суммаризация, креатив) Bonsai-8B заметно уступает Granite — 1 бит слишком агрессивно сжимает лексическое разнообразие. Но для tool calling это почти не имеет значения: здесь важна структура, а не красота фраз. Кроме того, модель не умеет обрабатывать длинные диалоги (>8K токенов) без потери точности — контекстное окно в 8K у неё меньше, чем у Granite (32K). Однако для коротких агентских вызовов — идеально.
Сравнение с другими «малышами»
Мы также включили в бенчмарк несколько маленьких моделей из обзора «11 маленьких LLM на CPU: какой размер действительно работает для tool-calling?». Ни одна из них (даже лучшая модель ~3B параметров) не достигла точности Bonsai-8B с GBNF выше 95%. ZAYA1-8B от Zyphra показала 88% — тоже неплохо, но проигрывает Bonsai по скорости. А Gemma 3 270M — крошечная модель — с грамматикой выдала лишь 45%, так что ультра-малые размеры для tool calling пока не годятся.
Кому эта новость — спасение, а кому — нет
- Разработчикам AI-агентов: Если вы строите что-то вроде автономного помощника для телеграм-бота или внутренней системы тикетов — Bonsai-8B с GBNF даёт скорость и точность на обычном CPU. Берите, не пожалеете.
- Хоум-лаборантам: У вас дома сервер на Intel N100 или старый ноутбук? Один гигабайт RAM под модель — и у вас полноценный агент с tool calling. 40-миллиардные модели тут излишни.
- Продакшен-инженерам: Если нужна гарантированная точность 99%+ для критических вызовов — пока рано. Bonsai-8B + GBNF дают 96%, но остальные 4% — это ошибки вложенных параметров или неправильный выбор функции. Для банковских транзакций риск велик.
Мой прогноз: в 2026 году 1-битные модели на CPU займут нишу лёгких агентов для умных домов и edge-устройств. А пока что Bonsai-8B — лучший выбор, если нужно дёшево и сердито вызывать инструменты. Интересно, что ZAYA1-8B на AMD тоже неплохо справляется, но Bonsai-8B с GBNF — бесспорный лидер среди крошечных моделей для tool calling.
