当前位置：首页 > news >正文

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

news 2026/8/7 10:57:47

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

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

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

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

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

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

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

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 性能普遍一般，上线前必须做轻量化处理，保证推理速度满足产线节拍：

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

2.3 制作标准离线模型包

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

文件	作用
`model.onnx`/`model.zip`	模型本体（ONNX 或 ML.NET 序列化管线）
`model_meta.json`	元数据：版本号、训练时间、适用工位、输入输出规格、特征口径
`benchmark_samples.bin`	基准测试样本 + 预期输出，用于上线前校验
`checksum.sha256`	文件完整性校验码，防止拷贝损坏
`readme.txt`	部署说明、参数阈值、注意事项

打包完成后，计算整体校验码，存入 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++ 运行库，老系统容易缺文件，必须提前处理：

VC++ 运行库静态打包：将 msvcp140.dll、vcruntime140.dll 等依赖随程序一起发布，不依赖系统安装。
老 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 离线源：

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

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

工位级部署是落地的核心，目标是不影响现有生产、不改动原有控制逻辑、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 标准化部署步骤

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

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

4.3 资源隔离与优先级控制

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

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

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

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

5.1 离线升级包导入流程

厂级训练环境生成新版本模型包，计算校验码，拷贝到专用运维 U 盘。
U 盘插入工位工控机，运维工具读取升级包，校验完整性与版本合法性。
后台静默加载新模型，运行基准测试，验证通过后进入待切换状态。
生产间隙（如换班、换料）执行原子切换，瞬间完成版本切换，业务无感知。
旧版本保留至少 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;}