
Bonsai vs Bonsai 27B:同じファミリー名で、パラメータ数は16倍
- openaiNEWOpenAI: GPT-6 Luna2026-09-2237知能
- openaiNEWOpenAI: GPT-6 Sol2026-09-2248知能
- anthropicNEWAnthropic: Claude Opus 5.52026-09-2258知能
- grokNEWGrok 4.72026-09-2146知能
- OrcaNEWOrca: OrcaCyber Zero 1.02026-09-17$3.00 / $5.00 100万トークンあたり
- orcaNEWOrca: OrcaVerify Text 1.02026-09-16$2.00 / $0.00 100万トークンあたり
- deepseekNEWDeepSeek: DeepSeek V4.1 Flash2026-09-1040知能
- openaiOpenAI: GPT-6 Astra2026-09-0453知能77コーディング
- googleGoogle: Gemini 3.8 Flash2026-09-0241知能76コーディング
- qwenQwen: Qwen3.8 Max (0902)2026-09-0245知能76コーディング
- anthropicAnthropic: Claude Fable 5.12026-09-0153知能82コーディング
- AlibabaQwen: Qwen3.8 Flash2026-08-26$0.15 / $0.47 100万トークンあたり
- z-aiZ.ai: GLM 5.3 Flash2026-08-2642知能72コーディング
- DeepSeekDeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.22 / $0.66 100万トークンあたり
- z-aiZ.ai: GLM 5.32026-08-1845知能75コーディング
- obsidianQwen3.8 27B2026-08-1534知能68コーディング
- deepseekDeepSeek: DeepSeek V4 Pro 08132026-08-1236知能69コーディング
- grokSpaceXAI: Grok 4.62026-08-1244知能77コーディング
- metaMeta: Muse Spark 1.22026-08-0540知能72コーディング
- qwenQwen: Qwen3.8 Max2026-08-0345知能76コーディング
このファミリーを名前だけで選ぼうとする人は、間違ったモデルを手に入れることになる。その理由は、ただの名前「Bonsai」はモデルではないからだ。それはファミリーであり、今週の時点で、そのファミリーには、スマートグラス上で動作する20億パラメータの視覚言語モデルと、スマートフォン、ノートPC、デスクトップで動作する270億パラメータのモデルが含まれている。1つ目は2026年9月23日に発表された1ビットのBonsai 2B視覚言語モデル——1.7Bの1ビット言語モデルと0.3Bの4ビット視覚エンコーダ、1,024トークンのコンテキストを備え、Bonsai 1.7Bをベースに構築されている。2つ目はBonsai 27Bで、2026年7月14日にApache 2.0の下でリリースされ、Qwen3.6-27Bをベースに、262,000トークンのコンテキストを持ち、5.9 GBの三値ビルドまたは3.9 GBの二値ビルドを選択できる。両者は名前、ベンダー、圧縮思想を共有しているが、それ以外はほとんど何も共有していない。パラメータ数は16倍、コンテキストは256倍、そしてまったく異なる2つのデバイスである。
このページは、そのうちの一方を検索して、もう一方にたどり着いた人のためのものです。
命名の問題を、平易に述べると
PrismML のモデルメニューには現在、Bonsai 2 27B、Bonsai 27B、Bonsai 8B、Bonsai 4B、Bonsai 1.7B、Bonsai Image が並んでいる。グラスに関する発表では、Bonsai 1.7B の系統に加えて 20 億パラメータの視覚言語モデルが追加される。つまり「Bonsai」だけでは、少なくとも 4 つのパラメータクラスと 2 つの世代のいずれかを指し得るのであり、サイズの接尾辞だけがそれを区別する手がかりになる。これは命名への批判ではない — モデルファミリーとしてはごく普通の形だ — が、ファミリー名だけでは、自分が何をダウンロードしているのか何の情報も得られないということを意味している。
有用な区切りは世代ではなく、デバイスクラスです。27B 系のすべては、言語モデルに与えるメモリを 4 GB から 8 GB の間に用意でき、それを費やすことをいとわないという前提に立っています。1.7B 系のすべては、数百メガバイトしかなく、それ以上はないという前提に立っています。その一つの事実が、どのベンチマークよりも先に、このファミリーのどちらの半分があなたに関係するかを決めます。
それぞれが実際に何なのか
• パラメータ — グラスモデルでは1.7Bの1ビットLLMと0.3Bの4ビット視覚エンコーダ、それに対してBonsai 27BではQwen3.6-27Bから派生した27Bクラスのモデル。
• コンテキスト — グラスモデルでは1,024トークン、それに対してBonsai 27Bではフル262,000トークンのコンテキスト。
• 言語モデルの重み — 1ビットの1.7Bが0.43 GBであるのに対し、三値のBonsai 27Bは5.9 GB、その1ビットビルドは3.9 GB。
• 表現 — 両方ともバイナリ {−1, +1} 重みと FP16 グループ単位スケーリングを採用しており、これはこのファミリーが基盤とする 1 ビットのレシピです。Bonsai 27B はさらに、重みあたり実効 1.71 ビットで三値 {−1, 0, +1} ビルドも提供します。
• 対象シリコン — Snapdragon AR1 Gen 1 グラスプラットフォーム上の Qualcomm Hexagon NPU。1 ビットカーネル対応の QNN SDK を通じてコンパイルされ、Bonsai 27B について、MLX 経由の Apple シリコンおよび CUDA 経由の NVIDIA と対比される。
• デコードスループット — グラスモデル向けの 4 GB AR1 Gen 1 テストプラットフォーム上で毎秒 15.36 トークン。一方、1-bit Bonsai 27B では、iPhone 17 Pro で毎秒約 11 トークン、Apple M5 Max で 87、RTX 5090 で 163 です。
それらの数値はすべてベンダー側が示したものであり、2つのデータセットは異なるハードウェア上で、異なるベースラインに対して測定されたものだ。したがって、それらが表しているのは1本の曲線上の2点ではなく、2つの製品である。

