Qwen3.5-2B 選定後の実測：iPhone の 4K と 8K は何が違うか

10 モデルの比較を終えた時点で、実用上の選択は明確になりました。Qwen3.5-2B Q4_K_M は、設定したリソース条件と構造化 Agent ルーティング条件をすべて満たした唯一の候補でした。

この結果で「どのモデルを使うか」は決まりました。しかし、「その context window をどう使うべきか」はまだ決まっていませんでした。

最初の iPhone 測定では、Qwen3.5-2B を 4K context から 8K に変更しても、Metal メモリの増加は 52 MiB だけでした。短い Prompt の TTFT もほとんど変わりません。この数字だけを見ると、8K はほぼ無料だと考えたくなります。

実際には違います。8K context の容量を確保することと、8K 近い token を実際に処理することは別の負荷です。モデル選択後、同じ iPhone で追加測定を行い、この差を直接確認しました。

モデル選択後に追加測定した理由

最初の 10 モデル比較では、2 種類の条件を評価しました。

この結果により、Qwen3.5-2B をスマートフォン上のローカル Agent ルーターのデフォルト候補としました。ただし、最初の 4K/8K 実機マトリクスで使用した Prompt は 85 tokens です。そこで測ったのはロード、context 割り当て、短い要求の遅延、メモリ、基本生成であり、window を埋めたときの計算量ではありません。

追加測定の問いは、より限定的です。

選択したモデルに、ほぼ満杯の 4K または 8K Prompt を渡した場合、prefill に何秒かかり、生成速度、メモリ、熱状態はどう変わるのか。

テスト構成

モデルファイルと推論スタックは、最初の比較と同じです。

モデルをロードした後、アプリはモデル自身の tokenizer を使い、system と chat wrapper を含むレンダリング済み Prompt を正確な token 数に調整しました。

• 4K context: Prompt 3,584 tokens
• 8K context: Prompt 7,680 tokens
• 両条件で出力用に 512 tokens を確保
• 全実行で 63 tokens を生成

単純な順序バイアスを抑えるため、4K と 8K の実行順を交互にしました。prefill と生成時間は llama.cpp のネイティブ性能カウンターで測定し、TTFT は Swift の推論呼び出しから最初の空でない stream piece までを別に計測しました。

flowchart LR
    A[選択したモデルをロード] --> B[モデル tokenizer で Prompt を調整]
    B --> C1[4K で 3584-token Prompt]
    B --> C2[8K で 7680-token Prompt]
    C1 --> D[Prefill 63 tokens 生成 メモリと熱状態を記録]
    C2 --> D
    D --> E[容量コストと実使用コストを比較]

実測した 4K と 8K のコスト

表は独立した 3 回の起動における P50 です。サンプル数の少なさを隠さないよう、prefill の min/P50/max も併記しています。

個々の数値より重要なのは、次の 3 点です。

利用可能な容量を確保するコストは小さい

短い Prompt の割り当てテストでは、8K の Metal メモリは 4K より 52 MiB 多いだけでした。今回も生成後の差は 52 MiB で、1821.4 と 1769.4 MiB です。モデルファイルは変わらず、8 GB の iPhone でも現実的なメモリ範囲に収まります。

これは 8K を利用可能にする根拠にはなりますが、毎回埋める根拠にはなりません。

Active context は計算量と待ち時間になる

7,680-token の prefill P50 は 30.583 秒で、3,584-token の 13.375 秒に対して 2.29 倍でした。Prefill throughput も 268.0 から 251.1 tokens/s に低下しました。

一方、Decode は 19.9 と 19.7 tokens/s で、ほとんど変わりません。長い待ち時間は回答が始まる前に発生します。生成が始まった後の token 出力速度はほぼ同じです。

そのため、短い Prompt の TTFT 0.274 秒と、ほぼ満杯の 8K における TTFT 30.602 秒は矛盾しません。同じ context 上限でも、実際に処理する Prompt 長が異なるためです。

より厳しい制約は熱

ほぼ満杯の両条件で熱負荷が発生しました。3,584-token は 3 回中 2 回が Serious で終了し、7,680-token は 3 回すべてが Serious でした。起動間に 30 秒冷却しても、この結果は避けられませんでした。

メモリだけを見ると 8K は簡単に見えます。遅延と熱状態を加えると、context は Runtime が管理すべき資源であり、無制限にテキストを追加する領域ではないことが分かります。

採用する導入ポリシー

端末が持つハード上限と、通常利用のソフト予算を分けます。

1. 物理メモリ 8 GB 以上の端末では 8K context 上限を有効にする。
2. 通常の active Prompt は 2K-4K 程度に保つ。
3. 推論前に、モデル tokenizer でレンダリング済み Prompt 全体を数える。
4. ソフト予算を超えた場合は、現在の指示や関連証拠より先に古い会話履歴を圧縮する。
5. 検索文書と Tool 出力は、すべて連結せず、再順位付けと切り詰めを行う。
6. 約 20-31 秒の prefill に見合う追加証拠が必要なタスクだけ、8K 方向へ拡張する。
7. 出力と復旧指示のため、少なくとも 512 tokens を残す。

flowchart TD
    A[System 履歴 証拠 Tool 出力を構成] --> B[レンダリング後の token 数を確認]
    B --> C{2K-4K の通常予算内か}
    C -->|Yes| D[通常推論]
    C -->|No| E[履歴を圧縮し証拠を再順位付け]
    E --> F{出力領域を残して 8K 未満か}
    F -->|Yes 遅延に見合う| G[長文 context 推論]
    F -->|No| H[タスクを分割または範囲を限定]

重要なのは、永続的な「4K か 8K か」の選択ではありません。8K を利用可能にし、通常は 2K-4K だけを active にするという設計です。

これにより、複雑なタスクではローカル文書、検索証拠、Tool 結果を格納でき、日常的な要求に 30 秒の最初の token 待ち時間を課さずに済みます。

このテストで証明していないこと

今回は、token 数を固定した決定的な合成計算負荷です。選択したモデルが対象端末で既知の token 数を処理するコストを測定しています。次の項目はまだ証明していません。

• 7.5K の自然な複数文書に対する意味精度
• 継続作業時のバッテリー消費
• 20 ターン連続会話の挙動
• 完全な温度回復時間
• 複数アプリのメモリ圧力下における Jetsam
• より少ないメモリの端末で同じ性能が得られること

各条件のサンプルも 3 件だけです。この制限を見える状態にするため、範囲と熱状態の件数をそのまま公開しています。

これらは次の測定項目であり、今回のデータから推測すべきものではありません。

最終判断

追加測定によってモデル選択が逆転することはありませんでした。Qwen3.5-2B Q4_K_M は、この比較で最も強い構造化 Agent 結果と、8K でも 2 GiB 未満の Metal 割り当てを両立しているため、引き続きデフォルトのローカルルーティングモデルです。

ただし、導入方法は明確になりました。

• 8K は 8 GB 端末で利用できる上限です。
• 2K-4K が通常の active Prompt 目標です。
• ほぼ満杯の 8K は明示的な低速経路であり、デフォルトではありません。

今回の追加測定で最も重要なのは、予約容量と実計算の違いです。スマートフォンの context window はメモリだけの話ではありません。最初の token までの遅延、熱、電力、そしてモデルが実行前に読まなければならない不要な情報量にも関係します。

評価設計と Agent の期待ルート 96 件は、「スマートフォンのローカル Agent 向けモデルをどう評価したか」で公開しています。