Ternary Bonsai 2 27B：5.9 GBに収まるもの、そして98.2%が教えてくれないこと

Ternary Bonsai 2 27Bは、Prism MLが2026年9月17日に発表した273億6,000万パラメータのマルチモーダル言語モデルであり、理解すべき点は、その言語重みがちょうど3つの値のいずれかを取るということだ。ベースモデルはQwen3.8 27B——27Bのハイブリッドアテンションモデル——で、Bonsaiはそのアーキテクチャ、そのトレーニング、その形状を維持し、言語モデルの行列重みを三値表現に置き換えている。出荷されるファイルは5.93 GB。フル精度の参照は53.81 GB。ベンダーの目玉の主張は、元のベンチマーク平均の98.2%を保持しているというものだ。

まず、ほとんどの報道が素通りしてしまう部分から始めましょう：その98.2%という数字はPrism ML自身の数値であり、Prism ML自身の20ベンチマークスイート、Prism ML自身のハーネスで測定されたもので、社外の誰も再現していません。これは非難ではありません——リリース翌日としてはごく当たり前の状態であり、まさにそういう位置づけにすべきものです。今日、独立して検証できるのはファイルです。Hugging Face APIはTernary-Bonsai-2-27B-PTQ1_0.ggufを5.947 GBと記載しており、FP16参照の53.808 GBに対して9.05倍の削減で、誰の言葉を信じる必要もなくベンダーの「およそ9倍」と一致します。サイズは事実です。品質保持はベンダーの測定値です。興味深いのはその中間——カテゴリ別の内訳で、圧縮が無償で済む場所とそうでない場所を正確に示しています。

このリリースにはもう一つの顔もある。9月18日、発表の翌日、OrcaRouterは同じモデルのランタイム・アブリテーションを施した変種——OrcaRouter Ternary Bonsai 2 27B Uncensored——を公開した。これは推論時に学習済みの拒否方向を除去し、重みはビット単位で同一のままとする。以下に独立したセクションで扱う。手法こそが興味深い部分であり、その限界が結果と同じくらい示唆に富むからである。

これは新たにトレーニングされたモデルではなく、圧縮された Qwen3.8 27B です。

この区別は、リリースを説明することとプレスリリースを繰り返すことの違いである。Prism ML は27Bモデルをゼロから学習したわけでも、新しい事前学習レシピを実行したわけでもない。実際に行ったのは、Qwen3.8 27B を対象に、その重みが保存され計算される際の数値表現を変更することだった。

アーキテクチャは変わっておらず、ベースモデルのものをそのまま踏襲しています。ハイブリッドアテンション設計で、およそ75%が線形アテンション、25%がフルアテンション、そこにSwiGLU MLPブロック、RoPE、RMSNormを組み合わせています。このハイブリッドなバックボーンこそ、262Kトークンのコンテキストが単に対応しているだけでなく「フルコンテキスト対応」と謳われる理由でもあります。大部分が線形のアテンションだからこそ、デバイス上でも長いコンテキストを低コストに保てるのです。このモデルは視覚言語モデルであり、テキストだけでなく画像も受け付けます。ビジョンタワーは標準の非量子化Qwenタワーで、別途パッケージ化されています。

Prism MLがもたらした貢献は2つある。1つ目は三値表現そのものと、それを実用に耐えうるものにする量子化対応トレーニングだ。2つ目はカーネルである。Apple SiliconとCUDA上でそのハイブリッドアテンションスタック向けのカスタム低ビットカーネルであり、パックされた重みをFP16にアンパックして乗算するのではなく、直接操作する。2つ目の貢献がなければ、1つ目は高速に使う手段のない保存形式にすぎない。

Prism ML自身のホワイトペーパーでは、パラメータの内訳を、言語バックボーンに64ブロック全体で24.35B、埋め込み層とLMヘッドに2.54B、27ブロックのビジョンタワーに0.47B、合計27.36Bと報告している。ビジョンタワーは、本当に別個のアーティファクトである唯一の部分だ。GGUFリリースではこれを約0.63GBの4ビットmmprojファイルとしてパッケージ化しており、実際に画像が到着したときにのみ読み込まれるため、テキストのみの提供では決してそれを伴わない。

