端侧AI不是按功能选，而是按任务选
苹果、谷歌文档中的限额与持续负载实测是判断标准
商业苹果把判断顺序写进了开发者文档里
苹果开发者文档里写着决定使用端侧模型还是服务器模型的顺序。先用设备内运行的模型做出来，用评估工具确认质量，只有判断推理能力或上下文窗口1不够时才发往服务器，这就是这个顺序。
看这句话所处的位置，它说的不是要一次性对整个产品决定是否在设备端处理。厂商先说的是，要用实际做出一个功能并实测的结果来决定。这意味着判断的单位不是服务，而是任务。
相同代码，不同限额
苹果在同一份文档里附上的比较表只有五行。两种模型都保护隐私，离线运行只有设备端能做到，用量方面设备端无限制、服务器端有每日限额。分多个步骤思考的推理模式只在服务器端运行，一次能输入的内容在 4K 和 32K 词元之间相差 8 倍。
| 项目 | 设备内模型 | 服务器模型（Private Cloud Compute） |
|---|---|---|
| 离线运行 | 可以 | 不可以 |
| 用量限制 | 无 | 每用户每日限额 |
| 推理模式 | 无 | 支持 3 个阶段 |
| 上下文 | 4K 词元 | 32K 词元 |
创建会话时只需改一行模型对象，相同的提示词就会发往服务器。工具和指令也原样传过去。因此开发团队实际要回答的问题，不是“要不要用端侧”，而是落到“这个任务能否在 4K 以内完成、需不需要分多个步骤来处理、是不是要在飞机上也能运行”。
安卓的结构也类似。谷歌以 ML Kit GenAI 这个组合提供摘要、拼写纠正、文体转换、图像描述、语音识别、自由提示词功能，这些功能都运行在由 AICore2 管理的共享 Gemini Nano 之上。谷歌在文档里写明的优点有三个。输入、推理、输出都在设备内处理，即使网络不稳定功能也照常运行，且不会产生每次调用都附加的服务器费用。
文档下方写着限制条件
沿着同一份谷歌文档往下拉到底，故事就变了。
GenAI API 推理只有在应用位于屏幕最前端时才被允许。即便使用前台服务也会被拦截，并返回 BACKGROUND_USE_BLOCKED 错误。那种想在后台整夜汇总累积通知的设计方案，到这一行就走到了尽头。
每个应用还被设置了推理配额。短时间内堆积请求会出现 ErrorCode.BUSY，超过按日计算的长时间使用上限时，则会单独抛出电池用量超限错误。并不是说在设备端跑就意味着无限制，只是账单从流量费变成了电池和配额而已。
设备清单也需要确认。截至 2026 年 9 月 10 日，文档中记载的支持设备为 Pixel 9～11 系列、Galaxy S25、S26 及其折叠屏机型，以及其他厂商的旗舰机型。中低端机型不在名单之列。而且各设备搭载的 Gemini Nano 版本分为 nano-v2、v3、v4，谷歌方面也提示，同样的提示词在不同版本下可能产生不同输出，需要事先做评估。文档中还写明，包括韩语在内的语言支持也会因设备设置和已下载的模型而有所不同。
浏览器端的门槛更为明确。要使用 Chrome 内置 AI，Chrome 用户资料所在的磁盘卷需要有 22GB 以上的剩余空间，且需要 VRAM 超过 4GB 的 GPU，或者 RAM 16GB、4 核以上 CPU 的配置。首次下载模型需要非计量计费的网络连接，下载完成后如果剩余空间跌破 10GB，模型就会被删除。安卓和 iOS 版 Chrome 目前尚不支持，而截至 Chrome 149，文档标明的输入输出语言为英语、西班牙语、日语、德语、法语。韩语不在这份清单里。
如果是面向韩国的服务，算盘在这里就会被打断一次。因为一旦把设备端处理定为网页端的默认路径，就得先数一数，究竟有多少百分比的用户能够真正打开这个功能。
不是测峰值，要测趋于平稳之后
性能比较的条件更为苛刻。2026 年 3 月公开、6 月修订的一篇实测论文可以作为参考。这项研究把压缩为 4 比特的 Qwen 2.5 1.5B 部署到四种设备上，以相同的 258 个 token 的提示词，每隔 1 秒连续投喂 20 次，记录速度与温度的变化。
iPhone 16 Pro 在最初两次达到每秒 40.49 个 token，从第三次反复开始温度状态上升，到第 17 次之后趋于平稳，稳定在每秒 23.67 个 token，比峰值低 41.5%。Galaxy S24 Ultra 从每秒 12.21 个 token 降到 10.38 个 token，下降了 15%，但这条平缓曲线只在关闭屏幕、把上下文限制为 2,048 个 token、并将预填充3片段缩小到 128 个 token 的条件下才会出现。论文作者明确指出，这些数值并非应用开发者默认设置下会出现的行为。
由此可以得出产品团队应采纳的一条标准。如果是持续接收请求的功能，纳入计算的数值不应是峰值，而应是趋于平稳之后的速度。基准测试视频或发布材料中的数字，大多是最初几次的结果。
从芯片规格直接推算速度同样会出错。同一项研究中，搭载 40 TOPS4专用 NPU 的板卡跑出了每秒 6.914 个 token 的成绩。这是因为逐字生成答案的解码阶段受限的不是算力，而是内存带宽。相反，这块板卡在功耗低于 2W 的情况下，20 次测试中速度几乎没有偏差，也没有观测到因发热导致的性能下降。生成 500 个 token 的答案需要 72 秒，无法用于对话场景，但这种特性反而适合用户无需等待的夜间摘要任务。
在处理功耗数值时还需格外谨慎。这篇论文也说明，各平台测量每个 token 能耗的方式各不相同，并特别注明不要直接比较这三类数值。把以 GPU 为单位测得的值、以整机为单位测得的值、以及通过关闭屏幕后电池电量估算出的值放在一起比较，这种比较本身是不成立的。
决定不使用，也是一种结论
到目前为止确认过的条件，如果按作业单位整理一下，可以这样区分。
| 作业的性质 | 在设备端处理 | 发送到服务器 |
|---|---|---|
| 输入长度 | 简短消息、一屏内容 | 长文档、累积的对话 |
| 判断的深度 | 分类、提取、润色 | 需要多阶段推敲的问题 |
| 连接状态 | 离线是必要条件时 | 可以假定常时连接时 |
| 执行时点 | 用户正在看屏幕时 | 后台、预约执行 |
| 频率 | 间歇性请求 | 连续、大量处理 |
在这张表里，越往右走，设备内处理的优势就越小。如果左侧对应的作业在我们的服务中一个都没有，结论就是“暂不引入”。
即便选择引入，成本也不会消失，只是转移了位置。由于每台设备上的模型版本不同，必须按版本评估输出质量；而且无论如何都要再做一套服务器路径，供不支持的设备用户使用；超出配额时该向用户展示什么内容，也需要设计。苹果甚至把接近每日额度上限时让应用显示状态的 API 都开放出来了。
关于个人信息和成本的承诺，也只能在已确认的范围内做出。“在设备端处理”这句话，意思是这项作业的输入不会发送到外部，并不意味着产品的其他路径也会因此一并变得安全。三星在 Galaxy AI 设置里让用户自己选择数据是在设备端处理还是在云端处理，这个设计的前提正是：两条路径并存于同一个产品之中。
Oswarld视角
我对端侧AI一直持相当积极的态度。这次借着资料重新确认了这份乐观的依据，发现值得期待的部分和现在就能用在产品上的部分，并不在同一个位置。
值得期待的是方向。厂商把设备端和服务器端放在同一个API之后、可以一行代码切换，这件事本身就是一个信号：未来这个选择将不再是架构层面的决定，而更接近于按功能设置的一个参数。专用NPU在2W以下二十次运行中始终没有出现波动的记录，也指向同一个方向——现在的慢，与其说是原理上的极限，不如说是配置上的极限。
结语
要不要引入端侧AI，并不是由我们如何看待技术的未来决定的。它取决于我们服务中哪些任务能在 4K 以内完成、是不是发生在用户正盯着屏幕看的那一刻、以及使用受支持设备的用户占比是多少。这三点，凭现有的厂商文档和公开的实测数据就能确认。
不过，这里写下的数字只是某个特定时间点的文档和一次实测得出的结果。受支持设备和语言列表每次更新都会变化，实测也只用了一个模型和一个提示词。用我们服务里真实的任务重新测一遍，这一步终究还是省不掉的。
💬 读者的服务里，有哪些任务值得尝试搬到设备端？哪怕只写出输入长度和执行时机，我也可以一起帮你算算。
📨 如果身边有同事正在评估要不要引入AI功能，哪怕只把这篇文章里按任务分类的对比表发给他们也好。
参考资料与延伸阅读
核心来源
- Apple Developer，“Adding server-side intelligence with Private Cloud Compute”，2026 年。……这是厂商自己整理的文档，列出了设备端模型与服务器端模型的五项差异以及切换顺序。
- Google for Developers，“Overview of the ML Kit GenAI APIs”，2026 年 9 月 10 日更新。……支持的功能、设备清单、按应用分配的配额、前台限制，都集中在一页里。
- Chrome for Developers，“Get started with built-in AI”。……上面写明了存储空间、GPU、网络连接、支持语言等左右网页端激活率的条件。
- Tummalapalli, P. 等，“LLM Inference at the Edge: Mobile, NPU, and GPU Performance Efficiency Trade-offs Under Sustained Load”，arXiv:2603.23640，2026 年。……展示了峰值性能与持续性能之间的差距有多大，以及测量条件应该披露到何种程度。
背景知识
- Apple Security Research，“Private Cloud Compute: A new frontier for AI privacy in the cloud”。……整理了发送到服务器的请求是如何被处理和删除的设计依据。
- 三星电子，“Galaxy AI”。……可以查看让用户自行选择设备端处理或云端处理的控制方式。
相关往期
你的观点会成为下一期的线索
欢迎留下你的经验与看法。