AMD 与 NVIDIA 推理基准测试：谁是赢家？——每百万 Token 的性能与成本 MI300X、MI325X、H100、H200、B200、MI355X、VLLM、SGLang、TRT-LLM、ROCm CI 覆盖不足、AMD 租赁价格虚高

本文信息来源：semianalysis

作者：Kimbo Chen，Dylan Patel，Daniel Nishball 和 Ivan Chiam

长期以来，业界一直声称 AMD 的 AI 服务器在总拥有成本（TCO）方面能够实现比 Nvidia 更优的推理性能。过去六个月里，我们通过对 Nvidia 和 AMD 提供的推理解决方案进行全面分析和基准测试，调查并验证了这一说法。我们原以为会得出一个简单的结论，但结果却比我们预想的更加复杂和令人惊讶。不同任务（如聊天应用、文档处理/检索和推理）之间的性能存在差异。

对于直接拥有和运营 GPU 的超大规模云服务商和企业来说，我们发现，在某些工作负载下，Nvidia 在每美元性能（perf/$）方面更强，而在其他工作负载下，AMD 的每美元性能更优。对于使用 Neoclouds 进行短期到中期租赁（6 个月以内）的客户来说，Nvidia 在每美元性能上始终占优。这是因为缺乏 AMD Neoclouds，导致 MI300X、MI325X 的租赁市场价格居高不下。相比之下，Nvidia GPU 有数百家 Neoclouds 提供 H100、H200 等多种显卡，市场租赁价格更具竞争力。

作为参考，AMD MI355X 旨在与 B200 竞争，而 MI325X 则被视为 H200 的竞争对手。然而，正如我们将要提到的，MI325X 的出货出现了延迟，这导致其上市时，大多数客户选择跳过它，转而选择 B200。

自 2024 年第三季度以来，我们一直与 AMD 紧密合作，在 2024 年 12 月发布了 AMD 训练文章 。AMD 已经采取措施，提升其推理解决方案的开发者体验和质量，并增加了一些持续集成（CI）自动化测试。 将近 6 个月后 ，我们认为现在是重新评估的合适时机。通过我们的测试， 尽管 AMD 目前已经做出了一些有意义的改变 ，但我们仍然认为还有很大的改进空间，后文我们将讨论遇到的问题以及 CI 覆盖率不足的情况。

我们的最终目标是创建一个统一的公开仪表盘，每天更新最新软件，展示多种硬件、多种主流模型在多种关键场景（如长上下文文档任务、聊天机器人任务、推理任务和智能体工作流）下的推理性能。该仪表盘将覆盖多个主流推理栈，包括 VLLM、SGLang TensorRT LLM，以及未来的 Dynamo 集成。

关键洞察

1. 对于购买硬件并使用 vLLM/SGLang 的客户来说，有时单节点 H200 的性价比（性能/美元）更高，有时单节点 MI325X 的性价比更高，这取决于工作负载和延迟需求。
2. 在大多数测试场景中，MI300X 与 H200 相比并不具备竞争力，无论是绝对性能还是性价比都更差。但在 Llama3 405B 和 DeepSeekv3 670B 的测试中，MI300X 在绝对性能和性价比上都优于 H100。
3. 对于租用 GPU、合同期为短期到中期（6 个月以内）的客户来说，由于只有少数供应商在短期到中期合同中提供 AMD GPU 租赁，Nvidia GPU 始终拥有更高的性价比。这导致市场供应紧张，价格被抬高。相比之下，Nvidia 生态系统中有超过一百家 Neocloud 供应商提供短期到中期的租赁服务，充足的供应带来了激烈的市场竞争，从而降低了成本。
4. MI325X 本应成为 H200 的竞争对手，但问题在于 MI325X 的大规模出货仅在 2025 年第二季度才开始，而 HGX B200 的出货则早了一个季度。这导致销售情况不佳，因为大多数服务商选择了 HGX B200 而不是 MI325X。
5. MI355X 将在 2025 年末开始出货，比 B200 晚两个季度。
6. B200 和 GB200 的软件生态仍未完全成熟。例如，FP8 DeepSeek V3 在 Tensor-RT LLM（TRT-LLM）、vLLM 或 SGLang 上都无法完全正常运行。
7. 在目前能够部署的工作负载和模型上，B200 表现出绝对的统治力。MI325 和 H200 在性能方面根本无法与之相比。
8. Nvidia 的 TRT-LLM 推理框架以开发者体验差而著称。自从 TRT-LLM 推出 pytorch 后端以及类似 vLLM 的一行命令行 serve 命令（可通过 huggingface 模型字符串调用）后，体验有所提升，但在开发者体验方面，仍远不及 vLLM 或 SGLang。
9. TRT-LLM 需要为 DeepSeek 提供完整支持，并且需要添加预构建的 TRT-LLM-serve 容器镜像。
10. 推理服务框架提供了过多的配置参数，导致组合设置呈爆炸式增长，这使得全面的基准测试几乎不可能实现。尽管我们之前建议移除环境变量，AMD 却反而增加了环境变量，使情况变得更糟。大多数用户无法获得最佳性能，因为如果不对每种工作负载进行非常深入和全面的参数遍历，根本无法知道该使用哪些参数和变量。
11. Anush 和他的团队正在努力让 ROCm SGLang 的 CI 覆盖率赶上 Nvidia 的覆盖率，但目前还有很长的路要走。目前与 NVIDIA 的覆盖率相比还不到 10%。
12. AMD 应该利用其雄厚的财务资源，增加对内部集群资源的投入。上个季度，AMD 在股票回购上花费了 7.49 亿美元，但在内部研发集群资源上的投入仅约为 1300 万美元。研发集群资源的匮乏是导致 AMD 开发者体验较弱以及在 AI 软件方面持续落后于 NVIDIA 的关键因素之一。我们认为，即使只将一小部分可观的回购资金转用于此，也能带来更好的长期股东回报，而不会牺牲回购带来的短期股东满意度。
13. 由于缺乏持续集成和数值精度内核，模型在 ROCm 上的各种评测得分相比 CUDA 更差。

