Bonsai 2 27B：6GBという数字の前に確認したいこと

Bonsai 2 27BはQwen3.8-27Bを基に、重みの大部分を−1・0・+1で表現します。128単位のgroupとHadamard rotationを使い、精度を保ちながらbit数を減らす設計です。モデル全体は27.36B parameterで、言語backbone 24.35B、embedding・出力head 2.54B、vision tower 0.46Bで構成されます。

最小のPTQ1_0言語重みは5.95GB、公式デモの標準PQ2_0は7.21GBです。MLX bundleは0.92GBのvision towerを含めて8.60GB、GGUF⁵ vision projectorは約0.63GBの別ファイルです。これらはファイルまたはbundleの保存容量であり、実行時メモリ全体ではありません。

promptを処理するとcontextを保持するKV cacheが増え、Apple Siliconではmodel bufferとOSもユニファイドメモリ⁶を使います。8GB機器のSSD⁷にモデルファイルが入るだけでは、会話を安定して実行できるとは判断できません。画像作業には言語ファイル以外にvision構成要素と、それらを接続するruntimeも必要です。

Bonsai 2はlinear layerに入る前のactivationにHadamard rotationを適用します。runtimeがこの変換と圧縮重みを一緒に処理して初めて正常な出力になります。Q2という表記だけで、どのQ2 loaderでもGGUFを開けるわけではありません。

公式デモのインストールscriptは必要な対応を含むpatch版llama.cppを準備します。標準llama.cppはファイルを拒否するか、読み込めても文章が壊れる場合があります。MLXにもBonsai変換を理解する専用loaderが必要です。再ダウンロードやGPU⁸変更の前にcheckpoint⁹とruntimeの対応組み合わせを確認してください。

まず短いテキスト質問を送り、回答が正常か確認してから長文や画像入力を加えます。テキスト試験を先に通すと、その後の失敗がメモリ・vision構成・runtime互換性のどれか判別しやすくなります。

PrismMLはPQ2_0、batch 1で128 token¹⁰生成速度と512 token入力処理速度を別々に公開しています。生成tok/sはfirst tokenまでの時間とは異なるため、prompt送信から応答完了までの遅延を見るには両方の測定が必要です。

このメーカー測定はvision towerを除外しています。個人環境の結果はOS・同時要求・実際のprompt・モデル構成で変わります。普段の短い質問と長文を別々に試し、first tokenまでと完了までの時間を分けて確認してください。4K token以上の入力では速度表示の範囲が広くなります。

PTQ1_0 は 1.75 bits/weight、5.95GB、PQ2_0 は 2.13 bits/weight、7.21GB です。ファイル差は 1.26GB ですが、小さいファイルの方が常にデコード¹¹も速いとは限りません。

公開された各デバイスでは、PTQ1_0 の生成速度は同程度かやや速かった一方、プロンプト処理は比較対象すべてで PQ2_0 の方が速い結果でした。空きメモリが 8GB を超える場合は PQ2_0 から始め、メモリに余裕がない場合やファイルを小さくしたい場合は同じ質問で PTQ1_0 と比較してください。

PrismMLは14のreasoning評価の平均としてPQ2_0 Bonsai 2を84.78点、FP16¹² Qwen3.8-27Bを86.32点と報告し、平均値の比として98.2%を主張しています。メーカー評価であり、すべてのpromptで98.2%の品質を保証するものではありません。よく使うコードレビュー・バグ修正や通常の長さの文書を同条件で比べ、正確さ・抜け・一貫性・first token待ち・完了時間を記録してください。

公式デモのPQ2_0とpatch runtimeが手元のPCで正常に動き、実際のpromptに十分答えるなら、その構成を使い続けられます。メモリが本当のボトルネックの場合は、同じ10問でPTQ1_0を試し、回答品質と容量削減を比べてください。画像作業はvision projectorも含めて別途検証します。