地铁进站，手机信号从满格掉到一格，语音助手还在转圈。这个场景并不新鲜，却解释了本地推理被反复提起的原因：有些任务等不及云端往返，也不该把原始数据全送出去。端侧AI把模型放在手机、电脑、车机或摄像头里，先让设备自己完成一部分判断，再决定要不要联网。
断网那一刻，问题才具体
很多演示把本地模型说成“把大模型塞进口袋”，听起来轻松。真正落地时，工程团队先面对的是内存、功耗和发热。一个模型能不能放进去，不只看参数量，还要看量化后的体积、运行时占用、连续推理时的温度变化。设备不是数据中心，风扇、供电和散热都有限，推理速度稍有波动，用户就会感知到卡顿。
这也让端侧AI的任务边界变得清楚：实时字幕、离线翻译、图片预处理、语音唤醒、工业相机里的缺陷初筛，通常只需要局部信息，延迟要求却很明确。把这些环节放在本地，云端只处理汇总、同步和复杂查询，系统会多一层分工。这里没有谁替代谁的问题，更多是任务该在哪一层完成。
隐私是理由，但不是全部
讨论端侧AI时，隐私常被放在前面。家庭摄像头画面、会议录音、车载传感器读数，留在本地确实能减少传输环节。可隐私并不是唯一驱动力。网络覆盖不稳定的现场、需要快速响应的交互、带宽成本敏感的设备，都会把推理往本地推。反过来，模型更新、复杂推理和跨设备协同仍然依赖云端。端侧与云端之间，更像一条按任务切分的流水线。
落地难点在“持续可用”
模型跑通一次不难，难的是几个月后仍然可用。端侧设备型号多、系统版本杂，传感器输入也不稳定。量化会带来精度损失，剪枝会影响某些长尾场景，更新包还要考虑存储和回滚。团队需要建立一套观察机制：推理失败时能否降级，温度过高时能否限流，模型版本和规则库是否一致。这些问题不显眼，却决定用户会不会在第二次打开时继续使用。
另一个容易被忽略的是责任边界。设备本地做出的判断，出问题时谁来解释？如果模型在离线状态下误识别，日志留在哪里，用户能否知道触发条件？本地推理把计算拉近用户，也把可观测性难题拉到眼前。没有清晰的日志、版本和回退策略，本地智能很容易变成黑盒。
它更像一层基础设施
从长期看，本地推理不会只停留在发布会演示里。它会像本地缓存、离线地图一样，成为设备能力的一部分：平时不抢眼，断网、弱网或对延迟敏感时才显出来。对产品团队来说，值得先问的不是“要不要上端侧AI”，而是哪些数据必须留在本地，哪些判断不能等，哪些失败可以优雅降级。这些问题答不清楚，本地能力就容易停在演示阶段。