在地铁隧道里，手机相机仍能实时识别画面，语音转写也不等网络恢复。这类体验背后，往往不是云端服务突然变快，而是端侧AI在设备本地完成了推理。
先把“离线可用”拆开看
离线只是表面。用户感知到的是少一次等待、少一次上传，开发者面对的却是一整套约束：模型要装进有限内存，推理时不能把电量迅速抽干，长时间运行还要控制发热。云端可以把请求排队、扩容，设备端没有这种余地。一次推理慢半秒，放在相机预览里就可能变成卡顿；模型多占一点内存，后台应用就可能被系统清理。
所以端侧AI不是把云上的模型原样搬下来。它接近一次产品重排：哪些能力必须在本地完成，哪些可以延后，哪些根本不该交给设备。这个问题不解决，模型再小也会显得笨重。
模型变小，不等于事情变简单
常见的做法是压缩模型、量化参数、裁剪层数，或者针对特定任务训练轻量网络。这些手段能降低存储和计算压力，但也会带来新的取舍。压缩过度，识别在光线变化或口音差异下就容易失准；为了省电减少计算，响应速度可能变得不稳定。设备型号、系统版本、传感器差异还会让同一套模型表现不一致。团队如果只在开发机上测试，很容易低估真实环境里的波动。
另一个容易被忽略的是更新。云端模型可以频繁迭代，设备端却要经过应用发版、用户下载、系统兼容等环节。模型文件变大，更新包也跟着变大；更新太频繁，用户未必愿意。端侧AI的维护接近长期运营，而不是一次交付。
先画边界，再谈能力
端侧AI适合处理对时延敏感、数据不宜离开设备、网络条件不稳定的任务。比如实时图像处理、语音唤醒、离线字幕，这些场景对本地计算有明确需求。反过来，需要大量知识检索、复杂推理或持续更新的任务，交给云端通常合理。这里没有放之四海皆准的答案，只有具体产品里的取舍。
- 先问数据是否必须留在本地，再谈模型大小。
- 把功耗和发热纳入验收，而不是只看单次推理速度。
- 为不同设备留出降级路径，避免一种配置打天下。
- 明确模型更新和回滚机制，别把发版当成终点。
端侧AI真正考验的，不是能不能在演示里跑通，而是能不能在电量、内存、网络和用户耐心都不宽裕的情况下，稳定地完成一件小事。把边界画清楚，它才会成为产品的一部分，而不是宣传页上的一个词。