摘要：长期以来，业界一直有观点认为，在总拥有成本（TCO）下，AMD 的 AI 服务器推理性能优于英伟达。过去六个月，本文通过对英伟达和 AMD 提供的推理解决方案进行全面分析与基准测试，对这一说法展开了调查验证。原本期待得到一个简单结论，但结果远比想象中复杂且令人

本文由半导体产业纵横（ID：ICVIEWS）编译自semianslysis

AMD or NVIDIA?

长期以来，业界一直有观点认为，在总拥有成本（TCO）下，AMD 的 AI 服务器推理性能优于英伟达。过去六个月，本文通过对英伟达和 AMD 提供的推理解决方案进行全面分析与基准测试，对这一说法展开了调查验证。原本期待得到一个简单结论，但结果远比想象中复杂且令人意外 —— 不同任务（如聊天应用、文档处理 / 检索、推理任务）的性能表现存在显著差异。

对于直接拥有并运营 GPU 的超大规模企业和企业客户，本文发现：在某些工作负载中，英伟达的每美元性能（perf/$）更具优势；而在另一些工作负载中，AMD 的每美元性能更优。但对于通过 Neoclouds 进行中短期租赁（租期不足 6 个月）的客户，英伟达的每美元性能始终占优 —— 这是由于 AMD 的 Neoclouds 生态缺失，导致 MI300X、MI325X 的租赁市场价格高企；相比之下，英伟达 GPU 拥有数百家提供 H100、H200 等显卡租赁的 Neoclouds，形成了竞争性的市场租赁价格。

AMD MI355X 本应是 B200 的竞争对手，MI325X 则被视作 H200 的对标产品。但正如后文将谈到的，MI325X 的发货延迟导致其进入市场时，大多数客户已选择跳过它而转向 B200。

在 2024 年 12 月发布 AMD 培训文章之前，本文从 2024 年第三季度起就与 AMD 展开了密切合作。AMD 已采取行动改善其推理解决方案的开发者体验与质量，并增加了持续集成（CI）自动化测试。近六个月后，本文认为有必要进行重新评估。测试显示，尽管 AMD 迄今已做出有意义的改进，但本文仍认为其存在较大提升空间—— 后文将讨论遇到的问题及 CI 覆盖不足的情况。

推理的解码阶段往往受内存带宽限制，因此两大核心系统规格为 HBM 容量和带宽。测试显示，单个 MI300 节点（1536GB HBM 容量）相比 H100 节点（640GB HBM 容量）具有显著优势 ——H100 甚至无法在单节点中容纳 DeepSeek V3 FP8 模型。英伟达于 2024 年第三季度大规模量产 H200，其 144GB HBM 容量解决了容量瓶颈问题，测试中性能优于 MI300。AMD 对 H200 的回应是 MI325X，但遗憾的是其上市时间滞后，导致客户转而选择 B200。

MI325X 原计划与 H200 同期（2024 年第三季度）出货，但因延迟至 2025 年第二季度才批量上市，直接与 2025 年第一季度推出的 HGX x86 B200 SXM 竞争。大多数客户选择 B200 而非 MI325X，这也是除 Meta 外，MI325X 未获超大规模采购的主因。

需要说明的是，量产延迟并非 AMD 独有问题：英伟达 GB200 NVL72 因集成 NVLink 背板的挑战及集群运营商缺乏调试工具，同样面临大规模延迟。

自 2023 年第一季度以来，AMD 在数据中心 AI GPU 市场份额持续增长。但 2025 年第一季度，英伟达 Blackwell 大规模投产，而 AMD 的应对产品推迟至第三季度，导致其市场份额相应下降。预计 2025 年第二季度 AMD 份额将继续下滑，但随着 MI355X 在年底推出及软件改进加速，AMD 有望在明年底或 2026 年初重新夺回部分市场份额。

为了使本文的基准测试尽可能接近真实的推理工作负载，本文的推理基准测试方法强调分析给定配置下的在线吞吐量与每个用户的端到端延迟，而不是基于传统的离线基准测试。与离线基准测试不同，离线基准测试在理想条件下测量吞吐量，不考虑实际延迟影响，本文的方法明确捕捉系统同时处理的用户数量与每个用户体验的延迟之间的权衡。通过逐步增加并发用户数量，本文测量延迟如何增加，使本文能够得出直接反映操作条件和用户体验的现实吞吐量指标。

下面将首先解释需要理解的关键指标以及这些指标的定义。

