「iPhone でローカル LLM を動かして、画像もテキストもデバイスから外に出さない、最強のプライバシー設計の AI アプリを作る」 ─ 2026年Q1の私の最初の設計目標でした。
恋愛メッセージ分析アプリ Relora で、llama.cpp + Metal GPU バックエンドで 0.8B〜4B クラスのローカルモデルを 7つ実機検証 した結果、「現時点ではクラウド LLM に勝てない」 という結論に達してプロジェクトを Amazon Bedrock 経由のクラウド構成に切り替えました。
本記事は、その判断の 定量的な根拠 を残すものです。同じく iPhone 上で LLM を動かしたい個人開発者が、同じ罠を踏まずに済むように、速度・メモリ・品質の3軸の実測値を公開します。
この記事で分かること
- iPhone 16 Pro Max (A18 Pro / 8GB) での Llama 3.2 / Gemma 3 / Gemma 4 / Qwen3.5 の実速度
- llama.cpp Metal バックエンドのモデル別メモリ消費（GGUF / KV+RS / 計算バッファの内訳）
- 「速度は十分でも品質が足りない」という典型的失敗パターン
- 広告 WebView との同居でクラッシュする「2GB の壁」
- LiteRT-LM が llama.cpp の約3倍速いという他ランタイムとの比較
検証環境
| 項目 | 値 |
|---|---|
| デバイス | iPhone 16 Pro Max (A18 Pro / 8GB RAM、GPU 5,461 MiB) |
| OS | iOS 26.x |
| ランタイム | llama.cpp（Swift Package 形式） |
| バックエンド | Metal GPU |
| 量子化 | Q4_K_M（4-bit、混合精度） |
| コンテキスト長 | 4,096 tokens |
| タスク | 日本語チャットスクリーンショット分析（OCR済テキスト → 構造化 JSON 出力） |
| 入力 | 同一スクショ（「返信が遅い」シチュエーション） |
| 計測日 | 2026-04-07 |
注意: 各モデル1回ずつの計測 で、初回はモデルロード時間を含みます。統計的精度よりも、「個人開発として採用可否を判断する粒度」を優先しています。
実測データ（7モデル）
| モデル | パラメータ | GGUF | 所要時間 | 入力 tok | 出力 tok | 出力速度 (tok/s) | 品質スコア |
|---|---|---|---|---|---|---|---|
| Llama 3.2 1B | 1B | ~600MB | 7.2s | 719 | 250 | ~34.7 | 8/10 |
| Gemma 3 1B | 1B | ~600MB | 9.1s | 732 | 241 | ~26.5 | 5/10 |
| Qwen3.5 0.8B | 0.8B | ~560MB | 18.4s | 700 | 538 | ~29.2 | 5/10 |
| Gemma 4 E2B | 2.3B(実効) | ~3.1GB | 19.2s | 723 | 335 | ~17.4 | 3/10 |
| Llama 3.2 3B | 3B | ~1.8GB | 23.2s | 688 | 355 | ~15.3 | 5/10 |
| Qwen3.5 2B | 2B | ~1.3GB | 29.3s | 673 | 492 | ~16.8 | 3/10 |
| Qwen3.5 4B | 4B | ~2.5GB | 37.5s | 740 | 317 | ~8.5 | 3/10 |
出力速度は 出力tok / 所要時間 の概算値（OCR・パース時間込みのため、純粋なデコード速度はやや高い）。品質スコアは同一入力に対する温度スコア出力の妥当性を 1〜10 で主観評価。
速度の知見
- 最速は Llama 3.2 1B の 7.2 秒。他モデルと比べて圧倒的に速い
- Qwen3.5 は全サイズで遅い。0.8B でも 18.4 秒。Qwen3.5 の Gated DeltaNet（SSM/Attention ハイブリッド） が llama.cpp の Metal 実装と相性が悪い可能性
- Qwen3.5 0.8B は出力トークン数が多い（538 tok）。他モデル（250〜355 tok）と比べて冗長で、所要時間を引き伸ばしている
品質の知見
- 同じ入力に対して温度スコア出力が 3〜8 と大きくばらつく
- Llama 3.2 1B が 8/10 と高めに出る傾向。ただし 各モデル1回ずつの計測 で統計的信頼性は低く、要追試
- Qwen3.5 系と Gemma 4 E2B は 3/10。サイズが大きい方が品質が高い、とは単純に言えない
メモリの内訳と「2GB の壁」
iPhone 16 Pro Max（8GB / GPU 5,461 MiB）での実測値です。
| モデル | GGUF | GPU確保 | KV+RS | 計算バッファ | 合計(推定) | 広告併用 |
|---|---|---|---|---|---|---|
| Llama 3.2 1B | 600MB | ~600 MiB | ~224 MiB | ~64 MiB | ~900 MiB | 可 |
| Gemma 3 1B | 600MB | ~600 MiB | ~224 MiB | ~64 MiB | ~900 MiB | 可 |
| Qwen3.5 0.8B | 560MB | ~560 MiB | ~178 MiB | ~128 MiB | ~870 MiB | 可 |
| Qwen3.5 2B | 1.3GB | ~1,211 MiB | ~67 MiB | ~256 MiB | ~1,530 MiB | 可 |
| Llama 3.2 3B | 1.8GB | ~1,918 MiB | ~448 MiB | ~256 MiB | ~2,620 MiB | 可（やや余裕） |
| Qwen3.5 4B | 2.5GB | ~2,604 MiB | ~178 MiB | ~490 MiB | ~3,270 MiB | 不可 |
| Gemma 4 E2B | 3.1GB | ~3,100 MiB | ~200 MiB | ~490 MiB | ~3,790 MiB | 不可 |
個人開発で意外に効く「広告 WebView との同居」
無料アプリでアドモブ等の広告を使う場合、広告 WebView は閉じた後も数百 MB のメモリを保持 します。GPU・WebContent・Networking の3プロセスに分かれていて、純粋な常駐分だけでも体感 300〜500MB は持っていかれます。
実測ベースの判定基準：
- GGUF サイズ ≤ 2GB → 広告表示と同居可
- GGUF サイズ > 2GB → 広告と同居で OOM クラッシュ
つまり Qwen3.5 4B や Gemma 4 E2B は性能云々の前に 「無料アプリの収益モデルと両立しない」 という別軸の制約に当たります。
品質スコアが意味すること
品質スコアの内訳は、温度スコア（1-10 の数値出力）の妥当性、JSON スキーマ追従、返信候補3パターンの距離感の出し分け、を統合した主観評価です。詳細は ローカルLLMの限界に挑んで挫折し、クラウドAIに辿り着くまで に実出力サンプルを掲載しています。
特徴的だった2つの失敗パターンを挙げると：
- 3B 帯（Llama 3.2 3B）の「ビジネスメール化」: スコア 5/10。返信候補が「お元気にしていらっしゃいますか」「返信お待ちしております」のような、誰が誰に送っても通用する定型文に収束する。ニュアンス調整 (4) が出ない
- 1-2B 帯（Gemma 3 1B / Qwen3.5 2B）の「タスク取り違え」: スコア 3-5/10。「ユーザーが相手に送るメッセージ」を生成するべきところ、ユーザー本人を慰めるテキスト を返す。指示追従 (3) が崩れる
サイズが大きい方が品質が高いとは限らない、という結果はこの2つのパターンが効いています。
なぜ品質に差がつくか（仮説）
恋愛チャット分析は表面的にはテキスト生成ですが、内部的には次のような複合タスクです。
- 会話の文脈理解: 「2回会った」「3日返信なし」をどの軽重で扱うか
- 常識的な人間関係知識: マッチングアプリの間柄なら踏み込みすぎは NG
- 指示追従: JSON スキーマ通りに3パターン返す
- ニュアンス調整: 「攻め」「守り」「様子見」の距離感を出し分ける
- 相手の文体への追従: カジュアル/丁寧の合わせ込み
1B-4B クラスは (3) の指示追従と (4) のニュアンス調整で破綻しやすい。JSON は出るが中身が定型文、または JSON が壊れる ─ どちらかが必ず起きます。
ランタイム側の伸びしろ: LiteRT-LM の存在
注目すべきは、Google の LiteRT-LM では同じ Gemma 4 E2B が decode 56.5 tok/s を記録していることです。llama.cpp の Metal 実装と比較して 約3倍速い。
ということは、品質を諦めずに速度を取りたい場合、ランタイム側の最適化余地が大きく残っています。Swift API が安定したら再評価する価値があります（2026年Q1時点では Swift Package が出ていない）。
App Store のアプリサイズ上限という伏兵
Llama 3.2 3B（1.8GB）レベルでもバンドルすると次の問題があります。
- App Store 配信の 4GB 上限: アプリ本体 + リソース + 各国語ローカリゼーション含めて 4GB を超えるとアップロード不可
- 200MB を超えるとセルラーダウンロード不可（ユーザー設定で許可可能）
- TestFlight でも本番でも 4GB 制限は同じ
つまり 3B 以上をバンドルすると、「Wi-Fi に接続してください」という壁 が DL ユーザーの前に立ちます。On-Demand Resources で起動後に DL する手もありますが、初回起動が「2GB ダウンロード中」になり離脱率が爆発します。
ローカル LLM が「勝てる」タスクと「負ける」タスク
検証を経て、私の中で線引きは次のようになりました。
| タスク | ローカル | クラウド |
|---|---|---|
| キーワード抽出 | ◎ | ○ |
| 感情ラベル分類（5クラス程度） | ○ | ◎ |
| 短文要約（1-2文） | △ | ◎ |
| 構造化生成（複数フィールドJSON） | ✕ | ◎ |
| ニュアンス調整が必要な生成 | ✕✕ | ◎ |
| 多言語対応（9言語） | ✕ | ◎ |
小さな分類タスクであればローカルで完結する価値はある。でも「ユーザーに見せる文章を作る」系は、現時点ではクラウドに勝てません。Reloraはそれが コア機能だった のでクラウドに切り替えました。
将来 Apple Intelligence や Foundation Models でデバイス上で 7B〜10B クラスを安定稼働させる時代が来れば再挑戦します（その日はそう遠くないと信じています）。
それでも残る「ローカルでやるべきこと」
クラウドに切り替えてもなお、Relora のローカル処理は健在です。
-
OCR: Apple Vision の
VNRecognizeTextRequestでローカル完結。画像はサーバーに一切送らない - 構造化前処理: チャットバブルの送信者判定（boundingBox の minX 座標）はローカル
- 多言語フィルタリング・メタデータ除去: タイムスタンプや既読表示の除去はクライアント側で完結
「画像はローカル、テキストだけクラウド」というハイブリッドは、ユーザーへのプライバシー説明としても綺麗です。
まとめ
- 0.8B〜4B クラスのローカル LLM は 速度は実用域、品質はまだ不足
- 最速は Llama 3.2 1B（7.2秒、品質 8/10）。バランスは Gemma 3 1B（9秒、5/10）
- 構造化生成・ニュアンス調整・多言語が必要なタスクはクラウド一択（2026年Q1時点）
- アプリサイズ・モバイル DL 制限・広告 WebView との同居 という非技術的な壁も大きい
- ランタイム側の最適化余地は大きい（LiteRT-LM が llama.cpp の3倍速い前例）
- ローカル LLM は「分類・抽出」など 小さなタスクの軽量化 に向ける
関連記事:
- ローカルOCR + クラウドLLMのハイブリッドアーキテクチャ
- Amazon Bedrock Converse APIでマルチモデル切替
- ローカルLLMの限界に挑んで挫折し、クラウドAIに辿り着くまで
Relora（App Store）: https://apps.apple.com/app/relora/id6762029713