The post has been translated automatically. Original language: Russian
I took one Qwen3.8-27B model in two versions, compressed ternary (Bonsai 2 27B). I ran both through the same tasks on a MacBook Pro M3 Max, 32 Gb.
Two versions of the same model
The first Ternary is Bonsai-2-27B from the Prism ML team. This is the same Qwen3.8-27B, but squeezed in an unusual way: instead of the usual 16 or 8 bits per weight, "ternary" quantization is used there — each weight is stored with only three possible values (-1, 0, +1), plus a mathematical trick with the rotation of the scales (Hadamard rotation), which compensates for some of the losses from such a hard compression. This adds up to about 1.7 bits per weight — a model with 27 billion parameters weighs only 6-7 GB on a disk.
The second is the usual Qwen3.8-27B in Q4_K_M quantization. This is a classic compression option that most people who drive models locally use: about 4-5 bits per weight, without exotics, just neatly trimmed accuracy.
There is a big difference in approaches, the ultimate goal is the same, a model with 27 billion parameters in the memory of a regular laptop without a data center graphics card.
What I had to set up
The ternary Bonsai format is not a standard thing, but a regular one llama.cpp it doesn't understand it (either refuses to run it, or it runs it and throws garbage). I had to build a fork from Prism ML itself (PrismML-Eng/llama.cpp ), which has the necessary cores for this format.
Then I connected it to the web interface llama.cpp several MCP servers at once — Context7, Hugging Face, Exa, Cloudflare Docs, DeepWiki and Playwright (gives the model a browser). Interestingly, Playwright did not want to connect because of CORS (it is treated with the llama server proxy flag) and could not find the browser (by default, Playwright searches for the system Chrome, not its built—in Chromium - it was solved with one flag).
I drove both models through the same setup so that the comparison was fair.
We write and check the code
I gave both of them the same simple, but with a catch, task to write a TypeScript function that combines overlapping intervals, plus tests for extreme cases.
Then I decided to run their code through node --test, like real tests.
The result turned out to be more interesting than I expected. The logic of merging intervals in both models turned out to be working. There was no difference between ternary compression and regular compression. But both models stumbled on the self-test, and in different ways.:
- Bonsai had one of its own tests written with an error, not in the code, but in the test itself: the expected result was incorrectly entered. The code was correct, but the test was not.
- For the usual Qwen (Q4_K_M), the bug turned out to be in the code itself: with certain input data, the function imperceptibly spoils the source array, although it should not. The model even wrote a test specifically for this case, but by a happy (for her) coincidence, the test data did not touch the problematic scenario, and the test passed, creating a false feeling that everything was in order. I picked up another set of numbers and ran the code again — the bug was confirmed.
The conclusion is simple: both models of the same caliber write a working code.
What does this mean for local models "for themselves"?
If we draw a general conclusion from this whole experiment, here's what I learned for myself about using such models on my own machine, without a cloud:
- 27B on a mac is real. With compression (which is ternary, which is regular Q4), a model of this size quietly spins on a laptop with 32 GB of memory and produces sane, working results, rather than a stream of random text.
- Exotic quantization is not necessarily worse than usual. Ternary compression of 1.7 bits sounds like something that should have broken everything, but in fact, on tasks of the "write a function and a test" level, there was almost no difference in code quality compared to regular Q4.
- The main risk is not in the code, but in trusting the self-report of the model. Both models confidently said "ready, tested," and both made a mistake at the self-test stage. For personal use, this means one thing: if the model wrote something and said "I checked it" herself, this is a signal to double-check yourself, and not a reason to relax.
- The local model is no longer a toy, but a working tool. With the support of tools (MCP, browser) and connection directly to the code editor, this model closes quite work tasks on your computer without sending anything to the cloud — which is really convenient for personal or experimental projects.
Взял одну модель Qwen3.8-27B в двух версиях, сжатую тернарную (Bonsai 2 27B). Прогнал обе через одинаковые задачи на MacBook Pro M3 Max, 32 Gb.
Две версии одной модели
Первая Ternary-Bonsai-2-27B от команды Prism ML. Это та же Qwen3.8-27B, но пережатая необычным способом: вместо привычных 16 или 8 бит на вес там используется "тернарное" квантование — каждый вес хранится всего тремя возможными значениями (-1, 0, +1), плюс математический трюк с вращением весов (Hadamard rotation), который компенсирует часть потерь от такого жёсткого сжатия. В сумме получается около 1.7 бита на вес — модель на 27 миллиардов параметров весит на диске всего 6-7 ГБ.
Вторая обычный Qwen3.8-27B в квантовании Q4_K_M. Это классический вариант сжатия, которым пользуется большинство людей, гоняющих модели локально: около 4-5 бит на вес, без экзотики, просто аккуратно урезанная точность.
Разница в подходах большая, конечная цель одна, модель на 27 млрд параметров в память обычного ноутбука без видеокарты дата-центра.
Что пришлось настроить
Тернарный формат Bonsai — штука не стандартная, обычный llama.cpp его не понимает (либо отказывается запускать, либо запускает и выдаёт мусор). Пришлось собирать форк от самой Prism ML (PrismML-Eng/llama.cpp), в котором есть нужные ядра для этого формата.
Дальше подключил к веб-интерфейсу llama.cpp сразу несколько MCP-серверов — Context7, Hugging Face, Exa, Cloudflare Docs, DeepWiki и Playwright (даёт модели браузер). Из интересного: Playwright не хотел коннектиться из-за CORS (лечится флагом-прокси у llama-server) и не мог найти браузер (Playwright по умолчанию ищет системный Chrome, а не свой встроенный Chromium — решилось одним флагом).
Обе модели гонял через одинаковый сетап, чтобы сравнение было честным.
Пишем и проверяем код
Дал обеим одну и ту же простую, но с подвохом, задачу написать TypeScript-функцию, объединяющую пересекающиеся интервалы, плюс тесты на крайние случаи.
Тут я решил прогнать их код через node --test, как настоящие тесты.
Результат оказался интереснее, чем я ожидал. Сама логика слияния интервалов у обеих моделей оказалась рабочей тут разницы между тернарным сжатием и обычным не нашлось. А вот споткнулись обе модели именно на самопроверке, причём по-разному:
- У Bonsai один из собственных тестов был написан с ошибкой, не в коде, а в самом тесте: неправильно вписан ожидаемый результат. Код был верным, тест — нет.
- У обычного Qwen (Q4_K_M) баг оказался в самом коде: при определённых входных данных функция незаметно портит исходный массив, хотя не должна. Модель даже написала тест специально на этот случай — но по счастливой (для неё) случайности тестовые данные не задели проблемный сценарий, и тест прошёл, создав ложное чувство, что всё в порядке. Я подобрал другой набор чисел и прогнал код заново — баг подтвердился.
Вывод простой: обе модели одного калибра пишут рабочий код.
Что это значит для локальных моделей "для себя"
Если вынести общий вывод из всего этого эксперимента — вот что я для себя вынес про использование таких моделей на своей же машине, без облака:
- 27B на маке это реально. С сжатием (что тернарным, что обычным Q4) модель такого размера спокойно крутится на ноутбуке с 32 ГБ памяти и выдаёт вменяемые, рабочие результаты, а не поток случайного текста.
- Экзотика в квантовании не обязательно хуже привычной. Тернарное сжатие в 1.7 бита звучит как что-то, что должно было всё сломать, но по факту на задачах уровня "напиши функцию и тест" разницы в качестве кода почти не почувствовалось по сравнению с обычным Q4.
- Главный риск не в коде, а в доверии к самоотчёту модели. Обе модели уверенно говорили "готово, протестировано", и обе в чём-то ошиблись именно на этапе самопроверки. Для личного использования это значит одно: если модель что-то написала и сама же сказала "я это проверил" — это сигнал перепроверить самому, а не повод расслабиться.
- Локальная модель уже не игрушка, а рабочий инструмент. С поддержкой инструментов (MCP, браузер) и подключением прямо в редактор кода такая модель у себя на компьютере закрывает вполне рабочие задачи, не отправляя ничего в облако — что для личных или экспериментальных проектов реально удобно.
Share
