说实话，刚接到把车间算力统一调度的任务时，我第一反应是：这又是个“一堆PPT”的活儿。但真干起来，发现里面的门道比想象的多。
我们厂是典型的离散制造，冲压、焊接、涂装、总装，每个工段都有独立的工控机和边缘盒子。以前每台设备各自为政，CPU利用率天差地别。有的视觉检测站排队排到天荒地老，旁边的弧焊机器人控制器却闲得发慌。数据不用挖，光看监控大屏就想骂人。
但光说浪费没用，得算账。我们统计过，全厂有232台工控机，平均CPU利用率只有22%，但高峰时段有设备冲到95%以上。搞统一调度，说白了就是把这些利用率拉平，顺手把排队时间砍掉一半。想法很简单，落地是真难。
一、先搞清楚“调度”到底调什么？
很多人一听“算力调度”，第一反应是“不就是虚拟机迁移吗？”——大错特错。工厂里的算力分三个层次：毫秒级的PLC控制，秒级的机器视觉，分钟级的MES数据汇总。每个层次对延迟、可靠性的要求完全不一样。你不能把PLC的周期任务扔到云端，哪怕延迟只有1毫秒，也会出大事故。所以调度的第一原则是：**看人下菜碟**，给不同任务画好安全区。
我们就栽过跟头。最开始想用OpenStack搞统一虚拟机池，结果发现训练好的视觉模型一上虚拟机，检测周期从200ms飙到350ms。原因很俗——虚拟机的网络栈和调度器开销太大。后来换成容器，用KubeEdge把边缘节点管起来，才勉强压回220ms。还是不够，最后干脆把视觉推理任务单独跑在裸金属上，只把状态上报、日志这种非实时任务丢进容器。所以你看，调度不是万金油，得按实时性切分。
二、技术选型：别被“容器化”忽悠了
市场上吹K8s的满天飞，但工厂环境不是互联网机房。车间里网络经常抖动，交换机走线不规范，还有电焊机这种大功率设备一启动，网线就丢包。Kubernetes那套健康检查机制，动不动就把节点标记为“NotReady”，然后任务重新调度，结果把PLC的一个写指令重复执行了两次，差点造成机械碰撞。后来我们设置了容忍度（Toleration）和本地故障恢复，才把误杀率降下来。
另外，别迷信Docker镜像的“一次构建到处跑”。工业现场有大量老掉牙的现场总线协议，比如Modbus RTU、CANopen，还有用串口通讯的扫码枪。这些设备驱动跟系统底层绑得死死的，强行容器化，光改driver就够喝一壶。我们的做法是：旧设备继续裸跑，新设备上容器，然后通过一个统一的消息中间件（EMQX + Kafka）连接——算是“**物理隔离，逻辑统一**”。
说到消息中间件，又是个大嗓门。数据吞吐量看似挺高，但一旦突峰，Kafka的消费者Lag一下子拉满。我们之前没做背压控制，结果边缘节点内存直接爆掉，设备死机。后来加了流控和削峰，才稳住。
三、实时性是个躲不过的坎
工厂里最大的矛盾是：IT要统一，OT要实时。我们试过用时间敏感网络（TSN）做底层，但交换机太贵，还得重新布线，领导一看预算就脸绿。退而求其次，采用“**优先级抢占**”策略：让PLC流量走独立VLAN，并且在边缘节点上设定CPU亲和性，把核心控制进程钉在独立CPU核上，剩下的核才给其它任务。这一刀下去，PLC周期抖动从2ms降到0.3ms，效果立竿见影。
还有个小技巧：把非实时任务放到夜深人静的时候跑。比如模型训练、大数据分析，白天产线忙着，咱就在凌晨把空闲算力拉起来，稳稳当当。
四、组织人事比技术更难
说实话，技术问题最后都解决了，真正的硬骨头是跨部门协调。IT部门想全盘接管，设备科不放心，说“你懂冲压吗？”；维修师傅们习惯了每台机器单独配置，突然要改统一管控，生怕出问题。后来我们搞了一个“算力调度委员会”，每个车间出个人当接口人，先试点一条线，跑稳定了再铺开。另外，监控大屏必须给车间主任权限，让他们看到自己车间的资源反而多了，才配合你。
这也让我学到一个道理：统一调度不是“剥夺”现场资源，而是“盘活”闲置资源。你要让一线人感受到好处，不然再好的技术也白搭。
所以啊，这活儿干到现在，至少我们不用再半夜被电话叫醒，“车间又卡了”。看着一台台边缘节点安安静静跑着，偶尔飘几行日志，心里还挺踏实。
