工厂内网 AI 方案：ML.NET 私有化部署全流程

制造业工厂的 AI 落地，永远绕不开「内网物理隔离」这条硬约束：生产网不能连接公网、工艺与质量数据绝对不能出厂区、工控机环境杂且不能随意装软件、现场没有专职算法运维人员。传统云端 AI、Python 推理服务方案，要么过不了数据安全关，要么部署运维复杂度太高，最后大多停留在试点阶段。

ML.NET 原生 .NET 技术栈的特性，恰好命中了工厂内网私有化部署的核心需求：全程离线运行、零额外运行时依赖、数据不出工位、可直接嵌入现有上位机系统、部署运维成本极低。不需要打通公网、不需要安装 Python 环境、不需要搭建集群，普通工控机就能跑，是制造业内网 AI 落地的高性价比方案。

本文完整拆解从模型制备、环境搭建、部署上线、离线迭代到运维管控的全内网闭环流程，所有步骤均可在完全断网环境下落地实施。

一、工厂内网 AI 的核心约束与方案定位

1.1 内网环境的五大刚性约束

绝大多数工厂生产网都有严格的隔离要求，AI 方案必须全部适配：

1. 物理断网：生产网与公网物理隔离，无法在线拉取 NuGet 包、无法在线更新、无法调用云端接口。
2. 硬件异构：工位工控机新老并存，从老旧的 32 位 Win7 机器到新款 Win10 工控机都有，CPU 指令集支持程度不一。
3. 稳定优先：产线 7×24 运行，AI 功能可以降级、可以关闭，但绝对不能导致上位机崩溃、影响生产控制。
4. 数据保密：设备参数、工艺数据、质量图像均为核心涉密数据，不允许传出工厂内网，更不能上传云端。
5. 运维极简：现场只有电气工程师，没有专职算法人员与运维人员，方案必须简单、易排错、能自愈。

1.2 ML.NET 私有化方案的核心优势

对比 Python 推理服务、专用 AI 盒子等方案，ML.NET 原生方案在内网场景下优势非常突出：

• 零额外运行时：自包含发布后直接拷贝运行，不需要安装 Python、Conda、CUDA 等任何依赖环境。
• 全链路离线：训练、部署、推理、迭代全流程都可以在工厂内网完成，不需要连接任何外部服务。
• 侵入性极低：以 DLL 形式直接嵌入现有 C# 上位机软件，不需要新增硬件、不需要改网络架构。
• 技术栈统一：现有工控开发团队就能维护，不需要新增 Python 开发与运维岗位。
• 安全可控：数据全程在本地进程内流转，模型文件可加密、可绑定硬件授权，防止外泄。

1.3 整体私有化架构

整套方案分为三层，全部部署在工厂内网，数据全程不出厂区：

• 工位层：推理完全在本地工控机完成，负责实时采集、实时推理、本地存储，断网不影响生产。
• 厂级层：部署在内网服务器，负责全工厂模型统一管理、数据汇聚标注、离线增量训练。
• 运维层：通过 U 盘等离线介质完成部署、升级、诊断，全程不经过公网。

二、第一步：离线模型制备

模型是 AI 的核心，所有训练与优化工作先在外部环境完成，打包成标准离线包后再导入内网。

2.1 模型选型与训练

工厂内网场景优先选择轻量、CPU 友好、解释性强的模型，不盲目追求大模型：

• 表格类场景（质量预判、异常检测、参数推荐）：优先 LightGBM、随机森林、孤立森林，可直接用 ML.NET 原生训练，也可用 Python 训练后导出 ONNX。
• 视觉类场景（缺陷检测、字符识别、定位）：优先 YOLOv8n、MobileNet 等轻量网络，Python 训练后导出 ONNX 格式。
• 时序类场景（设备健康度、寿命预测）：优先传统时序特征 + LightGBM，尽量不用复杂深度网络。

核心原则：训练可以用 Python，但交付给内网的产物必须是标准 ONNX 或 ML.NET 原生模型文件，现场只做推理，不做训练。

2.2 模型轻量化与量化

