云端大模型很强，但工业现场并不总有稳定网络。延迟、隐私、带宽和断网后的可用性，会把“模型越大越好”变成一道成本题。

边缘 AI 的目标也不是把完整聊天模型硬塞进控制器，而是让合适的模型在合适的位置完成合适的任务。振动异常检测、仪表读数识别、声音分类和局部控制策略，通常比开放式对话更适合先落地。

先画资源边界

部署前至少要列出内存、存储、算力、功耗、允许延迟和更新方式。模型文件能放进去，不代表推理时的中间张量也能放进去；平均延迟达标，也不代表最坏延迟不会破坏控制周期。

对实时系统来说，我会同时记录 P50、P95 和 P99 延迟，并在温度升高、CPU 抢占和低电量状态下重复测试。实验室里的稳定帧率，未必等于机柜里的稳定帧率。

量化的代价需要测量

INT8、INT4 量化可以降低内存和计算量，但精度损失并不均匀。分类模型可能几乎不受影响，回归、微弱故障特征或多语言生成却可能明显退化。

因此量化不能只看一个综合分数。应该按设备型号、工况和故障类别拆分评测，特别关注原本就稀少的边缘样本。

云边协同通常更现实

一种实用结构是：边缘端完成采集、过滤、快速告警和小模型推理；云端负责长周期分析、模型训练、设备管理与跨站点比较。网络中断时边缘仍能执行核心逻辑，恢复后再同步摘要和关键片段。

这也意味着设备端必须有版本号、回滚和观测指标。模型不是烧录后永远不变的固件，它会遇到数据漂移、传感器老化和环境变化。

控制系统最后仍要有边界

AI 可以给出建议或设定值，但直接接管高风险执行器前，需要限幅、联锁、超时和确定性的降级策略。模型输出应当被看作一个不完全可信的传感输入，而不是天然正确的控制命令。

把 AI 放进设备，真正困难的部分往往不是压缩模型，而是让它在断网、过热、数据异常和版本升级时仍然表现得像一件工程产品。

参考资料：