「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 は「分類・抽出」など 小さなタスクの軽量化 に向ける

関連記事:

Relora（App Store）: https://apps.apple.com/app/relora/id6762029713