地铁进隧道，语音助手停顿两秒，然后提示“网络连接失败”。这类瞬间比任何演示都诚实：模型在云端表现再亮眼，信号一断就与用户无关。端侧AI被反复提起，多半也是从这种窘境开始。
被忽略的约束：内存带宽与发热
把模型压缩到能装进手机，是过去两年最直观的进展。量化把权重从十六位压到八位、四位，蒸馏让小模型模仿大模型的输出分布，门槛看起来在下降。但真正卡住体验的往往不是参数量，而是内存带宽和持续功耗。一次推理要在几百毫秒内完成，权重就得反复从内存搬到计算单元，搬运的耗电常常超过计算本身。手机没有风扇，热量积累十几秒后芯片降频，第一秒的流畅和第三十秒的卡顿是两件事。
所以厂商谈端侧AI时喜欢说“支持”，而用户感受到的是“持续”。这两个词之间的距离，是调度策略、算子融合、内存复用这些不够吸引人的工作。我个人更愿意看一台设备连续使用二十分钟后的表现，而不是发布会上的单次演示。
并非所有计算都该留在本地
有一种流行的说法是，端侧意味着隐私更稳妥。方向没错，但需要拆开看。数据不出设备，确实减少了传输环节的暴露面；可本地模型同样会留下日志、缓存和推理中间结果，如果应用层没有相应处理，隐私风险并不会自动消失。把“本地”等同于“安全”，是一种偷懒的推论。
另一头是能力边界。参数规模受限，意味着端侧模型在长上下文、复杂推理、开放域知识上很难与云端对齐。合理的分工更像分层：唤醒、纠错、输入预测、离线可用的小任务放在本地；需要广博知识或重计算的部分交给云端，并且明确告知用户什么时候在联网。用户其实不介意切换，介意的是不知道自己何时被切换。
硬件的账，和开发者的账
芯片厂在NPU上投入很大，算力数字一年一个样。但算力只是上限，能否用满取决于工具链。一个模型从训练框架到设备端跑通，常要经过转换、图优化、算子适配几道关，遇到不支持的算子就退回CPU，速度掉一个量级。这解释了为什么同一个模型在不同设备上表现差异明显，也解释了为什么开发者对端侧的热情总是先高后低。
- 模型转换的坑多，调试成本高于预期；
- 设备碎片化，同一套参数要覆盖多种芯片；
- 效果评估缺少统一口径，离线指标和真实体验对不上。
这些问题不解决，端侧AI就容易停在“能跑”的阶段，而不是“好用”。
我的判断：先做减法
接下来一两年，端侧更可能沿着“窄而深”走，而不是把通用助手整个搬下来。输入法预测、通话降噪、图像语义分割、文档离线摘要，这类任务边界清晰、对延迟敏感、数据敏感度高，放在本地的价值容易算清楚。反过来，凡是需要庞大世界知识的问答，硬塞进设备只会得到既慢又不准的结果。
对做产品的人来说，一个实用的问法是：这个功能断网后还成立吗？如果答案是否定的，那它本来就不该被包装成本地能力。把技术边界说清楚，比漂亮的宣传词更能积累信任。