一个常见的场景是：人在电梯里，网络信号变弱，语音备忘录仍能把刚想到的句子转成文字。这个动作背后，推理没有离开设备，而是由本地模型完成。端侧AI常被描述成“把大模型塞进手机”，但真正难的地方并不是塞进去，而是让它在需要时立刻可用。
设备不是数据中心。它的内存、散热和电量都有限，用户也不会为了等一个模型加载而停在原地。很多演示能跑通，落到日常使用却会遇到冷启动、内存占用和后台调度的问题。模型装进了设备，并不等于体验已经成立。
省下的那几百毫秒，用户能感知吗
本地推理减少了一次网络往返，对手写识别、语音转写、相机预览这类连续交互有帮助。可延迟只是体验的一部分。若唤醒时要先加载模型，或系统在后台频繁回收资源，省下的时间又会被等待吃掉。本地推理的关键不是跑分，而是让模型像系统能力一样稳定待命。
省下带宽，花掉的是电
推理放到本地，数据不必上传，带宽和部分云端成本下降，但计算开销转移到设备上。持续运行会带来发热和耗电，厂商必须在响应速度、模型大小和续航之间做取舍。端侧AI不是把云端任务整体搬过来，它更像一次重新分工。
- 可以留在本地：短指令理解、离线转写、连续感知后的初步筛选。
- 仍要交给云端：需要大知识库、复杂生成或跨设备协同的任务。
这种分工听起来简单，做起来却要求应用清楚知道哪些请求必须即时返回，哪些可以等待网络。模糊的分工会让用户感到设备“时快时慢”，而不是智能。
模型变小以后，能力边界也变窄
量化、蒸馏和剪枝能让模型适应设备，但压缩也会损失一部分长尾能力。面对常见表达，本地模型可能反应不错；遇到含糊指令、方言或专业语境，错误会更明显。端侧AI的边界不在参数多少，而在它是否知道自己何时该求助云端。
因此，混合推理会长期存在。设备负责即时、连续、与个人上下文紧密相关的部分，云端处理复杂任务。难点在于切换要自然：用户不必理解请求去了哪里，也不该在两个模型之间来回确认。
隐私不是一句本地运行就能解决
数据留在本地，确实减少了上传环节，但日志、同步、备份和调试通道仍可能把信息带出去。端侧隐私要成立，需要从权限、存储到更新机制一起约束。否则“本地”只是计算位置变了，数据治理没有跟上。
讨论本地推理，最终绕不开一个朴素问题：设备是否在合适的时候做了合适的事。它可以是地铁里的离线转写，也可以是相机快门前的即时处理，但前提是功耗可控、边界清楚、失败时能退回云端。把这些细节处理好，本地推理才会从演示功能变成日常能力。