手机本地能跑的 Agent 小模型 Landscape

调研 · 2026-05 · iOS + Android 端侧 / ≤4B 参数 base 模型 + mobile-agent 专训 / benchmark + 推理框架 + 硬件约束全梳理

🎯 TL;DR — 一句话现状

端侧 base 模型:开源最现实是 Qwen2.5-VL-3B (Apache-2.0, multimodal phone-use) 与 Phi-3.5-mini 3.8B (MIT) 和 Gemma 3 4B (Gemma Terms);系统集成最深是 Apple Foundation Model ~3B (iOS 18+, 3.7 bit/weight 混合量化, iPhone 15 Pro ≈30 tok/s 来自 Apple 官方 blog) 与 Gemini Nano (Pixel 8 Pro+,通过 AICore 系统服务暴露)。
专门为手机 GUI 训的模型:学术线 Mobile-Agent-v3.5(阿里 X-PLUG / 王老师组,基于 GUI-Owl 2B/4B/8B/32B,Qwen3-VL 底)是 2026 最活跃 fork;商业线 UI-TARS-1.5 7B (字节,跨平台);RL 路线 DigiRL 1.3B (Stanford, AitW 17.7→67.2)。
Benchmark:事实标准是 AndroidWorld (Google, 116 task × 20 app, paper SOTA 30.6%, 现 leaderboard 已被 70%+ 突破);训练数据看 AndroidControl (15,283 demo × 833 app) 和 AitW (715K episode × 30K 指令)。
推理框架:跨平台首选 MLC-LLM (TVM, Apache, 原生 iOS+Android Swift/Kotlin SDK);PyTorch 派 ExecuTorch (Meta, 已上生产 — Instagram/WhatsApp/Quest 3,支持 CoreML/XNNPACK/Qualcomm/MediaTek 12+ 后端);Google 派 MediaPipe LLM Inference API;Apple 派 Core ML + ANE 或 MLX(GPU 路线);Android 派 llama.cpp + GGUF (PocketPal/LM Studio 封装)。
参数甜点:1.5-3B int4 = 0.8-1.6 GB 文件,在 8 GB RAM 旗舰上可挤 15-30 tok/s burst;4B+ 就开始挤占 app 主进程的 RAM 上限,iOS 即使有 com.apple.developer.kernel.increased-memory-limit entitlement 也只能拿到 ~3-4 GB,所以 4B fp16 (8 GB) 基本不可能跑,必须 int4。

≈ 3B

Apple Foundation Model 端侧

30 tok/s

Apple 官方 iPhone 15 Pro

116

AndroidWorld task

1.5-3B

参数甜点 (int4)

1 · 手机端 LLM agent 的特殊约束

桌面端跑模型,内存 32 GB 起步,7-13B 是日常配置;手机端是另一个物种。要做 mobile-agent,得先理解 6 条硬约束。

1.1 RAM 预算 — 旗舰 12-16 GB,但 app 实际能拿到的远少于此

设备	总 RAM	OS+常驻	单 app 可用 (典型)	需要 entitlement 才能上升到
iPhone 15 Pro / 16 Pro	8 GB	~3 GB	~3 GB	~4-5 GB (Increased Memory Limit entitlement)
iPhone 17 Pro Max	12 GB	~3-4 GB	~4-5 GB	~6-7 GB (未在公开来源精确确认)
Pixel 9 Pro	16 GB	~5 GB	~4-6 GB	取决于 Activity flags,无硬限
Samsung S25 Ultra	12-16 GB	~5 GB	~4-6 GB	同上
OnePlus 13 / 小米 15 Pro	16-24 GB	~5 GB	~6-10 GB	同上

iOS 的硬约束: iOS 在第三方 app 进程上有 jetsam 机制 (kernel memory pressure killer);系统直接根据 memorystatus_get_priority_list 排序去杀。第三方 LLM app 的硬上限,iPhone 15 Pro 实测 ≈ 3 GB;加 com.apple.developer.kernel.increased-memory-limit 可以上到 ≈ 5 GB,但仍然小于 fp16 4B 模型(~8 GB)。所以必须 int4。Apple 自家 Foundation Model 不受这条约束,因为它运行在系统进程,通过 FoundationModels framework 暴露给 app — app 不持有权重。

1.2 延迟预算 — 触控到行动 < 500ms 是体感上限

手机交互的"触摸到反应"心理上限在 100-300ms (UI 设计经典数据);若 agent 是"用户问一句 → LLM 思考 → 操作 UI",prefill + 一轮生成的 budget 大约是 1-3 秒。这意味着:

prefill 必须用 NPU/GPU 跑(CPU prefill 在 3B 上要 5-10 秒);
decode 必须 ≥ 20 tok/s 才能让 100-token 短回答 < 5s;
若是 GUI agent,每一步还要 vision encoder forward,vision encoder forward 在 SigLIP/CLIP ~400M 上至少要 200-400ms,这通常是 latency 第一瓶颈。

1.3 NPU / Tensor accelerator — 三大派系