SemiAnalysis 正在招聘更多技术成员，协助我们进一步推进开源基准测试和系统建模工作。这项工作极具影响力，能够接触到最先进的硬件，并对整个生态系统产生重大影响。如有意申请，请将您的简历及 5 条展示工程卓越能力的要点发送至此。我们也在韩国和新加坡招聘研究分析师。

我们非常感谢 AMD 和 Nvidia 对我们独立分析工作的支持。他们在整个过程中提供的技术支持极为宝贵。我们特别要感谢 Anush Elangovan（AMD AI 负责人）及其团队，感谢他们对我们各种错误报告的排查和修复，并审查我们的结果，确保我们正确开启了所有相关参数（AMD 的参数非常多）。在 Nvidia 方面，我们感谢 Ian Buck 的支持，同时也感谢 Kedar Pandurang Potdar 和 Sridhar Ramaswamy 对我们错误报告的排查和修复以及他们的支持。

感谢 TensorWave、Nebius、Crusoe、DataCrunch、CoreWeave 和 Nscale 提供算力，并支持开放生态系统，从而使独立的基准测试和分析成为可能。

H100 vs MI300X vs H200 vs MI325X vs B200 vs MI355X

推理的解码阶段往往受限于内存带宽。因此，两个主要的系统规格是 HBM 容量和 HBM 带宽。我们可以看到，单个 MI300 节点（拥有 1,536GB HBM 容量）相比 H100 节点（拥有 640GB HBM 容量）有明显优势，因为 H100 甚至无法在单节点内容纳 DeepSeek V3 FP8。NVIDIA 在 2024 年第三季度通过量产 H200 解决了容量不足的问题，H200 拥有 144GB 内存，而 H100 只有 80GB HBM 容量，并且在我们的测试中，H200 的性能优于 MI300。AMD 对 H200 的回应是 MI325X，但遗憾的是，该产品上市时间太晚，客户最终选择了 B200。

MI325X 原计划于 2024 年第三季度出货，与 H200 开始出货的时间相同，但由于延迟，最终于 2025 年第二季度才开始大规模出货。这使得它直接与 2025 年第一季度开始向客户交付的 HGX x86 B200 SXM 展开竞争。大多数客户选择购买 B200 而不是 MI325X，这也是除了 Meta 之外，MI325X 在超大规模客户中出货量不高的原因。

需要明确的是，生产延迟并不仅仅是 AMD 的问题，在 Nvidia 方面，GB200 NVL72 也因集成 NVLink 背板的挑战以及集群运营商缺乏背板调试工具而遭遇了大规模延迟。

AMD 与 Nvidia 数据中心 AI GPU 的市场份额

