AMD MI300X GPU 计算、内存、通信性能分析

关键词：GPU 性能评估、大语言模型推理、AMD MI300X、NVIDIA H100/H200、软件生态优化

• AMD MI300X GPU Performance Analysis
• https://arxiv.org/pdf/2510.27583
• 1.2 万字，阅读需 40 分钟，播客 25 分钟

• 突破 GPU 通信瓶颈：NCCL 协议创新与 25-95% 带宽利用率的量化研究
• 大规模 CUDA 程序漏洞研究：从特征分析到创新检测框架 Simulee 的高效识别实践，代码开源！（注：非 LLM 方法）
• LLM推理极限建模：Bandwidth, Compute, Sync and Capacity are All You Need

本文聚焦 AMD MI300X GPU 在大语言模型（LLM）推理中的性能表现，从计算吞吐量、内存带宽、互连通信三个核心维度展开全面评估，并与 NVIDIA H100/H200 进行对比。

研究通过厂商微基准测试与自定义内核，结合 Llama 70B 模型低精度（FP8、FP16）端到端推理基准测试发现，尽管 MI300X 理论计算能力是 H100 的 1.5 倍，但实际 LLM 推理性能仅为 H100/H200 的 37%-66%。

研究表明，AMD 硬件有优势，但软件生态成熟度不足，需优化通信库等才能提升在大规模 AI 工作负载中的竞争力。

unsetunset本文目录unsetunset

• 本文目录
• 关键问题
• 问题一：算力理论值与实际性能的割裂——差距核心是硬件架构缺陷还是软件栈成熟度滞后？
• 问题二：硬件优势向实际竞争力转化的梗阻——仅优化通信库和内核能否弥补生态差距？
• 一、引言
• 二、计算性能基准测试
• AMD 架构
• 2.1 基准测试方法
• 2.2 结果
• 2.3 软件效率
• 三、内存性能基准测试
• 3.1 基准测试方法
• 3.2 核函数实现
• 3.3 测试结果
• 四、通信性能基准测试
• NVLINK
• Infinity Fabric
• 4.1 基准测试方法
• 4.2 测试结果
• 五、LLM 性能
• 5.1 FP8 精度测试结果
• 5.2 FP16 精度测试结果
• 六、总结
• 参考文献

交流加群请在 NeuralTalk 公众号后台回复：加群

unsetunset关键问题unsetunset

问题一：算力理论值与实际性能的割裂——差距核心是硬件架构缺陷还是软件栈成熟度滞后？

AMD MI300X 理论计算能力达到 NVIDIA H100 的 1.5 倍，但其 LLM 推理实际性能仅为 H100/H200 的 37%-66%，且 FLOPs 利用率仅 45%（远低于 NVIDIA 的 93%），这一巨大差距的核心是硬件架构设计缺陷，还是软件栈成熟度的根本性滞后？

从硬件层面看，AMD MI300X 的架构设计（如 8 个 XCD 计算 die、Infinity Fabric 互连、8 组 HBM3 堆栈）具备理论算力优势，其 FP8 理论峰值达 2615 TFLOPs，是 H100（1979 TFLOPs）的 1.32 倍，内存带宽也能达到 5.3 TB/s 的理论值，硬件规格并未出现结构性缺陷。

而软件层面是核心瓶颈：

问题二：硬件优势向实际竞争力转化的梗阻——仅优化通信库和内核能否弥补生态差距？

MI300X 在 HBM 容量、内存带宽硬件指标上展现出一定竞争力，且在 FP16 解码阶段能达到 H100 80% 的性能，却始终无法在端到端 LLM 推理中追平 NVIDIA，AMD 仅靠优化通信库和内核就能弥补与 NVIDIA 的生态差距吗？

仅靠优化通信库和内核无法完全弥补 AMD 与 NVIDIA 的生态差距，这一举措只能缓解部分性能瓶颈，却无法解决 AMD 软件生态“全栈性滞后”的核心问题。

一方面，优化通信库（RCCL）和内核能改善局部性能：

另一方面，NVIDIA 的生态优势是全栈式的，而非单一库或内核的优化：

论文也在总结中强调，AMD 要实现大规模生产级 AI 部署，需解决的是【整个软件栈】的一致性性能和支持问题，而非仅优化单个组件。

unsetunset一、引言unsetunset