派系	硬件	峰值 TOPS	软件栈	支持的算子
Apple	Apple Neural Engine (ANE) — A17/A18/A19 Pro	~35-38 TOPS	Core ML 通过 MIL → ANE backend	int8/int4 mat-mul, attention, LayerNorm; 不支持任意算子,fallback 到 GPU
Qualcomm	Hexagon NPU (Snapdragon 8 Gen 3 / Gen 4 / 8 Elite)	45-75 TOPS	Qualcomm AI Engine Direct (QNN) / SNPE / AI Hub	int8/int4 GEMM、grouped-conv;对 LLM 的 KV cache management 是关键痛点
Google	Tensor G3 / G4 / G5 TPU	~33 TOPS (未在公开来源精确确认)	AICore + Edge TPU runtime	Gemini Nano 内部走 TPU,但不暴露 generic LLM API,只有 ML Kit GenAI 5 个高层 API
MediaTek	APU (Dimensity 9300/9400)	30-50 TOPS	NeuroPilot SDK / NNAPI	NeuroPilot SDK 直接暴露;较新机型支持 LLM ops

NPU "TOPS" 数字水分极大 — 厂商通常报 int8 sparse 峰值,LLM 实际 decode 受内存带宽而非算力限制(decode 是 memory-bound)。Snapdragon 8 Gen 3 的 LPDDR5X 带宽约 76.8 GB/s,这意味着 1B 模型 int4 (500 MB weights) 理论上限 ≈ 150 tok/s,实际 30-50 tok/s。

1.4 功耗 / 电池 / 散热 — 持续 LLM 推理是热瓶颈

iPhone 15 Pro 持续 ≈ 5W 功耗(约一半 SoC,一半屏幕)运行 LLM,会在 5-10 分钟后触发热降频 (thermal throttling),decode 速度可能砍半。battery:典型 4000 mAh × 3.85 V ≈ 15 Wh,持续 5W 推理 ≈ 3 小时极限(实际显著更短,因为还要算屏幕)。这就是为什么 Apple Intelligence 走 "burst on-device + 难任务 Private Cloud Compute" 的设计 — 不是技术上跑不了,而是用户体验上耗电不可接受。

1.5 Storage — 4-8 GB 是 app bundle 的实际上限

App Store / Play Store 都不喜欢超大 binary(App Store 单 app 安装大小有 4 GB 限制,但 On-Demand Resources 可绕过)。这意味着 base 模型权重最大 6-7 GB,留 1-2 GB 给 app 自身。int4 量化下 (~0.5 byte/param):

参数量	fp16 大小	int8 大小	int4 大小	能装 iPhone 15 Pro?
1B	2 GB	1 GB	0.5 GB	✓ 轻松
1.5B	3 GB	1.5 GB	0.75 GB	✓ 轻松
3B	6 GB	3 GB	1.5 GB	✓ 推荐
4B	8 GB	4 GB	2 GB	int4 才行
7B	14 GB	7 GB	3.5 GB	极限,接近 RAM 上限
8B	16 GB	8 GB	4 GB	int4 也吃力

1.6 量化是必修课

所有手机 LLM 部署都必须量化。常见方案:

GGUF (llama.cpp):Q4_K_M (4.5 bit/weight 平均) 是社区甜点,Q4_0 / Q8_0 / IQ3_XS 各种;
MLC-LLM:q3f16_1 / q4f16_1 / q4f32_1,后缀表示 group size 和 zero-point 表示;
Apple 的混合 2-bit/4-bit (3.7 bpw):Apple Foundation Model 的官方方案,只在系统模型上用,SDK 不开放;
AWQ / GPTQ:weight-only 4-bit,适合移动端;
ExecuTorch 内置 8-bit / 4-bit / dynamic quantization。

vision encoder 的特殊问题:大多数 mobile GUI agent 是 VLM,vision encoder (e.g. SigLIP-So400m, ~400M) 自身就要 200-800 MB,而且 activation 比 weight 更耗内存 — 一张 1920×1080 截图编码出的 patch tokens × hidden dim 会临时占用几百 MB。这是手机做 GUI agent 比做 function-call agent 难的核心原因。

2 · 可本地跑的 base 模型矩阵 (≤4B)

