最近我们一直对一个问题很感兴趣：小参数语言模型，是否已经足够在手机本地承担有用的 Agent 类任务？
为了让答案不只停留在主观感受上，我们选了五个热门 GGUF 文本模型，在 4K 和 8K 两种上下文设置下做了一组对比。资源测试跑在 iPhone 15 Pro Max 真机上；能力测试则对每个模型使用同一套 96 条确定性 Agent 路由用例，覆盖 Skill 选择、Action 提取、Mode 分类、缺槽识别和简单规划判断。
这不是一份泛化的学术评测，而是一份手机优先的工程检查：模型能不能加载，8K 上下文会多吃多少内存，首 token 有多快，以及它能不能为一个小型本地 Agent Runtime 稳定输出结构化决策。
测试模型
| 模型 | 本地文件大小 | 量化 | 状态 |
|---|---|---|---|
| MiniCPM5-1B | 656.2 MiB | Q4_K_M | 已测试 |
| Gemma-3-1B-IT | 768.7 MiB | Q4_K_M | 已测试 |
| Qwen3.5-2B | 1221.5 MiB | Q4_K_M | 已测试 |
| Qwen2.5-3B-Instruct | 2007.4 MiB | Q4_K_M | 已测试 |
| Phi-4-mini-instruct | 2376.4 MiB | Q4_K_M | 已测试 |
为什么 Qwen 已经到 3.8，还在测 Qwen3.5？
Qwen 最新主线确实已经不止 3.5。以当前公开信息看，Qwen3.8 系列的重点是 Qwen3.8-Max、Qwen3.8-2.4T-A95B 和 Qwen3.8-27B 这类更大的模型。它们很重要，但和 1B-4B 级手机本地路由模型不是同一个部署档位。
这次测试的目标不是评测最新云端旗舰，而是找一个真正能放进手机 Runtime 的模型：默认 4K context，复杂任务可切 8K，内存可控，并且能稳定输出结构化决策。在这个约束下，Qwen3.5-2B 仍然是 Qwen 系列里非常相关的候选，因为更新的 Qwen3.6、Qwen3.7、Qwen3.8 目前没有明确的官方 1B/2B 级开源小模型来承担这个角色。
| Qwen 系列 | 是否有公开的手机本地小模型候选 | 为什么本轮这样选 |
|---|---|---|
| Qwen3.5 | 有：0.8B、2B、4B 级别 | 适合手机本地路由，本轮测试了 2B |
| Qwen3.6 | 暂未看到明确 1B/2B/4B 开源候选 | 公开权重主要是 27B 和 35B-A3B 级别 |
| Qwen3.7 | 暂未看到明确 1B/2B/4B 开源候选 | 更多是 API 侧 Max/Plus/Flash 模型线 |
| Qwen3.8 | 暂无手机尺寸官方候选 | 公开重点是 Max、2.4T-A95B、27B；第三方 GGUF 更偏桌面/工作站 |
覆盖范围和还没测的候选
这张表不是在说“所有适合手机的模型都已经测完了”。它覆盖的是当时本地已经有 GGUF、并且能跑完同一套手机资源测试和 96 例路由协议的文本模型。
它也不是只有国内模型。当前表里有 Qwen、MiniCPM 这样的中文/国内模型系列，也有 Google 的 Gemma 和 Microsoft 的 Phi。真正的缺口是，还有一些海外或跨社区的新候选没有进入这一轮本地 benchmark。
| 仍值得补测的候选 | 来源/生态 | 为什么值得测 |
|---|---|---|
| LFM2.5-1.2B-Instruct | Liquid AI | 明确面向端侧和 tool-style 工作负载 |
| LFM2.5-1.2B-Thinking | Liquid AI | 小尺寸 reasoning 候选，但 thinking 输出需要控制延迟 |
| Llama 3.2 1B/3B Instruct | Meta | 虽然不是最新，但仍是重要的手机本地基线 |
| SmolLM2/SmolLM3 小尺寸 instruct 模型 | Hugging Face 生态 | 可作为独立轻量基线 |
| Gemma 3n E2B | 面向移动端的多模态候选，需要 VLM 测试而不只是文本路由 | |
| MiniCPM-V-4.6 | OpenBMB 生态 | 小尺寸多模态候选，适合测屏幕理解、图片和 OCR |
下一轮应该在满足同一条件后再把这些模型放进表里：有兼容的本地 artifact，能跑同一套 4K/8K 手机资源测试，并且能跑同一套结构化路由或多模态任务协议。
手机侧环境为 iPhone 15 Pro Max，A17 Pro，8 GB 物理内存，iOS 26.6.1，SwiftLlama + llama.cpp b8668，Metal 全层卸载。每个模型和 context 组合都独立启动 3 次。
评测流程
This diagram could not be rendered. Its source is still available below.
View diagram source
flowchart LR
A[选择 GGUF 模型] --> B[运行手机 4K 和 8K 资源测试]
B --> C[记录加载时间、TTFT、进程内存、Metal 内存]
C --> D[运行同一套 96 条路由用例]
D --> E[统计 Parse、Skill、Action、Mode、槽位、规划指标]
E --> F[套用手机优先的上线门槛]手机资源测试使用短中文 prompt，衡量模型加载、context 分配、短 prompt TTFT、基础生成和内存占用。它不等价于完整 4K/8K 长 prompt prefill 压测。
96 例能力测试使用同一批模型文件和确定性采样设置，但运行在桌面 Metal 评测器上，以保证各模型之间的能力对比可重复。这样可以把手机资源可行性和结构化路由能力分开看。
iPhone 4K 和 8K 资源结果
五个模型在两种上下文下都能成功加载。
| 模型 | Context | Load P50 | TTFT P50 | 加载后进程内存 | 加载后 Metal 内存 | 结果 |
|---|---|---|---|---|---|---|
| MiniCPM5-1B | 4K | 0.172 s | 0.140 s | 175.7 MiB | 1008.8 MiB | 3/3 loaded |
| MiniCPM5-1B | 8K | 0.176 s | 0.136 s | 271.6 MiB | 1104.8 MiB | 3/3 loaded |
| Gemma-3-1B-IT | 4K | 0.621 s | 0.215 s | 197.3 MiB | 1381.2 MiB | 3/3 loaded |
| Gemma-3-1B-IT | 8K | 0.567 s | 0.200 s | 301.3 MiB | 1485.2 MiB | 3/3 loaded |
| Qwen3.5-2B | 4K | 0.323 s | 0.268 s | 201.4 MiB | 1767.8 MiB | 3/3 loaded |
| Qwen3.5-2B | 8K | 0.323 s | 0.274 s | 249.6 MiB | 1819.8 MiB | 3/3 loaded |
| Qwen2.5-3B-Instruct | 4K | 0.303 s | 0.445 s | 230.8 MiB | 2447.0 MiB | 3/3 loaded |
| Qwen2.5-3B-Instruct | 8K | 0.296 s | 0.442 s | 375.0 MiB | 2591.0 MiB | 3/3 loaded |
| Phi-4-mini-instruct | 4K | 0.431 s | 0.503 s | 614.0 MiB | 3291.8 MiB | 3/3 loaded |
| Phi-4-mini-instruct | 8K | 0.569 s | 0.511 s | 1126.4 MiB | 3795.8 MiB | 3/3 loaded |
最关键的资源结果是从 4K 升到 8K 的增量。在这组设置里，Qwen3.5-2B 只增加了约 52 MiB Metal 内存，而 Phi-4-mini 增加了约 504 MiB。对于一个默认使用 4K、复杂任务才临时切到 8K 的手机端 Runtime，Qwen3.5-2B 的成本曲线更干净。
96 例路由能力结果
这套能力集包含 96 条中英文 Agent 请求，检查模型能否输出有效结构化决策、选对 Skill、选对 Action、区分 retrieve/act/clarify/answer 行为、保留必要槽位，并识别需要规划的任务。
| 模型 | Context | Parse | Skill | Action | Mode | Missing slots | Planning | TTFT P50 | E2E P50 |
|---|---|---|---|---|---|---|---|---|---|
| MiniCPM5-1B | 4K | 62.5% | 85.4% | 51.0% | 53.1% | 28.6% | 25.0% | 0.136 s | 0.622 s |
| MiniCPM5-1B | 8K | 62.5% | 85.4% | 51.0% | 53.1% | 28.6% | 25.0% | 0.138 s | 0.592 s |
| Gemma-3-1B-IT | 4K | 68.8% | 82.3% | 52.1% | 58.3% | 42.9% | 37.5% | 0.147 s | 0.976 s |
| Gemma-3-1B-IT | 8K | 68.8% | 82.3% | 52.1% | 58.3% | 42.9% | 37.5% | 0.148 s | 0.920 s |
| Qwen3.5-2B | 4K | 100.0% | 95.8% | 95.8% | 96.9% | 100.0% | 87.5% | 0.276 s | 1.098 s |
| Qwen3.5-2B | 8K | 100.0% | 95.8% | 95.8% | 96.9% | 100.0% | 87.5% | 0.273 s | 1.079 s |
| Qwen2.5-3B-Instruct | 4K | 94.8% | 80.2% | 71.9% | 79.2% | 66.7% | 37.5% | 0.522 s | 1.633 s |
| Qwen2.5-3B-Instruct | 8K | 94.8% | 80.2% | 71.9% | 79.2% | 66.7% | 37.5% | 0.529 s | 1.644 s |
| Phi-4-mini-instruct | 4K | 67.7% | 50.0% | 42.7% | 51.0% | 42.9% | 12.5% | 0.606 s | 2.220 s |
| Phi-4-mini-instruct | 8K | 63.5% | 55.2% | 34.4% | 42.7% | 42.9% | 25.0% | 0.620 s | 1.870 s |
1B 级模型的资源成本很诱人，但它们在结构化 Action 和 Mode 决策上失败太多。对于可能触达提醒、邮件草稿、记忆更新等写路径的本地助手来说，这不是一个小小的 benchmark 分数问题，而是实实在在的产品风险。
Qwen3.5-2B 是这一组里唯一通过建议上线门槛的模型：Parse 稳定、Skill 和 Action 都超过 90%、Mode 超过 95%，并且手机侧 8K Metal 内存低于 2 GiB。
实用排序
| 排名 | 模型 | 最适合的用途 |
|---|---|---|
| 1 | Qwen3.5-2B Q4_K_M | 默认本地 Agent 路由候选 |
| 2 | Qwen2.5-3B-Instruct Q4_K_M | 研究基线，但不是最合适的手机默认模型 |
| 3 | MiniCPM5-1B Q4_K_M | 极低资源 fallback，可承担更简单的分类 |
| 4 | Gemma-3-1B-IT Q4_K_M | 有参考价值的轻量基线，但行动决策不够稳 |
| 5 | Phi-4-mini-instruct Q4_K_M | 对这类手机优先路由任务来说过重 |
这组结果说明了什么
对手机端本地 Agent 来说，最好的模型不一定是最小的模型。最小的模型确实赢在 TTFT 和内存，但结构化决策质量下降明显。更大的模型也不会自动胜出：Qwen2.5-3B 和 Phi-4-mini 都比 Qwen3.5-2B 更吃内存，但在这套路由任务上得分更低。
这次测试里最有用的中间点是 Qwen3.5-2B。它把 8K 内存控制在相对可用的范围内，同时在中英文用例上都能稳定输出接近 JSON 的路由决策。默认 context 仍然应该保持 4K，以控制电量和发热；只有在任务复杂度确实需要时，再升级到 8K。
限制和下一步测试
这些数字不能被过度外推。
手机资源测试使用的是短 prompt，所以下一步需要增加长 prefill 档位，比如约 3.5K 和 7.5K prompt tokens，并加入连续 20 轮会话，记录 tokens/s、热状态、电量下降和 jetsam 风险。
能力测试聚焦文本路由。Gemma 3n 和 MiniCPM-V 这类多模态候选，应该用独立 VLM harness 来测，包括屏幕理解、OCR、图片问答和权限受限的隐私场景。
后续也值得继续接入新的端侧候选，包括 LFM2.5-1.2B-Instruct、LFM2.5-1.2B-Thinking、Llama 3.2 1B/3B、SmolLM 系列小尺寸 instruct 模型、Qwen3.5-4B、Gemma 3n E2B 和 MiniCPM-V-4.6。只有当它们完成同一套手机资源测试和同一套能力协议后，才应该进入同一张对比表。