ベースは Qwen3.6-27B、Bonsai はネットワーク全体を極限まで低ビット化

ベースは Alibaba Qwen チームの Qwen3.6-27B です。約 27B パラメータ、ハイブリッド注意力構造を持ち、約75%の層が線形注意力、25%の層がフル注意力を使用。ネイティブで超長文コンテキストをサポートします。PrismML は新しい 27B をゼロから訓練したのではなく、この訓練済みネットワークのウェイトを二値または三値化し、それを直接実行できる専用カーネルを組み合わせました。

ビジョンタワーは別途約4bitで、ディスク上は約0.63GB。テキストのみの利用なら通常メモリに常駐しません。オプションの DSpark ドラフト加速層は、さらに約 1.8〜2.0GB 追加されます。

ローカル27Bの壁は「1トークン生成ごとに全ウェイトを読み込む」こと

ローカルでトークンを生成するたびに、デバイスはほぼ毎回、モデル全体のウェイトをメモリから読み込み直す必要があります。バッチサイズが小さい場合、ボトルネックは演算ピークではなく、メモリ帯域幅になることが多いのです。モデルが大きいほど、ステップごとに移動するデータ量が増え、速度・発熱・バッテリー消費が悪化します。

FP16 の Qwen3.6-27B は約 54GB。一般的な「4-bit」パッケージ Q4_K_XL の実際の平均は約 5.2 bit/weight、約 17.6GB です。より積極的な IQ2_XXS は「2-bit」とされますが、実際は約 2.8 bit、約 9.4GB。多くのスマホの単一アプリ予算にはまだ重く、長い推論チェーンではスコアが大幅に低下します。

これが「27B がすごい理由」の本質です。パラメータ数自体の新しさではなく、このクラスの性能が初めてエッジ側のデプロイ可能な物理的境界に収まったのです。通常の方法では 4-bit 以上ならスコアを維持できますが、それ以下では、均等にスコアが下がるのではなく、ツール呼び出しの解析や多段推論の一貫性が崩れ始めます。Bonsai の主張は、サブ 2-bit 領域でもこれらの動作を一定レベル維持するというものです。

圧縮されるのはウェイト。長文を扱えるかを決めるのはキャッシュ

Qwen3.6-27B のハイブリッド注意力が大きく貢献しています。64 層のうち、完全な注意力キャッシュが長さに応じて増加するのは 16 層のみ。FP16 キャッシュは約 64KB/ステップで、全注意力の 27B より約4倍省メモリです。それでも 262K コンテキストの FP16 キャッシュは約 17.2GB となり、1-bit ウェイト自体よりも大きくなります。

Bonsai のウェイトは、4-bit KVキャッシュに対して比較的「耐性」があります。出力分布の forward-KL で測ると、同じく 4-bit キャッシュを有効にした場合、Bonsai は自身の FP16 キャッシュベースラインからの乖離が、FP16 / 通常の 4-bit ウェイトより約1桁小さくなります。ウェイト圧縮とキャッシュ圧縮は、この路線では方向性が同じで、互いに妨げにはなりません。プロジェクトのドキュメントでは、4-bit KV は依然として実験的機能とされており、主にメモリを節約しますが、デコードは少し遅くなり、実際のワークロードでの調整が推奨されます。

平均で約9割維持。損失は指示追従・ツール・視覚に集中

評価は thinking モードで実施。全15項目で、知識・数学・プログラミング・指示追従・ツール呼び出し・視覚をカバー。FP16 ベースライン平均 85.07、三値 80.49、1-bit 76.11。比較で最も顕著なのは、Bonsai が数点落としたことではなく、通常の積極的量子化がどう崩れるかです。IQ2_XXS は AIME26 で 93.33 → 57.5、LiveCodeBench で 87.77 → 56.4。同じ問題で、1-bit Bonsai の AIME は 87 以上、LiveCodeBench は 76.4 を維持しています。

2つのバージョンの位置づけが見えてきます。三値は、メモリが十分にあるノートPC向けで、オリジナルの 27B の感触にできるだけ近づけたい場合に適しています。1-bit はまず「収まるかどうか」を解決しますが、「平均9割」をそのまま「エージェント能力9割」と読んではいけません。ツール呼び出しが全精度より数点低いだけなら三値で辛うじて成立しますが、1-bit ではツール系の平均差分は約14点にもなります。

