制造超算AI项目实践：需求转化、架构落地与系统调优全记录

项目的起因其实很朴素。

我在某精密制造集团做架构师时，接手了一个被内部称为“制造超算AI项目”的平台建设任务。业务方没有给我标准的 PRD，也没有技术需求清单，只是在大会议室里说了几句：“产线智能化喊了好几年，今年想动真格。希望 AI 能自动识别缺陷、预测设备什么时候出问题。预算可以批，但要快，明年这个时候我要看到效果。”

架构师听到“看效果”三个字，往往就会会心一笑：这四个字是所有需求转化的起点，也是所有技术债务的起点。我负责的不只是写几行模型代码，而是把一个模糊的业务期望，翻译成一套可论证、可度量、可交付的工程系统。中间隔着产线数据采集、标注体系、算力选型、分布式训练、边缘推理、车间网络、运维保障等一长串环节。任何一个环节处理不好，“看效果”就会变成“看事故”。

这篇文章是我参与这个项目的完整过程记录。项目代号记为 X-600，场景是精密制造车间的 AI 视觉质检与设备预测维护，但这个套路几乎适用于大多数制造超算 AI 项目：先做需求转化，再做架构落地，最后在数据、算力与业务价值之间反复打磨。文章适合两类人看：一类是要从零搭建制造 AI 平台的架构师或技术负责人，另一类是正在做需求评审、但苦于“业务说不清、技术听不懂”的项目经理。

1. 制造超算项目的需求源头：到底该听业务说什么

1.1 一句“想用 AI”背后的真实痛点

我刚入场时，被安排了连续几场需求访谈。访谈对象包括车间主任、质检负责人、设备维护工程师，还有两位“眼睛毒得很、能一眼看出模具裂痕”的老师傅。

访谈第一天，车间主任提了三个要求：缺陷检测要够快，检测结果要能直接对接产线系统，以后挪到新产线也能用。

这三个要求听起来非常合理，但每一条都藏着坑。“够快”到底多快？人工检测一件产品大约需要 3 秒，AI 如果能做到 0.5 秒，是不是就满足了？如果产线节拍是每 2 秒出一件产品，0.5 秒确实卡在节拍之内。但现场的实际情况是，检测一个产品需要多角度拍照，单个工件不是 1 张图而是 6 张图，总处理时间一下子就变成了 3 秒。这时候再谈“0.5 秒”，完全是个伪命题，必须把口径改成“从收到全部图像到返回检测结果小于等于 1 秒”。

设备预测维护也是一样。业务方嘴上说“希望提前知道设备会坏”，但产线现场的 PLC 点位、振动传感器、工艺参数日志，有的根本没采集，有的采集了但时间口径不统一。设备维护工程师给我的是一堆纸质点检记录表，上面的信息是“这台机器上周三异常了一次，换了个继电器”。这种数据质量根本支撑不了“提前多少小时预测”这种要求。

这个阶段我最重要的工作不是听会议纪要，而是到现场蹲点。带一个笔记本，把每台设备的传感器位置、相机角度、触发方式、数据流向全部记下来。需求转化一旦脱离现场，后面设计的架构就一定会脱离现实。

1.2 把业务语言翻译成工程指标的三个案例

需求访谈结束后，我把所有“业务语言”整理成一张表，一栏一栏地翻译成“工程指标”。这一步看起来简单，实际上是最考验架构师经验的地方。

为什么每个指标都这么较真？因为“漏检率 ≤ 2%”和“故障前提前 48 小时”这两个数字，决定了后面所有投入资源的等级。漏检率要求越高，就需要采集越多人眼都难识别的边角案例，数据标注成本翻倍，模型迭代周期拉长。误报率 ≤ 15% 则意味着算法不能走极端，必须考虑设备本身状态的波动性。

工程指标定完，我还会故意问业务方一句：这些数字是从哪里来的？是拍脑袋定的，还是历史统计出来的？质检漏检率如果逐年有统计，那就按统计走；如果没有统计，就需要先花两周做人工复检小样本测试，把历史漏检率估算出来。我不怕业务方拍脑袋，但怕他们把拍脑袋的数字当成铁律，最后变成项目验收时互相扯皮的依据。

这里面还有一个容易被忽略的动作：每个工程指标后面，必须写清楚“验收时怎么看”。单工件分析时间用哪个工具测？整机漏检率抽多少样本？设备预警提前 48 小时是从报警时间到故障时间，还是设备经理确认故障的时间？指标定义清楚，验收才不用吵。

