地铁进隧道，手机信号掉到一格，语音输入却还能把话转成文字。这个瞬间很普通，却解释了端侧AI为什么被反复提起：不是所有计算都值得绕到云端再回来。
过去谈模型，默认它住在数据中心。端侧AI把问题倒过来：模型要先住进一台内存有限、电池有限、散热也有限的设备。于是题目不再只是“模型能不能跑”，而是“跑起来之后，用户还愿不愿意用”。
被忽略的成本：等待与打扰
云端推理的代价常被网速掩盖。请求上传、排队、返回，每一步都可能让交互变慢；在网络不稳的地方，这种延迟会被放大。端侧推理的价值并不神秘，它把一部分确定性留给本地：按键之后立刻有反馈，断网时仍能完成有限任务。对用户来说，这像一种产品礼貌，而不是技术炫技。
但把模型塞进设备，不等于把云端能力原样搬过来。内存带宽、持续功耗、发热降频，都会影响体验。一个模型在演示里流畅，到了口袋里可能因为温度升高而变慢。工程团队要做的取舍很具体：模型小一点，还是输入分辨率低一点；常驻后台，还是按需加载。这些选择没有统一答案，只能贴着场景走。
隐私是理由，但不是全部理由
端侧AI常被拿来谈隐私：数据不出设备，听起来让人安心。这个理由成立，却容易被说成万能答案。本地处理能减少原始数据外传，但模型更新、日志、故障诊断仍可能涉及数据流动。实际的问题是，用户是否知道哪些内容留在本地，哪些需要联网。边界不清，信任就很难建立。
另一个常被低估的点是更新。云端模型可以随时替换，端侧模型却要面对设备型号、系统版本、存储空间的差异。一次更新可能让旧设备变得吃力，也可能让新功能只覆盖一部分人。端侧AI的边界，往往不在算法本身，而在软件分发和长期维护。
先找对任务，再谈规模
端侧适合什么？我倾向于看三个条件：输入在本地产生，反馈需要即时，任务范围相对收敛。比如输入法联想、离线转写、图片去噪、简单分类，这些任务不需要把整个世界传给模型，也不需要模型每次都给出长篇回答。反过来，复杂推理、跨应用调度、需要大量外部知识的任务，通常放在云端完成。
这也意味着端侧AI不该被理解成“云端替代”。一种可操作的形态是分工：本地负责快速、私密、稳定的部分，云端负责重计算和知识更新。两者之间的切换要平滑，用户不必知道请求去了哪里，但能感受到响应是否可靠。
回到开头的隧道场景，真正值得关心的不是模型参数有多大，而是那一次语音输入有没有被稳稳接住。它要赢得的，也不是一句“本地运行”的口号，而是用户在不稳定环境里仍然愿意按下那个按钮。