“国内首个国产AI推理千卡集群落地”——这句话我在立项会上看到时第一反应是又来了一块硬骨头。千卡集群这四个字过去两年在PPT上见过无数次但真正从纸上走到机房才意识到把上千张国产加速卡组织成一台能稳定产出推理服务的机器难度远不是单机多卡的线性外推。网络怎么组、存储怎么挂、调度怎么排、故障怎么扛每一层都在挑战工程极限。这篇文章不写厂商宣传稿里的漂亮数据只讲我们在项目里踩过的坑、调过的参数、验证过的指标。如果你正准备从单机多卡走向大规模集群或者想评估国产算力平台能不能扛起生产级推理任务这篇应该能帮你省下不少试错时间。1. 千卡集群的真实目标不是算力堆叠是系统工程1.1 从“能用”到“好用”四个必须解决的工程瓶颈一千张卡单卡算力再强组织不起来就是一堆昂贵的装饰品。我们项目复盘的时候把瓶颈归成四类网络、存储、调度、容错。先说网络。千卡规模下AllReduce这类集合通信正常情况下占整体训练时间的10%-20%。听起来还能接受但网络一旦拥塞通信时间占比会直接飙到40%-50%。这意味着模型参数同步花的时间比计算本身还长训练迭代时间被拉长一倍以上。这时候你加再多的卡算力也喂不饱。再讲存储。训练数据读取、checkpoint写入是千卡集群的隐形杀手。存储带宽跟不上GPU只能空转等数据利用率肉眼可见地往下掉。我们项目里数据准备效率提升了3倍不是靠买更贵的盘而是把数据管线和计算管线真正并行起来。然后是调度。千卡集群不是一千张卡只跑一个任务而是几十个任务同时抢资源。调度器不给力就会出现一台机器GPU利用率90%、另一台只有30%的荒诞场景。碎片化的算力浪费单靠加卡永远补不回来。最后是容错。千卡规模下每天都有概率坏一两张卡。没有故障自愈能力一个小故障能让整个集群停摆半天。我们最后把容错指标磨到“3个9”的水准这块投入的精力一点都不比网络调优少。1.2 全链国产被倒逼出来的深度适配说句实话项目启动前我们评估过直接用成熟进口方案文档齐全、坑都被前人踩平开发和运维成本都低很多。但这次集群要求全链国产加速卡、交换机、服务器、训练推理框架全部用国内方案。一开始我们觉得这是给自己上难度后来发现这个决定逼着我们啃下了很多以前靠“黑盒”绕过去的问题。比如国产加速卡的驱动和通信库对RoCE无损网络的支持程度、不同厂商加速卡混部时的调度兼容性、推理引擎在非CUDA生态下的适配改造。这些问题在成熟生态里根本不会暴露但在国产平台上每一个都要亲手解决。也是在这个过程里我们看到了国产算力平台这几年的真实进步。这次落地的集群训练效率做到了90%左右推理服务成本相比进口方案降低了70%虚拟化损耗被压在5%以内。这些数字放到三年前没人敢打包票。全链国产从“能不能用”走到“好不好用”差的正是这一层一层的工程打磨。2. 组网与网络调优千卡集群最容易翻车的地方2.1 三层网络架构计算、存储、管理各走各的道千卡集群的网络不是一张大网而是三张各司其职的网我们称它为三层组网。第一张是计算网络承载东西向流量也就是GPU之间的AllReduce、AllGather等集合通信。它要求极低的延迟和极高的带宽因为每一轮训练迭代都要同步梯度。第二张是存储网络承载南北向流量训练时读数据、写checkpoint。它对带宽要求高但延迟敏感度比计算网络低。第三张是管理网络走带外管理通道IPMI、SSH、监控采集都靠它。带宽要求最低但对可靠性要求最高——计算网络挂了可以断点续训管理网络挂了连故障出在哪都查不了。不少团队第一次搭千卡集群为了省事让计算和存储共用一张网。结果训练一跑起来数据读取和梯度同步互相抢带宽两边一起慢。我们这次一开始就把三张网做物理隔离后续调优时省了大量精力。这个决定现在看来非常值。2.2 RoCE v2还是IB价格、性能与场景的三角权衡组网方案第一个选择题IB还是RoCE我们把两组数据摆在一起对比过。IB组网在AI训练场景下性能预计能提升30%以上但价格大约是RoCE v2的三倍。RoCE v2的优势是便宜成本只有IB的三分之一左右而且能和现有以太网生态无缝对接。如果你的任务对延迟不那么敏感RoCE v2完全够用。但RoCE有一个众所周知的痛点它本质上是“在以太网上用软件模拟IB的无损能力”。要实现无损传输必须依赖PFC优先级流控和ECN显式拥塞通知两个机制配合。PFC保证不丢包ECN提前告诉发送端“我要堵了你慢点”。这套机制配置不好RoCE的性能会断崖式下跌。我们最后的选型是推理集群用RoCE v2训练集群用IB。理由是推理任务的通信模式相对可控RoCE的成本优势能充分体现训练任务的通信模式更复杂IB的稳定性和性能更让人放心。这个搭配在成本和性能之间找到了平衡点。维度IB组网RoCE v2组网性能增益AI训练性能预计提升30%以上性能接近但依赖PFC/ECN调优成本约为RoCE的3倍约为IB的1/3网络生态专用网络需要独立布线兼容现有以太网适用场景大规模训练、延迟敏感任务推理服务、延迟不敏感任务2.3 PFC和ECN调优实战从死锁到吞吐减半的坑这块在RoCE网络上踩的坑最多单独拿出来讲。先说PFC死锁。PFC的原理是当交换机buffer快满的时候往上游发暂停帧让上游先别发。这个机制单看没问题但在多流场景下一个端口的暂停可能引发多米诺效应——A在等BB在等CC又在等A谁都动不了。我们实测碰到过这种情况带宽利用率到90%就再也上不去服务器间通信延迟从正常的1ms飙升到50ms左右。在千卡集群上这个状态等于训练直接停摆。解决办法是调PFC的水位线。交换机的buffer里有高水位线和低水位线高水位线决定什么时候触发暂停低水位线决定什么时候恢复。设得太高buffer容易积压引发死锁设得太低频繁触发暂停性能又下去了。我们最终把高水位线调到buffer的80%左右低水位线调到40%左右具体数值因交换机型号而异再配合ECN阈值调整才把延迟压回正常水平。再讲ECN。ECN在网络设备拥塞时给报文打上标记接收端收到标记后会通知发送端收缩发送窗口。这里有个经典问题如果发送端收到拥塞通知后窗口收缩太慢网络吞吐会持续恶化。还有一个更隐蔽的坑——即使第一跳网络并不拥塞中间交换机的buffer不够时ECN也会被标记结果吞吐量直接减半。我们查了半天最后定位到是交换机buffer配置不合理加上ECN的K阈值没有针对千卡流量特征重新标定。注意检查PFC是否正常开启可以用roce_exporter或dcb工具建议直接装无损网络工具集UCF做官方安装和检查。别自己手动瞎配RoCE的参数耦合性很强一个参数错了表面上只会看到莫名其妙的性能下降定位起来非常痛苦。3. 训练与推理的协同优化打满算力的关键3.1 混合并行策略三种并行怎么配千卡集群上的训练几乎没有只用一种并行策略的。要打满算力得用混合并行——数据并行、张量并行、流水线并行组合起来。三种策略的通信模型完全不同先给结论并行策略通信频率通信量通信时机数据并行高频小包每个step一次AllReduce张量并行高频大包每层前向和反向各2次流水线并行低频大包只在stage边界传输激活值数据并行是每个step都要做一次全归约AllReduce通信量约等于2倍模型参数总量模型越大通信量越大。张量并行因为模型参数被切到多张卡上每一层都要做通信训练时每层4次通信。流水线并行只在stage边界传激活值频率最低但对stage切分的均衡性要求很高。这里有个关键点三种并行策略对网络资源的需求完全不一样。数据并行受限于网络延迟张量并行受限于网络带宽流水线并行受限于切分均衡性。所以设计并行方案时一定要先看清楚网络拓扑再决定每个维度怎么切。我们这次是数据并行加张量并行为主少量流水线再配合序列并行处理长上下文最后才把MFU推到90%。PyTorch 2.4之后deviceMesh和DTensor的出现让分布式训练从手动多进程多卡转成了更自动化的方式。deviceMesh可以创建通信子组比如按节点内和节点间分组从而做分层AllReduce——先做节点内的走NVLink带宽高再做跨节点的走网络这样能显著降低跨节点通信量。不过提醒一句具体收益要看你的网络拓扑和模型通信模式别直接照搬社区里的配置。3.2 AllReduce与木桶效应通信占比飙升的真相AllReduce是分布式训练的命脉。每一轮迭代所有GPU都要把自己的梯度规约成全局梯度。通信量是2倍模型参数总量参数越大通信量越大。正常情况下AllReduce通信时间只占整体训练时间的10%-20%。这个数字一旦失控会很可怕。我们遇到的典型问题就是木桶效应collective通信要求所有rank同步所有rank必须等最慢的那个rank的梯度。假设某个节点的网卡性能下降50%其他7个节点再快也没用整体训练速度会被直接拖到和这个坏节点一样。更隐蔽的是RoCE网络里的PFC会把局部拥塞扩散成全局拥塞。本来只是两台机器之间通信拥塞PFC一介入整个网络都被暂停全部训练降速。这就是为什么千卡集群的网络监控必须细到每张网卡不能只看平均值。我个人的经验是训练集群里网络调优的优先级远高于算力调优。先把延迟、带宽、拥塞控制搞定再回头调batch size和并行策略否则你在算力层做的优化都会被网络吃掉。我们早期跑2机16卡任务时集群利用率只有30%-40%排查发现任务全在下发同步时排队等网典型的木桶效应。跨机通信带宽只有36GB/s这个瓶颈在千卡规模下会被放大几十倍。3.3 推理引擎选型vLLM、SGLang、TensorRT-LLM怎么选集群不光是训练推理才是持续产出价值的环节。推理引擎我们重点对比了三个vLLM、SGLang、TensorRT-LLM。vLLM是生产环境用得最多的核心优势是连续批处理和PagedAttention。连续批处理让GPU不用等一个batch完全结束就能接收新请求PagedAttention解决了KV cache的显存碎片问题显存利用率非常高。我们的线上推理服务主要跑在它上面。SGLang的特点是RadixAttention能自动缓存公共前缀特别适合多轮对话、多智能体这类前缀高度复用的场景。它的代码能力不弱吞吐数据也很亮眼。如果你的业务是Agent类应用居多SGLang值得认真试一次。TensorRT-LLM的优势是极致性能在闭源GPU生态下能把单卡性能压到极限。但到了国产算力平台适配和优化的工作量会大不少除非你有专门团队持续投入否则不建议作为首选。推理引擎核心优势适合场景国产算力适配难度vLLM连续批处理 PagedAttention通用生产推理中等社区适配活跃SGLangRadixAttention前缀缓存多轮对话、多Agent中等TensorRT-LLM极致单卡性能闭源GPU专用高需要深度定制推理侧的性能指标也值得记录。我们实测千卡集群上十亿级参数模型稳定运行100天无故障P99延迟控制在百毫秒内吞吐3000 tokens/s系统级推理chat回复延迟1.3秒左右。这套数据说明国产推理集群在性能上已经具备大规模商用的底子。4. 工程化验收用数据说话4.1 训练效率与推理延迟别只看平均值千卡集群工程化成不成功不能靠感觉要靠指标。我们最关注三类训练效率、推理延迟、可用性。训练效率看MFUModel FLOPs Utilization模型浮点运算利用率。MFU衡量的是GPU算力有多少真正花在了有效的矩阵运算上。普通集群MFU能到40%-50%就算不错我们最终做到了90%左右。这是混合并行策略、网络调优、存储管线联合优化的结果缺一环都到不了这个数。推理延迟看P99而不是平均值。P99意味着99%的请求都在这个延迟以内比平均值更能反映真实体验——长尾请求才是用户能感知到的卡顿。百毫秒内的P99延迟配合3000 tokens/s的吞吐已经可以支撑比较流畅的对话体验。吞吐量看的是系统整体不是单卡。单卡吞吐和集群吞吐是两个概念。集群吞吐受调度器、负载均衡、模型并发的整体配合影响单卡性能再好调度不均衡一样白搭。我们在上线过程中反复调整负载均衡策略才把集群吞吐稳定在目标值。4.2 容错与弹性伸缩“3个9”是磨出来的一千张卡单卡年故障率哪怕只有1%整个集群每天都有卡处于故障边缘。容错是千卡集群的必修课。我们定下的目标是“3个9”99.9%的可用性。拆解成硬指标就是节点故障检测60秒内完成容器秒级拉起断点续训15分钟内完成。故障发生到恢复训练全过程控制在15分钟左右这是用户可接受的下限。这里最花功夫的是checkpoint机制。千卡集群的checkpoint文件经常是TB级别写入和恢复都是大工程。我们做了两件事一是checkpoint异步写入不阻塞训练二是断点续训时只恢复必要状态不从头加载全部参数。这两件事加起来才把恢复时间压缩到15分钟内。弹性伸缩相对好做一些做到分钟级就行。流量高峰时把推理实例扩出来低谷时缩回去。但要注意扩缩容不只是起容器还要把模型加载、KV cache预热这些时间算进去否则用户感知到的还是慢。我们遇到过扩容完成后前几个请求延迟特别高的现象后来发现是KV cache预热没做好补上这个环节才解决。4.3 GPU池化与调度把碎片算力捡回来接前面说的负载不均衡问题。我们早期跑任务时某个GPU利用率是0的情况很常见集群整体利用率只有30%-40%。排查下来发现都是同一个原因任务在下发同步时排队等网算力再强也只能干等。后来的解法是GPU池化加vGPU调度。把物理GPU变成可切分的资源池支持混部和分时调度。小任务不用独占整张卡几个任务可以共享同一张卡的算力和显存碎片化浪费立刻减少。虚拟化损耗控制在5%以内这个代价换来的利用率提升非常划算。不过GPU池化不是银弹。vGPU调度会引入隔离问题、显存超分问题。我们踩过的坑包括某个任务的显存超分把其他任务挤到OOM混部时高优先级任务被低优先级任务抢占带宽。这些细节都要在调度器层面做精细控制。NVIDIA vGPU、AMD MxGPU、字节跳动的vGPU池化方案我们都调研过最终是根据自己的调度器特点做了定制改造才把混部效果调到比较理想的状态。5. 给后来者的实操清单从单卡到千卡的五个层级5.1 逐层拆解先跑通再跑满如果你的团队正面临同样的跨越我建议把路径拆成五个层级一层层过。第一层节点层级。单机8卡的NVLink/NVSwitch拓扑要彻底搞明白这是所有通信的地基。可以用NVLink带宽测试工具跑一遍确认拓扑识别正确。第二层单机多卡层级。先把AllReduce跑对确保单机内梯度同步不成为瓶颈。这一层过不了后面全白搭。第三层多机多卡层级。这一步最容易翻车跨机通信带宽、网络拓扑、网卡队列都要逐个验证。我们之前2机16卡任务跨机通信带宽只有36GB/s这个数字在千卡规模下会被放大几十倍。第四层数据中心层级。存储、网络、调度联合优化前面讲的三层组网、PFC/ECN调优都是这一层的核心工作。第五层永不宕机层级。容错、弹性伸缩、故障自愈做到前面说的“3个9”。五个层级每一层都有独立的验证方法不该跳过。很多团队一上来就铺千卡结果前三层的坑一起爆排查起来连头绪都没有。按层级推进每个层级都有清晰的前置条件和验收标准出问题时也能快速定位。5.2 落地节奏与可复用的经验最后分享一下我们的落地节奏和几条能直接用的经验。节奏上分三个阶段小规模验证、中期压测、全量上架。小规模验证用2机16卡把训练、推理、容错三个主流程全部跑通确认基础链路没有问题。中期压测用百卡规模把网络调优、调度策略、checkpoint机制全部验证一遍这时候发现的参数问题还来得及改。最后才部署到千卡规模。我们百卡压测阶段就发现了PFC水位线和ECN阈值有问题改完才敢上千卡否则整个集群通信瘫痪的风险极高。几条经验每一条都是真金白银换来的第一不要低估数据管线的重要性。FileReader的块大小不是随便设的。我们最后用的公式是块大小 数据总量 × 单节点batch size / 总batch size。这个参数直接决定数据读取的并行度设不好GPU就在等数据。训练数据读取尽量从SSD直接读别从显存buffer反复拷贝配合CPU预取能进一步降低等待时间。第二网络参数务必先小规模验证再全量下发。PFC、ECN这些参数在16卡上可能完全没问题到千卡规模就会触发死锁。我们就是在百卡阶段发现通信量上来之后延迟飙升连夜调参才避免了大事故。第三监控一定要做到卡级。千卡集群的平均指标没有意义必须实时看到每一张卡的利用率、每一块网卡的流量、每个交换机的buffer水位。我们就是靠卡级监控第一时间发现了一次网卡性能下降50%的隐性故障及时做了隔离和迁移避免了集群级的木桶效应。第四别省管理网络的钱。管理网络独立组网看起来多花钱但在故障排查时它可能是你唯一的救命稻草。我们有一次计算网络出现异常就是靠管理网络登录所有节点采集日志才定位到是某个交换机的buffer配置问题。最后说点个人感受。这个项目做下来我最深的一个体会是千卡集群的难点永远是“组织”而不是“堆料”。单卡性能再好网络一堵、调度一乱、故障一拖整体效率立刻跌到脚踝。国产算力这几年的进步是实打实的但硬件只是地基真正让用户敢用、愿用的是上面这一层层的系统工程打磨。如果你是刚接触这个领域的工程师别被“千卡”两个字吓住按那五个层级一层层验证大概率能比我们少走很多弯路。这套路径我们走大半年才趟平希望这篇能帮你把前面最难的那段路缩短一点。