Bonsai 27Bが勝利する領域、しかも大差で
コンテキストが第一の論点であり、その差は微妙な話ではありません。262,000トークンのウィンドウなら、コードベース、長い文書、文字起こし、あるいは稼働中のエージェントセッションを余裕をもって収められます。1,024トークンのウィンドウには、短い指示1つと画像1枚しか入りません。ワークロードで1ページより長いものを読む必要があるなら、この2つのうちその作業をそもそもこなせるのは Bonsai 27B だけであり、グラスモデル側でどれほど巧みにプロンプトを工夫してもその差は埋まりません。なぜなら、限界は重みのサイズではなく、キー・バリュー状態のために確保されるメモリにあるからです。
能力は二の次だ。Bonsai 27Bの三値ビルドは、15ベンチマークのthinkingモードスイート全体でフル精度ベースラインの約95%を維持し、1ビットビルドは約90%を維持すると報告されており、最も大きな損失は視覚とツール利用で生じている。これらはベンダー自身のスイートにおけるベンダー公表値であり、それでも、公表されている品質に関する記述が4ビットのQwen 3 1.7Bに対して「比較可能なベンチマーク結果」を達成したというだけの20億パラメータモデルとは、依然として別次元のものだ。グラスモデルは、その開発元によって27Bモデルと比較されていない。その比較は有用ではないからだ。
エコシステムが3つ目です。Bonsai 27BはGGUF、MLX、AWQのパッケージで提供され、ランタイムも文書化されているため、すでに所有しているハードウェアで実行する道があります。グラスモデルはQualcomm NPUツールチェーン内に存在します。

