正在加载，请稍候
同一个编码任务，新旗舰模型得分从 60 涨到 66，每任务成本却从 10.79 涨到 13.04 美元。这笔账搬到手机上会被弱网和中断再放大——要固定的不是模型选型，而是每任务成本、缓存命中率、端上闭环率这几个口径。
同一个编码任务，新旗舰模型得分从 60 提到 66，每任务成本却从 10.79 涨到 13.04 美元。这笔账搬到手机上，会被弱网和中断再放大一轮。
延迟与端云协同的工程护栏，站内 移动端 AI 应用开发落地 那篇已经讲得比较细。本篇只谈一个更窄、也更常被算错的问题：钱和任务完成率怎么计量。
按请求统计，是移动端最容易踩的第一个坑。智能体每一轮调用都会重发前缀——工具定义、系统指令、到当前为止的对话。于是「把单个请求压小、但让轮数变多」的改动，整体往往更贵。
Cursor 团队公开的一份编排层调优提示词把这条写得很直白：要按任务计量、按计费类型加权，输出、未缓存输入与缓存输入的单价差得很远（AIHOT 收录的原文摘要）。
手机上还多一层：切后台、断网重连、推送唤醒会把一次任务切成多段连接。按 HTTP 请求归集，会同时低估开销、高估效率。若架构还在「小程序 / 原生 / 混合」之间摇摆，站内那篇 小程序三种架构取舍 值得先看——形态直接决定轮数与前缀大小。
把口径固定成下面五项，团队之间的数字才能对得上。前两项看钱，中间一项看编排，后两项看体验与分工。计费单位这里统一叫词元（token）。
| 口径 | 定义 | 采集位置 | 移动端为什么不同 |
|---|---|---|---|
| 每任务加权成本 | 输出、未缓存输入、缓存输入按各自单价加权求和 ÷ 已完成任务数 | 网关 / 代理层日志 | 必须按任务 ID 聚合，按请求聚合会失真 |
| 缓存命中率 | 缓存读取词元 ÷ 总输入词元 | 请求体与响应 usage 字段 | 会话被系统切碎，命中率天然偏低 |
| 每任务轮数 | 完成一个任务消耗的模型调用次数 | 编排层 | 轮数上升会成倍重发前缀 |
| 端上闭环率 | 在设备内完成、未回云端的任务 ÷ 任务总数 | 客户端埋点 + 补报队列 | 杀进程、卸载会截断数据 |
| 失败重试率 | 因超时或中断而重发的任务 ÷ 任务总数 | 编排层 + 客户端 | 弱网下重试是最隐蔽的开销项 |
单价下降不等于账单下降。Anthropic 把输入/输出单价降到每百万 4/20 美元（降 20%）、缓存读取从 0.50 降到 0.20 美元（降 60%），可新版本每任务用掉约 1560 万词元（上一代 1140 万），其中输出词元是上一代的 2.4 倍，每任务成本反而上涨 21%（Artificial Analysis 的测评条目）。
这也是缓存命中率必须进看板的原因：缓存读取的单价只剩未缓存输入的一个零头，命中率掉十个点，单价优惠立刻被吃掉。项目侧结出来的真实账单，站内 一篇移动端成本账 有更具体的口径对照。
失败重试率的处理细节，可以直接参考 超时、重试与副作用 那篇：移动端的重试不是加个次数上限就完事，副作用幂等才是前提。
端云分工的判据不是「覆盖了多少台设备」，而是「多少任务在端上闭环完成」。一个现成的反面案例：某系统级助手被整合进数以百万计的 iPhone，上线一个月后起步缓慢，到 2025 年夏季被合作方判定为「远低于预期」，并因此下调了周活跃用户预测（IT之家报道条目）。装机量是分母，任务完成率才是分子。
反方向的经验同样清楚：把长任务从本机移出去。Claude Code 的云会话已结束研究预览，合上笔记本后仍可在托管基础设施上继续执行（AIHOT 条目）。手机更适合做入口、授权与确认，重编排放到云端或内网侧；按上下文长度划这条线的做法，站内 端侧先扛、32K 之后交给云 已经给过参照。按硬件形态分层的问题，手机到眼镜助手的三层取舍 拆过一遍，本篇只补它的数据口径。
想把推理留在自有基础设施的团队，先读许可。Moonshot 的 Kimi K3 以开放权重形式发布，用的是自定义许可，OpenRouter 专门写文说明它属于「开放权重而非开源」（该解析条目）。工程决策要按许可条款做，不要按权重可得性做。
如果下个迭代就要动开销，建议按原团队验证过的顺序走，别先改提示词。
两个反例值得记住。第一，不要在系统提示词里叮嘱模型「注意节省 token」：有团队发现模型随后变得不愿承担有雄心的任务，甚至中途退出。第二，别用「不要 / 必须 / 重要」的清单驱动模型，改用对每个工具功能的平实描述——有团队据此把系统提示词削减了约三分之二。
一句话概括：改变的是编排层发送什么，而不是要求模型更努力地省。埋点缺失这一条，在站内 从 Demo 到生产的四个深坑 里已经出现过，它正是本文这套口径的前置条件。
差在会话边界。Web 端一次任务通常就是一个长连接；移动端会被切后台、断网和系统回收打断。口径上要把重连归并到同一个任务 ID，并在客户端留一个补报队列，避免杀进程丢数据。
按任务闭环率和失败成本判断，而不是按模型榜单分数。能端上闭环、失败代价低的任务优先端上；长上下文、多工具编排、强一致性的任务放云端。这条分工线可以先用两周埋点数据校准。
它只统计分发，不统计使用。上文系统级助手的例子说明，数百万台装机也可能换不来实际使用。看板至少要有每任务加权成本、端上闭环率、失败重试率三项。
不必，但前提是把约束写死：任务质量没有可测量的下降。上述那轮改动的实测结果是无损降本约 7%；一旦允许「偶尔任务失败但平均更便宜」，指标就失去意义。
如果你正在设计移动端智能体的成本与延迟看板，可以先从埋点清单开始。把现有的指标定义与采集位置发给我们，按任务口径对齐一遍：联系我们聊工程落地，或先看 已交付案例 里的度量方式。