模型	参数	许可	多模态	int4 大小	实测 tok/s @ iPhone 15 Pro	用途
Apple Foundation Model	~3B	闭源 (系统服务)	否 (有图像理解 sibling)	~1.4 GB	30 tok/s (Apple 官方)	iOS 18+ Writing Tools / Smart Reply / 应用内 LLM API
Gemini Nano	3.25B (未在公开来源精确确认)	闭源 (AICore)	v2 多模态	~1.6 GB	未在公开来源精确确认	Pixel 8 Pro+ 系统层 / ML Kit GenAI 5 个 API
Qwen2.5 0.5B / 1.5B / 3B	0.5/1.5/3 B	Apache-2.0	否 (VL sibling 见下)	0.3/0.9/1.7 GB	~50/35/20 (社区报道)	function-call agent
Qwen2.5-VL 3B / 7B	3 / 7 B	Apache-2.0	是	1.7 / 3.8 GB	~15 / ~8 (vision encoder 拖累)	mobile GUI agent 首选开源
Qwen3 0.6B / 1.7B / 4B	0.6/1.7/4 B	Apache-2.0	否 (VL 见下)	0.4/1.0/2.2 GB	未在公开来源精确确认	thinking mode 可开关
Phi-3-mini / Phi-3.5-mini	3.8B	MIT	vision sibling	~2.2 GB	~20 (社区报道)	通用 reasoning
Phi-Silica	~3B (未在公开来源精确确认)	闭源 (Windows)	是 (多模态版本)	—	Copilot+ PC NPU,不是手机	Windows on-device,严格说不是 phone
Gemma 2 2B	2.6B	Gemma Terms	否	~1.4 GB	~25 (社区)	通用
Gemma 3 1B / 4B	1 / 4 B	Gemma Terms	4B+ 多模态	0.6 / 2.2 GB	~30 / ~12	多模态 4B 是当前 Apache-类许可下端侧 VLM 最强之一
LLaMA 3.2 1B / 3B	1 / 3 B	Llama Community	否 (11B/90B 是 vision)	0.6 / 1.8 GB	~35 / ~18 (社区)	Meta 官方 ExecuTorch 集成,手机最 friction-less 之一
MiniCPM 2B / 4B	2 / 4 B	Apache-2.0	V 系列多模态	1.1 / 2.2 GB	未在公开来源精确确认	面壁智能 OpenBMB
MiniCPM-V 2.6	8B	Apache-2.0	是	~4 GB	~6-8 (社区,极限)	"在 iPad 上跑得动的多模态" 营销点
MobileLLM	125M / 350M	CC-BY-NC (paper)	否	0.08 / 0.2 GB	~100+	Meta 研究品,主要为证明 sub-1B 也能 function-call
SmolLM2 135M / 360M / 1.7B	0.135 / 0.36 / 1.7 B	Apache-2.0	否	0.08/0.2/1.0 GB	1.7B ~40 (社区)	HuggingFaceTB,IFEval 56.7,BFCL 27% (官方报)

2.1 几个关键 base 模型的精读卡片

Apple Foundation Model (~3B)

WWDC 2024 / iOS 18+

Source: machinelearning.apple.com

参数量: ~3B(Apple 自报 approximate,Server 模型尺寸未披露)
量化: 平均 3.7 bpw,采用混合 2-bit / 4-bit策略;更激进的 3.5 bpw 也可以无显著质损
性能: iPhone 15 Pro 上 time-to-first-token ~0.6 ms/prompt token,decode 30 tok/s
评估: 人工偏好上 outperform Phi-3-mini / Mistral-7B / Gemma-7B / Llama-3-8B(Apple 自报)
API: iOS 26+ 的 FoundationModels framework — app 用 LanguageModelSession 调用,权重不暴露,通过 LoRA-style adapter 提供 task-specific 风格(Apple 称 "Adapters")
Agent 关键: 内置Tool use(系统-level Intent + 第三方 App Intent),这是 Apple Intelligence "在 Mail 里召唤 Notes 数据" 的核心机制

Gemini Nano (3.25B, Pixel 8 Pro+)

2024-Q4 起逐步铺开 / 2026 Nano v2 多模态

Source: developer.android.com/ai/aicore + Google AI blog (未在公开来源精确确认 3.25B 是否仍是 Nano v2 当前规格)

架构: 运行在 Android AICore 系统服务里(类似 Apple FoundationModels framework),app 不持权重
API: ML Kit GenAI 提供 5 个高层 API — Prompt / Summarization / Proofreading / Rewriting / Image Description / Speech Recognition
Gemini Nano v2: 2025 加入多模态(图片 → 描述 / 图片 → 答题),具体参数未公开
关键限制: 没有 "generic LLM completion" API — 必须经过 5 个 Task API,所以不能用来跑任意 agent(类似 Apple 但更紧)
设备覆盖: Pixel 8 Pro / 8a / 9 / 9 Pro / Galaxy S24 系列 / 部分 Xiaomi 14 等;不是所有有 NPU 的 Android 手机都有,要 OEM 主动集成 AICore

Qwen2.5-VL-3B (Apache-2.0)

2025-Q1 / HF 4.2M downloads/月

Source: HuggingFace

参数: 3B,bf16 ≈ 7.6 GB,int4 ~1.7 GB
关键能力: 论文/官方明确支持 "computer use / phone use" 作为 visual agent;能输出 bounding box 和 point 用于 GUI grounding
HF 上有 81 个量化版本给 llama.cpp/LM Studio/Jan/Ollama;事实标准 open-weight phone-VLM
底层就是 Mobile-Agent-v3.5 GUI-Owl 系列的 base(2B/4B/8B/32B 都从 Qwen2.5/3-VL 起步)

MobileLLM (Meta, ICML 2024)

arXiv:2402.14905 / Liu et al.