吞吐量衡量在给定时间内完成的工作量，例如，每个 GPU 每秒可以处理多少个令牌。更高的吞吐量意味着系统可以同时处理更多的请求，提高整体容量、效率和收入。

延迟指的是完成单个请求所需的时间，从发出请求到交付最终响应的时间。更低的延迟意味着更快的响应和更好的用户体验。在本文的框架中，本文关注端到端（E2E）延迟，本文在下面定义。

在推理基准测试中，这两个指标是相关的。通过添加更多的并发请求来增加吞吐量通常会增加单个用户体验到的延迟。这是因为当系统处理许多并发用户时，资源变得更加紧张，导致单个请求等待更长时间。相反，优化低延迟通常会限制整体吞吐量，因为同时处理的请求更少，以保持响应迅速。

理解吞吐量和延迟之间的平衡对于选择正确的配置至关重要—— 交互式应用程序优先考虑低延迟以获得响应迅速的用户体验，而批处理任务则优先考虑更高的吞吐量，即使每个请求的延迟增加。

首令牌时间（TTFT）表示用户从发送请求到接收第一个生成的令牌所经历的初始延迟，反映了预填充整个输入提示令牌的时间。

输出令牌之间的时间（TBOT）量化了生成初始令牌后连续令牌之间的延迟，捕捉稳态推理性能。

端到端（E2E）延迟计算为 E2E 延迟 = TTFT+（输出序列长度 ×TBOT）。这是本文分析用户体验的首选指标，因为它包含了处理请求时的所有各种延迟源。这与一些仅比较每个 GPU 的吞吐量与 TBOT 的分析形成对比。

传统的离线基准测试忽略了这些延迟交互和并发效应，未能模拟现实的用户条件，从而产生与实际操作环境脱节的过于乐观的吞吐量数字。当离线基准测试分析吞吐量与批量大小时，结果并不准确，因为即使给定批量大小下每个 GPU 的吞吐量相同，不同的 AI 芯片也可能有非常不同的延迟。

离线吞吐量基准测试，来源：Signal65

现实生产工作负载的模型主要有两类：密集架构和稀疏混合专家（MoE）架构。

对于密集模型，本文测试了 FP16 精度的 Llama3 70B 作为中等规模 FP16 部署的代表，以及 FP8 精度的 Llama3 405B 作为大规模密集场景的代表。

为了对稀疏 MoE 模型进行基准测试，本文选择了 FP8 精度的 DeepSeekV3 670B。在算术强度、近似活动、总参数计数和内存访问模式方面，DeepSeekV3 的模型架构与 OpenAI 的 4o/4.1/o1/o3/o4 等前沿封闭模型非常匹配。因此，DeepSeek 是基准测试 OpenAI 内部模型架构的最佳代理模型。

本文对三种不同的输入和输出令牌长度组合进行基准测试，以反映现实的推理场景和性能特征。

第一种使用 4K 输入和 1K 输出令牌场景。这代表了以大型预填充通用矩阵乘法（GEMM）操作为特征的摘要任务。这种场景严重依赖计算，有利于英伟达 GPU 等在计算密集型预填充方面始终表现出色的架构。

第二种场景，输入 1k 令牌，输出 1k 令牌，与翻译或对话工作负载非常一致，平衡了预填充和解码性能需求。

最后，本文测试了 1k 输入和 4k 输出令牌场景。这代表了输出大量推理令牌的推理密集型任务，这意味着性能通常受内存带宽限制，而不是计算。评估所有这三种输入 / 输出长度场景可以全面了解模型和硬件在不同推理工作负载中的性能。

对于 Llama3 70B 和 405B 的推理基准测试，本文选择 vLLM 作为本文的主要推理引擎。虽然许多用户现在由于更好的性能而转向 QWEN，但 Llama3 仍然是使用最多的模型。vLLM 是这些模型中使用最广泛的推理框架。由于其优化的性能、易用性和鲁棒性，它得到了英伟达和 AMD 的认可和积极推荐。对于 H200 GPU 平台，除了 vLLM 之外，本文还评估了 TensorRT-LLM（TRT-LLM）服务。虽然 TensorRT-LLM 最初基于 C++ 的实现历史上提供了次优的用户体验，但英伟达在 12 月推出了一个基于 Python 的版本，在功能和使用风格上与 vLLM 和 SGLang 类似。然而，根据本文的最新测试，这个基于 Python 的 TensorRT-LLM 实现的整体用户体验和成熟度仍然落后于 vLLM，尽管持续的改进正在缩小这一差距。为了完整起见，本文对这两种实现进行了基准测试。