工控机 CPU 性能普遍一般，上线前必须做轻量化处理，保证推理速度满足产线节拍：

1. INT8 量化：使用 ONNX Runtime 量化工具将 FP32 模型转为 INT8，体积减少 75%，推理速度提升 2~4 倍，精度损失通常小于 1%，工业场景完全可接受。
2. 裁剪计算图：移除训练相关节点、后处理中不必要的分支，只保留推理必需的算子。
3. 降低输入尺寸：视觉场景只保留 ROI 区域，在满足精度的前提下尽量缩小输入分辨率。

2.3 制作标准离线模型包

不能只拷一个模型文件进内网，必须做成完整的交付包，包含：

打包完成后，计算整体校验码，存入 U 盘等离线介质，准备导入内网。

三、第二步：内网运行环境搭建

工厂内网不能在线拉取 NuGet、不能在线装运行时，所有依赖必须提前打包好，做到「拷过去就能跑」。

3.1 两种发布模式选型

根据工控机环境统一程度，选择对应的发布方式：

方案一：自包含发布（推荐，适配杂环境）

将 .NET 运行时、原生依赖、业务代码全部打包到一起，目标机器不需要安装任何 .NET 环境，拷贝完直接运行。

dotnet publish-cRelease-rwin-x64 --self-containedtrue/p:PublishSingleFile=true /p:IncludeNativeLibrariesForSelfExtract=true /p:EnableCompressionInSingleFile=true

• 优点：零环境依赖，适配 Win7/Win10/Win11 各种系统，老机器也能直接跑。
• 缺点：发布包体积稍大，一般几十 MB 级别，对工厂内网完全可接受。

方案二：框架依赖发布（环境统一时用）

如果全厂工控机都统一安装了对应版本的 .NET Runtime，可以只发布程序集，体积更小。前提是运行时版本必须严格一致，避免版本兼容问题。

3.2 原生依赖与兼容性处理

ML.NET 和 ONNX Runtime 依赖原生 C++ 运行库，老系统容易缺文件，必须提前处理：

1. VC++ 运行库静态打包：将 msvcp140.dll、vcruntime140.dll 等依赖随程序一起发布，不依赖系统安装。
2. 老 CPU 兼容处理：默认 ONNX Runtime 依赖 AVX 指令集，服役 8 年以上的工控机 CPU 往往不支持，启动直接闪退。
   • 解决：程序启动时自动检测 CPU 指令集支持情况，不支持 AVX 则自动加载兼容版运行库。
   • 打包时同时携带Microsoft.ML.OnnxRuntime和Microsoft.ML.OnnxRuntime.MKL或无 AVX 版本，运行时动态切换。

publicstaticboolCheckCpuAvxSupport(){try{returnSystem.Runtime.Intrinsics.X86.Avx.IsSupported;}catch{returnfalse;}}

3.3 离线 NuGet 源制作

如果内网需要二次开发、编译项目，提前制作本地 NuGet 离线源：

1. 在有网环境下载所有需要的 NuGet 包（ML.NET、ONNX Runtime、OpenCvSharp 等）到本地文件夹。
2. 将整个文件夹拷贝到内网服务器，搭建本地 NuGet 源（可用文件共享或轻量 NuGet.Server）。
3. 开发环境配置包源指向本地地址，完全离线即可还原依赖、编译项目。

四、第三步：工位端部署实施

工位级部署是落地的核心，目标是不影响现有生产、不改动原有控制逻辑、AI 功能可随时旁路。

4.1 两种集成方式

方式一：DLL 内嵌式（首选，实时性最高）

将 ML.NET 推理能力封装成标准 .NET 类库 DLL，直接引用到现有上位机软件中，和业务逻辑同进程运行。

• 优点：零网络开销、延迟最低、部署最简单、不新增进程。
• 适用：单工位独立推理、实时性要求高的场景，如质量实时检测、设备异常预警。

核心封装示例：

/// <summary>/// 推理服务接口，上位机只依赖接口，不感知实现/// </summary>publicinterfaceIQualityInferenceService{boolIsReady{get;}stringCurrentVersion{get;}QualityPredictionPredict(QualityInputinput);boolUpdateModel(stringmodelPackagePath);}

