PrismML が Qwen3.6-27B の軽量版「Bonsai 27B」をリリース：ラップトップやスマートフォンで動作する 1 ビットおよび 3 値モデル
PrismML は Qwen3.6-27B のアーキテクチャを変更せず、1 ビットおよび 3 値化（Ternary）による高圧縮モデル「Bonsai」を公開し、ラップトップやスマートフォンでの動作を可能にした。
キーポイント
極限の圧縮技術とサイズ削減
1.71 ビット/重み（3 値）および 1.125 ビット/重み（バイナリ）の実装により、モデルサイズをそれぞれ約 5.9GB および 3.9GB に圧縮し、FP16 版と比較して最大 14.2 倍の削減を実現した。
高精度な推論性能の維持
15 のベンチマーク評価において、3 値化モデルはベースラインの 94.6%、1 ビットモデルでも 89.5% の性能を維持し、従来の低ビット量化モデルに見られる精度崩壊（collapse）を防いでいる。
モバイル・エッジデバイスへの適応
iOS のメモリ制限（物理メモリの約半分がアプリ利用可能）を考慮した設計により、12GB iPhone などのスマートフォンでも動作可能なサイズを実現し、KV キャッシュの最適化も含まれている。
既存手法との技術的差異
BitNet のような事前学習からの再構築を必要とせず、既存の Qwen3.6-27B アーキテクチャを維持したまま圧縮に成功しており、特に数学やコーディングなどの複雑な推論タスクで優位性を示している。
極限の圧縮とメモリ効率
Ternary（3値）化によりFP16の94.6%、1-bit化でも89.5%の性能を維持しつつ、それぞれ5.9GB・3.9GBという驚異的なサイズでiPhoneやラップトップに搭載可能。
DSpark 推論加速技術
専用ドラフターと併用することでH100環境で1.37倍の速度向上を実現し、検証ロスレス（出力分布が同一）を保証する。
多様なデプロイメント対応
ローカルエージェント、オンデバイス推論、プライバシー重視ワークフローに対応し、24GB GPUでも27Bクラスの品質で単一GPU運用が可能。
影響分析・編集コメントを表示
影響分析
この発表は、大規模言語モデルがクラウド依存からエッジデバイス（スマートフォンやラップトップ）へシフトする際の最大の障壁であった「メモリ容量と推論精度のトレードオフ」を劇的に解消する可能性を示しています。特に、既存の高性能モデルを事前学習なしで極限まで圧縮できる手法は、開発コストを削減しつつローカル AI アプリケーションの実用化を加速させる重要な転換点となるでしょう。
編集コメント
「1 ビット」という極限の数値を達成しつつ、数学やコーディングといった高難易度タスクで精度が崩壊しない点は、技術的に極めて注目に値します。これにより、クラウドなしで動作する次世代のローカル AI アプリケーション開発が現実味を帯びてきました。
PrismML が「Bonsai 27B」をリリースしました。これは Qwen3.6-27B の低ビット表現であり、新しい事前学習モデルではありません。アーキテクチャ自体も変更されていません。
Apache 2.0 ライセンスで提供されるのは 2 つのバリアントです。1 つ目は「Ternary Bonsai 27B」で、重みを {−1, 0, +1} の 3 値に制限し、実質的に 1 ワットあたり 1.71 ビットの密度を実現しています。理想サイズは約 5.9GB です。2 つ目は「1-bit Bonsai 27B」で、重みを {−1, +1} のバイナリ値に限定し、1 ワットあたり 1.125 ビット、サイズは約 3.9GB に抑えられています。
どちらもマルチモーダルモデルです。パラメータ構成は言語重みが約 248 億、ビジョンタワーが 0.46 億、埋め込み層と LM ヘッドに 25 億となっています。ビジョンタワーは別個に 4 ビット（HQQ）で保持され、コンテキスト長は 26 万トークンです。これは Qwen3.6-27B のアテンションの約 75% が線形計算であるため、実用的な範囲内に収まっています。
(function(){
window.addEventListener('message', function(e){
if(e.data && e.data.mtpBonsaiHeight){
var f = document.getElementById('mtp-bonsai-27b-frame');
if(f){ f.style.height = e.data.mtpBonsaiHeight + 'px'; }
}
});
})();
このアーキテクチャが、以下の圧縮手法の基盤となっています。
圧縮の仕組み
各重みはコードとして扱われ、128 個のグループごとに共有される FP16 スケール係数が 1 つ付加されます。実際の重み値は w_i = s_g · t_i で計算されます。
3 値（Ternary）の場合、1 値あたり log2(3) ≈ 1.585 ビットの情報量を持ちます。これに 128 個の重みにつき 1 つの FP16 スケール（16/128 ビット分）を加えると、1 ワットあたりの平均ビット数は約 1.71 となります。これは従来の FP16 と比較して約 9.4 倍の圧縮率です。
バイナリ（Binary）の場合、1 値あたり 1 ビットに抑えられ、スケール係数を加えても合計 1.125 ビットになります。これにより、FP16 と比べて約 14.2 倍の圧縮を実現しています。
このモデルの表現は、行列演算を多用する主要コンポーネント全体にわたって完結しています。具体的には埋め込み層、アテンション投影層、MLP 投影層、そして言語モデル出力ヘッドが該当します。正規化やスケールパラメータなど、わずかな尾部部分のみが高精度で保持されます。
真の平均値として測定すると、Qwen3.6-27B の「4 ビット版」（Q4_K_XL）は重みあたり 5.2 ビット、「2 ビット版」（IQ2_XXS）は 2.8 ビットです。また Bonsai は BitNet とも異なり、崩壊を防ぐためにゼロから事前学習を行うというアプローチを採用しています。
当然ながら、精度をどの程度犠牲にするかが最大の疑問点となります。
パフォーマンス
PrismML は H100 GPU 上で vLLM を用いた EvalScope を活用し、思考モードで 15 のベンチマークを実施しました。その結果、Ternary Bonsai 27B は FP16 ベースラインの 94.6%、1-bit Bonsai 27B は 89.5% の性能を維持しています。
| バリアント | True bpw | フットプリント | Thinking avg | Density (1/GB) |
|---|---|---|---|---|
| Qwen3.6-27B FP16 | 16.0 | 54GB | 85.07 | 0.051 |
| Qwen3.6-27B Q4_K_XL（"4-bit"） | 5.2 | 17.6GB | 84.99 | 0.155 |
| Qwen3.6-27B IQ2_XXS（"2-bit"） | 2.8 | 9.4GB | 72.73 | 0.199 |
| Ternary Bonsai 27B | 1.7 | 5.9GB | 80.49 | 0.400 |
| 1-bit Bonsai 27B | 1.12 | 3.9GB | 76.11 | 0.530 |
| カテゴリ | FP16 | Ternary | 1-bit |
|---|---|---|---|
| Math | 95.33 | 93.40 | 91.66 |
| Coding | 88.74 | 85.96 | 81.88 |
| Knowledge and reasoning | 83.15 | 76.96 | 73.39 |
| Agentic and tool calling | 80.00 | 74.01 | 66.03 |
| Instruction following | 78.47 | 71.77 | 65.74 |
| Vision | 72.61 | 65.19 | 59.57 |
従来のサブ 4 ビットモデルでは、崩壊の仕方が異なります。IQ2_XXS は AIME26 で 57.5、LiveCodeBench で 56.4 にまで低下しますが、MMLU-Redux では依然として 88.93 を記録しています。これは短尺ベンチマークでは崩壊が隠蔽されてしまうことを示唆しています。Gemma-4-31B の Q2_K_XL モデルでも同様のパターンが確認されています。
しかし、スコアだけではこのリリースの背景は説明できません。鍵となるのは「メモリ」です。
メモリこそが最大の制約条件
スマホへの搭載は、単なるストレージ容量の数値以上の厳しい要件を課します。iOS では、1 つのアプリが使用できるメモリは物理メモリの半分程度に制限されています。したがって、12GB の iPhone であっても、実際に利用可能なのは約 6GB です。
次に重要なのが KV キャッシュ（Key-Value Cache）の確保です。全 64 レイヤーのうち、増大するフルアテンションキャッシュを保持するのは 16 レイヤーのみですが、それでも FP16 形式ではトークンあたり約 64 KiB のコストがかかります。262K トークンのコンテキストウィンドウを想定すると、その容量は約 17.2GB に達します。しかし、KV キャッシュを 4 ビット量化すれば、この数は約 4.3GB に削減可能です。
許容誤差の範囲も実測されています。FP16-KV ベースラインと比較した場合、Ternary Bonsai の MATH-500 における出力前方 KL 発散値はわずか 0.0011 nats です。一方、Q4_K_XL では 0.0146 となっています。
ピーク時のメモリ使用量も確認済みです。FP16 キャッシュを使用し 100K トークン処理を行う場合、1-bit モデルは約 11.6GB、Ternary モデルは約 14.7GB を必要とします。一方、導出された Q4_K_XL の行では約 25.6GB が必要となります。
モデルがメモリに収まるかどうかが決まれば、次はスループット（処理速度）の問題です。
スループットと DSpark による推測的デコーディング
| プラットフォーム | バリアント | tg128 | pp512 |
|---|---|---|---|
| M5 Max | Binary | 66.4 | 874 |
| M5 Pro | Ternary | 26.2 | 393 |
| iPhone 17 Pro Max | Binary | 11.0 | 111 |
| H100 (CUDA) | Binary | 104.8 | 2755 |
生成処理はメモリ帯域幅にボトルネックがあるため、1 ステップあたりのデータ量が少なければ少ないほど、1 秒間に生成できるトークン数は増えます。一方、プリフィル（初期処理）は計算リソースに依存するため、その恩恵は限定的です。
PrismML はまた、Bonsai 27B ターゲット向けに訓練された DSpark ドラフターも提供しています。H100 でドラフト深さ k=4 の条件下では、Binary モデルの平均受容長 τ は 3.6 に達します。これは 1 秒あたり 143.8 トークンという速度で、1.37 倍の高速化を実現しています。検証プロセスはロスレス（情報損失なし）であるため、出力分布は元のモデルと完全に同一に保たれます。Apple Silicon 上では、バッチサイズが 1 の場合、デフォルトでドラフターは無効化されています。
実際に動かしてみる
Ternary 27B がデモリポジトリのデフォルト設定です。サーバーを起動するか、直接生成を実行してください。
./scripts/start_llama_server.sh # OpenAI 互換 API とチャット/ビジュアル UI を :8080 で提供
./llama-cli -m ./Ternary-Bonsai-27B-gguf/Ternary-Bonsai-27B-Q2_0.gguf \
--mmproj ./Ternary-Bonsai-27B-gguf/mmproj.gguf -c 0 \
-p "Explain KV cache growth."
mlx_lm.generate --model prism-ml/Ternary-Bonsai-27B-mlx-2bit \
--prompt "Explain KV cache growth."
ツール呼び出しは、標準的な OpenAI スタイルのツール配列を使用します。
curl http://localhost:8080/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"messages": [{"role": "user", "content": "What is the weather in Lisbon?"}],
"tools": [{
"type": "function",
"function": {
"name": "get_weather",
"parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]}
}
}]
}'
レスポンスは choices[0].message.tool_calls に格納されます。デフォルトで思考モードが有効になっており、各リクエストごとに thinking_budget_tokens で切り替え可能です。
これらは以下の 4 つの展開パターンに対応しています。
ユースケース
ノートパソコン上で動作するローカルエージェントは、262K トークンを超える大規模なリポジトリ全体を対象としたコード処理に「3 値版（Ternary）」を採用しています。一方、スマートフォン上での推論には「1 ビット版」が使用され、ホワイトペーパーによると、iPhone のバッテリー残量の 1% あたりで約 672 トークンの生成が可能となっています。プライバシーが敏感な領域やオフライン環境でのワークフローでは、プロンプトが構造的にデバイス内に留まる設計になっています。
さらに 4 ビットの KV キャッシュと組み合わせることで、単一の GPU（VRAM 24GB）でも 27B クラスのモデル品質を維持したサービス提供が可能になります。
主なポイント
- Bonsai 27B は Qwen3.6-27B の新しい事前学習モデルではなく、重みをバイナリまたは 3 値に変換したものです。
- 3 値版は FP16 の性能の 94.6% を維持しつつサイズを 5.9GB に圧縮。1 ビット版も 89.5% の精度を保ちながら 3.9GB まで削減しています。
- PrismML は、この 1 ビット版がスマートフォンに収まる初の 27B クラスモデルであると主張しています。
- 従来の 4 ビット未満の圧縮モデルは、AIME、LiveCodeBench、およびエージェントタスクにおいて性能が著しく低下する傾向があります。
すべてのリリースは Apache 2.0 ライセンスの下、llama.cpp（CUDA、Metal 対応）や MLX で提供されています。
技術詳細、GitHub リポジトリ、モデルウェイトについては各リンクをご確認ください。また、Twitter や 15 万人以上のメンバーが参加する ML サブレッド、ニュースレターへの登録もぜひご検討ください。Telegram ユーザーの方にも、今すぐ Telegram チャンネルにご参加いただけるようになりました。
GitHub リポジトリや Hugging Face ページ、製品発表、ウェビナーなどのプロモーションを弊社と連携したい場合は、お気軽にお問い合わせください。
※本記事は MarkTechPost に掲載された「PrismML Releases Bonsai 27B: 1-bit and Ternary Builds of Qwen3.6-27B That Run on Laptops and Phones」の翻訳です。
原文を表示
PrismML just released Bonsai 27B. It is a low-bit representation of Qwen3.6-27B, not a new pretrain. The architecture is unchanged.
Two variants ship under Apache 2.0. Ternary Bonsai 27B uses {−1, 0, +1} weights at a true 1.71 bits per weight. Its ideal size is 5.9GB. 1-bit Bonsai 27B uses binary {−1, +1} weights at 1.125 bits per weight, for 3.9GB.
Both are multimodal. The split is ~24.8B language weights, a 0.46B vision tower, and 2.5B in embeddings and the LM head. The vision tower is held separately at 4-bit (HQQ). Context is 262K tokens, kept practical because ~75% of Qwen3.6-27B attention is linear.
(function(){
window.addEventListener('message', function(e){
if(e.data && e.data.mtpBonsaiHeight){
var f = document.getElementById('mtp-bonsai-27b-frame');
if(f){ f.style.height = e.data.mtpBonsaiHeight + 'px'; }
}
});
})();
That architecture shapes the compression method below.
How the Compression Works
Each weight is a code, with one shared FP16 scale per group of 128. The effective weight is w_i = s_g · t_i.
A ternary value carries log2(3) ≈ 1.585 bits. One FP16 scale per 128 weights adds 16/128, giving ≈1.71 bits per weight. That is a ~9.4× reduction against FP16. Binary costs 1 + 16/128 = 1.125 bits, a ~14.2× reduction.
The representation runs end to end across the matrix-heavy components. Those are embeddings, attention projections, MLP projections, and the LM head. Only a negligible tail of normalization and scale parameters stays higher precision.
Measured as a true average, the Qwen3.6-27B “4-bit” build (Q4_K_XL) is 5.2 bits per weight. The “2-bit” build (IQ2_XXS) is 2.8. Bonsai also departs from BitNet, which avoids collapse only by pretraining from scratch.
The obvious question is what compression costs in accuracy.
Performance
PrismML evaluated 15 benchmarks in thinking mode, using EvalScope with vLLM on H100 GPUs. Ternary Bonsai 27B retains 94.6% of the FP16 baseline, and 1-bit Bonsai 27B retains 89.5%.
VariantTrue bpwFootprintThinking avgDensity (1/GB)
Qwen3.6-27B FP1616.054GB85.070.051
Qwen3.6-27B Q4_K_XL (“4-bit”)5.217.6GB84.990.155
Qwen3.6-27B IQ2_XXS (“2-bit”)2.89.4GB72.730.199
Ternary Bonsai 27B1.715.9GB80.490.400
1-bit Bonsai 27B1.1253.9GB76.110.530
CategoryFP16Ternary1-bit
Math95.3393.4091.66
Coding88.7485.9681.88
Knowledge and reasoning83.1576.9673.39
Agentic and tool calling80.0074.0166.03
Instruction following78.4771.7765.74
Vision72.6165.1959.57
Conventional sub-4-bit builds fail differently. IQ2_XXS falls to 57.5 on AIME26 and 56.4 on LiveCodeBench. It still scores 88.93 on MMLU-Redux, so short-form benchmarks mask the collapse. Gemma-4-31B Q2_K_XL repeats that pattern on a second base model.
Scores alone, however, do not explain the release. Memory does.
Memory is the Binding Constraint
Fitting a phone is stricter than storage numbers suggest. iOS limits a single app to roughly half of physical memory. A 12GB iPhone therefore exposes about 6GB.
The KV cache is the second budget. Only 16 of 64 layers carry a growing full-attention cache, so FP16 costs ≈64 KiB/token. A 262K window costs ≈17.2GB, and a 4-bit KV cache cuts that to ≈4.3GB.
Tolerance is measured. Against its own FP16-KV baseline, Ternary Bonsai shows 0.0011 nats of output forward-KL on MATH-500. Q4_K_XL shows 0.0146.
Peaks follow. At 100K tokens with an FP16 cache, 1-bit peaks at 11.6GB and ternary at 14.7GB. The derived Q4_K_XL row needs ≈25.6GB.
Once a model fits, throughput is the next question.
Throughput and DSpark Speculative Decoding
PlatformVarianttg128pp512
M5 MaxBinary66.4874
M5 ProTernary26.2393
iPhone 17 Pro MaxBinary11.0111
H100 (CUDA)Binary104.82755
Generation is memory-bandwidth-bound, so fewer bytes per step means more tokens per second. Prefill is compute-bound and gains less.
PrismML also ships a DSpark drafter trained against the Bonsai 27B target. On an H100 at draft depth k=4, the binary target reaches accepted length τ=3.6. That is 143.8 tok/s, a 1.37× speedup. Verification is lossless, so output stays distribution-identical. On Apple Silicon the drafter is off by default at batch size 1.
Running It
Ternary 27B is the demo repo default. Start the server, or generate directly:
Copy CodeCopiedUse a different Browser
./scripts/start_llama_server.sh # OpenAI-compatible API + chat/vision UI on :8080
./llama-cli -m ./Ternary-Bonsai-27B-gguf/Ternary-Bonsai-27B-Q2_0.gguf \
--mmproj ./Ternary-Bonsai-27B-gguf/mmproj.gguf -c 0 \
-p "Explain KV cache growth."
mlx_lm.generate --model prism-ml/Ternary-Bonsai-27B-mlx-2bit \
--prompt "Explain KV cache growth."
Tool calling uses the standard OpenAI-style tools array:
Copy CodeCopiedUse a different Browser
curl http://localhost:8080/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"messages": [{"role": "user", "content": "What is the weather in Lisbon?"}],
"tools": [{
"type": "function",
"function": {
"name": "get_weather",
"parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]}
}
}]
}'
The call returns in choices[0].message.tool_calls. Thinking mode is on by default; thinking_budget_tokens toggles it per request.
That maps onto four deployment patterns.
Use Cases
Laptop-local agents run the ternary build for full-repository code work over 262K tokens. Phone-local reasoning runs the 1-bit build; the whitepaper measures 672 tokens per 1% of iPhone battery. Privacy-sensitive and offline workflows keep prompts on-device by construction. Combined with the 4-bit KV cache, single-GPU serving fits 27B-class quality on a 24GB card.
Key Takeaways
Bonsai 27B moves Qwen3.6-27B into binary or ternary weights, not a new pretrain.
Ternary retains 94.6% of FP16 at 5.9GB; 1-bit retains 89.5% at 3.9GB.
PrismML claims the 1-bit build is the first 27B-class model to fit a phone.
Conventional sub-4-bit builds collapse selectively on AIME, LiveCodeBench, and agentic tasks.
Everything ships under Apache 2.0, on llama.cpp (CUDA, Metal) and MLX.
Check out the Technical details, GitHub Repo and Model Weight. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well.
Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us
The post PrismML Releases Bonsai 27B: 1-bit and Ternary Builds of Qwen3.6-27B That Run on Laptops and Phones appeared first on MarkTechPost.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み