TRT-LLM 通过其新的 python pytorch 后端、用于启动推理实例的简单单行命令行界面以及兼容 OpenAI 的 HTTP 服务器，使用起来变得容易多了。然而，它仍然存在很多问题 —— 例如，DeepSeek 在 TRT-LLM 上运行不佳，英伟达也尚未发布 python TRT-LLM-serve docker 镜像，导致数小时的时间浪费在从源代码安装上。本文建议 TRT-LLM 团队修复 DeepSeek V3 实现并发布 TRT-LLM-serve docker 镜像。

本文: SemiAnalysis

相比之下，对于更大的 DeepSeek 670B 模型，本文选择 SGLang 作为推理引擎。SGLang 是 DeepSeek 670B 部署中最常推荐和采用的推理框架，由于其能够高效处理更大的模型尺寸和 DeepSeek 规模推理工作负载的复杂性，它得到了英伟达和 AMD 的强烈认可。

在本文的基准测试方法中，全都系统地评估了每个 GPU 架构和测试场景允许的所有实际张量并行（TP）配置。例如，在对 405B 模型进行基准测试时，AMD 的 MI300X 支持 TP=4 和 TP=8 配置，而英伟达的 H100 由于内存和性能限制，通常仅支持 TP=8。对于每个并行配置，本文测量吞吐量和延迟，以构建性能上限—— 确定在给定延迟要求下提供最大吞吐量的最佳张量并行策略。这种全面的方法确保本文准确地确定适合每个 GPU 平台和模型场景的最有效和性能最佳的并行设置。

请注意，本文只测试单节点场景—— 随着主要 AI 实验室在生产中使用的解耦解码和解耦预填充的发明，多节点推理已成为事实上的前沿标准。不幸的是，解耦解码 / 预填充目前在 AMD 的开源软件栈上不可用，仅在英伟达的系统上可用。

本文的推理基准数据应该从每美元性能和每种 GPU 类型之间的相对性能的角度来看待。通过微优化（例如，对 FP16 模型使用 FP8 KV 缓存或微优化最大批量令牌），有办法继续提高绝对性能，但这只会优化每个 GPU 类型的特定数据点，而不是整个曲线。这就是为什么本文建议读者关注每种 GPU 类型之间的相对性能，而不是所实现的绝对性能。

此外，请注意，在将 H200 与其他 GPU 类型进行比较时，本文提供了 H200 在使用 TRT-LLM 推理框架和 vLLM 时的结果。TRT-LLM 提供了更强的性能，但它的开发人员体验比 vLLM 差。本文建议查看 vLLM H200 和 TRT-LLM H200 的数据点，而不仅仅是 TRT-LLM H200 的性能曲线。

本文的基准测试在 Docker hub 上提供了本文尝试过的确切 vLLM 和 SGLang 版本，以便于重现。

上图显示了在 1k 输出 / 1k 输入场景下服务 LLaMA 3 70B 的结果，该场景映射到翻译和聊天应用程序。本文看到，在低延迟场景下，使用 vLLM 的 H100 和 H200 优于两个 AMD GPU，但 MI325X 在更高的批量大小 / 更高的并发性下勉强领先并超过英伟达设置。

关于张量并行（TP）规模，本文发现 TP=8 在低延迟场景中占主导地位，而 TP=2 或 TP=4 在更大批量 / 高并发下提供最高吞吐量。对于 AMD GPU，TP=1 从未实现最佳性能，仅 MI325X 在高并发场景下是唯一例外。本文认为这是因为在高并发时，通信量足够大，使得从 HBM 加载数据与通过 NVLink 通信数据的性能差异显著。MI325X 的 TP=1 数据点体现了高 HBM 带宽的优势。

总体而言，搭载 TRT-LLM 的 H200（标记为 H200-TRT）在基准测试中大多占据主导地位。本文认为这得益于英伟达对自身硬件的深度理解和对性能调优的大量投入。

在 LLaMA 3 70B 的类推理工作负载（1k 输入，4k 输出）中，H100 的性能明显低于所有其他 GPU，每秒每 GPU 吞吐量迅速稳定在约 900 tokens 左右。另一方面，MI325X 的性能平台期晚于所有其他 GPU，这意味着它在约 450 秒延迟时具有最高吞吐量。这也解释了为何使用 vLLM 的 H200 在高并发时超越 MI325X，尽管其在低延迟区域的性能优于 MI325X。在 300 秒以下延迟场景中，性能排名（从优到劣）清晰如下：搭载 TensorRT-LLM 的 H200、H200、MI325X、MI300X 和 H100。

