“模型放云端还是工厂？”往往问得太早。应先问：外部连接中断时，哪一个业务动作必须继续，依赖的数据能保持多久，谁负责恢复。本文的判断是，工业 AI 部署位置应沿着业务连续性的边界划分；同一应用可以本地执行、集中管理、异步分析，不必把全部能力放在一个位置。以下框架与场景属于本文工程分析，不是壹典项目成果。
近期研究提醒：推理框架的优势有明确条件
2026 年 7 月 13 日公开的一项工业视觉研究比较了 PyTorch、ONNX Runtime、OpenVINO 与 TensorRT。它在指定硬件、模型和软件版本下测量批量为一的推理时间，未计入前后处理；其中 CNN 的优化优势没有完整迁移到所测的 Grounding DINO 桌面 GPU 场景。[1] 这是一项特定实验，不是所有边缘模型的排名。
对企业的启示是：新模型或新运行时扩大了候选方案，但采购判断仍应围绕现场动作。相机取图、传输、预处理、推理、规则判断和下游确认组成完整路径。一次模型调用更快，不能自动证明整条路径能在期限内完成。
需要重新审视方案的，尤其是有多条产线、多处工厂或间歇网络连接的企业。单站点演示容易隐藏集中服务中断、现场设备差异和远程维护的问题。边云分工改变的是故障影响范围与维护方式，不能只按单次推理费用比较。
按业务动作划分三个位置
先把必须在短时间内作出、且断网也不能等待的动作列出来。若现场模型与配套规则能够达到要求，可将该动作的完整必要依赖放在设备侧或厂内服务上。需要确定性时限或安全保护的控制功能，应由适用的控制与保护系统承担；AI 给出建议并不意味着它已经具备直接控制资格。
其次是允许等待的现场辅助，例如维修资料解释、班次质量归因和操作建议。这类任务可以使用厂内共享服务，也可在数据条件允许时调用云端。关键是明确无响应时如何继续工作，不能把“稍后重试”留给产线人员临时判断。
最后是跨站点汇总、模型训练、质量复盘和版本管理。它们往往适合集中处理，但这只是有条件的设计建议：若数据不能离厂、上行成本太高，或集中团队缺少维护能力，方案需要调整。这里的边缘包括设备侧与厂内节点，云端指经外部网络访问的集中服务；厂内服务器也可能成为多个工位的共同故障点。
离线能力要检查整个依赖链
Microsoft 的 IoT Edge 文档说明，设备首次同步后可继续离线工作，但消息保留仍受存活时间与磁盘容量限制；断网时，云端显示的状态也可能没有及时更新。[2] 平台提供的离线能力因此不能直接等同于整个 AI 应用可以无限期持续运行。
逐项追问：模型文件是否已经下载，许可证校验是否依赖远程服务，启动是否要拉取镜像，身份校验是否能在允许条件下本地完成，规则与物料信息是否有可用快照。应用正在运行时断网，与断网后重启，属于不同验收情形。
应为每项缓存数据记录有效期和失效后的行为。过期物料规则可能比暂时没有 AI 结果更危险。可选行为包括继续使用经批准的旧规则、转人工复核、降低自动化范围或暂停相关动作，具体选择由业务后果决定。离线运行也要保留身份和权限边界，不能用共享管理账号替代依赖治理。
本地进程存活、模型推理成功、业务动作完成和云端可观察，应分别记录。否则管理页面上的“在线”或“正常”很容易被误当作生产连续性的证据。
构造场景：断网预算与恢复预算是两件事
假设一个工位每秒产生两条必须保留的检查记录，每条连同附件平均占 1 MB，要求容忍两小时外网中断。仅业务记录就会累积约 14,400 MB，即十进制 14.4 GB。该算式没有包含文件系统开销、日志、重试副本、模型文件和备用空间；所有数字均为构造假设，不是设备指标。
还需确定本地存储策略：何时发出容量告警，哪些数据允许按规则采样，哪些记录绝不能删除，写满后哪个业务流程要转入降级。不能先承诺所有原图永久保留，再把有限磁盘当作实现细节。
再假设恢复后可稳定用于回传的有效带宽为每秒 5 MB，新记录仍以每秒 2 MB 产生，且回传没有其他瓶颈。净清理能力只有每秒 3 MB，积压约需 4,800 秒，也就是 80 分钟清空。若可用回传能力不高于持续产生速率，恢复联网并不会让积压自动消失。
这个简化推演忽略波动和协议开销，现场应以实际有效吞吐替换假设。它用于明确两个验收目标：断网能撑多久，联网后能多久恢复完整数据。记录还应包含工件与事件标识、采集时间、模型版本和补传状态，以便区分当时的判断与事后的复盘结果。
模型部署要交付一个可维护的组合
AWS Greengrass V2 将机器学习部署区分为模型、运行时和推理组件，可通过依赖组成部署。[3] 本文据此建议把模型文件、推理代码、运行时、预处理与业务规则作为一个兼容组合管理，而不是只向现场发送新的权重文件。
集中团队应维护已验证的组合与适配范围；现场团队应明确谁能批准切换、谁处理硬盘损坏、谁验证相机和设备接口。远程可更新不等于远程能修复所有故障。多站点部署还要考虑访问窗口、现场支持时差、备件和不同硬件代际。
更新包应先完成下载与完整性检查，再在约定窗口切换；旧版本能否重新启动、旧数据格式能否读取，也要有证据。设备长期离线后重新加入时，不宜同时执行大规模回传和重型更新，避免两者争抢带宽与磁盘。这些是部署策略建议，并非所有平台默认提供的保证。
若任务发生频率低、允许等待、数据可外传且现场没有维护人员，集中托管可能更合理。若关键动作必须在外部网络中断时继续，而且输入规模稳定，本地执行更值得投入验证。边云混合会增加版本与数据同步复杂度，不能仅因架构看起来完整就采用。
把方案比较变成可观察的交付条件
方案评审时固定相同的业务质量要求，分别测试正常网络、外网中断、断网重启、存储接近上限和恢复回传。对每种情况写明允许完成的动作、必须拒绝的动作，以及由谁接手。模型失败和数据过期应进入统计，不能只计算成功响应。
观察从现场输入到业务结果的延迟分布、按期完成比例、本地最旧待传记录的年龄、积压字节数和降级持续时间。按期完成比例的分母是要求在期限内完成的全部任务；积压年龄比单纯“还有多少条”更能暴露长期滞留，但两者应联合查看。
费用也按完整生命周期列出：设备与冗余、部署适配、网络和存储、更新验证、巡检与现场故障处理。不要给断网容忍、数据保留和恢复时限不同的两个方案直接比较单价。对于壹典关注的企业与工业 AI 建设，这种交付边界能把模型选型、数据工程和现场运行责任连接起来，而不需要预设所有客户使用同一种拓扑。