メインコンテンツへスキップ
見出し画像

ノートPCで27Bが47トークン/秒。Ternary Bonsai 2 27Bの「98.2%」は、推論努力を下げた瞬間に崩れる

    本記事の対象

    • ローカルLLMを実務で回したい開発者・エンジニア。

    • 量子化モデルの精度劣化をどう見積もるべきか悩んでいる方。

    • 「圧縮しても性能はほぼ落ちない」という主張の検証方法を知りたい方。

    要約

    PrismMLが2026年9月17日に公開した Ternary Bonsai 2 27B は、Qwen3.8-27B を三値 {−1, 0, +1} に圧縮し、53.8GBのモデルを5.93GBに収めたモデルです。公式は「ベンチマーク性能の98.2%を保持」と発表しました。本記事では、まず1.72ビット/重みという数字がどう積み上がるのかを分解し、次に公開されたホワイトペーパー全14ページの付録まで追って、98.2%という保持率がどの条件で成立し、どの条件で崩れるのかを確認します。読み終えるころには、このモデルを自分の用途に採用すべきかどうかを、公式のヘッドラインではなく測定条件から判断できるようになります。

    画像
    図1. 公式ホワイトペーパーの表紙。掲げられているのは「約9.1倍小さい」「98.2%の知能を保持」「ノートPCで46.8トークン/秒」の3点。この3つの数字がそれぞれ別の条件で測られていることが、本記事の出発点になる。出典: PrismML「Ternary Bonsai 2 27B」ホワイトペーパー

    ローカルLLMの話になると、必ず同じ壁にぶつかります。動かしたいモデルはメモリに載らない。載るサイズまで量子化すると、コードを書かせた瞬間に挙動がおかしくなる。どこまで圧縮していいのか、判断する材料がない。

    PrismMLが出した答えは明快でした。重みを3つの値しか取らない形にまで潰し、それでも元の98.2%を保つ。数字だけ見れば、もう議論の余地がないように思えます。

    ただ、公開されたホワイトペーパーは14ページあり、そのうち目立つ主張が載っているのは最初の6ページです。残り8ページ、とくに付録Cを読むと、話はもう少し込み入っていました。

    2か月で何が変わったのか

    PrismMLは2026年7月14日に初代 Bonsai 27B を公開しています。ベースは Qwen3.6-27B、三値版が5.9GBで保持率95%、1ビット版が3.9GBで90%。当時の売りは、1ビット版が iPhone 17 Pro のメモリに収まる点でした。

    今回の Bonsai 2 27B はベースモデルが Qwen3.8-27B に替わり、保持率が95%から98.2%へ上がりました。PrismML自身も今回の改善によって「実用上ほぼロスレス」と言える水準に達したと表現しています。

    画像
    図2. 注目すべきは最下段ではなく、その1つ上の行。従来型の2ビット量子化 IQ2_XXS は7.3GBと Bonsai より大きいのに、スコアは75.2で8.7ポイント低い。「小さくして、かつ強い」が同時に成立している点が、この表の本題である。出典: PrismML ホワイトペーパー Table 7

    ここで一点、見落とされやすい事実があります。今回の Bonsai 2 で公開されているのは三値版だけで、1ビット版はまだありません。Hugging Faceのコレクションに並ぶのは gguf、mlx-2bit、gguf-dev の3つで、ホワイトペーパーのタイトルも「Ternary Bonsai 2 27B」。7月の「スマホで動く」という話題性を期待して待っていた人は、今回はまだ対象外ということになります。

    1.72ビットはどこから来るのか

    三値量子化という言葉は、重みが −1、0、+1 のどれかしか取らないことを意味します。取りうる値が3つなら、情報量は log₂3 ≈ 1.585ビット。ただし実際には、128個の重みごとに共有するFP16の倍率が1つ付きます。

    画像
    図3. 公称値が「1.72」で、配布ファイルが「1.76」や「2.16」になる理由。カーネルが直接読めるパッキング形式に落とし込む分だけ、理論値より太る。下段の注記も重要で、5.93GBは言語モデル部分だけの数字である。出典の数値をもとに筆者作成。出典: PrismML ホワイトペーパー 2.1〜2.3節

    面白いのは、初代との差分がここに出ていることです。初代はすべての重みを三値化していましたが、Bonsai 2 では線形アテンション層の状態パス(in_proj_a、in_proj_b、conv1d など)と正規化層を高精度のまま残しました。その追加コストは2,620万パラメータ、言語モデル全体の0.0976%にすぎません。全体の0.1%を三値化の対象から外す——それだけで平均ビット幅は1.71から1.72へ、わずか0.01しか増えない。どこを諦めないかを選ぶ余地が、この規模でもまだ残っていたわけです。

    もうひとつの仕掛けが重みの回転です。重みはブロック1024のWalsh–Hadamard変換と固定符号で回された基底に格納され、推論時には活性化側に同じ変換をかけて辻褄を合わせます。SpinQuantの系譜にある手法で、外れ値を分散させて低ビット化しやすくする狙いがあります。ただしこれは無料ではなく、PrismML自身がバッチサイズ1では活性化側の回転が行列積以外で最も重いコストの一つとして残っており、オンデバイスのデコード遅延に対する最も直接的な改善余地だと認めています。

    量子化そのものの仕組み、プルーニングや蒸留との関係を整理しておきたい方は、以前の記事『LLM軽量化・最適化技術の完全ガイド:量子化からMoEまで徹底解説』で基礎から解説しています。本記事は、その先にある「実際の製品でどこまで詰められたか」の検証編という位置づけです。

    速度の数字は、どのファイルの話なのか

    公式ニュースには「RTX 5090で最大143トークン/秒、M5 Maxで44トークン/秒」と書かれています。ホワイトペーパーのTable 5を見ると、その内訳がわかります。

    画像
    図4. 142.5トークン/秒はPQ2_0、つまり7.25GBのファイルの数字。サイズ最小の5.93GB版(PTQ1_0)は同じRTX 5090で134.4トークン/秒にとどまる。小ささと速さは別の軸だとわかる。出典: PrismML ホワイトペーパー Table 5

    この表を眺めていて、公式ニュース記事と噛み合わない箇所が1つ見つかりました。ニュース記事は「RTX 4090では1トークンあたり0.581 mWhしか消費しない」と書いています。ところがTable 5のRTX 4090の行は、PQ2_0が0.714、PTQ1_0が0.682。0.582という値が載っているのはRTX 5090のPQ2_0の欄です。行を1つ取り違えた可能性が高いと見ています。

    M5 Maxの数字も、ニュース記事は44トークン/秒、ホワイトペーパーTable 6は46.8トークン/秒。どちらも致命的な誤りではありませんが、ベンダー発表を引くときはホワイトペーパー側の数値を採るのが安全です。

    PTQ1_0とPQ2_0の使い分けにも癖があります。PTQ1_0はPQ2_0より18%少ないデータしか動かさない一方、展開に追加の演算が必要になるため、AdaクラスとL4では速く、Hopper、Ampere、Blackwell、Apple Siliconでは遅い。手元のGPUによって正解が入れ替わる、という面倒な作りです。

    同じ「メモリを削ってローカルで動かす」課題に、量子化ではなくオフロードと実行順序の工夫で挑んだ例は、『35BのMoEを、3GiBのメモリで動かす。OSS推論フレームワーク「edge0」の三つの仕掛けを一次情報で解剖する』で扱いました。アプローチの違いを見比べると、どちらが自分の環境に向くか判断しやすくなります。

    デモ2本が示しているもの

    PrismMLは公式デモ動画を2本公開しています。どちらもRTX 5090上で動かしたものです。

    動画1. Cline上でコーディングエージェントとして動く様子(1分19秒)。見るべきは生成速度ではなく、ツール呼び出しが何往復も続いたあとに破綻していないかどうか。出典: PrismML公式Vimeo

    動画2. コンピュータ操作(Computer Use)のデモ(2分31秒)。画面を見て次の操作を決める工程が続くため、視覚性能と長工程の安定性が同時に問われる題材になっている。出典: PrismML公式Vimeo

    デモとしては十分に説得力があります。ただ、2分程度のデモで確認できるのは「破綻しないこと」までで、「元のモデルと同じだけ完遂できること」ではありません。そこを測るための数字が、ホワイトペーパーの後半にあります。

    「98.2%」が崩れる場所

    まず前提を確認します。98.2%という数字は、20個のベンチマークの平均を、思考モードかつ推論努力(reasoning effort)xhigh で測った条件のものです。PrismMLはこのモデルの推奨設定を xhigh または medium としており、low は思考量を減らさないと注記しています。

    では medium ではどうなるのか。付録Cの表11に、同じ20ベンチマークを medium で測った結果が載っています。

    画像
    図5. 同じホワイトペーパーの中だけで、保持率は98.2%から75%台まで分布する。ヘッドラインの数字は「最も条件の良いところ」を指していると理解しておいたほうがいい。出典の値をもとに筆者作成。出典: PrismML ホワイトペーパー 4章・Table 7・Table 11

    medium での20ベンチ平均は、Qwen3.8-27B FP16 が82.6、Bonsai 2 が79.3。保持率は96.0%に下がります。2.2ポイントの差、と言えばわずかに聞こえますが、個別の項目を見ると分布はかなり偏っています。

    画像
    図6. 落ち込みが集中するのは AIME25(−11.67)、GPQA Diamond(−8.78)、τ²-Bench(−8.64)。一方 IFBench は 55.00 対 55.33 で圧縮版のほうがわずかに上回る。劣化は全体に薄く広がるのではなく、特定のタスクに刺さる。出典: PrismML ホワイトペーパー Table 11

    そして、エージェント用途を考えている人にとって最も重いのが次の2つです。Terminal-Bench 2.1 で52.8 対 69.7、SWE-bench Verified で60.8 対 80.6。いずれもフル精度のおよそ4分の3にとどまります。

    PrismMLはこれを隠していません。むしろ長工程のエージェント評価は強い圧縮に対して容赦がなく、この規模では何の進展も出せないモデルが多いなかで、Bonsai 2 は持続的なツール利用とエンドツーエンドのソフトウェア開発タスクをこなせると、達成として書いています。その評価自体は妥当です。ただ「98.2%」という見出しと、「SWE-benchで75%」という本文を並べて読まないと、導入判断を誤ります。

    率直に言うと、ここが本記事で一番伝えたい点です。ローカルで動く27Bが実用域に入ったのは間違いない。しかし「クラウドのQwen3.8-27Bと同じものが手元で動く」と読むのは行きすぎで、置き換えられる作業とそうでない作業の線引きが必要になります。

    削れるのは知識と視覚、残るのは数学と指示追従

    カテゴリ別に見ると、劣化の構造がはっきりします。

    画像
    図7. 数学はほぼ無傷(−0.49)、指示追従はむしろ向上(+1.41)。削られているのは知識と推論(−2.71)、視覚(−3.05)、エージェント/ツール呼び出し(−2.17)。パラメータに「詰め込まれた知識」が先に痩せる、という直感どおりの結果になっている。出典: PrismML ホワイトペーパー Table 8

    この傾向は使い分けの指針になります。手順が明確で、必要な情報をコンテキストで渡せる仕事——社内文書の要約、定型的なコード変換、構造化データの抽出——は、ローカルの Bonsai 2 に任せやすい。逆に、モデル自身が抱えている知識を引き出す仕事や、画像の細部を読む仕事は、フル精度側に残したほうが安全です。

    なおベースとなった Qwen3.8 系については、『Qwen3.8-Flash-Next徹底解説:Qwen4を先出しする新モデルの正体と、割れるサイズ論争』で系列全体の位置づけを整理しています。圧縮前のモデルがどんな設計思想なのかを押さえておくと、今回の結果の読み方が変わってきます。

    動かす前に知っておくべき3点

    (1) 標準の llama.cpp では動きません。 モデルカードには対応アプリの一覧も並んでいますが、同じページに、標準の llama.cpp は PQ2_0 と PTQ1_0 を未知の型として拒否し、Q2_0 は警告なしに読み込んだうえで意味のない出力を返す、と明記されています。Hadamard変換の実行時処理を持っていないためです。まず PrismML-Eng/llama.cpp のフォーク版バイナリを入手する、が正しい第一歩になります。

    (2) 画像を使うなら容量が増えます。 5.93GB は言語モデル単体の数字で、画像入力にはvision tower(mmproj)の0.63GBが別途必要です。テキストのみなら読み込まれないので、テキスト用途のメモリ見積もりは5.93GBのままで構いません。

    (3) ライセンスは Apache 2.0、コンテキストは262Kトークン。 商用利用の制限はなく、長文コンテキストもベースモデルから引き継いでいます。ここは素直に強い。

    画像
    図8. どのファイルを落とせばいいかの早見表。PTQ1_0 と PQ2_0 は中身が同じモデルで、違いは詰め方だけ。出典の数値をもとに筆者作成。出典: PrismML ホワイトペーパー Table 3・Table 4

    まとめ

    Ternary Bonsai 2 27B は、27B級のモデルが6GB前後のファイルに収まり、ノートPCで対話可能な速度で動くことを実証しました。従来型の2ビット量子化 IQ2_XXS より小さく、しかも8ポイント以上高いスコアを出している点は、低ビット化のアプローチとして明確な前進です。

    一方で「98.2%」は、20ベンチマークの平均を推論努力 xhigh で測った条件下の数字でした。medium なら96.0%、長工程のエージェント評価では約75%まで落ちます。ホワイトペーパーは付録でそれを開示しており、隠蔽ではありません。読む側が最初の6ページで止まらないかどうか、という話です。

    次の一手としては、まずフォーク版バイナリで手元の環境に載せ、自分の実務タスクを10件ほど流して、xhigh と medium の差を体感してみることをおすすめします。ベンチマークの平均値より、その10件のほうが採用判断には効きます。

    参考資料・使用素材

    関連記事

    この記事が役に立ったら、ぜひスキ❤️やコメントをお願いします!質問があれば、コメント欄でお気軽にどうぞ。

    テクノロジーで、あなたのビジネスに革新を

    画像

    この記事をお読みいただき、ありがとうございます。「システムを作りたいけど、初期投資が高すぎる」「IoT製品を開発したいが、技術とコストの両面で不安」とお悩みではありませんか?

    ✨ 初期費用0円でSaaSを開発。ポノテクのマイクロSaaSサービス

    私たちポノテク株式会社は、お客様専用のSaaSを初期費用0円で開発します。

    画像

    マイクロSaaS開発の特徴

    • 初期費用0円: Webアプリ、モバイルアプリ、デスクトップアプリを無料で開発

    • 月額サブスクで提供: 必要な機能に応じた月額料金で利用開始

    • 買取オプション: サブスク利用中に、システムを自社所有物として買い取ることも可能

    「自社専用のSaaSが欲しいけど、数百万円の初期投資は厳しい」そんな企業様に最適なソリューションです。

    🔧 IoT受託開発 × 補助金活用で、ものづくりを支援

    ハードウェアからソフトウェアまで一貫して開発可能。IoTシステムの構築を、補助金を活用して最大66%のコスト削減で実現します。

    画像

    補助金活用でシステム開発コスト削減
    経済産業省認定のIT導入支援事業者として、以下のサービスをワンストップで提供。

    • 補助金診断・申請サポート: 採択率82.8%の実績で、最適な補助金をご提案

    • 要件定義から開発まで一貫支援: 補助金要件に100%準拠した開発体制

    • 省力化補助金・ものづくり補助金など: 最大8,000万円の補助金活用をサポート

    📚 最新刊『ComfyUIマスターガイド』5月9日発売!

    AI技術に関する深い知見を持つ私たちの代表・早野康寛が共著者として参加した画像生成AI書籍『ComfyUIマスターガイド』が、2025年5月9日にSBクリエイティブ社より発売されました。AI画像生成の最前線を理解したい方は、ぜひご覧ください。

    📈 こんな課題をお持ちの企業様に最適です

    • 「専用SaaSが欲しいが、初期投資を抑えたい」

    • 「IoT製品を開発したいが、ハードとソフト両方の知見が必要」

    • 「補助金を活用したいが、申請方法がわからない」

    • 「サブスクで始めて、必要なら買い取りたい」

    🌟 三つの強みで、確かな未来を共に創る

    1. マイクロSaaS開発: 初期費用0円で専用システムを構築

    2. IoT受託開発: ハードウェアからソフトウェアまで一貫対応

    3. 補助金活用: 開発コストを最大66%削減

    ぜひ初回無料相談をご利用ください。技術と経営の両面から、貴社の成長戦略を共に考えましょう。
    ポノテク株式会社へのお問い合わせはこちらから!

    ▶ テクノロジーで成長を加速する第一歩を踏み出す
    ― 技術で未来を創る。ポノテク株式会社

     
     
    AI Driven LabはAI駆動の未来を探求し、最新技術・洞察・アイデアを発信するメディア。エンジニア視点で革新を追求します。 運営元:ポノテク株式会社 https://www.ponotech.net

    あなたへのおすすめ