上个月我们车间那套MES系统又卡了，调度看板转圈圈转得人心慌。后来一查，原来是服务器上的数据库查询把CPU吃满了。说实话，这种问题在工厂里太常见了——大家都盯着设备、盯着工艺参数，偏偏没人关心机房那些服务器到底扛不扛得住。
今天想跟你聊聊工厂算力资源这事。不是鼓吹什么数字化转型，纯粹是这几年踩坑踩出来的心得。你手头的PLC、视觉系统、仿真软件，哪个不靠算力撑腰？但算力这个东西，不是买台高配服务器就完事了，得费心思去匹配实际工况。
算力规划：先弄明白谁在消耗CPU
做算力规划之前，你得先搞清楚现场到底有哪些算力需求。我先说个我的经历：给一条自动化装配线做控制升级，原方案用一台老式工控机跑视觉算法，结果相机一开，平均帧率只有15，检测时还把PLC通讯拖到超时。当时把算法从OpenCV的CPU版本换成GPU版本，帧率立刻上到60，但GPU的功耗和散热又让机柜温度飙到55度。这就是典型的没有全局算力规划——视觉和运动控制抢同一个CPU，互相扯皮。
一般来说，工厂里的算力消耗大头有这么几类：其一是实时控制系统，比如PLC、运动控制器，这些响应时间通常要求在1毫秒到10毫秒之间，优先级最高；其二是实时数据采集与预处理，比如振动监测、温度热成像，采样频率可能高达100kHz，数据量巨大；其三是非实时的业务系统，比如MES、ERP、仿真计算，这类对延迟不敏感，但往往需要高并发。
说到C代码，我们常用IEC 61131-3标准，它规定了PLC的编程模型，但算不上算力指标。真正让你感觉到算力紧张的时刻，往往是PLC的扫描周期变长，或者HMI画面掉帧。你知道吗，一个带PID自整定的温度控制回路，在200MHz的PLC上就能转得飞起，但如果你非要在PLC里跑一个神经网络模型，那纯属自己找罪受。
算力规划的第一原则，就是区分硬实时和软实时。硬实时任务，比如急停、安全联锁，必须保证在极短的时间内响应，这时候任何调度延迟都不能容忍。而软实时任务像视觉检测，偶尔延迟个几毫秒也能接受。所以你在选型时，就得把这两种任务分到不同的计算单元上去。
举个例子，我们给一条焊接线做工艺监控，焊机电流电压信号以10kHz采样，每台焊机每秒产生20万个数据点。如果全部上传到中央服务器做分析，带宽和存储都扛不住。后来我们在焊机旁边加了一个边缘网关，先做特征提取，只上传统计指标，比如有效值、峰值、波形畸变率，数据量直接降到原来的百分之一。这个网关只需要一个四核ARM处理器就能搞定，成本不到一千块。
所以你看，算力规划的意义不在堆料，而在分流。别什么任务都往同一个CPU塞，该专用的专用，该共享的共享。
选型陷阱：多核高频率不是灵丹妙药
我见过不少同事选服务器，上来就问几核几线程。每次我都忍不住想反驳一句：你那个实时控制任务真的需要那么多核吗？实际上，PLC和运动控制器的RTOS通常只跑在一个核上，多余的核心往往闲置。更麻烦的是，通用CPU有一个大坑——中断延迟不可预测。你在跑Windows的工控机上写个高速脉冲输出，偶尔会抖动一下，就是因为Windows的调度器在背后搞事情。
这时候，你可能需要一个可预测的实时平台。常见的方案是走EtherCAT总线的运动控制，它需要一个专用的主站芯片或实时网卡，把周期抖动控制在微秒级。比依赖CPU主频更靠谱的是硬实时内核，比如Linux的PREEMPT_RT补丁，或者干脆上PLC专用的ASIC。
还有一次，我用一台带i9处理器的工控机做数据采集，结果采集卡DMA直传的内存带宽被核显抢占，导致波形出现周期性毛刺。后来把核显的显存分配调小，问题才解决。这类问题你说它是算力不足吗？不，是资源分配不当。
说到这里，我强烈建议你在选型时多关注缓存大小和内存通道数，而不是单纯看主频。比如做有限元仿真，计算矩阵乘法时，CPU的L3缓存对性能影响巨大。同样喝咖啡的时间，可能程序就快了一倍。另一个容易被忽略的是网络带宽，特别是当你用千兆网传视觉图像时，很容易成为瓶颈。我们现场就把视觉系统单独接在一台万兆交换机上，才保证了多相机并发时的实时性。
记住：算力的关键指标不止是算得快，还要算得稳、算得准。
边缘与云端：数据量决定分流策略
云端算力听着高大上，可在工厂环境里，延迟和带宽都是硬伤。我有个客户把设备数据全都传到阿里云上做训练，结果4G网络一卡，数据积压了半个多小时，直接导致模型失效。后来他们学乖了，把大部分推理任务放在边缘端，云端只做模型更新和离线训练，才算解决问题。
你计算一下就明白了：假设你有一条汽车零部件产线，有50台数控机床，每台机床的振动传感器以50kHz采样，每个样本16位，除以1024变成KB，每秒就是约1.25MB，50台就是62.5MB/s的持续数据流。这已经超过了百兆网线的传输能力，更别说到云端还要走公网。所以边缘端的数据预处理是必须的。
那么边缘计算到底该选什么硬件呢？目前工业界比较流行的是带GPU的紧凑型工控机，或者支持TSN的嵌入式平台。比如NVIDIA的Jetson系列，在目标检测任务上功耗只有几十瓦，非常适合现场部署。但我们之前用它跑过一种老旧的机器视觉算法，因为没有CUDA的对应实现，反而比纯CPU还慢——所以说，选型不能只看硬件参数，还要看软件生态是否匹配。
另一个关键点，是工业现场的环境恶劣。灰尘、温度、振动，对服务器都是考验。我们机房隔壁就是压铸车间，空气中飘着铝粉，隔三差五就得清理散热风扇。如果机箱没有做防尘设计，算力性能会随着温度升高而下降。这就是热降频的现象，你买再高的主频也撑不住。
所以我的习惯是，在机柜空调之外，再加装一个独立的风道，把服务器散热直接引到室外。这样既省电，又能保证CPU不因为过热而自我降频。
监控与优化：别等卡死才想起看监控
算力资源就像人的精力一样，你得时刻关注它的使用率。我见过有的工程师，程序跑起来之后什么都不管，直到某天发现产线停了两分钟才知道出了事。这太被动了。你至少得给服务器配置基本的CPU监控和告警，比如CPU使用率超过85%就报警。可别小看这招，去年我正是靠这招提前发现了一个机器人控制柜的潜伏故障。
那台机器人平时运行平稳，但CPU负载偶尔冲到90%，虽然程序没有明显问题，但我盯了几天，发现每次都是机械臂经过某个路径点时触发的。后来检查伺服参数，发现是一个扭矩补偿的计算量太大了，稍加优化就把峰值压到了60%。你看，算力优化和机械调校很像，都得基于测量数据来做决策。
还有一种常见情况是内存泄漏。我们有一套仿真软件，运行三天后模型计算速度明显变慢，重启后恢复正常。后来在任务管理器一看，内存占用每年递增，直到把系统挤爆。这种问题往往隐藏在第三方库里，你只能通过压力测试来验证系统的长时稳定性。建议在交付前跑满72小时的内存和CPU压力测试，比如用GCC编译安装或运行一个无限数据流脚本，看看有没有资源占用异常。用不着过度担心，但也不能忽略。
最后说一个我们正在尝试的优化思路：利用工业互联网平台把非实时的计算任务调度到工控机的空闲核心上，比如将统计报表生成放到深夜，这样能避免白天的资源争抢。但别指望任何商业软件能自动做到，你得自己写脚本，做一些任务编排。虽然有点烦，不过效果显著。
说白了，工厂算力资源管理这事儿，说难也难，说简单也简单。关键在于你要真正了解自己的工艺、数据和系统，然后做出合理的分层分配。别盲目追新，也别舍不得投入。算力够不够用，只有在产线停机的时候才真正暴露出来——那种感觉，大家应该都懂。
好了，先聊到这儿。回头有新的坑再分享。