これは同じラボによる第2世代のBonsaiです。初代のBonsai 27Bは2026年7月に登場しており、およそ2か月前のことになります。両世代の比較はもっともな疑問ですが、ここで重複して扱うのではなく、Bonsai 27Bとの直接対決の記事で取り上げます。

「ternary g128」とは、具体的にどういう意味なのか

これまで三値重みに触れたことがないなら、この段落がほかのすべてを読み解けるようにしてくれるので、ここでは略記なしで示します。

ニューラルネットワークにおける通常の重みは16ビット浮動小数点数であり、有用な範囲で約65,536個の識別可能な値を持ち、それぞれの保存に16ビットを要する。三値重みは小さな浮動小数点数ではない。それは3つの記号のいずれかの選択である：−1、0、+1。それが語彙のすべてである。そのような記号を1つ素朴に保存すると、重みごとに2ビットを費やすことになる。なぜなら2ビットで4つの状態を表せるが、必要なのは3つだけだからである。

それ自体では表現力の壊滅的な損失となり、だからこそこの形式は決して単なる記号だけではありません。連続する128個の重みごとに1つのFP16スケール係数を共有し、実際の重みの値は三値記号にそのスケールを掛けたものになります：

• w = ssub>g/sub> · t、ここで t ∈ {−1, 0, +1} であり、ssub>g/sub> は 128 のグループに対して共有される 1 つの FP16 スケールです

つまりモデルは依然として広い範囲の大きさを表現している——ただし、それを重みごとではなく、粗いグループ単位の刻みで表現しているだけだ。0は丸め誤差の産物ではなく、れっきとした第三の状態であり、これがあるからこそ、128個の重みのグループが必要なときにほぼ沈黙していられるのだ。

回転された基底こそが、人々を驚かせる部分である。三値の割り当てが行われる前に、各重み行列は直交回転によってブロック単位で変換される——ウォルシュ–アダマール行列と固定の±1符号の対角成分を組み合わせたもので、ブロックサイズは1024——そして三値はその回転された空間で選ばれる。回転は準備段階で保存される重みに折り込まれるため、余分なビットも余分な重みの転送も要しない。推論時には、ランタイムが代わりに活性化に対して対応する変換を適用し、パックされたモデルは自身の回転をメタデータで宣言するため、ランタイムは対応する変換を適用するか、そのファイルの読み込みを拒否するかのいずれかである。

なぜわざわざそんなことをするのか？ アダマール回転は重み行列のエネルギーを座標全体により均等に分散させるため、その後の3値量子化が、生の尖った分布に対して行う場合よりもはるかに損傷が少なくなるからだ。この回転は飾りではない。三値モデルが親モデルの品質に近いものを保てるのは、まさにこの回転のおかげである。その代償は、バッチサイズ1では変換がすべてのプロジェクションのクリティカルパス上に載ることだ。これは現実のエンジニアリング上の問題である — Prism MLはMetalでは符号反転を変換のロードパスに融合し、CUDAではスレッドブロック全体に並列化することで、デコードを支配しないようにしている。

数字にご注意ください：1.585、1.71、1.72、1.76

このリリースをめぐっては4つのビット幅の数値が出回っている。それらはすべて正しく、それぞれ異なる4つのものを測っている。これらを混同することが、この話で最も簡単に起きる誤りだ。以下にそれぞれと、それが実際に何を対象にしているのかを示す。

• 重みあたり1.585ビット — 三値シンボル1つの情報量、log₂3。これはフォーマットの性質であり、特定のファイルの性質ではない。出荷されているものの中に1.585ビット/重みで動作するものはない。

• 重みあたり1.71ビット — 三値テンソルのみ。16ビットFP16のグループスケールを128個の重みにわたって償却して加えると、log₂3 + 16/128 ≈ 1.71 になります。まだ出荷済みの数値ではなく、三値テンソル単体の値です。