2Bが勝つところ、そしてそれがまさに要点だ
0.43 GB の言語モデルは、5.9 GB のものが収まらない場所に収まる。そしてグラスプラットフォームも、そうした場所の一つだ。これが論点のすべてであり、仕様の対比から受ける印象よりも強い論拠である。なぜなら、当該デバイスにはほかに選択肢がないからだ。4 GB の共有プラットフォームメモリを備えたメガネは、どのビルドでも Bonsai 27B をホストできないし、スマートフォンも、本来の用途の大半を諦めない限り ternary ビルドをホストできない。
あまり注目されないもう一つの利点がある。1ビット表現はこのデバイスクラスにおける妥協ではなく、それを可能にする仕掛けなのだ。PrismML自身の説明では、1ビット経路は同じモデルの4ビット精度とほぼ同等の知能を提供しつつ、メモリ使用量は約4分の1、トークン生成速度は2倍以上になる。すべてのミリワットとすべてのメガバイトが奪い合いになる常時オンのデバイスでは、そのトレードオフこそが製品そのものだ。
つまり、この2つのモデルは競合しているわけではない。2Bは他に動かせる場所がないときに動くものだ。27Bは、あるときに動くものだ。
ティアの境界こそが本当の決断だ
この2つのどちらかを選んでいる人はほとんどいない。現実的なデプロイメントには両方があり、1,024トークンに収まるリクエスト向けのデバイス上の小さな常時稼働モデルと、それ以外のすべてを担うその背後にあるより大きなものだ。その形を受け入れれば、エンジニアリング上の問いは「どのBonsaiか」ではなくなり、「線はどこにあり、誰がそれを強制するのか」になる。
アプリケーションコードで強制すると、その一行は、オンデバイスモデルがコンテキスト長や能力を変えるたびに書き直さなければならない分岐になる——過去3か月の証拠が示すとおり、それはほぼ毎月だ。ルーティングポリシーとして強制すれば、コンテキスト予算と必要な能力に関する一つのルールになり、ローカル層は、クライアント全体に焼き込まれた前提になってしまうのではなく、層のままでいられる。OrcaRouter が運用するのはこの層だ:200 以上のホスト型モデルの手前に置かれた単一のエンドポイントであり、フェイルオーバーと構成で表現されたエスカレーション・ポリシーを備える。どちらの Bonsai もここではルーティングされない——どちらも自分のハードウェアで動かすダウンロード品だ——だから正直に言えば、ルーティング層がカバーするのはローカル層の一つ上であり、ローカルモデルが 1,024 トークンなら、トラフィックの大半が着地するのはその層だということになる。

もし一つだけ選ばなければならないなら
• グラス、ウェアラブル、その他常時オンのデバイス向けに開発しているなら——1ビットのBonsai 2B視覚言語モデルがここでは唯一の選択肢であり、1,024トークンのコンテキストは、抗う対象ではなく前提として設計を組み立てる制約である。
• あなたはスマートフォン向けに構築している — 3.9 GB の 1-bit Bonsai 27B は、iPhone クラスのメモリ予算に収まるこのファミリー最大のモデルであり、グラスモデルでは到底及ばない 262K コンテキストを手に入れられる。
• ノートパソコンやデスクトップ向けにビルドする場合、ternary Bonsai 27Bビルドはこのファミリーの中で品質重視の選択肢であり、1-bitビルドは能力ではなく速度を得るためのものです。
• ハイブリッドを構築しようとしているなら——まずエスカレーションのルールを決め、モデルは後回しにしよう。モデルは差し替えられるが、境界は一度クライアントに入ってしまえば差し替えられない。
注目に値するのは、グラスのリリースを可能にしたNPUの道筋が上位へと広がるかどうかだ。モバイルアクセラレータ上の1ビットカーネルが一般化すれば、1.7B系はさらに大きくなり、スマートフォン上の27Bモデルの妥当性も強まる。それまでは、このファミリーの二つの半分はデバイスクラスによってきれいに分かれたままで、そのことが、共通の名前から想像されるよりも選択を容易にしている。