自 2023 年第一季度以来，AMD 在数据中心 AI GPU 市场的份额一直稳步增长。然而，到了 2025 年第一季度，Nvidia 的大规模 Blackwell 产品开始量产，而 AMD 应对 Blackwell 的产品要到 2025 年第三季度才会推出，因此 AMD 的市场份额在 2025 年第一季度出现了下滑。我们预计 AMD 的市场份额将在 2025 年第二季度继续下降。不过，随着 AMD 的 MI355X 将在今年晚些时候发布，以及 AMD 软件改进速度的加快，我们认为 AMD 有望在今年年底或明年年初重新夺回部分市场份额。

推理基准测试方法论——在线吞吐量与延迟

为了让我们的基准测试尽可能贴近真实世界的推理工作负载，我们的推理基准测试方法强调分析特定配置下的在线吞吐量与每个用户端到端延迟之间的关系，而不是基于传统的离线基准测试。与离线基准测试不同，后者在理想条件下测量吞吐量，未考虑真实世界中的延迟影响，我们的方法明确捕捉了系统同时处理多少用户与每个用户所经历延迟之间的权衡。通过逐步增加并发用户数量，我们测量延迟的增长，从而得出一个直接反映实际运行条件和用户体验的真实吞吐量指标。

我们将首先解释需要了解的关键指标及其定义。

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

延迟指的是完成单个请求所需的时间——从发出请求的那一刻起，到最终响应被送达为止。更低的延迟意味着更快的响应和更好的用户体验。在我们的框架中，我们关注端到端（E2E）延迟，具体定义如下。

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

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

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

输出标记间隔时间（TBOT） 量化了在生成初始标记后，连续标记之间的延迟，反映了推理的稳态性能。

端到端（E2E）延迟的计算公式为：E2E 延迟 = TTFT +（输出序列长度 × TBOT）。这是我们分析用户体验时首选的指标，因为它涵盖了处理请求时所有不同来源的延迟。这与一些只比较每个 GPU 吞吐量与 TBOT 的分析方法形成了对比。

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

推理基准方法论——模型选择

现实世界生产工作负载的模型主要分为两大类：稠密架构和稀疏专家混合（MoE）架构。

对于稠密模型，我们在 FP16 精度下测试了 Llama3 70B，作为中等规模 FP16 部署的代表，并在 FP8 精度下测试了 Llama3 405B，用于大规模稠密场景。

为了对稀疏 MoE 模型进行基准测试，我们选择了 FP8 精度下的 DeepSeekV3 670B。在算术强度、近似激活参数、总参数量和内存访问模式方面，DeepSeekV3 的模型架构与 OpenAI 的 4o/4.1/o1/o3/o4 等前沿闭源模型架构高度相似。 因此，DeepSeek 是用于基准测试 OpenAI 内部模型架构的最佳代理模型。

推理基准测试方法论——输入/输出标记长度

我们对三种不同的输入和输出 token 长度组合进行了基准测试，以反映真实的推理场景和性能特征。

第一个场景使用 4K 输入和 1K 输出的 token 配置。这代表了以大规模预填充通用矩阵乘法（GEMM）操作为特征的摘要任务。该场景对计算资源的需求极高，更有利于像 NVIDIA GPU 这样在计算密集型预填充任务中表现出色的架构。

第二种场景，包含 1k 输入和 1k 输出标记，与翻译或对话类工作负载高度契合，兼顾了预填充和解码性能需求。

最后，我们测试了一个 1k 输入和 4k 输出的 token 场景。这代表了需要大量推理输出的推理密集型任务，这类任务的性能通常受限于内存带宽而非算力。评估这三种输入/输出长度的场景，可以全面了解模型和硬件在不同推理工作负载下的性能表现。

随着工作负载的演变和我们收集到更多数据，我们将在未来更新这些比率。

推理基准测试方法论——推理引擎

在对 Llama3 70B 和 405B 进行推理基准测试时，我们选择了 vLLM 作为主要的推理引擎。尽管许多用户现在因更好的性能而转向 QWEN，但 Llama3 仍然是使用最广泛的模型。vLLM 是这些模型中被最广泛采用的推理框架。由于其优化的性能、易用性和健壮性，vLLM 得到了 NVIDIA 和 AMD 的认可并被积极推荐。对于 H200 GPU 平台，我们还评估了 TensorRT-LLM（TRT-LLM）与 vLLM 并行服务。虽然 TensorRT-LLM 最初基于 C++实现，用户体验不佳，但 NVIDIA 于去年 12 月推出了基于 Python 的版本，其功能和使用方式与 vLLM 和 SGLang 类似。然而，根据我们最新的测试，这一基于 Python 的 TensorRT-LLM 整体用户体验和成熟度仍落后于 vLLM，尽管持续的改进正在不断缩小这一差距。为了完整性，我们对这两种实现都进行了基准测试。

