この記事のポイント
27Bクラスをスマホ・エッジで動かしたいなら、配布約3.9GBの1-bit Bonsaiが2026年時点でスマホ級メモリ制約の最有力候補
Ternary版は94.6%の品質保持で通常運用の第一候補、1-bit版は89.5%で端末制約が厳しい環境向け
元モデルQwen3.6-27B由来の高性能を継承し、Apache 2.0で商用利用も無料
独立評価でGSM8K数値の再現性に懸念が指摘されており、数理推論・コード生成用途は事前検証必須
AppleがiPhone搭載向けにPrismMLを評価中で、オンデバイスAIの本命候補として業界注視

Microsoft MVP・AIパートナー。LinkX Japan株式会社 代表取締役。東京工業大学大学院にて自然言語処理・金融工学を研究。NHK放送技術研究所でAI・ブロックチェーンの研究開発に従事し、国際学会・ジャーナルでの発表多数。経営情報学会 優秀賞受賞。シンガポールでWeb3企業を創業後、現在は企業向けAI導入・DX推進を支援。
Bonsai 27Bは、Caltech発のスタートアップPrismMLが2026年7月14日に公開した、Qwen3.6-27Bを1-bit/ternary量子化した27B級のオンデバイスAIモデルです。
1-bit版は約3.9 GB・Ternary版は理論5.9 GB/実配布約7.2 GBと、27Bクラスとしては前例のない軽さでスマートフォンやエッジデバイスに載る設計になっており、Apache 2.0ライセンスで商用利用も無料で配布されています。
本記事では、Bonsai 27Bの技術的な位置づけ・2つのバリアントの違い・ベンチマーク性能と正直な限界・実行環境と実測速度・導入手順・想定ユースケース・Appleが評価中との報道の意味・採用判断軸までを、2026年7月時点の公式一次情報とベンチマーク検証で体系的に解説します。
目次
Bonsai 27Bとは?スマホで動く初の27B級オンデバイスモデル
Bonsai 27Bの2つのバリアント:1-bit と ternary(1.58-bit)
Bonsai 27Bの導入方法(llama.cpp・MLX・Together AI)
llama.cpp でのローカル起動(フォーマットとバックエンドで対応が分かれる)
Bonsai 27Bのユースケース:オフラインAI・産業エッジ・機密環境
Bonsai 27Bとは?スマホで動く初の27B級オンデバイスモデル

Bonsai 27B(ボンサイ27B)とは、Caltech(カリフォルニア工科大学)発のスタートアップPrismMLが2026年7月14日に公開した、Qwen3.6-27Bを1-bit/ternary(三値)量子化した27B級のオンデバイスAIモデルです。
PrismMLは同モデルを「27Bクラスとして初めてスマートフォンに載る主要モデル」と位置づけており、Apache 2.0ライセンスで商用利用も含めて無料で配布しています。
2026年現在、on-device LLMの主流は3〜10Bクラスで、27B級モデルはクラウド推論が前提とされてきました。Bonsai 27Bはスマートフォンやエッジデバイスに載る前例のない軽さで、この前提を覆した最初の主要モデルです。
Caltech発の技術背景とPrismMLの位置づけ

PrismMLは2026年3月31日にステルスから公開されたスタートアップで、CEOのBabak Hassibi氏(Caltech教授)を中心とする研究チームが、Caltech内で開発した1-bit量子化技術の独占ライセンスを保有しています。
Khosla Ventures・Cerberus Ventures・Caltechから合計$16.25M(約24億円)のシードラウンドを調達しており、Google・Caltechからは計算資源のグラントも受けています(PrismML公式リリース・HPCwire)。
-
Caltech発の学術基盤
量子化アルゴリズムの数学的基礎はCaltech内で完成させたもので、特許はCaltechが保有しPrismMLに独占ライセンスされている
-
1-bit LLMファミリー戦略
Bonsai 27Bは同社の1-bit LLMファミリーの旗艦モデルで、他に1.7B・4B・8Bの派生モデルもHugging Faceで公開されている
ここでのポイントは、「クラウド前提の27Bモデルを、専用ハードや高性能GPUなしで手元のデバイスで動かせる」という体験が、2026年7月時点で商用ライセンスで解放されたことです。
Bonsai 27Bの2つのバリアント:1-bit と ternary(1.58-bit)