GPT、Llama、Mistral 等大语言模型的迅速崛起，催生了对高性能 GPU 硬件前所未有的需求——这不仅是为了训练参数规模达数十亿至数千亿、耗时数周至数月的模型，更是为了大规模高效部署这些模型的推理服务。

大语言模型推理流水线的性能，关键取决于硬件的多个维度：计算吞吐量（每秒浮点运算次数 FLOPs，衡量计算性能的核心指标）、内存带宽与容量，以及互连性能（GPU 之间数据传输的延迟和带宽）。同样重要的是，还需要一个成熟的软件生态系统，以充分发挥这些硬件能力。

长期以来，NVIDIA GPU 一直是生产级 AI 工作负载的行业标准，这得益于其稳健且高度集成的 CUDA 软件生态。但如今，替代硬件方案的发展势头日益强劲，其中以 AMD 的产品最为突出。

在本白皮书中，我们针对大语言模型推理场景，对 NVIDIA 和 AMD GPU 展开横向对比评估，重点关注硬件性能的三个核心维度：

我们的评估采用厂商支持的基准测试工具，包括 vLLM（一种高性能大语言模型推理框架）和 TensorRT-LLM（NVIDIA 推出的针对大语言模型推理优化的框架）等框架，以评估实际推理性能和系统效率。

unsetunset二、计算性能基准测试unsetunset

NVIDIA GPU 上的张量核心（Tensor Cores）和 AMD GPU 上的矩阵核心（Matrix Cores），均为专用硬件加速器，旨在实现高吞吐量的矩阵乘法——而矩阵乘法是大语言模型（LLMs）背后最核心的计算操作。

评估这些单元原始计算能力的关键指标，是其可持续提供的每秒浮点运算次数（FLOPs），尤其是在 FP8、BF16（脑浮点数，16 位浮点数的一种变体，专为 AI 场景优化）、FP16 等低精度格式的推理任务中。

AMD 架构

AMD 早期的 GPU 架构为通用图形处理器，采用统一架构，既能满足 PC 游戏玩家的需求，也可用于数据中心平台。目前，AMD 拥有两大架构体系：

• 一是 AMD RDNA 架构，专为游戏优化，核心目标是最大化每秒帧数；
• 二是 AMD CDNA 架构，专为计算优化，致力于突破每秒浮点运算次数的极限。

CDNA-I 架构的计算单元以 GCN 架构为基础，通过增强改进，在每个计算单元（CU，GPU 中的基本计算模块，包含多个流处理器）中加入矩阵核心引擎（Matrix Core Engines），以提升 FP64 和 FP32 的计算吞吐量。

CDNA-2 架构实现了从单片架构（整个 GPU 集成在单一芯片上的架构）到芯粒架构（将 GPU 拆解为多个独立芯粒，再通过互连技术集成的架构，利于提升性能和良率）的巨大飞跃：在 MI250 和 MI250X 产品中，两个图形计算芯粒（GCDs，芯粒架构中的核心计算芯片）被集成到单个 OAM 封装形态（一种用于数据中心 GPU 的标准化封装规格）的封装中，并通过 AMD 独特的片上无限结构（Infinity Fabric，AMD 自主研发的高速互连技术，用于芯片内部或芯片间的数据传输）实现连接。

CDNA-3 架构在此基础上进一步升级，其 MI300 系列产品最多可集成 8 个垂直堆叠的加速计算芯粒（XCD，CDNA-3 架构中的计算芯粒）。其中，MI300X 配备 8 个 XCD 芯粒，计算能力较上一代产品近乎翻倍；而 MI300A 异构计算单元（APU，Accelerated Processing Unit）则在单个封装中集成了 3 个 Zen 4 架构的 x86 CPU 芯粒和 6 个 XCD 芯粒。

2.1 基准测试方法

为评估矩阵乘法性能，我们针对每个平台，均采用其优化程度最高且维护活跃的线性代数库进行测试。对于 AMD GPU，我们使用 ROCm 软件栈（AMD 推出的针对 GPU 计算的开源软件平台，类似 NVIDIA 的 CUDA），该软件栈包含 rocBLAS（AMD 基于 ROCm 的 BLAS 库）、hipBLAS（AMD 提供的与 CUDA 的 cuBLAS 兼容的 BLAS 库）和 hipBLASLt（hipBLAS 的轻量级版本，支持低精度等新特性）等多个 BLAS 库。