TRT-LLM 现在通过其新的 Python PyTorch 后端、便捷的一行命令行推理实例启动方式以及兼容 OpenAI 的 HTTP 服务器，变得更加易用。然而，它仍然存在许多问题——例如，DeepSeek 在 TRT-LLM 上运行效果不佳，Nvidia 也尚未发布 Python 版 TRT-LLM-serve 的 Docker 镜像， 导致用户需要花费数小时从源码安装 。我们建议 TRT-LLM 团队修复 DeepSeek V3 的实现，并发布 TRT-LLM-serve 的 Docker 镜像。

相比之下，对于规模更大的 DeepSeek 670B 模型，我们选择了 SGLang 作为推理引擎。SGLang 是 DeepSeek 670B 部署中最常被推荐和采用的推理框架，并且由于其能够高效处理更大模型规模以及 DeepSeek 级别推理工作负载的复杂性，得到了 Nvidia 和 AMD 的大力支持。

推理基准测试方法论——并行策略

在我们的基准测试方法中，我们系统性地评估每种 GPU 架构和测试场景下所有可行的张量并行（TP）配置。例如，在对 405B 模型进行基准测试时，AMD 的 MI300X 支持 TP=4 和 TP=8 两种配置，而由于内存和性能限制，NVIDIA 的 H100 通常只支持 TP=8。对于每种并行配置，我们都会测量吞吐量和延迟，以构建性能屋脊线——从而确定在特定延迟需求下能够实现最大吞吐量的最佳张量并行策略。这种全面的方法确保我们能够准确地为每个平台和模型场景确定最高效、性能最优的并行设置。

请注意，我们只测试了单节点场景——随着解耦解码和解耦预填充的出现（所有主要 AI 实验室的生产环境都在使用），多节点推理已成为事实上的前沿标准。不幸的是，AMD 目前在开源软件栈上尚不支持解耦解码/预填充，该功能目前仅在 Nvidia 的系统上可用。

推理基准测试方法论——如何解读数据

我们的推理基准数据应从每美元性能和各类 GPU 之间的相对性能来分析。虽然可以通过微调（例如，在 FP16 模型中使用 FP8 KV-cache，或对最大批处理 token 数进行微优化）来持续提升每种 GPU 类型下某一具体数据点的绝对性能，但这只会优化该特定数据点，而不是整体曲线。因此，我们建议读者关注各类 GPU 之间的相对性能，而不是所达到的绝对性能。

另外，请注意，在将 H200 与其他 GPU 类型进行比较时，我们分别提供了 H200 在使用 TRT-LLM 推理框架和 vLLM 时的结果。TRT-LLM 的性能更强，但开发者体验不如 vLLM。我们建议同时参考 vLLM H200 和 TRT-LLM H200 的数据点，而不是只关注 TRT-LLM H200 的性能曲线。

我们的基准测试已在 Docker hub 上公开，使用了我们测试过的确切 vLLM 和 SGLang 版本，以便实现可复现性。

Llama3 70B FP16 吞吐量与延迟结果

上图展示了在 1k 输出/1k 输入场景下运行 LLaMA 3 70B 的结果，这对应于翻译和聊天应用。我们可以看到，在低延迟场景下，配备 vLLM 的 H100 和 H200 的表现优于两款 AMD 显卡，但在更高批量/更高并发的情况下，MI325X 略微领先并超过了 Nvidia 的配置。

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

总体来看，配备 TRT-LLM 的 H200（记作 H200-TRT）在基准测试中基本处于主导地位。我们认为这主要归功于 NVIDIA 对自家硬件的深刻了解，并在性能调优方面投入了大量精力。

在 LLaMA 3 70B 上进行类似推理的工作负载（1k 输入，4k 输出）时，H100 的表现远远不及其他所有 GPU，每块 GPU 的吞吐量很快就在每秒约 900 个 token 左右达到瓶颈。相比之下，MI325X 的瓶颈出现得比其他所有 GPU 都要晚，这意味着在大约 450 秒延迟时它拥有最高的吞吐量。这也解释了为什么 H200 搭配 vLLM 在高并发情况下能够超越 MI325X，尽管在低延迟区域 H200 的表现优于 MI325X。在延迟低于 300 秒的场景下，性能排名（从好到差）非常清晰：H200 搭配 TensorRT-LLM、H200、MI325X、MI300X 和 H100。

