Technical Report
跨供应商 Disaggregated 推理:在 NVIDIA H100 和 AMD MI300X GPU 上运行 GPT-OSS-120B
March 18, 2026
本文档由AI自动翻译。内容可能存在不准确之处,如有需要请参阅英文原文。 查看英文原文
单一 GPU 包揽一切的时代正在终结
AI 数据中心在传统上围绕单一 GPU 型号构建——在预算范围内尽可能多地购买最新的 NVIDIA GPU,以相同方式部署,然后通过负载均衡器均匀分发请求。这种方法虽然简单,但与大规模 AI 推理的经济现实日益矛盾。没有单一的加速器架构能够适应所有工作负载,仅部署一种类型意味着某些硬件总是被过度配置或利用不足。
业界正在转向异构系统,将不同类型的加速器组合在一起,分别分配给最适合的工作负载。NVIDIA 在 GTC 2026 上明确了这一方向,展示了将 Vera Rubin GPU 与 NVIDIA Groq 3 LPX——一个包含 256 个 LPU 加速器(每芯片 500 MB SRAM,每加速器 150 TB/s 带宽)的机架——配对进行联合推理的系统。NVIDIA 指出,此前的推理架构迫使用户在交互性和吞吐量之间做出选择——“你无法三者兼得”(交互性、智能性和吞吐量)。LPX 通过在单一系统中将 GPU 的计算密度与 LPU 的超高速 SRAM 访问相结合来解决这一问题,声称在万亿参数模型上每兆瓦吞吐量可提高高达 35×。

同样的逻辑也适用于单一供应商产品线之外。现实世界的数据中心已经在混合使用不同代际的 GPU(B300 与 H200 并行)、不同供应商的 GPU(NVIDIA 和 AMD),以及完全不同类别的加速器(GPU 和 AI 加速器,如 Tenstorrent 处理器)。每种组合都根据工作负载开辟了不同的效率前沿。
Prefill-Decode Disaggregation
在利用异构加速器的各种技术中,最具代表性的是 prefill-decode disaggregation(PD disaggregation)。LLM 推理由两个计算特性截然不同的阶段组成。Prefill 阶段通过密集矩阵乘法并行处理整个输入提示,属于计算密集型。Decode 阶段以自回归方式逐个生成输出 token,每一步都从 GPU 内存中读取模型参数和 KV cache,属于内存带宽密集型。这两个阶段对硬件的需求根本不同。