Bonsai 27Bには、1-bit(Binary)とternary(1.58-bit)の2つのバリアントがあります。
どちらもベースはQwen3.6-27B(Alibabaが2026年4月に公開したdense 27Bモデル、Apache 2.0)ですが、量子化方式が違うため、メモリ占有量・品質保持率・推論速度の3軸でトレードオフが生まれます。
以下の表で、2つのバリアントの主要スペックを整理しました。
| 項目 | Bonsai 27B(1-bit) | Ternary Bonsai 27B |
|---|---|---|
| 重みの表現 | {−1, +1} の2値(binary) | {−1, 0, +1} の3値(ternary) |
| 実効ビット数 | 1.125 bits/weight | 約1.71 bits/weight(情報論理値1.58) |
| モデル配布サイズ | GGUF 3.53 GiB/MLX 3.92 GiB | GGUF 6.66 GiB/MLX 7.05 GiB |
| 4Kコンテキストのピークメモリ(text-only/KV cache含む) | 4.8〜5.5 GiB | 7.8〜8.6 GiB |
| 画像入力時のメモリ追加 | +0.9 GiB | +0.9 GiB |
| FP16品質保持率 | 89.5% | 94.6% |
| RTX 5090の推論速度 | 163 tok/s | 134 tok/s |
| M5 Maxの推論速度 | 87 tok/s | 58 tok/s |
この表から見えるのは、**「1-bit版はメモリと速度を最優先」「ternary版は品質を最優先」**という明確な使い分けの構図です。
両バリアントでLLM本体は1-bit/ternary量子化されていますが、画像入力を扱うVision Tower(画像埋め込み層)は4-bit量子化で共通という点も重要です。
マルチモーダル推論(画像+テキスト)で使う場合は、追加で「mmproj.gguf」(約0.9GiB)を読み込む構成になります。
1-bit(Binary)版の仕組み

1-bit版は重みを {−1, +1} の2値だけで表現します。厳密には各重みに1ビット(符号)+128重みごとに共有する16ビットのスケール値を持つhybrid schemeで、実効的には約1.125 bits/weightになります。
この設計により、Qwen3.6-27Bの元サイズ(FP16で約54GB)をGGUF形式で3.53 GiB/MLX 1-bit形式で3.92 GiBまで圧縮しつつ、Math suiteで91.7、Knowledge/STEM(MMLU-Redux・MuSR平均)で73.4という水準を維持しています。
一方で、PrismML公式は「12 GB搭載のiPhone 17 Pro Maxでもアプリに割り当てられるRAMは約6 GB」で、しかもKV cacheとactivationsも同じ枠を共有すると明記しています。
3.9 GBのフットプリントはそのぎりぎりの制約を突破する設計で、8 GB端末はさらに余裕が薄いため、実機での動作確認が前提になります。
Ternary(1.58-bit)版の仕組み

Ternary版は重みを {−1, 0, +1} の3値で表現します。
ternary量子化はMicrosoftのBitNet b1.58で有名になった方式で、情報論理的な最小値は log₂(3) ≒ 1.58 bits/weight ですが、FP16 group-wise scaling(128重みごとの共有スケール値)込みの実効値は約1.71 bits/weight、公式配布は GGUF 6.66 GiB/MLX 7.05 GiB、Hugging Face上の配布ファイルサイズは約7.17 GBと説明されています(PrismML docs・Ternary Bonsai HF)。
「0」が使えるぶん重みの表現力が上がり、FP16の94.6%という高い品質保持率を達成します。
ただし4Kコンテキストでのピークメモリは公式で7.8〜8.6 GiB(KV cache含む・text-only)、画像入力ではさらに+0.9 GiBが加算されるため、16 GB級以上のRAMを積むノートPC・エッジサーバでの運用が安定圏です(8 GB台の環境は短コンテキスト・text-only限定で、実機検証が前提)。
どちらを選ぶか

判断軸はシンプルで、端末メモリと品質要件のどちらを優先するかの1点に集約されます。
-
Ternary版が第一候補
MacBook・デスクトップPC・エッジサーバなど16 GB級以上のRAMが安定圏で、コード生成・エージェント推論・数理タスクで品質を確保したい場合(公式ピークメモリは4Kコンテキストで約7.8〜8.6 GiB、画像入力ではさらに+0.9 GiB。8 GB台の環境は短コンテキスト・text-only限定で実機検証前提)
-
1-bit版が第一候補
iPhone・低スペックエッジデバイス・組込み用途など、Ternaryが載らない環境で、応答遅延を最優先したい場合(公式ピークメモリは4Kコンテキストで約4.8〜5.5 GiB、画像入力で+0.9 GiB)
Together AI経由でクラウドAPIとして使う場合はTernary Bonsai 27Bが提供されており、ローカル導入前の性能比較にも使えます。
Bonsai 27Bのベンチマーク性能と正直な限界

Bonsai 27Bのベンチマーク結果は、PrismMLが公開した15ベンチマークスイート(thinking mode)で評価されており、元モデルQwen3.6-27B(FP16)に対する品質保持率が公表されています。

Bonsai 27B と主要量子化モデルの Intelligence density(モデル誤り率の負対数をモデルサイズで割った独自指標/per GB)比較(出典:PrismML)
PrismMLが公開したこのIntelligence densityチャートは、モデルの誤り率の負対数(negative log of error rate)をモデルサイズで割ったPrismML独自指標で、「1GBあたりに詰め込めた知能の密度」を表します。
1-bit Bonsai 27Bが0.530、Ternary Bonsai 27Bが0.400と、次点のQ2_XXS 2.8bit(0.199)に対して2〜2.6倍以上の密度を示しています。
Gemma-4-31B QAT(0.111)やQwen3.6-27B FP16(0.051)と比べれば、桁違いの差が出ています。
Qwen3.6-27B(FP16)比の性能保持率