其中，我们选择 hipblaslt-bench 作为 MI300X 平台的主要基准测试工具，原因在于其开发活跃，且支持 FP8 等新型数据类型（目前其他 AMD 库暂不支持这些类型）。

对于 NVIDIA GPU，我们使用 CUDA 工具包中的 cuBLASLt 库——该库为通用矩阵乘法提供高度优化的内核。为测试 H100（Hopper 架构，NVIDIA 上一代数据中心 GPU）和 B200（Blackwell 架构，NVIDIA 新一代数据中心 GPU）的性能，我们借助微软 Superbench 基准测试套件（微软推出的用于 AI 基础设施性能验证和分析的工具）中的 cublaslt_gemm 微基准测试。

在两种平台的测试中，我们均通过固定矩阵维度使 M=N=K，以测试方阵乘法性能。测试规模范围为 64 至 65536（指矩阵的行数/列数），覆盖从小型到超大型的各类 GEMM 操作。为保证跨平台一致性，我们主要采用 NT 内存布局（指矩阵 A 采用行优先存储，矩阵 B 采用列优先存储，可优化内存访问效率）——即输入矩阵 A 按行优先（按行顺序存储矩阵元素）、输入矩阵 B 按列优先（按列顺序存储矩阵元素）。

2.2 结果

从图 1 可知，在 FP8、BF16 和 FP16 三种精度格式下，AMD MI300X 的平均实际浮点运算性能仅能达到其理论峰值的 45%（该数据已与 AMD 发布的博客交叉验证）。相比之下，NVIDIA 的 H100 和 B200 GPU 可持续达到其峰值计算吞吐量的 93%，表明其可用硬件性能的利用率显著更高。

NVIDIA 的 H100 和 B200 两款 GPU 均表现出优异的扩展性：

• 在中等矩阵规模（约 4096 及以上）下，其浮点运算性能可达到理论峰值的 90%以上。而 MI300X 则表现欠佳，在矩阵规模为 4096 及以上时，利用率峰值仅能达到 50%。
• 我们还注意到，当矩阵规模进一步增大时，性能会出现轻微下降。此现象可归因于这些大型矩阵对应的计算内核受内存限制（指计算速度受限于内存数据传输速度，而非计算单元本身的能力）。
• 此外，大型计算任务的规模通常会超出共享内存和缓存的有效容量，从而导致需要更频繁地访问速度更慢的全局内存。

2.3 软件效率

AMD MI300X 的理论浮点运算次数与实际观测值之间存在巨大差距，这主要归因于两个因素：

1. 软件栈效率，包括编译器和内核成熟度；
2. 动态频率调节与功耗管理行为——这两项机制可能会在负载下限制 GPU 的时钟频率。

每个 GPU 的理论峰值浮点运算次数通过以下公式估算：

• Max Boost Clock Frequency 为最大加速时钟频率，即 GPU 可达到的最高运行频率；
• Number of Cores 为核心数量；
• OPS/Core·Cycle 为每核心每周期操作数，即每个计算核心每时钟周期可执行的操作数量。

为更好地分离软件开销和频率调节的影响，我们设计了矩阵规模与计算单元数量高度匹配的微基准测试实验。我们同时记录了持续时钟频率（GPU 在负载下能稳定维持的时钟频率，区别于瞬时峰值频率）和观测到的吞吐量，从而能够更精确地量化每个限制因素的影响程度。该验证实验的结果如下所示。

unsetunset三、内存性能基准测试unsetunset

现代深度学习工作负载如大规模 Transformer 架构，对内存带宽的依赖性极高。随着模型规模和序列长度的持续增长，如何高效地将数据传输至计算单元已成为主要性能瓶颈。

高带宽内存（High Bandwidth Memory, HBM）是一种先进的 DRAM 技术，专为实现极高的内存带宽而设计，其带宽可达到每秒数太字节（TB/s）级别。

可安装的 HBM 堆叠数量受计算裸片周围基板面积的物理限制。例如，AMD 的 MI300X 支持 8 个 HBM 堆叠，而 NVIDIA 的 H100 则包含 6 个堆叠（其中 1 个可能预留用于冗余备份或良率保障）。每个堆叠的总内存容量取决于两个关键因素：