「GB あたり知能密度」はサイズ効率を見る指標：1-bit は約 0.53/GB で、FP16 の約10倍以上、最も密度の高い一般的な低ビットパッケージの約 2.7 倍。この指標は PrismML が独自に定義し、分母に直接サイズを用いるため、より小さいモデルを強く優遇します。デプロイ効率の比較には適しますが、絶対的な能力スコアの代替にはなりません。

評価条件で割り引くべき点

評価には EvalScope、vLLM、H100 を使用し、各項目の生成長さの予算と採点方法も公開されており、レーダーチャートだけを出す発表よりははるかに詳細です。ただし、結果はまだ第三者による再現がされていません。ほとんどの項目は1回のみの実行です。Bonsai のサンプリング温度は 0.7、Qwen ベースラインと通常の量子化は 1.0 で、生成設定は完全には一致していません。総平均は15項目の単純平均で、数学が4項目を占めます。Bonsai は偶然にも数学で最も良い成績を維持しているため、「95% / 90%」は、ツールや指示に偏った実際のプロダクト負荷よりも良く見えます。エージェントとして使う場合は、総平均ではなく BFCL v3、τ²-Bench、IFEval、IFBench を優先的に確認してください。

速度は2層：低ビット転送と、CUDA 上のドラフト加速

低ビットウェイトは各ステップで転送するデータ量を直接減らすため、トークン生成が最も恩恵を受けます。速度は tg128（約128ユニット生成）と pp512（512入力ユニット処理）で統一報告され、バッチサイズ1、ドラフト層とビジョンタワーは含みません。

DSpark 投機的デコード：小さなドラフトモデルが先にセグメントを予測し（深さ k=4）、ターゲットモデルが一度に検証します。検証はロスレスで、出力分布はターゲットモデルのみを実行した場合と同一です。H100 では、三値が 98.0 → 131.8 字/秒（約 1.34×）、1-bit が 104.8 → 143.8（約 1.37×）に向上。Apple Silicon のシングルリクエストシナリオでは、複数行の検証コストを償却できず、デフォルトではオフです。プロジェクト側も高度に実験的と位置付けています。

消費電力：M5 Pro では 1-bit が約 0.275 mWh/字で、データセンター GPU 6種の 0.63〜1.32 mWh/字より1桁低い値です。iPhone 17 Pro Max では、バッテリー1% あたり約 672 字を生成し、約 10.8 字/秒を維持。5.2分で約 3360 字生成後、バッテリーが 100% から 95% になり、軽度の熱スロットリングが見られました。桁としては参考程度に、機種によってばらつきがあります。

試す価値があるものと、当面は想定すべきでないもの

PCが最も簡単、スマホは現時点では開発者向けパス

すぐ試したい一般ユーザーは、PC向けデモを優先。スマホ側でも動作しますが、「App Store でワンタップインストール」できる完成品アプリはまだありません。1-bit ウェイトと Apple 製 MLX / Swift カーネルを自分で組み込むか、今後のアプリ版を待つ形になります。

git clone https://github.com/PrismML-Eng/Bonsai-demo.git
cd Bonsai-demo

# デフォルト：三値 27B（ノートPC向き）
export BONSAI_MODEL=27B
# 27B リポジトリが非公開の場合、HF 読み取りトークンを設定
export BONSAI_TOKEN="hf_your_token_here"
./setup.sh
./scripts/start_llama_server.sh
# ブラウザで http://localhost:8080 を開く

# 1-bit スマホ同梱ファミリーに変更：
# BONSAI_FAMILY=bonsai BONSAI_MODEL=27B ./setup.sh

上記のデータとデモは発表資料と技術ホワイトペーパーに基づきます。第三者による再現がされているか、ミッドレンジ機で十分かは、ご自身で検証が必要です。27B ウェイトが初めてローカルデプロイのハードルを約 4GB に引き下げました。長文コンテキスト、マルチモーダル常駐、エージェント信頼性は、引き続きシナリオごとに実測が必要です。