地铁里没有信号，语音转写仍要可用；摄像头拍到敏感画面，希望数据不出设备；车载系统在隧道里也要对指令做出反应。这些设想听起来像同一个需求，拆开后却指向不同约束：算力、功耗、时延、存储、更新，以及出问题时谁来负责。
把模型放进设备，并不等于把云端能力原样搬过去。模型文件大小只是账面数字，运行时还要占内存、缓存中间结果、留出系统余量。设备一旦发热，频率会下降，响应就会抖动；电池容量有限，持续推理会挤占续航。端侧AI的门槛不在演示时能否跑通，而在长时间运行后是否仍然稳定。
资源账本不是参数表
讨论端侧模型时，人们容易盯着参数规模，却忽略内存带宽和算子适配。一个模型在开发机上顺畅，到了不同芯片、不同系统版本上，可能因为缺少算子支持而退回CPU，速度立刻变化。量化、剪枝、蒸馏能减轻负担，但也会改变输出风格和边界表现。工程上要做的是把模型、芯片、系统调度放在一起看，而不是只看单次推理耗时。
离线价值有前提
端侧AI常被赋予两个理由：隐私和低时延。它们都成立，但都有前提。数据留在本地，不代表它不会被日志、缓存或调试接口带出去；低时延也不只取决于模型，输入采集、预处理、后处理同样占时间。若设备在弱网下频繁重试云端请求，本地推理的确定性才会显出价值。判断一个功能该不该放到端侧，可以先问：断网时它是否仍要工作，数据是否敏感，响应是否必须稳定，以及本地资源是否长期够用。
更新与责任不能外包
端侧设备一旦铺开，模型更新就变成长期问题。不同型号、不同系统版本、不同硬件配置会让灰度发布变得复杂；更新失败要能回滚，旧模型要能兼容，线上表现要有可观测指标。麻烦的是责任边界：当本地模型给出错误建议，日志在设备上，问题复现和归因都更困难。把模型推到端侧，不能把评估和兜底一起推掉。
我并不认为端侧AI会取代云端推理。现实中的形态常常是分工：需要即时响应、数据不便外传、网络条件不稳定的任务放在本地；需要长尾知识、复杂推理和集中更新的任务留给云端。端侧AI的价值不在于“全部在本地”这句口号，而在于让设备在受限条件下仍能做出可预期的反应。边界划清楚，演示才能变成可维护的产品。