以下の表で、Bonsai 27Bの主要ベンチマーク結果を整理しました。
| ベンチマーク | Qwen3.6-27B(FP16) | Ternary Bonsai 27B | Bonsai 27B(1-bit) |
|---|---|---|---|
| 総合品質保持率(15ベンチマーク平均) | 100%(ベースライン) | 94.6% | 89.5% |
| Knowledge/STEM(MMLU-Redux・MuSR 平均) | 83.1 | 77.0 | 73.4 |
| Math suite(GSM8K/MATH-500/AIME25/AIME26 平均) | 95.3 | 93.4 | 91.7 |
※ PrismML公式リリース のカテゴリ別公表値
Ternary版なら元モデルとほぼ遜色ない実務レベルを維持できるということがわかります。特にMath suite(数理推論)で93.4という水準は、多くのビジネス用途で「クラウド版と同じ体験」に十分近い水準と言えます。
1-bit版はQ4_K_XL(4-bit)量子化のQwen3.6-27B(総合品質保持99.9%)には品質で明確に劣ります。
ただし2-bit級との比較では優位で、Qwen3.6-27B IQ2_XXS(2.8bit)の総合72.73点を1-bit Bonsai 76.11点で上回り、モデルサイズあたりの知能密度(Intelligence density)では4-bit級すら上回ります。
独立評価で指摘されたGSM8K数値の再現性懸念

一方で、公表数値をそのまま信じるわけにはいかない側面もあります。
独立評価を実施したbyteiotaは、GSM8K(小学生レベルの数学問題ベンチマーク)で数値の再現性に懸念(irregularity)があると報告しており、公表された品質保持率よりも実測での劣化が大きい可能性を指摘しています。
これは1-bit/ternary量子化モデル全般に見られる傾向で、特に多段推論を要するタスク(数学・複雑な論理展開・長いコード生成)でベンチマーク数値と実測体感がずれることが知られています。
量子化モデルを本番導入する際は「公表ベンチマークを起点にしつつ、自社ワークロードで最低50件の代表タスクをA/B検証する」プロセスを踏むのが実務的です。
Bonsai 27Bも同様で、コード生成・エージェント推論・数理タスクで本番運用を検討するなら、Together AI経由の事前検証を強く推奨します。
元モデルQwen3.6-27Bの位置づ
Bonsai 27Bを評価するには、ベース模型であるQwen3.6-27B(Alibaba、2026年4月22日公開)の性能理解が前提になります。

Qwen3.6-27B(Alibaba・2026年4月公開/Apache 2.0)の紹介画像(Qwen Blog より)
Qwen3.6-27Bはdenseアーキテクチャの27Bモデルながら、MoE(Mixture of Experts)のQwen3.5-397B-A17B(397B総パラメータ/17B active)を主要コーディングベンチマークで上回るという珍しい性能を持ちます。
- SWE-bench Verified: 77.2(vs 397B: 76.2)
- SWE-bench Pro: 53.5(vs 50.9)
- Terminal-Bench 2.0: 59.3(vs 52.5)

Qwen3.6-27B の12ベンチマーク結果(Qwen3.5-397B-A17BやClaude 4.5 Opusとの比較)(出典:QwenLM/Qwen3.6)
Qwen公式が公開したこのベンチマーク図には、Terminal-Bench 2.0(59.3)・SWE-bench Pro(53.5)・SWE-bench Verified(77.2)・SWE-bench Multilingual(71.3)などの主要コーディングベンチマークで、dense 27BのQwen3.6-27BがMoE勢(Qwen3.5-397B-A17B・Qwen3.6-35B-A3B)と互角以上で戦っている様子が示されています。
GPQA Diamond(87.8)・MMMU(82.9)・RealWorldQA(84.1)などの推論・マルチモーダル系も高水準です。
この高性能な27Bを1-bit量子化してもMath suiteで91.7を維持できる(総合平均76.11・FP16比89.5%)という事実が、Bonsai 27Bの実務価値を担保しています。
「小型化した27B」ではなく「圧縮した準フロンティア級モデル」として評価する視点が重要です。
Bonsai 27Bが動く実行環境と実測速度

Bonsai 27Bの最大の売りは「27B級モデルが実際にどのハードウェアで、どれくらいの速度で動くか」という具体性です。
このセクションでは、PrismMLが公表した実測速度と、そこから導けるエッジデバイス射程を整理します。
主要ハードウェア別の推論速度

以下の表で、代表的なハードウェアでのBonsai 27Bの実測速度をまとめました。
| ハードウェア | 1-bit版(tok/s) | Ternary版(tok/s) | 用途イメージ |
|---|---|---|---|
| iPhone 17 Pro Max | 約11 | データなし | モバイルアシスタント・オフライン推論 |
| M5 Max搭載MacBook | 87 | 58 | クリエイター向けローカル推論・開発 |
| NVIDIA RTX 5090 | 163 | 134 | ワークステーション・エッジサーバ |
※ PrismML公式リリース・9to5Mac より
この表から読み取れるのは、「iPhoneでも人間の読解速度に追随できる約11tok/sを確保している」という点です。11tok/sは会話体験としては違和感のない水準で、オンデバイスAIアシスタントとして実用ラインに達しています。
RTX 5090の163tok/sは、社内エッジサーバでチーム全員が同時に使うようなユースケースに十分な速度です。
DSpark drafterによる推論高速化(実験的機能)

