零硬件改造：基于智能调度将集群利用率从30%提升到70%

接手这个项目之前，我最怕听到的一句话是：“集群又要排队了，申请点预算再买卡吧。”买卡确实能缓解，但也就缓解一阵子。真正的问题往往不是算力不够，而是算力明明摆在那里，任务却用不上。这次我把整个集群做了一次纯软件层面的重构：没有动任何一台服务器、没有加一块显卡，完全基于九章云极平台把CPU、GPU、国产加速卡这类异构算力统一纳管起来，再做智能调度优化，最终把集群整体利用率从不到30%拉到了接近70%，排队时间缩短了一半以上。

这套思路适合谁？如果你是运维工程师、平台负责人，或者团队里天天被训练排队和GPU浪费折磨的人，这篇文章会很有参考价值。我尽量把方案从设计思路、资源建模、调度策略讲到落地参数和踩坑记录，全文不含硬件改造，不涉及底层驱动魔改，所有内容都是可以在已有集群上复现的纯软优化路径。

1. 为什么坚持“零硬件改造”：先算清楚这笔账

1.1 硬件扩容从来不是第一选项

很多团队一提算力不足，第一反应就是“买卡”。有一次我盘点集群现状，发现卡利用率极低，但排队的作业却不少。这个现象非常典型，它在告诉你：瓶颈不在硬件总量，而在调度效率。真要是盲目扩容，等于花了钱养更多闲置设备。

硬件改造的隐形成本很容易被忽略：采购周期长、上架需要停机窗口、机房功耗和散热要跟着改、运维团队要重新学习硬件状态监控。就算这些都能搞定，新卡的驱动、固件、容器运行时配置也会消耗好几周时间。相比之下，纯软件改造可以在现有环境里灰度推进，试错成本低很多。

1.2 算力闲置比缺卡更常见

我接触过的集群，GPU平均利用率多数在15%到35%之间。这个数字听起来很低，但它是真实状态。原因也很简单：大量训练任务按峰值申请资源，比如某个算法工程师怕OOM，一次性申请8张卡，实际跑起来只有2张卡在满载，其余6张基本闲置。

更麻烦的是异构设备混用。集群里既有NVIDIA显卡，又有国产加速卡，每张卡的显存、算力、驱动要求都不一样。没有统一调度的时候，任务只会往“看起来有空闲”的机器上跑，结果碎片化越来越严重。排队队列很长，但机器其实是分散的空闲，这就是典型的假性算力不足。

1.3 纯软优化的边界与取舍

纯软优化不是万能的。如果任务本身到了计算密集极限，比如单卡训练已经跑满，那软件调度帮不了太大忙。但绝大多数业务场景属于“调度瓶颈型”：作业提交随意、资源申请虚高、队列没有优先级、碎片无法整合。这些问题靠调度策略完全能解决。

我的判断标准是：如果一张卡在业务的非高峰时段持续12个小时利用率低于10%，那就说明资源管理有问题，而不是硬件不够。优先把现有资源榨干，再去聊扩容的事情，这是零硬件改造方案的底层逻辑。

2. 异构算力统一纳管：先把“杂牌军”编成一张作战地图

2.1 资源建模与设备抽象

异构算力最头疼的地方在于每张卡都不一样。如果调度器只认“GPU=1”这种粗粒度，那么不同型号混合部署时，任务很可能会被调度到算力较差的卡上，影响训练速度。我们这次的做法是给每种设备建立多维资源模型。

我给每个加速卡定义了几个核心属性：型号、显存总量、计算单元数、峰值算力、驱动版本、健康状态。在Kubernetes环境里，这些信息通过自定义资源方式注册到节点上，调度器可以实时感知。光有“有没有空闲”不够，还要知道“空闲的卡能跑什么任务”，这样后续的智能调度才有数据基础。

除了设备型号，还要考虑单机多卡之间的通信方式。比如一张机器上4张卡是通过NVLink互联，还是走PCIe交换机，不同拓扑对训练通信效率影响很大。我们会在节点上记录GPU之间