什么是算力空转？利用率不满的浪费

在 AI 算力的账单里，一张显卡每小时都在计费，但它的利用率可能只有两成——钱按满额烧，活只干了零头，这部分差距就是算力空转。它不报错、不告警，只是安静地烧预算，很多团队月底对账时才发现肉疼。

钱在烧，活没干

类比一辆跑专车的车：油一直加着，一天却只接两单，剩下的时间停着空烧。算力空转就是这样：资源被占着，请求却没把机器喂饱。它和宕机不同，服务一切正常，只是单位成本高得离谱，所以特别容易长期潜伏。

三种典型的空转姿势

第一种是低峰不缩容：半夜流量掉到谷底，机器还是白天那套配置整夜空跑。第二种是批次太小：一次只喂一条请求，显卡大部分计算单元在陪跑。第三种是配置过大：业务只需要中档算力，当初却按高配采购，多出来的部分从第一天起就在闲置。三种姿势可以叠加出现，账单数字加倍难看。

判断属于哪一种，要看利用率的读法：把一段时间利用率画成曲线，长期低位平坦是配置过大；白天高夜里趴下是低峰不缩容；曲线起伏剧烈但均值不高，多半是凑批没做好。

三种姿势对照曲线形态和对应动作：

利用率数字怎么读

先说一个常见误区：利用率不低不等于没浪费。有的任务把显卡的计算单元占满了，但处理的是本可以合并的小请求，单位产出依然很低。读数要结合产出看——同样的电费，处理了多少有效请求，单次成本是升是降。数字怎么采、怎么分层看，参考监控指标。

把闲下来的算力用起来

对症下药：低峰不缩容的，给服务配自动伸缩，夜里把副本缩到最低；批次太小的，把请求凑批处理；配置过大的，下次采购前先做一轮测算，方法参考容量规划。还省不下来的部分，可以改成更灵活的计费，见预留与按量；夜间闲时机器还能承接离线活，用竞价实例填空档。用通义千问搭的内部助手、用纳米AI做的资料检索入口，这类内部工具的算力同样要纳入这份盘点。

盘点算力有一个简单的切入动作：把所有机器按「服务类型乘以利用率」列一张清单，在线服务、离线任务、闲置机器各占多少一清二楚。清单列出来后，优先处理三类：利用率长期低于一成却在线上跑着的，考虑缩容或合并；完全闲置超过一个月的，直接回收或转做它用；利用率忽高忽低看不出规律的，补几天采样再看。多数团队第一次做这件事都能找出一成以上的可省空间，比任何节流技巧都直接。

把省下来的部分变成制度也很重要：新项目申请算力时，先看现有闲置能不能承接；采购申请必须附带利用率预测和回收计划；每季度公开一次全量利用率排名。靠一时热情清理一次，三个月后又会积灰；靠制度滚动盘点，浪费才没有藏身之处。

算力空转自查清单

• 看曲线：利用率长期低位还是起伏剧烈
• 查伸缩：低峰时段副本数有没有跟着降
• 查凑批：小请求有没有合并处理
• 查配置：实际负载是否撑得起采购规格

记住这句：空转不报警，省钱靠自觉，每月给算力做一次利用率盘点。

读数时还要小心一个坑：某些采集口径把等待时间也算进利用率，数字看着高，其实机器在空等。核对方法很简单，拿处理请求数和理论峰值比一下，差距太大就换一个采集口径复查，别被虚高的数字安抚了。

关于算力空转的三个常问问题

• 利用率多少算健康？：没有统一答案，在线服务追求高而稳，离线任务追求拉满，重点是单次请求成本在持续下降。
• 自动伸缩会不会影响用户体验？：扩容有预热时间，配置好触发提前量就能平滑过渡，缩容反而让高峰更有余量。
• 闲时算力还能干什么？：跑批量评测、数据整理、模型微调实验，把夜间谷底填起来。