在处理 LLaMA 3 70B 的类摘要工作负载（4k 输入，1k 输出）时，工作负载的预填充密集特性通常更有利于英伟达 GPU。本文看到，在 30 秒延迟标记后，H100 超越 MI300X，使用 vLLM 的 H200 则领先于 MI325X。然而，MI325X 的 TP=1 配置在高并发时再次表现出色，优于使用 vLLM 的 H200。搭载 TensorRT-LLM 的 H200 则始终无人能及，从 20 秒标记开始即在所有节点提供最高吞吐量。

来演: SemiAnalysis

在处理 1k 输入和 1k 输出的 LLaMA 3 405B 时，本文发现大多数设置的性能迅速进入平台期。在 40 秒以下延迟时，MI325X 和 MI300X 均优于 H100，且出人意料地优于使用 vLLM 的 H200。总体而言，MI325X 持续优于使用 vLLM 的 H200、MI300X 和 H100。在 150 秒延迟限制下，H100 每秒吞吐量勉强达到 400 tokens。这表明在服务大型密集模型时，内存带宽至关重要。

与此同时，搭载 TensorRT-LLM 的 H200 再次碾压竞争对手。它可在 150 秒延迟内实现每 GPU 近 1000 tokens / 秒的吞吐量，且在更高并发下未见平台期迹象。本文认为这是因为 TensorRT-LLM 对内存使用的控制更佳，从而能够维持更高的内存利用率并提升性能。

在处理 LLaMA 3 405B 的推理工作负载（1k 输入，4k 输出）时，内存限制的影响显著。例如，本文看到 H100 的吞吐量不及同类产品的一半。使用 vLLM 的 H200 性能也低于 MI300X，仅在更高并发（需更多计算）时才再次超越。然而，这仍无法使使用 vLLM 的 H200 与 MI325X 竞争。MI325X 在所有场景中均优于 H100、MI300X 和使用 vLLM 的 H200。

搭载 TensorRT-LLM 的 H200 再次展现技术优势，在相似延迟下吞吐量比 MI325X 高 1.5 倍。这表明 vLLM 远未达到最优，也解释了为何 vLLM 将 TensorRT-LLM 视为主要竞争对手。

根据上图，本文可以得出结论：服务大型密集模型是 AMD GPU 的优势。具体而言，MI325X 在所有延迟场景中均击败竞争对手，MI300X 甚至在约 250 秒延迟时优于使用 vLLM 的 H200。另一方面，H100 的吞吐量稳定在约 350 tokens / 秒，使用 vLLM 的 H200 为 600 tokens / 秒。与其他情况一样，搭载 TensorRT-LLM 的 H200 在 50 秒延迟标记后显著超越所有其他配置，占据绝对优势。

尽管类摘要工作负载以预填充为主，但运行大型密集模型仍受内存限制，这一点从图表中也可看出。这就是 AMD 选择使用 MI300X 和 MI325X 进行大型模型服务的原因。

对于 DeepSeekV3 670B，本文使用 SGLang 推理框架并测试了 H200、MI300 和 MI325X。本文未测试 H100，因为它无法在单个节点中容纳 DeepSeekV3 670B。

在翻译和聊天应用场景（1k 输入 1k 输出）中，本文看到 H200 在所有延迟级别上均击败 MI300X。MI325X 仅在 25 至 35 秒的小范围延迟内与 H200 竞争，其余延迟范围内 H200 均占优。在低延迟、高交互性场景中，当每个模型副本同时处理 4-16 个并发用户时，H200 是明显的赢家。

在推理测试场景（1k 输入 / 4k 输出）中，H200 在所有延迟范围内均击败 MI300X。但 MI325X 在超过 100 秒的延迟范围内击败 H200，而在 100 秒以下延迟时，H200 仍是明显赢家。

在摘要任务场景（4k 输入，1k 输出）中，H200 与 MI300X 的对比结果类似 ——H200 在所有延迟范围内均碾压 MI300X。对于 MI325X，延迟超过 25 秒后开始超越 H200。在更偏向在线低延迟的用例中，H200 击败 MI300X 和 MI325X。

在大多数应用所需的中低延迟场景中，H200 击败 MI300X 和 MI325X，这也是 OpenAI 等实验室选择 H200 的原因。

