说实话，前阵子去一家汽车零部件工厂做技术交流，那场景让我挺有感触的。车间里有焊装机器人、视觉检测工位、AGV调度系统……光是边缘侧的工控机就有二十多种规格，CPU从老掉牙的Atom到最新的至强都有。每套系统各自为政，算力利用率能到20%就算烧高香了。这哪是数字化工厂，分明是算力孤岛集中营。
后来他们上了一套统一调度平台，效果立竿见影。但这里面的坑，远比想象中要多。今天就跟大家聊聊——工厂算力资源统一调度平台到底该怎么搞，尤其是那些容易在设计阶段就被忽视的细节。
一、先别急着上容器，把“算力账”盘清楚
做这类平台，最忌讳的就是一上来就搬Kubernetes那一套。工厂环境和互联网公司完全是两码事。产线设备对时延的敏感度，高得离谱。比如视觉检测，一个帧周期超过30毫秒，那边机械臂就等着“发呆”，节拍全乱了。
所以第一步，先得把现场的资源摸个底。哪些设备是硬实时要求的，哪些是软实时的，哪些其实可以容忍几秒的延迟。我见过一个案例，他们把机加工的车床数据采集任务和办公网络跑在一个集群里，结果一个大模型训练任务直接把网络带宽吃满，导致车间数据上报延迟超过一分钟——差点酿成误报警。
记住：资源池化不是把什么东西都扔进一个池子。要分域。至少按照功能分：实时控制域、数据采集域、分析计算域。域和域之间用独立网络或者VLAN隔离开。否则一出事，扯皮都来不及。
顺带说一句，别迷信“边缘节点越多越好”。节点数量增长带来的分布式一致性开销，可能比省下的那点传输时延还大。我见过工厂为了省带宽在每台CNC旁边放一个边缘盒子，结果呢？光维护那些盒子的系统镜像就累死人，后来砍掉一半，性能反而好了。
二、调度策略：既要“智慧”，也要“冷酷”
很多人以为调度算法越智能越好，什么预测式、启发式、群体智能……听着玄乎，实际一跑，发现还不如一个简单的加权截止时间优先（Weighted Deadline First）好用。
为什么？因为工厂的算力任务规律性太强了。大部分场景，任务就是周期性的——比如每30秒做一次质量数据汇总，每5分钟跑一次产线效率统计。这种场景，简单的策略加一点扰动控制就够了。真的，别把简单问题复杂化。
但有一个地方必须复杂——算力与任务的匹配度。举个例子，同样是一个推理任务，有些神经网络在GPU上跑得飞快，在CPU上就慢得像蜗牛。调度器必须识别出任务的加速器偏好。我们的做法是给任务打标签，比如“需要GPU”“对向量指令集敏感”“必须跑在RT Linux环境”等。
然后调度的时候，要预留弹性。很关键的一点：禁止任务之间互相抢占。工业任务没有什么是可以随意抢占的。你宁可让一部分任务排队等待，也不能让正在运行的推理任务突然被“挤走”。我们当年就吃过这个亏，一个调度器为了给高优先级任务让路，把正在运行的边缘检测进程杀了，结果那批工件全部误判。
顺带提一下资源预测。别指望那些花里胡哨的算法，用历史分位数就够。比如CPU使用率的95分位数作为预留值，再叠加一个小的安全边际。这样既不太浪费，又不会频繁触发扩容。
三、选型与落地：硬件、网络、工程的“三座大山”
硬件选型这块，很多人只关注CPU的核数和主频，却忽略了内存带宽和PCIe通道数。做统一调度之后，数据搬移成了常态，神经网络推理、数据清洗，哪个不吃内存带宽？我用过一片低端工业主板，标称8核2.5G，结果跑起来还不如另选的一块4核的工业ITX板卡，就是因为后者支持DDR5 ECC内存，带宽翻倍。
再说网络。千兆网络真的是瓶颈。我们算过一笔账，如果一台设备要回传10GB的原始数据，千兆网至少要给80秒。而用光口（万兆或者25G）只要8秒。调度平台的任务下发、日志采集，这些流量加起来也不小。所以，网络设计规划必须预留2-3倍的冗余带宽，否则调度高峰期一拥过来，通信延迟直接爆炸。
还有个大坑——时钟同步。统一调度意味着所有节点要协同动作，你没有一个高精度的时钟基准，任务启动时间就校不准。别小看这一点，在工厂里，两个节点之间时间差个50毫秒，就可能导致协同流程逻辑错乱。建议直接用IEEE 1588 PTP协议，精度能在微秒级。
四、一个典型案例：发动机缸体产线的算力整合
去年帮一个动力总成工厂做过一次改造。产线上有6套视觉检测系统，各自配了一台GPU服务器，峰值利用率只有30%左右。另外还有4台数据采集服务器，CPU常年跑不到10%。
我们做了个统一调度平台，把这些服务器的GPU、CPU资源都纳管起来。然后把视觉检测任务改成按帧调用的微服务，和数据采集、特征分析任务混部。用了上面说的分域策略，实时区保证检测时延，非实时区跑离线分析。改造之后，GPU利用率提到了67%，最重要的是——检测工序的响应时间抖动从原来的±120毫秒降到了±10毫秒以内。
这个结果让车间主任挺惊讶的，他甚至问我：“你们是不是偷偷换了硬件？”
其实哪有换硬件，只是把“闲得发慌”的资源借给了“忙得打转”的任务。这就是统一调度的价值。
五、一些碎碎念的踩坑经验
最后分享几个实际教训，都是血泪。
第一，控制平面必须独立于数据平面。调度器所在的控制节点，千万别和业务节点搅在一起。我们试过把调度器部署在边缘节点上，结果有一次那个节点CPU被任务占满，调度心跳超时，整个集群脑裂，差点出事。
第二，任务编排要考虑“接力”场景。有些算力任务是要跨节点串联的，比如先采集，然后滤波，再识别，最后存储。如果调度器只关心单个任务的资源使用，不关注数据流方向，性能会很差。我们后来给平台加了数据亲和性调度——尽量让串联任务落在同一个节点或者临近节点。
第三，也别忘了“人”。统一调度平台上线后，设备维护人员原来的操作习惯几乎全部被打破。必须配备一个“傻瓜式”的可视化界面，把资源占用率、任务排队情况用最直白的方式显示出来。不然等运维老师傅抱怨几次，项目就黄了。
对了，安全隔离这关过不了，工业场景压根不上线。平台至少要支持基于标签的资源隔离，以及任务级的审计日志。我用过OpenFog框架，也试过KubeEdge，但说实话，做工业落地，还是得自己做一层定制化的安全中间件。
总之，统一调度不是银弹，但它是工厂数字化转型必须迈过的一道坎。关键是清醒地认识工业现场的特殊性，别被互联网的造词游戏忽悠了。
