Обзор Ternary-Bonsai-2-27B-gguf: 27B модель на тритных весах в 5,9 ГБ — что изменилось против первой версии

Введение

В июле 2026 Prism ML выпустила Bonsai 27B — первую попытку упаковать 27-миллиардную модель в тритные веса (−1, 0, +1) с потерей всего ~5% качества. Тогда базой служила Qwen3.6-27B, а о первой версии мы уже писали подробно: когда 27B параметров помещается в карман.

В сентябре 2026 команда выпустила Bonsai 2 27B — второе поколение под репозиторием prism-ml/Ternary-Bonsai-2-27B-gguf. База сменилась на Qwen3.8-27B (dense VLM с мультимодальностью), заявленная сохранность интеллекта выросла до 98,2% от FP16 при том же footprint в ~5,9 ГБ. В этой статье — что именно изменилось: методика, бенчмарки, размеры квантов и на чём модель всё ещё проигрывает полной точности.

Что такое тритное представление: напоминание для тех, кто пропустил первую версию

Классическое квантизация GGUF (Q4_K_M, IQ2_XXS) сжимает веса до 4 или ~2 бит, но каждый вес остаётся произвольным числом в диапазоне. Тритный подход радикальнее: каждый вес принимает ровно одно из трёх значений — −1, 0 или +1. Информация о величине выносится в общий FP16-масштаб на группу из 128 весов (g128).

Эффективная плотность хранения получается такой:

Для сравнения: Q4_K_M — это 4,83 бит/вес, IQ2_XXS — ~2,06 бит/вес. Тритный Bonsai 2 в ~2,8 раза плотнее Q4_K_M и даже плотнее самых агрессивных «обычных» квантов.

💡 Практический смысл: модель влезает не только в одну потребительскую GPU (5,9 ГБ — меньше, чем любой Q4_K_S), но и целиком в оперативную память ноутбука вместе с KV-кэшем для длинного контекста. Это меняет класс задач: локальный reasoning на 27B перестаёт требовать серверное железо.

Ключевая инновация второй версии — поворотная база. Веса хранятся не в исходном базисе, а после блочного преобразования Хадамар (блок 1024, фиксированные знаки ±1), которое «вплетено» в сами хранимые веса. На инференсе соответствующее преобразование применяется к активациям — без дополнительных бит и трафика памяти. Это позволяет тритной сетке сохранять распределение признаков ближе к FP16, чем наивное пороговое округление.

Что нового во второй версии: база, размер, мультимодальность

Первая версия Bonsai 27B строилась на Qwen3.6-27B и предлагала два варианта: тритный (1,71 бит/вес) и бинарный 1-bit (1,125 бит/вес). Во второй версии линейка упрощена до двух GGUF-файлов на языке модели:

Бинарный 1-bit вариант из первой версии во вторую не перенесён — видимо, команда сочла его избыточным: тритная версия уже покрывает сценарий «модель в телефоне», а бинарная сильнее всего теряла именно в tool calling и агентных задачах (80,0 → 66,0 по данным первых тестов).

Отдельно поставляется vision tower — Q8_0 mmproj-пакет на ~0,63 ГБ. Мультимодальность здесь не «на всякий случай»: база Qwen3.8-27B — это 24,35B языкового бэкбона + 2,54B эмбеддингов/LM head + 0,46B vision tower. Поддержка контекста до 262K токенов заявлена официально.

⚠️ Важно понимать: это не «квантование готового GGUF», а полное представление модели в тритной форме — от эмбеддингов и attention-проекций до MLP и LM head. Методология описана в whitepaper, ссылка на который есть в репозитории. Повторить результат «на коленке» инструментами из коробки не получится — это собственная инженерия Prism ML (ядра llama.cpp для нативной тритной упаковки по-прежнему нет: PQ2_0 «обслуживается в 2-битных слотах», а нативные тритные ядра заявлены как активная цель разработки).

Бенчмарки: 98,2% от FP16 — и где именно теряются оставшиеся 1,8%

Оценка проведена через EvalScope + vLLM на NVIDIA H100, thinking-режим, 14 бенчмарков. Средний балл тритной версии — 84,78 против 86,32 у FP16 базы (98,2% сохранности). Для первой версии заявлялось ~95%, так что прирост заметный.

Агрегированные группы: математика 96,57, кодинг 89,42 — оба практически на уровне FP16. Разрыв концентрируется в двух местах:

1. Знания и рассуждения: 79,86 против 85,55 у FP16 (−5,7 п.п.). Тритное представление хуже хранит «тонкие» фактологические ассоциации — именно то, что в классической теории квантизации страдает первым при снижении разрядности весов эмбеддингов и attention.

2. Vision: 66,19 против 71,36 (−5,2 п.п.). OCR Bench v2 с его 56,88 — самый низкий балл таблицы: чтение мелкого текста со скриншотов остаётся уязвимым местом даже при том, что vision tower хранится в Q8_0 и не трогался квантованием. Значит, потери идут на стыке языковой части и визуальных признаков — там, где тритные веса теряют точность интеграции мультимодальных представлений.

Ещё один показательный балл — BFCL v3 (74,92). Это tool calling: способность модели корректно вызывать внешние функции по JSON-схеме. Для агентных сценариев это критично, и здесь тритная модель уже заметно уступает FP16. В первой версии бинарный вариант терял в tool calling ещё сильнее (80,0 → 66,0), так что тритное представление проблему не сняло, а лишь смягчило.

Скорость: цифры авторов и оговорки

