摘要：本文来自实际工厂数字化改造项目的落地经验，针对中小离散制造工厂算力散乱、利用率低的痛点，讲清楚工厂算力资源统一调度管理平台设计的核心要点，以及落地过程中常见的踩坑点，给负责转型的中级工程师做参考。
为什么离散工厂的算力最后都成了一堆乱麻？
我前两年在长三角一家汽车零配件冲压厂做数字化改造，刚进去就碰到一件离谱的事。研发部要算新模具的成型仿真，全部门的工作站都占满了，找生产部借服务器，生产部说这条线的视觉检测要用，不能动。最后查了一圈，三个车间一共五台空闲的服务器，其中两台GPU性能比研发部的工作站还强，就因为分属不同部门，一直闲在那里跑日常日志，利用率不到5%。
这不是个例。根据工信部装备工业一司2023年发布的中小制造企业数字化转型调研报告，国内离散制造工厂的存量算力资源平均利用率不到21%。说白了就是，大家买算力的时候，都是按单个项目、单个生产线的峰值需求买，买完之后大部分时间都在闲着，真要用的时候又抢不到。
转产越来越快，多品种小批量已经成了常态，今天要开新线，明天要改模具，算力需求忽高忽低，全靠每个部门自己囤算力，太浪费了。
核心设计要点：别上来就堆开源调度框架，先理清楚工厂算力的特殊性
第一次做试点的时候，我也踩过坑。一开始觉得不就是算力调度吗，照搬互联网公司的k8s容器调度方案就行，上来就把所有旧设备都改成容器化，结果光改造成本直接超出预算32%，而且还有十几台老的Windows工控机，根本改不了，差点项目黄了。
说实话，工厂的算力跟互联网的数据中心算力根本不是一回事。互联网都是同构的云原生服务，工厂里是啥都有：老工控机、带专用GPU的视觉检测工作站、嵌入式算力板、研发的离线工作站，甚至还有新买的云服务器节点，全是异构的。
所以第一步，不是搭调度，是做异构算力接入适配层。我们最后改的方案，给所有类型的节点都装一个轻量代理，代理本身占用的系统资源不到1%，不会影响工控设备的正常运行，不管你是什么系统什么架构，只要能联网，就能纳进平台管理。不用淘汰旧设备，省了一大笔改造成本。
然后，一定要做任务优先级硬隔离，这是红线。按照GB/T 39116-2020《智能制造系统 互联互通要求》，生产现场的实时控制任务优先级，必须高于所有非实时任务，哪怕仿真任务再急，也不能抢生产任务的算力。我见过同行做项目没做隔离，调度的时候把冲压线的运动控制任务给挤掉了，直接停线两小时，赔了几十万，老板脸都绿了。
对不同类型的任务做算力分片就好，实时任务留专属算力保底，不能被抢占，非实时的仿真、训练、数据分析任务，就走动态调度，用闲下来的算力跑，互不干扰。
落地过程中最容易踩的坑，我帮你踩过了
第一个坑，算力冗余留不够。很多人做预算的时候，把所有节点的算力加起来，直接算能承接多少任务，完全忘了调度本身、网络传输都会消耗算力，跨车间传输大模型还会有延迟。一般来说，我做设计都会留足15%的冗余，超过10ms延迟的节点不调度实时任务，从来没出过错。
第二个坑，没做断点续跑的本地缓存。工厂电网不稳，万一区域断电或者断网，中心平台连不上节点，正在跑的仿真任务直接丢了，几个小时的工作白做。我们现在的设计是，所有任务都在本地节点存断点，断网了本地自己继续跑，网通了再把结果同步回中心，不用依赖中心平台的高可用，成本降了一半，可靠性还更高。
第三个坑，没做好部门配额和激励。之前试点的时候，各个部门都不愿意把闲算力共享出来，怕自己要用的时候没了。后来我们改了规则，每个部门有保底基础算力配额，共享出去的闲算力可以换算力积分，下次自己要跑大任务的时候，可以优先调度，积分不够才掏钱买。改完规则之后，不到一周，共享出来的算力就翻了三倍，大家都愿意放出来了。
第四个坑，把算力利用率当成唯一KPI。很多平台做了花里胡哨的看板，老板一看利用率从20%涨到60%，特别开心，实际任务排期反而变长了。核心指标永远是任务按时完成率，利用率只是顺带的结果，别搞反了。
不过话说回来，也不是所有工厂都得上这套平台。如果你的工厂就三五台设备，总共没多少算力需求，那完全没必要，浪费钱。
要是你已经有十台以上的智能设备，既要做生产检测，又要做研发仿真、工艺优化，算力不够用还一堆闲资源浪费，那真的可以试试。我们那个试点厂，改造完不到一年，省下来的新算力采购费用就有八十多万，新模具开发周期缩短了27%，投资回报比真的好看。
结论
现在工厂数字化转型，大家都热衷于买新设备上新系统，却很少有人回头盘活手里已经有的存量资源。工厂算力资源统一调度管理平台不是什么高大上的黑科技，本质就是把你已经花钱买了的资源，攒起来用到该用的地方，花小钱就能解决大问题。