Bonsai 27BにはDSpark speculative-decoding drafterが同梱されています。PrismML公式は「Highly experimental」機能と位置づけつつ、CUDA環境のコード生成・推論ワークロードでは約1.8〜2倍のdecode速度を報告しています(Bonsai-demo SPECULATIVE.md)。
Speculative decodingは、小さな「draft model」で複数トークンを先に予測し、大きな「target model」で並列に検証することで実効速度を上げる技術です。
ただし現行実装には以下のトレードオフがあり、常時有効化が最善とは限りません。
-
CUDA限定で高速化:Apple Silicon(Metal)は「後続リリースで改善予定・現時点でMacでは高速化を期待するな」と公式に明記
-
acceptance率はワークロード依存:コード生成・推論では高いが、雑談チャットでは効果が薄い
-
Cross-requestのプロンプトキャッシュ再利用が無効化:マルチターンチャットで初回トークンの応答が遅くなる
-
シングルスロット運用(-np 1固定):同時並列リクエストは処理不可
コード生成・エージェント推論をCUDA GPU上で回すユースケースでは有効化するメリットが大きい一方、マルチターンチャットやMac環境では標準decodeのままの方が総合的に速いこともあります。
エッジデバイスへの射程

「iPhoneで動く」=「同等以上のRAMを積んだARM系デバイスなら基本動く」と読み替えられます。
以下の表で、Bonsai 27B 1-bit版を導入可能なエッジデバイスカテゴリを整理しました。
以下の表はPrismML公式実測ではなく、モデル配布サイズとハードウェアRAMから導いた推定射程です。
実運用ではKV cache・activations・OS/アプリ側の予約RAMも同じ枠を奪うため、各デバイスとも実機検証が前提になります。
| デバイスカテゴリ | RAM目安 | 実用性(要実機検証) |
|---|---|---|
| NVIDIA Jetson Orin Nano(8GB) | 8GB | 1-bit版が載る想定。実行速度はPrismML未公表・実測必須 |
| NVIDIA Jetson AGX Orin(32/64GB) | 32-64GB | Ternary版も余裕を持って載る想定、複数モデル同居も可能 |
| Raspberry Pi 5(8/16GB) | 8-16GB | 起動は可能想定、対話速度は未公表・厳しめの見通し |
| 車載SoC(Qualcomm Snapdragon Ride等) | 8GB以上 | NPUカーネル対応が要件。実装事例待ち |
| 産業用エッジPC(Intel N100+等) | 8GB以上 | CPU推論想定。組込み用途は要ワークロード検証 |
実務的な本命はJetson Orin系+Bonsai 27B 1-bitの組み合わせと想定されますが、公式に速度実測が公表されているのはiPhone 17 Pro Max・M5 Max・RTX 5090の3機種のみです。
従来「エッジで動くLLM」といえばLlama 3.2 3BやPhi-4 miniといった3〜4B級が主流でしたが、Bonsai 27Bは27B級の推論能力をそのまま同じRAM枠に押し込めるため、業務用途で「妥協ではない選択肢」として成立し得ます。
Bonsai 27Bの導入方法(llama.cpp・MLX・Together AI)

Bonsai 27Bには3つの導入ルートが用意されています。ローカルで動かすか、クラウド経由で試すかで選択肢が分かれ、まずはBonsai-demoリポジトリ経由での起動が公式推奨です(フォーマット判定・カーネル差替・fork/mainline切替が自動)。
- Bonsai-demoリポジトリ(推奨): PrismML公式のセットアップスクリプト経由。GGUFファイル形式(Q1_0/Q2_0)とバックエンド(CUDA/Metal/CPU)ごとに、mainlineとforkの適切なバイナリが自動セットアップされる
- llama.cpp(fork版とmainline混在)
1-bit Q1_0はmainline llama.cppで完全対応(CPU/Metal/CUDA/Vulkan)。Ternaryは27Bでも 「Q2_g64」 ファイルならmainline CPU/Metal対応、demo default の 「Q2_0_g128」 とCUDA全般はPrismML-Eng/llama.cpp fork版が必要
- MLX(PrismML-Eng/mlx / mlx-swift fork): MacBook・iPhone・iPad向けApple Silicon最適化(mlx upstream merge は進行中)
- Together AI(クラウドAPI): 導入前の性能検証や小規模利用
llama.cpp でのローカル起動(フォーマットとバックエンドで対応が分かれる)