• 重みあたり1.72ビット — 低ビット表現より上に保持される少数の集合を含め、言語モデル内のすべてのパラメータ。Prism MLは26,238,464個のパラメータ — 言語モデルの0.0976%、bf16で約52 MB — をより高い精度で保持しており、その大半は線形アテンション層の再帰状態パスと正規化重みである。これらのテンソルは回転も量子化もされておらず、数値を1.71から1.72へと動かしているのは、まさにこれらである。1.72では、理想化されたフットプリントは5.80 GBで、約9.3倍の削減となる。これはPrism MLの「True Ternary」行であり、ダウンロードするファイルではなく目標である。

• 重みあたり1.76ビット — 実際に出荷されるGGUF。効率的なカーネルにはパッキング形式が必要であり、Prism MLのPTQ1_0はトライトを高密度にパックし、5.93 GBで重みあたり1.76ビット、約9.1倍に達します。これは発表が引用する「5.9 GB」と「9倍小さい」の両方の背後にあるファイルであり、上記の測定が確認するものです。

2つ目のパッキングはPQ2_0で、各トリットを密にではなく2ビットのスロットに格納します。展開を安くする代わりにより多くの容量を要し、7.25 GBで2.16ビット/重み、約7.4倍です。どちらのパッキングも一律に高速なわけではありません——PTQ1_0は1ステップあたりの重みデータ移動量が約18%少ないものの、密なトリットを展開する算術コストを払うため、メモリが制約要因となるAda世代のカードとL4では有利になり、バッチ1デコードが代わりに命令スループットによって制限されるHopper、Blackwell、Apple siliconでは不利になります。プロンプト処理は計算律速であるため、どこでもPQ2_0が有利です。

これらを一次資料と突き合わせて確認する人向けの補足が2点ある。第一に、Prism ML自身の文書では丸め方が少し異なる。ホワイトペーパーのストレージ表ではPTQ1_0は1.76ビット/重み、5.93 GBとされている一方、Hugging Face上のGGUFモデルカードでは1.75、5.95 GBとされており、実測ファイルは5.947 GBである。これらは同じファイルを異なる精度で記述したものであり、内容についての見解の相違ではない。第二に、発表されている「9倍超」の削減率はベンダーによるものであり、実際のファイルに対して測定すると53.808 / 5.947 = 9.05倍となり、これは整合している。

ベンチマークの全体像：平均ではなく、形

見出しの数値は平均83.9で、Qwen3.8 27B FP16ベースラインの85.4に対して98.2%にあたります。その平均は、この結果の中で最も面白みのない部分です。その下にある形こそが本当の情報であり、それは一様ではありません。

• 指示追従 — 82.66 対 81.25。 これは、圧縮モデルが全精度の親モデルを上回った唯一のカテゴリである。誰も軽々しく説明で片付けられるようなノイズではない。ベンダー自身のスイートにおける、紛れもないカテゴリでの勝利なのだ。

• 数学 — 96.57 対 97.06、コーディング — 81.58 対 82.17。 どちらも実質的に同レベルです。カテゴリ平均で0.5点と0.6点の差にすぎません。フットプリントが9分の1のモデルにとって、これらはこの手法全体が議論の根拠としている結果です。

• 知識と推論 — 83.95 対 86.66。2.7ポイントの低下であり、総合平均で失われた1.8ポイントのうち相当な割合がここに潜んでいます。

• ビジョン — 78.59 対 81.64。3.05ポイントの低下で、単一カテゴリとしては最大の損失です。注目すべきは、圧縮されているのはビジョンタワー自体ではなく、その出力を読み取る言語モデルの方だという点です。

• エージェント機能とツール呼び出し — 77.57 対 79.74。カテゴリ平均は τ 2-Bench の 80.22 と BFCL v3 の 74.92 を対象としています。