1. 堆叠高度，即垂直堆叠中的内存层（裸片）数量；
2. 每一层的 DRAM 密度。

与此同时，内存带宽主要由以下两个因素决定：

1. 接口中的数据引脚数量；
2. 每引脚的信号传输速率。

HBM 技术的代际演进始终以容量和带宽扩展为核心驱动力，具体通过多种创新实现，例如：

这些技术进步使得 MI300X 和 H100 等现代加速器能够实现前所未有的内存性能。下表总结了近期 AMD 和 NVIDIA 架构产品的 HBM 版本、堆叠数量及内存规格。

3.1 基准测试方法

为评估峰值内存带宽性能，我们针对不同 GPU 厂商采用了两种定制化方法。

对于 AMD GPU，我们使用了 BabelStream——一款基于 CPU 的 STREAM 基准测试开发的合成基准测试工具，专门用于测量高带宽内存（HBM）与计算单元之间的内存传输速率，并支持多种后端，如 HIP、OpenMP 和 Kokkos（多后端并行编程模型——由美国能源部支持开发，可在 CPU、GPU 等不同硬件上实现高性能并行计算，屏蔽硬件差异）。

在本研究中，我们针对 HIP 后端进行编译，以对 AMD MI300X GPU 进行基准测试。

BabelStream 基于三个大型数组（a、b、c）和一个可选标量（alpha）运行。每个核函数处理 N 个元素，带宽根据读写的总字节数（β = 每个数据元素的字节数）计算，具体如下表所示：

对于 NVIDIA GPU，我们开发了一个定制化 CUDA 核函数，该核函数模拟 BabelStream 的内存访问模式，并聚焦于“复制”（Copy）核函数操作。这种设计既能确保基准测试方法的一致性，又能适配 CUDA 编程环境并利用 NVIDIA 专属的优化手段。

3.2 核函数实现

针对 MI300X，我们编译并执行了基于 HIP 的 BabelStream 实现。在此配置中，每个线程负责处理一个数据元素。核函数以固定的 1024 线程块大小启动，线程块总数设置为 N/1024（其中 N 为数组中的总元素数）。该配置旨在充分利用 GPU 的计算资源，同时最大化大规模数组操作的持续内存吞吐量。

为确保与 AMD 配置的公平对比，我们在 CUDA 中实现了一个定制化“复制”核函数，用于 NVIDIA GPU 的内存带宽基准测试。在该核函数中，每个线程从数组 A 读取一个元素并写入数组 B。我们评估了多种线程块大小（256、320、512 和 1024）以确定最优性能，最终选择了 320 线程/块的配置——这与 NCCL 的集合通信核函数常用内部配置一致。线程网格大小（grid size）根据数据集的覆盖需求动态确定，线程块数量则基于待处理元素的总数计算得出。

3.3 测试结果

上图对比了五种常用于 LLM 推理工作负载的 GPU 的理论峰值内存带宽与实测峰值内存带宽，分别是 AMD MI300X 以及 NVIDIA A100、H100、H200 和 B200。

图 4 展示了 AMD MI300X 与 NVIDIA A100、H100、H200、B200 在不同数组大小下的实测内存带宽扩展情况。结果显示：

• NVIDIA B200 在所有架构中表现最佳，峰值带宽约为 6.6 TB/s，且在数组大小超过 512 MiB 时仍能保持稳定扩展。
• MI300X 表现出竞争性性能，饱和带宽约为 4.3 TB/s，但带宽达到饱和的时间更早（数组大小约为 64–128 MiB）。
• H200 的性能略优于 H100，这表明 HBM 内存技术在架构上有增量改进。相比之下，A100 的带宽更早达到饱和（约 1.7 TB/s），反映出其较旧的 HBM2 堆叠技术存在局限性。

总体而言，这些结果凸显了内存带宽扩展在大型模型推理工作负载中的重要性，并展示了新一代 GPU 架构在处理 LLM 推理中典型的大型激活张量与权重张量时的效率优势。

unsetunset四、通信性能基准测试unsetunset

截至目前，我们仅单独分析了单个 GPU 的计算和内存特性。然而，随着现代大型语言模型（LLM）规模的持续增长，其对内存的需求日益超出单个 GPU 的容量——这主要受限于可用 HBM 内存的规模。