规模: 125M / 350M — sub-billion 路线
方法: deep-and-thin (更深而非更宽) + embedding sharing + GQA + block-wise weight sharing
结果: 比同尺寸 SOTA 前作 +2.7-4.3 pp;API-calling 任务上"close to LLaMA-v2 7B"
定位: 研究 demo,不是 production checkpoint(license CC-BY-NC),但证明了 350M 就够 function-call,这条 thesis 直接催生 SmolLM2 / Octopus v2

SmolLM2 (HuggingFaceTB, 2024-11)

Apache-2.0 / 135M / 360M / 1.7B

训练: 11T tokens, 256 H100, FineWeb-Edu + DCLM + The Stack + math/code
1.7B Instruct: IFEval 56.7(超 Qwen2.5-1.5B 的 47.4) / HellaSwag 66.1 / GSM8K 48.2 / MT-Bench 6.13
BFCL: 27% (官方自报)
定位: "端侧能跑 + 通用强 + 完全开源"当前最佳综合

3 · 专门为 mobile-agent / GUI 训练的模型

这一节是 base 模型之上的专门为 phone 任务做后训练的工作。

模型	规模	base	训练	许可	主线 benchmark
Octopus v2	2B	Gemma 2B	SFT on synthetic Android Intent	Apache-2.0 (weights)	自报"超 GPT-4 in accuracy + latency, context length -95%"
Octopus v3 / v4	1-7B	Mistral / Llama	SFT 跨模态 / 多 agent 路由	研究 demo	—
Mobile-Agent v1	—	GPT-4V (推理时)	无训练,纯 prompting + OCR/检测器	MIT (code)	Mobile-Eval (自家)
Mobile-Agent v2 (NeurIPS 2024)	—	GPT-4V / Qwen-VL	三 agent (planning/decision/reflection) + memory	MIT	+30% completion vs v1
Mobile-Agent v3 / v3.5	2/4/8/32 B	GUI-Owl (Qwen3-VL)	full SFT + RL	开源 weights	AndroidWorld / OSWorld 自报 SOTA
Mobile-Agent-E	—	GPT-4o	self-evolving (无训练)	MIT	—
AutoUI / Auto-GUI	~7B	BLIP/Flamingo	SFT on AitW	研究	AitW
AppAgent (TencentQQGYLab)	—	GPT-4V	self-explore docs + prompting	MIT	self-bench (自家 9 app)
DigiRL (Stanford, NeurIPS 2024)	1.3B	VLM	offline → offline-to-online RL	Apache-2.0	AitW 17.7 → 67.2 success
ScreenAgent	—	multi	SFT	研究	screen-task
UI-TARS-1.5 / UI-TARS-2 7B	7B	Qwen2-VL	大规模 SFT + RL (字节)	weights ✓ / RL infra 部分开源	OSWorld 47.5, AndroidWorld 高位

3.1 Octopus 系列 (Nexa AI) — function-call 路线

Octopus v2 (arXiv:2404.01744, 2024-04)

规模: 2B(Gemma 2B base);方法: 把每个 Android Intent / API 编码成一个 "functional token",LLM 只需生成 1-2 个 token 就完成 function-call,prefill 几乎为 0;
自报: "surpasses GPT-4 in both accuracy and latency, decrease context length by 95%";"35× latency over Llama-7B RAG-style";
意义: 把 mobile agent 的核心瓶颈 ("prompt 包含所有 API → 几千 token prefill") 用 vocab tricks 绕过;但只解决已知封闭 tool set 的情况,不能跨任意 MCP server。

3.2 Mobile-Agent 系列 (阿里 X-PLUG) — 学术线最活跃

Mobile-Agent-v2 (NeurIPS 2024, Wang et al.)

三 agent 架构:

Planning Agent — 维护 task progress 而非全 history,绕过"长 token 序列下 mobile screenshot 容易丢"的问题;
Decision Agent — 每步出操作;
Reflection Agent — 看上一步结果,纠错;
Memory unit — 持续累积"focus content"

结果: 完成率比 v1 +30% pp(GPT-4V 后端,自家 Mobile-Eval)

Mobile-Agent-v3.5 / GUI-Owl (2026-Q1, arXiv:2602.16855)

转折点:从 prompt engineering 转向 自训 base 模型;GUI-Owl 2B / 4B / 8B / 32B / 235B 在 Qwen3-VL 上 SFT+RL
评测:跨 20+ GUI benchmark(OSWorld / AndroidWorld 等),自报多个 SOTA
开源:weights + code 在 GitHub X-PLUG/MobileAgent(8.7K stars 截至 2026-05)
定位:开源 mobile GUI agent 当前最完整 stack — 兼有训练 base + 多 agent 编排

3.3 DigiRL — RL 路线 (Stanford, NeurIPS 2024)

DigiRL (arXiv:2406.11896, Bai et al.)

1.3B VLM,在 AitW 上做 offline → offline-to-online RL
方法:advantage-weighted RL + automatic curriculum
结果:17.7% → 67.2% success(同 base SFT 起点);对比: AppAgent + GPT-4V 仅 8.3%,CogAgent 38.5%
意义:证明 1.3B + RL 能在某些 AitW 子集超过 GPT-4V;但只在已知 app 集合有效,跨 app generalization 仍弱

