先说个真事儿。去年我们厂做数字化改造，上了全套MES和边缘网关。结果试运行第三天，凌晨两点，二号产线突然停了。查了半天，居然是视觉检测服务器上某个后台进程把CPU吃满，导致边缘网关的数据上报延迟，触发了产线安全联锁。那会儿我的心情，又气又好笑——机械和电气都没问题，问题出在看不见的调度逻辑上。
这件事让我彻底明白，工厂里的算力，跟车间的物料是一个道理，也需要调度。而且调度不好，真的能出大事。以前我们只关心机床的转速和进给量，现在还得关心算法的优先级和任务的截止时间……说实话，有点超纲，但硬着头皮也要学。
算力调度的本质，是给“任务”排优先级
工厂里的算力资源，从PLC、运动控制器，到边缘服务器，再到云端的HPC，每一层都在争抢CPU时间、内存带宽和网络时延。就像厂区里的一条主干道，货车、叉车、电瓶车全挤在一起，没有交警肯定乱套。机械工程师最熟悉“传动比”，而算力调度其实就是数字世界的“传动比”——你给哪个任务多分一点时间，它就跑得更快。
我见过一个小作坊，用同一台工控机跑SCADA和视觉识别。结果视觉一启动，SCADA的刷新率从100ms掉到500ms，操作台上数据直接变成幻灯片。这就是典型的没有调度的后果。更微妙的是，安全联锁任务必须实时响应，而数据记录晚几秒也没关系。这里有个概念叫“混合关键性”（Mixed-Criticality），按安全等级把任务分层，道理简单，落地却常常被忽略。
边缘算力和云端算力，怎么协同才不打架
现在的工厂离不开边缘，也离不开云。但边缘和云的算力调度，经常是两张皮。我遇到过一个案例，某汽车零部件厂把现场所有数据都往云上送，结果出口带宽不够，设备指令时延飙到300ms，拧紧枪动作直接不同步。后来我们把模型推理挪到边缘，云端只做训练和离线分析，时延才压回20ms以内。
这里有个核心参数：控制循环的截止时间。比如典型的伺服控制周期是1ms，那边缘侧的任务如果超时，要么硬件升个级，要么把非实时功能砍掉。按经验，边缘算力最好预留30%以上的冗余，否则数据突发一上来，系统立马喘不过气。
云端的算力调度更像“错峰用电”。我们让设备在夜间回传海量数据，用Kubernetes的CronJob特性，让算力集群凌晨自动扩容，白天再缩容。这样一来，云成本降了不少，数据处理也不卡了。
落地的关键是标准和协议，不是算法
很多人以为搞算力调度要懂一堆高深算法，其实第一步是统一通信模型和调度模型。机械工程师可能不熟OPC UA和TSN，但这两个恰是未来智能工厂算力调度的底座。OPC UA的PubSub模式可以给数据定义优先级，TSN则能在交换机层面预留带宽，保证关键帧不排队。
我们做过试验，把视觉检测的图像流和PLC的实时控制流混跑在同一个万兆网里。不开TSN时，图像突发流量会让控制帧的时延抖动达到几百微秒；打开TSN后，抖动直接降到微秒级，效果立竿见影。此外，PLCopen的Motion Control规范里对多轴同步的机制，其实也隐含了算力调度的思想。对了，别忘了IEEE 802.1Qbv标准，这是TSN的核心，值得花时间读一读。
算法选择？别迷信轮询，也别迷信绑定
网上很多教程教你用轮询调度，看起来公平，但在工厂里根本不够用。实时任务和数据采集任务的周期差异太大，轮询会让低期限任务被饿死。我们最后用的是优先级抢占加特权服务。但如果你在Linux上，注意PREEMPT_RT补丁不是万能的。我吃过亏，线程在四个核之间乱跳，缓存命中率惨不忍睹。手动把视觉算法绑在0、1核，控制任务锁在2、3核，性能才稳定下来。
还有，算力调度不是纯软件问题。功耗和散热也是资源维度。有些产线边缘机柜没加空调，夏天一到直接宕机。你问这算算力调度吗？算！硬件热设计跟不上，调度算法再牛也白搭。
一个简单的调度设计思路
根据我的经验，先画一张任务清单，每个任务标上周期、截止时间、重要度。然后分成三类：实时控制、近实时感知、非实时管理。分别匹配不同的优先级和硬件资源。比如视觉检测要求200ms内返回结果，那就放到边缘端的高优先级队列；设备历史数据可以攒到夜间上传，归到云端批处理。中间用消息队列做缓冲，既解耦又削峰。
这套思路我在好几个工厂试过，效果都不错。核心是把算力调度当成系统设计的一部分，而不是事后补救。你也别怕踩坑，多踩几次就知道里面那些弯弯绕绕了。
