【geek-terminalニュース】Bonsai 27Bの最新情報：27B推論モデルを1-bit/Ternaryでスマホ級へ押し込むローカルLLM圧縮実験

【事象の全貌と背景】

以前お伝えしたBonsai 1-bitやBonsai Imageの続報です。今回の主役は、PrismMLが2026年7月14日に発表したBonsai 27B。公式発表とHugging Face上のモデルカードで確認できる範囲では、これはQwen3.6-27Bをベースにした27B級のオープンウェイト推論モデルで、1-bit binary版と1.58-bit ternary版の2系統が提供されています。MarktechPostやThe Decoderも、ラップトップやスマートフォン上で動く低ビットLLM、あるいはiPhoneに収まるフルオープンな推論モデルとして紹介しており、焦点は明確にオンデバイス推論です。

ここで重要なのは、単なる小型モデルではない点です。ローカルLLM界隈では、7Bや8B級をスマホやノートPCで動かす話はすでに珍しくありません。しかし27B級の推論モデルを、メモリ数GB級まで圧縮し、それでも実用的な推論能力を残せるのか、という問いは別物です。編集長視点で一番おいしいのはここです。巨大モデルを雑に量子化して動いた、ではなく、1-bitやternaryという極端な表現で、性能劣化、速度、コンテキスト長、実装互換性の全部がぶつかる。Bonsai 27Bは、ローカルLLM勢にとって夢の圧縮実験であり、同時に現場で踏むエラーまで含めてニュースになっています。

【技術的ディープダイブ】

公式に確認できる中核仕様は、Qwen3.6-27B由来の27B hybrid-attention causal language modelをベースにし、アーキテクチャ自体は変更せず、重み表現を低ビット化している点です。PrismMLのBonsai 27Bコレクションには、Bonsai-27B-gguf、Ternary-Bonsai-27B-gguf、AWQ 4-bit版、unpacked版、WebGPU kernelsなどが並びます。つまり配布形態は、llama.cpp向けのGGUFだけでなく、Transformers、vLLM、SGLang、Docker Model Runner、WebGPU実験までを意識した広い構成です。

数字を見ると、このリリースの異常さが分かります。公式系の説明では、1-bit形式によってFP16 unpacked版の約54GBに対し、ネイティブ1-bit版は約3.9GB規模まで小さくなるとされています。Hugging FaceのBonsai-27B-unpackedページでは、1-bit重みをまだネイティブサポートしない標準ツール向けにFP16 safetensors互換版も用意されていますが、PrismMLが推奨するのはネイティブ1-bitモデルです。ここは重要で、unpacked版は互換性のための逃げ道であって、Bonsaiの本命であるメモリ削減や高速ローカル推論の利点は得られません。

さらにKV cacheにも工夫があります。GGUF版の説明では、near-losslessな4-bit KV量子化を使い、hybrid backboneでは64層中16層だけがfull-attention cacheを増やすため、最大262KトークンのウィンドウでもKV cacheは約4.3GBに抑えられるとされています。これは、単に重みを小さくしただけでは長文コンテキストでメモリが破綻する、というローカル推論の現実を見た設計です。公式系情報では、日常的なノートPCで44 tok/s、iPhone 17 Pro Maxで11 tok/sという実行速度も示されています。ただし、これらは公式・モデルカード側の提示値であり、ユーザー環境で常に再現される実測値として読むべきではありません。

【コミュニティの生々しい熱量と議論】

Redditのr/LocalLLaMAでは、期待と検証と混乱がかなり濃く出ています。あるユーザーは、ついに8Bを超えるモデルでこの新しい方法論を使う本格モデルが来た、という趣旨で盛り上がっています。これはローカルLLM勢の感覚としてかなり自然です。8B級の省メモリ化ではなく、27B級をスマホ・ノートPC級に寄せるからこそ、夢があります。

