27Bモデルを9分の1に圧縮、性能98.2%を維持したBonsai 2 27B
Bonsai 2 27B: Near-Lossless Compression in a 9x Smaller Footprint
Prism MLがQwen3.8 27BをベースにしたTernary Bonsai 2 27Bを公開した。3値重みとFP16グループスケーリングで実効1.76ビット/重み、モデル全体で5.9GBに収めながら、集計ベンチマーク性能の98.2%を維持。262Kトークンのコンテキストとマルチモーダル入力に対応し、RTX 5090で毎秒143トークン、M5 Maxで46.8トークンを達成。Apache 2.0ライセンスで公開され、CUDAとMLX上で動作する。
圧縮はデプロイの扉を開く。ほぼ同じ能力を、はるかに多くの場所で動かせるフットプリントで実現する。
HNでの議論
172- simonw
https://huggingface.co/prism-ml/Ternary-Bonsai-2-27B-gguf#th... のGGUFを試してみたい人は、動かすにはPrismのllama.cppフォークが必要なことに注意してほしい。https://github.com/PrismML-Eng/llama.cpp/releases/tag/prism-... から入手できる。
これは動くはず:
cd /tmp
# Get the Prism macOS runtime
curl -fL https://github.com/PrismML-Eng/llama.cpp/releases/download/prism-b10685-7dffb15/llama-prism-b10685-7dffb15-bin-macos-arm64.tar.gz -o bonsai-runtime.tar.gz
tar -xzf bonsai-runtime.tar.gz
# Get the ~5.95 GB GGUF model:
curl -fL https://huggingface.co/prism-ml/Ternary-Bonsai-2-27B-gguf/resolve/main/Ternary-Bonsai-2-27B-PTQ1_0.gguf -o Ternary-Bonsai-2-27B-PTQ1_0.gguf
# Run the server, I used port 8331
./llama-prism-b10685-7dffb15/llama-server \
-m Ternary-Bonsai-2-27B-PTQ1_0.gguf \
--port 8331 -ngl 99 -fa on -c 32768
あとは http://localhost:8331 を開けば（とてもよく出来た）組み込みのllama-server Web UIが使える…あるいはAPI経由でこんな感じでプロンプトを投げられる:
uvx llm openai endpoint http://127.0.0.1:8331/v1 \
--model bonsai-2-27b --responses hi
自分のM5 Proだと約20 token/秒で動いている（サーバーを再起動したら44 token/秒になった、理由はよく分からない）。ただ、何かが正しく動いていないのはほぼ確実で、起動時にサーバーが「ggml_metal_device_init: - the tensor API is not supported in this environment - disabling」と言っていた。
- miffy900
比較をするときに「〜よりN倍小さい」と言うのを本当にやめてほしい。そんなの意味が通らない——正しくは1/9（11.11%）のサイズだ。1.0より大きい数を掛けても量は小さくならない。代わりに比較する主語を逆にして「元のモデルはこの新しい効率的な小さいモデルより9倍大きい」みたいに言えばいい。そちらのほうが筋が通っている。
効率や性能の向上について話すときにこれが使われているのをよく見かけるけど、ただただ直感的でない言葉遣いだ。
- Aurornis
これらは小さいので、完全にブラウザ内で動かせる https://huggingface.co/spaces/webml-community/ternary-bonsai...
後でダウンロードした重みを消すのを忘れずに。
前のモデルと同様、これだけうまく動くのは驚きだ。少し長めのタスクに使うと、見事に、そして面白い形で崩壊する。
- adrian17
> Ternary Bonsai 2 27B uses ternary {−1, 0, +1} weights with FP16 group-wise scaling, for 1.76 effective bits per weight
記憶が正しければ、最近の投稿[1]で、同じベースのQwenモデルのQ2量子化（2.6 bpw程度）が「明らかに劣る」とQ1の「使い物にならない」の境目に位置することが示されていた。Bonsaiのブログ記事をざっと見たが、「典型的な」量子化との比較や、彼らをより良くしている秘伝のタレが何なのかの説明は見当たらなかった。
- huseyinkeles
MBP m4 pro 24gbでテスト
prefill約100t/s、約15t/s、64kコンテキストでは後半10t/s程度まで低下。
問題は、このマシンで動かせる有用なエージェント型ローカルLLMにまだ出会えていないことだ。
Swiftアプリでの比較的単純なタスクを与えただけで25分かかり、あれこれ必死にブレインストーミングするけど何をすべきか決められない。結局killした。参考までに、同じタスクをGPT 5.6 sol-mediumは3分で完了した。
- danbrooks
いいね！このモデルのUnsloth量子化と比べてどうなのか知っている人はいる？
- zhiyan
素晴らしい結果だ。多くの人に扉を開くね。
- jedbrooke
Mac Mini M2 16GBで約7-8 tok/s（prefill約60 tok/s）で動いている。
今のところBonsai 1 27Bより賢い感じがする。Q1_0量子化より少し大きいくらい。めちゃくちゃワクワクする :)