「スマホで動く」1-bit Bonsai 8Bを実機検証してみた──記事の主張とM3 Macで見えた現実

2026年3月末にPrismML(米カリフォルニア工科大学発)が公開した1-bit量子化LLM「1-bit Bonsai 8B」。「1.15GBでスマホ実運用レベル」という触れ込みがITmedia・GIGAZINEなど多数のメディアで報じられました。本当にそこまで軽量で高性能なのか──Apple M3 / メモリ8GBのMacBookで実機検証し、記事の主張と現実のギャップを定量的に測定しました。

TL;DR (3行まとめ)

• 記事の「1.15GB」はモデル重みだけの数字。実運用には最大3.7GB前後のメモリが必要

• 速度はM3 Macで58〜62 tok/sと実用レベル。公式のiPhone 17 Pro Max値(44 tok/s)を上回る

• 日本語技術Q&Aは実用レベルだが、日本語のビジネス文は誤訳混入で推敲前提

なぜ検証したか

弊社VISKは大阪でAI・システム開発を手がけており、クライアントから「自社でLLMをオンプレ運用したい」「エッジデバイスでAIを動かしたい」という相談が増えています。

こうした中、2026年4月初旬にITmediaが報じた「スマホで動く80億パラメーターLLM──1.15GBで実運用レベルうたう1-bit Bonsai」は、エッジAI案件の可能性を大きく広げうるニュースでした。ただし記事を読み込むと、数字の根拠や実運用時の制約に関する記述が限定的で、そのままクライアントに紹介するには根拠が不足していました。

そこで社内Mac(M3 / 8GB)で実機検証し、**「記事の主張はVISKのクライアントに紹介して大丈夫な内容か」**を定量的に判断することにしました。

検証環境

セットアップは公式のBonsai-demoリポジトリのsetup.shで完了。所要時間は10分程度でした。

検証1:「1.15GBで動く」は本当か?

記事の核心である「メモリ1.15GB」を、コンテキスト長を段階的に変えて実測しました。llama.cppのllama_memory_breakdown_printで内訳まで取得しています。

実測結果

M3のMTL0 GPUの推奨最大ワーキングセットは5726 MiB。-c 32768ではこれを超過してメモリ不足エラーが出ました。

数字の正体

記事の「1.15GB」は**モデル重み1099 MiB(≒1.07GB)**とメタデータ等を含めたディスク上のファイルサイズを指しています。しかし実運用では、

• KVキャッシュ(会話履歴に応じて増える): コンテキスト長に比例して増加

• 計算用バッファ: 約300 MiB固定

が加算されます。実用的なコンテキスト長(8192〜16384)では合計2.5〜3.7GBが必要。記事は間違ってはいませんが、「1.15GBだけあれば動く」と読み取ると現実を誤解します。

重要な気づき

興味深いのは、KVキャッシュがコンテキスト長の約2倍ごとに倍増する綺麗な比例関係を示したこと。1-bit量子化されているのはモデル重みのみで、KVキャッシュは通常通り(128 MiB/1024トークン相当)のメモリを食います。つまり、

1-bit化の恩恵は「モデルを載せる段階」で効き、「長い会話を続ける段階」には効かない

これはエッジデプロイを検討する際の重要な設計制約です。

検証2: 速度はiPhone公式値を上回った

PrismML公式は「iPhone 17 Pro Maxで44 tok/s」を宣伝していますが、M3 Mac 8GBでは一貫して58〜62 tok/sを記録。コンテキスト長にほぼ依存せず安定していました。

人が読む速度(目安5〜10 tok/s相当)の5倍以上出ているため、体感でのストレスはありません。レスポンスは即座に表示され始め、長文でも待たされる感覚はほぼない水準です。

「遅いから使えない」という理由で候補から外す必要はない、というのが実測した結論です。

検証3: 日本語品質は用途で大きく割れた

実運用を想定して、クライアント業務でありがちな2パターンを投げました。

テストA: 日本語ビジネス説明(評価: 低)

プロンプト:

大阪の中小IT企業向けに、AIチャットボットを導入するメリットを3つ、日本語で簡潔に説明してください。

実際の回答(抜粋):

問題点:

• 「時間と手伝う能力を節約」: 直訳調で日本語として不自然

• 「人工的な対応を必要とする」: "manual" を「人工的」と誤訳した疑い

• 「long-term cost reduction」: 英語がそのまま混入

• 1つ目の「効率性向上」が「24/7自動処理」と説明 → 2つ目の「24/7サポート」と重複

• 論理的には3つ挙げたつもりが実質2つ

結論: そのままクライアント向け資料には使えない。必ず人間の推敲が必要。

テストB: Python技術質問(評価: 高)

プロンプト:

Pythonで、リストから重複を取り除く方法を3通り、コード例とともに簡潔に教えてください。

実際の回答(抜粋):

• コードは実行可能、コメントの期待出力も正確

• Python 3.7以降のdict順序保持など技術的正確性高い

• Markdownレンダリングも適切(絵文字まで使う器用さ)

結論: 社内開発者向けのQ&A用途としては十分実用レベル。

なぜこの差が出るのか

1-bit BonsaiのベースはQwen3 8B(中国Alibaba Cloud系)と公式情報で明言されています。英語と中国語(およびコード)に最適化された学習データが中心のため、日本語の自然な語彙選択や文脈理解は量子化の影響を大きく受けたと推測されます。コードやAPI名のように「意味が英語で固定されている」領域は量子化後も精度を保ちやすい、という傾向です。