llama.cppでBonsai 27Bを動かす場合、mainline対応状況はGGUFファイル形式とバックエンドの組合せで決まります。以下の表で整理します。
| モデル・フォーマット | mainline llama.cpp対応 | fork(PrismML-Eng/llama.cpp)が必要な範囲 |
|---|---|---|
| Bonsai 27B(1-bit・「Q1_0」) | ✅ CPU/Metal/CUDA/Vulkan完全対応(upstream merge済) | 不要 |
| Ternary-Bonsai 27B(「Q2_0_g128」・demo default) | ❌ 非対応(fork専用フォーマット) | CPU/Metal/CUDAすべてforkバイナリ必須 |
| Ternary-Bonsai 27B(「Q2_g64」) | ✅ CPU/Metal対応 | CUDAはfork必要 |
| Ternary-Bonsai 1.7B/4B/8B(「Q2_0_g64」) | ✅ CPU/Metal対応(Vulkan進行中) | CUDAはfork必要 |
27B Ternaryを動かす場合、demo default の 「Q2_0_g128」 はfork版バイナリ必須ですが、「Q2_g64」 ファイルを選べばmainline llama.cpp(CPU/Metal)で動きます(CUDAだけfork必要)。
1-bit版は通常のmainline llama.cppビルドで完全対応。GGUF形式のモデルはHugging Face(Bonsai-27B)・Hugging Face(Ternary-Bonsai-27B)から取得できます。
1-bit版(mainline llama.cpp対応):
# mainline llama.cpp でOK
./build/bin/llama-server \
-m Bonsai-27B-Q1_0.gguf \
--host 0.0.0.0 --port 8080 -ngl 99
Ternary 27B版(fork版バイナリまたはBonsai-demo経由):
# PrismML-Eng/llama.cpp fork版のバイナリを使う
./build/bin/llama-server \
-m Ternary-Bonsai-27B-Q2_0.gguf \
--host 0.0.0.0 --port 8080 -ngl 99
起動後、「http://127.0.0.1:8080」 でWeb UIにアクセスできます。
「-ngl 99」 はGPUに全レイヤーをオフロードする指定で、CUDA・Metalで動作します。
バックエンド別の対応進捗(Vulkan:進行中/CUDA:Q2_0でfork必要)はPrismML公式READMEのUpstream Status for Ternaryで最新化されます。
画像入力を扱うマルチモーダル推論では、追加で 「mmproj.gguf」(約0.9GiB)を 「--mmproj」 オプションで指定する必要があります。CLIから直接推論する場合は以下のようになります。
./llama-cli \
-m ./Ternary-Bonsai-27B-gguf/Ternary-Bonsai-27B-Q2_0.gguf \
--mmproj ./Ternary-Bonsai-27B-gguf/mmproj.gguf \
-c 0
Bonsai demoリポジトリでの一括セットアップ

自分でGGUFのダウンロード・パス指定を組む手間を省きたいなら、PrismMLが公開しているBonsai-demoリポジトリのセットアップスクリプトが便利です。
./setup.sh # Ternary-Bonsai-27B を自動ダウンロード
./scripts/start_llama_server.sh # チャット・vision・toolsが localhost:8080 で起動
「setup.sh」 はデフォルトでTernary版を取得します。1-bit版を使いたい場合は環境変数で切り替え可能です。
MLX(Apple Silicon)での起動
![]()
MacBookやiPhoneで動かす場合は、Apple Silicon向けに最適化されたMLXフォーマットのモデルが用意されています(Hugging Face MLX 1bit・MLX 2bit ternary)。
iPhone上でネイティブに動かす場合は、MLX Swift runtimeを組み込んだアプリ経由で実行します。iPhone 17 Pro Maxでの実測は約11 tok/sです。
MLX版はMetal APIを直接叩くため、llama.cpp経由よりもApple Silicon上で高速に動作します。開発中のiOS/macOSアプリに組み込むなら、こちらが実質の第一候補になります。
Together AI経由のクラウドAPI
ローカル導入前に性能を試したい・小規模用途で運用コストを抑えたい場合は、Together AIがTernary Bonsai 27BのマネージドAPIを提供しています。
OpenAI互換のREST APIで呼び出せるため、既存のLLMアプリケーションから最小の変更で切り替え可能です。オンデバイス導入の判断材料として、まずクラウド版で自社ワークロードに耐える性能かを確認するプロセスに使えます。
Bonsai 27Bのユースケース:オフラインAI・産業エッジ・機密環境

Bonsai 27Bの技術的な意味は明確ですが、「これで実際に何ができるか」という業務ユースケースが最も重要です。
このセクションでは、Bonsai 27B(および同等の27B級オンデバイスモデル)が真価を発揮する4つの領域を整理します。
オフグリッド・低通信環境での業務AI

海洋・山間部・海外現場・軍事用途など、クラウドAPIへの接続が保証されない環境では、オンデバイスAIが唯一の選択肢になります。
これまでこの領域では3〜7B級のSLM(小規模言語モデル)が主流でしたが、複雑な要約・多段推論・コード生成では限界がありました。Bonsai 27Bクラスがオフラインで使えるようになったことで、**「クラウドと同等の推論能力を、ネットワーク非依存で提供する」**運用が現実的になります。
- 海洋プラント点検の作業指示生成
- 山間部インフラ保守の技術ドキュメント検索
- 災害時の通信途絶下でも稼働する現場AI
特に24時間365日の可用性が求められる社会インフラ領域では、クラウド依存のリスクをオンデバイスで排除できる価値が大きいです。
機密データを外部送信できない環境