一方で、実用面の評価は割れています。ある実行報告では、Ternary GGUFをPrismML側のllama.cpp forkで動かし、M4 Pro 48GB環境、32K contextで約10GBのメモリ使用だったとされています。これはコミュニティ投稿ベースの報告であり、公式ベンチではありませんが、ローカル実行勢が本当に知りたい生の数値です。また別のユーザーは、Qwen3.6 27Bの2bit量子化と比べて、Bonsai 27Bの方がはるかに賢く感じる、何か特別なことが起きている、という趣旨で評価しています。

ただし絶賛一色ではありません。検索結果で確認できるReddit上の具体発言には、Bonsai 27Bは単純タスクにはかなり使いにくく、コーディングタスクでも厳しい、思考プロセスが途中で切れて結果を返さない、という不満もあります。さらに、-n値の調整や省略で出力切れが改善する場合があるが、それでも結果はかなり悪い、という報告もあります。ここはBonsai 27Bの面白さであり怖さです。27B級が3.9GB級に収まるというロマンと、実タスクでの応答品質・安定性は別問題なのです。

実装面の泥臭さも濃いです。Redditでは、Q_2 official supportがb9994にあるという話、Q2_0とQ2_0_g64を混同しているのではないかという指摘、CUDAやVulkanではまだサポート状況に注意が必要というコメントが出ています。さらに、Ternary-Bonsai-27B-PQ2_0を落としてgguf_init_from_readerのinvalid ggml type 142エラーに遭遇したユーザーもいます。別ユーザーは、mainlineではなくPrismML側のcloned llama.cppを使い、不要なスイッチを外した最小構成でllama-serverを起動するよう助言しています。ここから見えるのは、Bonsai 27Bがワンクリックの消費者向けAIアプリではなく、まだビルド、フォーク、カーネル、GGUF種別、バックエンド対応を読み解く必要のあるギーク向けリリースだという現実です。

【今後の展望とエコシステムへの影響】

Bonsai 27Bが示しているパラダイムシフトは、小さいモデルを賢くする方向だけではありません。大きいモデルを極端に薄くして、スマホ級・ノートPC級に落とす方向です。これが本当に安定すれば、ローカルLLMの競争軸は、7Bでどこまで頑張るかから、27B級やそれ以上をどこまで低ビットで実用速度に持ち込めるかへ移ります。クラウドAPIが不要になる、という単純な話ではありません。むしろ、プライバシー重視の下書き、オフライン推論、ローカルRAG、常駐エージェント、ブラウザ内推論など、クラウド巨大モデルに投げる前のローカル前処理層が分厚くなる可能性があります。

一方で、オワコン化しそうなのは、ただ重みサイズだけを小さくした低品質な量子化です。Redditの反応でも、Q4やQ8に知能で勝っているわけではないという冷静な指摘があります。つまりBonsai 27Bの価値は、量子化ビット数の数字遊びではなく、27B級のモデル能力をどの程度保ちながら、どの実行環境で、どれだけ安定して返答できるかにあります。公式情報では15ベンチマークでフル精度ベースラインの90〜95%を維持するという説明もありますが、コミュニティ実行ではタスクによって出力切れや品質低下の報告もあるため、現時点ではベンチと実用の差分を追う段階です。

エコシステム面では、llama.cpp、MLX、WebGPU、SGLang、vLLMのような実行基盤側の対応が勝負になります。モデルが出ても、mainlineに入っていない量子化型、CUDAやVulkan未対応のカーネル、誤ったGGUF選択があると、ユーザーはすぐ詰まります。逆に言えば、ここが整うと、27B級ローカル推論は一部のワークステーション趣味から、普通のノートPCやスマホで触れる実験領域に近づきます。Bonsai 27Bは完成品というより、圧縮モデル、実行ランタイム、コミュニティ検証が一斉に動く号砲です。ギーク的に見るべきポイントは、3.9GBに収まったという見出しそのものではなく、その小ささでどこまで考え続けられるのか、どのバックエンドで速度が出るのか、そしてQ4/Q8や通常の小型モデルと比べて、本当に日常ワークフローの座席を奪えるのかです。