1.3 边界比范围更重要：先学会说“不”

需求转化最容易失控的地方，不是“不满足”，而是“全都要”。我们原计划做视觉质检加设备预测，业务方后来提了一句“顺便把排产优化也做进去”，又提了一句“最好生产经理在手机上看实时看板”。

作为架构师，我做了几件事来守住项目边界。

第一，试点产线只选一条。优先选择节拍稳定、数据采集条件较好的车间。如果一开始铺三条产线，光是相机点位、网络布线和设备对接就够把一个团队拖崩。

第二，排产优化暂时不做。排产优化需要大量历史订单数据，还涉及到计划部门复杂的约束条件，目标函数本身都很难建模。贸然做进去，项目周期至少翻一倍。

第三，手机看板只展示质检结果统计，不做实时视频流。车间网络环境复杂，实时视频流对带宽和延迟的敏感度都很高，架构复杂度会显著上升。

但“拒绝”不是把需求丢回去，而是要给替代方案。我当时给业务方的承诺是：排产优化暂时不启动，但平台的数据层会保留订单数据的接入接口，以后想加不会推倒重来；手机看板先做统计报表，实时视频流等试点跑通后再作为二期增强包评估。

这种“暂时不做、但留好接口”的答复，比冷冰冰的“这个不归我们做”更容易让对方接受。项目边界本质上不是一堵墙，而是双方对投入和回报的共同承认。

2. 架构落地前，选型拆解要算清哪些账

需求转化完成之后，才进入真正的架构落地。这一步有一个常见误区：把选型当成“选最贵的设备”。尤其是制造超算项目，一说要建 AI 平台，采购第一反应就是堆显卡。真正有经验的架构师，会把算力、网络、存储、调度这四个层面分开算账。

2.1 算力底座：训练集群与推理设备的配置思路

制造超算 AI 项目通常有两种算力形态：一种是训练算力，一种是推理算力。很多人只盯着训练算力，结果推理环境稀烂，项目最终照样跑不起来。

训练算力我当时的配置选择是：先按 4 台训练服务器起步，每台 8 张加速卡，CPU 128 核，内存 512GB，通过高速 RDMA 网络互联。为什么是 4 台？因为视觉检测模型从预训练模型微调起步，参数量在中型规模，单机 8 卡已经能跑通小批量数据，4 台是为了留出分布式训练和多团队并行实验的空间。网络必须用 RDMA，不是普通千兆万兆以太网堆在一起就完事。数据并行训练时，每轮迭代都要做梯度同步，网络是最大的卡脖子点，网络带宽上不去，加再多卡都是纸面算力。

推理算力则分了两路。一路是产线边缘的在线检测，使用工业级工控机加单块推理加速卡，模型做定点化压缩，保证单工件延时达标；另一路是夜间的离线批量分析，直接复用训练集群的空闲算力，不用额外采购一批专门的推理服务器。

存储层面，我选择了一套并行文件系统作为中心存储，容量按一个月的训练数据量估算，聚合带宽按训练时多节点并发读取的峰值计算。这里有一个常见错误：只看容量不看带宽。如果几十个训练进程同时从存储读小图片，带宽不够照样把训练拖死。

2.2 平台层：调度器、容器与数据管道的分工

平台层的架构设计，核心是不让训练任务和推理服务打架。我的做法是引入两套队列：离线训练队列和在线推理队列，通过调度器做资源隔离。

训练队列里跑的是分布式训练任务，特点是耗时长、资源吃满、可容忍排队。推理队列里跑的是常驻服务，特点是 24 小时在线、延迟敏感、不能随便被任务抢占。调度器配置好之后，即使训练任务把 GPU 占满，也不会影响产线的实时检测结果。

容器化是制造场景里最容易被低估的一环。模型训练依赖的深度学习框架版本、代码库、系统库，一旦有一点点版本不一致，就会出现“在我机器上能跑”的情况。我要求所有训练和推理环境都做成镜像，镜像仓库统一管理，每次业务变更只动镜像版本，不手动改系统依赖。这个动作一开始会觉得很繁琐，但到了项目后期，它节省的时间远超前期投入。

数据管道分为三块：采集、清洗、版本化。采集负责从相机、PLC、MES 系统实时拉数据；清洗负责把图像去重、格式统一、时间对齐；版本化负责把每一批训练样本打上版本号。训练样本是可迭代资产，没有版本管理，模型复现就是一句空话。

