一位做质检的朋友给我看他们的新产线：摄像头对准流水线上的零件，屏幕上框出划痕位置，全程没有联网。我问他为什么不用云端算力，他说得很直接——一次拍照到结果返回，走公网要几百毫秒，碰上网络抖动就是几秒，产线等不起，而且照片里有客户的工艺细节，传出去还得先过合规流程。
这类理由正在把越来越多的推理任务从机房拉回设备本身。端侧AI说的不是某个具体的模型，而是一种部署选择：把训练好的模型压缩、量化、适配到手机、摄像头、车载盒子或工控机上，让判断在本地完成。
延迟与数据，是两笔绕不开的账
把计算放到云端的逻辑曾经很顺：算力集中、成本摊薄、模型随时更新。但这个逻辑建立在两个前提上——网络足够可靠，数据足够不敏感。当设备数量从几亿涨到几百亿，两个前提都在松动。
延迟是第一道硬约束。自动驾驶的紧急制动、AR眼镜的实时跟踪、工厂里的机械臂避障，都属于“算得完但传不回来”的场景。链路往返的时间比推理本身还长，云端再快也没用。
数据是第二道。端侧AI最容易被忽略的价值，不是快，而是数据可以不出设备。语音助手在本地唤醒、相册在本地识别人脸、会议耳机在本地做降噪，这些功能如果每次都要上传，用户未必同意，厂商也未必敢长期承担存储和审计的成本。
真正的难点不是“塞进去”，而是塞进去之后
把一个几十亿参数的模型放进功耗几瓦的芯片，工程上有很多办法：低比特量化、剪枝、知识蒸馏、算子融合。但压缩只是开头，麻烦在后面。
- 精度会掉。量化到某个位宽之后，某些任务的准确率开始明显下滑，需要针对具体场景重新校准，而不是拿通用指标交差。
- 内存比算力更紧张。带宽和存储往往先成为瓶颈，模型结构要为访存做妥协。
- 设备是异构的。同一款应用要在不同厂商的芯片上跑，调度方案和算子支持各不相同，移植工作量常被低估。
- 更新很麻烦。云端改一行配置就能全量生效，端侧要面对版本碎片、灰度周期和用户是否愿意升级。
所以我一直觉得，讨论端侧AI时只谈“能不能跑”意义有限，更该问的是“跑起来之后，维护这套东西的成本有多高”。很多项目不是死在第一版，而是死在第二年的迭代上。
混合架构可能才是常态
把端侧和云端对立起来，是一种偷懒的叙事。现实里更常见的是分工：高频、轻量、涉及隐私的推理留在本地，复杂生成、长上下文理解、需要全局知识的任务交给云端。手机上的输入法预测、拍照优化大多在本地完成，而一次长文档总结仍可能走服务器。
这种分工带来的新问题是策略如何决定。路由逻辑本身要轻、要稳，还得考虑电量、温度、当前网络质量。用户不希望看到“正在连接服务器”的转圈，也不希望设备因为一次本地推理就发烫。体验的一致性，往往比单项指标的漂亮更影响口碑。
另一个被反复提及的顾虑是安全。模型放在用户手里，就意味着权重、提示词和推理过程都可能被逆向。端侧AI并不天然更安全，它只是把攻击面从服务器转移到了设备。对真正敏感的业务，加密和可信执行环境仍要单独设计。
它适合解决什么，不适合解决什么
我的判断偏保守：端侧AI会稳定占据“实时性敏感、数据敏感、任务边界清晰”这一块，比如视觉检测、语音唤醒、传感器异常识别、离线翻译。这些任务的共同点是输入输出明确，模型规模可控，出错代价可以被兜住。
而需要大参数、强泛化、频繁更新知识的任务，短期内仍会留在云端。硬把后者搬到设备上，通常换来的是体验缩水，而不是体验升级。
那位做质检的朋友最后说了一句话，我觉得比很多技术宣讲都准确：他们真正买的不是“AI”，而是一台不需要联网也能稳定判断的机器。端侧AI的意义大概也在这里——它不制造新奇观，只是让计算回到该在的地方。