如第 3 节所述，HBM 容量和带宽的扩展能力既受物理内存密度的限制，也受高带宽内存接口技术复杂度的制约。因此，要高效运行这类模型，必须将工作负载分布到多个 GPU 上，这使得 GPU 间通信的效率变得至关重要。

GPU 间的互连方式成为影响整体系统性能的关键因素，尤其对于张量并行或流水线并行的推理和训练工作负载而言。

NVLINK

NVIDIA 的 NVLink 是一种高速低延迟互连技术，专为支持 GPU 架构的横向扩展而设计，可实现 GPU 间以及 GPU 与 CPU 间的高速数据传输。

在 Grace Blackwell（GB200）等新一代架构中，NVLink 是 NVIDIA 统一内存与计算架构的核心组成部分。每一代 NVLink 在带宽和互连效率上都有显著提升，最新的第五代 NVLink 为全归约（all-reduce——分布式计算中的一种集合通信操作，所有 GPU 将本地数据汇总并计算出一个全局结果，再将结果广播给所有 GPU，是深度学习梯度同步的核心操作）等集合通信操作提供了高达 1800 GB/s 的每 GPU 双向带宽。

本研究中，我们评估的是 NVLink 4.0——该版本用于基于 Hopper（H100）架构的系统。

Infinity Fabric

在 AMD 方面，Infinity Fabric 是其专有的互连技术，既用于单个 MI300X 设备内部连接多个计算裸片（GCDs，GPU 中的核心计算单元，包含多个计算单元和内存控制器，如 AMD 的 GCD/XCD 芯片）的 GPU 内部通信，也用于节点内多个设备间的 GPU 间通信、。

最新一代 Infinity Fabric 支持每链路高达 128 GB/s 的双向带宽，能够实现一致性内存访问（多个处理器或计算单元可访问同一块内存区域，且能看到最新的数据更新，保证数据一致性），并支持分布式芯粒架构（将 GPU 拆解为多个独立的芯粒/芯片，通过互连技术组合成完整的 GPU，可提升芯片制造良率和性能扩展性）下的同步计算。

4.1 基准测试方法

NVIDIA 集合通信库（NCCL，NVIDIA Collective Communications Library）是 NVIDIA 开发的高性能库，用于实现 GPU 间优化的集合通信（如全归约、广播——集合通信操作的一种，将一个 GPU 上的数据发送到其他所有 GPU 上、全收集——集合通信操作的一种，每个 GPU 将本地数据发送给其他所有 GPU，最终每个 GPU 都拥有所有 GPU 的本地数据）。

该库具备拓扑感知能力（能够识别 GPU 间的物理连接拓扑结构，如通过 NVLink 还是 PCIe 连接，从而选择最优的通信路径），即能根据系统的 NVLink、NVSwitch 或 PCIe 布局调整算法，以最大化带宽并最小化延迟。

AMD 的对应方案是 ROCm 集合通信库（RCCL，ROCm Collective Communication Library），用于多 GPU 通信。它基于 NCCL 的分支开发（从 NCCL 的源代码仓库复制代码，在此基础上修改适配 AMD 硬件），保留了类似的 API 和设计原则，但针对 AMD 硬件进行了定制，包括支持基于 Infinity Fabric 的互连技术和 ROCm 软件栈。

对于 AMD GPU 的基准测试，我们采用了 RCCL-tests——该套件基于 NCCL-tests 的代码库和性能评估方法开发，是 RCCL 对应的测试工具。这确保了通信指标收集方式的一致性，从而能够直接对比 NVIDIA 和 AMD GPU 互连的性能。

4.2 测试结果

前面图 5 展示了在 2 个、4 个和 8 个 GPU 配置下，集合通信操作（具体为全归约）的实测 GPU 间峰值带宽。该评估对比了两种 GPU：通过 NVLink 4.0（NV18）连接、双向带宽为 900 GB/s 的 NVIDIA H100，以及通过每链路双向带宽为 128 GB/s 的 Infinity Fabric 连接的 AMD MI300X。

