训推系统 ¶
前三节围绕统一访存,回答了 " 跨设备内存能否以可接受的代价被稳定兑现为 Goodput"。后两节分别讨论了通信运行时与 RAS 体系。本节将视角拉回到训练、推理与后训练这三个最终交付场景,讨论上述能力如何在真实负载下组合落地。
训练、推理与后训练对系统的压力画像并不相同。训练是强同步、周期性、批处理的执行流,核心瓶颈在梯度同步的通信开销和流水线气泡;推理是异步、随机到达、延迟敏感的执行流,核心瓶颈在尾延迟、KV Cache 管理和动态调度;后训练尤其是强化学习后训练,则把生成、奖励、更新三条异构链路耦合在一起,系统压力更多表现为长尾轨迹、样本陈旧度和多资源池协同。超节点的 HBD 能力在三种场景下被兑现的路径并不相同,面临的工程约束也不同。因此,本节不把它们只当作“几类应用”来排列,而把它们视作三类必须分开建模、又必须在同一资源底座上共同成立的系统负载。
训练系统工程 ¶
并行策略与超节点拓扑的匹配 ¶
大规模训练的核心工程问题是:如何将数据并行(DP
这一问题的真实规模远超直觉。以 NVIDIA Blackwell NVL72 为例,其官方技术白皮书披露,仅在单一 NVL72 机柜上运行 1.8T 参数 MoE 模型,TP、PP、EP、DP 四个维度的组合就产生了超过 2700 种候选并行配置。每一种在吞吐、延迟、显存占用和气泡率上的表现各不相同,且不存在一种在所有指标上同时最优的配置。这一数量级的组合爆炸意味着
关键原则是将通信密集度最高的并行维度放在带宽最高的互联层级内:
| 并行维度 | 通信模式 | 带宽敏感性 | 延迟敏感性 | 推荐互联层级 |
|---|---|---|---|---|
| TP | AllReduce / ReduceScatter | 极高 | 极高 | HBD 域内(NVLink / Scale-Up) |
| EP | All-to-All(动态路由) | 极高 | 极高 | HBD 域内 |
| PP | 点对点 Send/Recv | 中 | 高 | 域内优先,可跨域 |
| DP | AllReduce(梯度同步) | 高 | 可容忍 | 可跨域(RDMA / Scale-Out) |
MoE 架构的普及使 EP 通信成为新的关键路径。与 TP 的规则对称通信不同,EP 的 All-to-All 流量模式是动态、稀疏、非对称的,路由结果取决于每个 token 的 gating 输出。这意味着超节点互联不仅需要高聚合带宽,还需要低排队延迟和动态负载均衡能力。HBD 域内的全交叉互联在这一场景下的优势,不在于峰值带宽,而在于可控的尾延迟和无拥塞热点的均匀通信。
但现实训练系统中的并行谱系已经不止这四种。若只讨论 DP/TP/PP/EP,仍不足以解释现代训练软件栈的真实复杂度,因为工程侧还要继续处理显存冗余、长上下文激活占用以及自动并行搜索空间爆炸等问题:
- 优化器并行 / 参数分片:以
ZeRO为代表,把优化器状态、梯度和参数按运行时阶段进行分片与临时展开,核心目标不是提高单次通信效率,而是把显存冗余压缩到业务可接受区间。 - 长序列并行:当上下文继续拉长时,仅靠张量并行已无法自然消化激活压力,还需要序列维度切分、
Sequence Parallelism、Ulysses、Ring Attention等机制把内存与带宽压力重新分配。 - 自动并行搜索:真实训练部署面对的是数千级组合空间,人工经验只能给出起点,最终仍需要代价模型、运行时剖析和规则收敛共同决定可行配置。
进一步说,训练系统中的网络并不只是“一张用于同步梯度的网”。当系统规模继续扩大后,参数同步、训练数据搬运和管理控制流会自然分化为不同平面;如果这些流量仍被混放在同一调度与布线逻辑中,训练集群就很容易在并行策略尚未失效之前,先被跨平面干扰、拥塞扩散和资源错配拖垮。因此,并行策略与拓扑匹配不仅是把 TP/PP/EP/DP 映射到某种互联层级,更是在为参数面、数据面和业务面预留彼此可隔离的组织方式 1。
通信 - 计算重叠与低精度训练 ¶
训练效率的工程兑现度,很大程度上取决于通信能否被计算隐藏。核心技术包括:
- 梯度桶(Bucket)聚合:将反向传播产生的梯度按桶分组,桶满即触发 AllReduce,使通信与后续层的反向计算重叠。
- 分层同步策略:HBD 域内使用高带宽互联做快速 Reduce,域间使用 RDMA 网络做跨 Pod AllReduce,通过收敛比控制域间通信量。
- 流水线气泡压缩:
1F1B、Interleaved 1F1B和ZeroBubble等调度策略的选择,直接影响流水线效率。气泡率是训练 Goodput 的核心损耗项之一。
高带宽域内互联与慢速域间互联之间常常存在数倍的剪刀差,训练作业的并行策略设计必须围绕 " 域内近线速通信 + 域间收敛比 " 展开。这也是为什么超大规模训练越来越依赖“通信策略 + 调度策略 + 网络平面”联动设计。仅有高带宽互联并不足以自动得到高利用率;只有当作业调度能够理解跨 Pod 通信需求、网络侧能够针对关键链路做带宽倾斜、训练系统能够把大流量交互尽可能压缩在更小的域内时,通信 - 计算重叠才不会停留在理论上 2。
低精度训练则是另一条会直接改变训练系统组织方式的主线。它的意义不只是减少显存占用、提高张量核吞吐,更在于重新分配训练过程中“算力、内存、通信”三者之间的比例。若训练作业原本受计算限制,低精度会把瓶颈继续推向通信与内存;若训练作业原本已经受网络或 HBM 带宽限制,则低精度收益不会线性兑现。也因此,低精度训练在系统工程上至少包含三层约束:
- 数值稳定性:需要细粒度缩放、溢出检测、动态校准与必要的高精度回退路径。
- 内核与编译器兑现度:只有算子融合、内核实现与数据布局同步跟上,低精度的理论收益才不会停留在芯片规格层。
- 通信与运行时承接能力:混合精度
reduce、紧凑布局和格式转换若不能被通信库与内存语义层稳定承接,就会重新变成软件税。
Checkpoint 与训练稳定性 ¶
大规模训练的 Checkpoint 写出涉及 HBM → CPU 内存 → NVMe / 远端存储的多级数据搬运。HBD 域内的高速互联可以加速分布式快照的收集,但最终写出瓶颈往往在 PCIe 和网络 IO 上。异步 Checkpoint、增量快照与预写日志(WAL)等技术的工程落地,决定了 Checkpoint 频率与训练有效吞吐之间的权衡。
从长期运行视角看,Checkpoint 与容错也不只是“训练框架的一项功能”,而是大规模系统把故障损失限制在可接受范围内的核心机制。节点数上来之后,故障不再是低概率异常,而会变成持续背景噪声;如果恢复路径仍停留在人工介入、整作业重启或长时间资源重排,集群的理论峰值算力就很难被稳定兑现为有效训练时间 3。
在实际运行中,训练稳定性通常还要靠三层检测面共同支撑:第一层是进程与网络健康,如心跳超时、集合通信错误与链路异常;第二层是训练数值健康,如损失发散、梯度 NaN/Inf 与缩放失衡;第三层是数据与存储健康,如快照写出超时、恢复失败率上升和版本不一致。只有把这些信号组织成可分级处理的恢复机制,训练系统才能把“故障背景噪声”控制在 Goodput 可承受的范围内。
推理系统工程 ¶
进入推理时代之后,系统能力的评价对象已经不再是某一时刻的静态峰值吞吐,而是吞吐、交互性、成本与功耗共同构成的多目标边界。对真实业务而言,tok/s/gpu 只能描述局部能力,真正决定系统价值的,是在给定并发水平、给定用户交互要求、给定功耗约束和给定成本约束下,整套系统能够持续稳定产出多少有效 token。也正因如此,推理基础设施的竞争,正在从 " 谁的单项性能更高 " 转向 " 谁能在多重约束下更接近帕累托前沿 "。
推理优化的系统性挑战 ¶
推理系统优化常被简化为硬件性能比较问题,但实际工程决策通常并不对应单点 benchmark。线上推理服务的架构选择同时受到 TTFT、TPOT、吞吐、成本、扩展性等多方面约束。单个硬件指标可以帮助理解设备特征,却不足以直接支撑系统架构决策。
更根本的困难在于:不同团队使用的评估口径、benchmark 场景和指标 trade-off 经常不一致,导致方案难以横向比较、讨论反复拉扯。随着模型规模、GPU 成本与业务负载持续上升,只靠经验判断已经不够用。即便训练网络和推理网络复用同一套物理基础设施,两者也不应再被假设为相同问题:训练更关心同步效率和大流量收敛,推理更关心尾延迟、调度时效和局部热点控制;两者真正共享的不是同一组静态指标,而是都必须最终回到 Goodput、可服务能力和资源兑现度上来衡量。
推理系统的另一个难点在于,它同时承受“高并发、短时长、强实时”的调度压力。训练作业更接近批处理,推理服务则要求资源系统在更短时间内完成分配、回收和重平衡;一旦调度响应滞后于负载变化,就会出现部分实例排队、部分算力闲置、局部链路过热而全局利用率并不高的典型错配。这也是为什么推理优化最终会走向架构、调度和缓存策略的联合决策,而不是停留在单机 benchmark 比较 4。
这一阶段最值得重视的变化,是软件栈已经不再是硬件能力的附属物,而是持续改写系统可达边界的主变量。同一代 GPU 或 XPU,其真实推理能力并不是一个固定常数,而是会随着推理引擎、编译器、运行时、通信库和调度策略的演进不断变化。vLLM、SGLang、TensorRT-LLM、CUDA、ROCm 这类软件栈的快速迭代,实际上正在把 " 系统优化 " 从一次性的硬件交付,改写为持续进行的全栈协同过程。对超节点来说,这意味着软件系统不再只是兑现硬件能力,而是在重新定义硬件能力能够被兑现到什么程度。InferenceX 开源基准的持续追踪数据提供了一个直观的量化参照:同一块 B200 GPU 上,SGLang 推理引擎在 2025 年 10 月至 2026 年 2 月的四个月间,部分交互性水平下的单卡吞吐翻了一倍;AMD MI355X 上的 SGLang 在两个月内同样实现了近 2× 的吞吐提升 5。硬件没有变化,变化的只是软件栈——这正是 " 软件持续改写边界 " 的第一手产业级证据。
推理的帕累托分析框架 ¶
帕累托前沿为推理架构决策提供了统一的分析语言(详见第三章方法论落地案例
tokens/s/user:反映用户感知生成速度,是体验侧的硬约束代理指标。tokens/s/GPU:反映单位 GPU 吞吐,是成本与容量侧的核心变量。tokens/10k_rmb(可选第三维) :反映单位成本产出,在成本敏感场景下决定方案的最终可行性。
这组指标天然互相冲突:减小 batch 提升单用户速度但降低系统吞吐;增大 batch 提升吞吐但抬高排队时间与尾延迟。帕累托前沿将这些冲突显式化,把 " 打地鼠 " 式的局部调优升级为 " 在地图上定位并选择 " 的系统决策。
推理优化可分为三个层次:
- 可行区间 → 帕累托前沿(天级):通过
batch调整、量化、执行参数调优等手段,在现有架构不变的前提下,将当前配置推到前沿附近。 - 理论前沿 → 工程可达前沿(周到月级):系统调度、请求合并、缓存策略和实现细节决定了帕累托前沿上的点是否真正可达。安全边际(
Safety Margin)是度量工程兑现度的核心指标。 - 旧前沿 → 新前沿(月到季度级):
PD分离、异构 GPU 组合、新一代硬件接入等架构变化,不是在现有前沿里移动,而是把整条边界往外推。
推理系统的优化重点,也正在从单机内核效率转向运行时组织方式本身。disaggregated prefill/decode、wide EP、MTP 等技术所揭示的,并不是某一个局部技巧的价值,而是一个更深的系统事实:当模型规模、上下文长度和并发请求持续增长后,决定性能边界的往往不再是单个算子的速度,而是请求如何切分、阶段如何解耦、专家如何分布、缓存如何迁移、并行度如何编排。换言之,推理系统的竞争正在从 " 把模型跑起来 " 转向 " 能否把请求流、资源池与运行时调度组织成稳定的系统吞吐 "。
分离式推理服务架构 ¶
推理链路的 Prefill 和 Decode 两个阶段具有截然不同的资源需求画像:
| 阶段 | 计算特征 | 瓶颈资源 | 适配硬件特征 |
|---|---|---|---|
| Prefill | 计算密集,处理完整 prompt | 算力(FLOPS) | 高算力密度、高性价比 |
| Decode | 访存密集,逐 token 生成 | 内存带宽(GB/s) | 高 HBM 带宽 |
这一结构性差异为异构部署提供了工程基础:用算力密度高但带宽较低的 GPU 承担 Prefill,用带宽高的 GPU 承担 Decode,可以在不降低整体性能的前提下优化成本结构。
但一旦进入真实线上环境,PD 分离能否成立并不只取决于两类 GPU 的静态特征是否匹配,还取决于统一调度层是否能把不同阶段的资源需求及时拼接起来。否则,系统很容易出现 Prefill 侧排队而 Decode 侧空闲、或 Decode 侧成为全局瓶颈而 Prefill 侧算力被低效占用的错配现象。异构推理真正困难的地方,不是发现“哪张卡更适合哪个阶段”,而是让这种阶段性匹配在动态请求流下持续成立 4。
如果把推理拆得更细,系统工程问题还会继续下沉。对很多大模型而言,解码阶段内部的注意力子层更偏带宽 / 状态约束,而前馈网络更偏算力约束,这使“注意力池”和“前馈池”分离成为可能。它的价值在于把“高 HBM 带宽”和“高算力密度”分别扩出来;它的风险则在于配比极其敏感,一旦两个资源池规模失衡,中间同步点会迅速演化为全局阻塞。这意味着推理架构拆分得越细,越需要更强的统一调度面与容量预测能力。
下图展示了全场景、全架构的帕累托分布。横轴为用户感知生成速度(tokens/s/usertokens/s/GPUSLA 约束的最优配置。

全场景 tokens/s/GPU 与 tokens/s/user 帕累托分布。不同场景和架构的相对位置清晰展示了用户体验与单位算力效率之间的权衡关系。L40_P + A100_D 异构方案在多个场景下位于帕累托前沿上或其附近,而反向异构方案普遍被支配。
实证分析表明L40S(Prefill)+ A100(Decode)的异构分离方案在满足 SLA 约束后,相比纯 A100 聚合架构,Medium 场景成本效益提升约 31%,Long 场景提升约 45%。反向配置在多数场景中被支配,证实了阶段瓶颈与硬件特征之间存在方向性匹配关系。
但异构方案的成立是有条件的:
- SLA 稳健性非均匀:
Short场景余量充裕,Medium场景TPOT安全边际仅约3%,处于工程可达的边界。 - 价格敏感性显著:
L40月成本处于较低区间时优势明显,价格上升后优势会收敛,帕累托前沿的形状也会随TCO发生结构性位移。 - 规模扩展收益非线性:从
8卡到32卡,系统总吞吐近似线性增长,但TPOT并不单调改善,说明吞吐扩张与用户体验之间并不是简单线性关系。

全场景 tokens/s/10k_rmb 与 tokens/s/user 帕累托分布。将成本维度纳入分析后,帕累托前沿的形状发生显著变化,说明价格因素会直接改变不同架构的相对位置。
KV Cache、请求分发与服务优化 ¶
长上下文推理(百万 token 级)使 KV Cache 成为显存的主要消费者。在超节点范围内,KV Cache 的管理与统一访存直接相关:
- 分页显存管理(如
PagedAttention)将 KV Cache 切分为固定大小的物理块,通过逻辑 - 物理映射消除碎片化,但引入了页表维护和跨块访问的开销。 - 跨设备 KV 迁移在 HBD 域内可以利用低延迟互联完成,但需要第二章讨论的统一寻址和内存语义支撑,迁移的代价不在搬运本身,而在一致性维护和地址翻译。
- 冷热分层将高频访问的 KV 块保留在 HBM,低频块卸载到 CPU 内存或 NVMe。分层策略的有效性取决于访问模式的可预测性和迁移延迟与
Decode延迟的比值。
推理服务一旦进入多节点或分离式部署,请求分发也不再只是“把请求均匀打散”。它必须显式考虑缓存亲和性:相同或相近前缀是否命中已有缓存,当前实例的 KV 压力是否已接近阈值,请求剩余生成长度会不会拖坏整体尾延迟。更现实的分发顺序通常是:先命中前缀缓存,再看 KV 占用与队列长度,最后再按预计剩余生成长度分桶,以减少长尾请求对批处理的破坏。
推理系统并不只靠架构拆分获益,模型侧与服务侧优化也在不断重写前沿的形状:
- 模型结构优化:
MQA/GQA通过减少 KV 头数,直接压低解码阶段的带宽与容量压力。 - 参数、激活与 KV 压缩:后训练量化、权重量化、激活压缩与 KV 压缩的共同价值,不只是“更省显存”,而是让更高并发和更长上下文进入可服务区间。
- 投机推理:通过草稿模型生成候选 token、目标模型并行验证与必要回退,减少主模型的逐 token 调用次数,本质上是在用更多系统协同换取更低平均解码成本。
- 业务指标驱动的扩缩容:推理服务的扩缩容若只看 GPU 利用率,往往会错过真正的时延风险;更有意义的指标通常是排队请求数、排队 token 数、
TTFT、TPOT与 KV 分页压力。
因此,对推理基础设施而言,单位成本和单位功耗下的产出,正在比单点性能更接近真实经营指标。cost per million tokens 比峰值带宽更能反映一套系统是否具备长期可运营性,tokens per megawatt 则把电力、冷却和设施约束重新纳入了系统竞争的核心。InferenceX 基准的实测数据提供了一个更具体的参照:在 GB300 NVL72 上以 150 tok/s/user 的高交互性服务 DeepSeek R1 FP4,仅启用 MTP(Multi-Token Prediction)一项软件优化,cost per million tokens 就从约 $2.35 骤降至约 $0.11——同一硬件、同一负载,纯软件手段带来了约 21× 的成本下降 5。超节点时代的基础设施竞争,最终比拼的不是谁在规格表上更激进,而是谁能在现实的功耗、成本、交互性与稳定性约束下,把更多硬件资源稳定转化为更高质量的有效 token 产出。
后训练与强化学习系统工程 ¶
如果说训练系统工程解决的是“如何稳定消化大规模同步计算”,推理系统工程解决的是“如何稳定承接高并发低时延服务”,那么强化学习后训练解决的则是第三类问题:如何把生成、奖励、更新这三条异构链路组织成一个持续收敛的在线系统。
同步与异步后训练 ¶
同步范式更接近“按轮次采样、按轮次更新”的闭环:同一版本策略先生成整批轨迹,再统一计算奖励与完成一次或数次更新。它的优点是版本边界清晰、收敛分析更直接;缺点是最慢的长轨迹会拖住整轮吞吐。
异步范式则把生成、奖励、训练拆成可并行执行的资源池:生成端持续产出轨迹,奖励端并行完成规则校验、环境交互或奖励模型打分,训练端从经验缓冲区持续取样更新。它的优点是显著缓解长轨迹阻塞,特别适合工具调用、代理任务和长推理场景;代价是样本不再完全来自最新策略,系统必须显式控制“样本陈旧度”,否则更新偏差会反向吞噬吞吐收益。
长尾轨迹、奖励计算与沙箱 ¶
强化学习后训练最典型的系统问题,是轨迹长度天然长尾。样本之间会因为生成长度、思维链深度、工具调用次数和外部验证耗时而产生极不均匀的执行时间;若仍按同步批次硬等最慢样本,系统大量算力会在等待中空转。因此,工程上通常需要几种配套手段:
- 长度感知分桶与装箱:把长度相近的样本组织进同一批次,减轻尾部拖累。
- 异步流水与回压:用队列把采样、奖励与训练解耦,同时限制积压深度,避免样本过旧。
- 奖励计算沙箱化:当奖励依赖代码执行、工具调用或外部环境反馈时,安全隔离、资源配额和最小权限控制会从“平台附属能力”升级为训练前提。
微服务化与弹性扩缩容 ¶
强化学习系统在大规模实验和生产环境里,通常会自然拆成任务分发、演员推理、环境 / 工具执行、奖励计算、轨迹存储、学习更新和权重发布等多个服务。这样的拆分并不只是为了部署方便,而是因为这些环节的资源画像本来就不同:生成更吃算力和带宽,奖励更吃沙箱并发与外部依赖,训练更吃显存、同步和稳定性。因此,强化学习后训练的扩缩容也不能是统一副本扩张,而应围绕哪一条链路正在成为瓶颈来做弹性调节。
对超节点参考设计的启示 ¶
训练、推理与后训练三类负载,对超节点能力的需求画像差异显著,这直接影响第四章参考设计的适用性判断:
| 维度 | 训练侧需求 | 推理侧需求 | 后训练侧需求 | 对参考设计的含义 |
|---|---|---|---|---|
| 带宽 | 极高(梯度同步、EP All-to-All) | 高但间歇性(PD 分离后的跨阶段传输) | 高且波动大(生成、奖励、更新交替) | 训练更依赖 HBD 域内全二分带宽,后训练更依赖资源池之间的稳定衔接 |
| 延迟 | 可部分隐藏(通信 - 计算重叠) | 极敏感(TTFT/TPOT 直接影响 SLA) | 中等但对长尾敏感 | 推理对单跳延迟最严格,后训练更怕尾部长轨迹拖垮整体节奏 |
| 拓扑弹性 | 作业粒度调度 | 请求粒度调度,需支持异构混部 | 资源池粒度调度 | 推理和后训练都更需要动态拓扑重构与更细粒度调度 |
| 内存 | 显存容量为主(模型状态 + 激活值) | KV Cache 容量 + 带宽并重 | 轨迹缓存、奖励状态与模型状态并存 | 推理更依赖内存池化,后训练更依赖跨阶段状态管理 |
标准以太网方案的低延迟让步在训练侧可被通信 - 计算重叠部分缓解,但在推理侧可能直接影响 TPOT 级 SLA。MoE、长上下文和后训练长轨迹的兴起,又使推理侧和后训练侧的带宽需求不断向训练侧靠拢,模糊了三者原本较为清晰的边界。这进一步要求超节点方案在设计时兼顾三类负载的帕累托前沿,而不是只围绕单一场景优化。
从这个意义上说,训练、推理与后训练的统一工程目标并不是“使用同一套硬件”这么简单,而是让同一套系统在不同负载形态下都能维持较高的 Goodput 兑现度。训练更敏感于同步效率、故障恢复和长周期稳定性,推理更敏感于调度时效、尾延迟和资源重平衡速度,后训练则更敏感于长尾抖动、奖励链路与在线更新节奏;真正成熟的超节点方案,需要在这些压力画像之间找到可共享的资源组织方式,而不是让其中一种负载长期挤压另一种负载的工程空间
-
《超大规模智算集群关键技术及工程落地研究报告》, 2025 年 12 月 , 第 16-19 页。涉及节点间互联、
DCN前后端网络以及参数面 / 数据面 / 业务面分层组织。 ↩ -
《超大规模智算集群关键技术及工程落地研究报告》, 2025 年 12 月 , 第 18-19 页。涉及算存网协同、带宽适配、流量调度和跨架构资源联动。 ↩
-
《超大规模智算集群关键技术及工程落地研究报告》, 2025 年 12 月 , 第 27-28 页。涉及资源碎片、长期运行稳定性、故障频发、训练中断与快速恢复要求。 ↩↩
-
《超大规模智算集群关键技术及工程落地研究报告》, 2025 年 12 月 , 第 27 页、第 30-31 页。涉及智能体 / 推理业务的高并发、短时长、强实时特点,以及统一调度与场景化资源配置压力。 ↩↩↩
-
SemiAnalysis, "InferenceX v2: NVIDIA Blackwell Vs AMD vs Hopper", 2026-02.
https://newsletter.semianalysis.com/p/inferencex-v2-nvidia-blackwell-vs↩↩