2.3 数据层：制造数据“脏乱差”的解法

制造数据比互联网数据的脏乱差程度高得多。互联网数据的核心问题是量大，制造数据的核心问题是口径杂、脏、乱。

先说图像数据。产线相机分辨率、光源角度、产品摆放位置都会变，同一个缺陷在不同光线下看起来完全不同。我必须把“图像采集规范”定死：相机分辨率统一、拍摄距离固定、光源亮度由程序自动校正。否则今天采集的数据能训练出 90% 准确率的模型，明天换一批数据就只有 60%。

再看时序数据。各设备 PLC 采集频率不一致，有的每 100ms 一个点，有的每秒一个点，还有的只在变化时才记录。做设备预测前，先要做时间对齐和缺失值处理。这一块没有捷径，只能一条设备一条设备核对，把所有点位的数据字典建起来。

最后讲业务标签。缺陷标签是由质检员人工标的，不同人标准不一致。同一个划痕，A 质检员标为“轻微划痕”，B 质检员标为“可接受”。我建了一套标注规范加仲裁机制：两个人标不一致的样本进入争议池，由老师傅做最终仲裁。这个过程看起来慢，但实际上极大降低了模型的错误学习概率。

数据治理做得越细，后面模型训练的效率就越高。制造超算项目的底座，不是算力，而是数据。

3. 从原型验证到生产闭环的落地节奏

3.1 原型阶段：6 周打通端到端的最小链路

架构落地最忌讳一上来就铺几十台服务器，然后把项目排成半年的瀑布计划。我习惯先做一个最小可运行版本（MVP），拿一小批真实产线数据把整条链路端到端跑通。时间窗口我给自己卡了 6 周。

第一周做数据采集和盘点，从相机的图像流里连续采集多天的样本，同时记录真实生产节拍和相机触发频率。第二周做标注规范，先标注几千张样本，把类别定义清楚，制作第一版标注字典。第三周训练基线模型，不做任何复杂优化，用现成的预训练模型微调，目的是把训练流程、指标口径跑顺。第四周做边缘推理 Demo，把压缩后的模型放进边缘工控机，模拟产线的图像输入方式，验证单张图的延迟是否达标。第五周和第六周做接口联调和灰度试运行，把检测结果写入测试环境，和模拟 MES 系统对接。

这 6 周里，没有任何一个模块是“完美”的，但每条边都已经跑通。这样做有一个巨大好处：业务方能在很短时间内看到实物反馈，而不是听一堆技术汇报。他们发现模型在某个缺陷类别上的误报偏高时，会主动坐下来讨论要不要调整光源，这比在需求评审会上争辩指标有意思得多。

原型阶段结束，我会明确告诉业务方：现在的系统是一个可以演示的骨架，不是一个可以全面上线的系统。别急着宣布胜利，接下来的迭代才是真正考验。

3.2 分布式训练：数据并行与资源配额怎么设计

当数据规模从数千张扩展到数十万张，单机 8 卡已经不够，就要做分布式训练。最常用的是数据并行：每个计算节点持有模型副本，每个批次的数据被切分到不同节点，正向和反向计算在各节点跑完后，通过梯度同步把参数保持一致。

我在工程上先解决的是数据加载问题。很多人一上来就调通信库，发现性能还是上不去，最后定位到是 DataLoader 的问题。这里我给一个典型的训练数据加载配置，就是要把num_workers、prefetch_factor、persistent_workers这些参数都调对：

train_loader = DataLoader( dataset, batch_size=32, shuffle=True, num_workers=8, prefetch_factor=4, pin_memory=True, persistent_workers=True, )

num_workers决定用多少个进程并行读数据，prefetch_factor决定每个进程提前预取多少个批次，pin_memory把数据放在锁页内存以加快 GPU 拷贝。这套配置在大多数视觉任务里都可以作为起点。

训练任务通过调度器提交，我给一个典型的提交脚本示例：

#!/bin/bash #SBATCH --partition=training #SBATCH --job-name=vision_baseline #SBATCH --nodes=4 #SBATCH --ntasks-per-node=8 #SBATCH --gres=gpu:8 #SBATCH --time=24:00:00 #SBATCH --chdir=/workspace srun python train.py --config configs/baseline.yaml

