乌兰察布集宁区的这座智算园区，2024年下半年上线时，纸面算力8000P（FP16），但真实GPU利用率长期卡在62%。
运维负责人老周第一次给我看监控时，周均利用率就是这个数，凌晨2点到5点的低谷期只有41%。按当地0.35元/度的工业电价粗算，单日空转损失超过40万元。财务每个月都在催，因为签的SLA是85%，差23个百分点意味着要按比例返还机时费。
62%这个数字在智算圈其实不丢人。根据国家数据局2024年9月发布的《全国一体化算力网应用优秀案例》背景说明，大模型训练普遍存在“计算显存限制、风冷算力密度较低、智算资源利用率较低”三类问题，业内大盘常年落在50%-70%。但老周知道，园区承载的不是单一万卡训练任务，而是混合了千卡级预训练、百卡级微调、实时推理和高校科研的弹性作业——三套指令集、两套通信协议、一套自研液冷加两套风冷散热体系混跑在同一张400G RoCE网络上，问题比标准集群复杂得多。
第一刀砍在调度器的“装箱”逻辑上
园区最初用的是开源Volcano调度器加自研插件。AI作业不像Web服务可以均匀切片，千卡训练任务要求GPU必须连续分配在同一NUMA节点内，跨节点通信延迟一旦超过3微秒，all-reduce效率断崖式下跌。
Volcano的默认策略是BestEffort装箱，经常把千卡请求拆成两块500卡碎片放在不同集群，训练任务直接报NCCL/HCCL超时。团队统计发现，47%的调度失败都是碎片化导致的假性资源不足——集群明明有空卡，就是凑不出连续拓扑。
解法是自研拓扑感知调度器。新调度器在分配前先读取RoCE网络拓扑矩阵和PCIe Switch亲和表，将千卡请求锁定在同一个rail-optimized域内。针对昇腾910C集群，调度器直接调用HCCL的topo文件做预判，避免跨SuperPod分配。上线两周后，碎片化失败率从47%降到6%。
这里有个反直觉的决策：团队没有选择Kubernetes社区热推的Gang Scheduling全家桶，而是自己写了一个轻量级all-or-nothing分配器。原因很简单——Gang Scheduling的placeholder机制在高并发场景下会产生大量Pending Pod堆积，API Server压力陡增，反而拖慢整体调度吞吐。实测对比，自研分配器在8000卡规模下的调度延迟中位数是1.8秒，Gang模式是4.3秒。
第二刀砍在通信拥塞上
利用率爬到78%之后，瓶颈从调度转移到了网络。RoCE的PFC死锁和ECN误触发开始频繁出现，尤其是昇腾HCCL和英伟达NCCL混跑时，两种协议的拥塞控制算法互相踩脚。
最严重的一次事故：昇腾集群在做千卡checkpoint同步时触发PFC风暴，同一交换域内的H20推理集群被连带拖垮，推理延迟从12ms飙到800ms，持续11分钟。
团队做了两件事。第一，物理隔离——把昇腾和英伟达集群拆分到不同交换域，中间用ACL硬隔离，只保留存储网络互通。第二，在RoCE上叠加自研拥塞感知路由，实时采集交换机buffer occupancy，当某端口buffer超过60%阈值时，自动将新流路由到备选路径。
这套路由逻辑写在SmartNIC的DPU上，不占用GPU节点CPU周期。上线后，跨域通信拥塞导致的训练中断从每周7次降到0次，推理P99延迟稳定在18ms以内。
第三刀砍在故障恢复上
万卡级集群的GPU月故障率在0.5%-1.2%之间，8000P集群平均每周有6-8块卡报ECC错误或掉卡。传统做法是人工下线节点、重新调度任务，整个过程耗时40分钟以上。
团队实现了三级自愈策略：一级是GPU软复位，通过DCGM/Xid事件触发，自动reset GPU并重载驱动，耗时约90秒；二级是节点热迁移，把故障节点上的容器live-migrate到备用节点，耗时约5分钟；三级才是整节点下线重新调度。
配合checkpoint异步保存机制（每500步自动存一次到NVMe-oF分布式存储），三级自愈把故障恢复的平均耗时从42分钟压到7分钟。这对利用率的影响是直接的——故障恢复期间算力空转窗口大幅收窄。
异构适配的隐藏账本
很多人谈异构算力，先算的是CUDA到CANN的代码迁移成本。但这座园区的真实账本显示，迁移是一次性的，运行时兼容成本才是持续出血点。
最典型的是算子精度对齐。同一个Attention算子，在H20上用BF16跑出来loss曲线正常，移到昇腾910C上，因为算子内部累加顺序不同，loss在第3000步开始漂移，最终收敛值差0.3个点。团队花了三周，把CANN的matmul累加模式从fp32_ieee改成fp32_fast，再配合混合精度校准工具逐层对齐，才把loss曲线拉回一致。
这类隐藏成本在立项预算里通常不见踪影，但实际占用了异构算力池化项目30%以上的工程时间。如果你正在评估昇腾910C的迁移可行性，站内《H20之后，昇腾910C迁移账本》拆解了从Attention算子到HCCL通信的完整成本结构，建议先读那篇再动手。
90%之后呢？
今年6月，园区利用率稳定在90%上下。剩下的10%不是不想吃，是不敢吃。
运维负责人算过一笔账：如果把利用率推到95%，集群缓冲余量只剩5%，一旦突发大规模作业排队或节点批量故障，恢复时间会指数级拉长，可能引发连锁任务超时。这是集群韧性（resilience）和利用率之间的经典张力。他们选择留10%作为弹性缓冲，换来SLA达标率保持在99.7%。
根据《全球重点区域算力竞争态势分析报告（2025年）》的统计，国内智算中心平均利用率在55%-65%之间，顶尖园区能摸到85%，能稳定在90%以上的，全国不超过两位数。这座园区的18个月实战验证了一个判断：算力利用率的瓶颈不在硬件本身，而在调度策略、通信拓扑和故障恢复这三层工程细节。62%到90%的提升，没有靠换更贵的交换机或买更多GPU，而是靠把调度器、拥塞控制和自愈逻辑重新写了一遍。
对于正在规划万卡集群的团队，值得参考的站内文章包括：《万亿参数跑通之后：万卡国产算力中心的夜班生存指南》记录了昇腾910C集群的稳定性实战，《Rust重写推理调度器，性能账别只看吞吐》则从推理侧给出了调度器重构的另一种思路。
工程这件事，从来都是细节里藏着一半的算力。
