先说个真实场景。上个月去一家汽车零部件厂做产线诊断，车间里几十台数控机床，每台都配了台工控机，算力资源七零八落。有的设备负荷飙到90%，有的闲得发慌——但没人知道怎么挪。说实话，这种“算力孤岛”在机械制造行业太常见了。
咱们做机械的，习惯了跟齿轮、轴承、液压缸打交道，但现在的产线，本质上是“机械+计算”的混合体。你得把PLC的循环时间、视觉检测的推理延迟、MES的数据库查询，统统塞进同一条时间轴里。这时候，一个能统一调度算力的平台，就成了刚需。
算力资源池化：别让机床等CPU
传统做法是每台设备配固定算力，比如一台加工中心配个高性能IPC。可实际上，加工过程分阶段：粗加工时计算量小，精加工时在线测量和补偿算法突然吃满CPU。你按峰值配，平时就浪费；按均值配，关键时刻卡顿——工件报废的损失可不是省几台电脑能补回来的。
我见过最典型的踩坑案例：某厂给视觉检测系统配了GPU加速卡，但检测工位只有两个，其它工位闲置。后来我们帮他们把GPU做成资源池，通过容器化动态挂载，检测任务来了就分配，没任务就释放给仿真计算用。改造后，光GPU利用率就从不到20%提到了70%以上。注意，这里说的资源池不是简单虚拟化，而是要跟产线的实时性要求对齐。工业场景跟互联网不一样，你没法容忍150毫秒的调度延迟。所以，边缘侧的调度器必须做到微秒级响应，至少要保证PLC周期中断不被抢占。
有人会问，那直接用Kubernetes不就行了？现实是，K8s那套服务发现、负载均衡在IT环境里很香，但OT环境里——设备发现、OPC UA、Modbus TCP这些协议，它根本不懂。你需要在K8s之上再套一层“工业感知”的调度层，知道哪台机床正在换刀，哪台处于待机，哪台在急停。这些状态会直接影响算力分配策略。
调度策略：把“优先级”从概念变成代码
算力调度最核心的是优先级设计。在机械加工里，安全控制 > 质量检测 > 生产执行 > 数据追溯，这是铁律。你不能让一个数据备份任务抢了安全联锁计算的时间片，哪怕它再占用少。
具体实现时，我给客户的方案是“双通道调度”：硬实时任务走独立的内核模块，用优先级位图直接管理；非实时任务扔进普通进程队列。比如，某个工位发生刀具断裂报警，系统需要在1ms内触发响应——这个计算必须独占一个核，而且不能被打断。你用队列调度？不可能。得用中断绑定，或者干脆把这位任务直接跑在RTOS上。
另一个关键点是混合关键性（Mixed-Criticality）调度。这个概念在航空电子里早就成熟了，但工厂里很少人用。说白了，就是不同任务在资源冲突时，低关键性任务要让路，但要让得优雅。我见过有些团队简单粗暴地给每个容器限制CPU份额，结果高优先级任务启动时，低优先级任务被活活饿死——最后连日志都写不出去。正确的做法是设定最小资源保证，而不是一刀切。
举个例子：数据采集任务，允许它在高峰期降频到10Hz，但不允许挂掉；仿真分析任务可以排队，但不能无限期等。这里需要引入弹性配额机制，类似Linux的CFS带宽控制，但要按工业任务的周期特性重新调参。
边缘自治与云端协同：断网也不能停线
工厂网络不像公司办公室，交换机、光纤、无线AP经常被现场金属粉尘干扰，偶尔断个网根本避免不了。所以，调度平台必须支持边缘自治。云端负责全局优化模型和预测性维护，边缘负责实时调度和本地缓存。一旦网络恢复，再做补偿同步。
我参与过一个项目，客户要求即使核心交换机坏了，产线也不能停。那怎么办？我们在每台机床旁边部署一个边缘网关，算力调度器跑在网关里，向上连接云端控制面，向下连接机床控制器。平时云端下发最优策略，边缘执行；断网时，边缘自己按预设规则调度——比如，把视觉检测的采样率从30fps降到5fps，牺牲一点精度，保住连续生产。这个权衡，很多工程师一开始接受不了，觉得是偷工减料。但现实是，让价值几百万的加工中心停下来，损失远大于那几帧视觉采样。
顺带提一句，选型时一定要算一下调度器的“内存足迹”。有些商用平台的调度代理吃几百MB内存，在工业PC上可能没什么，但你放在那种只有1GB内存的嵌入式网关上，直接就炸了。我倾向于用C++或Rust写核心调度器，内存控制在几十MB以内。别迷信那些Java系的重型框架——运维是方便了，但产线不认这个。
全链路可观测：谁在吃算力？一目了然
算力调度的前提是可见。你不能只知道CPU平均利用率，你得知道每个任务在每一毫秒的调度延迟、排队时长、被抢占次数。这需要内核级探针和业务级的链路追踪配合。
我们在部署时，会在每台设备上跑一个轻量级agent，采集调度事件，然后汇聚到Grafana里展示。方便到什么程度？有一次现场排查一个视觉卡顿问题，发现是机械手动作触发了负载峰值，导致CPU缓存抖动——光看负载曲线根本看不出，但看调度延迟热力图，瞬间定位到是哪个任务的cache miss。这比纯靠经验猜强太多了。
还有一点，日志和指标一定要带时间戳和任务ID。别问我为什么，调试过三四个小时定位“幽灵任务”的兄弟都懂。
踩坑总结与建议
最后说几个实际建议，都是血泪。
第一，不要一开始就搞大而全的平台。先挑一条典型产线做试点。把调度粒度从“容器”细到“任务”，把优先级模型跟生产工艺绑定，验证无损切换后再推广。
第二，安全认证不能省。工业网络环境复杂，调度平台一旦被入侵，等于控制了整个产线计算资源。你要用基于角色的访问控制（RBAC），最好再加物理层隔离。别嫌麻烦。
第三，算力规划要预留20%-30%的冗余。你以为算好了，但现场总会有意外，比如新版视觉模型推理时间翻倍。没有冗余，调度就成了死锁。
第四，考虑硬件的异构性。不同代的工业PC可能有不同指令集，容器镜像必须兼容x86、ARM甚至MIPS。我们就在一个项目里吃了亏，边缘网关是ARM的，云端训练的模型推下去跑不了，逼着我们改用ONNX Runtime做跨平台推理。
说实话，工厂算力资源统一调度管理平台，不是个纯软件项目，得懂机械工艺、嵌入式实时系统、网络协议，还得懂点心理学——因为你要说服老师傅们用你的调度策略。慢慢来，先把一条线跑顺，再复制经验。别再让机床等CPU了，真的。