在为类似摘要的工作负载（4k 输入，1k 输出）提供 LLaMA 3 70B 服务时，由于工作负载以预填充为主，通常更有利于 Nvidia GPU。我们可以看到，在延迟达到 30 秒后，H100 超越了 MI300X 和 H200，并且搭载 vLLM 的 H100 领先于 MI325X。然而，MI325X 的 TP=1 配置在高并发下再次表现出色，超越了搭载 vLLM 的 H200。搭载 TensorRT LLM 的 H200 依然无可匹敌，从 20 秒起在每个时间点都提供了最高的吞吐量。

Llama3 405B FP8 吞吐量与延迟结果

在为 LLaMA 3 405B 提供 1k 输入和 1k 输出服务时，我们看到大多数配置很快就达到了性能瓶颈。在低于 40 秒的延迟下，MI325X 和 MI300X 的表现都优于 H100，甚至在 vLLM 下也优于 H200。总体来看，MI325X 在 vLLM 下始终优于 H200、MI300X 和 H100。在 150 秒延迟限制下，H100 勉强达到每秒 400 个 token。这显示了在服务大型稠密模型时，内存带宽的重要性。

与此同时，H200 搭配 TensorRT LLM 再次击败了竞争对手。在 150 秒延迟下，每块 GPU 几乎可以达到每秒 1,000 个 token，并且在更高并发下也没有出现性能瓶颈。我们认为这是因为 TensorRT-LLM 对内存使用有更好的控制，因此能够维持更高的内存利用率并提升性能。

在推理工作负载（1k 输入，4k 输出）下运行 LLaMA 3 405B 时，可以看到受限于内存带宽的影响。例如，H100 的吞吐量不到其他同类产品的一半。我们还看到，H200 搭配 vLLM 的表现不如 MI300X，只有在更高并发度、计算量更大时才重新超过 MI300X。然而，这并不能帮助 H200 搭配 vLLM 与 MI325X 竞争。MI325 在所有场景下的表现都优于 H100、MI300X 和搭配 vLLM 的 H200。

H200 搭载 TensorRT-LLM 再次展现了其技术实力，在相似延迟下，吞吐量可达到 MI325X 的 1.5 倍。这表明 vLLM 还远未达到最优状态，也说明了为什么 vLLM 将 TensorRT-LLM 视为其主要竞争对手。

根据上面的图表，我们可以得出结论：在大规模稠密模型推理方面，AMD GPU 展现出了强大的实力。具体来说，MI325X 在所有延迟场景下都遥遥领先，而 MI300X 在大约 250 秒延迟时甚至超越了搭载 vLLM 的 H200。另一方面，H100 的性能在每秒约 350 个 token 时达到瓶颈，搭载 vLLM 的 H200 则在每秒 600 个 token 时达到瓶颈。与其他情况一样，搭载 TensorRT-LLM 的 H200 依然表现最为出色，在 50 秒延迟之后明显优于所有其他配置。

对于类似摘要的工作负载来说，运行大型稠密模型依然受限于内存，尽管这类工作负载以预填充为主，从图表中我们可以看到这一影响。

这就是为什么 AMD 选择使用 MI300X 和 MI325X 来进行大模型推理服务。

DeepSeekV3 670B FP8 吞吐量与延迟结果

对于 DeepSeekv3 670B，我们使用 SGLang 推理框架，并测试了 H200、MI300 和 MI325X。我们没有测试 H100，因为它无法将 DeepseekV3 670B 装入单个节点。

在翻译和聊天应用场景（1k 输入 1k 输出）中，我们看到 H200 在所有延迟水平上都优于 MI300X。MI325X 仅在 25 到 35 秒的少量延迟区间内能与 H200 竞争。在其余的延迟区间，H200 获胜。在高交互性所需的低延迟下，当每个模型副本同时只有 4-16 个并发用户时，H200 显然是赢家。

我们看到，在推理测试场景（1k 输入/4k 输出）中，H200 在所有延迟范围内都优于 MI300。但在延迟超过 100 秒时，MI325X 则超过了 H200。在低于 100 秒的延迟下，H200 无疑是赢家。

