电梯里信号只剩一格，语音助手还在等云端返回；会议室的网络被临时限速，录音转写进度条停住。用户不会关心计算发生在哪，只会问：为什么刚才还能用，现在不行。端侧AI被反复提起，背后其实是这个朴素问题——当连接不再可靠，设备能不能自己完成一部分事。
先别问模型多大，先问现场允不允许
把模型放进手机、电脑或车载设备，听上去像把云端能力搬下来。实际落地时，约束条件立刻变多：内存要留给系统和其他应用，电池不能掉得太快，机身发热不能被用户明显感知，模型还要在有限算力上稳定响应。于是“能跑起来”和“愿意天天用”之间，隔着一段很长的工程距离。
本地计算的第一层价值，往往不在参数规模，而在响应路径变短。语音唤醒、输入法联想、照片去噪、会议录音的初步转写，这些任务对时延敏感，也对隐私敏感。数据不必每次都离开设备，体验就少了一次往返。但这也意味着，设备端的模型必须学会在资源紧张时做取舍，而不是把所有能力原样复刻。
断网可用，不等于所有任务都该本地扛
有些任务适合放在本地：固定格式的文本整理、常见指令识别、离线字幕的初步处理、对已下载资料做检索。它们输入输出相对明确，错误成本可控，用户也能感知到即时反馈。另一些任务则更适合与云端配合，比如需要广泛世界知识、复杂推理或持续更新内容的请求。硬把这类任务塞进设备，可能出现等待更久、结果更短、发热更明显的情况。
所以讨论端侧AI时，容易忽略一个边界：它不是云端的替代品，而是一套任务分配方式。设备先判断哪些事能自己做，哪些事需要联网，哪些事可以先给一个可用草稿、再等网络恢复后补全。这个判断逻辑做得好，用户看到的是“一直在线”；做得不好，用户看到的是“功能变少了”。
体验的账，要按一整天的使用来算
演示环境里，模型回答一次问题就能赢得注意。真实使用中，用户会连续唤醒、反复修改、在低电量下使用、在夏天户外使用。本地计算的体验账本因此变得具体：首次加载要多久，连续使用会不会明显发热，内存占用会不会让其他应用被后台清理，模型更新会不会悄悄占满存储。这些问题不显眼，却决定功能会不会被关掉。
对产品团队来说，评估方式也需要换一换。只看单次推理速度，可能漏掉长时间使用的稳定性；只看模型准确率，可能漏掉弱网下的任务完成度。更实际的观察是：在网络不稳定、设备电量不高、用户连续操作的情况下，这个功能还能不能给出可理解的反馈。端侧AI真正的门槛，常常藏在这些不漂亮的日常里。
把边界说清楚，比把能力说满更重要
端侧AI不会让所有设备突然变聪明，它更像是在局部补上一段可控的计算能力。适合它的场景通常有几个共同点：任务边界清楚、对时延或隐私有要求、离线时仍能提供基础价值。超出这些条件，云端协同仍然合理。产品说明里把“离线可做什么、联网后增强什么”讲明白，比笼统宣称“本地大模型”更能建立信任。
用户最终记住的，不是模型跑在哪，而是断网那一刻功能有没有掉链子。它要回答的，也正是这个具体问题：在连接不可靠的时候，设备能不能稳稳接住那部分该它接住的事。