3.4 UI-TARS 系列 (ByteDance, 2024-2026)

详见 #17 UI-TARS-2。简要:UI-TARS-1.5 是 7B 跨平台 agent,2 代是 230B MoE,二代不是端侧模型,但 1.5 的 7B int4 在高端 Android (24 GB 机型) 上是 prudent 选择。真正面向手机端的还是 GUI-Owl 2B/4B。

4 · Benchmark 全景

Benchmark	规模	评测协议	当前 SOTA	许可
AndroidWorld (Google)	116 task × 20 app	动态参数化 + 程序化 success-checker	paper 时 30.6%; 2026 leaderboard 70%+ (Mobile-Agent v3.5 / UI-TARS 等)	Apache-2.0
AndroidControl (Google, NeurIPS 2024)	15,283 demo × 833 app	SFT 数据集 + in/out-of-domain split	SFT 数据,不是 leaderboard	Apache-2.0 (?)
AitW (Android in the Wild)	715K episode × 30K 指令	4 Android 版本 × 8 设备类型 × 多分辨率	多版本 leaderboard;DigiRL 67.2 / CogAgent 38.5	研究用
GUI-Odyssey	~7,735 task (多任务长 episode)	cross-app 转移 + 200 多任务长 traj	未在公开来源精确确认	研究
Mobile-Eval (M3A / T3A)	33 task (M3A multimodal)	self-reported success	Mobile-Agent v2 报多 +30 pp	MIT (随 Mobile-Agent)
B-MoCA (Benchmark for Mobile Control Agents)	未在公开来源精确确认	跨 daily-life 任务	未在公开来源精确确认	研究
Mobile-Agent-Bench / AppAgent-Bench	每个 ~9-15 app	self-bench	—	各自 MIT
SPA-Bench (Smartphone Agent Benchmark)	340 task × en/zh 双语	real-device + emulator	未在公开来源精确确认	研究

4.1 AndroidWorld — 事实标准

AndroidWorld (Rawles et al., arXiv:2405.14573)

116 个程序化 task,覆盖 20 个真实 Android 应用(系统设置、Markor 笔记、OsmAnd 地图、Audio Recorder、Tasks、Files、Joplin、Simple Gallery 等)
动态参数化:每个 task 模板可以生成"无限"自然语言变体 — 例如 "set alarm for 7am" → "wake me up at quarter to 7" → "remind me 30 min before sunrise"
每个 task 有 init / success-checker / tear-down 三件套,可重复执行
paper 报告 SOTA 30.6%(最佳 baseline,paper 时未命名具体模型);2026 公开 leaderboard 已经 70%+(Mobile-Agent-v3.5 / Aria-UI / 字节 UI-TARS 系列)
关键限制:跑在 Android emulator(android_world Python 包 + AVD),不是真机;但是公认开源金标准

4.2 AitW — 历史最重要的训练数据

Android in the Wild (Rawles et al., 2023, arXiv:2307.10088)

715K episode × 30K 唯一指令,人工演示;Android v10-13,8 种 Pixel 设备
任务是 multi-step,需要"语言 + 视觉 + 手势"语义理解;关键:动作不是 UI element 而是精确手势(水平滚动、长按、坐标级 tap),这使 grounding 难度比 web 高得多
它是后续几乎所有 mobile-agent 训练的数据源:DigiRL / Auto-UI / AutoUI / CogAgent (mobile mode) / Aria-UI 都从 AitW 起步
但 AitW 不是 dynamic benchmark(只能离线评分,看 action 是否与 ground truth 一致),所以 AndroidWorld 才是"评测"金标准;AitW 是"训练 + 离线评测"金标准

4.3 AndroidControl — Google 自己加的 NeurIPS 2024 训练 + eval 套件

AndroidControl (Li et al., NeurIPS 2024, arXiv:2406.03679)

15,283 demo × 14,548 唯一 task × 833 Android app
每个 instance 提供 high-level + low-level 双层指令 — 这是 AitW 没有的;让研究者可以单独评估 "理解任务" vs "理解 UI"
关键结论:in-domain fine-tune 涨得快,out-of-domain scaling 显著慢;"fine-tune on more data 单凭这一项不足以实现 robust OOD"
它对 DigiRL / Mobile-Agent-v3 / GUI-Owl 等都是核心 SFT 数据

4.4 评测 leaderboard 现状 (2026-05 snapshot)

系统	AndroidWorld	AitW (web subset)	底层模型
GPT-4V (Mobile-Agent v2)	~30% (paper)	~30% completion	GPT-4V API
GUI-Owl 7B (Mobile-Agent v3.5)	自报 SOTA(具体数值未在公开来源精确确认)	—	Qwen3-VL 7B + SFT/RL
UI-TARS-1.5 7B	高位(未在公开来源精确确认确切名次)	—	Qwen2-VL 7B + 大规模 SFT
Aria-UI (Rhymes AI)	57.0% (自报)	—	MoE 24B(不能上手机)
DigiRL 1.3B	未直接评 AndroidWorld	AitW 67.2%	1.3B VLM + offline-to-online RL