分布式训练的几个关键点，我踩完之后印象非常深。第一是混合精度训练。视觉模型在中大规模分布式训练里，用混合精度能显著减少显存占用和通信量，但要注意收敛稳定性，必要时设置动态损失缩放。第二是 checkpoint 和断点续训。训练一个模型如果跑一天，中途网络抖动或节点故障，没有断点续训就只能从头再来，这是最让人崩溃的事。第三是资源配额，训练任务和在线推理任务必须分开队列，并给推理队列设置更高优先级。

3.3 推理闭环：在线检测与离线批量的双轨设计

制造场景的 AI 落地绝不只一个模型。真正上线以后，我看到系统实际上是两条轨道并行。

在线检测轨：每件产品经过相机位时，触发拍照，图像数据通过消息队列进入推理服务，服务把结果返回产线系统。这一轨要求的指标是延迟和稳定性，任何单点故障都不能拖停产线。我做了故障降级机制：检测服务异常连续超过指定次数后，系统自动切换回人工复检，宁慢不能漏。

离线批量轨：每天晚上训练集群空闲下来，对当天采集的批量数据做二次筛查，把在线检测时被判定为轻微异常但未拦截的样本再全部过一遍。这样做能把漏检率再压一个量级，同时还能每天自动生成新的困难样本集，回灌到训练集里。

这两条轨共享同一个样本库和模型注册中心。在线检测发现的新情况，离线批量筛查挖掘出的新特征，最终都会回流到数据管道，变成下一轮模型迭代的数据源。这就是一个“数据-模型-业务”的闭环，越跑数据越顺手。

闭环设计里还有一个必须考虑的事：业务方后来发现新增了一种缺陷类型，希望快速支持。因为架构里预留了模型服务多版本切换能力，我们只用两周就把新检测项加进去了。如果当初把模型和业务逻辑绑死在一起，这个改动至少要拆掉半个系统。

4. 制造超算项目踩坑实录：问题、排查与调优

4.1 GPU 利用率上不去的根因排查

项目上线后，第一次在 4 机 32 卡上跑正式训练，我发现 GPU 利用率只有 30% 左右。这个现象非常有迷惑性：看起来 AI 在“跑”，但算力被浪费了一半以上。

我的排查思路是自上而下一层层剥。先用nvidia-smi看 GPU 利用率和显存占用，发现利用率低但显存不高，说明模型没有在满负荷计算；再看 CPU 和内存，发现 CPU 占用很高，部分计算节点 CPU 已跑满；接着看 IO，用系统监控工具一看，存储 IO 等待时间长，大量训练进程卡在读数据上。

根因出来了：数据加载是瓶颈，不是通信，也不是存储本身不够快，而是每个 GPU 进程只配了很少的加载线程，且没有做预取缓存。我们还没决定重新买存储，只是把加载配置从num_workers=4改成num_workers=16，把每个节点的本地缓存目录打开，让训练数据优先命中本地 NVMe 盘。这组参数调整后，GPU 利用率直接升到接近 85%。

GPU 利用率排查有一个经验：不要一上来就怀疑网络和通信库。90% 的情况是数据加载的某个参数没调好。调模型前先调数据管道，这句话值得贴在工位上。

4.2 在线推理抖动：一个请求被拖慢的真相

在线检测上线后，产线侧反馈最尖锐的问题是：单张图平时很快，但一到高峰期整条链路就卡，P99 时延从 200ms 涨到 1.5 秒，某些请求还会超时。

第一个原因是并发请求不均匀。产线节拍并不是绝对匀速的，上下游一卡壳，瞬间会积压多件产品，触发多个相机同时拍照。而推理服务最初是请求到达一个才处理一个，没有做队列管理。我改成带缓冲的消息队列加动态批处理，把同一毫秒内到达的请求合并到一个批次里推理。这样单张图的平均耗时没变，但整体吞吐大幅提升。

第二个原因是图像预处理吃掉了大量耗时。最初的预处理脚本在应用层做了大量像素操作，比如分辨率归一化、白平衡校正、对比度增强。这些操作如果在 CPU 上串行执行，耗时会达到甚至超过模型推理。我把预处理挪到加速卡上的算子库执行，同时缓存光源校正参数，不重复计算，延迟一下子就降下来了。

第三个原因是 GPU 冷启动问题。第一次请求进入时，推理引擎要加载模型权重、做显存初始化，耗时可能好几秒。我加了预热机制，服务启动后先跑几轮假请求把显存和核心热起来，保证真正请求进入时不会经历“冷启动暴击”。

