Ternary Bonsai 2 27B 対 Qwen3.8-27B：47.9ギガバイトの精度が実際にもたらすもの

Ternary Bonsai 2 27B と Qwen3.8-27B は、2つの数値世界における同じモデルです。両者はアーキテクチャ、トークナイザー、学習系統、そして262,144トークンのコンテキストウィンドウを共有しています。両者を分けるのは、重みがどのように書き表されているかです。Qwen3.8-27B は各重みを16ビット浮動小数点数として保存し、FP16参照形式で53.81 GBを占めます。一方、Ternary Bonsai 2 27B は各重みを3つの記号のいずれかとして保存し、5.93 GBを占めます。Prism ML は2026年9月17日に圧縮ビルドを発表し、Apache 2.0 の下で Hugging Face に公開しました。元の Qwen3.8-27B の重みは2026年8月13日に公開され、これも Apache 2.0 の下でした。

重要な比較は、どちらが優れているかではない。それは、失われた47.9 GBがあなたに何の代償をもたらすかであり、正直な答えは、どちらの陣営が言うよりも狭く、より具体的だ。Prism MLの報告によれば、そのビルドは98.2%を維持している。これは、20ベンチマークスイート全体におけるフル精度モデルの平均に対する値である——83.9 対 85.4。その数値はベンダー自身のもので、ベンダー自身のハーネスで測定されており、リリースから1日後、Prism ML以外にこれを再現した者はいない。この集計値は、あなたが実際に気にすべき部分も隠している。なぜなら、1.8ポイントは均等に分布していないからだ。持続的なソフトウェアエンジニアリングに負荷をかける2つのベンチマークでは、差は1.8%ではない——25%に近い。

同じネットワークを、別の書き方で表したもの

圧縮が手を付けないものから始めよう。それこそが、この比較がそもそも興味深い理由だからだ。層数、隠れサイズ、語彙、アテンションパターン、ビジョンタワーはベースモデルのものだ。Qwen3.8-27B はハイブリッドアテンション設計だ。48 の Gated DeltaNet 線形アテンション層が 16 のフルアテンション層と交互に配置され、ほぼ 3:1 の分割で、64 層にわたり、隠れサイズは 5,120、語彙は 248,320 トークン。その大部分が線形のバックボーンこそが、そもそも 262K コンテキストを現実的なコストで扱えるものにしているのであり、Bonsai が変わらず受け継ぐ性質だ。

Prism MLが変えたのは、言語モデルの行列の表現と、それらを計算するために必要なカーネルです。ホワイトペーパーでは、27.36Bのパラメータを、64ブロックにわたる言語バックボーンの24.35B、埋め込みとLMヘッドの2.54B、27ブロックのビジョンタワーの0.47Bに分割しています。ビジョンタワーは約0.63 GBの別個の4ビットmmprojファイルとして提供され、実際に画像が届いたときにのみ読み込まれるため、テキストのみのデプロイではそのコストを負担しません。

そのほとんどが線形な設計による実用的な帰結は、ベンチマークの議論をする前に指摘しておく価値がある。このアーキテクチャは従来のトランスフォーマーではないため、低ビットカーネルはそれ専用に書く必要があった。標準の llama.cpp は、Prism ML の両方のパッキングを未知の型として拒否する。さらに危険なことに、古い三値フォーマットは何のエラーも出さずに読み込み、流暢なナンセンスを生成する。活性化に適用される対応する回転がないからだ。このモデルを、そのことを知らないバイナリで実行しても、エラーは出ない。得られるのは、自信満々の間違った出力だ。

カテゴリー別の比較

ベンダーによる20ベンチマークの内訳を、フル精度のベースを基準として示します。このリストの数値はすべてPrism MLのものであり、そのいずれも独立に検証されたものではありません。

• 数学 — Ternary Bonsai 2 27B が 96.57、Qwen3.8-27B が 97.06。実質同等。

• コーディング — 81.58 対 82.17。これも僅差であり、この手法全体が議論の対象となっているカテゴリーだ。

• 指示追従 — 82.66 対 81.25。圧縮モデルはここで優位に立っており、これは表の中で唯一本当に驚くべき行です。

• 知識と推論 — 83.95 対 86.66。2.7ポイントの低下であり、失われた1.8ポイントへの単一最大の寄与要因。

• エージェント型およびツール呼び出し — 77.57 対 79.74、τ2-Bench では 80.22、BFCL v3 では 74.92 をカバー。

• ビジョン — 78.59 対 81.64 で、最大のカテゴリ損失。ビジョンタワー自体は圧縮されている部分ではなく、その出力を読み取る言語モデルの方が圧縮されている点に注意。

平均ではなく形を読めば、より明確な話が見えてくる。圧縮は数学、コーディング、指示追従ではほとんど無料であり、知識と視覚では高くつく。これは、表層的な知識は生き残り、推論は崩壊するという低ビットモデルに関する通説とは正反対だ。ここでは知識が侵食され、推論が持ちこたえている。

1.8ポイントは実際どこにあるのか

集計値は20のベンチマークの平均であり、平均こそ格差が隠れる場所だ。個々の結果を取り出してみると、そのうち2つは平均が示唆するよりもはるかに悪い。

• Terminal-Bench 2.1 — 三値ビルドが52.8、フル精度が69.7

• SWE-bench Verified — 60.8 対 80.6

どちらもフル精度スコアのほぼ4分の3に達している。それに対して、AIME26は95.83、LiveCodeBenchは90.07、AA-LCRは77.0を記録し、非圧縮モデルと1ポイント以内の差だ。BonsaiファミリーがTerminal-Benchで評価されるのはこれが初めてであり、Prism MLは自社資料の中で、第1世代で約束した長期的なソフトウェアエンジニアリング能力が完全ではなく部分的にしか実現されていないと明言している。