校订: AndroidWorld 公开 leaderboard 在 2026 已被多家刷到 70%+,但 paper PDF 仍写 30.6%。引用时必须区分 "paper 数字" 和 "现 leaderboard 数字" — 不少二手 survey 误把 30.6% 当现实 ceiling。

5 · 推理框架 / 部署栈

框架	出品	iOS	Android	NPU 后端	许可	支持模型
MLC-LLM	MLC AI / CMU TVM	Swift SDK ✓	Kotlin/Java SDK ✓	Metal / Vulkan / OpenCL	Apache-2.0	Llama / Mistral / Qwen / Phi / Gemma / RedPajama 等几十家
llama.cpp + GGUF	ggerganov + community	via PocketPal / LLMFarm	via PocketPal / Maid / ChatterUI	CPU + Metal (iOS) + OpenCL (Android Adreno)	MIT	几乎一切开源 LLM,GGUF 是事实标准
MLX	Apple ML Research	iOS 18+ (mlx-swift)	—	Apple GPU (Metal); ANE 较弱	MIT	Mistral / Qwen / Llama / Phi (mlx-community)
ExecuTorch	Meta PyTorch	Swift / Obj-C (CoreML backend)	Kotlin/Java + JNI	XNNPACK + CoreML/ANE + Vulkan + Qualcomm QNN + MediaTek	BSD-3	Llama 3.2/3.1/3, Qwen 3, Phi-4-mini, LiquidAI LFM2, Llava, Voxtral, Gemma 3
MediaPipe LLM Inference API	Google	✓ (CocoaPods)	✓ (AAR)	XNNPACK / GPU / NPU (per device)	Apache-2.0	Gemma / Phi-2 / Falcon / StableLM (官方支持列表)
Apple Core ML	Apple	原生	—	ANE + GPU	闭源 (Apple platforms)	转换工具 (coremltools);事实上 Apple Foundation Model 就在这条路径
NNAPI	Google (Android)	—	OS-level (deprecated 在 NDK 31+)	各 OEM 后端	—	tflite 走 NNAPI,但Google 在缓慢弃用,推 Android NDK + 厂商 SDK 替代
Qualcomm AI Engine Direct (QNN)	Qualcomm	—	✓	Hexagon NPU 直接编程	闭源 SDK	需手动 export;ExecuTorch 已经包了一层
MNN	Alibaba	✓	✓	各种	Apache-2.0	主要 vision/ASR,LLM 支持后加
NCNN	Tencent	✓	✓	Vulkan / Metal	BSD-3	主要 vision;LLM 走 ncnn-llm fork 但 ecosystem 落后
TensorFlow Lite (LiteRT)	Google	✓	✓	NNAPI / GPU / EdgeTPU	Apache-2.0	主流 vision/ASR;LLM 走 MediaPipe wrapper

5.1 三种推荐组合

组合 A · "我要跨 iOS+Android 一套代码" → MLC-LLM。
官方 Swift + Kotlin SDK,模型只需要在 desktop 上预编译(weight conversion + libgen)一次,iOS/Android binary 直接 link。适合早期 prototype / 独立开发者。

组合 B · "我已经在 PyTorch 训了 GUI agent 模型" → ExecuTorch。
直接 torch.export → .pte → CoreML backend (iOS) / XNNPACK / Qualcomm (Android)。Meta 自己 Instagram/WhatsApp/Quest 3 都在用。代价:exporter 支持的算子有限,custom ops 要写 kernel。

组合 C · "iOS 单平台,要榨 ANE" → Core ML (coremltools) 或直接 FoundationModels framework。
FoundationModels 不需要打包权重(Apple 系统级),但仅限 Apple 模型;Core ML 自家模型可以但 ANE backend 对自由 transformer 还不够灵活,实际仍多 fallback 到 GPU。

5.2 MLC-LLM vs ExecuTorch 一句话

MLC-LLM 是 "编译器派"(TVM),把模型从 IR 一路编译到 Metal/Vulkan kernel,跨平台一致;ExecuTorch 是 "runtime 派"(50 KB runtime),依靠 12+ 硬件 backend partition graph。MLC 对模型 zoo 友好,ExecuTorch 对硬件 zoo 友好。两条路在 2026 已经 converge — 都支持 Qwen/Llama/Phi/Gemma,差距越来越窄。

6 · 实测性能表 — model × phone × tok/s @ int4

下表数字大多来自社区报告 / Reddit / HF discussion / GitHub issue,而非官方;Apple Foundation Model 的 30 tok/s 是 Apple 官方 blog;其他凡未在公开来源精确确认的标注为"~估计"。