個々の結果は知っておく価値がある。なぜなら、それらはすべて同じ方向を指しているわけではないからだ。Terminal-Bench 2.1では、このモデルはフル精度の69.7に対して52.8を記録し、およそ4分の3である。そしてSWE-bench Verifiedでは、フル精度の80.6に対して60.8を記録し、これも約4分の3である。このモデルファミリーがTerminal-Benchで評価されたのはこれが初めてであり、Prism MLは、最初のBonsaiリリースで約束した長期的なソフトウェアエンジニアリングの成果が部分的であり、完全ではないと明言している。それに対して、τ 2-Benchは前回リリースの73.6から80.2に上昇し、BFCL v3は74.9を維持し、AA-LCRは77.0で、フル精度と1ポイント以内である。AIME26は95.83、LiveCodeBenchは90.07となっている。

どこを信頼し、どこを信頼すべきでないか。 数学、コーディング、指示追従については、この傾向を信頼してよい——これらはこの手法が主張どおりに機能していることが実証可能なカテゴリであり、ベースラインと同じハーネスで測定されている。長期的なエージェント作業については慎重になるべきだ。持続的なツール駆動型エンジニアリングを実際に負荷検証する2つのベンチマーク、Terminal-Bench 2.1 と SWE-bench Verified は、集計値が示唆するよりも実質的に大きな差を示しており、ベンダーもそれを隠さずに認めている。そして、他の誰かが実行するまでは、表全体を1つのラボが1つのハーネス上で行った測定値として扱うべきだ。この注意書きはここでは形式的なものではない——「このモデルは98.2%を保持する」と「このモデルのベンダーが、ベンダー自身が選んだスイートで98.2%を測定した」との違いなのだ。どちらも真実だが、モデルそのものに関する事実であるのは一方だけだ。

なぜこれが同じベースモデルのIQ2_XXSビルドを上回るのか

これは一行で済ませるのではなく、独立したセクションを設けるに値する。訓練後量子化よりも量子化認識型三値トレーニングを支持する論拠のすべてが、まさにこれだからだ。

Qwen3.8 27Bを小型化する従来の手法は、学習後に量子化することです。ホワイトペーパーにおける比較対象は、同じベースモデルのIQ2_XXS GGUFビルドです：

• Ternary Bonsai 2 27B — 1.76 ビット/重み、5.93 GB、20ベンチマーク平均 83.9

• Qwen3.8 27B IQ2_XXS — 2.2 ビット/重み、7.3 GB、20 ベンチマーク平均 75.2

訓練時に圧縮されたモデルはより小さく、かつより優れている。従来の低ビット版よりも1.23倍小さく、スコアは8.7ポイント高い。この組み合わせは端数処理の妙などではなく、訓練中に選ばれた表現が、同じ名目上のビット予算を後から適用した場合よりもはるかに価値があるという主張である。

より示唆に富むのは、どのように従来のビルドが失敗するかです。というのも、その失敗は選択的で気づきにくいからです。IQ2_XXS は均等に性能が落ちるわけではありません。表層的な知識では持ちこたえ — MMLU-Redux で 85.79 — ながら、持続的な推論の連鎖を要するタスクでは崩壊します。AIME26 で 78.6、LiveCodeBench で 70.05、GPQA Diamond で 65.45 です。Bonsai 2 は同じ3つで 95.83、90.07、85.76 を記録します。何気ないチャットテストでは、IQ2_XXS ビルドはまったく実用的だと判断され、崩壊は決して表面化しないでしょう。損傷はまさに、長い推論とコード生成が行われる場所に潜んでいます。その非対称性こそ、「試したときは問題なく感じた」が量子化モデルについての証拠にならない理由です。

Prism MLは同じ主張を、インテリジェンス密度と呼ぶ単一の派生値に圧縮している——おおよそ、ギガバイト当たりのベンチマーク能力である。20項目のベンチマークスイートでは、Bonsai 2で1GB当たり0.444、IQ2_XXSビルドで0.276、FP16で0.051と報告している。この指標はベンダー自身が作り上げたもので、その重み付けは設計上の選択であり、法則ではない。しかし、それが生み出す順序は生の表が生み出す順序と同じであるため、証拠を加えるというより解釈を加えている。