PD disaggregation 将这些阶段分配到专用服务器节点上,将每个 GPU 分配给最匹配其硬件特性的角色。Prefill 节点以高吞吐量处理输入提示,并通过高速低延迟网络将生成的 KV cache 传输到 decode 节点。Decode 节点仅处理 token 生成,保持低且可预测的 token 间延迟。如果不进行这种分离,在集群中混合使用不同的 GPU 效果有限——每个节点仍然运行两个阶段,较弱的阶段将成为瓶颈。
跨供应商 Disaggregation 的挑战
单一供应商生态系统内的 PD disaggregation 已得到 vLLM、SGLang 和 NVIDIA Dynamo 等框架的支持。然而,将其扩展到跨供应商的场景——例如在 NVIDIA GPU 上运行 prefill,在 AMD GPU 上运行 decode——会引入一系列独特的工程挑战,现有的开源框架尚未解决。
最根本的障碍是缺乏统一的跨供应商通信层。NVIDIA GPU 依赖 NCCL,AMD GPU 依赖 RCCL,这些库无法互操作。不同供应商的 prefill 节点和 decode 节点之间的 KV cache 传输无法使用 GPUDirect RDMA 进行直接的 GPU 到 GPU 内存访问;数据必须通过主机 CPU 内存中转,在关键路径上增加延迟。此外,两个供应商生态系统使用完全不同的软件栈(CUDA vs. ROCm),需要独立的 kernel 实现、独立的模型编译,以及仔细管理 KV cache 内存格式以确保跨架构兼容性。最后,由于不同的 GPU 架构具有不同的计算带宽比,框架必须理解每种架构的性能特征,以在集群中最优地平衡 prefill 和 decode 工作负载。
MoAI Inference Framework:跨供应商 Disaggregation
MoAI Inference Framework 是唯一支持跨供应商 PD disaggregation 的生产级推理框架——在单一服务集群内将 prefill 和 decode 路由到不同供应商的 GPU。虽然 NVIDIA Dynamo、vLLM 和 SGLang 各自在其平台上支持 PD disaggregation,但没有一个能将此能力扩展到跨供应商的场景。
MoAI 通过供应商无关的抽象层解决了跨供应商挑战,该抽象层处理软件栈差异和特定架构的性能特征,并配合通信库实现不同供应商 GPU 之间基于 RDMA 的 KV cache 传输。数据中心运营商可以摆脱单一供应商锁定,在多个供应商之间分配硬件预算,并将每个供应商的 GPU 分配给性能表现最佳的工作负载阶段。
在本报告中,我们对一种特定的跨供应商组合进行了基准测试:NVIDIA H100 负责 prefill,AMD Instinct MI300X 负责 decode,服务 GPT-OSS-120B 模型。在四种 ISL/OSL 场景中,跨供应商配置与单一供应商 MI300X 集群相比,几何平均端到端延迟和吞吐量改善 8–9%,在最高负载工作下延迟最多降低 43%,吞吐量最多提升 67%。
系统架构
NVIDIA H100 和 AMD Instinct MI300X 具有根本不同的硬件特性,使其适合推理的不同阶段。
| NVIDIA H100 SXM | AMD Instinct MI300X | MI300X / H100 | |
|---|---|---|---|
| HBM Capacity | 80 GB (HBM3) | 192 GB (HBM3) | 2.4× |
| Memory Bandwidth | 3.35 TB/s | 5.3 TB/s | 1.58× |
| FP8 TFLOPS | 1,979 | 2,615 | 1.32× |
| L1 + Scratchpad | 256 KB per SM | 32 KB L1D + 64 KB LDS per CU | 0.38× |
MI300X 提供 H100 的 2.4× HBM 容量和 1.58× 内存带宽,这使其在内存带宽密集型的 decode 阶段具有结构性优势。相反,prefill 阶段以大规模 GEMM 运算为主,H100 更大的 L1 和 scratchpad 内存(每 SM 256 KB vs. 每 CU 96 KB)使其在峰值 TFLOPS 较低的情况下仍能保持更高的计算利用率。基于这些特性,我们将 H100 分配给 prefill,MI300X 分配给 decode。
测试了两种配置,每种均包含一个专用 prefill 节点和一个专用 decode 节点:
- 跨供应商(异构):H100 节点负责 prefill,MI300X 节点负责 decode。Moreh 实现了自定义的跨供应商通信层,通过 RDMA 传输 KV cache。当前实现通过主机内存中转数据;未来版本将增加 GPUDirect RDMA 支持,以实现跨供应商边界的直接 GPU 到 GPU 传输。
- 单一供应商(同构):MI300X 节点负责 prefill,MI300X 节点负责 decode。KV cache 传输使用启用了 GPUDirect RDMA 的 NIXL connector,允许通过 NIC 直接进行 GPU 到 GPU 内存传输,无需 CPU 中转。
后端推理引擎在 AMD MI300X 节点上为 Moreh vLLM,在 NVIDIA H100 节点上为 vLLM。尽管跨供应商配置使用的是经主机中转的传输路径而非硬件加速的 GPUDirect RDMA,计算与通信重叠技术有效地隐藏了传输延迟,尤其是在高负载工作下。
实验设置
使用了三台独立的服务器节点:一个 NVIDIA H100 节点(prefill),配备 8× H100 80 GB SXM GPU;两个 AMD MI300X 节点(一个用于 decode,一个用于单一供应商测试中的 prefill),各配备 8× MI300X 192 GB OAM GPU。所有节点通过 200 Gbps ConnectX-6 NIC 连接。
| Category | H100 Node | MI300X Node |
|---|---|---|
| CPU | 2× AMD EPYC 9654 (96-core, 2.4 GHz) | 2× AMD EPYC 9474F (48-core, 3.6 GHz) |
| Memory | 1,536 GB | 2,304 GB |
| GPU | 8× NVIDIA H100 80 GB SXM | 8× AMD Instinct MI300X 192 GB OAM |
| NIC | ConnectX-6 (200 Gbps) | ConnectX-6 (200 Gbps) |
| OS | Ubuntu 22.04.3 LTS | Ubuntu 22.04.4 LTS |
| Model | GPT-OSS-120B | GPT-OSS-120B |
| Precision | MXFP4 | MXFP4 |
| Parallelism | Tensor Parallelism (TP=8) | Tensor Parallelism (TP=8) |
| Backend Engine | vLLM 0.15.0 | Moreh vLLM |
目标模型为 OpenAI 的 GPT-OSS-120B,一个稀疏 Mixture-of-Experts (MoE) 模型,总参数量约 1168 亿,每个 token 的活跃参数约 51 亿。推理使用 MXFP4 量化和 tensor parallelism TP=8,因此每个节点的 8 个 GPU 构成单一模型 pipeline。Prefix caching 已禁用,以隔离每种硬件配置的原始计算效率。
测试了四种 ISL/OSL(输入序列长度/输出序列长度)场景:1K/1K、1K/8K、8K/1K 和 8K/8K。大多数场景的并发级别范围从 1 到 32,8K/1K 场景扩展到最多 256 以观察高负载下的行为。所有实验的请求速率固定为 REQ_RATE=8。每次测量前进行两次预热迭代,以消除内存分配、GPU kernel 初始化和 KV cache connector 握手带来的冷启动效应。
结果
以下表格比较了跨供应商(H100 prefill + MI300X decode)和单一供应商(MI300X prefill + MI300X decode)的性能。E2EL 为端到端延迟中位数(秒);TPS 为总吞吐量(token/秒)。E2EL Ratio 和 TPS Ratio 为跨供应商/单一供应商——E2EL ratio 低于 1.0 和 TPS ratio 高于 1.0 表示跨供应商优势。
亮点:高负载工作下的跨供应商优势
在长序列和高并发的高负载工作下,跨供应商 disaggregation 相较单一供应商基线实现了显著改善。
| ISL/OSL | CON | Cross E2EL (s) | Single E2EL (s) | E2EL Ratio | Cross TPS | Single TPS | TPS Ratio |
|---|---|---|---|---|---|---|---|
| 8K/1K | 256 | 190.52 | 256.62 | 0.74× | 12,107 | 9,030 | 1.34× |
| 8K/8K | 16 | 119.24 | 207.67 | 0.57× | 2,190 | 1,312 | 1.67× |
| 8K/8K | 32 | 214.75 | 324.80 | 0.66× | 2,417 | 1,540 | 1.57× |
| Geomean | 0.65× | 1.52× |
在 ISL 8K / OSL 8K 场景下,跨供应商配置在并发 16–32 时将 E2EL 降低了 34–43%,吞吐量提升了 57–67%。这些收益来自于将每个 GPU 分配给最匹配其硬件特性的推理阶段,并结合跨供应商边界管理 KV cache 传输的通信层。以下各节展示了四种 ISL/OSL 场景和不同并发级别的完整结果,说明跨供应商 disaggregation 何时以及为何具有优势。
ISL 1024 / OSL 1024
输入和输出均为 1,024 个 token——最轻量的工作负载——两种配置在所有并发级别上表现几乎相同。
| CON | Cross E2EL (s) | Single E2EL (s) | E2EL Ratio | Cross TPS | Single TPS | TPS Ratio |
|---|---|---|---|---|---|---|
| 1 | 5.32 | 5.32 | 1.00× | 381 | 378 | 1.01× |
| 4 | 6.42 | 6.39 | 1.00× | 1,165 | 1,234 | 0.94× |
| 8 | 7.28 | 7.30 | 1.00× | 2,139 | 2,175 | 0.98× |
| 16 | 9.09 | 9.24 | 0.98× | 3,402 | 3,333 | 1.02× |
| 32 | 11.66 | 11.39 | 1.02× | 5,198 | 5,086 | 1.02× |
| Geomean | 1.00× | 1.00× |
仅 1,024 个输入 token 时,prefill 在任一 GPU 上都能快速完成,每个请求的 KV cache 仅为几十 MB。由于 prefill 计算和 KV cache 传输都不是瓶颈,性能几乎完全取决于 decode 速度——而两种配置的 decode 速度相同。这证实了跨供应商操作不会引入固有的性能损失。
ISL 1024 / OSL 8192
短输入但长输出(8,192 个 token)时,decode 阶段占据了大部分总时间。跨供应商优势从并发 4 开始显现并持续扩大,在并发 32 时达到 29% 的 E2EL 降低和 46% 的吞吐量提升。长达 8K 的输出序列放大了 decode 端的拥塞效应:在单一供应商配置下,通过 NIXL connector 的未经调节的 KV cache 突发传输在整个输出生成过程中增加了 token 间延迟。
| CON | Cross E2EL (s) | Single E2EL (s) | E2EL Ratio | Cross TPS | Single TPS | TPS Ratio |
|---|---|---|---|---|---|---|
| 1 | 45.05 | 44.13 | 1.02× | 204 | 208 | 0.98× |
| 4 | 53.67 | 58.51 | 0.92× | 686 | 626 | 1.10× |
| 8 | 67.06 | 74.49 | 0.90× | 1,093 | 986 | 1.11× |
| 16 | 93.82 | 92.41 | 1.02× | 1,639 | 1,489 | 1.10× |
| 32 | 108.74 | 152.61 | 0.71× | 2,508 | 1,722 | 1.46× |
| Geomean | 0.91× | 1.14× |
ISL 8192 / OSL 1024
长输入(8,192 个 token)和短输出时,prefill 占总延迟的比例更大。在低并发(1–16)时,prefill 更倾向于内存带宽密集型,MI300X 的 5.3 TB/s 带宽使单一供应商配置占优。在并发 32 处出现明显的交叉点:随着 prefill 转为计算密集型,H100 的优势开始发挥,跨供应商配置在并发 256 之前保持领先(E2EL 改善 26%,吞吐量保持在 12,000 tok/s 以上,而单一供应商低于 10,000 tok/s)。
| CON | Cross E2EL (s) | Single E2EL (s) | E2EL Ratio | Cross TPS | Single TPS | TPS Ratio |
|---|---|---|---|---|---|---|
| 1 | 6.52 | 6.02 | 1.08× | 1,409 | 1,509 | 0.93× |
| 4 | 9.00 | 7.60 | 1.18× | 3,854 | 4,727 | 0.82× |
| 8 | 11.72 | 9.65 | 1.21× | 6,077 | 7,095 | 0.86× |
| 16 | 17.33 | 14.62 | 1.19× | 8,794 | 9,597 | 0.92× |
| 32 | 24.93 | 36.54 | 0.68× | 11,486 | 8,105 | 1.42× |
| 64 | 47.76 | 57.00 | 0.84× | 11,870 | 9,978 | 1.19× |
| 128 | 101.58 | 119.45 | 0.85× | 11,224 | 9,598 | 1.17× |
| 256 | 190.52 | 256.62 | 0.74× | 12,107 | 9,030 | 1.34× |
| Geomean | 0.95× | 1.06× |
ISL 8192 / OSL 8192
最重的工作负载结合了前两个场景的影响。在并发 1 时,由于 MI300X 在低并发下的带宽优势,单一供应商配置略快。从并发 8 开始,跨供应商配置明显领先——在并发 16–32 时,E2EL 快 34–43%,吞吐量高 57–67%。长输入和长输出的双重压力放大了 H100 在计算密集型 prefill 中的优势以及 decode 端的拥塞效应。
| CON | Cross E2EL (s) | Single E2EL (s) | E2EL Ratio | Cross TPS | Single TPS | TPS Ratio |
|---|---|---|---|---|---|---|
| 1 | 52.67 | 47.88 | 1.10× | 311 | 342 | 0.91× |
| 4 | 73.47 | 74.77 | 0.98× | 890 | 927 | 0.96× |
| 8 | 87.13 | 110.40 | 0.79× | 1,595 | 1,183 | 1.35× |
| 16 | 119.24 | 207.67 | 0.57× | 2,190 | 1,312 | 1.67× |
| 32 | 214.75 | 324.80 | 0.66× | 2,417 | 1,540 | 1.57× |
| Geomean | 0.80× | 1.25× |
主要发现
在所有四种 ISL/OSL 场景中,跨供应商配置(H100 prefill + MI300X decode)相对于单一供应商 MI300X 集群,实现了 0.92× 的几何平均 E2EL ratio 和 1.10× 的几何平均 TPS ratio(E2EL ratio 低于 1.0 和 TPS ratio 高于 1.0 表示跨供应商优势)。主要结论如下:
- 可行性已验证:NVIDIA 和 AMD GPU 之间的跨供应商 PD disaggregation 在所有测试工作负载中均可靠运行。MoAI Inference Framework 抽象了硬件差异,使运营商能够在单一服务集群中混合使用不同供应商的 GPU,不受兼容性限制。
- 低负载下性能持平:对于轻量工作负载(1K/1K)和低并发,两种配置的性能几乎相同,证实跨供应商操作不会引入固有的性能损失。
- 高并发下跨供应商优势显著:对于长输出序列的工作负载(1K/8K、8K/8K)或高并发场景(8K/1K,CON ≥ 32),跨供应商配置在延迟方面最多优于单一供应商 43%,在吞吐量方面最多优于 67%。两个因素共同作用:(1) 随着并发增加,prefill 变为计算密集型,H100 更大的片上内存(L1 + shared memory)更高效地处理密集 GEMM 运算;(2) 跨供应商通信层基于软件的传输缓冲防止了 NIXL connector 直接 GPU 内存路径导致的 decode 节点队列饱和。
- 互补的硬件优势:在低并发时,prefill 更倾向于内存带宽密集型,MI300X 的 5.3 TB/s 带宽使其占优。在更高并发时,prefill 转为计算密集型,H100 的计算密度提供了优势。MI300X 的 192 GB HBM3 和高带宽使其始终非常适合内存带宽密集型的 decode 阶段。
- 基于工作负载的优化至关重要:性能特征在不同序列长度和并发级别之间变化显著——在低并发时落后的配置在高并发时可以领先高达 43–67%。要充分发挥异构硬件的优势,需要根据实时工作负载模式动态调整 prefill/decode 分配、KV cache 传输策略和请求路由。MoAI Inference Framework 旨在自动化此优化过程,使运营商无需进行需要深入了解每种 GPU 架构和工作负载交互的手动调优。
结论
本研究表明,异构 GPU 集群可以像单一供应商配置一样有效地服务 LLM——在许多场景中甚至更加高效。通过将 NVIDIA H100 GPU 分配给计算密集型的 prefill 阶段,将 AMD MI300X GPU 分配给内存带宽密集型的 decode 阶段,MoAI Inference Framework 使数据中心运营商能够超越单一供应商锁定,根据工作负载特性而非供应商限制来设计 GPU 基础设施。
在最高负载的工作下,跨供应商配置将端到端延迟降低了最多 43%,吞吐量提升了最多 67%,相较于单一供应商 MI300X 集群。同时,结果表明性能特征会随着序列长度和并发的变化而发生显著变化——在轻负载下表现最佳的配置在重负载下可能并非最优,反之亦然。在规模化环境中手动应对这种复杂性是不切实际的。MoAI Inference Framework 通过自动化跨异构集群的工作负载感知 GPU 资源分配、KV cache 传输策略和请求路由来解决这一问题,使运营商能够在无需持续手动调优的运营负担下获得跨供应商 disaggregation 的性能优势。