你在直播间看主播喊321上链接湘钢的AI在产线旁喊321上推理——区别是前者算的是GMV后者算的是钢板表面有没有裂纹。一、炼钢炉旁的云原生先讲个真实的事。湖南湘潭钢铁集团湘钢2023年干了一件让传统制造业同行瞳孔地震的事情——他们在5G专网覆盖的炼钢产线上部署了一套基于Kubernetes的边缘AI推理集群同时在后端的私有云里跑着一个8卡A100的分布式训练集群。这听起来像是互联网大厂的配置但它切切实实发生在了一家钢铁企业里。为什么要这么搞因为钢铁生产的容错率极低。一块钢坯从加热炉出来经过粗轧、精轧、冷却、矫直每一步都可能产生表面缺陷——裂纹、结疤、划伤、氧化铁皮压入。传统做法是质检员站在高温产线旁用肉眼一块一块看。但人的注意力最多集中20分钟而产线24小时不停。于是湘钢的工程师们提了个方案在每条产线旁部署边缘AI节点做实时推理模型在云端训练好再下发到边缘。这就是典型的边缘-云协同架构但真正的魔鬼藏在实现细节里——往下看你就知道了。二、制造业AI的三个真需求很多文章一上来就给你列十个八个应用场景看起来热闘非凡但你仔细一想这些东西跟实际生产有什么关系制造业的AI需求说穿了就三个2.1 产品质量——“这块钢板能不能用”这是最刚性、ROI最明确的需求。一块有缺陷的钢板流到下游轻则退货赔款重则安全事故。传统人工质检的检出率大约在85%-90%而且一致性差——同一个质检员早上和晚上的判断标准都不一样。AI视觉质检可以把检出率推到98%以上而且24小时不疲劳、标准完全一致。2.2 生产优化——“怎么炼更快更省”炼钢是一个多变量耦合的复杂过程——温度、压力、成分、时间任何一个参数偏离都会影响成品质量。传统做法依赖老师傅的经验看火候是一门玄学。但老师傅会退休他的经验带不走。AI可以在海量历史生产数据中找到最优参数组合把看火候变成算火候。2.3 预测性维护——“这个设备什么时候会坏”轧机、风机、电机这些核心设备一旦意外停机损失是以分钟计的。传统维护方式是定期检修——不管设备状态好不好到时间就拆开看。这叫过度维护浪费钱还影响生产。预测性维护的思路是通过振动传感器、温度传感器持续采集设备运行数据AI模型在故障发生前几小时甚至几天就发出预警。⚠️警告1预测性维护最容易踩的坑很多人以为预测性维护就是采集数据→训练模型→预测故障三步走完收工。实际上最大的难题根本不是模型而是标注数据。正常运行的设备数据你有一大堆但真实故障数据可能一年才几条。没有足够的故障样本模型学个寂寞。解药先用无监督学习做异常检测AutoEncoder、Isolation Forest只学正常长什么样偏离正常的就是异常。等攒够了故障标注数据再上监督学习。三、四个典型场景的技术栈总览场景数据源AI技术路线部署形态核心挑战产品质检工业相机/3D扫描CV目标检测语义分割边缘推理毫秒级响应预测性维护振动/温度/电流传感器时序异常检测LSTM边缘推理故障样本稀缺智能排产MES/ERP系统数据运筹优化强化学习中心训练边缘执行约束条件复杂供应链协同订单/库存/物流数据需求预测动态规划云端数据孤岛打通可以看到不同场景对算力、时延、数据量的要求差异巨大一刀切的部署方案根本行不通。这就是为什么湘钢选了混合架构。四、湘钢案例拆解把监控变成了自动驾驶4.1 整体架构先上一张大局图graph TB subgraph 5G专网覆盖的钢铁产线 A1[热轧产线-边缘节点1br/Atlas 300I Pro推理卡] A2[冷轧产线-边缘节点2br/Atlas 300I Pro推理卡] A3[连铸产线-边缘节点3br/NVIDIA Jetson Orin] end subgraph 5G MEC边缘云 B1[边缘K8s Masterbr/3节点集群] B2[模型管理服务br/Model Registry] B3[推理结果汇聚br/ KafkaClickHouse] end subgraph 中心私有云-训练集群 C1[GPU训练集群br/8×A100 NVLink] C2[分布式训练平台br/KubeflowPytorch DDP] C3[模型仓库镜像仓库br/HarborMLflow] end subgraph 业务应用层 D1[实时监控大屏] D2[质量追溯系统] D3[设备健康管理系统] end A1 --|5G URLLCbr/10ms| B1 A2 --|5G URLLC| B1 A3 --|5G URLLC| B1 B1 --|模型下发| A1 B1 --|模型下发| A2 B1 --|模型下发| A3 B2 --|推理结果| B3 B3 -- D1 B3 -- D2 B3 -- D3 C1 --|训练完成模型| C3 C3 --|模型同步| B2 B1 --|训练数据回流| C2这套架构的核心思路是八个字边缘推理中心训练。4.2 边缘节点产线旁的AI质检员每条产线侧部署一个边缘AI节点典型配置如下硬件华为Atlas 300I Pro推理卡昇腾310P或NVIDIA Jetson Orin软件栈K3s轻量级Kubernetes NVIDIA Triton Inference Server网络5G URLLC切片保证10ms空口时延 99.999%可靠性推理模型基于YOLOv8ResNet的钢板表面缺陷检测模型INT8量化后推理延迟5ms/帧为什么不直接在中心云做推理因为工业相机的帧率是60fps每帧16ms。如果把视频流传到中心云再传回结果光是网络往返就超过50ms等结果回来钢板已经跑了半米远了。技巧1边缘推理的热备策略别在生产环境直接用K8s的默认调度。边缘节点资源有限推理服务必须用nodeSelector锁定到带GPU的节点同时配置PodAntiAffinity保证同一服务的副本分散到不同节点。更重要的是在边缘节点上预拉取模型镜像——别等Pod调度到节点上才开始拉10GB的模型镜像那时候黄花菜都凉了。边缘K8s部署完整YAML配置# # 边缘节点推理服务完整部署配置 # 适用场景产线侧钢板表面缺陷实时检测 # 硬件要求NVIDIA GPU 或 昇腾NPU # --- # 1. 命名空间 apiVersion: v1 kind: Namespace metadata: name: edge-inference labels: app: steel-inspection environment: production --- # 2. GPU节点标签kubectl label nodes edge-node-01 acceleratornvidia-t4 # 3. 推理模型配置ConfigMap apiVersion: v1 kind: ConfigMap metadata: name: inference-model-config namespace: edge-inference data: config.pbtxt: | name: steel_defect_detector platform: tensorrt_plan max_batch_size: 8 input [ { name: input data_type: TYPE_FP32 dims: [ 3, 640, 640 ] } ] output [ { name: output data_type: TYPE_FP32 dims: [ 8400, 85 ] } ] instance_group [ { count: 2 kind: KIND_GPU gpus: [ 0 ] } ] dynamic_batching { max_queue_delay_microseconds: 500 } inference-threshold.yaml: | # 缺陷检测阈值配置 defect_thresholds: crack: 0.75 # 裂纹 scab: 0.80 # 结疤 scratch: 0.70 # 划伤 scale: 0.85 # 氧化铁皮压入 min_confidence: 0.65 # 最低置信度 nms_iou_threshold: 0.45 --- # 4. Triton Inference Server Deployment apiVersion: apps/v1 kind: Deployment metadata: name: triton-defect-detector namespace: edge-inference labels: app: triton-defect-detector spec: replicas: 2 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 0 # 推理服务不允许中断必须0宕机滚动 maxSurge: 1 selector: matchLabels: app: triton-defect-detector template: metadata: labels: app: triton-defect-detector spec: # 关键反亲和避免所有副本落在同一节点 affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: app: triton-defect-detector topologyKey: kubernetes.io/hostname # 关键节点选择器 GPU容忍 nodeSelector: accelerator: nvidia-t4 edge-zone: production-line-01 tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule # 关键预拉取模型镜像 initContainers: - name: model-loader image: harbor.xianggang.local/models/steel-defect-v3:latest imagePullPolicy: IfNotPresent command: [/bin/sh, -c] args: - | # 等待模型卷挂载完成 until [ -f /models/steel_defect_detector/1/model.plan ]; do echo Waiting for model files... sleep 2 done echo Model ready for inference volumeMounts: - name: model-repo mountPath: /models containers: - name: triton-server image: nvcr.io/nvidia/tritonserver:23.10-py3 imagePullPolicy: IfNotPresent args: - tritonserver - --model-repository/models - --strict-model-configfalse - --log-verbose0 - --metrics-port8002 ports: - containerPort: 8000 name: http protocol: TCP - containerPort: 8001 name: grpc protocol: TCP - containerPort: 8002 name: metrics protocol: TCP env: - name: CUDA_VISIBLE_DEVICES value: 0 - name: TF_CPP_MIN_LOG_LEVEL value: 2 resources: requests: memory: 8Gi cpu: 4 nvidia.com/gpu: 1 limits: memory: 16Gi cpu: 8 nvidia.com/gpu: 1 volumeMounts: - name: model-repo mountPath: /models - name: inference-config mountPath: /models/steel_defect_detector/config.pbtxt subPath: config.pbtxt readinessProbe: httpGet: path: /v2/health/ready port: 8000 initialDelaySeconds: 30 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 3 livenessProbe: httpGet: path: /v2/health/live port: 8000 initialDelaySeconds: 60 periodSeconds: 30 timeoutSeconds: 10 failureThreshold: 5 volumes: - name: model-repo hostPath: path: /data/models type: DirectoryOrCreate - name: inference-config configMap: name: inference-model-config --- # 5. 视频采集与分析Pipeline - 核心处理逻辑 apiVersion: apps/v1 kind: Deployment metadata: name: video-analytics-pipeline namespace: edge-inference labels: app: video-analytics-pipeline spec: replicas: 3 selector: matchLabels: app: video-analytics-pipeline template: metadata: labels: app: video-analytics-pipeline spec: nodeSelector: edge-zone: production-line-01 containers: # ----- 容器A: 视频采集 ----- - name: video-capture image: harbor.xianggang.local/edge/video-capture:2.1.0 env: - name: CAMERA_RTSP_URL valueFrom: secretKeyRef: name: camera-credentials key: rtsp-url - name: FRAME_WIDTH value: 1920 - name: FRAME_HEIGHT value: 1080 - name: TARGET_FPS value: 30 - name: OUTPUT_TOPIC value: raw-frames - name: KAFKA_BROKERS value: kafka.edge.svc.cluster.local:9092 resources: requests: memory: 2Gi cpu: 2 limits: memory: 4Gi cpu: 4 volumeMounts: - name: frame-buffer mountPath: /tmp/frames # ----- 容器B: 帧预处理裁剪归一化批处理----- - name: frame-preprocessor image: harbor.xianggang.local/edge/frame-preprocessor:2.1.0 env: - name: INPUT_TOPIC value: raw-frames - name: OUTPUT_TOPIC value: preprocessed-frames - name: KAFKA_BROKERS value: kafka.edge.svc.cluster.local:9092 - name: BATCH_SIZE value: 8 - name: TRITON_ENDPOINT value: triton-defect-detector.edge-inference.svc:8001 resources: requests: memory: 4Gi cpu: 4 limits: memory: 8Gi cpu: 8 volumeMounts: - name: frame-buffer mountPath: /tmp/frames # ----- 容器C: 结果后处理与告警 ----- - name: result-handler image: harbor.xianggang.local/edge/result-handler:2.1.0 env: - name: INPUT_TOPIC value: inference-results - name: KAFKA_BROKERS value: kafka.edge.svc.cluster.local:9092 - name: ALERT_WEBHOOK value: http://alertmanager.monitoring.svc:9093/api/v2/alerts - name: CLICKHOUSE_DSN valueFrom: secretKeyRef: name: clickhouse-credentials key: dsn - name: DEFECT_IMAGE_STORAGE value: /data/defect-images resources: requests: memory: 2Gi cpu: 2 limits: memory: 4Gi cpu: 4 volumeMounts: - name: defect-storage mountPath: /data/defect-images volumes: - name: frame-buffer emptyDir: medium: Memory sizeLimit: 2Gi - name: defect-storage hostPath: path: /data/defect-images type: DirectoryOrCreate --- # 6. Kafka用于Pipeline内部消息传递 apiVersion: v1 kind: Service metadata: name: kafka namespace: edge-inference spec: ports: - port: 9092 targetPort: 9092 name: kafka clusterIP: None selector: app: kafka --- # 7. HPA - 推理服务自动扩缩容 apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: triton-hpa namespace: edge-inference spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: triton-defect-detector minReplicas: 2 maxReplicas: 6 metrics: - type: Pods pods: metric: name: nv_inference_request_success target: type: AverageValue averageValue: 500 - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 behavior: scaleUp: stabilizationWindowSeconds: 30 policies: - type: Pods value: 1 periodSeconds: 15 scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 10 periodSeconds: 60技巧2视频Pipeline的流水线设计很多人把视频采集、预处理、推理、后处理写在一个进程里这在开发环境没问题但在产线环境是灾难。一旦推理变慢整个Pipeline都卡住。正确的做法是用Kafka做解耦每个阶段独立Pod、独立扩缩容。预处理慢了就扩预处理Pod推理慢了就扩推理Pod互不影响。这本质上是生产者-消费者模式在K8s里的实践。4.3 视频分析Pipeline流程图flowchart LR subgraph 数据采集层 A[工业相机br/60fps 1080P] end subgraph 边缘预处理层 B[视频采集Podbr/RTSP→Kafka] C[帧预处理Podbr/裁剪/归一化/批处理br/1920×1080→640×640] end subgraph 推理引擎层 D[Triton Serverbr/INT8量化模型br/推理延迟5ms] E[TensorRT Enginebr/batch_size8br/dynamic batching] end subgraph 后处理与决策层 F[结果后处理Podbr/NMS/阈值过滤] G{缺陷检测br/置信度0.75?} H[写入ClickHousebr/质量追溯] I[触发告警br/AlertManager→钉钉/企微] J[缺陷图片存档br/MinIO对象存储] K[正常帧丢弃br/仅保留元数据] end A --|RTSP流| B B --|raw-frames topic| C C --|preprocessed topic| D D -- E E --|inference-results| F F -- G G --|是| H G --|是| I G --|是| J G --|否| K style I fill:#ff6b6b,stroke:#c92a2a,color:#fff style G fill:#ffd43b,stroke:#fab005五、拓扑感知调度让GPU走亲戚快点5.1 问题你的GPU集群可能只发挥了60%的性能湘钢的云端训练集群是8卡A100通过NVLink互联。理论上NVLink带宽600GB/s但实际训练时你会发现——这个带宽经常跑不满。根本原因是什么默认的K8s调度器不懂硬件拓扑。举个例子你有2台8卡A100的节点。K8s可能把4块GPU调度给节点1另外4块调度给节点2。结果你的分布式训练变成了跨节点的NCCL通信走的是RDMA网卡200Gb/s而不是本机的NVLink600GB/s——差了3倍。这就是典型的拓扑无感知问题。5.2 解法Volcano GPU拓扑感知调度# # Volcano GPU拓扑感知调度配置 # 核心目标让分布式训练Job的Pod尽可能落在同一NVLink域内 # apiVersion: batch.volcano.sh/v1alpha1 kind: Job metadata: name: steel-defect-training namespace: training spec: minAvailable: 8 schedulerName: volcano tasks: - replicas: 8 name: worker template: spec: containers: - name: pytorch image: harbor.xianggang.local/training/pytorch:2.1.0-cuda12.1 command: - torchrun - --nnodes1 - --nproc_per_node8 - /workspace/train_defect_detector.py - --epochs100 - --batch-size256 - --modelyolov8x resources: requests: nvidia.com/gpu: 8 limits: nvidia.com/gpu: 8 env: - name: NCCL_SOCKET_IFNAME value: eth0 - name: NCCL_IB_DISABLE value: 0 - name: NCCL_NET_GDR_LEVEL value: 5 - name: NCCL_DEBUG value: INFO # 拓扑感知调度策略 policies: - event: PodEvicted action: RestartJob - event: PodFailed action: RestartJob plugins: svc: [] env: [] queue: training-queue priorityClassName: high-priority # 关键taskTopology配置 # 强制所有worker Pod落在同一NUMA节点/NVLink域内 tasks: - replicas: 8 name: worker topologyPolicy: restricted # restricted 必须同NVLink域⚠️警告2NVLink拓扑感知的隐形成本当你配置了topologyPolicy: restricted后调度器会优先把8个Pod放在同一台机器的8块GPU上。这听起来完美但有一个坑如果这台机器刚好资源不够你的Job会一直Pending。生产环境建议配置两级策略restricted优先单机8卡NVLink全互联如果等待超过5分钟降级为best-effort允许跨2台机器各4卡NVSwitch互联 RDMA跨机这需要在Volcano的Queue配置里设置queue.schedulingGracePeriod。六、确定性网络5G凭什么敢用在工业控制6.1 工业场景的网络需求回到湘钢的场景边缘节点和MEC之间的通信有几个硬指标业务类型带宽要求时延要求可靠性要求典型场景视频流上传≥50Mbps/路30ms99.9%产线监控推理结果下发1Mbps10ms99.999%缺陷报警模型更新下发≥100Mbps1s99.99%模型热更新训练数据回流≥1Gbps不敏感99.9%离线训练这里最苛刻的是推理结果下发——10ms以内99.999%可靠性。这个指标是什么概念工业以太网PROFINET的周期时间是1ms5G URLLC的目标是空口时延1ms、端到端时延5ms。湘钢的做法是向运营商申请5G URLLC专用切片把工业控制流量和普通办公流量在无线侧就物理隔离开。6.2 确定性网络不只是5G的问题很多人以为有了5G就万事大吉但实际上端到端的确定性需要整条链路配合工业相机 → 5G CPE → gNB基站 → UPF → MEC → 边缘K8s → 推理服务 ↑ ↑ ↑ ↑ ↑ ↑ ↑ │ │ │ │ │ │ │ 1ms采集 5ms空口 2ms回传 3ms转发 1ms处理 2ms网络 5ms推理全链路加起来大约19ms还需要加上排队和抖动。技巧3减少网络抖动的三板斧边缘K8s节点开启CPU隔离推理Pod绑定独占CPU核心cpuset避免CPU争抢导致推理延迟抖动。在Kubelet配置中开启--cpu-manager-policystatic。Kafka开启零拷贝视频帧数据从Kafka到推理服务走sendfile系统调用数据不经过用户态拷贝。Kafka Producer配置compression.typelz4在CPU开销和压缩率之间取平衡。Triton Server开启动态批处理不要傻等batch凑满设置max_queue_delay_microseconds: 500最多等500微秒就推理平衡吞吐和延迟。七、混合云架构的三明治模型湘钢的整体方案可以抽象成三层# 湘钢混合云三明治架构的概念配置 # 这是一个逻辑视图表示三层如何协作 sandwich_architecture: # 第一层边缘推理层产线侧 edge_layer: location: 生产车间 compute: Atlas 300I Pro / Jetson Orin network: 5G URLLC responsibilities: - 实时视频采集与推理10ms - 缺陷实时报警 - 轻量级数据预处理 k8s_flavor: K3s (3节点边缘集群) # 第二层MEC汇聚层厂区机房 mec_layer: location: 厂区边缘机房 compute: 通用x86服务器 推理卡 network: 5G eMBB 光纤 responsibilities: - 多产线推理结果汇聚与分析 - 模型版本管理与下发 - 短期数据缓存7天热数据 k8s_flavor: 标准K8s (5节点集群) # 第三层中心训练层集团私有云 cloud_layer: location: 集团数据中心 compute: 8×A100 SXM NVLink network: 100GbE RoCE v2 responsibilities: - 大规模分布式训练 - 全量数据存储与标注 - 模型性能评估与AB测试 k8s_flavor: 标准K8s Volcano调度器 (20节点集群)⚠️警告3模型下发的版本地狱这是边缘-云协同架构最容易被低估的坑。当你有10条产线、每条产线2个边缘节点、每个节点跑3个模型——一旦模型版本管理混乱你就会陷入哪个节点跑的是v2.3、哪个是v2.4的猜谜游戏。湘钢的做法是模型即容器镜像。每个模型版本打成一个独立的Docker镜像推到Harbor边缘节点通过ArgoCD监听模型仓库的变化自动拉取新版本。这样模型版本就和代码版本一样可追溯、可回滚。# ArgoCD Application - 边缘模型自动同步 apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: edge-models-sync namespace: argocd spec: project: manufacturing source: repoURL: harbor.xianggang.local/models chart: steel-defect-models targetRevision: 2.4.1 destination: server: https://edge-k3s-api.xianggang.local:6443 namespace: edge-inference syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespacetrue八、效果与ROI湘钢这套系统上线一年后的数据质检检出率从87.3%提升到98.6%误报率从12.5%降低到3.2%单产线人力减少质检岗从每班4人减少到1人复核处理异常年均避免质量损失约2300万元设备非计划停机同比下降67%整个项目的硬件软件实施总投入约1800万ROI回收周期大约10个月。但说实话湘钢能跑通这个方案背后有一些隐形条件——他们本身就有很强的信息化基础MES、ERP系统数据完整5G专网是省里智能制造示范项目的配套运营商给了很大支持。一般中小企业要想复制最大的瓶颈不是技术而是数字化基础。九、总结三件套 一张图总结制造业AI云原生的铁三角边缘推理→ 毫秒级响应产线实时质检 5G确定性网络→ 低时延低抖动工业级可靠性 ☁️云端训练→ 大规模算力持续模型优化三者缺一不可。少了任何一个角整个三角就塌了。 三个关键决策点边缘和云的分工要清晰边缘只管推理云只管训练。别在边缘搞训练——你的边缘节点连散热都是问题。网络不是有就行工业场景要的是确定性网络不是尽力而为的互联网。5G URLLC切片是硬需求WiFi6在工业场景只能做备份。模型版本管理是隐形杀手在你被版本混乱搞疯之前把模型也当成代码管起来——容器化 ArgoCD Harbor。 下集预告制造业的供应链是AI的下一个战场。钢铁生产只是起点。零部件供应商、物流、仓储、分销——整条供应链的协同优化才是真正的深水区。下篇《零售业AI云原生实战——奇点数聚全渠道用户画像》我们聊聊当AI开始读心消费者在毫秒级实时推荐背后藏着怎样的云原生架构。本文是AI云原生实战调研系列第7篇前6篇已覆盖金融、医疗、教育、能源等行业。欢迎关注专栏获取完整系列。标签制造业AI、工业质检、5G、边缘计算、拓扑感知调度、NVLink、混合云