金融・医療・防衛・法務など、規制で機密データの外部送信が制限される業界では、SaaS型LLMサービスの導入が難しいケースが多くあります。
Bonsai 27Bを社内サーバやワークステーションで動かせば、データを一切外部に出さずに27B級推論を業務プロセスに組み込めるようになります。
- 病院内の電子カルテ要約(HIPAA準拠環境)
- 金融機関の内部文書検索・分析
- 法律事務所のクライアント情報分析
従来はローカル運用の場合、Ollama+Llama 3.3 70Bのように数十GB級のVRAM・大容量Unified Memory・複数GPUを要求する構成が前提でしたが、Bonsai 27Bなら消費電力・コスト・設置スペースが1桁小さいハードで同等クラスの推論品質を実現できます。
産業エッジ・工場現場での実時間推論

Jetson Orin Nano/AGX Orinのような産業エッジデバイスを工場のPLC近傍に設置し、Bonsai 27Bで異常検知・作業指示生成・多言語対応マニュアル検索を実行するユースケースが現実的になります。
エッジAIの従来の課題は「推論品質と応答速度のトレードオフ」でしたが、Bonsai 27Bはこの両方を1つの27B級モデルで解決できる点で従来と一線を画します。
具体シナリオは以下のとおりです。
- 製造ラインの外国人労働者向けリアルタイム多言語通訳
- 熟練工の暗黙知を対話形式で若手作業員に伝達
- 品質検査結果と過去事例を照合した原因分析
モバイルアプリのオフライン機能

iPhoneで11 tok/sという実測速度は、モバイルアプリのオフライン機能として実用ラインに達しています。
- 出張中の飛行機内・地下鉄・海外ローミング環境での資料要約
- 通信状態の悪い出張先でのメール下書き・翻訳
- プライバシー配慮が必要な個人ノート・日記アプリ
「クラウドLLMに送りたくないが手元では処理したい」というプライバシー配慮ニーズと、Bonsai 27Bのオンデバイス性能が噛み合う領域です。
AppleがPrismMLを搭載?オンデバイスAIの転換点

Bonsai 27Bの技術的意義に加えて、業界インパクトの面でも重要なニュースがあります。
AppleがPrismMLをiPhone搭載向けに評価中と報じられており(cryptobriefing、MacDailyNews、MacRumors)、初期段階の面談・技術評価フェーズにあるとの報道がBonsai 27B発表と同時に流れています。
契約・提携そのものは公式には発表されていません。
AppleがPrismMLを評価中との報道の意味

Appleは2026年6月のWWDCで、Apple IntelligenceのアーキテクチャをGoogle Geminiと共同開発した新設計に刷新すると発表しました(MacRumors)。
同時に、on-device model「AFM 3 Core(3B dense)」「AFM 3 Core Advanced(20B sparse・1〜4Bアクティブ)」を第三世代として公開しています(Apple Machine Learning Research)。
このタイミングでPrismMLとの面談が報じられたことは、AppleがAFM 3世代を超える「フロンティア級モデルのiPhone搭載」を模索している可能性として報道されています(Apple公式コメントはなく、確定情報ではありません)。
- Apple自社のApple IntelligenceはAFM 3 Core(3B dense)とAFM 3 Core Advanced(20B sparse・1〜4Bアクティブ)の2段構成
- Bonsai 27Bクラスを追加すれば、Siriのオンデバイス知能を一気に押し上げられる可能性
- PrismMLの1-bit技術は他ベンダーのモデルにも適用できる汎用圧縮方式で、Apple独自モデルの圧縮にも転用しうる
iPhone 17 Proに27B級モデルが載る未来が現実的な射程に入ってきたこと、これが2026年7月時点でBonsai 27Bが業界に与える最大のインパクトです。
他社オンデバイスモデルとの位置づけ