当我们观察摘要任务场景（4k 输入，1k 输出）时，H200 与 MI300X 的对比依然如出一辙——在所有延迟范围内，H200 都全面压制 MI300X。对于 MI325X 来说，在延迟超过 25 秒后，MI325X 开始超越 H200。而在更偏向在线、低延迟的使用场景下，H200 则优于 MI300X 和 MI325X。

在大多数应用所需的低延迟和中等延迟下，H200 的表现优于我们的 MI300X 和 MI325X，因此像 OpenAI 这样的实验室选择了 H200。

每块 GPU 每小时总拥有成本——自有并运营的集群

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

对于每种延迟和模型测试场景，我们都以每百万个 token 的成本为单位，计算了每美元的性能，以反映在考虑总拥有成本后的 AMD 和 NVIDIA 之间的性能差异，具体见下表。请注意，下面的图表是基于下表中的总拥有成本（TCO）生成的，代表了客户自购 GPU 自用时的总成本。这并不代表从 Neoclouds 租用 GPU 的用户的成本结构。

在文章结尾，我们将深入探讨资本支出、运营支出和总拥有成本计算的详细财务分析及其背后的战略考量。

Llama3 70B FP16 每百万标记成本

在超低延迟推理方面，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 相当。

Llama3 405B FP8 每百万标记成本

从聊天和翻译场景（1k 输入，1k 输出）来看，AMD GPU 价格更低且在大规模稠密模型推理中表现更好，使得成本效率差异更加明显。我们可以看到，MI325X 在使用 vLLM 时的服务成本始终低于 H200 和 H100，而 MI300X 在使用 vLLM 时也与 H200 持平。不过，H200 搭配 TensorRT LLM 在超过 60 秒延迟后，凭借其卓越的性能再次获胜。

对于超低延迟的 405B 推理任务（1k 输入，4k 输出），毫无疑问，MI325X 和 MI300X 都击败了 H200 vLLM 和 H100 vLLM。它甚至在 TRT-LLM 上也击败了 H200！

在推理任务场景下观察更长的延迟时间，和之前所有用于部署大型稠密模型的配置一样，MI300X 和 MI325X 的性价比都优于搭载 vLLM 的 H100 和 H200。但需要注意的是，搭载 TensorRT LLM 的 H200 依然是所有方案中性价比最高的，因为它带来的性能提升超过了 H200 与 AMD GPU 之间的价格差距。

在摘要场景（4k 输入，1k 输出）中，MI325X 显然是赢家。在低延迟下，MI325X 的表现优于所有配置，包括搭载 TensorRT LLM 的 H200，并且即使在高延迟下也依然具有竞争力。MI300X 在高延迟下的性价比也超过了搭载 vLLM 的 H200，并且在低延迟下接近搭载 TensorRT LLM 的 H200。令人惊讶的是，这一次即使搭载 TensorRT LLM 的 H200 性能更强，也无法证明其价格的合理性。

DeepSeekv3 670B FP8 每百万 Token 成本

对于聊天和翻译任务（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%。

为什么除了超大规模企业之外，几乎没有人使用 AMD？

上述每单位总拥有成本的性能分析侧重于直接采购场景——即在大型超大规模企业或企业直接购买硬件，而不是从 Neoclouds 租用 GPU 的情况下，将 AMD GPU 与 NVIDIA GPU 进行比较。

在租用 GPU 方面，成本差异非常大。与 NVIDIA 相比，AMD 面临着显著的竞争劣势，主要原因是可用性有限以及市场竞争较少。

目前，已有超过 100 家不同的 Neocloud 服务商提供 NVIDIA GPU 的短期（少于六个月）租赁服务，形成了价格竞争并推动租赁成本下降。相比之下，只有少数几家服务商提供类似的 AMD GPU 短期租赁服务。

租赁市场上的这种稀缺性导致 AMD GPU 租赁价格被人为抬高，削弱了 AMD GPU 的整体成本竞争力。 因此，无论延迟需求如何，NVIDIA 在租赁市场上的每美元性能始终优于 AMD。 这种不平衡也解释了为什么除了主要的超大规模云服务商之外，AMD GPU 的采用率极低；这些超大规模云服务商通常会直接进行长期 GPU 采购，能够利用 AMD 硬件的成本优势，而无需面对 AMD 租赁市场的价格限制。