• 在 8 个 GPU 的 NVIDIA DGX H100 系统（NVIDIA 推出的基于 H100 GPU 的一体化 AI 服务器，通常包含 8 个 H100 GPU，配备 NVSwitch 实现高速互连）中，GPU 通过图 5 所示的 NVSwitch 拓扑连接，无论涉及多少个 GPU，都能实现均匀且稳定的带宽。
• 相比之下，8 个 GPU 的 AMD MI300X 平台采用基于网状结构的 Infinity Fabric 拓扑（多个 GPU 按网状方式连接，每个 GPU 与相邻的几个 GPU 直接通信，整体形成网状结构，通信带宽随 GPU 数量和连接链路数量增加而扩展），其聚合带宽（多个通信链路的总带宽，如 8 个 GPU 间所有活跃通信链路的带宽总和）随活跃 GPU 对和通信链路数量的增加而扩展。

实测结果显示，NVIDIA GPU 的实测带宽达到其理论峰值的约 85%，这反映出 NCCL 中集合通信栈的成熟度和高度优化。对于 AMD，带宽从 2 个 GPU 时的 64 GB/s 扩展到 4 个 GPU 时的 192 GB/s，再到 8 个 GPU 时的 448 GB/s，实测带宽达到其理论峰值的约 70%。仍有改进空间，尤其是在优化 RCCL 以更好地利用 AMD 的网状互连布局方面。

从 LLM 推理的角度来看，这些互连特性对张量并行（TP）通信有直接影响，尤其是当模型分区跨多个 GPU 时。若能增强 AMD 的集合通信算法，使其达到 NCCL 中拓扑感知策略的水平，将显著降低通信开销，并提升大规模推理部署的可扩展性。

unsetunset五、LLM 性能unsetunset

尽管微基准测试对于分离和比较影响大型语言模型（LLM）推理的核心硬件组件（如计算、内存和通信带宽）具有重要价值，但它们无法捕捉端到端执行的全部复杂性。

为解决这一问题，我们使用 Llama 3.1 70B 作为代表性模型，开展了全面的端到端推理实验。这些测试在 NVIDIA H100、H200 GPU 以及 AMD MI300X 上进行，并分别采用了为各平台优化的、快速迭代的软件栈。

为评估真实场景下的性能，我们测试了广泛的输入和输出序列长度，涵盖了短文本生成和长文本生成两种典型用例。

这些实验反映了硬件能力与软件栈成熟度对实际推理吞吐量（inference throughput，指单位时间内模型生成的 token 数量，是衡量 LLM 推理效率的核心指标）的综合影响。

5.1 FP8 精度测试结果

图 7（NeuralTalk 注：原文标错为 Figure 6，此处以实际对应图号为准）展示了 Llama 3.1 70B 模型在 FP8 精度下，三款 GPU（NVIDIA H100、NVIDIA H200、AMD MI300X）的推理吞吐量。

先介绍一下 LLM 推理包含两个主要阶段：

推理吞吐量的计算方式如下：

公式说明：吞吐量=输出 token 数量 ÷（预填充时间+解码时间）

预填充主导场景（Prefill-Dominated Regime，输入长度增加，输出长度固定为 32）：

当输入长度从 32 增加到 256、输出长度固定为较短的 32 时，所有 GPU 的吞吐量均下降。这一趋势源于预填充成本（prefill cost，指预填充阶段消耗的计算资源和时间）的增加，而预填充成本的增加会使吞吐量公式中的分母（预填充时间+解码时间）变大。

在此场景下，AMD MI300X 的吞吐量始终仅为 NVIDIA H100 和 H200 的 50%左右，这与本文“计算性能”章节中关于 MI300X 矩阵乘法性能较低的讨论结论一致。

解码主导场景（Decode-Dominated Regime，输入长度固定为 512，输出长度增加）：

当输入长度固定为 512、输出长度从 1 增加到 2048 时，所有 GPU 的吞吐量均稳步上升。这一现象符合预期，因为公式中的分子（输出 token 数量）的增长速度快于解码时间（分母中的解码时间部分）的增长速度。

在此场景下，内存带宽成为主导因素，AMD MI300X 的性能差距有所缩小：其吞吐量相对于 NVIDIA H100 的比例从（输出长度为 1 时的）49%提升至（输出长度为 2048 时的）66%。这一结果与本文“内存性能”章节中关于 MI300X 具备竞争性内存带宽性能的讨论结论一致。

5.2 FP16 精度测试结果

下面图 8 展示了 FP16 精度下的推理吞吐量（单位：token/秒），其趋势与 FP8 精度测试结果相似。

