这种比较毫无意义，如_老虎社区_美港股上老虎

这种比较毫无意义，如果amd测试出来比英伟达强，英伟达还能是20倍市值amd?写点有意义的东西。

免责声明：上述内容仅代表发帖人个人观点，不构成本平台的任何投资建议。

精彩评论

CDMD
06-02
CDMD
工程师不过是牛马，他们的思维不会考虑利润，amd基本没有什么利润
一只没有耳朵一只没有尾巴
06-02
一只没有耳朵一只没有尾巴
说的是每美元性能，还是有意义的。

发表看法

{"i18n":{"language":"zh_CN"},"detailType":1,"isChannel":false,"data":{"magic":2,"id":441297822572768,"tweetId":"441297822572768","gmtCreate":1748777363125,"gmtModify":1748777365165,"author":{"id":4192259115439500,"idStr":"4192259115439500","authorId":4192259115439500,"authorIdStr":"4192259115439500","name":"股道自然","avatar":"https://community-static.tradeup.com/news/default-avatar.jpg","vip":1,"userType":1,"introduction":"","boolIsFan":false,"boolIsHead":false,"crmLevel":4,"crmLevelSwitch":0,"individualDisplayBadges":[],"fanSize":0,"starInvestorFlag":false},"themes":[],"images":[],"coverImages":[],"html":"<html><head></head><body>这种比较毫无意义，如果amd测试出来比英伟达强，英伟达还能是20倍市值amd?写点有意义的东西。</body></html>","htmlText":"<html><head></head><body>这种比较毫无意义，如果amd测试出来比英伟达强，英伟达还能是20倍市值amd?写点有意义的东西。</body></html>","text":"这种比较毫无意义，如果amd测试出来比英伟达强，英伟达还能是20倍市值amd?写点有意义的东西。","highlighted":1,"essential":1,"paper":1,"likeSize":2,"commentSize":2,"repostSize":0,"favoriteSize":0,"link":"https://laohu8.com/post/441297822572768","repostId":2540733947,"repostType":2,"repost":{"id":"2540733947","kind":"news","pubTimestamp":1748751145,"share":"https://www.laohu8.com/m/news/2540733947?lang=&edition=full","pubTime":"2025-06-01 12:12","market":"us","language":"zh","title":"AMD vs NVIDIA 推理基准测试：谁赢了？","url":"https://stock-news.laohu8.com/highlight/detail?id=2540733947","media":"半导体产业纵横","summary":"过去六个月，本文通过对英伟达和AMD 提供的推理解决方案进行全面分析与基准测试，对这一说法展开了调查验证。AMD 对 H200 的回应是 MI325X，但遗憾的是其上市时间滞后，导致客户转而选择 B200。AMD 与英伟达数据中心 AI GPU 的市场份额自2023 年第一季度以来，AMD 在数据中心 AI GPU 市场份额持续增长。预计 2025 年第二季度 AMD 份额将继续下滑，但随着 MI355X 在年底推出及软件改进加速，AMD 有望在明年底或 2026 年初重新夺回部分市场份额。","content":"<html><body><article><img src=\"https://fid-75186.picgzc.qpic.cn/20250601121747248v201jmqzqc3a1t4\"/><img src=\"https://fid-75186.picgzc.qpic.cn/20250601121748913v201kdp5jlb8wf6\"/>本文由半导体产业纵横（ID：ICVIEWS）编译自semianslysisAMD or NVIDIA?<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121751717v201vtolx5do0l3\"/>长期以来，业界一直有观点认为，在总拥有成本（TCO）下，AMD 的 AI 服务器推理性能优于<a href=\"https://laohu8.com/S/NVDA\">英伟达</a>。过去六个月，本文通过对英伟达和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 覆盖不足的情况。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121752194v20134355qigrfr\"/>主要观点对于购买硬件并使用vLLM/SGLang 的客户，根据工作负载和延迟要求，单节点 H200 部署与单节点 MI325X 的每美元性能（perf/$）呈现 “各有胜负” 的特点：部分场景 H200 更优，部分场景 MI325X 更优。在大多数测试场景中，MI300X 与 H200 相比缺乏竞争力，无论是绝对性能还是每美元性能均表现较差。但对于 Llama3 405B 和 DeepSeekv3 670B 模型，MI300X 在绝对性能和每美元性能上均优于 H100。对于采用中短期合同（不足6 个月）租赁 GPU 的客户，由于仅有少数提供商提供 AMD GPU 短期租赁，市场供应紧张推高了价格，导致英伟达 GPU 的每美元性能始终更优。反观英伟达生态，超百家 Neoclouds 提供商提供中短期租赁服务，充足的供应形成竞争性市场，有效降低了成本。MI325X 本应与 H200 竞争，但核心问题在于：其大规模出货推迟至 2025 年第二季度，此时 HGX B200 已出货一个季度，导致多数供应商选择 B200 而非 MI325X，进而造成 MI325X 销量低迷（除 Meta 外，未见大规模超算级采购）。MI355X 计划于 2025 年底开始出货，比 B200 晚两个季度。当前B200 和 GB200 的软件仍未完全成熟。例如，FP8 精度的 DeepSeek V3 在 TensorRT-LLM（TRT-LLM）、vLLM 或 SGLang 上无法完全正常运行。在目前可部署的工作负载和模型中，B200 占据主导地位，MI325 和 H200 的性能甚至无法接近其水平。英伟达的TRT-LLM 推理框架素以 “开发者体验差” 著称。尽管发布 PyTorch 后端和类似 vLLM 的单行 CLI 服务命令后有所改善，但在开发者体验上仍无法与 vLLM 或 SGLang 比肩。TRT-LLM 仍需全面支持 DeepSeek，并提供预构建的 TRT-LLM-serve 容器镜像。服务框架提供的大量配置标志导致“组合爆炸”，使全面基准测试几乎不可能完成。AMD 通过添加环境变量进一步复杂化了问题（尽管本文此前建议删除这些变量）。大多数用户无法获得最佳性能，因为若不对每种工作负载进行深度调优，根本无法确定最优标志和变量组合。AMD AI 负责人 Anush 及其团队正努力提升 ROCM SGLang 的 CI 覆盖率至与英伟达持平，但目前覆盖率仍不足 10%，差距显著。AMD 应利用其雄厚财务资源增加内部研发集群投入。上个季度，AMD 花费 7.49 亿美元用于股票回购，而内部研发集群资源投入仅约 1300 万美元。研发集群资源匮乏是其开发者体验落后于英伟达的关键原因，也是 AMD 在 AI 软件领域持续滞后的根源。本文认为，即便从回购资金中划拨一小部分用于研发集群，也能在不牺牲短期股东回报的前提下，带来更优的长期价值。由于缺乏CI 测试和数值精度内核，与 CUDA 相比，模型在 ROCM 上的各项评估得分普遍更低。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121752594v2012tx55a6b8u2\"/>H100 vs MI300X vs H200 vs MI325X vs B200 vs MI355X推理的解码阶段往往受内存带宽限制，因此两大核心系统规格为HBM 容量和带宽。测试显示，单个 MI300 节点（1536GB HBM 容量）相比 H100 节点（640GB HBM 容量）具有显著优势 ——H100 甚至无法在单节点中容纳 DeepSeek V3 FP8 模型。英伟达于 2024 年第三季度大规模量产 H200，其 144GB HBM 容量解决了容量瓶颈问题，测试中性能优于 MI300。AMD 对 H200 的回应是 MI325X，但遗憾的是其上市时间滞后，导致客户转而选择 B200。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121753608v2015wg00aomv9f\"/>来源: SemiAnalysisMI325X 原计划与 H200 同期（2024 年第三季度）出货，但因延迟至 2025 年第二季度才批量上市，直接与 2025 年第一季度推出的 HGX x86 B200 SXM 竞争。大多数客户选择 B200 而非 MI325X，这也是除 Meta 外，MI325X 未获超大规模采购的主因。需要说明的是，量产延迟并非AMD 独有问题：英伟达 GB200 NVL72 因集成 NVLink 背板的挑战及集群运营商缺乏调试工具，同样面临大规模延迟。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121754033v2016hncw5v4mol\"/>AMD 与英伟达数据中心 AI GPU 的市场份额自2023 年第一季度以来，AMD 在数据中心 AI GPU 市场份额持续增长。但 2025 年第一季度，英伟达 Blackwell 大规模投产，而 AMD 的应对产品推迟至第三季度，导致其市场份额相应下降。预计 2025 年第二季度 AMD 份额将继续下滑，但随着 MI355X 在年底推出及软件改进加速，AMD 有望在明年底或 2026 年初重新夺回部分市场份额。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121804897v201ie40vimlk8u\"/>来源:SemiAnalysis Accelerator Model, AMD Earnings, Nvidia Earnings<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121810482v2016eoklftqvmr\"/>推理基准测试方法 - 在线吞吐量与延迟为了使本文的基准测试尽可能接近真实的推理工作负载，本文的推理基准测试方法强调分析给定配置下的在线吞吐量与每个用户的端到端延迟，而不是基于传统的离线基准测试。与离线基准测试不同，离线基准测试在理想条件下测量吞吐量，不考虑实际延迟影响，本文的方法明确捕捉系统同时处理的用户数量与每个用户体验的延迟之间的权衡。通过逐步增加并发用户数量，本文测量延迟如何增加，使本文能够得出直接反映操作条件和用户体验的现实吞吐量指标。下面将首先解释需要理解的关键指标以及这些指标的定义。吞吐量衡量在给定时间内完成的工作量，例如，每个GPU 每秒可以处理多少个令牌。更高的吞吐量意味着系统可以同时处理更多的请求，提高整体容量、效率和收入。延迟指的是完成单个请求所需的时间，从发出请求到交付最终响应的时间。更低的延迟意味着更快的响应和更好的用户体验。在本文的框架中，本文关注端到端（E2E）延迟，本文在下面定义。在推理基准测试中，这两个指标是相关的。通过添加更多的并发请求来增加吞吐量通常会增加单个用户体验到的延迟。这是因为当系统处理许多并发用户时，资源变得更加紧张，导致单个请求等待更长时间。相反，优化低延迟通常会限制整体吞吐量，因为同时处理的请求更少，以保持响应迅速。理解吞吐量和延迟之间的平衡对于选择正确的配置至关重要—— 交互式应用程序优先考虑低延迟以获得响应迅速的用户体验，而批处理任务则优先考虑更高的吞吐量，即使每个请求的延迟增加。首令牌时间（TTFT）表示用户从发送请求到接收第一个生成的令牌所经历的初始延迟，反映了预填充整个输入提示令牌的时间。输出令牌之间的时间（TBOT）量化了生成初始令牌后连续令牌之间的延迟，捕捉稳态推理性能。端到端（E2E）延迟计算为 E2E 延迟 = TTFT+（输出序列长度 ×TBOT）。这是本文分析用户体验的首选指标，因为它包含了处理请求时的所有各种延迟源。这与一些仅比较每个GPU 的吞吐量与 TBOT 的分析形成对比。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121813198v201l1zbsmvbiiw\"/>来源: SemiAnalysis传统的离线基准测试忽略了这些延迟交互和并发效应，未能模拟现实的用户条件，从而产生与实际操作环境脱节的过于乐观的吞吐量数字。当离线基准测试分析吞吐量与批量大小时，结果并不准确，因为即使给定批量大小下每个GPU 的吞吐量相同，不同的 AI 芯片也可能有非常不同的延迟。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121813872v2017ic5mt2erb7\"/>离线吞吐量基准测试，来源：Signal65<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121815367v201kvg5fu68rkc\"/>推理基准测试方法 - 模型选择现实生产工作负载的模型主要有两类：密集架构和稀疏混合专家（MoE）架构。对于密集模型，本文测试了FP16 精度的 Llama3 70B 作为中等规模 FP16 部署的代表，以及 FP8 精度的 Llama3 405B 作为大规模密集场景的代表。为了对稀疏MoE 模型进行基准测试，本文选择了FP8 精度的 DeepSeekV3 670B。在算术强度、近似活动、总参数计数和内存访问模式方面，DeepSeekV3 的模型架构与 OpenAI 的 4o/4.1/o1/o3/o4 等前沿封闭模型非常匹配。因此，DeepSeek 是基准测试 OpenAI 内部模型架构的最佳代理模型。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121816594v201d36esomcjm4\"/>推理基准测试方法 - 输入 / 输出令牌长度本文对三种不同的输入和输出令牌长度组合进行基准测试，以反映现实的推理场景和性能特征。第一种使用4K 输入和 1K 输出令牌场景。这代表了以大型预填充通用矩阵乘法（GEMM）操作为特征的摘要任务。这种场景严重依赖计算，有利于英伟达 GPU 等在计算密集型预填充方面始终表现出色的架构。第二种场景，输入1k 令牌，输出 1k 令牌，与翻译或对话工作负载非常一致，平衡了预填充和解码性能需求。最后，本文测试了1k 输入和 4k 输出令牌场景。这代表了输出大量推理令牌的推理密集型任务，这意味着性能通常受内存带宽限制，而不是计算。评估所有这三种输入 / 输出长度场景可以全面了解模型和硬件在不同推理工作负载中的性能。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121822169v201ci33nn7hk9y\"/>推理基准测试方法 - 推理引擎对于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 镜像。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121827751v2018zazh47ohcz\"/>本文: SemiAnalysis相比之下，对于更大的DeepSeek 670B 模型，本文选择SGLang 作为推理引擎。SGLang 是 DeepSeek 670B 部署中最常推荐和采用的推理框架，由于其能够高效处理更大的模型尺寸和 DeepSeek 规模推理工作负载的复杂性，它得到了英伟达和 AMD 的强烈认可。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121836151v2012qk453jgq22\"/>推理基准测试方法 - 并行策略在本文的基准测试方法中，全都系统地评估了每个GPU 架构和测试场景允许的所有实际张量并行（TP）配置。例如，在对 405B 模型进行基准测试时，AMD 的 MI300X 支持 TP=4 和 TP=8 配置，而英伟达的 H100 由于内存和性能限制，通常仅支持 TP=8。对于每个并行配置，本文测量吞吐量和延迟，以构建性能上限—— 确定在给定延迟要求下提供最大吞吐量的最佳张量并行策略。这种全面的方法确保本文准确地确定适合每个GPU 平台和模型场景的最有效和性能最佳的并行设置。请注意，本文只测试单节点场景—— 随着主要 AI 实验室在生产中使用的解耦解码和解耦预填充的发明，多节点推理已成为事实上的前沿标准。不幸的是，解耦解码 / 预填充目前在 AMD 的开源软件栈上不可用，仅在英伟达的系统上可用。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121836624v201ty4ngswi70w\"/>推理基准测试方法 - 如何解释数据本文的推理基准数据应该从每美元性能和每种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 版本，以便于重现。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121837026v201z55vktbjtcu\"/>Llama3 70B FP16 吞吐量与延迟结果<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121843760v201o0uwib2p08w\"/>来源: SemiAnalysis上图显示了在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）在基准测试中大多占据主导地位。本文认为这得益于英伟达对自身硬件的深度理解和对性能调优的大量投入。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121850266v201nh9abnj4sr4\"/>来源: SemiAnalysis在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。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121851105v2018azvh0fxxva\"/>来源: SemiAnalysis在处理LLaMA 3 70B 的类摘要工作负载（4k 输入，1k 输出）时，工作负载的预填充密集特性通常更有利于英伟达 GPU。本文看到，在30 秒延迟标记后，H100 超越 MI300X，使用 vLLM 的 H200 则领先于 MI325X。然而，MI325X 的 TP=1 配置在高并发时再次表现出色，优于使用 vLLM 的 H200。搭载 TensorRT-LLM 的 H200 则始终无人能及，从 20 秒标记开始即在所有节点提供最高吞吐量。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121852203v201h0o87vjsj9o\"/>LLaMA3 405B FP8 吞吐量与延迟结果<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121854391v201xp9a83mdo85\"/>来演: 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 对内存使用的控制更佳，从而能够维持更高的内存利用率并提升性能。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121858083v201o0k5jjq7w9o\"/>来源: SemiAnalysis在处理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 视为主要竞争对手。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121859347v201xb7e1l3jc58\"/>来源: SemiAnalysis根据上图，本文可以得出结论：服务大型密集模型是AMD GPU 的优势。具体而言，MI325X 在所有延迟场景中均击败竞争对手，MI300X 甚至在约 250 秒延迟时优于使用 vLLM 的 H200。另一方面，H100 的吞吐量稳定在约 350 tokens / 秒，使用 vLLM 的 H200 为 600 tokens / 秒。与其他情况一样，搭载 TensorRT-LLM 的 H200 在 50 秒延迟标记后显著超越所有其他配置，占据绝对优势。尽管类摘要工作负载以预填充为主，但运行大型密集模型仍受内存限制，这一点从图表中也可看出。这就是AMD 选择使用 MI300X 和 MI325X 进行大型模型服务的原因。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121904821v2011d66mzdj2ru\"/>DeepSeekV3 670B FP8 吞吐量与延迟结果对于DeepSeekV3 670B，本文使用SGLang 推理框架并测试了 H200、MI300 和 MI325X。本文未测试H100，因为它无法在单个节点中容纳 DeepSeekV3 670B。在翻译和聊天应用场景（1k 输入 1k 输出）中，本文看到H200 在所有延迟级别上均击败 MI300X。MI325X 仅在 25 至 35 秒的小范围延迟内与 H200 竞争，其余延迟范围内 H200 均占优。在低延迟、高交互性场景中，当每个模型副本同时处理 4-16 个并发用户时，H200 是明显的赢家。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121905547v20182c76ib0xt1\"/>来源: SemiAnalysis在推理测试场景（1k 输入 / 4k 输出）中，H200 在所有延迟范围内均击败 MI300X。但 MI325X 在超过 100 秒的延迟范围内击败 H200，而在 100 秒以下延迟时，H200 仍是明显赢家。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121906480v201imqx1qryc2b\"/>来源: SemiAnalysis在摘要任务场景（4k 输入，1k 输出）中，H200 与 MI300X 的对比结果类似 ——H200 在所有延迟范围内均碾压 MI300X。对于 MI325X，延迟超过 25 秒后开始超越 H200。在更偏向在线低延迟的用例中，H200 击败 MI300X 和 MI325X。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121907456v201fe3g1x75q0h\"/>来源: SemiAnalysis在大多数应用所需的中低延迟场景中，H200 击败 MI300X 和 MI325X，这也是 OpenAI 等实验室选择 H200 的原因。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121922990v201b0pzykryf7j\"/>每小时每 GPU 的 TCO—— 自主拥有和运营的集群在考虑总拥有成本（TCO）时，选择 AMD 还是英伟达 GPU 需要仔细评估资本支出和持续运营成本。AMD 的 MI300X 和 MI325X GPU 的每小时总成本通常低于英伟达的 H100 和 H200 GPU。对于每个延迟和模型测试场景，本文以每百万tokens 成本为单位计算了每美元性能，以反映计入下表所示的总拥有成本后 AMD 与英伟达的性能差异。请注意，下图基于下表中的 TCO 生成，代表客户自行购买 GPU 的总成本，不反映从 Neoclouds 租赁 GPU 的成本结构。下面，本文将深入探讨资本支出、运营支出和TCO 计算背后的详细财务分析和战略考量。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121927009v201lxw9mpvnjgd\"/>来源: SemiAnalysis<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121927413v201dxo8r4k9xo0\"/>LLama3 70B FP16 每百万 tokens 成本<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121939711v201c748okiqp5q\"/>来源: SemiAnalysis在超低延迟推理中，MI325X 和 MI300X 在 LLama3 70B 聊天和翻译任务（1k 输入 / 1k 输出）的每美元性能上超越所有其他 GPU。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121940406v201pv7h19iafyo\"/>来源: SemiAnalysis从更长远的延迟周期来看，当延迟超过20 秒时，价格差异开始显现。AMD GPU 的性价比低于 H100 和使用 vLLM 的 H200，但随着延迟增加，MI325X 因其在高并发下的出色性能而比 H200 更经济。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121941176v201ecs1gt1hy8m\"/>来源: SemiAnalysis转向推理场景（1k 输入，4k 输出），从低延迟应用开始，MI325X 和 MI300X 在 TCO 性能上胜出。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121948818v2011imrhv6bjvw\"/>来源: SemiAnalysis将分析扩展到更长的延迟周期，本文发现由于性能较弱，在H100 上运行 LLaMA 3 70B 的成本效益最低。MI300X 和 MI325X 比使用 vLLM 和 TensorRT LLM 的 H200 更昂贵，但在更高延迟下更具竞争力。有趣的是，在 MI300X 上运行的成本几乎与 MI325X 相当，这表明在此案例中 MI325X 的性能提升未能证明其价格上涨的合理性<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121958193v201remiin4byn8\"/>来源: SemiAnalysis<img src=\"https://fid-75186.picgzc.qpic.cn/20250601121958876v201qmrwg1b25r7\"/>来源: SemiAnalysis摘要工作负载也呈现类似趋势。AMD GPU 在低延迟区域性价比最高，H100 则落后于所有其他配置。虽然使用 vLLM 和 TensorRT 的 H200 在中延迟区域最经济，但 MI325X 的每百万 tokens 成本低于使用 vLLM 的 H200，并与使用 TensorRT 的 H200 相当。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122007423v201m7svol3gq8s\"/>LLama3 405B FP8 每百万 tokens 成本<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122009649v201tfutwd89yj0\"/>来源: SemiAnalysis<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122015959v201j6x3dqmuo10\"/>来源: SemiAnalysis在聊天和翻译场景（1k 输入，1k 输出）中，AMD GPU 的低价和在服务大型密集模型时的更高性能使成本效率差异更加明显。本文看到，MI325X 的服务成本持续低于使用 vLLM 的 H200 和 H100，MI300X 也与使用 vLLM 的 H200 相当。尽管如此，搭载 TensorRT LLM 的 H200 在 60 秒延迟标记后凭借卓越性能再次胜出。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122023843v201uewehajxvif\"/>来源: SemiAnalysis对于405B 推理任务的超低延迟场景（1k 输入，4k 输出），MI325X 和 MI300X 无疑击败使用 vLLM 的 H200 和 H100，甚至超越使用 TRT-LLM 的 H200！<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122030242v201hqdnrvgx40z\"/>来源: SemiAnalysis从推理任务场景的更长延迟来看，与之前所有服务大型密集模型的配置一样，MI300X 和 MI325X 的性价比均高于 H100 和使用 vLLM 的 H200。但需注意，搭载 TensorRT LLM 的 H200 仍是所有配置中成本效率最高的，因其性能提升幅度超过了与 AMD GPU 的价格差异。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122032476v201igx3zb8xlzx\"/>来源: SemiAnalysis<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122041816v201jvuc6mx0vfj\"/>来源: SemiAnalysis转向摘要场景（4k 输入，1k 输出），MI325X 是明显的赢家。在低延迟时，MI325X 超越包括搭载 TensorRT LLM 的 H200 在内的所有配置，且在高延迟时仍具竞争力。MI300X 在高延迟时的成本效率也优于使用 vLLM 的 H200，在低延迟时接近搭载 TensorRT LLM 的 H200。令人惊讶的是，尽管性能更优，搭载 TensorRT LLM 的 H200 此次未能证明其价格的合理性。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122042549v20101pod1hugif\"/>DeepSeekv3 670B FP8 每百万 tokens 成本<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122044434v201pckf0i63veg\"/>来源: SemiAnalysis在聊天和翻译任务（1k 输入，1k 输出）中，MI300X 的每美元性能无法与 H200 竞争，而 MI325X 仅在 25 至 40 秒延迟内与 H200 有一定竞争力，但优势不大。每美元性能的微小提升不足以抵消切换和采用 ROCM 的成本。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122047570v201nyyeks9s8tu\"/>来源: SemiAnalysis在推理任务（1k 输入，4k 输出）中，本文看到延迟超过100 秒后，MI325X 优于 H200，每美元性能比 H200 高 20%。但在低延迟 / 中高交互性场景（即延迟低于 100 秒）中，H200 仍轻松胜出。MI300X 在推理任务的每美元性能上无法与 H200 竞争。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122048277v201iakvsozlu7j\"/>来源: SemiAnalysis在摘要任务（4k 输入，1k 输出）中，H200 在低延迟 / 高交互性的每美元性能上胜出。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122104437v201ppixuermrjm\"/>来源: SemiAnalysis在摘要任务的中高延迟场景中，MI300X 与 H200 具有竞争力，MI325X 的每美元性能比 H200 高 20-30%。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122105778v201z450yvmnzou\"/>为何除了超大规模企业外没人用 AMD？上述每TCO 性能分析聚焦于直接购买场景 —— 比较大型超大规模企业或企业直接购买硬件时的 AMD GPU 与英伟达 GPU，而非从 Neoclouds 租赁 GPU 的情况。在GPU 租赁方面，成本差异显著。AMD 相比英伟达面临显著竞争劣势，主要原因是供应有限和市场竞争不足。目前，超过100 家不同的 Neocloud 提供商提供英伟达 GPU 的短期（不足 6 个月）租赁，形成价格竞争并压低租赁成本。相比之下，仅有少数提供商提供类似的短期 AMD GPU 租赁。租赁市场的这种稀缺性导致AMD GPU 租赁价格人为高企，削弱了其整体成本竞争力。因此，在租赁市场中，无论延迟要求如何，英伟达在每美元性能上始终优于 AMD。这种不平衡解释了为何除主要超大规模企业外，AMD GPU 的采用率极低 —— 超大规模企业通常直接进行长期 GPU 采购，可利用 AMD 有利的硬件经济性，而无需面对 AMD 租赁市场的价格限制。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122107395v201v3w6i593pai\"/>对于推理计算的租赁者，AMD GPU 需达到何种租赁价格才能与英伟达竞争？2025 年第二季度，H200 的当前 1 个月期合同市场租赁价格约为 2.5 美元 / 小时 / GPU，低质量云服务的价格差异较大且更低。MI325X 的 1 个月期租赁合同尚不存在，而 MI300X 的 1 个月期租赁价格超过 2.5 美元 / 小时，这使其在租赁中缺乏竞争力。以下是本文计算的MI300X 和 MI325X 需达到的约 1 个月期租赁价格，以使其与租赁英伟达 H200 竞争。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122108001v201an8au0hcog6\"/>来源: SemiAnalysis在翻译和聊天工作负载（1k 输入，1k 输出）中，MI300X 租赁价格需定为 1.9 美元 / 小时才能与 H200 竞争，MI325X 的 1 个月期合同价格需低于 2.5 美元 / 小时才能与 H200 竞争。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122111391v2019k1bcgs5hs1\"/>来源: SemiAnalysis在推理推理任务（1k 输入，4k 输出）中，MI300X 的 1 个月期合同价格需低于 2.1-2.4 美元 / 小时，才能在每美元性能上与 H200 竞争。MI325X 则需根据交互性定价在 2.75-3 美元 / 小时 / GPU 之间，以具备竞争力。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122117796v201zaqebf0dna4\"/>来源: SemiAnalysis在摘要任务（4k 输入，1k 输出）中，MI325X 的 1 个月期合同价格应为 2.75-3 美元 / 小时，MI300X 则应定价在 2.1-2.4 美元 / 小时之间。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122118235v201bv40z8ly74z\"/>B200 性能初探由于目前缺乏软件支持，本文未在完整基准测试中纳入B200。在撰写本文时，大多数主要服务框架尚未对 B200 GPU 提供稳定支持。vLLM 的标准发布镜像尚未支持 B200（参考），SGLang 团队也未公布支持 B200 的明确时间表。在 AMD 方面，本文未对MI355X 进行基准测试，因为生产单元尚未上市。尽管存在工程样品，但漏洞尚未完全修复，因此系统尚未准备好进行测试。虽然TensorRT-LLM 支持 B200，但仅针对少量模型进行了优化，且明显缺少 FP8 DeepSeek V3。因此，本文使用TensorRT-LLM 对 B200 进行了部分模型和场景的基准测试，作为对 B200 性能的初探。下图展示了 LLaMA 70B 和 405B 在推理工作负载（1k 输入，4k 输出）中的表现。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122135457v2019l5waa8npf9\"/>来源: SemiAnalysis搭载TensorRT LLM 的 B200（标记为 B200-TRT）在 LLaMA 70B 基准测试中全面领先，整体延迟更低、吞吐量更高。MI325X 和 MI300X 与 B200 的竞争力相差甚远。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122136307v201oxd3bumtxe4\"/>来源: SemiAnalysis对于LLaMA 405B，B200 在所有延迟和吞吐量指标上再次碾压所有其他配置，甚至在本文测试的最高请求速率下仍未进入平台期。到目前为止，B200 在本文运行的基准测试中表现出极高性能。为确保全面性，本文将在未来几个月内报告MI355X 和 B200 的训练和推理性能。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122137425v2018jk4u0n2yir\"/>推理过程中的 AMD 和英伟达漏洞在基准测试过程中，本文遇到了多个障碍。服务框架中的大量调优标志导致配置组合呈爆炸式增长。例如，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 一样被移除。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122138971v201x7fejafypgd\"/>AMD SGLang 持续集成测试缺乏覆盖 parity在过去的5 个月里，AMD 的整体持续集成（CI）有了很大的改进。5 个月前，AMD 的 SGLang 推理 CI 测试为零，现在已经有了一些。不幸的是，其 CI 测试覆盖率仍远不及 NVIDIA。三周前，AMD 的 AI 负责人 Anush 要求他们的一位核心工程师 “996” 工作以修复 SGLang 的 CI 问题。AMD 虽然取得了一些进展，但遗憾的是仍有数十个单元测试缺失。如果没有适当的测试，AMD 的软件质量将继续较差，存在更多漏洞，导致开发者体验不佳和采用速度缓慢。<img src=\"https://fid-75186.picgzc.qpic.cn/20250601122140739v2019p0t4455ei5\"/>来源：SemiAnalysis, SGLang, Github</article></body></html>","source":"tencent","collect":0,"html":"<!DOCTYPE html>\n<html>\n<head>\n<meta http-equiv=\"Content-Type\" content=\"text/html; charset=utf-8\" />\n<meta name=\"viewport\" content=\"width=device-width,initial-scale=1.0,minimum-scale=1.0,maximum-scale=1.0,user-scalable=no\"/>\n<meta name=\"format-detection\" content=\"telephone=no,email=no,address=no\" />\n<title>AMD vs NVIDIA 推理基准测试：谁赢了？</title>\n<style type=\"text/css\">\na,abbr,acronym,address,applet,article,aside,audio,b,big,blockquote,body,canvas,caption,center,cite,code,dd,del,details,dfn,div,dl,dt,\nem,embed,fieldset,figcaption,figure,footer,form,h1,h2,h3,h4,h5,h6,header,hgroup,html,i,iframe,img,ins,kbd,label,legend,li,mark,menu,nav,\nobject,ol,output,p,pre,q,ruby,s,samp,section,small,span,strike,strong,sub,summary,sup,table,tbody,td,tfoot,th,thead,time,tr,tt,u,ul,var,video{ font:inherit;margin:0;padding:0;vertical-align:baseline;border:0 }\nbody{ font-size:16px; line-height:1.5; color:#999; background:transparent; }\n.wrapper{ overflow:hidden;word-break:break-all;padding:10px; }\nh1,h2{ font-weight:normal; line-height:1.35; margin-bottom:.6em; }\nh3,h4,h5,h6{ line-height:1.35; margin-bottom:1em; }\nh1{ font-size:24px; }\nh2{ font-size:20px; }\nh3{ font-size:18px; }\nh4{ font-size:16px; }\nh5{ font-size:14px; }\nh6{ font-size:12px; }\np,ul,ol,blockquote,dl,table{ margin:1.2em 0; }\nul,ol{ margin-left:2em; }\nul{ list-style:disc; }\nol{ list-style:decimal; }\nli,li p{ margin:10px 0;}\nimg{ max-width:100%;display:block;margin:0 auto 1em; }\nblockquote{ color:#B5B2B1; border-left:3px solid #aaa; padding:1em; }\nstrong,b{font-weight:bold;}\nem,i{font-style:italic;}\ntable{ width:100%;border-collapse:collapse;border-spacing:1px;margin:1em 0;font-size:.9em; }\nth,td{ padding:5px;text-align:left;border:1px solid #aaa; }\nth{ font-weight:bold;background:#5d5d5d; }\n.symbol-link{font-weight:bold;}\n/* header{ border-bottom:1px solid #494756; } */\n.title{ margin:0 0 8px;line-height:1.3;color:#ddd; }\n.meta {color:#5e5c6d;font-size:13px;margin:0 0 .5em; }\na{text-decoration:none; color:#2a4b87;}\n.meta .head { display: inline-block; overflow: hidden}\n.head .h-thumb { width: 30px; height: 30px; margin: 0; padding: 0; border-radius: 50%; float: left;}\n.head .h-content { margin: 0; padding: 0 0 0 9px; float: left;}\n.head .h-name {font-size: 13px; color: #eee; margin: 0;}\n.head .h-time {font-size: 11px; color: #7E829C; margin: 0;line-height: 11px;}\n.small {font-size: 12.5px; display: inline-block; transform: scale(0.9); -webkit-transform: scale(0.9); transform-origin: left; -webkit-transform-origin: left;}\n.smaller {font-size: 12.5px; display: inline-block; transform: scale(0.8); -webkit-transform: scale(0.8); transform-origin: left; -webkit-transform-origin: left;}\n.bt-text {font-size: 12px;margin: 1.5em 0 0 0}\n.bt-text p {margin: 0}\n</style>\n</head>\n<body>\n<div class=\"wrapper\">\n<header>\n<h2 class=\"title\">\nAMD vs NVIDIA 推理基准测试：谁赢了？\n</h2>\n\n<h4 class=\"meta\">\n\n\n2025-06-01 12:12 北京时间&nbsp;&nbsp;&nbsp;<a href=http://gu.qq.com/resources/shy/news/detail-v2/index.html#/?id=nesSN20250601122324a494ea7a&s=b>半导体产业纵横</a>\n\n\n</h4>\n\n</header>\n<article>\n<div>\n本文由半导体产业纵横（ID：ICVIEWS）编译自semianslysisAMD or NVIDIA?长期以来，业界一直有观点认为，在总拥有成本（TCO）下，AMD 的 AI 服务器推理性能优于英伟达。过去六个月，本文通过对英伟达和AMD 提供的推理解决方案进行全面分析与基准测试，对这一说法展开了调查验证。原本期待得到一个简单结论，但结果远比想象中复杂且令人意外 —— 不同任务（如聊天应用、文档...\n\n<a href=\"http://gu.qq.com/resources/shy/news/detail-v2/index.html#/?id=nesSN20250601122324a494ea7a&s=b\">Web Link</a>\n\n</div>\n\n\n</article>\n</div>\n</body>\n</html>\n","type":0,"thumbnail":"","relate_stocks":{"SG9999015986.USD":"LIONGLOBAL DISRUPTIVE INNOVATION \"I\" (USD) ACC","LU1642822529.SGD":"THREADNEEDLE (LUX) GLOBAL TECHNOLOGY \"A\" (SGD) ACC","NVDU":"Direxion Daily NVDA Bull 2X Shares","LU1232071149.USD":"AZ FUND 1 GLOBAL GROWTH SELECTOR \"AAZ\" (USDHDG) ACC","NVD3.UK":"LS 3X NVIDIA","LU2023250330.USD":"ALLIANZ INCOME AND GROWTH \"AMG\" (USD) INC","LU1814569148.SGD":"WELLINGTON GLOBAL QUALITY GROWTH \"D\" (SGDHDG) ACC","LU0476273544.USD":"CT (LUX) I GLOBAL TECHNOLOGY \"BU\" (USD) ACC","BK4543":"AI","NVDS.UK":"LS -1X NVIDIA","AMD":"美国超微公司","LU1720051017.SGD":"Allianz Global Artificial Intelligence AT Acc H2-SGD","BK4585":"ETF&股票定投概念","SG9999002232.USD":"Allianz Global High Payout USD","LU0061475181.USD":"THREADNEEDLE (LUX) AMERICAN \"AU\" (USD) ACC","LU2357305700.SGD":"Allianz Global Artificial Intelligence ET H2-SGD","NVDY":"YIELDMAX NVDA OPTION INCOME STRATEGY ETF","LU0289961442.SGD":"SUSTAINABLE GLOBAL THEMATIC PORTFOLIO \"AX\" (SGD) ACC","LU0417517546.SGD":"Allianz US Equity Cl AT Acc SGD","LU1839511570.USD":"WELLS FARGO GLOBAL FACTOR ENHANCED EQUITY \"I\" (USD) ACC","LU1718418525.SGD":"JPMorgan Investment Funds - Global Select Equity A (acc) SGD","NVD2.UK":"2X NVIDIA ETP","BK4566":"资本集团","LU2471134952.CNY":"INVESCO GLOBAL EQUITY INCOME ADVANTAGE \"A\" (CNYHDG) INC","LU0154236417.USD":"BGF US FLEXIBLE EQUITY \"A2\" ACC","2NVD.UK":"2X NVIDIA ETP","HK0000320223.HKD":"TAIKANG KAITAI CHINA NEW OPPORTUNITIES FUND \"A\" (HKD) ACC","GB00BDT5M118.USD":"天利环球扩展Alpha基金A Acc","LU2471134879.HKD":"INVESCO GLOBAL EQUITY INCOME ADVANTAGE \"A\" (HKD) INC","LU0390134368.USD":"FRANKLIN GLOBAL GROWTH \"A\" (USD) ACC","NVDD":"Direxion Daily NVDA Bear 1X Shares","3NVD.UK":"LS 3X NVIDIA","LU0127658192.USD":"EASTSPRING INVESTMENTS GLOBAL TECHNOLOGY \"A\" (USD) ACC","SNVD.UK":"LS -1X NVIDIA","SGXZ51526630.SGD":"大华环球创新基金A Acc SGD","LU0094547139.USD":"abrdn SICAV I - GLOBAL SUSTAINABLE EQUITY FUND \"A\" (USD) ACC","NVDA":"英伟达","NVIW.SI":"NVDA 3xLongSG261006","LU1066051498.USD":"HSBC GIF GLOBAL EQUITY VOLATILITY FOCUSED \"AM2\" (USD) INC","IE00BFSS8Q28.SGD":"Janus Henderson Balanced A Inc SGD-H","LU0053666078.USD":"摩根大通基金-美国股票A（离岸）美元","BK4598":"佩洛西持仓","LU0965509010.AUD":"AB LOW VOLATILITY EQUITY PORTFOLIO \"AD\" (AUDHDG) INC","NVDS":"Tradr 1.5X Short NVDA Daily ETF","GFS":"GLOBALFOUNDRIES Inc.","LU2430703251.USD":"WELLINGTON MULTI-ASSET HIGH INCOME \"AM4\" (USD) INC","LU0345770308.USD":"NINETY ONE GSF GLOBAL STRATEGIC EQUITY \"A\" (USD) ACC"},"source_url":"http://gu.qq.com/resources/shy/news/detail-v2/index.html#/?id=nesSN20250601122324a494ea7a&s=b","is_english":false,"share_image_url":"https://static.laohu8.com/9a95c1376e76363c1401fee7d3717173","article_id":"2540733947","content_text":"本文由半导体产业纵横（ID：ICVIEWS）编译自semianslysisAMD 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 覆盖不足的情况。主要观点对于购买硬件并使用vLLM/SGLang 的客户，根据工作负载和延迟要求，单节点 H200 部署与单节点 MI325X 的每美元性能（perf/$）呈现 “各有胜负” 的特点：部分场景 H200 更优，部分场景 MI325X 更优。在大多数测试场景中，MI300X 与 H200 相比缺乏竞争力，无论是绝对性能还是每美元性能均表现较差。但对于 Llama3 405B 和 DeepSeekv3 670B 模型，MI300X 在绝对性能和每美元性能上均优于 H100。对于采用中短期合同（不足6 个月）租赁 GPU 的客户，由于仅有少数提供商提供 AMD GPU 短期租赁，市场供应紧张推高了价格，导致英伟达 GPU 的每美元性能始终更优。反观英伟达生态，超百家 Neoclouds 提供商提供中短期租赁服务，充足的供应形成竞争性市场，有效降低了成本。MI325X 本应与 H200 竞争，但核心问题在于：其大规模出货推迟至 2025 年第二季度，此时 HGX B200 已出货一个季度，导致多数供应商选择 B200 而非 MI325X，进而造成 MI325X 销量低迷（除 Meta 外，未见大规模超算级采购）。MI355X 计划于 2025 年底开始出货，比 B200 晚两个季度。当前B200 和 GB200 的软件仍未完全成熟。例如，FP8 精度的 DeepSeek V3 在 TensorRT-LLM（TRT-LLM）、vLLM 或 SGLang 上无法完全正常运行。在目前可部署的工作负载和模型中，B200 占据主导地位，MI325 和 H200 的性能甚至无法接近其水平。英伟达的TRT-LLM 推理框架素以 “开发者体验差” 著称。尽管发布 PyTorch 后端和类似 vLLM 的单行 CLI 服务命令后有所改善，但在开发者体验上仍无法与 vLLM 或 SGLang 比肩。TRT-LLM 仍需全面支持 DeepSeek，并提供预构建的 TRT-LLM-serve 容器镜像。服务框架提供的大量配置标志导致“组合爆炸”，使全面基准测试几乎不可能完成。AMD 通过添加环境变量进一步复杂化了问题（尽管本文此前建议删除这些变量）。大多数用户无法获得最佳性能，因为若不对每种工作负载进行深度调优，根本无法确定最优标志和变量组合。AMD AI 负责人 Anush 及其团队正努力提升 ROCM SGLang 的 CI 覆盖率至与英伟达持平，但目前覆盖率仍不足 10%，差距显著。AMD 应利用其雄厚财务资源增加内部研发集群投入。上个季度，AMD 花费 7.49 亿美元用于股票回购，而内部研发集群资源投入仅约 1300 万美元。研发集群资源匮乏是其开发者体验落后于英伟达的关键原因，也是 AMD 在 AI 软件领域持续滞后的根源。本文认为，即便从回购资金中划拨一小部分用于研发集群，也能在不牺牲短期股东回报的前提下，带来更优的长期价值。由于缺乏CI 测试和数值精度内核，与 CUDA 相比，模型在 ROCM 上的各项评估得分普遍更低。H100 vs MI300X vs H200 vs MI325X vs B200 vs MI355X推理的解码阶段往往受内存带宽限制，因此两大核心系统规格为HBM 容量和带宽。测试显示，单个 MI300 节点（1536GB HBM 容量）相比 H100 节点（640GB HBM 容量）具有显著优势 ——H100 甚至无法在单节点中容纳 DeepSeek V3 FP8 模型。英伟达于 2024 年第三季度大规模量产 H200，其 144GB HBM 容量解决了容量瓶颈问题，测试中性能优于 MI300。AMD 对 H200 的回应是 MI325X，但遗憾的是其上市时间滞后，导致客户转而选择 B200。来源: SemiAnalysisMI325X 原计划与 H200 同期（2024 年第三季度）出货，但因延迟至 2025 年第二季度才批量上市，直接与 2025 年第一季度推出的 HGX x86 B200 SXM 竞争。大多数客户选择 B200 而非 MI325X，这也是除 Meta 外，MI325X 未获超大规模采购的主因。需要说明的是，量产延迟并非AMD 独有问题：英伟达 GB200 NVL72 因集成 NVLink 背板的挑战及集群运营商缺乏调试工具，同样面临大规模延迟。AMD 与英伟达数据中心 AI GPU 的市场份额自2023 年第一季度以来，AMD 在数据中心 AI GPU 市场份额持续增长。但 2025 年第一季度，英伟达 Blackwell 大规模投产，而 AMD 的应对产品推迟至第三季度，导致其市场份额相应下降。预计 2025 年第二季度 AMD 份额将继续下滑，但随着 MI355X 在年底推出及软件改进加速，AMD 有望在明年底或 2026 年初重新夺回部分市场份额。来源:SemiAnalysis Accelerator Model, AMD Earnings, Nvidia Earnings推理基准测试方法 - 在线吞吐量与延迟为了使本文的基准测试尽可能接近真实的推理工作负载，本文的推理基准测试方法强调分析给定配置下的在线吞吐量与每个用户的端到端延迟，而不是基于传统的离线基准测试。与离线基准测试不同，离线基准测试在理想条件下测量吞吐量，不考虑实际延迟影响，本文的方法明确捕捉系统同时处理的用户数量与每个用户体验的延迟之间的权衡。通过逐步增加并发用户数量，本文测量延迟如何增加，使本文能够得出直接反映操作条件和用户体验的现实吞吐量指标。下面将首先解释需要理解的关键指标以及这些指标的定义。吞吐量衡量在给定时间内完成的工作量，例如，每个GPU 每秒可以处理多少个令牌。更高的吞吐量意味着系统可以同时处理更多的请求，提高整体容量、效率和收入。延迟指的是完成单个请求所需的时间，从发出请求到交付最终响应的时间。更低的延迟意味着更快的响应和更好的用户体验。在本文的框架中，本文关注端到端（E2E）延迟，本文在下面定义。在推理基准测试中，这两个指标是相关的。通过添加更多的并发请求来增加吞吐量通常会增加单个用户体验到的延迟。这是因为当系统处理许多并发用户时，资源变得更加紧张，导致单个请求等待更长时间。相反，优化低延迟通常会限制整体吞吐量，因为同时处理的请求更少，以保持响应迅速。理解吞吐量和延迟之间的平衡对于选择正确的配置至关重要—— 交互式应用程序优先考虑低延迟以获得响应迅速的用户体验，而批处理任务则优先考虑更高的吞吐量，即使每个请求的延迟增加。首令牌时间（TTFT）表示用户从发送请求到接收第一个生成的令牌所经历的初始延迟，反映了预填充整个输入提示令牌的时间。输出令牌之间的时间（TBOT）量化了生成初始令牌后连续令牌之间的延迟，捕捉稳态推理性能。端到端（E2E）延迟计算为 E2E 延迟 = TTFT+（输出序列长度 ×TBOT）。这是本文分析用户体验的首选指标，因为它包含了处理请求时的所有各种延迟源。这与一些仅比较每个GPU 的吞吐量与 TBOT 的分析形成对比。来源: SemiAnalysis传统的离线基准测试忽略了这些延迟交互和并发效应，未能模拟现实的用户条件，从而产生与实际操作环境脱节的过于乐观的吞吐量数字。当离线基准测试分析吞吐量与批量大小时，结果并不准确，因为即使给定批量大小下每个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 版本，以便于重现。Llama3 70B FP16 吞吐量与延迟结果来源: SemiAnalysis上图显示了在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）在基准测试中大多占据主导地位。本文认为这得益于英伟达对自身硬件的深度理解和对性能调优的大量投入。来源: SemiAnalysis在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。来源: SemiAnalysis在处理LLaMA 3 70B 的类摘要工作负载（4k 输入，1k 输出）时，工作负载的预填充密集特性通常更有利于英伟达 GPU。本文看到，在30 秒延迟标记后，H100 超越 MI300X，使用 vLLM 的 H200 则领先于 MI325X。然而，MI325X 的 TP=1 配置在高并发时再次表现出色，优于使用 vLLM 的 H200。搭载 TensorRT-LLM 的 H200 则始终无人能及，从 20 秒标记开始即在所有节点提供最高吞吐量。LLaMA3 405B FP8 吞吐量与延迟结果来演: 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 对内存使用的控制更佳，从而能够维持更高的内存利用率并提升性能。来源: SemiAnalysis在处理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 视为主要竞争对手。来源: SemiAnalysis根据上图，本文可以得出结论：服务大型密集模型是AMD GPU 的优势。具体而言，MI325X 在所有延迟场景中均击败竞争对手，MI300X 甚至在约 250 秒延迟时优于使用 vLLM 的 H200。另一方面，H100 的吞吐量稳定在约 350 tokens / 秒，使用 vLLM 的 H200 为 600 tokens / 秒。与其他情况一样，搭载 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 是明显的赢家。来源: SemiAnalysis在推理测试场景（1k 输入 / 4k 输出）中，H200 在所有延迟范围内均击败 MI300X。但 MI325X 在超过 100 秒的延迟范围内击败 H200，而在 100 秒以下延迟时，H200 仍是明显赢家。来源: SemiAnalysis在摘要任务场景（4k 输入，1k 输出）中，H200 与 MI300X 的对比结果类似 ——H200 在所有延迟范围内均碾压 MI300X。对于 MI325X，延迟超过 25 秒后开始超越 H200。在更偏向在线低延迟的用例中，H200 击败 MI300X 和 MI325X。来源: SemiAnalysis在大多数应用所需的中低延迟场景中，H200 击败 MI300X 和 MI325X，这也是 OpenAI 等实验室选择 H200 的原因。每小时每 GPU 的 TCO—— 自主拥有和运营的集群在考虑总拥有成本（TCO）时，选择 AMD 还是英伟达 GPU 需要仔细评估资本支出和持续运营成本。AMD 的 MI300X 和 MI325X GPU 的每小时总成本通常低于英伟达的 H100 和 H200 GPU。对于每个延迟和模型测试场景，本文以每百万tokens 成本为单位计算了每美元性能，以反映计入下表所示的总拥有成本后 AMD 与英伟达的性能差异。请注意，下图基于下表中的 TCO 生成，代表客户自行购买 GPU 的总成本，不反映从 Neoclouds 租赁 GPU 的成本结构。下面，本文将深入探讨资本支出、运营支出和TCO 计算背后的详细财务分析和战略考量。来源: SemiAnalysisLLama3 70B FP16 每百万 tokens 成本来源: SemiAnalysis在超低延迟推理中，MI325X 和 MI300X 在 LLama3 70B 聊天和翻译任务（1k 输入 / 1k 输出）的每美元性能上超越所有其他 GPU。来源: SemiAnalysis从更长远的延迟周期来看，当延迟超过20 秒时，价格差异开始显现。AMD GPU 的性价比低于 H100 和使用 vLLM 的 H200，但随着延迟增加，MI325X 因其在高并发下的出色性能而比 H200 更经济。来源: SemiAnalysis转向推理场景（1k 输入，4k 输出），从低延迟应用开始，MI325X 和 MI300X 在 TCO 性能上胜出。来源: SemiAnalysis将分析扩展到更长的延迟周期，本文发现由于性能较弱，在H100 上运行 LLaMA 3 70B 的成本效益最低。MI300X 和 MI325X 比使用 vLLM 和 TensorRT LLM 的 H200 更昂贵，但在更高延迟下更具竞争力。有趣的是，在 MI300X 上运行的成本几乎与 MI325X 相当，这表明在此案例中 MI325X 的性能提升未能证明其价格上涨的合理性来源: SemiAnalysis来源: SemiAnalysis摘要工作负载也呈现类似趋势。AMD GPU 在低延迟区域性价比最高，H100 则落后于所有其他配置。虽然使用 vLLM 和 TensorRT 的 H200 在中延迟区域最经济，但 MI325X 的每百万 tokens 成本低于使用 vLLM 的 H200，并与使用 TensorRT 的 H200 相当。LLama3 405B FP8 每百万 tokens 成本来源: SemiAnalysis来源: SemiAnalysis在聊天和翻译场景（1k 输入，1k 输出）中，AMD GPU 的低价和在服务大型密集模型时的更高性能使成本效率差异更加明显。本文看到，MI325X 的服务成本持续低于使用 vLLM 的 H200 和 H100，MI300X 也与使用 vLLM 的 H200 相当。尽管如此，搭载 TensorRT LLM 的 H200 在 60 秒延迟标记后凭借卓越性能再次胜出。来源: SemiAnalysis对于405B 推理任务的超低延迟场景（1k 输入，4k 输出），MI325X 和 MI300X 无疑击败使用 vLLM 的 H200 和 H100，甚至超越使用 TRT-LLM 的 H200！来源: SemiAnalysis从推理任务场景的更长延迟来看，与之前所有服务大型密集模型的配置一样，MI300X 和 MI325X 的性价比均高于 H100 和使用 vLLM 的 H200。但需注意，搭载 TensorRT LLM 的 H200 仍是所有配置中成本效率最高的，因其性能提升幅度超过了与 AMD GPU 的价格差异。来源: SemiAnalysis来源: SemiAnalysis转向摘要场景（4k 输入，1k 输出），MI325X 是明显的赢家。在低延迟时，MI325X 超越包括搭载 TensorRT LLM 的 H200 在内的所有配置，且在高延迟时仍具竞争力。MI300X 在高延迟时的成本效率也优于使用 vLLM 的 H200，在低延迟时接近搭载 TensorRT LLM 的 H200。令人惊讶的是，尽管性能更优，搭载 TensorRT LLM 的 H200 此次未能证明其价格的合理性。DeepSeekv3 670B FP8 每百万 tokens 成本来源: SemiAnalysis在聊天和翻译任务（1k 输入，1k 输出）中，MI300X 的每美元性能无法与 H200 竞争，而 MI325X 仅在 25 至 40 秒延迟内与 H200 有一定竞争力，但优势不大。每美元性能的微小提升不足以抵消切换和采用 ROCM 的成本。来源: SemiAnalysis在推理任务（1k 输入，4k 输出）中，本文看到延迟超过100 秒后，MI325X 优于 H200，每美元性能比 H200 高 20%。但在低延迟 / 中高交互性场景（即延迟低于 100 秒）中，H200 仍轻松胜出。MI300X 在推理任务的每美元性能上无法与 H200 竞争。来源: SemiAnalysis在摘要任务（4k 输入，1k 输出）中，H200 在低延迟 / 高交互性的每美元性能上胜出。来源: SemiAnalysis在摘要任务的中高延迟场景中，MI300X 与 H200 具有竞争力，MI325X 的每美元性能比 H200 高 20-30%。为何除了超大规模企业外没人用 AMD？上述每TCO 性能分析聚焦于直接购买场景 —— 比较大型超大规模企业或企业直接购买硬件时的 AMD GPU 与英伟达 GPU，而非从 Neoclouds 租赁 GPU 的情况。在GPU 租赁方面，成本差异显著。AMD 相比英伟达面临显著竞争劣势，主要原因是供应有限和市场竞争不足。目前，超过100 家不同的 Neocloud 提供商提供英伟达 GPU 的短期（不足 6 个月）租赁，形成价格竞争并压低租赁成本。相比之下，仅有少数提供商提供类似的短期 AMD GPU 租赁。租赁市场的这种稀缺性导致AMD GPU 租赁价格人为高企，削弱了其整体成本竞争力。因此，在租赁市场中，无论延迟要求如何，英伟达在每美元性能上始终优于 AMD。这种不平衡解释了为何除主要超大规模企业外，AMD GPU 的采用率极低 —— 超大规模企业通常直接进行长期 GPU 采购，可利用 AMD 有利的硬件经济性，而无需面对 AMD 租赁市场的价格限制。对于推理计算的租赁者，AMD GPU 需达到何种租赁价格才能与英伟达竞争？2025 年第二季度，H200 的当前 1 个月期合同市场租赁价格约为 2.5 美元 / 小时 / GPU，低质量云服务的价格差异较大且更低。MI325X 的 1 个月期租赁合同尚不存在，而 MI300X 的 1 个月期租赁价格超过 2.5 美元 / 小时，这使其在租赁中缺乏竞争力。以下是本文计算的MI300X 和 MI325X 需达到的约 1 个月期租赁价格，以使其与租赁英伟达 H200 竞争。来源: SemiAnalysis在翻译和聊天工作负载（1k 输入，1k 输出）中，MI300X 租赁价格需定为 1.9 美元 / 小时才能与 H200 竞争，MI325X 的 1 个月期合同价格需低于 2.5 美元 / 小时才能与 H200 竞争。来源: SemiAnalysis在推理推理任务（1k 输入，4k 输出）中，MI300X 的 1 个月期合同价格需低于 2.1-2.4 美元 / 小时，才能在每美元性能上与 H200 竞争。MI325X 则需根据交互性定价在 2.75-3 美元 / 小时 / GPU 之间，以具备竞争力。来源: SemiAnalysis在摘要任务（4k 输入，1k 输出）中，MI325X 的 1 个月期合同价格应为 2.75-3 美元 / 小时，MI300X 则应定价在 2.1-2.4 美元 / 小时之间。B200 性能初探由于目前缺乏软件支持，本文未在完整基准测试中纳入B200。在撰写本文时，大多数主要服务框架尚未对 B200 GPU 提供稳定支持。vLLM 的标准发布镜像尚未支持 B200（参考），SGLang 团队也未公布支持 B200 的明确时间表。在 AMD 方面，本文未对MI355X 进行基准测试，因为生产单元尚未上市。尽管存在工程样品，但漏洞尚未完全修复，因此系统尚未准备好进行测试。虽然TensorRT-LLM 支持 B200，但仅针对少量模型进行了优化，且明显缺少 FP8 DeepSeek V3。因此，本文使用TensorRT-LLM 对 B200 进行了部分模型和场景的基准测试，作为对 B200 性能的初探。下图展示了 LLaMA 70B 和 405B 在推理工作负载（1k 输入，4k 输出）中的表现。来源: SemiAnalysis搭载TensorRT LLM 的 B200（标记为 B200-TRT）在 LLaMA 70B 基准测试中全面领先，整体延迟更低、吞吐量更高。MI325X 和 MI300X 与 B200 的竞争力相差甚远。来源: SemiAnalysis对于LLaMA 405B，B200 在所有延迟和吞吐量指标上再次碾压所有其他配置，甚至在本文测试的最高请求速率下仍未进入平台期。到目前为止，B200 在本文运行的基准测试中表现出极高性能。为确保全面性，本文将在未来几个月内报告MI355X 和 B200 的训练和推理性能。推理过程中的 AMD 和英伟达漏洞在基准测试过程中，本文遇到了多个障碍。服务框架中的大量调优标志导致配置组合呈爆炸式增长。例如，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 一样被移除。AMD SGLang 持续集成测试缺乏覆盖 parity在过去的5 个月里，AMD 的整体持续集成（CI）有了很大的改进。5 个月前，AMD 的 SGLang 推理 CI 测试为零，现在已经有了一些。不幸的是，其 CI 测试覆盖率仍远不及 NVIDIA。三周前，AMD 的 AI 负责人 Anush 要求他们的一位核心工程师 “996” 工作以修复 SGLang 的 CI 问题。AMD 虽然取得了一些进展，但遗憾的是仍有数十个单元测试缺失。如果没有适当的测试，AMD 的软件质量将继续较差，存在更多漏洞，导致开发者体验不佳和采用速度缓慢。来源：SemiAnalysis, SGLang, Github","news_type":1,"symbols_score_info":{"2NVD.UK":0.6,"3NVD.UK":0.6,"AMD":1,"GFS":1,"NVD2.UK":0.6,"NVD3.UK":0.6,"NVDA":1,"NVDD":0.6,"NVDS":0.6,"NVDS.UK":0.6,"NVDU":0.6,"NVDY":0.6,"NVIW.SI":0.6,"SNVD.UK":0.6}},"isVote":1,"tweetType":1,"viewCount":1741,"commentLimit":10,"likeStatus":false,"favoriteStatus":false,"reportStatus":false,"symbols":["NVDA"],"verified":2,"subType":0,"readableState":1,"langContent":"CN","currentLanguage":"CN","warmUpFlag":false,"orderFlag":false,"shareable":true,"causeOfNotShareable":"","featuresForAnalytics":[],"commentAndTweetFlag":false,"andRepostAutoSelectedFlag":false,"upFlag":false,"length":84,"optionInvolvedFlag":false,"xxTargetLangEnum":"ZH_CN"},"commentList":[{"id":441634024993488,"commentId":"441634024993488","gmtCreate":1748859699093,"gmtModify":1748866559041,"authorId":3474932182717872,"author":{"id":3474932182717872,"idStr":"3474932182717872","authorId":3474932182717872,"name":"CDMD","avatar":"https://static.laohu8.com/default-avatar.jpg","vip":1,"hat":"https://static.tigerbbs.com/0a8758340a08196056f8bc1e54805193","crmLevel":7,"crmLevelSwitch":0,"individualDisplayBadges":[]},"repliedAuthorId":0,"objectId":441297822572768,"objectIdStr":"441297822572768","type":1,"supId":0,"supIdStr":"0","prevId":0,"prevIdStr":"0","content":"工程师不过是牛马，他们的思维不会考虑利润，amd基本没有什么利润","text":"工程师不过是牛马，他们的思维不会考虑利润，amd基本没有什么利润","html":"工程师不过是牛马，他们的思维不会考虑利润，amd基本没有什么利润","likeSize":0,"commentSize":0,"subComments":[],"verified":10,"allocateAmount":0,"commentType":"valid","coins":0,"score":0,"disclaimerType":0},{"id":441503531492224,"commentId":"441503531492224","gmtCreate":1748827553663,"gmtModify":1748827557642,"authorId":4099470509812690,"author":{"id":4099470509812690,"idStr":"4099470509812690","authorId":4099470509812690,"name":"一只没有耳朵一只没有尾巴","avatar":"https://static.laohu8.com/default-avatar.jpg","vip":1,"crmLevel":7,"crmLevelSwitch":1,"individualDisplayBadges":[]},"repliedAuthorId":0,"objectId":441297822572768,"objectIdStr":"441297822572768","type":1,"supId":0,"supIdStr":"0","prevId":0,"prevIdStr":"0","content":"说的是每美元性能，还是有意义的。","text":"说的是每美元性能，还是有意义的。","html":"说的是每美元性能，还是有意义的。","likeSize":0,"commentSize":0,"subComments":[],"verified":10,"allocateAmount":0,"commentType":"valid","coins":0,"score":0,"disclaimerType":0}],"isCommentEnd":false,"isTiger":false,"isWeiXinMini":false,"url":"/m/post/441297822572768"}