对于推理计算租户来说，AMD GPU 的租赁价格需要达到多少，才能与 Nvidia 具有竞争力？

截至 2025 年第二季度，目前 H200 的一百万次租赁合同市场价格约为每小时每 GPU 2.5 美元，价格波动较大，低质量云服务的价格更低。MI325X 的一个月租赁合同几乎不存在，而 MI300X 的一个月租赁合同价格则高于每小时 2.5 美元，这使得 MI300X 在租赁市场上缺乏竞争力。下文中，我们计算了 MI300 和 MI325X 的一个月租赁价格需要达到多少，才能在租赁市场上与 NVIDIA H200 竞争。

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

对于推理推断任务（1k 输入，4k 输出），MI300X 在 1 个月合约中需要定价低于每小时 2.1 至 2.4 美元，才能在每美元性能上与 H200 竞争。对于 MI325，根据交互性不同，定价需要在每小时每 GPU 2.75 美元到 3 美元之间，才能具备竞争力。

对于摘要任务（4k 输入，1k 输出），MI325X 的 1 个月合约价格应为每小时 2.75 至 3 美元，而 MI300X 的价格应为每小时 2.1 至 2.4 美元。

B200 性能抢先看

由于目前缺乏软件支持，我们没有将 B200 纳入完整的基准测试。在撰写本文时，大多数主流推理框架尚未对 B200 GPU 提供稳定支持。vLLM 的标准发布镜像尚不支持 B200（ 参考 ），SGLang 团队也尚未公布 B200 支持的明确时间表。至于 AMD 方面，我们没有对 MI355X 进行基准测试，因为量产版尚未上市。虽然已有工程样品，但仍存在一些未解决的 bug，因此该系统尚未准备好进行测试。

虽然 TensorRT-LLM 支持 B200，但它只针对少数模型进行了优化，而且这个小列表中最显著地缺少了 DeepSeek V3 FP8。因此，我们在部分模型和场景下使用 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 的训练与推理性能。

AMD 和 NVIDIA 在推理过程中的漏洞

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

服务框架中大量的调优参数导致了配置数量呈指数级增长。例如，vLLM 使用 max-num-seq、max-num-batched-tokens、num-scheduler-steps 和 max-model-len；其中大多数参数的文档都没有详细说明每个参数对性能的具体影响。这使得基准测试极其耗时，也意味着无法保证已经找到实现最佳性能的正确参数组合。因此，我们不得不依赖 NVIDIA 和 AMD 工程师为我们提供他们认为最优的配置。我们希望所有服务框架都能改进关于每个参数对性能影响的文档，并且最好能够自动调优。这是 AMD 和 Nvidia 应该专门投入 GPU 资源去做并公开服务的事情。我们非常乐意参与合作。

由于服务框架更新代码的速度非常快，我们很难获得最新的性能结果。即使在配置最佳的情况下，每次对一种 GPU 类型进行基准测试都需要 60 到 120 小时，而服务框架几乎每周都会更新代码。由于 vLLM 从 v0 到 v1 的过渡、SGLang CUDA Graph 捕获失败 、SGLang AMD 段错误 ，我们不得不从头开始进行基准测试，并且在被要求重新配置参数时也多次重新开始。更糟糕的是，AMD 多次要求我们启用在反馈循环期间新开发的功能，导致多次重新运行和软件版本不一致。我们希望未来通过发布一个实时基准测试网站来缓解这个问题。

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

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

AMD SGLang CI 测试缺乏覆盖率对等

在过去的 5 个月里，AMD 的整体持续集成（CI）有了很大提升。5 个月前，AMD 的 SGLang 推理 CI 为零，但现在已经有了一些。不幸的是，CI 测试覆盖率远远无法与 NVIDIA 相比。

三周前，Anush（AMD AI 负责人）让他们的一位骨干工程师实行 996 工作制 ，以修复 SGLang CI。AMD 已经取得了一些进展，但遗憾的是，仍然有数十个单元测试缺失。没有完善的测试，AMD 的软件质量将持续较差，出现更多的漏洞，导致开发者体验变差，采用速度也会更慢。

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

使用 ROCm 会让模型比在 CUDA 上“更笨”

在每晚的准确率测试方面，直到三周前 SemiAnalysis 指出准确率问题之前，AMD 完全没有进行过准确率测试。对于大多数模型，我们观察到在 AMD 上运行时的准确率比在 NVIDIA 上更差。在 AMD 上运行时，有 25%的测试模型未能通过准确率测试。

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