この比較について、もう一つ正直な注記を。Prism ML の GGUF モデルカードは、より範囲の狭い第2の評価——14 ベンチマークの thinking モードスイート——を報告しており、そこでも同じ保持率が 84.78 対 86.32 として再び現れ、IQ2_XXS は 72.59 です。2 つの異なるスイートが同じ 98.2% に到達していることは、集計値の主張が単一のベンチマーク選択による人為的な産物ではないことの、控えめな裏付けです。ただし、両方を実行しているのは依然として同じラボであり、同じハーネス上です。パッキング形式の疑問を含む、この対戦のより詳細な内訳は、Qwen3.8 27B GGUF ビルドとの比較にあります。

実際に運営するために必要なこと

スループットの数値は、ホワイトペーパーの標準化されたtg128測定（バッチサイズ1、ビジョンタワーを除外）によるものです：

• Apple M5 Max — デコード 46.8 tok/s、プロンプト処理 765 tok/s

• Apple M5 Pro — デコード 27.7 tok/s。PQ2_0 パックの別のより長いウィンドウでの実行では、持続 27.0 tok/s を計測し、GPU レールで 27.0 W、CPU と GPU 全体で 32.8 W を消費した

• {{1}}Apple M4 Pro{{/1}} — {{2}}18.0 tok/s デコード{{/2}}、{{3}}プロンプト処理は約 125 tok/s で{{/3}}、{{4}}非常に長いコンテキストではこれが制約となる{{/4}}

• NVIDIA RTX 5090 — PQ2_0パックでのデコードは142.5 tok/s、トークンあたり0.582 mWh

Prism ML が示す実用的な主張は、高速化率ではなく、不在である。53.8 GB の FP16 ベースラインは 16 GB のラップトップにはまったく収まらないため、意味のあるのは、27B クラスのモデルが今や日常的なハードウェア上で対話的に動作するという事実だ。M5 Pro では、測定されたデコードが約 201 GB/s の重みをストリームしており、低ビット表現が活用するように設計されたメモリ帯域幅支配型のプロファイルを裏付けている。

次に、ピークの数値よりも重要なエッジケースです。

標準のllama.cppは使えません。三値ハイブリッドアテンションカーネルは、Prism ML独自のllama.cppフォークに存在します。標準のllama.cppはPTQ1_0とPQ2_0タイプを不明なものとして拒否し、さらに危険なことに、古いQ2_0三値形式を警告なしで読み込んでゴミを生成します。Hadamardアクティベーションランタイムを備えていないからです。このモデルを、対応する回転を適用しないバイナリで実行しても、エラーは出ません。代わりに、流暢に見えるナンセンスが出力されます。このリリースで午後を無駄にする、最もありがちな方法はこれです。

MLXパックにはCUDAパスがありません。 MLXリリース（prism-ml/Ternary-Bonsai-2-27B-mlx-2bit）はApple Siliconを対象としており、そこではPythonとSwiftの両ランタイムにあるハイブリッドスタック向けのカスタムカーネルが用意されています。その量子化matmulにはMetalカーネルとCPUカーネルがありますが、CUDA実装はないため、NVIDIAマシン上ではその特定のパックはGPUアクセラレーションをまったく得られません。CPU推論は動作しますが、27BのフォワードパスをCPUで実行すると数分かかることがあります。そのためLinuxのCPUパスは実装テストと再現性には有用ですが、サービングには役立ちません。

この2つのパックは優劣ではなく、正当なトレードオフです。Ada世代のカードやL4を使っている場合、あるいはメモリが制約要因になっている場合は、5.93 GBのPTQ1_0が選択肢です。Hopper、Blackwell、または5090を使っているなら、PQ2_0は1.3 GBと引き換えにデコード速度を得られます。Appleシリコンの場合は、上記のM5 Proの数値がPQ2_0で測定されたものであり、PQ2_0はデモセットアップがデフォルトでダウンロードするパックでもある点に注意してください。

