PrismML Bonsai 2 27BはローカルAIを小型化するが、最も難しいテストはなお重要
PrismMLは9月17日、270億パラメータのモデルを消費者向けハードウェア用の5.9GBパッケージに圧縮したBonsai 2 27Bを発表した。同社によれば、PrismML Bonsai 2 27Bはフル精度版に対する総合ベンチマーク性能の98.2%を維持している。
この組み合わせは、ローカルAIにおける判断基準を変える。従来、開発者は快適に動作する小型モデルと、より強い推論能力を持つ大型モデルの間で選択を迫られてきた。Bonsai 2は、270億パラメータ級のマルチモーダルシステムをノートPCや消費者向けグラフィックスカードのメモリ範囲に収めることで、このトレードオフに挑んでいる。
ただし、重みを収めることは最初の試験にすぎない。PrismMLの総合結果はベンダー報告によるものであり、複数のパッケージ形式は5.9GBを超え、現時点でモデルはカスタムランタイムコンポーネントに依存している。最大の疑問は、コンパクトなローカルモデルが長時間にわたるツール駆動型タスクでも信頼性を維持できるかどうかだ。
PrismML Bonsai 2 27Bは270億パラメータ級AIを5.9GBに収める
この発表が重要なのは、PrismMLが基盤となる270億パラメータのアーキテクチャを変えずに、言語モデルのフットプリントを削減したためだ。
Bonsai 2は、テキストと画像を扱うマルチモーダルモデル、Qwen3.8-27Bから派生している。PrismMLはアーキテクチャを維持しつつ、言語モデルの重みの大半を三値表現に変換した。
三値重みは、負の1、0、正の1という3つの値を取る。共有スケーリング値により、ランタイムは推論時にこれらのコンパクトな値を有用な数値演算へ変換できる。
この表現は、単にパラメータを削除したり、モデルをより小さなアーキテクチャに置き換えたりするものとは異なる。Bonsai 2には依然として約270億のパラメータが含まれるが、圧縮された各重みは従来の16ビット値よりはるかに少ないストレージしか必要としない。
PrismMLの発表では、Google v5 TPUを用いて学習された278億パラメータのモデルと説明されている。より詳細なモデル資料では、言語バックボーン、埋め込み層、出力ヘッド、ビジョンタワーを含め、総パラメータ数は273.6億とされている。
公開された最小のGGUFパッケージは、PrismMLのPTQ1_0形式を使用する。言語コンポーネントを約5.95GBに格納しており、フル精度の参照モデルでは約54GBとなる。
PQ2_0と呼ばれる第2のGGUFパッケージは約7.21GBを占める。Appleデバイス向けのMLX言語重みは、このコンテナが追加のスケーリング情報を格納するため、約7.67GBとなる。
未圧縮の0.92GBのビジョンタワーを加えると、完全なMLXパッケージは8.60GBに達する。したがって、見出しの5.9GBという数値は、ダウンロード可能なすべての構成ではなく、最小のテキストモデルのパッキングを示している。
この区別は成果を損なうものではない。より大きなパッケージであっても、フル精度モデルのメモリ要件を大幅に下回る。それでも、特定のダウンロードに対して購入者や開発者が何を期待すべきかには影響する。
ドキュメントによれば、このモデルは262,144トークンのコンテキスト容量を維持している。コンテキストウィンドウとは、モデルが1回の対話で処理できるテキストやその他のトークン化された情報の量を指す。
Bonsai 2は、Qwen3.8-27Bのハイブリッドアテンション・アーキテクチャも維持している。レイヤーの約4分の3は線形アテンションを使用し、長いプロンプトに伴うメモリ使用量の増加を抑えている。
PrismMLはApache 2.0ライセンスの下で重みを公開した。同社はllama.cppベースのデプロイメント向けGGUFビルドと、Appleハードウェア向けMLX版を提供している。
この提供形態により、開発者はクラウド専用サービスよりも大きな制御を得られる。チームはファイルを確認し、自らの環境内で推論を実行し、すべてのプロンプトを外部プロバイダーに送信せずにモデルをテストできる。
今回のリリースは、2026年7月に発表されたPrismML初のBonsai 27Bモデルを基盤としている。前世代は同社の圧縮アプローチを確立し、Bonsai 2ではそれを新しいQwenベースモデルに適用している。
新たな発表では、主張される総合性能維持率が約95%から98.2%へと引き上げられた。より重要なのは、大型モデルをローカルに収めるというPrismMLの訴求が、本格的な作業に十分な品質を維持する方向へ移ったことだ。
ローカル270億パラメータモデルが小型代替案に圧力をかける理由
Bonsai 2は、ローカルデプロイには80億パラメータ級モデルへの縮小が必要だという前提に圧力をかける。
ローカルモデルの利用者は通常、メモリ、応答速度、出力品質という相互に関連する3つの制約のバランスを取る。モデルサイズを大きくすれば能力は向上し得るが、ストレージ、メモリ帯域幅、ランタイム要件も増大する。
従来の量子化は、モデルの重みをより少ないビット数で表現することで、こうした要件を減らす。しかし、強力な量子化は性能を不均一に損なう可能性があり、とりわけ長い推論や正確な指示追従を伴うタスクで顕著だ。
PrismMLは、その三値アプローチがこの曲線を変えると主張する。同社のモデルカードでは、コア表現における実際の平均が重み1つ当たり1.72ビットと報告されている。
PrismMLの14ベンチマークによる思考モード評価では、5.9GBのBonsaiビルドは平均84.78点を記録した。フル精度のQwen3.8-27B参照モデルは86.32点だった。
同じ比較では、従来型のIQ2_XXSビルドは9.4GBを占め、72.59点だった。より大きなUD-Q4_K_XLビルドは17.6GBを使用しながら85.18点に達した。
これらの数値は、限定的ながら重要な主張を裏付ける。PrismMLのテスト構成では、Bonsai 2は従来の低ビット比較モデルよりも大幅に多くの総合品質を維持した。
この圧縮により、完全な言語モデルをより多くのデバイスで高速メモリ内に保持することも可能になる。重みが低速なシステムメモリへ流出すると、推論はインタラクティブな利用には遅すぎるものになり得る。
PrismMLは、Nvidia GeForce RTX 5090で毎秒最大143生成トークンを報告している。Appleでの測定値には、M5 Maxで毎秒約47トークン、M5 Proで28.7トークンが含まれる。
これらの結果はハードウェア固有であり、同社による報告だ。プロンプト長、パッキング形式、ランタイム、熱的条件はいずれもスループットに影響するため、普遍的な速度として扱うべきではない。
それでも、デプロイ可能な範囲には意味がある。開発者はワークステーション上でプライベートなコーディングアシスタントを実行できる可能性があり、AppleノートPCでは有能なローカルのリサーチモデルや文書モデルをホストできる。
これは小型の汎用モデルに圧力をかける。80億パラメータモデルは、起動時間、メモリのオーバーヘッド、旧世代ハードウェア全般でのサポートにおいて優位性を保つ。しかし、圧縮された270億パラメータモデルが同じデバイスに収まるなら、メモリ容量だけで小型モデルを選ぶ理由は弱まる。
クラウドプロバイダーは別種の圧力に直面する。ローカル推論はネットワーク遅延をなくし、プロンプトを組織のセキュリティ境界内に留められる。
たとえば、独自のソースコードを扱うエンジニアリングチームを考えてみよう。ローカルモデルなら、リポジトリをリモートの推論サービスに送信することなく、ファイルのレビュー、テスト生成、技術文書の検索を行える。
同じ論理は、個人記録、社内会議メモ、規制対象文書にも当てはまる。チームは、検索と生成をソース資料の近くに保ちながら、ローカルモデルを検索可能なナレッジベースと組み合わせられる。
多くの要求の厳しいタスクでは、クラウドモデルが引き続き望ましい選択肢となる。より強力な能力、管理されたスケーリング、成熟した運用サポートを提供できるためだ。
したがって直近の課題は、ローカルAIがクラウドを置き換えることではない。ローカルモデルが、日常的でプライベート性が高く、遅延に敏感な作業のより大きな割合を処理できるほど有能になることだ。
三値圧縮は小さなフットプリントを支える仕組み
Bonsai 2は、カスタムカーネルが直接処理するコンパクトな3値コードとして言語重みの大半を格納し、メモリトラフィックを削減する。
標準的なフル精度推論では、各重みは通常16ビットで格納される。数百億のパラメータを持つ密なモデルでは、ランタイム状態を考慮する前から、こうした値が大きなメモリフットプリントを生む。
Bonsai 2は、圧縮された各重みに3つの値のいずれかを割り当てる。PrismMLは128個の重みを共有の16ビットスケールの下でグループ化し、実効表現を重み1つ当たり約1.71ビットにしている。
少数の高精度テンソルにより、モデル全体の平均は1.72ビットへ上昇する。PrismMLによれば、これらのテンソルは言語モデルの約0.098%を占める。
変換には、三値割り当ての前に適用される数学的変換、アダマール回転も用いられる。これは、低ビット量子化の精度を低下させかねない異常に大きな値を再分配する。
ランタイム時には、ネットワークを通じて入力が進む際に生成される中間値である活性化に、対応する変換が適用される。パックされた重みはフル精度に戻して展開されることなく、圧縮状態を維持する。
この設計が重要なのは、ローカル推論がメモリ帯域幅によって制限されることが多いためだ。プロセッサはトークンを生成する間、メモリから重みを繰り返し移動させるため、各ステップで移動するバイト数を減らせば速度とエネルギー効率を改善できる。
ランタイムリポジトリは、異なるBonsai世代にわたり、CUDA、Metal、Vulkan、ROCm、CPU向けデプロイメントをサポートしている。ローカルサービング、ビジョン、ツール統合も提供する。
Bonsai 2自体には、発表時点で互換性の制約がある。必要なアダマール活性化変換は、標準のllama.cppプロジェクトにはまだ取り込まれていない。
現在、ユーザーはPrismMLのフォーク、または同社のセットアップスクリプトがインストールするバイナリに依存しなければならない。これは、同社の実装およびリリースのペースへの依存を生む。
パッキング形式の違いも、もう一つの要素となる。PTQ1_0はより高密度なストレージを使用し、見出しの5.95GBサイズに到達する一方、PQ2_0は各三値を2ビットのスロットに配置する。
高密度なパッキングはメモリトラフィックを減らすが、デコードにはより多くの演算を必要とする。PrismMLの測定では、どちらの形式もすべてのグラフィックスプロセッサで常に高速というわけではない。
Apple向けMLX版には別の妥協がある。このコンテナはグループごとにスケールとバイアスの両方を格納するため、言語モデルパッケージは7.67GBに増加する。
したがって、開発者は最小のファイルを自動的にダウンロードするのではなく、実際のランタイムに基づいて形式を選ぶべきだ。最適なビルドは、利用可能なメモリ、対応カーネル、プロセッサ世代、プロンプト処理の必要性に左右される。
ビジョンシステムも、見出しの圧縮ストーリーの外に残っている。PrismMLはQwenの0.92GBのビジョンタワーを三値重みに変換せず、フル精度で含めている。
この選択は、完全なマルチモーダルパッケージが5.9GBというテキストの数値より多くのストレージを占める理由を説明する。また、追加の量子化損失からビジョン品質を保護している可能性もある。
実務的に言えば、Bonsai 2はどこでも動作する単なる小さなファイルではない。その利点が互換性のある低ビットカーネルに依存する、モデルとランタイムが連携したシステムだ。
このことは、このリリースを通常のポストトレーニング量子化アップロードより技術的に興味深いものにしている。同時に、エコシステムへの採用をこの物語の不可欠な要素にしている。
98.2%という主張にはより慎重な読み解きが必要
総合ベンチマーク結果は有望だが、Bonsai 2がすべての能力やワークフローの98.2%を維持することを意味するわけではない。
PrismMLの公開発表は、20ベンチマーク群で83.9という総合スコアを引用している。これをQwen3.8-27Bの85.4と比較し、報告された98.2%の維持率を導いている。
詳細なモデルカードでは、異なる14ベンチマークの集計が示されている。そこでは、Bonsai 2は84.78点、フル精度版は86.32点であり、これも約98.2%に相当する。
どちらの計算も会社発表の数値である。ベンチマーク群と合計値が異なるため、独立して再現された単一のテスト結果であるかのように混同すべきではない。
性能はカテゴリーによっても異なる。14ベンチマークの結果では、Bonsai 2は4つの数学テストで96.57点を記録し、フル精度版の97.06点と比較されている。
コーディングカテゴリーでは89.42点に達し、参照スコアの89.07点をわずかに上回った。指示追従も81.25点から82.66点へ上昇している。
こうした小幅な向上は、圧縮によって基盤モデルそのものが改善されることを証明するものではない。ベンチマークのサンプリング、採点のばらつき、デコーディングの挙動により、わずかな逆転が生じる場合がある。
より大きな低下は、知識、推論、ビジョンで見られる。Bonsai 2は知識と推論を合わせたカテゴリーで79.86点を記録し、参照モデルの85.55点を下回った。
ビジョンの平均スコアは71.36点から66.19点へ低下した。画像からの文字認識をテストするOCR Bench v2では、Bonsai 2は56.88点で、フル精度版の60.99点に対して低い。
こうした差は、文書を多く扱うワークフローで重要になる。数学やコードでは高い性能を維持できるモデルでも、スクリーンショット、スキャンした帳票、チャート、詳細な視覚的証拠を解釈する際には精度を落とす可能性がある。
エージェント型の結果についても慎重な見方が必要だ。ツール呼び出しベンチマークであるBFCL v3では、Bonsai 2は74.92点、フル精度版は76.74点だった。
集計上の差は比較的小さい。しかし、単一のツール呼び出しテストだけでは、長時間にわたるエージェントループ全体での信頼性を立証できない。
エージェント型システムでは、誤りが増幅される。ファイルの選択、コマンド、途中の結論がわずかに誤っているだけで、その後のすべてのステップが変わり得る。
長文コンテキスト対応にも同様の区別がある。262,144トークンをサポートすることは、アーキテクチャとランタイムがその量を受け入れられることを意味する。すべての位置で一貫した想起や推論が保証されるわけではない。
ここでは独立したテストが最も重要になる。レビュー担当者は、Bonsai 2とフル精度Qwenについて、同一のプロンプトセット、ランタイムのバージョン、コンテキストサイズ、デコーディング設定を比較すべきである。
最初の実用的な報告はすでに入り混じっている。あるユーザーは、8GBのM2 Mac miniでモデルを完全に実行し、毎秒約7.6トークンを達成したと報告しており、基本的な動作要件の主張を裏付けている。
一方で、複雑なプロンプトや長い推論における挙動に疑問を呈する初期ユーザーもいる。これらの報告は逸話的で、ハードウェアに依存し、安定した品質プロファイルを確立するには時期尚早である。
SiliconANGLEの報道は、性能と効率の数値を会社側の主張として適切に位置付けている。独立評価が成熟するまで、この区別は明確に保たれるべきだ。
PrismMLは、公開された重みと再現可能なファイルを備える、異例にコンパクトなリリースを明確に示した。ただし、あらゆる高負荷ワークロードで能力低下がわずか1.8%にとどまることは、まだ確立されていない。
ローカルAIはプライバシーを高めるが、導入には依然としてコストがある
Bonsai 2はローカルにとどめられる処理の範囲を広げる一方、セルフホスティングでは運用責任がプロバイダーからユーザーへ移る。
最も明確なユースケースは、プライベートな文書処理だ。ユーザーは、元データをアップロードすることなく、ローカルのノートを要約し、社内ファイルから情報を抽出し、機密性の高いナレッジコレクションを検索できる。
ソフトウェア開発も論理的な対象となる。ローカルでホストされたコーディングアシスタントは、ワークステーションの既存のアクセス境界内で、リポジトリを検査し、パッチを提案し、開発ツールを呼び出し、テストを生成できる。
マルチモーダル対応により、画像ベースのタスクも加わる。チームは、インターフェースのスクリーンショットを分析し、文書からテキストを抽出し、図表と書面の指示を組み合わせられる。
ただし、ビジョンにおけるベンチマーク差は、こうしたシナリオに検証が必要であることを示している。高リスクの光学文字認識を、一般的な集計スコアだけに依存させるべきではない。
ローカル推論は第三者への露出を減らせるが、それだけでアプリケーションが安全になるわけではない。モデルサーバーは、設定ミス、ネットワークへの露出、過剰なファイルおよびコマンド権限の付与を受ける可能性がある。
PrismMLのドキュメントによると、デモサーバーはデフォルトでローカルアドレスにバインドされる。このアドレスを変更したユーザーは、サービスをマシンの外部に公開する可能性がある。
ツールを利用するエージェントには、追加のリスクがある。ファイルを編集したりコマンドを実行したりできるモデルには、権限境界、ログ、人間によるレビューが必要だ。
チームはモデルの更新も管理しなければならない。クラウドプロバイダーはインフラを一元的に置き換えられるが、ローカル導入ではデバイスごとに異なるバイナリ、重みのバージョン、設定が蓄積する可能性がある。
カスタムランタイムが必要であることは、その負担を増幅させる。ユーザーがサポート対象の経路で受け取るには、セキュリティ修正と互換性の変更がPrismMLのフォークに反映されなければならない。
ハードウェア適合性は、アプリケーション全体で評価すべきだ。モデルの重みはメモリ消費の一部にすぎない。
ランタイムには作業メモリが必要であり、キー・バリューキャッシュはコンテキスト状態を保存し、マルチモーダルコンポーネントは追加のリソースを消費する。そのため、長いプロンプトは、名目上は対応しているデバイスでも快適に動作する上限を超えさせることがある。
バッテリー駆動では、別のトレードオフも生じる。PrismMLは、M5 Proでのデコーディング時にGPU消費電力が約27.5ワット、CPUとGPUの合計が34.1ワットだったと報告している。
これらの測定にはシステムのすべてのコンポーネントが含まれておらず、Nvidiaのボード測定値と直接比較することもできない。それでも、ローカル推論が無償ではないことを示している。
最適な導入パターンはハイブリッドかもしれない。日常的かつ機密性の高い作業はデバイス上にとどめ、特に難しいタスクは明示的なルールのもとで、より強力なマネージドモデルへ移す。
この構成により、組織はデータがいつマシンを離れるかを管理できる。また、品質がプライバシーやレイテンシより重要なタスクを、コンパクトなモデルに無理に処理させずに済む。
判断は、パラメータ数だけでなく、測定したタスク性能に基づくべきだ。既存サービスを置き換える前に、チームは自社のコード、文書、画像、ツール操作のシーケンスをテストすべきである。
Bonsai 2では、重みと実行リソースが公開されているため、この種のテストがより身近になる。残る課題は、運用面での節約が統合と保守のコストを上回ることを証明することだ。
Bonsai 2 27Bのローンチ後に注目すべき点
Bonsai 2が長期的なローカルAIの選択肢となるかは、独立評価、アップストリームのランタイム対応、継続的な本番導入という3つのシグナルによって決まる。
最初のシグナルは、独立したベンチマーク再現である。最も価値の高いテストは、Bonsai 2をフル精度Qwen3.8-27Bおよび従来型の量子化モデルと、同一条件で比較するものになる。
評価者は平均値以上の情報を報告すべきだ。タスク別の失敗、応答長、推論ループ、視覚精度、長文コンテキストの想起は、圧縮がどこで挙動を変えるかを明らかにする。
エージェント型コーディングには、特に注意が必要だ。多数のツール呼び出し、リポジトリ内の探索、テスト実行を必要とするベンチマークは、単独のコード補完よりも優れたストレステストになる。
Bonsai 2がこうした評価でもフル精度版に近い性能を維持すれば、PrismMLの知能密度という主張は大幅に強まる。品質低下が大きければ、このモデルの最適な用途は、より単純なタスクまたは多少の誤差を許容できるタスクに限定される。
2つ目のシグナルは、主流ランタイムでの対応だ。PrismMLによると、Bonsai 2はHadamard活性化変換がアップストリームに取り込まれていないため、現在は同社のllama.cppフォークを必要とする。
広く使われるプロジェクトに採用されれば、導入時の摩擦と単一ベンダーのバイナリへの依存は減る。また、実装はより多くのレビュー、最適化、ハードウェアテストにさらされることになる。
ランタイム対応の広がりは、ベンチマーク品質と同じくらい重要になり得る。技術的に印象的な形式でも、開発者が慣れ親しんだツールで導入できなければ普及は難しい。
3つ目のシグナルは、デモの外における実際の導入だ。ダウンロード数は初期の手がかりになるが、再現可能なアプリケーションと継続的に保守される統合の方が、より確かな証拠となる。
有用な指標には、安定したコーディングアシスタント、プライベートなリサーチシステム、ローカルのマルチモーダル検索、評価段階を超えて継続するエンタープライズパイロットが含まれる。コンパクトなモデルがまだ対応できないワークロードを特定するため、失敗報告も同様に価値がある。
競争も激しくなる。ユーザーにより多くのメモリがある場合、従来型の4ビットモデルはすでに高い品質を提供しており、一方で小型のネイティブモデルは控えめなハードウェアでより容易に動作する。
Bonsai 2は、これらの選択肢をなくすものではない。より大きな基盤モデルと異例に積極的な圧縮を組み合わせ、新たな曲線上の一点を提示している。
開発者にとって、次のステップは実用的なテストだ。適切なパッケージをダウンロードし、対象マシンで小規模なベンチマークを再現し、権限を拡大する前に実際のプロンプトを評価する。
エンタープライズの購入担当者は、タスク単位の精度、ランタイム対応のコミットメント、明確なセキュリティモデルを求めるべきだ。98.2%という数値を包括的なサービスレベル保証として扱ってはならない。
PrismML Bonsai 2 27Bはすでに基本的な結果を示している。27Bクラスのモデルは、最小の言語専用形式では6GB未満に収められる。残る疑問は、実際の作業が長く、視覚的で、エージェント型になったときにも、その密度が信頼できるものとして維持されるかどうかだ。
プライベートなローカルモデルはワークフローを改善するだろうか。それとも、保守と品質面のトレードオフが、得られる制御の利点を上回るだろうか。答えは今や、有能なモデルが収まるかどうかよりも、その後に何が起きるかに左右される。