AMD 需要安排更多的 996 工程师来立刻解决这个问题！

股票回购与内部集群

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

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

我们对 AMD 内部研发预算的估算来自这样一个事实：AMD 内部大约有 4,000 块 MI300X 显卡，从他们的超大规模云服务商和 Neoclouds 租用的成本是每小时 1.5 美元。1.5 美元/小时/显卡 * 4000 块显卡 * 每季度 90 天 * 每天 24 小时 = 每季度研发集群支出 1,300 万美元。虽然他们正在增加支出，但他们是通过短期 GPU 租赁来实现的，而不是为团队和项目长期分配专用集群。

速度是护城河，AMD 若想有机会，必须跑得更快，下注更大。更多的内部集群资源将有助于加速内部开发和持续集成（CI）支持。

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

AMD 缺乏分离式预填充推理优化

尽管在单节点推理方面 AMD 占优，但目前 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 Smart Router 会在多 GPU 推理部署中智能地将每个 token 路由到所有可用的实例。对于预填充阶段，这意味着要确保传入的 token 被均匀分配到为预填充服务的不同 GPU 上，以避免在预填充阶段的任何专家节点上出现瓶颈。

同样地，在解码阶段，确保序列长度和请求在负责解码的 GPU 之间分布均匀、负载平衡也非常重要。对于流量较大的某些专家模型，Dynamo 提供的 GPU Planner 也可以进行复制，以帮助保持负载均衡。

路由器还会在为模型提供服务的每个副本之间进行负载均衡，而这是 AMD 的 vLLM 以及许多其他推理引擎所不支持的。

Dynamo 的 GPU 规划器是一种自动扩缩器，能够根据一天中自然波动的需求，自动增加或减少 prefill 节点和 decode 节点的数量。它可以在 MoE 模型中的多个专家之间，在 prefill 节点和 decode 节点上实现一定程度的负载均衡。GPU 规划器会为高负载的专家增加额外的 GPU，以提供更多的计算资源。它还可以根据需要在 prefill 节点和 decode 节点之间动态重新分配节点，进一步最大化资源利用率。

此外，这还支持调整用于解码和预填充的 GPU 比例——这对于像 Deep Research 这样的场景尤其有用，因为这些应用需要处理大量的上下文信息，但实际生成的内容却相对较少，因此更需要预填充而不是解码。

不幸的是，这目前并不是 AMD 生态系统中可用的功能。

NVIDIA Dynamo 的 KVCache 卸载管理器通过将先前用户对话的 KVCache 保存在 NVMe 存储中，而不是直接丢弃，从而实现了更高效的整体预填充执行。

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

相反，借助 Dynamo 的 NVMe KVCache 卸载功能，当用户离开时，KVCache 可以被卸载到 NVMe 存储系统中，直到用户返回对话。当用户在对话中提出后续问题时，KVCache 可以从 NVMe 存储系统中快速恢复，无需再次计算 KVCache。

这将释放预填充节点的容量，以处理更多的输入流量，或者可以减少所需的预填充部署规模。用户也将获得更好的体验，因为首次生成 token 的速度更快，现在检索 KV 缓存所需的时间远远少于计算它所需的时间。

随着 RLVR 和具备工具使用能力的多智能体系统变得越来越普遍，KVCache 卸载的这些功能将变得越来越重要，这也是 AMD 需要重点探索的另一个重要特性。

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

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

下一步和未来探索

我们致力于不断改进我们的基准测试方法。作为这一工作的长期目标，我们计划建立一个自动化的定期基准测试开源仓库，例如通过 GitHub CI 每周运行，以跟上推理服务软件更新的步伐。这将为社区提供可审计的基准测试日志，便于结果验证。目前，我们已经获得了多家行业合作伙伴的承诺来支持这一工作。

为了使我们的代理基准测试更加接近真实的生产工作负载，我们将进一步探索输入和输出序列长度的比例，并收集具有多样化输入/输出长度分布的多轮推理聊天日志数据集。最后，我们还将展示更多指标，包括首个 Token 生成时间（TTFT）、输出 Token 间隔时间（TBOT）等。

我们希望本文能够呼吁制定更好的推理基准测试，并且我们也非常乐意与行业合作伙伴和推理框架开发者进行合作。

下面，我们将对 MI300、MI325X、H100、H200、B200 和 MI355X 的资本支出、运营支出以及总拥有成本进行详细分析。