PrismMLは9月17日、270億パラメータ級の「Ternary Bonsai 2 27B」を公開した。Qwen3.8-27Bを基に、53.80GBの言語モデルを約5.9GBへ圧縮し、同社の20項目の評価では元モデルの98.2%のスコアを保ったという。Apache 2.0で重みが公開され、同社はiPhoneやiPadへの対応も明記している。270億級のモデルを身近な機器へ移す選択肢が広がる一方、推論設定や任せる作業によって性能の落ち方は異なり、スマホで使うには配布形式やアプリの対応も確かめる必要がある。導入時には、平均スコアとファイル容量に加え、長い作業の成功率や実行時のメモリまで見極める必要がある。
5.9GBに収める仕組み
Bonsai 2 27Bは、モデルのパラメータを大幅に減らす代わりに、重みを表すビット数を削る。中心となるのは、重みを「−1、0、+1」の三値と、128個ごとに共有するFP16の倍率で表現する方式だ。元のQwen3.8-27Bの構造を保ちながら、保存容量と、推論時にメモリから読み出すデータ量を小さくする。
三値に必要な情報量に、共有する倍率の分を加えると約1.71ビットになり、少数の高精度パラメータも含めた理論上の平均は1.72ビットとなる。実際の配布形式には詰め方の都合があるため、PrismMLの技術報告は最小の形式を1重みあたり1.76ビット、5.93GBと記載している。発表の「約5.9GB」はこの言語モデルを指す。
すべてを三値にしたわけではない。線形アテンションで状態を更新する経路や正規化処理に使う重みなど、言語モデルの0.0976%に当たる約2620万パラメータは高精度で残す。画像を処理する部分も別扱いだ。わずかな例外を残したうえで、言語モデル全体を低ビットで保存している。
もう一つの要素が、アダマール回転と呼ばれる固定の直交変換である。保存する重みの表現と、実行時に入力側へ施す変換を対応させて計算する。専用の演算プログラムは圧縮された重みを直接使い、モデル全体をFP16に戻さずに処理するため、小さい容量を推論時にも生かせる。ただし入力側の変換には計算時間がかかり、その削減は引き続き開発課題になっている。
前世代に対しては、ベースモデルの更新も効いている。PrismMLは性能保持率が従来の約95%から98.2%へ上がったと説明するが、ベースモデルの進歩と圧縮手法の改善がそれぞれどこまで寄与したかは分離されていない。世代間の数字を、そのまま圧縮技術だけの改善率とは読めない。
98.2%が当てはまる範囲を分けて見る
20項目の評価でBonsai 2 27Bが得た平均は83.9、比較対象のQwen3.8-27B FP16は85.4だった。数学やコード生成から画像理解までを含む、PrismML自身による測定である。ここで使われた推論強度はxhighで、推論を短めにするmediumの結果も技術報告に載っている。
PrismMLの公表値から保持率を計算すると、20項目平均はxhighで98.2%、mediumで96.0%、Terminal-Bench 2.1は75.8%、SWE-bench Verifiedは75.4%となる。
| 評価と設定 | Qwen3.8-27B FP16 | Bonsai 2 27B | 元モデルに対する保持率 |
|---|---|---|---|
| 20項目平均・xhigh | 85.4 | 83.9 | 98.2% |
| 20項目平均・medium | 82.6 | 79.3 | 96.0% |
| Terminal-Bench 2.1・別枠のエージェント評価 | 69.7 | 52.8 | 75.8% |
| SWE-bench Verified・別枠のエージェント評価 | 80.6 | 60.8 | 75.4% |
出典はPrismMLの2026年9月版技術報告の第4節と付録B・C。保持率は各行の「Bonsaiの公表スコア÷FP16の公表スコア×100」を小数第1位に丸めた。下の2評価は20項目平均に含まれず、異なる評価の点数を合算してはいない。
medium同士でも平均スコアは近いが、xhighの98.2%をそのまま適用することはできない。ローカル環境で待ち時間を減らそうと推論を短くすれば、品質との交換条件も変わる。しかも評価では、一部の課題に最大81,920トークンの出力枠を認めている。これは実際に常にその長さを出力するという意味ではないものの、短い回答だけの評価とも違う。
長い作業を伴うエージェント評価では差がさらに大きい。Terminal-Benchは端末を操作して課題を解き、SWE-bench Verifiedはソフトウェアの不具合修正を試す。PrismMLは前者をTerminus-2で全89課題、各1試行、後者をmini-swe-agentで全500件評価したと説明している。単発のコード生成や関数呼び出しが良好でも、作業を最後まで完了できる割合まで同程度に保てるとは限らない。
それでも、約6GBのモデルでこうした作業を完了できる例があることには価値がある。平均の保持率が高いことと、元モデルをそのまま置き換えられることは別々に判断したい。表の数字は開発元の測定であり、一般のPC上で同じ成功率や所要時間を確認した独立試験ではない。
なお、9月20日に確認したHugging FaceのGGUFモデルカードには、14項目平均84.78対86.32という別の集計が掲載されていた。こちらも比率は98.2%だが、対象となる評価項目が異なる。発表と技術報告の20項目集計に、モデルカードの個別値を継ぎ足すことは避けるべきだ。
小さい形式が最速とは限らない
配布されている重みには、容量を優先するGGUFのPTQ1_0と、三値を2ビットの枠へ入れて取り出しやすくしたPQ2_0がある。Apple向けのMLX版も、同じ三値を別の保存形式に収める。9月20日時点のモデルカードと配布ファイルのサイズを照合すると、容量は次のようになる。
| 配布形式・構成 | 保存容量 | 容量に含まれるもの |
|---|---|---|
| GGUF PTQ1_0 | 約5.95GB | 言語モデル |
| GGUF PQ2_0 | 約7.21GB | 言語モデル |
| GGUFの画像用追加ファイル | 約0.63GB | 画像入力時に使う処理部分 |
| MLX 2-bit | 約8.60GB | 言語モデルと画像処理部分 |
出典：GGUF配布ページとMLX配布ページ。容量は十進のGBで、実行時に必要な総メモリではない。技術報告にはGGUFが5.93GB／7.25GB、MLXが8.49GBと記載され、配布側と差があるため、表は確認時点の配布側の値を採った。
MLX版では128個ごとの重みに倍率とバイアスを保存するため、三値の表現に必要な情報より保存量が増える。さらに画像処理部分を同梱している。「5.9GBのモデル」という見出しから、どの配布形式も同じ容量で済むと考えると、導入時の見積もりを誤る。
速度も形式次第だ。技術報告の同一測定版では、RTX 5090の生成速度はPQ2_0が142.5トークン/秒、PTQ1_0が134.4トークン/秒。一方、RTX 4090では順に90.9、96.7トークン/秒となり、容量の小さい形式が勝つ。転送する重みを減らす効果と、詰め込んだ三値を取り出す計算の負担が、GPUによって異なるためである。
長いプロンプトを読む速さにも注意したい。RTX 5090の入力処理はPQ2_0で4121トークン/秒、PTQ1_0で1901トークン/秒だった。生成が速い形式を選ぶだけでは、長い文書を渡して最初の回答を待つ時間まで短くなるとは限らない。
これらは2026年9月16日に、バッチサイズ1、蓄積済み文脈なし、画像処理部分なしで測った値である。生成は128トークン、入力処理は512トークンを使い、準備運転の後に3回測って平均した。M5 Maxの46.8トークン/秒も、PQ2_0をllama.cppのMetalバックエンドで動かした結果であり、MLX版の実測値ではない。いずれも最大文脈を使ったときの速度や、回答が完成するまでの時間を保証する数字ではない。
省電力の比較にも測定範囲がある。技術報告のRTX 4090・PQ2_0は1トークンあたり0.714mWhだが、これはGPUとそのメモリを含むボード全体の値で、PC全体の消費電力ではない。Apple側の計測にはDRAMが含まれないため、同報告は両者のトークンあたり電力を直接比較していない。
iPhoneでも動く、その意味と確認すべき条件
PrismMLは今回の発表で、Bonsai 2 27BがMLXと独自の低ビット演算処理を通じて、Mac、iPhone、iPadで動くと明記している。大きなモデルを手元へ移す先には、スマートフォンも含まれる。
ただし、iPhoneでの具体的な実測値は世代を区別して読む必要がある。同社が7月14日の発表で示した「iPhone 17 Proで毎秒11トークン」は、容量3.9GBの前世代「1-bit Bonsai 27B」の結果だ。今回の三値版Bonsai 2 27Bの速度ではない。今回の発表と技術報告では、対応するiPhoneの具体的な機種や、端末上での生成速度、実行時の最大メモリ使用量は示されていない。
容量の見方も変わる。発表の約5.9GBは最小のGGUF形式の言語モデルを指し、前掲のMLX配布パッケージは約8.60GBある。保存された重みのほかに作業用メモリが要り、同じ端末ではOSやアプリも動いている。したがって「空き容量が5.9GBあるiPhoneなら使える」とは判断できない。画像を扱うか、どこまで長い文章を読ませるかによっても必要な余裕は変わる。
試すためのアプリとして、PrismMLの公式案内は「Locally AI」を紹介している。App Storeの更新履歴にも、対応端末へのBonsai 27B追加がある。ただし、これはBonsai 2 27Bの対応確認とは分けて考えたい。モデルの世代まで確かめずに選ぶと、この記事で扱う性能とは別のものを試すことになる。
開発者向け資料にも注意点が残る。Bonsai 2の公式ドキュメントは通常のMLXで動くと説明する一方、配布物内の実行上の注意書きは、通常の読み込み処理では必要な変換が適用されず、Swiftでモデル全体を読み込むには追加の組み込みが必要だとしている。説明に食い違いがある以上、MLX対応という表示だけで、一般のiPhoneアプリに読み込ませればすぐ動くとは保証できない。
それでも、スマホ内にこの規模のモデルを置く意味は大きい。たとえば端末内の文書を要約したり、その内容を踏まえて文章を作ったりする際、入力全文をクラウドの推論サービスへ送る必要を減らせる。モデルを取得し、処理を端末内で完結させる構成なら、ネット接続のない場所で使う設計も可能になる。外部検索やクラウドAPIを呼ぶ機能の通信は別だが、身近な文書を処理する場所を選べる点は、PC向けの容量削減とは違う利用価値だ。
実用性を判断するには、起動できるかに加え、最初の応答までの待ち時間や、長い回答を生成するときの発熱と電池消費を確かめたい。PC向けの短い生成テストや前世代のiPhone実測だけでは、その答えは出ない。iPhone対応の発表を出発点に、使う機種とアプリでどの仕事を無理なく任せられるかが、次の評価になる。
導入を決めるのは作業と文脈の長さ
Bonsai 2のGGUFを動かすには、現時点でPrismML版のllama.cppが必要になる。公式の実行ガイドによると、通常版には必要なアダマール変換の処理がまだ入っておらず、PQ2_0とPTQ1_0は読み込みを拒否される。GGUFという拡張子だけで、普段使っているアプリに互換性があるとは判断できない。
最大262,144トークンという文脈長も、少ないメモリで常に使えるという意味ではない。重みのほかに、過去の入力を参照するためのKVキャッシュや演算用の領域が必要になる。公式ガイドは27B系のFP16 KVキャッシュを1トークンあたり64KiBとしており、文脈を長くするほど追加容量が増える。起動スクリプトが搭載メモリに応じて文脈長を選ぶのは、このためだ。
約5.9GBまで言語モデルが小さくなれば、従来は重みを載せるだけで難しかったPCにも選択肢が生まれる。しかし、浮いたメモリを長い文脈に使うのか、画像入力に使うのかで、必要な構成は変わる。保存容量、生成速度、作業の成功率を一つの「効率」にまとめてしまうと、その選択が見えなくなる。
導入を試すなら、自分が扱う文書やコードで、推論強度ごとの正答率と回答完了までの時間を確かめたい。自律的に不具合修正を任せる場合は、単発の回答より、作業を最後まで完了できる割合を測る。その条件で十分な結果が出れば、Bonsai 2 27Bはクラウドへ送らずに処理したい仕事を、手元の機器へ移すための有力な候補になる。