方式二：本地服务式

将推理引擎封装成 ASP.NET Core Web 服务或 Windows 服务，在本机通过 HTTP 接口供上位机调用。

• 优点：解耦性好，上位机语言不限制（C++/Delphi 也能调用），多模块共用一个推理服务。
• 适用：一个工位有多套软件共用 AI 能力，或者上位机不是 .NET 技术栈的场景。

4.2 标准化部署步骤

所有工位统一按以下步骤操作，避免遗漏：

1. 环境预检：运行预检工具，检查 CPU 指令集、系统版本、内存磁盘、依赖库是否齐全，输出检测报告。
2. 文件拷贝：将发布包拷贝到工控机非系统盘目录，避免还原系统后丢失。
3. 基准测试：首次运行自动执行基准样本测试，对比输出与预期结果，误差在允许范围内才算部署成功。
4. 权限配置：配置程序开机自启、运行权限，添加杀毒软件白名单，避免被误杀。
5. 旁路验证：先开启观察模式，只记录结果不参与控制，运行 24 小时无异常再逐步开放功能。

4.3 资源隔离与优先级控制

工控机的核心资源要优先保障采集与控制，AI 推理不能抢资源：

• 线程优先级：推理线程设置为BelowNormal，CPU 满载时优先让位给控制线程。
• CPU 亲和性：将推理线程绑定到指定 CPU 核心，避免干扰实时控制线程。
• 内存上限：设置内存占用阈值，超过阈值自动释放缓存、触发降级，绝对不能把工控机内存跑满。

五、第四步：离线模型更新与回滚

模型迭代是常态，但工厂不能随便停机更新，必须支持不停产热更新、一键回滚。

5.1 离线升级包导入流程

1. 厂级训练环境生成新版本模型包，计算校验码，拷贝到专用运维 U 盘。
2. U 盘插入工位工控机，运维工具读取升级包，校验完整性与版本合法性。
3. 后台静默加载新模型，运行基准测试，验证通过后进入待切换状态。
4. 生产间隙（如换班、换料）执行原子切换，瞬间完成版本切换，业务无感知。
5. 旧版本保留至少 3 个稳定版，随时可以一键回滚。

5.2 热更新核心实现

使用读写锁 + 双实例方案，切换过程毫秒级，不阻塞正在执行的推理：