在考虑总拥有成本（TCO）时，选择 AMD 还是英伟达 GPU 需要仔细评估资本支出和持续运营成本。AMD 的 MI300X 和 MI325X GPU 的每小时总成本通常低于英伟达的 H100 和 H200 GPU。

对于每个延迟和模型测试场景，本文以每百万 tokens 成本为单位计算了每美元性能，以反映计入下表所示的总拥有成本后 AMD 与英伟达的性能差异。请注意，下图基于下表中的 TCO 生成，代表客户自行购买 GPU 的总成本，不反映从 Neoclouds 租赁 GPU 的成本结构。

下面，本文将深入探讨资本支出、运营支出和 TCO 计算背后的详细财务分析和战略考量。

在超低延迟推理中，MI325X 和 MI300X 在 LLama3 70B 聊天和翻译任务（1k 输入 / 1k 输出）的每美元性能上超越所有其他 GPU。

从更长远的延迟周期来看，当延迟超过 20 秒时，价格差异开始显现。AMD GPU 的性价比低于 H100 和使用 vLLM 的 H200，但随着延迟增加，MI325X 因其在高并发下的出色性能而比 H200 更经济。

转向推理场景（1k 输入，4k 输出），从低延迟应用开始，MI325X 和 MI300X 在 TCO 性能上胜出。

将分析扩展到更长的延迟周期，本文发现由于性能较弱，在 H100 上运行 LLaMA 3 70B 的成本效益最低。MI300X 和 MI325X 比使用 vLLM 和 TensorRT LLM 的 H200 更昂贵，但在更高延迟下更具竞争力。有趣的是，在 MI300X 上运行的成本几乎与 MI325X 相当，这表明在此案例中 MI325X 的性能提升未能证明其价格上涨的合理性

摘要工作负载也呈现类似趋势。AMD GPU 在低延迟区域性价比最高，H100 则落后于所有其他配置。虽然使用 vLLM 和 TensorRT 的 H200 在中延迟区域最经济，但 MI325X 的每百万 tokens 成本低于使用 vLLM 的 H200，并与使用 TensorRT 的 H200 相当。

在聊天和翻译场景（1k 输入，1k 输出）中，AMD GPU 的低价和在服务大型密集模型时的更高性能使成本效率差异更加明显。本文看到，MI325X 的服务成本持续低于使用 vLLM 的 H200 和 H100，MI300X 也与使用 vLLM 的 H200 相当。尽管如此，搭载 TensorRT LLM 的 H200 在 60 秒延迟标记后凭借卓越性能再次胜出。

对于 405B 推理任务的超低延迟场景（1k 输入，4k 输出），MI325X 和 MI300X 无疑击败使用 vLLM 的 H200 和 H100，甚至超越使用 TRT-LLM 的 H200！

从推理任务场景的更长延迟来看，与之前所有服务大型密集模型的配置一样，MI300X 和 MI325X 的性价比均高于 H100 和使用 vLLM 的 H200。但需注意，搭载 TensorRT LLM 的 H200 仍是所有配置中成本效率最高的，因其性能提升幅度超过了与 AMD GPU 的价格差异。

转向摘要场景（4k 输入，1k 输出），MI325X 是明显的赢家。在低延迟时，MI325X 超越包括搭载 TensorRT LLM 的 H200 在内的所有配置，且在高延迟时仍具竞争力。MI300X 在高延迟时的成本效率也优于使用 vLLM 的 H200，在低延迟时接近搭载 TensorRT LLM 的 H200。令人惊讶的是，尽管性能更优，搭载 TensorRT LLM 的 H200 此次未能证明其价格的合理性。

在聊天和翻译任务（1k 输入，1k 输出）中，MI300X 的每美元性能无法与 H200 竞争，而 MI325X 仅在 25 至 40 秒延迟内与 H200 有一定竞争力，但优势不大。每美元性能的微小提升不足以抵消切换和采用 ROCM 的成本。

在推理任务（1k 输入，4k 输出）中，本文看到延迟超过 100 秒后，MI325X 优于 H200，每美元性能比 H200 高 20%。但在低延迟 / 中高交互性场景（即延迟低于 100 秒）中，H200 仍轻松胜出。MI300X 在推理任务的每美元性能上无法与 H200 竞争。

在摘要任务（4k 输入，1k 输出）中，H200 在低延迟 / 高交互性的每美元性能上胜出。

在摘要任务的中高延迟场景中，MI300X 与 H200 具有竞争力，MI325X 的每美元性能比 H200 高 20-30%。

