谁来接住设备现场的第一层智能，端侧模型吗？

AI 助手离开聊天框，问题就已经变了

在聊天窗口里，用户先替 AI 做了一遍整理：选好图片，组织语言，敲下一句相对完整的提示词，再点发送。

到了智能眼镜、手机、车机和耳机上，这个前提没了。摄像头看到一串画面，麦克风收到半句话，屏幕停在某个 App，本地文件、位置和系统权限各有边界。用户说一句“把这个记下来”，这里的“这个”可能指眼前招牌、屏幕上的地址，也可能是刚才那段对话。

⬆️AI生成

AI 进入设备后，最先遇到的不是推理题，而是一地没有整理过的现场。

这就是“第一层智能”要处理的东西。专业一点说，它是靠近数据源的本地智能层：接收传感器、应用状态和用户输入，先完成识别、过滤、结构化与路由。说白了，它不急着回答，而是先弄清楚发生了什么、用户想做什么、哪些数据能碰、下一步该交给谁。

Apple 和 Google 的开发接口已经露出这种形状。Apple 的 Foundation Models framework 不只生成文本，还支持结构化输出和工具调用；Android 的 Gemini Nano 则运行在 AICore 系统服务中，由系统管理模型权重、请求处理以及输入输出安全。模型开始从一个 App 里的功能，变成操作系统能调度的公共能力。

图源：Android Developers（CC BY 2.5）

差别很大。

一个只会聊天的小模型，可以离线回答问题；一个能承担第一层智能的系统，还得读懂现场、遵守权限、调用工具，并在设备资源不足时知道自己该停手。

能在端上跑，只是入场券。能接住现场，才算上场。

第一层智能不是一个模型，而是四个连续动作

“端侧模型”这个说法容易把注意力吸到参数量、量化位数和每秒 token 上。这些当然重要，但它们解释不了产品为什么好用。

把一次设备交互拆开，会更清楚。

第一步是上下文整理。 端侧先把语音、画面、屏幕内容、位置和应用状态对齐，判断哪些信号属于同一任务。这里可能同时用到传统语音识别、视觉模型、规则系统和小语言模型，不必什么都塞给一个大模型。

第二步是权限判断。 模型看得见，不等于应用有权使用；模型推断出动作，也不等于系统应该执行。读取相册、访问联系人、调用摄像头和付款，风险完全不是一个等级。第一层智能必须把“理解了什么”与“获准做什么”分开。

图源：Android Developers（CC BY 2.5）

第三步是任务路由。 简短摘要、实体提取、意图分类和明确的本地工具调用，可以留在设备端。涉及大文档、外部知识、长上下文或复杂推理，再升级到边缘节点或云端。Android 官方文档给出的边界就很直白：Gemini Nano 适合图像理解、短翻译和引导式摘要；处理大型 PDF 或依赖额外知识时，云端模型更合适。

第四步是轻量执行。 输出最好不是一段漂亮废话，而是应用能直接消费的结构化对象：时间、地点、联系人、动作类型和待确认参数。Apple 把 Guided Generation 和 Tool Calling 放进系统模型接口，意义就在这儿——模型的终点开始从“说一句”变成“交付一个受约束的动作”。

这四步串起来，第一层智能更像酒店前台：先听清需求，核对身份和权限，能当场办的当场办，办不了的再转给对应部门。类比到此为止。技术上，它仍是一条由感知模型、系统服务、策略规则、端侧生成模型和工具接口共同组成的处理链。

不是一个万能模型。

端侧和云端，不该再做一道二选一

很多讨论喜欢问：未来推理到底在端侧，还是在云端？这个问题有点旧了。真正需要决定的是，一项任务的哪一段留在本地，哪一段值得上云。

Apple 的方案很有代表性。官方安全文档写得很克制：能在设备完成的任务尽量本地处理，更复杂的请求才交给 Private Cloud Compute。也就是说，本地优先不等于本地包办；复杂模型上云，也不等于把摄像头、文件和现场噪声原封不动倒进服务器。

更合理的调用链，大致有四层：