publicboolHotUpdate(stringnewModelPath){// 1. 后台加载新模型varnewEnginePool=CreateModelPool(newModelPath);// 2. 基准校验if(!ValidateBenchmark(newEnginePool)){newEnginePool.Dispose();returnfalse;}// 3. 原子切换引用_rwLock.EnterWriteLock();try{varoldPool=_currentPool;_currentPool=newEnginePool;CurrentVersion=newVersion;// 4. 延迟释放旧实例，等待存量请求结束_=Task.Delay(TimeSpan.FromSeconds(60)).ContinueWith(_=>oldPool.Dispose());}finally{_rwLock.ExitWriteLock();}returntrue;}

5.3 灰度与回滚机制

• 灰度放量：新版本先在 1~2 个试点工位运行 3 天，效果达标再逐步推广到全产线。
• 自动回滚：新版本运行中如果错误率飙升、输出分布异常，自动切回上一个稳定版本，同时触发告警。
• 人工回滚：操作人员可以随时在界面上一键切回旧版本，不需要找开发人员。

六、第五步：内网数据闭环与模型迭代

模型上线不是终点，现场工况会变化（设备磨损、原料批次、季节温湿度），模型效果会缓慢衰减，必须建立内网闭环迭代机制。

6.1 本地样本自动留存

工控机端自动采集两类样本，本地存储：

• 边界样本：推理置信度在阈值附近的模糊样本，人工标注价值最高。
• 异常样本：人工复核过的误检、漏检样本，是模型优化的核心数据。

样本数据（参数、图片、标签）全部存在本地 SQLite 数据库，只存原始数据，不向外传输。

6.2 离线数据汇聚与标注

定期（每周/每月）将各工位的样本数据通过离线介质导出，汇总到厂内标注服务器：

• 由工艺人员、质检人员在内网标注工具上完成标注，不需要算法人员参与。
• 标注完成的数据集存入内网样本库，按版本管理。

6.3 内网增量训练

在内网训练服务器上完成模型迭代，全程不联网：

• 基于上一版模型，用新样本做增量训练，不需要从零开始。
• 训练完成后自动跑测试集，指标达标则生成新版本模型包。
• 按前述离线升级流程下发到各工位，完成一次迭代闭环。

整个过程从数据产生、标注、训练到下发，全部在工厂内网完成，数据零流出。

七、生产级运维与安全保障

7.1 全本地可观测体系

不需要云端监控平台，所有监控能力本地实现：

• 本地状态面板：上位机集成 AI 状态页，实时显示推理速度、成功率、版本号、异常计数。
• 本地日志系统：所有推理日志、异常日志、操作日志全部本地留存，保留至少 3 个月，支持离线导出排查。
• 声光告警：AI 模块异常、模型效果漂移、资源占用过高时，通过工位现有声光报警器通知现场人员。

7.2 多级容错降级机制

严格遵循「AI 不影响生产」原则，设计四级退守：

1. 单次推理失败 → 自动重试，返回兜底值。
2. 连续失败超阈值 → 自动切换为传统规则判定，AI 后台静默重试。
3. 模块严重异常 → 自动旁路 AI 功能，产线按原有纯人工/纯 PLC 模式运行。
4. 紧急情况 → 操作人员一键关闭所有 AI 功能，完全恢复改造前状态。

7.3 安全与授权

• 模型加密：模型文件加密存储，运行时内存解密加载，防止被直接拷贝盗用。
• 硬件授权：绑定工控机 CPU + 硬盘指纹生成机器码，离线生成授权文件，不依赖网络激活，防止模型跨厂滥用。
• 数据脱敏：本地留存的样本数据自动脱敏，去除敏感工艺参数标识，降低数据泄露风险。

八、高频踩坑与避坑指南

坑1：老工控机启动直接闪退，无任何报错

• 原因：CPU 不支持 AVX 指令集，ONNX Runtime 默认版本加载失败。
• 解决：启动时先检测 CPU 指令集，不支持自动切换兼容版运行库；部署前用预检工具提前筛查。

坑2：U 盘拷贝模型文件损坏，推理结果完全错乱

• 原因：大文件拷贝过程中断电、U 盘坏道，导致模型文件部分损坏。
• 解决：升级包必须带 SHA256 校验码，加载前先校验完整性；校验不通过直接拒绝加载，提示文件损坏。

坑3：内网系统时间不准，授权失效

• 原因：很多工控机不连外网，系统时间不准，导致基于时间的授权失效。
• 解决：采用纯硬件指纹授权，不依赖系统时间；授权有效期设置足够宽，避免时间跳变影响生产。

坑4：杀毒软件误杀程序文件

• 原因：工业现场杀毒软件规则严格，单文件发布容易被误判为病毒。
• 解决：提前将程序目录加入白名单；必要时使用非单文件发布，减少误判概率。

坑5：多工位批量部署效率低

• 原因：几十上百个工位逐个拷贝、配置，工作量大且容易出错。
• 解决：制作一键部署脚本，自动完成文件拷贝、权限配置、基准测试、注册服务；支持内网批量下发。

九、方案落地价值总结

1. 安全合规：全流程内网闭环，数据不出厂区，满足制造业数据安全与等保要求。
2. 成本极低：不需要新增服务器、不需要采购专用 AI 硬件、不需要新增运维岗位，复用现有工控机与开发团队即可落地。
3. 稳定可靠：多级容错、热更新、一键回滚，完全适配工业 7×24 运行场景。
4. 自主可控：从模型到代码全部自主掌握，不依赖外部厂商、不依赖云服务，不会被卡脖子。

对于大量存量制造业工厂来说，AI 落地不一定要搞大平台、大项目。用 ML.NET 这种轻量化原生方案，从单个工位、单个场景切入，小步快跑、快速迭代，反而更容易落地出实际价值。