MLXパック自体の会計処理についての注意点です。これはよく混乱の原因になるためです。MLXコンテナはアフィン2ビット形式で、そのブロックは128個の重みごとにFP16スケールとFP16バイアスの両方を格納します。Bonsaiの三値重みにはスケールだけで十分で——レベルはスケールだけから得られる——ため、バイアスは無駄な重荷であり、ブロックは128重みあたり34バイトではなく36バイトを要します。その結果、MLXパックのパック済みレートは1.72でも1.76でもなく2.250ビット/重みになります。これは同じ三値値を運ぶ別のコンテナであり、Hugging Face上で計測されたファイルは8.005 GiBです。

ランタイム・アブリタレーテッド変種

9月18日、OrcaRouterはOrcaRouter Ternary Bonsai 2 27B Uncensoredを公開した。これは、拒否方向のアブレーションをこのモデルに対して完全にランタイムで適用するものだ。注目に値するのは製品よりもそのエンジニアリング上のアイデアであり、まずはそのアイデアから述べよう。

従来のアブリテレーションは重みを編集する。拒否挙動に対応する活性化空間内の方向を見つけ、残差ストリームへ書き込む重み行列をその方向に対して直交化する：W ← W − r(rᵀW)。通常のFP16モデルではそれで問題ない——編集後の行列も依然として密な浮動小数点行列なので、保存して先に進めばよい。三値パックではそれは行き止まりであり、しかも、このモデル全体が存在する理由そのものによって行き止まりなのだ。三値行列を直交化すると、密なフル精度行列が生成される。それを三値パックへ戻して保存するには再量子化が必要になる——そして、編集済みの重みを再量子化しても、元の重みを生み出した量子化対応学習は再現されない。まさに、手に入れたものそのものを捨てることになるのだ。

したがって、射影は代わりに推論時へ移ります。変更するのはWではなく、その出力です：

• y ← y − α · dot(y, r) · r（float32で計算）。ここで y は残差寄与、r は正規化された拒否方向である。

α = 1 では、各残差書き込みのうち拒否方向に平行な成分が除去される。α = 0 では、モデルは変更されない。α が 1 を超えると過剰投影となり、品質が低下する可能性がある。α はチェックポイントのプロパティではなく実行時パラメータであるため、同じパックを同一プロセス内でそれ自体に対して A/B テストできる。これはまさに OrcaRouter の評価が行っていることだ。元の Bonsai パックはビット単位で同一のままである。変更された重みはゼロ、再量子化はゼロ、追加の重み量子化誤差はゼロ。

実装上の2つの細部こそが、これを素朴に実装した場合に失敗する箇所です。

介入サイトは16ではなく129です。残差ストリームに書き込む可能性のあるすべてのモジュールをラップする必要があり、このハイブリッドアーキテクチャでは、それは64個の mlp.down_proj ブロック、48個の linear_attn.out_proj 層、16個の self_attn.o_proj 層、および model.embed_tokens です — 合計129個です。self_attn.o_proj だけをラップするのは明らかな間違いであり、それはそのうち16個を捕捉し、残りの113個の書き込みを未投影のままにします。自己チェックスクリプトは、拒否方向に沿った残存成分が残差ノルムのおよそ1e-6まで駆動されているかどうかを測定し、129か所すべてを検出できない場合は警告を出します。

方向を再回転させないでください。 三値パックは、その射影を、それらの 入力次元上の回転基底に保持し、活性化側で補正します。拒否射影はそれらの射影の 出力 に対して作用しますが、それらはすでに通常の隠れ基底に戻っているため、拒否方向は通常の5120次元ベクトルであり、それに追加のアダマール回転を適用すると、まったく誤った基底に対して射影することになります。

OrcaRouterが測定したもの — 独立した数値ではなく、当社独自の数値です

これらはOrcaRouter自身のルールベース測定であり、そのように読むべきものです。つまり、ルールベースの冒頭フレーズ分類器であり、LLMジャッジではなく、thinking off、greedy decoding、64トークン予算で、baseとablatedは同一プロセス内の同じ重みで、α = 0 対 α = 1 としたものです。これらは参考値であり、出版品質ではなく、Prism MLが主張した何かを検証するものでもありません。

拒否について、拒否を受け取ったプロンプトの割合として測定：