以下の表で、Bonsai 27Bと主要オンデバイスモデルの位置づけを整理しました。
| モデル | ベンダー | パラメータ | RAM占有 | 特徴 |
|---|---|---|---|---|
| Bonsai 27B(1-bit) | PrismML | 27B → 圧縮 | 配布約3.9GB/ピーク4.8-5.5 GiB | 27B級の推論品質をスマホに載せる |
| Bonsai 27B(Ternary) | PrismML | 27B → 圧縮 | 配布約7.2GB/ピーク7.8-8.6 GiB | 94.6%品質保持で本命推奨 |
| Apple AFM 3 Core | Apple | 3B(dense) | 数GB | iOS/macOSネイティブ統合 |
| Apple AFM 3 Core Advanced | Apple | 20B sparse(1〜4Bアクティブ) | 数GB以上 | On-Device MoE、より高度な推論向け |
| Google Gemma 3(270M〜) | 270M〜 | 1GB以下 | 超軽量、Chrome/Android統合 | |
| Google Gemma 4 E4B | 4B | 5GB | 128K contextに対応 | |
| Microsoft Phi-4 mini | Microsoft | 3.8B | 数GB | Windows/Android汎用 |
| BitNet b1.58 2B4T | Microsoft | 2B | 1GB以下 | ternary量子化の元祖 |
※ 各社公表値。詳細は各ベンダーの公式ドキュメントを参照
この比較から見えるのは、「Bonsaiが27B級のフロンティアクラスモデルをスマホ級RAMに押し込む初の主要な実用例になった」という点です。
他社モデルは元々3〜4B程度のdense modelで、絶対的な推論能力の天井が異なります。
1-bit/ternary量子化は先行技術がありますが、Microsoft BitNet b1.58の公開モデルは2B規模、PrismML従来のBonsaiファミリーも8Bまでで、2026年6月時点では8B以下に留まっていました。Bonsai 27Bはこの壁を突破した最初の27Bクラスモデルです。
Apple自社のAFM 3世代モデルは、Bonsaiとはまったく別のアプローチでオンデバイス化を実現しています。以下はApple公式が公開したOn-Device MoEの動作モデルです。

Apple 第3世代 Foundation Models の On-Device MoE 構成(DRAM静的重み+NAND展開エキスパート)(出典:Apple Machine Learning Research)
Appleの構成では、Attention Blockと共通のFFN Block(Static weights)はDRAM常駐、それ以外のFFNエキスパート群はNANDフラッシュに置き、User Inputに応じて必要な「Selected Experts」だけ動的にDRAMへ引き上げます。Bonsai 27Bが「27Bの重みを1-bit/ternary圧縮でDRAMに全部載せる」アプローチであるのに対し、Appleは「MoEで必要な専門家だけ都度DRAMに引き上げる」アプローチを取っており、設計思想が対照的です。
両者は競合というより補完関係にあり、将来的にAppleがBonsai的な量子化技術をMoEエキスパート側に組み合わせれば、DRAM常駐重みも縮められる可能性があります。
「オンデバイスがクラウドを喰う」時代の始点

2026年7月のBonsai 27B公開は、業界的には**「オンデバイス推論の能力天井が、実用的な業務要件を満たすラインに到達した」**シグナルと見るべきです。
これまで多くの企業でオンデバイスAIは「バックアップ・オフライン時の縮退運用」の位置づけでしたが、27B級が手元で動く前提でシステム設計を始めると、**「そもそもクラウドに送る必要があるか」**という問い直しが起きます。
AI総合研究所の支援現場でも、2026年後半から「まずオンデバイスで完結できないかを検討し、性能要件で足りない部分だけクラウドに委譲する」という設計方針が増えてきています。Bonsai 27Bはこの流れを加速させる触媒になります。
Bonsai 27Bを採用すべきケース・避けるべきケース

ここまでBonsai 27Bの技術的な優位性を整理してきましたが、実際の業務導入判断では「自社のケースに本当に合うか」を冷静に見極める必要があります。
このセクションでは、AI総合研究所のSIer視点から、Bonsai 27Bを第一候補にすべきケースと、避けたほうがよいケースを整理します。
Bonsai 27Bを第一候補にすべきケース

以下のいずれかに該当する場合、Bonsai 27B(特にternary版)は現時点で最有力の選択肢です。
-
機密データを外部送信できない業種で27B級推論が必要
医療・金融・防衛・法務など、クラウドLLMを規制上使えないが、3〜7B級SLMでは能力が足りない用途
-
オフグリッド・低通信環境で高品質AIを動かしたい
海洋プラント・山間部インフラ・災害時の通信途絶下・軍事用途など、クラウド接続が保証されない現場
-
エッジデバイスに27B級モデルを載せて実時間処理したい
Jetson Orin搭載のロボット・産業機器・車載システムで、クラウド往復のレイテンシを排除したい用途
-
iOS/macOSアプリのオフライン機能を強化したい
プライバシー配慮ニーズと高品質推論を両立させたい個人向け・エンタープライズ向けアプリ
Bonsai 27Bを避けるべきケース

一方で、以下のケースでは他の選択肢のほうが合理的です。
-
数理推論・複雑なコード生成が中心の用途
GSM8K数値の再現性懸念が指摘されており、多段推論・数学タスクではFP16の元モデルやより大きなクラウドモデル(Claude Opus 4.8・GPT-5.6等)が適する場合が多い
-
クラウドインフラが既に整備されていて外部送信に制約がない
規制上の制約もなくクラウドAPIを自由に使える環境なら、GPT-5.6 API・Claude API等のフロンティアモデルのほうが総合的な体験は上
-
モデルの精度検証・チューニングに時間をかけられない
量子化モデル全般の特性として、公表ベンチマークと実測体感のズレが起きうる。事前検証プロセスを組めないなら、実績のあるフルパラメータのモデルが安全
-
推論以外の学習・ファインチューニングが必要
Bonsai 27Bは推論特化の量子化モデル。追加学習が必要な用途では、Qwen3.6-27B(FP16版)を知識蒸留で自社データに適応させるルートが現実的
導入前に検証すべき3つの観点

