早高峰的地铁里，有人对着手机说了一段话，转写文字几乎同时出现在屏幕上。隧道里没有信号，这个功能照样能用。类似的变化正在不少设备上发生，它们被归到同一个词下面：端侧AI。
模型装进设备，先撞上的是内存和电
把模型放进手机、车机或者一枚摄像头里，第一道门槛往往不是算力峰值，而是内存带宽和功耗预算。参数量稍大一点，推理时数据在内存和计算单元之间来回搬运，耗电和发热就上来了。工程上常见的做法是量化、剪枝、蒸馏，把模型压到设备能长期承受的规模，再针对具体芯片做算子适配。这部分工作琐碎，也很难讲成故事，但它决定了一个功能是能常驻后台，还是只能在演示视频里跑一遍。
另一个容易被低估的麻烦是碎片化。同一套模型，换一颗芯片、换一个系统版本，表现就可能不一样。厂商要在有限的机型覆盖和有限的调试人力之间做取舍，这种取舍通常不会写进发布会。
用户感知到的，是不用等的那几秒
语音唤醒、拍照识物、输入法联想、会议录音转写，这些场景的共同点是高频、短时、对延迟敏感。放到端上跑，断网可用、响应更直接，数据也不必离开设备。用户说不出技术名词，但会记住“这个反应快”。反过来，如果端上模型为了省资源砍得太狠，答非所问，用户同样会立刻察觉，然后关掉这个功能。
所以体验的关键常常不在模型本身有多大的能力，而在它是否稳定地待在后台、是否在电量紧张时被系统悄悄杀掉、是否在弱网和离线之间平滑切换。这些细节由产品策略和系统调度决定，模型只是其中一环。
不是所有任务都该留在端上
长文档总结、复杂推理、需要持续更新知识的问答，放在云端更合理。端侧AI更像是一种分工：把高频、低延迟、涉及个人数据的部分放在本地，把重计算交给远端。真正难的是路由策略——什么条件下走端、什么条件下走云，切换时怎么保证结果衔接，模型更新失败怎么回滚。这些问题偏产品和工程，却直接影响体验是否稳定。
我倾向于认为，端云之间不该被描述成替代关系。端上负责“随时可用”，云上负责“能力上限”，两者之间的边界会随着芯片和模型压缩技术缓慢移动，而不是某天突然重画。
几个还悬着的问题
- 功耗预算归谁：模型常驻后台的电费，算在系统头上还是应用头上，目前缺少清晰的约定。
- 模型更新由谁负责：端上模型体积不小，更新频率、灰度节奏和失败回滚，都需要专门的机制。
- 能力边界怎么说明：用户很难判断一次回答是本地生成还是云端返回，出错时的责任和提示方式也还没形成惯例。
我的判断是，端侧AI的价值不在于把大模型塞进小设备这件事本身，而在于让一些小事不再需要等待和联网。它大概不会有一个统一的爆发时刻，更可能是一批功能悄悄变了反应速度，用户过一阵子回头，才发现自己已经习惯了。