今年3月，深圳点亮了全国首个万卡级全栈自主可控智算集群，11000P新建成加上此前3000P，总规模达到14000P（来源：深圳特区报，2026-03-31）。消息令人振奋，但海淀8000P园区里，运维老张看着监控面板上的“算力利用率”曲线——峰值62%，大部分时间在45%上下徘徊——心里很清楚：卡多了，训练反而慢了，这不是个例。
买卡只是第一步，从纸面算力到实际吞吐，中间隔着一层“调度税”。这个税不是单点问题，它藏在通信、显存和任务编排的每一层抽象里。以下是从数十次千卡集群问题回溯中总结的三个主要漏点，以及一份可落地的调优checklist。
NCCL建链与AllReduce的慢动作
跨机AllReduce是千卡训练最频繁的集体动作。在昇腾910C集群上（参考从CUDA迁到昇腾910C的第三个月），默认的NCCL配置容易踩进两个坑：建链超时和协议选择不当。 建链阶段，每张卡需要与拓扑中所有对端建立RoCE连接。64节点、8卡每节点时，建链握手次数达512×511≈26万次。如果网络负载均衡策略不匹配，大量SYN包被同一网卡队列处理，建链时间能从秒级飙升到分钟级，触发NCCL超时重试。据H3C《智算网络技术白皮书》（2025），PFC死锁在同类场景下可使网络吞吐下降30%以上，而精准ECN流控能缓解，但前提是网卡和交换机协同启用。
运行阶段，AllReduce的算法选择影响更直观。NCCL默认的树算法在跨机场景中尾延迟偏高。阿里云灵骏（官方产品页）基于端网协同设计，将端到端时延压到2微秒，但大部分园区网络并未商用这类方案。一线经验是：对千卡规模，将NCCL_ALGO显式设为Ring并配合NCCL_PROTO=LL（低延迟协议），通常比Tree快15-20%；同时把NCCL_MIN_NCHANNELS提升到4以上，能更充分利用多路径。
显存碎片：算力池里的“隐形浪费”
大模型训练对显存是动态申请、随时释放的模式。在昇腾910C的HBM2e上，频繁调用torch.empty和torch.zeros会产生大量不连续碎片。据从CUDA迁到昇腾910C的第三个月中的实测，一个67B参数的MoE模型使用4D并行时，每张卡的可用显存因碎片损失约12%-18%，这部分直接被计数为已分配却无法参与运算。
更隐蔽的是多任务混合调度场景。微调、推理和评测任务同时运行时，显存释放不及时，导致后续大任务启动时触发OOM重调度，平均增加30分钟等待。采用显存池预分配策略（启动时按最大可能需求一次性申请）能缓解碎片，但会降低单节点任务密度——运维需要在碎片容忍度和资源效率之间反复测试。该文的九项检查清单中，特别提醒“禁用PyTorch缓分配器（PYTORCH_NO_CUDA_MEMORY_CACHING）”在昇腾环境下反而容易加剧碎片，需要针对华为CANN适配层单独调优。
异构调度的“手脚”比想象更长
8000P园区不是单一芯片池。昇腾910C、寒武纪MLU590、英伟达H20甚至少量Intel Gaudi3可能共用一个调度队列。任务在不同芯片间迁移时，隐藏成本有三层：
- 编译缓存失效：每个芯片厂商的算子库都有自己的JIT编译缓存（如HCCL vs NCCL vs MSCCL），切换到新型号时几乎需要重新编译所有融合算子，耗时10-20分钟。
- 数据预处理偏移：sharding逻辑依赖设备数，集群扩容或缩容后种子变化，导致训练效果波动。
- 容错重跑范围：不同芯片的checkpoint格式不兼容，故障后如果从最近的统一ckpt恢复，可能损失数小时进度。
8000P算力园区半年追踪的调研数据印证了这一点：入驻企业的调度排队等待时间平均占训练总时长的15%以上，其中近一半源于异构资源协商而非算力不足。
调优Checklist：五项可落地的运维动作
基于上述坑点，我们在日常运维中积累了以下措施，实测能将千卡集群的有效利用率从不足60%提到78%以上：
- NCCL环境变量硬编码：在启动脚本中设定
NCCL_ALGO=Ring、NCCL_PROTO=LL、NCCL_MIN_NCHANNELS=4。每批次任务附带网络拓扑文件，避免建链阶段随机路由。 - 显存池与碎片监控：添加
torch.cuda.memory_stats()埋点，实时输出碎片率。当碎片率超过15%时自动切换至预分配模式（具体参数见从CUDA迁到昇腾910C的第三个月的checklist）。 - 芯片亲和性分组：在调度器（如Slurm + Volcano）中设置节点标签，将同型号芯片任务固定到同组节点。跨芯片迁移仅允许在维护窗口操作，并提前预热算子缓存。
- 网络基线测试：每周运行
nccl-tests的all_reduce_perf，记录总线带宽和Algbw。当Algbw低于理论峰值70%时，排查ECN标记策略或交换机队列深度。 - 统一Checkpoint格式：所有任务强制使用Hugging Face Safetensors + 外部元数据文件，屏蔽底层设备差异。故障恢复时优先从最后一级OSS存储拉取，而非依赖节点的本地缓存。
算力池规模越大，调度开销的放大效应越显著。深圳14000P集群的建成验证了国产硬件堆叠的能力，但把千万亿次算力真正转化为训练效率，还需要运维工程师逐个微秒、逐字节地抠。这不仅是技术问题，更是园区运营从“卖卡”转向“卖服务”必须跨过的成本暗沟。
