スマートフォンのローカル Agent 向けモデルをどう評価したか

このテストは、モデルの順位表を作るために始めたものではありません。

最初にあったのは、もっと具体的な問題でした。スマートフォン上のローカル Agent には、デフォルトで使うルーティングモデルが 1 つ必要です。そのモデルには会話だけでなく、短時間で要求を理解し、適切な機能を選び、実行パラメータを取り出し、情報が足りなければ質問して止まることが求められます。同時に、8K context を有効にしてもメモリや発熱が現実的な範囲に収まらなければなりません。

検証したかったのは、次の問いです。

二言語・構造化・オンデバイスという現在の Agent ワークフローで、現実的なリソース消費のまま、ルーティングと実行パラメータを最も安定して生成できるモデルはどれか。

これは重要な限定です。一般知能、文章力、数学、知識問題の順位を測っているわけではありません。製品開発上の選択に答えるテストです。

Agent の仕事を先に分解する

「明日の朝 7 時に起こして」という依頼を実行するまでに、Agent は少なくとも 2 段階の判断をします。

まず、現在利用できる機能から正しい Skill を選びます。アラーム、カレンダー、メール、メモリなどです。次に Skill 内の Action を選び、既知のパラメータと不足しているパラメータを整理し、実行するか、計画するか、確認質問を返すかを決めます。

flowchart LR
    A[ユーザーの依頼] --> B[候補 Skill の検索]
    B --> C[Stage 1: Skill 選択]
    C --> D[Stage 2: Action とパラメータ]
    D --> E{情報は十分か}
    E -->|十分| F[実行または計画]
    E -->|不足| G[構造化された確認]
    F --> H[Swift Runtime の検証]
    G --> H

もっともらしい文章を書かせ、雰囲気で採点することはしません。評価器は Skill、Action、Mode、既知 Slots、不足 Slots、目標を明示した構造を要求します。その後、Swift Runtime が候補範囲と現在の Schema に適合しているかを決定的なルールで確認します。

システム機能を扱う Agent にとって、「だいたい理解した」は実行保証になりません。Action の選択ミスと必須パラメータの欠落は別の失敗であり、両方を見えるようにする必要があります。

96 件の構成

モデル比較には v3-96-staged-skill-action データセットを使っています。

core はアラーム作成、予定確認、メール下書きなど、よくある表現を扱います。challenge では、似た Skill の混在、必須情報の不足、複数機能にまたがる計画、曖昧な言い方を加えています。

短い入力も意図的に残しました。スマートフォンへの指示は数語で終わることが珍しくありません。テスト問題のように整った文章でしか安定しないモデルは、実際の製品では使いにくいからです。

各ケースには期待する Skill、Action、Mode と構造上の制約があります。公開精度の分母は常に 96 件です。Parse に失敗したケースを精度計算から外すことはありません。

96 件のテストケースと期待結果

以下の期待結果は最終的な自然言語回答ではなく、モデルが Runtime に渡すルーティング契約です。各ケースで Skill、Action、Mode を個別に照合します。追加条件は、不足 Slots の空/非空、または計画必須を表します。

3 つの具体的な採点例

• 情報が完全：Set an alarm for 7 AM tomorrow.

builtin.alarm.manage → create_alarm、Mode は act、missing_slots は空であること。

• 情報が不足：Create an email draft for me.

builtin.mail.draft → create_draft、Mode は clarify、missing_slots は空でないこと。メール Schema は宛先、件名、本文を必須とします。

• 複数ステップ：First inspect tomorrow's calendar, then create reminders for unresolved items.

builtin.task.plan_recover → orchestrate、Mode は act、requires_plan = true。

現在の v3 には制限もあります。不足 Slots は空か非空かだけを採点し、すべての不足フィールド名を正しく列挙したかは個別採点していません。正確な Slot 名と値は次版の契約テストに追加します。

Core：48 件の基本ケース

Challenge：48 件の境界ケース

何を採点するか

弱点を別の長所で隠せる単一の総合点は使いません。

Parse が高くても意味が正しいとは限りません。合法な JSON を安定して出しながら、Skill を安定して間違えるモデルもあります。逆に、内容は理解しているようでも、出力形式が崩れて Runtime が使えない場合もあります。

実行ルーターとして重要なのは Skill、Action、Mode、不足 Slots の挙動です。Skill は強くても Action が弱いモデルは、第 1 段階の候補絞り込みには使えても、実行パラメータを直接任せるべきではありません。

公平とは、全モデルに同じ文字列を渡すことではない

10 モデルはすべて GGUF Q4_K_M、同じ evaluator、同じデータセット、同じ 4K/8K 設定、固定デコード条件で実行しました。

temperature = 0
top_p = 1
top_k = 1
seed = 42
candidate_limit = 3

ただし、全モデルに同じ ChatML 文字列を無理に渡してはいません。Llama 3 は header tokens、SmolLM3 は extended thinking を無効化し、LFM2.5 は必須の start-of-text token を使います。タスク、情報、出力契約は同じまま、外側のテンプレートだけをモデル本来の形式に合わせています。

私たちにとって公平な比較とは、仕事とルールを揃えたうえで、誤った入力形式による不利益を意図的に作らないことです。