上述每 TCO 性能分析聚焦于直接购买场景 —— 比较大型超大规模企业或企业直接购买硬件时的 AMD GPU 与英伟达 GPU，而非从 Neoclouds 租赁 GPU 的情况。

在 GPU 租赁方面，成本差异显著。AMD 相比英伟达面临显著竞争劣势，主要原因是供应有限和市场竞争不足。

目前，超过 100 家不同的 Neocloud 提供商提供英伟达 GPU 的短期（不足 6 个月）租赁，形成价格竞争并压低租赁成本。相比之下，仅有少数提供商提供类似的短期 AMD GPU 租赁。

租赁市场的这种稀缺性导致 AMD GPU 租赁价格人为高企，削弱了其整体成本竞争力。因此，在租赁市场中，无论延迟要求如何，英伟达在每美元性能上始终优于 AMD。这种不平衡解释了为何除主要超大规模企业外，AMD GPU 的采用率极低 —— 超大规模企业通常直接进行长期 GPU 采购，可利用 AMD 有利的硬件经济性，而无需面对 AMD 租赁市场的价格限制。

2025 年第二季度，H200 的当前 1 个月期合同市场租赁价格约为 2.5 美元 / 小时 / GPU，低质量云服务的价格差异较大且更低。MI325X 的 1 个月期租赁合同尚不存在，而 MI300X 的 1 个月期租赁价格超过 2.5 美元 / 小时，这使其在租赁中缺乏竞争力。以下是本文计算的 MI300X 和 MI325X 需达到的约 1 个月期租赁价格，以使其与租赁英伟达 H200 竞争。

在翻译和聊天工作负载（1k 输入，1k 输出）中，MI300X 租赁价格需定为 1.9 美元 / 小时才能与 H200 竞争，MI325X 的 1 个月期合同价格需低于 2.5 美元 / 小时才能与 H200 竞争。

在推理推理任务（1k 输入，4k 输出）中，MI300X 的 1 个月期合同价格需低于 2.1-2.4 美元 / 小时，才能在每美元性能上与 H200 竞争。MI325X 则需根据交互性定价在 2.75-3 美元 / 小时 / GPU 之间，以具备竞争力。

在摘要任务（4k 输入，1k 输出）中，MI325X 的 1 个月期合同价格应为 2.75-3 美元 / 小时，MI300X 则应定价在 2.1-2.4 美元 / 小时之间。

由于目前缺乏软件支持，本文未在完整基准测试中纳入 B200。在撰写本文时，大多数主要服务框架尚未对 B200 GPU 提供稳定支持。vLLM 的标准发布镜像尚未支持 B200（参考），SGLang 团队也未公布支持 B200 的明确时间表。在 AMD 方面，本文未对 MI355X 进行基准测试，因为生产单元尚未上市。尽管存在工程样品，但漏洞尚未完全修复，因此系统尚未准备好进行测试。

虽然 TensorRT-LLM 支持 B200，但仅针对少量模型进行了优化，且明显缺少 FP8 DeepSeek V3。因此，本文使用 TensorRT-LLM 对 B200 进行了部分模型和场景的基准测试，作为对 B200 性能的初探。下图展示了 LLaMA 70B 和 405B 在推理工作负载（1k 输入，4k 输出）中的表现。

搭载 TensorRT LLM 的 B200（标记为 B200-TRT）在 LLaMA 70B 基准测试中全面领先，整体延迟更低、吞吐量更高。MI325X 和 MI300X 与 B200 的竞争力相差甚远。

对于 LLaMA 405B，B200 在所有延迟和吞吐量指标上再次碾压所有其他配置，甚至在本文测试的最高请求速率下仍未进入平台期。

到目前为止，B200 在本文运行的基准测试中表现出极高性能。为确保全面性，本文将在未来几个月内报告 MI355X 和 B200 的训练和推理性能。

在基准测试过程中，本文遇到了多个障碍。

服务框架中的大量调优标志导致配置组合呈爆炸式增长。例如，vLLM 使用 max-num-seq、max-num-batched-tokens、num-scheduler-steps 和 max-model-len 等参数；其中大多数配置关于每个标志对性能的具体影响文档不足。这使得基准测试极其耗时，且无法保证找到实现最佳性能的正确组合。因此，本文不得不依赖英伟达和 AMD 工程师提供的最佳配置。本文希望所有服务框架改进每个标志对性能影响的文档，并理想地实现自动调优。这是 AMD 和英伟达应投入 GPU 资源并公开提供的服务，本文乐于合作。

