早高峰地铁里，手机相册弹出“整理本周照片”的提示。你点了同意，几秒后它把模糊截图和重复连拍归到一起。整个过程没有转圈等待网络，也没有把原图传到某个看不见的机房。这类体验背后，常常就是端侧AI在做事：模型不离开设备，计算发生在本地。
但它并不是把云端模型原样搬进手机那么简单。一个能在服务器上跑的模型，放到手机、平板、车机或眼镜里，先要面对内存、功耗和发热的约束。模型小一点，效果可能打折；模型大一点，设备扛不住。所谓“放进设备”，更像在有限空间里重新安排一套工作流程。
先问一句：为什么非要在本地算
有些任务天然适合本地。相册分类、输入法联想、语音唤醒、会议记录转写，用户希望按下就有反应，不愿每次都等网络往返。还有一些场景网络本身不稳定，比如地下车库、电梯、偏远路段，本地计算能保住基本可用性。更现实的一层是数据：照片、录音、聊天记录留在设备里，用户对“上传”这件事的顾虑会少一些。它的价值，往往不在参数规模，而在这些具体摩擦被抹平。
难点藏在细节里
从工程角度看，端侧AI的麻烦很少集中在“能不能跑”，更多在“能不能稳定地跑”。
- 内存和带宽：模型权重、缓存和中间结果都要占空间，设备还要同时运行别的应用，留给模型余量并不宽裕。
- 功耗和发热：持续推理会推高耗电，手机烫手、掉电快，用户很快就会关掉功能。
- 设备碎片化：不同芯片、不同系统版本、不同内存规格，让同一套模型很难原样适配所有设备。
- 更新与回退：模型需要迭代，但端侧分发不像网页更新那样轻，出错后的回退也要提前设计。
所以，模型压缩、量化、蒸馏这些手段会被反复使用，但它们不是免费午餐。压缩过头，理解能力和稳定性可能下降；保留太多，又回到资源问题。这类产品设计，常常是在“够用”和“能承受”之间找平衡，而不是追求一次到位。
不是所有任务都该留在本地
本地计算有边界。复杂的知识问答、长文档推理、需要持续更新的事实性查询，仍可能更适合交给云端。反过来，低延迟、强隐私、弱网环境下的任务，更适合本地处理。更可行的路径可能是分工：设备先做唤醒、筛选和预处理，把真正需要大算力的部分送上去；云端返回结果后，再由本地完成呈现和个性化。这样看，端侧AI不是云端的替代品，而是把计算重新分配到更合适的位置。
这也意味着，评价一个本地功能，不能只看演示时那几秒。还要看它是否常驻、是否耗电、是否打扰、离线时是否还能用、模型更新后是否变得陌生。用户感知到的不是“模型有多大”，而是相册整理有没有误判、语音输入有没有延迟、会议摘要会不会漏掉关键句。
把模型放进设备，门槛并没有消失，只是从机房转移到了口袋、桌面和车里。端侧AI真正考验的，是团队对资源约束的耐心，以及对具体场景的克制。