• AdvBench（n=100） — ベース99.0%、アブレーション6.0%、56.0%は回答されたが免責事項で包まれていた

• JailbreakBench（n=100） — ベース 96.0%、アブレーション 4.0%、留保付き 52.0%

• StrongREJECT (n=150) — ベース99.3%、アブレーション3.3%、条件付き45.3%

• HarmBench (n=150) — 98.7% ベース、7.3% アブレーション済み、48.0% 注意事項付き

• MaliciousInstruct（n=100）— ベースライン97.0%、アブレーション後0.0%、注意書き付き52.0%

• ForbiddenQuestions（n=150） — 75.3% ベース、5.3% アブレーション、42.7% 但し書き付き

• SimpleSafetyTests（n=50） — ベース96.0%、アブレーション18.0%、但し書き付き60.0% — そしてこの数値は過小評価されている。 そのセットは主に自傷プロンプトで構成されており、モデルは「I am deeply sorry to hear…」で始まる危機対応リダイレクトでそれらに回答するが、分類器の完全一致フレーズリストはこれを見逃し、コンプライアンスとしてスコア付けする。そのセットにおける実際の残存拒否率は18.0%より高い。分類器は、数値がOrcaRouterの他のモデルカードと比較可能なままになるよう、意図的にそのままにされた。

どの集合でもトークン予算を使い切った返答はなかったので、これらの率はいずれも打ち切りによって水増しされていない。良性プロンプトでは、同じ射影が過剰拒否も取り除く。XSTest-safe の拒否率は5.2%から0.4%に低下し、JailbreakBench の良性サブセットは25.0%から0.0%になった。公開されたパックは、そのベンチマークの良性プロンプトの4分の1を拒否するが、アブレーションすると1つも拒否しない。

能力に関しては、重みがビット単位で同一であるということは、支払うべき再量子化が存在しないことを意味しており、測定結果はそれと一致している：

• MMLU（n=300） — ベース 76.7%、アブレーション 77.7%、+1.0

• GSM8K（n=150） — 87.3% ベース、86.0% アブレーション、−1.3

• CMMLU（n=500） — ベース 76.2%、アブレーション 75.6%、−0.6

これらのサンプルサイズでは、すべての変動はノイズの範囲内である。GSM8Kの1問は0.7ポイントに相当する。MMLU-Proは報告されず、除外されている。そのプロンプトは回答の前に推論を求めており、双方の応答の63～64%はトークン予算内で回答に到達していなかった。したがって、どのような精度の数値も、測定値ではなく予算によって設定された下限値となる。

最も重要な注意点

拒否方向は、Bonsaiパックの学習元となったBF16ベースモデルから推定された。アーキテクチャと隠れ基底は同一であるため、幾何学的に整合する。ただし、その方向が量子化認識トレーニングをどの程度生き残るかはまだ完全には測定されていない。

ランタイムは、数学的に、かつ約1e-6の精度で、与えられた方向をすべての残差書き込みから除去することを証明できる。しかし、それだけから、その方向が量子化モデルにおいても、密なモデルで捉えていたのと同じ振る舞いの特徴を依然として捉えていることを証明することはできない。これらは別々の主張であり、確定しているのは最初のものだけである。上記の安全性テーブルを読む人は、介入が方向転移の仮定が正しいのとちょうど同じだけ有効であり、その仮定が未解決の問いであることを知った上で読むべきである。

OrcaRouter がリリース自体に示している実務的な位置づけもあり、これは言い換えて薄めるよりも、繰り返す価値がある。学習された拒否方向を除去すると、元のモデルなら断っていたであろう要求にモデルが応答する可能性がある。これは研究および推論制御のメカニズムであり、その結果得られる出力が安全、正確、適切であることの証拠ではない。また、これを使用するデプロイでは、独自のアクセス制御とポリシー施行を適用すべきである。拒否を除去することはただで得られる改善ではなく、本稿もそうであるかのようには書かれていない。