模型 (int4)	iPhone 15 Pro (A17 Pro, 8 GB)	iPhone 17 Pro (A19 Pro, 12 GB)	Pixel 9 Pro (Tensor G4)	Snapdragon 8 Gen 3 (8-16 GB)	Snapdragon 8 Elite
Qwen2.5-0.5B	~80 (~估计)	~100 (~估计)	~60 (~估计)	~70 (~估计)	~110 (~估计)
Qwen2.5-1.5B	~30-40 (~估计)	~45 (~估计)	~25 (~估计)	~30 (~估计)	~55 (~估计)
Qwen2.5-3B	~18-22 (社区)	~28 (~估计)	~15 (~估计)	~20 (~估计)	~35 (~估计)
Qwen2.5-VL-3B	~12-15 (~估计,vision encoder 拖累)	~20 (~估计)	~10 (~估计)	~13 (~估计)	~22 (~估计)
Phi-3.5-mini 3.8B	~18-20 (社区报)	~25 (~估计)	~15 (~估计)	~18 (~估计)	~30 (~估计)
LLaMA 3.2 1B	~40 (~估计)	~55 (~估计)	~30 (~估计)	~35 (~估计)	~60 (~估计)
LLaMA 3.2 3B	~15-18 (社区)	~25 (~估计)	~13 (~估计)	~17 (~估计)	~28 (~估计)
Gemma 3 1B	~30-35 (~估计)	~45 (~估计)	~25 (~估计)	~30 (~估计)	~50 (~估计)
Gemma 3 4B	~10-12 (~估计)	~18 (~估计)	~8 (~估计)	~12 (~估计)	~20 (~估计)
SmolLM2 1.7B	~35 (社区)	~50 (~估计)	~28 (~估计)	~32 (~估计)	~55 (~估计)
MiniCPM-V 2.6 8B	~极限/不可用	~6 (~估计)	RAM 紧	~5 (~估计)	~10 (~估计)
Apple Foundation 3B	30 (Apple 官方)	~40+ (~估计)	—	—	—

表的可信度:除 Apple 30 tok/s 外,其它都是数量级估计,实际可能 ±50%。差异来自:① quantization (Q4_0 vs Q4_K_M 差很大);② thermal 状态(冷启 vs sustained);③ context length(长 context 时 KV cache 主导,decode 慢);④ 框架(llama.cpp vs MLC vs ExecuTorch)。本表用于决策粗排序,不用于绝对承诺。

7 · Mobile agent 训练框架与数据

7.1 训练数据三大支柱

数据集	规模	用途
AitW (Android in the Wild)	715K episode	SFT 大规模 — DigiRL / Auto-UI / GUI-Owl base
AndroidControl (Google)	15.3K demo × 833 app	SFT in/out-of-domain split
GUI-Odyssey	~7K cross-app multi-step	跨应用 long horizon
OS-Atlas (跨平台,含 mobile)	13M element	grounding
Aguvis	4.2M grounding + 1.3M traj	两阶段训
Mobile-Agent self-explore	合成 (无具体 size 公开)	v2/v3 自有合成

7.2 RL 训练框架

DigiRL (Stanford, 2024) — 第一个公开的 mobile-agent online RL trainer;走 AitW + advantage-weighted RL + auto curriculum;Apache-2.0;GitHub
android_world (Google) — 既是 benchmark 也是 env,可以接 RL — emulator + adb;Apache-2.0
ClawGUI / MobileWorld — 见 #14,Docker 化的 mobile env,17.1% 训练成绩,提供并行 emulator
UI-TARS-2 sandbox(字节内部)— 见 #17,mobile+desktop 混合训练 env
Mobile-Agent-v3.5 (X-PLUG) — 自家 RL pipeline,但代码不完整开源

7.3 训练成本 (粗估)

训一个 3-4B mobile GUI agent,从 base VLM 起步:

SFT:AitW + AndroidControl 全量,Qwen2.5-VL-3B base,8× H100 / 2-3 天 / ~$2K-$5K
online RL on emulator:DigiRL-style,32 parallel emulator + 8× H100 / 1-2 周(emulator 是瓶颈,见 #14 ClawGUI 讨论)
对比 desktop OSWorld RL:mobile emulator overhead 显著小于 X11 VM(no display server),所以 mobile RL 在 throughput 上比 desktop 友好

8 · 与本系列其他工作的连接

关联	笔记	关系
#14 ClawGUI	14_ClawGUI	同主题 — Mobile-World Docker emulator,本笔记 §7 直接复用
#15 PinchBench	15_PinchBench	姊妹 agent benchmark 调研(coding agent,跨平台)
#16 Desktop Agents landscape	16_DesktopAgents	姊妹篇 — 桌面 GUI / CLI 生态,本笔记沿用其模板和结构
#17 UI-TARS-2	17_UITARS2	跨平台 GUI agent(mobile+desktop),其 1.5 版 7B 是手机端可考虑候选
#27 Small Model MCP landscape	27_SmallModelMCP	参数甜点讨论 — 那边讨论 ≤40B MCP,这边讨论 ≤4B mobile;1.5-4B 是两边交集
#29 EnvTuning	29_EnvTuning	"tune env 不 tune agent" 思想对 mobile 同样有效 — emulator 的 error message 可以 actionable 化
#31 Prime Intellect Hub	31_PrimeIntellectHub	Environments Hub 已有 Android emulator env,可以用 verifiers SDK 起步训练

9 · 决策树 — 我要在手机上做 agent

从 "单 OS 还是跨平台" 一路分到 "目标机型 RAM" 的 mobile agent 选型决策树。注意每一层都有"诚实落子"的回退选项 — 8 GB RAM 中低端不能跑 3B+,即使你想。

10 · 局限 / 诚实分析

10.1 为什么 Siri / Google Assistant 仍然走云

这一点必须直说:截至 2026-05,所有可商用的复杂 mobile agent 任务,产品上仍然是 cloud-first。本地模型只做简单子任务:

智能回复短信(Apple / Google 都做)
邮件 / 通知 summarization
简单的 in-app 命令(打开某 app、设个闹钟)
OCR / 翻译 / ASR(这些不是 LLM,是 task-specific 小模型)

真正的多 app reasoning(e.g. "看一下我妈微信发的菜谱,把里面的食材加到购物 app 然后打开外卖 app 看哪个超市送货最快")— 没有产品级的 on-device 解决方案。原因:

1B-3B 模型 multi-turn reasoning 弱 — 这是 #27 笔记的核心结论之一,BFCL V4 上 ≤4B 极少能 cross 50%;
vision encoder 太贵 — 真要每 step 看屏幕,RAM/延迟双重不可承受;
跨 app 权限本身是 OS 问题不是模型问题(Android 跨 app 还行 via accessibility service,iOS 几乎不可能,只能走 Shortcuts/Intent 这种受控接口)。

所以 Apple 设计了 Private Cloud Compute(同样架构、可审计、no-log)做难任务 fallback;Google 直接走 Gemini Cloud。这就是产品现实。

10.2 mobile GUI agent 比 mobile function-call agent 难一个量级

维度	function-call	GUI agent
模型尺寸	0.5-3B 足够	VLM 至少 3-7B
RAM 内存	1.5 GB 内 fit	3+ GB (含 vision activation)
延迟	<1s feasible	每 step 1-3s typical
OS 权限	app intent / shortcut API 即可	iOS 需 Accessibility / Android 需 Accessibility Service(显眼系统警告)
跨 app generalization	SDK schema 已知,容易迁移	视觉 layout 千差万别,OOD generalization 弱

这就是为什么 Octopus / MobileLLM 那条 "functional-token / function-call" 路线产品上更接近落地,而 Mobile-Agent v3.5 / GUI-Owl 这条 "看屏幕直接操作" 在实验室漂亮但产品上还没成熟方案。

10.3 持续推理的能耗诚实账

iPhone 15 Pro 持续 LLM decode ≈ 5W,A19 Pro 更高效但仍至少 3-4W;
4000-5000 mAh 典型电池 ≈ 15-20 Wh,纯 LLM 持续运行 ≈ 3-5 小时(还要算屏幕/通讯);
更现实模型:每天 burst 几十次,每次 30 秒-1 分钟,这是 Apple Intelligence 的实际负载模型;
"agent 在后台 7×24 跑" — iOS 当前不允许(后台只允许有限 task);Android 允许 foreground service 但很费电。

10.4 关于本笔记数字的诚实标注

本笔记中已经明确标记为 "未在公开来源精确确认" 的字段包括:

iPhone 17 Pro Max 单 app 可用 RAM 上限(只是 12 GB total 的内插)
Tensor G5 TPU TOPS 数字
Gemini Nano v2 的当前精确参数量(3.25B 是 v1 数据)
Qwen3 0.6B/1.7B/4B 在 iPhone 15 Pro 的实测 tok/s
MiniCPM 2B/4B 在 iPhone 上 tok/s
GUI-Odyssey 准确 task 数量
B-MoCA / SPA-Bench 当前 SOTA
AndroidWorld 2026 leaderboard 各家具体名次
Mobile-Agent-v3.5 GUI-Owl 在 AndroidWorld 上自报 SOTA 的精确数值
UI-TARS-1.5 7B 在 AndroidWorld 上确切名次
第 6 节实测性能表中除 Apple 30 tok/s 之外的所有数字(均为社区数量级估计)

这些字段在二手 survey 中常被错引,本笔记选择承认不知道而非编造一个精确数字。

📚 主要参考来源

AndroidWorld — Rawles et al., arXiv:2405.14573
Android in the Wild — Rawles et al., arXiv:2307.10088
AndroidControl — Li et al., NeurIPS 2024, arXiv:2406.03679
DigiRL — Bai et al., arXiv:2406.11896
Mobile-Agent v1 — Wang et al., arXiv:2401.16158 · v2 NeurIPS 2024, arXiv:2406.01014
Octopus v2 — Nexa AI, arXiv:2404.01744
MobileLLM — Liu et al., ICML 2024, arXiv:2402.14905
Apple Foundation Models — machinelearning.apple.com
Gemini Nano / AICore — developer.android.com/ai/aicore
Qwen2.5-VL — HF
SmolLM2 — HF
MLC-LLM — llm.mlc.ai
ExecuTorch — GitHub
Mobile-Agent (X-PLUG) — GitHub