この結果は第三者ベンチマーク(GitHub: ArmanJR/PrismML-Bonsai-vs-Qwen3.5-Benchmark)の結論──「ファクト・コーディング系では健闘するが、多言語や推論重視のワークロードではQwen3.5を選ぶべき」──とも一致します。

検証できなかったこと(正直に書く)

スマホ(iPhone 15)での動作検証

記事タイトル「スマホで動く」の核心検証は、以下の理由で断念しました。

• 検証端末のiPhone 15(RAM 6GB)のストレージ空きが約4GB未満で、モデル3サイズ(1.7B/4B/8B=計2.5GB)のダウンロードに必要な空き領域を確保できず

• そもそもPrismML公式が検証端末として挙げているのはiPhone 17 Pro Max(RAM 8GB超)

これ自体が示唆的で、「スマホで動く」は事実上「最新フラッグシップiPhoneで動く」が前提と見ておくのが安全です。iPhone 13〜15世代では、8Bモデルの実装可否以前にストレージ面の現実的制約が存在します。

MLX版との速度比較

PrismMLはApple Silicon向けにMLX最適化版を配布しており、「M4 Proで8.4倍高速」を謳っています。llama.cpp版との同条件比較を試みましたが、M3 8GB環境ではMLXランタイムの起動に必要なメモリ(+2〜3GB)を確保できず、公平な計測が不可能でした。

再起動直後でもメモリ使用量が7.4GB/8GBから下がらず、macOS自体の常駐プロセスで M3 8GB はすでに手狭という状況でした。MLX検証したい場合はメモリ16GB以上のMacが必須と言えます。

VISKとして、クライアントに薦められるか?

薦められるケース

✅ オンプレで英語ベースの技術Q&A・コード生成ボットを構築したい

• 社内開発者向けChatOps、コード補完の補助

• メモリ4GB+の小型デバイスで、クラウドAPIに依存せず動かしたい

• データをクラウドに送れない金融・医療系の開発環境

✅ オフライン環境での軽量アシスタント

• 工場、医療現場、出張先など、ネットワーク前提にできない環境

• プライバシー要件が極端に厳しい案件

慎重に検討すべきケース

⚠ 日本語で顧客対応するチャットボット

• 直訳調・英語混入で品質NG。推敲前提なら人件費がかかり、導入メリットが相殺される

• 日本語特化モデル(例:rinna、ELYZA、日本語Qwen、GPT-4o-mini API)の方が現実的

⚠ 長い会話履歴を保持する用途

• KVキャッシュが肥大し、「1.15GB」のスリム感は消える

• 実用コンテキスト(8K〜16K)では合計3〜4GB必要

⚠ 1世代前のスマホでの運用

• iPhone 15以前では動作可否の検証自体が困難

• iPhone 17 Pro Max級、またはPixel 9 Pro級以上の最新端末想定

記事タイトルと現実のギャップ まとめ

記事の主張は嘘ではありませんが、文字通りに受け取ると用途を誤るリスクがあります。特に日本のBtoB現場で「導入すれば社内LLMで日本語チャットボットができる」と期待して入れると、期待と現実のギャップで失敗します。

技術的示唆: 1-bit量子化の本質

今回の検証で見えた1-bit量子化の本質は、「モデルの静的サイズを劇的に削減する技術だが、動的なメモリ消費は削減しない」という点です。

• モデル重み: 1-bit化で16→1.07 GB(約15分の1)

• KVキャッシュ: 1-bit化の対象外、通常通り

• 計算バッファ: こちらも通常通り

つまり「スマホに乗るサイズまで圧縮」は事実だが、「スマホで長時間動く」には別の工夫(KVキャッシュ量子化など)が必要。実際、Turbo1BitプロジェクトはこのKVキャッシュ問題に取り組んでおり、65KコンテキストでBonsai-8Bを10.4GB→3.9GBに圧縮できるようです。

1-bit化は魅力的ですが、実運用設計では量子化だけでなくKVキャッシュ戦略もセットで考える必要があります。

おわりに

1-bit Bonsaiは「研究的ブレイクスルー」として確かに価値あるモデルです。ただしITmediaやGIGAZINEで報じられた数字を額面通りに受け取ると、エッジAI案件の設計を誤る可能性があります。

VISKでは、クライアントのエッジAI案件について「どのハードウェアで、どの言語で、どのコンテキスト長で運用するか」を最初に丁寧に詰めた上で、Bonsaiを含む複数の選択肢(日本語特化モデル、各種量子化済みモデル、クラウドAPI併用)を比較検討しています。

「軽量LLMを社内/エッジで動かしたい」というご相談、お気軽にお寄せください。 今回の検証ログも含めた実データを踏まえて、最適な構成をご提案します。

参考リンク

• PrismML公式: Announcing 1-bit Bonsai

• Hugging Face: prism-ml/Bonsai-8B-gguf

• GitHub: PrismML-Eng/Bonsai-demo(公式デモリポジトリ)

• The Register: PrismML debuts 1-bit LLM

• 第三者ベンチマーク: ArmanJR/PrismML-Bonsai-vs-Qwen3.5-Benchmark

• KVキャッシュ圧縮: jhammant/Turbo1bit

株式会社VISK・技術ブログ | 2026年4月16日公開