端侧小语言模型与云端大模型的协同研究，也不再只讨论“卸载到哪里”。2025 年提交至 arXiv 的综述《端侧小模型与云端大模型的协同推理与学习》把协同推理分成任务分配、任务切分和混合式协作，并进一步讨论了自适应调度、资源感知卸载与模块化路由。这是论文提出的分类框架，不是已经形成的行业标准。换句话说，路由不是写死一句“复杂任务上云”就完事，它要同时看任务难度、网络状态、电量、时延目标、数据敏感度和当前可用模型。

这事儿挺工程，也挺不浪漫。

可产品体验往往就死在这些地方。Microsoft 的 Phi Silica 平台卡明确提醒：设备持续处于内存压力时，系统可能卸载模型，下一次调用的首 token 等待时间会增加；流式生成因为要更频繁地做安全检查，也会带来额外开销。所谓“本地零延迟”——不对，准确说是减少网络往返，并不等于推理没有等待。

端云协同不是妥协，它本来就是设备智能的完整形态。

真正的门槛，是系统能不能守住边界

端侧模型越来越小，NPU 越来越强，于是很容易产生一种错觉：再等一两代芯片，云端就没那么重要了。

我不太认同。

中国信通院一篇关于智能终端 AI 计算的文章，把路线变化概括为从云推理走向端推理、从小模型走向可部署大模型、从单点优化走向系统级协同。它列出的难题也不只是模型压缩，还包括编译优化、硬件加速、系统能效管理、统一 Runtime 和 AI-native OS。

这才是硬骨头。一个端侧模型即使回答质量不错，也可能因为常驻内存太大、连续调用发热、权限设计粗糙、旧设备跑不动、模型更新不可控，结果只能待在演示视频里。参数表很热闹，真正落到设备里，账单是冷的：内存、功耗、散热、兼容性，少一个都不行。

⬆️AI生成

所以，判断一款 AI 硬件有没有“第一层智能”，我会看四件事：

1. 它能否把多模态现场整理成稳定、可检查的结构化任务；
2. 它是否把数据访问权限和动作执行权限分开管理；
3. 它能否根据任务、网络和设备状态在本地、边缘与云端之间路由；
4. 断网、模型不可用或置信度不足时，它有没有可预测的降级路径。

少了前两项，它只是多了一个聊天入口。少了后两项，它大概率是一段跑得起来、却很难长期运行的 Demo。

第一层智能的竞争，表面看是模型下沉，底层其实是系统重新分工。 模型负责理解，但不能独吞权限；云端负责重推理，但不该默认拿走整个现场；应用负责执行，也不能把自然语言当成无条件授权。

等 AI 真正进入眼镜、耳机、汽车和身边每一块屏幕，我们需要担心的，可能不再是“它会不会回答”。

而是它在替我们整理现场时，究竟看见了多少，又替我们决定了多少？

参考资料

• Apple Foundation Models developer documentation: https://developer.apple.com/documentation/FoundationModels/
• Meet the Foundation Models framework, WWDC25: https://developer.apple.com/videos/play/wwdc2025/286/
• Android Developers, Find the right AI/ML solution for your app: https://developer.android.com/ai/overview
• Android Developers, Gemini Nano: https://developer.android.com/ai/gemini-nano
• Android Developers Content License: https://developer.android.com/license
• Google AI for Developers, Deploy Gemma on mobile devices: https://ai.google.dev/gemma/docs/integrations/mobile
• Microsoft Learn, Phi Silica platform card: https://learn.microsoft.com/en-us/windows/ai/cards/phi-silica-platform-card
• Apple Private Cloud Compute Security Guide: https://security.apple.com/documentation/private-cloud-compute/
• Collaborative Inference and Learning between Edge SLMs and Cloud LLMs: https://arxiv.org/abs/2507.16731
• 智能终端AI计算技术的路径与挑战: https://ictp.caict.ac.cn/CN/abstract/abstract1544.shtml

Portions of this page are reproduced from work created and shared by the Android Open Source Project and used according to terms described in the Creative Commons 2.5 Attribution License.

文章仅做学术分享，如有侵权请联系删除，非常感谢！