由于服务框架代码更新速度极快，本文在获取最新性能结果时遇到了困难。即使采用最佳配置，每种 GPU 类型的基准测试运行仍需 60 到 120 小时，而服务框架几乎每周都会更新代码。由于 vLLM 从 v0 过渡到 v1、SGLang 的 CUDA 图捕获失败、SGLang 在 AMD 上的分段错误等问题，本文不得不从头开始进行基准测试，并且在被要求重新配置标志时多次重启。更糟糕的是，AMD 多次要求本文启用反馈周期中新开发的功能，导致多次重新运行和软件版本不一致。本文希望未来通过发布实时基准测试网站来缓解这一问题。

基准测试耗时较长的另一个原因是本文无法在多台机器上并行进行实验。本文发现云服务提供商的机器在吞吐量和延迟方面存在不可忽视的差异，这导致 AMD 和 NVIDIA 要求本文重新进行所有实验。

最后，AMD 维护独立的代码分支和配置导致了严重的延迟。由于 AMD 维护了一个独立的 vLLM 分支，本文不得不编写单独的基准测试设置。在撰写本文时，AMD 已结束并弃用了其 vLLM 分支。本文欢迎这一变化，并希望 AMD 在其他软件中也采用这一做法。在配置方面，他们添加了与 AITER 相关的环境变量，这让本文回想起 PYTORCH_TUNABLE_OP 的问题。本文已表达了对使用环境变量启用功能的不满，并希望该做法能像 PYTORCH_TUNABLE_OP 一样被移除。

在过去的 5 个月里，AMD 的整体持续集成（CI）有了很大的改进。5 个月前，AMD 的 SGLang 推理 CI 测试为零，现在已经有了一些。不幸的是，其 CI 测试覆盖率仍远不及 NVIDIA。

三周前，AMD 的 AI 负责人 Anush 要求他们的一位核心工程师 “996” 工作以修复 SGLang 的 CI 问题。AMD 虽然取得了一些进展，但遗憾的是仍有数十个单元测试缺失。如果没有适当的测试，AMD 的软件质量将继续较差，存在更多漏洞，导致开发者体验不佳和采用速度缓慢。

还有许多与 DeepSeekv3 相关的多 GPU 单元测试缺失，例如 DP 注意力、MoE EP 测试等。

在夜间准确性测试方面，直到三周前 SemiAnalysis 指出准确性问题时，AMD 的准确性测试仍为零。对于大多数模型，本文观察到在 AMD 上运行时的准确性质量比在 NVIDIA 上差。25% 的测试模型在 AMD 上运行时准确性测试失败。

这意味着在 ROCM 上使用相同的模型，你会得到比在 NVIDIA 上更差的答案。

AMD 需要让更多工程师 “996” 工作来解决这个问题！

来源: SemiAnalysis, SGLang, Github

在 2025 年第一季度，AMD 大约花费了 7.5 亿美元用于股票回购，而本文估计他们在内部研发的集群租赁上仅花费了 1300 万美元。尽管 ROCM 的软件质量有了很大的改进，但其软件质量和开发者体验仍远不及 NVIDIA 的软件质量和功能完整性。

例如，由于缺乏开发该优化所需的内部集群级资源，AMD 尚未实现分布式预填充推理优化。

本文对 AMD 内部研发预算的估计基于以下事实：AMD 内部约有 4000 块 MI300X，从超大规模云服务商和 Neoclouds 租赁的成本为 1.5 美元 / 小时 / GPU。1.5 美元 / 小时 / GPU × 4000 块 GPU × 每季度 90 天 × 24 小时 / 天 = 每季度 1300 万美元的研发集群支出。虽然他们在增加支出，但他们是通过短期 GPU 租赁来实现的，而不是为团队和项目长期分配专用集群。

速度是护城河，AMD 要想有机会，就需要跑得更快，下更大的赌注。更多的内部集群资源将有助于加速内部开发和 CI 支持。

如果 AMD 自己都没有充分测试过，而且内部只有 4000 块 GPU，客户为什么要从 AMD 购买大型集群呢？他们对 MI325X 有更大的计划，但这些计划没有长期合同，只是短期的。

尽管 AMD 在单节点推理方面表现出色，但目前缺乏对许多推理功能的支持，如分布式预填充、智能路由和 NVMe KV 缓存分层。分布式服务多年来一直是行业标准，上个月 NVIDIA 开源了分布式推理框架 Dynamo，进一步普及了这一技术。分布式服务使用独立的计算实例来处理请求的不同阶段，包括预填充和解码。