В репозитории заявлены два ориентира генерации: ~28 токенов/с на M5 Pro (ноутбук, CPU+ANE) и ~130 токенов/с на RTX 5090. Оба числа — из README Prism ML, независимых замеров в момент написания статьи мы не проводили.

Контекст для сравнения: Qwen3.8-27B в Q6_K_M (≈21 ГБ) на нашей связке двух RTX 5060 Ti даёт порядка 25–30 токенов/с генерации. То есть тритный файл вдвое быстрее при том, что занимает меньше шестой части памяти — и это без учёта того, что KV-кэш для длинного контекста влезает целиком на диск или в RAM, а не вытесняет модель из VRAM.

⚠️ Оговорка про «130 токенов/с на 5090»: PQ2_0 сегодня обслуживается через 2-битные слоты, а нативная тритная упаковка в llama.cpp ещё не реализована. Когда Prism ML выпустит native ternary kernels (это прямо заявлено как ближайшая инженерная цель), скорость и энергопотребление должны вырасти — часть выигрыша от плотности представления сейчас «заперта» в обходном пути через 2-битные слоты.

Сравнение с альтернативами: что выбрать под конкретную задачу

Вывод по выбору: PTQ1_0 — это новая точка Pareto для локального reasoning. Если задача — «мне нужен 27B-уровень математики и кодинга на домашнем железе», альтернатив с сопоставимым footprint у классических квантов нет (IQ2_XXS при ~2 битах/весе даёт заметно худшие бенчмарки). Если задача — продакшн-агент с интенсивным tool calling или OCR документов, тритная версия пока не заменяет Q4/Q8.

💡 Практический совет: перед внедрением в рабочий процесс прогоните свою конкретную задачу (не MMLU, а реальные промпты) на PTQ1_0 и на ближайшем Q4_K_M. Разрыв в 5–7 п.п. по бенчмаркам знаний может оказаться незаметным для вашего домена — или критичным, если задача фактологическая (правовые тексты, медицинские справочники).

Вайб-кодинг и «модель из коробки»: где начинается реальная работа

Лёгкость развёртывания — 5,9 ГБ на любой ноутбук — провоцирует иллюзию, что «просто скачать GGUF и всё заработает». На практике вопросы начинаются сразу:

• Интеграция в пайплайн. Тритные ядра llama.cpp ещё не native: PQ2_0 ходит через 2-битные слоты. Если вы строите сервис, нужно понимать, что производительность зависит от версии llama.cpp и её поддержки форматов PTQ1_0/PQ2_0 — это не «всё GGUF одинаково».

• Tool calling в агентных системах. BFCL 74,92 означает, что часть вызовов функций будет ошибочной. В продакшн-агенте это либо ретраи с удвоением затрат на токены, либо откат на более точную модель для критичных шагов. Архитектура «одна маленькая модель на всё» здесь не работает — нужна маршрутизация по типу задачи.

• Безопасность промптов. Меньшая модель в локальном контуре — это и меньший риск утечки данных наружу, но и более хрупкая защита от prompt injection: тритное представление сильнее сжимает «запас прочности» внимания модели к инструкциям. Если сервис принимает внешние данные, фильтрация на входе обязательна вне зависимости от размера модели.

Команды, которые доверяют критичные задачи опытным разработчикам, экономят время и деньги на исправлении ошибок, которые могли быть предотвращены на этапе проектирования: выбор 5,9 ГБ тритной модели — это архитектурное решение, а не просто «скачал файл».

Рекомендации по использованию

1. PTQ1_0 — дефолтный выбор для локального reasoning и кодинга на ноутбуке или одной GPU.

2. PQ2_0 — если есть 8–16 ГБ свободной памяти и хочется чуть выше качество без перехода в Q4.

3. Не используйте тритную версию как единственную модель в агенте с tool calling: маршрутизируйте критичные вызовы на Q4_K_M или выше.

4. Vision-задачи (OCR, чарты) — пока лучше закрывать более точным квантом или отдельной специализированной моделью.

5. Следите за native ternary kernels в llama.cpp: это заявленная ближайшая цель Prism ML, и после релиза скорость на GPU вырастет без изменения качества.

Заключение

Bonsai 2 27B — второй шаг Prism ML в том же направлении, что и первая версия, но с заметно более сильной базой (Qwen3.8-27B) и более зрелой методикой: поворотная база Хадамаром позволила поднять сохранность интеллекта с ~95% до 98,2%. Математика и кодинг практически не теряют от тритного представления, знания и vision — теряют на 5–6 п.п., tool calling остаётся уязвимым местом.

Для локального использования это пока лучшая точка соотношения «размер/качество» в классе 27B: 5,9 ГБ против ~16–17 ГБ у Q4_K_M при цене в 5–7 п.п. на фактологических задачах. Если ваша задача — reasoning и код на домашнем железе, скачивайте PTQ1_0 сегодня. Если задача — продакшн-агент с интенсивным вызовом функций или чтение документов, подождите native ternary kernels и/или оставайтесь в Q4/Q8.

Источники

• prism-ml/Ternary-Bonsai-2-27B-gguf — Hugging Face

• PrismML — Introducing Bonsai 2 27B: Near-Lossless Compression in a 9x Smaller Footprint

• Bonsai-demo и whitepaper (GitHub PrismML-Eng)

• Ternary-Bonsai-27B-gguf — первая версия (Hugging Face)

• MarkTechPost: PrismML Releases Bonsai 27B — 1-bit and Ternary Builds of Qwen3.6-27B

• Обзор первой версии Bonsai 27B в нашем блоге