Bonsai 27Bを本番採用する前に、以下の3点で自社ワークロードとの相性を検証することを推奨します。
-
代表タスクの品質実測
50件以上の自社代表タスクで、Together AI経由のTernary版と自社利用中のクラウドLLMを並列実行し、品質差を数値化する
-
推論速度の実機検証
本番想定のハードウェア(Jetson Orin・MacBook・iPhone等)で実測tok/sを測り、業務要件を満たすか確認する
-
マルチモーダル運用の必要性
画像入力を使うなら「mmproj.gguf」(+0.9GiB)が必要。RAM budget再計算とVision Tower精度の別途評価が要る
これらの検証を経ずに公表ベンチマークだけで導入判断をすると、本番リリース後に「思ったほど品質が出ない」「メモリが足りない」といった落とし穴に嵌ります。
Bonsai 27Bと並行して、一般業務プロセスもAgent化するなら
Bonsai 27Bが刺さる用途は明確で、"クラウドAPIに送れない機密データ"、"通信が保証されないオフグリッド環境"、"エッジデバイスでのリアルタイム推論"、"モバイルアプリのオフライン機能"の4領域です。
一方で、記事末尾で整理した「避けるべきケース」の1つ「クラウドインフラが既に整備されていて外部送信に制約がない」領域や、経費精算・請求書処理・稟議書レビュー・保全帳票入力といった業務プロセス側は、Bonsai 27B on-deviceではなくAzureテナント内で動く業務Agent実行基盤で受けるのが現実的です。
このレイヤーを担うのが、自社Azureテナント内で動くエンタープライズAIエージェント基盤です。
AI総合研究所のAI Agent Hubは、AI-OCR Agent・自動入力Agent・フロー判定Agentなど9種類の業務特化Agentを、SAP Concur・freee会計・Dynamics 365・Salesforce・勘定奉行クラウドといった基幹システムと繋げ、Microsoft Teamsから呼び出せる形でパッケージ化しています。機密領域はBonsai 27B on-device、一般業務プロセスはAgent Hubというハイブリッド運用で、規制と業務効率化を両立できます。
AI総合研究所の専任チームが、オンデバイスAI(Bonsai 27B等)と、クラウド側業務Agent実行基盤の使い分け設計から運用まで伴走支援します。AI Agent HubのLPで、Bonsai 27Bが担う機密・オフライン領域とは別レイヤーの、一般業務プロセスへのAI Agent組み込みの全体像をご確認ください。
オンデバイス×業務Agentハイブリッド運用
機密領域と一般業務を別レイヤーで運用
Bonsai 27Bは機密・オフグリッド・エッジ・モバイルの4領域で真価を発揮しますが、一般的な社内業務プロセス(経費精算・請求書処理・稟議書レビュー・基幹入力)はAzureテナント内で動く業務Agent実行基盤で受けるのが現実的です。AI Agent HubのLPで、Bonsai 27Bと並行運用できる業務プロセスAgent実行基盤の全体像をご確認ください。
まとめ
本記事では、Bonsai 27B(PrismML)の技術的位置づけ・2つの量子化バリアント・ベンチマーク性能と限界・実行環境・導入方法・ユースケース・AppleがPrismMLを評価中との報道・採用判断軸まで、2026年7月時点の公式一次情報で解説しました。
要点を整理すると、以下のとおりです。
- 技術的意義: 27Bクラスをスマホ・エッジで動かせる初の主要モデル。配布サイズは1-bit版約3.9GB/Ternary版約7.2GB、4Kコンテキストのピークメモリは1-bit 4.8〜5.5 GiB/Ternary 7.8〜8.6 GiBで、Apache 2.0で商用利用も無料
- 性能と限界: Ternary版はFP16の94.6%品質保持で通常運用の第一候補、1-bit版は89.5%だが端末制約が厳しい環境向け。GSM8K数値の再現性は事前検証が必須
- 実行環境: iPhone 17 Pro Max 11 tok/s、M5 Max 87 tok/s、RTX 5090 163 tok/s。Jetson Orin系がエッジデバイスの本命
- ユースケース: オフグリッド業務AI・機密環境・産業エッジ・モバイルオフライン機能の4領域で真価を発揮
- 業界インパクト: AppleがPrismMLを評価中で、iPhone搭載検討という報道あり。オンデバイスAIの本命候補として業界注視
- 採用判断: 機密・オフライン・エッジ用途では第一候補、数理推論中心やクラウド自由環境では他選択肢を検討
Bonsai 27Bは「27Bをスマホに載せた」という技術的マイルストーンにとどまらず、企業のAIシステム設計思想を「クラウド前提」から「オンデバイスも含めた最適配置」へ移行させる触媒になり得るモデルです。
自社のユースケースがオンデバイスに向いているかを判断するために、まずTogether AI経由のTernary版で自社ワークロードを試すところから始めるのが現実的な第一歩です。