再現する人向けの実用的な注記がさらに3つある。パックはそれ自体に同梱されたランタイムで読み込む必要がある — 通常のMLXローダーは、正常に読み込めたように見えても、黙って誤った計算をしている可能性がある。そのため、アブレーションを有効にする前の時点で出力がおかしい場合は、まず読み込み経路を確認してほしい。層選択的アブレーションがサポートされているので、介入はオール・オア・ナッシングである必要はない。そして、アブレーション評価は、パックが自身のカーネルを駆動するのではなく、パックを展開したFP16拡張上で実行された。というのも、パックされた量子化matmulにはCUDA実装がなく、CPUバックエンドは順伝播1回につき数分を要するからである。この拡張はパックの三値値を正確に保持しており、スポットチェックではパック自身の次トークン分布を小数点以下3桁まで再現するが、これはコンテナの変更であり、知っておく価値がある。コードと完全な表は、OrcaRouter Ternary Bonsai 2 27B Uncensoredリポジトリにある。アブレーション済みMLXビルドと未修正のQwen3.8 27B MLX経路を比較する別の比較では、ランタイムの詳細をより深く扱っている。

これがどこへ向かうのか、そして何がまだ証明されていないのか

およそ6ギガバイトに収まるほぼロスレスの27Bモデルがローカルエージェントにもたらす変化は、主に何が常駐するかという点にある。16 GBのラップトップ上で実際のコンテキストウィンドウと併存できる言語モデルは、エージェントが他の作業——ファイルを読む、ツールを呼び出す、ターンをまたいで計画を保持する——を行っている間もロードされたままでいられる。リクエストごとにスワップインされたり、サーバーに押しやられたりするのではなく。それは、試しに使うローカルモデルと、動かしっぱなしにするローカルモデルの違いであり、エージェント性能の数値、τ 2-Benchの80.2とBFCL v3の74.9が裏付けようとしているまさにその特性だ。

未証明のものは、発表が示唆するよりも長いリストである。

独立した再現はありません。この記事に載っているすべての品質数値——83.9、98.2%、カテゴリ平均——は、Prism ML が自社スイート上で行った Prism ML 自身の測定値です。それはこのリリースの欠陥ではなく、単に、公開から1日しか経っていないものがどう見えるかを示しているだけです。また、それは最初に変わるものでもあります。

• 長期的なエージェント作業は、ベンダー自身の表の中で最も弱い部分であり、最も強い部分ではない。Terminal-Bench 2.1 の 52.8 対 69.7 は実際の差であり、ベンダーもその能力は部分的だと述べている。

• まだ試していないプロンプト。低ビットモデルの失敗プロファイルは選択的であり、IQ2_XXSがMMLU-Reduxで85.79を維持しつつAIME26とLiveCodeBenchで崩壊することは、ベンチマークの平均値があなたのワークロードで何が起こるかを教えてくれないという、入手可能な中で最も明確な証拠である。Bonsai 2はそれら2つのベンチマークでその崩壊を示しておらず、これは心強いことではあるが、保証と同じではない。

• 上記のアブリテレートされた変種における方向転移の問い。これは構造上未解決である。

• ランタイムが移り変わっても、カーネルが持ちこたえるかどうか。現時点でこのモデルにはフォークが必要だ。素の llama.cpp は3つのフォーマットのうち2つを拒否し、3つ目は黙って文字化けさせる。これらのカーネルが上流に取り込まれるまで、「llama.cpp が動くところならどこでも動く」は、このモデルに関してはまだ真ではない。

このリリース自体に疑念はない。5.93 GBの27Bクラスのマルチモーダルモデルは、圧縮元の9分の1のフットプリントで、数学とコーディングは親モデルと同等、指示追従はわずかに上回っており、ローカル推論にとって真に異なる動作点だ。2026年9月18日時点で妥当な姿勢は、ファイルサイズを事実として受け止め、保持率の数値は、ベンダーが選んだスイートについて1日前にベンダーが示した慎重な主張として受け止め、自分のワークロードについては実際に動かすまで判断を保留することだ。

ランタイムアブレーションのコード、拒否方向、および完全な評価テーブルは、OrcaRouterによって、チームが構築するルーティングプラットフォームとともに公開されています。