各重みについて、提供元、リポジトリ、commit、ファイル名、バイト数、SHA-256、ライセンス、Prompt Profile も記録します。モデル名だけでは再現できません。同名でも変換や量子化ファイルが違えば、挙動が変わる可能性があります。

能力評価と実機測定を分ける理由

ここは特に誤解されやすい点です。

96 件の能力評価は、同じモデルファイルをデスクトップの Metal evaluator で実行します。大量実行、全 Raw Output の保存、安定した条件での再比較がしやすいためです。

リソース測定は A17 Pro、8 GB 物理メモリの iPhone 15 Pro Max 実機で行い、SwiftLlama と llama.cpp b8668 を使いました。各モデルを 4K と 8K でそれぞれ 3 回独立起動し、合計 60 回測定しました。

実機で記録するものは次のとおりです。

• モデルのロード時間
• 短い Prompt の TTFT
• プロセスメモリ
• Metal メモリ
• 熱状態
• 基本生成が完了したか

flowchart TB
    A[モデルファイルと SHA-256 を固定] --> B1[デスクトップ Metal 能力評価]
    A --> B2[iPhone 実機リソース評価]
    B1 --> C1[96 件の二言語要求]
    C1 --> D1[Parse Skill Action Mode]
    B2 --> C2[4K と 8K を各 3 回起動]
    C2 --> D2[Load TTFT Memory Thermal]
    D1 --> E[モデル選択]
    D2 --> E

この 2 種類の証拠は混ぜません。デスクトップの能力精度は iPhone のエンドツーエンド成功率ではなく、iPhone でロードできたことも 96 件を理解できた証明にはなりません。

4K と 8K で測ったもの

今回の実機 Prompt と生成は短くしています。4K/8K 測定が答えるのは主に 3 点です。

1. 対象端末で、その context 設定のモデルをロードできるか。
2. context 拡大による追加メモリはいくらか。
3. 短い依頼での起動、最初の token、熱状態は許容できるか。

8K token を埋めた後も速度が同じだとは証明していません。長い Prompt の prefill 性能も未測定です。それには実際に約 3.5K/7.5K token を入力し、prefill、生成速度、消費電力、継続的な熱推移を測る必要があります。

今回の 8K は容量とリソースのテストであり、「8K 長文能力の認証」ではありません。

結果を証拠として残す

能力評価では最終的な百分率だけでなく、モデルの Raw Output と SHA-256 を保存します。集計 JSON には次の情報が入ります。

• データセットのバージョンと digest
• モデルファイルの SHA-256
• Prompt 設定の SHA-256
• Prompt Profile
• context と候補数
• ケースごとの期待値、実値、各判定
• TTFT、E2E 遅延、token 数
• 形式修復が必要だったか

実機側では、独立起動ごとの Raw Text、CSV 集計、モデル別チェックサムを残します。証拠ディレクトリ全体にも SHA256SUMS.txt があります。

これで人為的な誤りがすべて消えるわけではありません。それでも、どのファイルを、どの設定で測り、表の数値がどのサンプルから計算されたかを後から確認できます。

この結果で証明しないこと

現在の証拠は、このオンデバイス Agent のルーター選びには使えます。ただし、次の主張には直接使えません。

• あるモデルの一般知能が最も高い
• すべての言語と Tool で優れている
• 8K の長文 prefill 性能を検証済み
• 実際のアラーム、カレンダー、メールの成功率が特定の数字に達した
• 学術的または業界全体のランキングである

96 件のうち 48 件の core は開発フィードバックに使われており、完全に独立した最終 holdout ではありません。確認質問や planning の重要な切片もまだ小さい状態です。実機測定は 1 構成 3 回で、モデル順序のランダム化、統一した冷却、電力、20 ターン連続セッションも未実施です。

これは記事末尾の形式的な注意書きではなく、結果そのものの一部です。

次に追加するもの

次版では、基準をさらに厳しくします。

1. tuning と分離した 300 件以上の独立 holdout を作る。
2. 全ケースを 2 名の非作者がバージョン管理された Rubric で確認する。
3. 1 ケース 3 Trial 以上を実行し、安定通過、変動ケース、95% Wilson 下限を出す。
4. 実際の 3.5K/7.5K prefill、連続会話、電力、熱推移、Jetsam 復旧を測る。
5. 隔離 Tool fixture でパラメータ、順序、承認、確認質問、最終環境状態を検証する。
6. 最後に少数の高リスク経路を、実機のシステム機能でエンドツーエンド確認する。

300 件の tuning/holdout 草案と Harness はすでにありますが、独立した 2 名の確認は完了していません。そのため、正式結果としては扱っていません。

最初の問いに戻る

この方法は「世界で最も賢い小型モデル」を探すものではありません。定義された端末、Runtime、Agent 契約の中で、現在のワークフローに最も適したデフォルトを選び、勝った理由、失敗する場所、証拠の限界を確認できるようにするものです。

10 モデルの結果、iPhone の 4K/8K リソース、モデルごとの判断は、「iPhone 実機で小型言語モデル 10 種を比較」で公開しています。