したがって、実用的な問いは「98.2%を保持しているか」ではなく「自分のワークロードは何か」です。数十回のツール呼び出しにわたって計画を保持し、数分かけてファイルを編集するコーディングエージェントを動かしているなら、あなたは25%のギャップがあるカテゴリにいて、集計値はむしろ積極的に誤解を招きます。数学、単一ターンのコード生成、抽出、分類、チャットを行っているなら、ギャップが丸められて消えるカテゴリにいます。ベンダー自身の表の最も有用な点は、推測する代わりにその区別を下せるようにしてくれることです。

それぞれを実際に動かすために必要なもの

ハードウェアの話は、サイズ比が示唆するほど対称的ではない。53.81 GB の FP16 モデルは 16 GB のラップトップにはまったく収まらない。そのため、この比較は「より速いか、より遅いか」というよりは、「可能か、そうでないか」に近い。Prism ML によるバッチサイズ 1、ビジョンタワーを除外した標準化測定：

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

• {{1}}Apple M5 Max{{/1}} — {{2}}デコード{{/2}} {{3}}46.8 tok/s{{/3}}、{{4}}プロンプト処理{{/4}}は{{5}}約765 tok/s{{/5}}{{6}}{{/6}}

• Apple M5 Pro — デコード 27.7 tok/s

• Apple M4 Pro — デコード 18.0 tok/s、プロンプト処理は約125 tok/sで、非常に長いコンテキストではこれがボトルネックになりつつある

重要な注意点は、これはどれも単一のバイナリではないということだ。PTQ1_0 パッキングでは、重みあたり 1.76 ビットで 5.93 GB になる。PQ2_0 は重みあたり 2.16 ビットで 7.25 GB を消費し、命令スループットが制限要因でメモリ帯域幅ではないハードウェア上でデコード速度を得る。Apple Silicon 向けの MLX ビルドは、独自の計算方法を持つ第三の成果物である — 三値重みには不要なバイアスを格納するアフィン 2 ビットコンテナで、重みあたり 2.25 ビット、ディスク上 8.005 GiB になり、Metal と CPU カーネルを備えるが CUDA パスはない。「5.9 GB で動く」は、まさに適切なランタイム上の、それらのファイルのうちちょうど 1 つに当てはまる。

コスト比較を、正直に提示する

Qwen3.8-27Bには2つの支払い方法があり、その圧縮版には1つの支払い方法しかありません。Ternary Bonsai 2 27Bはダウンロード提供です。Apache 2.0、自分のハードウェア、従量課金なし。Qwen3.8-27Bはダウンロードとホスト型サービスの両方であり、ホスト型を選ぶ場合の該当数字はモデルページにあるとおり、入力トークン100万あたり0.33ドル、出力トークン100万あたり2.40ドルで、OrcaRouter自身のインフラストラクチャから提供されており、他社から再販されたものではありません。

まさにそこが、OrcaRouter がこの比較で脚注ではなく一席を得る所以です。Qwen3.8-27B のルーティング版ビルドは同じ 262K コンテキストを備え、テキスト、画像、動画を受け付け、モデルが標準で備える推論エフォート制御を公開しています。200 以上の他のモデルと同じキーの背後にあり、プロバイダーの定価に上乗せもありません。これは聞こえ以上に重要なことです。なぜなら定価は転売されるのではなくそのまま渡されるため、ベンダーの価格変更は次の契約更新時ではなく当日にここへ反映されるからです。ローカルの Bonsai の上位のエスカレーション層としてフル精度のベースを求めるチームにとって、それは 2 つのベンダー関係ではなく、1 つのエンドポイントと 1 つのキーです。

どちらを選ぶべきか

その判断は主に、その作業をどこで行うかに関するものであって、どちらのモデルが優れているかということではありません。なぜなら、ほとんどのタスクにおいて、それらは同じモデルだからです。

• タスクが長期的でエージェント的な場合、評価やファインチューニングを行う場合、1MトークンのYaRNコンテキストが必要な場合、または視覚精度が重要となる場合は、Qwen3.8-27Bのフル精度を選択してください。その根拠はTerminal-BenchとSWE-benchの数値にあります。

• 作業を自分が所有するハードウェア上で行う必要がある場合、代替手段が27Bモデルをまったく実行しないことである場合、またはワークロードが数学、コーディング、抽出、ツールを使わない推論であり、各カテゴリが互角である場合は、Ternary Bonsai 2 27B を選びましょう。

• 総合値で選ばないでください。83.9 と 85.4 は、ベンチマークを 1 つ入れ替えるだけで順位が入れ替わるほど近接しており、しかも 2 つの数値のうち独立に検証されているのは 1 つだけです。

ここで本当に新しいのは、27Bモデルが6ギガバイトに収まることではない——最初のBonsai世代がそれを7月に実現している。新しいのは、指示追従が親モデルを上回り、数学とコーディングが同等だったという点であり、これは「サイズの割に小さい」とは別の主張だ。それがあなたのワークロードで成り立つかどうかは、まさに生まれて一日のモデルには分からないことだし、このモデルについての最初の独立した評価こそ、待つ価値のある結果だ。

ベンチマークスイートではなく自分のプロンプトで比較を実行したいなら、最速のルートは、ホストされている Qwen3.8-27B を1つのエンドポイント経由で呼び出し、三値ビルドをローカルで実行してから、実際に自分が持っているタスクで出力を差分比較することです。それは午前中の仕事で済み、公表されたどんな表よりも、その1.8ポイントについて多くのことを教えてくれます。