在线推理调试的教训是：不要在实验室里只测单请求延迟，要用真实产线的并发模型压测。单请求 50ms 不等于产线高峰期不抖动。

4.3 存储分层：优化本地缓存与归档策略

项目运行前三个月，有一个周末我们遇到了存储阻塞：几十个训练任务同时读取历史样本，并行文件系统 IO 排队严重，连在线检测的日志写入都变慢了。

问题出在我太信任中心存储。所有训练数据、日志、中间文件都堆在并行文件系统上，从没做过分层。训练时几十个节点同时读，峰值 IO 一上来，整集群跟着遭殃。

我做的调整是三步。第一步，训练数据统一先拉取到计算节点本地 NVMe 盘，训练只在本地读；第二步，验证集和当前使用频率高的测试集放中心存储，不使用时不占用；第三步，历史数据归档到对象存储，保留一个月内的完整数据和三个月内的统计摘要。加上这套策略之后，训练时间缩短了将近四成，存储告警基本消失。

数据分层的另一个收获是：冷热数据不再混在一起，备份和清理策略也好做了。以前数据工程师怕误删，所有数据都不敢动；现在热数据一周一备份，冷数据一个月一归档，运维事故反而更少。

5. 制造超算 AI 项目复盘：架构师守住的三件事

5.1 需求转化是一场持续共识，而不是一次性翻译

项目上线第二个月，业务方突然提出要加一个新的缺陷识别类型，原因是市场上客户投诉了。这就是需求转化的真实面貌：它不是启动会上的一个环节，而是贯穿全生命周期的日常动作。

我建立了一个轻量变更流程，业务侧提新需求，技术组评估影响，然后大家坐下来确认两个问题：这次改动是影响现有成功率，还是不改变现状只增加覆盖范围？如果是后者，就按增量需求排入下一迭代；如果是前者，必须重新跑验收样本，不能直接上线。这个流程把绝大多数无休止的“顺便加个功能”挡在了可控范围内。

需求转化能做好的关键，不是把需求文档写得无懈可击，而是让业务方在每周的例行演示里看到系统当前的真实状态。实时看板、失败样本展示、误报案例回放，这些比任何汇报 PPT 都管用。业务方越早看见系统边界，就越早把不切实际的预期收回。

5.2 架构落地必须有一条“最小可运行版本”主线

复盘整个项目，我最后悔的，是有两次差点被“完美方案”拉走。一次是有人提议先把全流程微服务化再接入第一条产线，另一次是有人提议先建一个完整的指标体系再讨论模型。这两次我都强行踩了刹车。

架构落地的有效性，不在于设计图画的有多完整，而在于最短时间内有没有一个能演示、能验证、能被业务方批评的真实系统。我把项目里程碑都压成短周期，每次都能拿出一个能对着产线讲清楚的东西。风险前置暴露，修改成本也随之降低。

小步快跑不是一句口号，它会影响架构决策：存储组件要选能用插件扩展的，模型服务要有版本切换能力，调度器要支持动态加节点。所有这些设计，都是为了“先跑通主路径、再逐步加厚”这个主线服务的。

5.3 以“业务收益”收尾：从跑通到算清楚账

项目做成功与否，最后我要求团队不只用技术指标说，还要求用业务账本说。这也是制造超算 AI 项目能不能持续获得投入的关键。

实际运行三个月后，我们做了这样一份账：在线检测上线后，整机漏检数量下降了约六成，单条产线质检人力释放了两名，设备预测预警提前了至少 48 小时，意外停机次数明显减少。再把每一项折算成成本减少，数字比任何指标都有说服力。

这份账还有一个作用：它反过来指导了二期投入的优先级。业务方看到漏检率下降收益最大，主动提出要扩大部署范围；看到设备误报率还有不少优化空间，愿意投入更多资源做样本标注。这就是架构师最想看到的局面：不是技术追着业务解释，而是业务拿着账本找技术要增量。

我个人在整个项目里最大的体会是：需求转化和架构落地，从来不是一个线性流程，而是同一件事的两面。没有把业务语言翻译成工程指标的耐心，再好的架构图纸也只是空中楼阁；没有把最小可运行系统拿到真实产线去摔打的决定，再精确的需求规格也换不来稳定的业务收益。制造超算 AI 项目最难的部分，从来不是那几行模型代码，而是让代码背后的人和流程真正转起来。