此外，NVIDIA 还与 SGLang 合作，将分布式服务引入 SGLang，而 AMD 的 SGLang 分布式服务并不存在。由于 AMD 没有分布式预填充解决方案，NVIDIA 在原始性能和每美元性能上胜出。

AMD 正计划向 LMSys 的 SGLang 维护团队提供一个 16 节点的 MI300X 集群，以便他们开始研究合作，并在 ROCM 上实现分布式预填充。本文相信，使用 NVIDIA Dynamo 分支版本的 AMD 分布式预填充原型将在 6 月 12 日的 AMD Advancing AI 活动中进行演示。

AMD 和 NVIDIA 在功能上的差距还延伸到了 NVIDIA Dynamo 的其他特性。

Dynamo 智能路由器可以在多 GPU 推理部署中智能地将每个令牌路由到可用的实例。在预填充阶段，这意味着要确保传入的令牌均匀分布到不同的预填充 GPU，以避免预填充阶段任何给定专家的瓶颈。

同样，在解码阶段，确保序列长度和请求在解码 GPU 之间得到良好的分布和平衡也很重要。Dynamo 提供的 GPU Planner 还可以复制流量较大的专家，以帮助保持负载平衡。

该路由器还可以在服务模型的每个副本之间进行负载平衡，这是 AMD 的 vLLM 和许多其他推理引擎不支持的。

Dynamo 的 GPU Planner 是预填充和解码节点的自动扩展器，可以根据一天中自然的需求波动启动额外的节点。它可以在预填充和解码节点中对 MoE 模型中的许多专家进行一定程度的负载平衡。GPU Planner 会启动额外的 GPU，为高负载的专家提供额外的计算资源。它还可以根据需要在预填充和解码节点之间动态重新分配节点，进一步最大化资源利用率。

这还支持改变用于解码和预填充的 GPU 比例 —— 这在 Deep Research 等案例中特别有用，因为这些应用需要更多的预填充而不是解码，因为它们需要处理大量的上下文，但生成的内容相对较少。

不幸的是，目前 AMD 生态系统中还没有这个功能。

NVIDIA Dynamo 的 KV 缓存卸载管理器通过将之前用户对话的 KV 缓存存储在 NVMe 存储中而不是丢弃，从而允许更高效地执行整体预填充。

当用户与 LLM 进行持续的多轮对话时，LLM 需要考虑对话中之前的问题和回答，并将其作为输入令牌。在简单的实现中，推理系统会丢弃最初用于生成这些早期问题和回答的 KV 缓存，这意味着必须重新计算 KV 缓存，重复相同的计算集。

相反，使用 Dynamo 的 NVMe KV 缓存卸载功能，当用户离开时，KV 缓存可以卸载到 NVMe 存储系统中，直到用户返回对话。当用户在对话中提出后续问题时，可以从 NVMe 存储系统中快速检索 KV 缓存，无需重新计算 KV 缓存。

这释放了预填充节点的容量，以处理更多的传入流量，或者可以减少所需的预填充部署规模。用户还将获得更好的体验，因为第一个令牌的生成时间更快，因为检索 KV 缓存所需的时间比计算它要少得多。

来源: Nvidia

随着 RLVR 和带工具使用的多代理系统越来越普遍，这些 KV 缓存卸载功能将变得越来越重要，这也是 AMD 需要探索的另一个重要功能。

除了 NVIDIA Dynamo，本文还看到越来越多的分布式服务库。例如，在他们的 DeepSeek 推理系统复制尝试中，SGLang 团队使用 Mooncake 传输引擎进行 KV 缓存传输。Mooncake 传输引擎是一个高性能、零拷贝的数据传输库。最初作为 Mooncake 服务平台的一部分设计，Mooncake 传输引擎现在作为后端插件集成到 NIXL 中。最近，红帽 AI 宣布了 llm-d，这是一个 Kubernetes 原生的分布式推理框架，也使用 NIXL 进行 KV 缓存传输。NIXL 的流行意味着 NVIDIA GPU 将获得一流的最新支持。如果 AMD 不致力于支持开发者，同样的软件碎片化问题将再次发生。

AMD 工程师将需要更多的计算资源来探索和实现上述所有推理优化。

*声明：本文系原作者创作。文章内容系其个人观点，我方转载仅为分享与讨论，不代表我方赞成或认同，如有异议，请联系后台。

来源：半导体产业纵横