值得注意的是，在解码主导场景下，AMD MI300X 的相对性能有所提升：其吞吐量相对于 NVIDIA H100 的比例从约 56%提升至 80%，这一提升幅度超过了 FP8 精度下的对应结果。

这一现象可通过图 6（内存带宽相关图表）所示的内存带宽特性来解释：具体而言，对于较小的工作集大小（working set sizes，指程序在特定时间内需要访问的数据量）——NVIDIA H100 为 1-64 MB，NVIDIA H200 最高为 128 MB——AMD MI300X 的有效带宽（指实际应用中能达到的内存数据传输速度，区别于理论峰值带宽）低于 NVIDIA GPU。

这些内存大小对应于典型的 FP8 推理工作负载，因为此类工作负载中模型权重和键值缓存的内存占用正处于这一低带宽区间。由于推理的解码阶段是内存密集型的，较低的带宽会直接影响 MI300X 在 FP8 场景下的性能。

相反，FP16 推理的模型权重和键值缓存内存占用是 FP8 的两倍，这使得工作负载的内存需求进入带宽曲线的更高区间（更高带宽区间指内存工作集大小达到一定阈值后，内存带宽能稳定在较高水平的区间）。在该区间内，AMD MI300X 的内存吞吐量（memory throughput）与 NVIDIA H100、H200 相当甚至更优。这种工作集区间的转移导致了解码阶段性能差距的缩小，也凸显了内存系统特性对不同精度格式下推理性能的影响。

unsetunset六、总结unsetunset

尽管 AMD 在其 GPU 产品的硬件规格（核心数量、内存容量、带宽等硬件参数）提升方面取得了显著进展，但要充分发挥这些硬件能力的潜力，仍需依赖成熟且稳健的软件生态（驱动程序、框架、库等软件整体）。

尽管 AMD GPU 已在研究环境中展现出应用价值（例如部署于橡树岭国家实验室的 Frontier 百亿亿次超级计算机），但要在生产级 LLM 工作负载中实现广泛采用，仍需确保整个软件栈具备稳定的性能和完善的支持。

关键改进领域包括加速集合通信库和互连技术的开发。NVIDIA 的 NCCL 库正在集成对 NVSHMEM（一种用于 GPU 间高效共享内存的技术）的支持，而 AMD 的软件生态则需加入类似的高性能通信原语，以提升多 GPU 推理的扩展性和效率。填补这些软件领域的差距，对于 AMD 成为大规模、生产级 AI 工作负载的竞争性平台至关重要。

unsetunset参考文献unsetunset

1. AMD Inference Benchmark: https://rocm.docs.amd.com/en/latest/how-to/rocm-for-ai/inference/vllm- benchmark.html
2. Babel Stream: https://www.amd.com/en/developer/resources/infinity-hub/babelstream.html
3. Microsoft SuperBenchmark: https://github.com/microsoft/superbenchmark
4. AMD MAF Part 1 Blog: https://rocm.blogs.amd.com/software-tools- optimization/Understanding_Peak_and_Max-Achievable_FLOPS/README.html
5. AMD MAF Part 2 Blog: https://rocm.blogs.amd.com/software-tools-optimization/measuring-max- achievable-flops-part2/README.html
6. Blackwell Datasheet: https://resources.nvidia.com/en-us-blackwell-architecture/datasheet
7. DGX B200: https://www.nvidia.com/en-us/data-center/dgx-b200/
8. H200 Datasheet: https://nvdam.widen.net/s/nb5zzzsjdf/hpc-datasheet-sc23-h200-datasheet-3002446
9. A100 Datasheet: https://www.nvidia.com/content/dam/en-zz/Solutions/Data-Center/a100/pdf/nvidia-a100- datasheet-us-nvidia-1758950-r4-web.pdf
10. AMD CDNA 1: https://www.techpowerup.com/gpu-specs/docs/amd-cdna-architecture.pdf
11. MI300x Datasheet: https://www.amd.com/content/dam/amd/en/documents/instinct-tech-docs/data- sheets/amd-instinct-mi300x-data-sheet.pdf
12. RCCL tests: https://github.com/NVIDIA/nccl-tests
13. NCCL tests: https://github.com/NVIDIA/nccl-tests
14. HipBLASLt: https://github.com/ROCm/hipBLASLt