综述 · RDNA3 · ROCm · vLLM

ROCm 内核的八个结论在 RDNA3 上收窄至三个，
而实测另一厂商排除了两个

RDNA3 上的八个结论按五条硬件轴分类；对照另一厂商、内核源码与宿主机拓扑逐一核验

本仓库自身的总结将 RDNA3 称为 ROCm 内核生态里的二等公民，并将八篇文章归于该标题下。但若按证据实际支持的范围归类，八个结论中只有三个确实如此。其余结论要么覆盖 AMD 全线，要么与厂商无关，要么完全不关 GPU 的事。分清各自的归属，正是技术诊断与宣泄情绪的分水岭。

2× RX 7900 XT · gfx1100 8 个结论 · 16 条上游 issue 与 PR 状态核查于 2026-08-29

摘要

这一论断确有其事，但涵盖的范围比表面看来要窄。真正属于架构特定的问题只有一份简短清单：这套硬件无法走通的注意力快路径，用类型闸门将常见 checkpoint 类别拒之门外的原生量化线性内核，以及某函数中只写进单一架构分支、却在另一架构中缺失的性能启发式规则。

最纯粹的实例仅有一行代码。对于同一个内核，use_rocm_custom_paged_attention 在 gfx11 上要求 gqa_ratio >= 3，在 CDNA 上则要求 >= 1。在被排除的区间里，该内核比绕过它而换用的兜底实现快 1.84 到 7.28 倍， 且两个区间彼此重叠。这道界限没有任何区分意义。

八个结论中有四个不是 RDNA3 的问题，实测的目的也正是为了厘清这一点。其中两个结论在不同证据下均表明与厂商无关：同一道注意力闸门在 A100 上实测显示，其在 50K 上下文时性能下降 61 %；此外，单线程编译设置经溯源位于一个所有平台均会执行的文件中。第三个问题覆盖 AMD 全线，根源在于 AMD 明确指出的某行内核代码。最后一个问题则是 PCIe 能力位限制，在裸机环境下同样会遇到。

十六条上游 issue 与 PR 中有一半属于其他开发者。 这套硬件发挥的最大作用，无非是充当了上游开发者手头缺少的那台测试机。

1按实际成因对八个结论归类

下表每一行均对应一篇独立文章，其旁标注的每个数字都直接基于底层数据文件由仓库重算。这里的分类归属是唯一带有主观判断的部分，因此每行都列出了将其归入对应硬件轴的事实证据。

图 1 · 每个结论究竟是什么的实例 可由仓库重算
图 1. 按轴排序，不按大小。这些倍数彼此之间不可比 —— 它们是不同东西的比值，各自只在自己那篇文章的基线上才有意义 —— 放在这里是为了说明哪些结论值得花一个下午，而不是给它们排名。 被标为架构特定的那三个，是同一套软件在这台硬件上做出与另一款 AMD 部件不同决定的那三个。

2最纯粹的实例只有一行

如果"二等公民"具有确切的定义，那便是同一套软件在面对不同架构时做出区别对待，而背后的依据却经不起实测核验。vllm/platforms/rocm.py 中的一个函数就正是如此：

图 2 · 同一个 kernel，两个分支，差一个条件 可由仓库重算
图 2. 这个界限是一条性能启发式 —— 加入它的那个 PR 自己这么说 —— 而在这台硬件上实测下来它是反的：被排除的那个区间正是被挡住的 kernel 帮助最大的地方。 下面是这个仓库的架构笔记列出的四个生态缺口，从那份文档里提取。 它们是同一件事的结构性版本：快路径存在，而支持硬件清单里没有这一款。

上述四个缺口中有两个需要明确区分。AITER 与 FP8 在设计上就仅面向 Instinct，这体现的是刻意的产品边界而非软件缺陷。缺失的 MoE 调优配置在任何 AMD GPU 上均不存在，因此属于 AMD 全线的缺口而非 RDNA3 特有的局限。唯有 Composable Kernel 在 RDNA3 上仅支持前向融合注意力这一条，与上文的闸门并列，确凿无疑地落在架构特定这条轴上。

3不属于此类的另外四个

分量最重的那些实测，恰恰是将结论从这份清单中排除出去的测试。

两个结论经由实测另一厂商而确立 长上下文下投机解码性能塌陷，最初看似是 RDNA3 的问题。然而在租用的 A100 上测试同一模型时，走同一个 Triton 内核在 50K 下同样出现 61 % 的性能跌幅，且在没有该防护检查的后端上恢复了正常。同样，128 专家 MoE 跑出 15 tok/s 的极低吞吐，起初令人怀疑是 ROCm 缺少调优内核所致。实际原因却是 env_override.py 中一行在所有平台上均会执行的赋值语句。参见投机解码报告与另一篇 MoE 报告。
一个属于 AMD 全线，根源在 AMD 指明的一行代码中 权重加载速度甚至低于磁盘读取，根源在于 kfd_svm.c 直接从 VMA 读取访问模式。只读拷贝请求了写权限，从而破坏了所有常驻内存页上的 copy-on-write 机制。该内核文件并不针对特定架构。AMD 确认了这一机理，第三方开发者也在另一款显卡上复现了该故障。详见完整分析文章。
一个完全与 GPU 无关 所有 RCCL 集合通信在 dispatch 阶段崩溃，是因为卡上方的 PCIe 根端口缺少 AtomicOps 能力。该故障在裸机环境下同样能够复现，与系统中安装了哪款 GPU 毫无关联。对于虚拟机环境，修复只需一行宿主机配置。参见关于 RCCL 的分析文章。

第五个案例值得单独列出，因为它反映的是宿主机拓扑而非芯片本身。2D 注意力路径为每个 KV head 启动一个 workgroup；将模型拆分到两张卡上会使可用的 KV head 减半，导致计算饥饿程度加倍。这种性能惩罚属于张量并行的固有代价。此处作为实测单卡对照的 A100 运行着完全相同的内核，因此无需承担这笔开销。参见双卡对比分析。

4这套硬件最终证明的真正用途

这项工作共衍生出十六条上游讨论。其中的分布很能说明问题：八条来自本仓库，另外八条则属于外部贡献者；在这后者之中，本测试平台提供的是对方无法自行采集的实测数据。

图 3 · 每一条 issue 与 PR，以及它在 2026-09-09 的状态 可用 gh api 自行核对
图 3. 状态是在标注日期从 API 读的，不是凭记忆写的 —— 这些会变， 而一个永远写着"开着"的页面几周内就错了。有两条已合并。一条由它自己的作者合的， 关掉的是本仓库花了一个月、经由另一个 kernel 刻画的那个问题里更大的一半；另一条是 V-cache padding 修复，2026-09-08 合并，线程里有本仓库补交的 gfx11 证据。 另外两条明确把 gfx11 列为缺口：它们的作者在 Instinct 上验证过，并在测试计划里写明了。

这便是消费级显卡对此软件生态真实价值的客观总结。本测试的目的从来不是追求极致跑分：在没有 P2P、依靠跨 die PCIe 3.0 链路的 VFIO 客户机上运行，测出的绝对吞吐仅仅是下限。它们真正的价值在于填补实测空缺：为缺乏对应硬件的开发者提供实体机器，让那些仅在编译层面做过验证的测试计划得以经受实际运行的检验。

5没有被确立的部分

这个分类是一个判断

尽管各项倍数均可重算且每条依据均给出了事实支持，将结论归入特定硬件轴依然属于逻辑推论而非直接实测。八个结论中有两个可合情合理地归入其他类别：W4A16 类型闸门本质上是恰好位于特定架构内核中的常规缺陷；而缺失的 MoE 调优配置虽放在 RDNA3 评测中讨论，本质上却涵盖 AMD 全线。

一台机器，一代软件

所有实测均基于 VFIO 客户机上的 gfx1100，跨越两代 vLLM 与两个 ROCm 版本。这些结论是否适用于 RDNA4 并未做过实测；仓库架构笔记虽预期该生态缺口会延伸至该架构，但该断言仅来自对支持硬件文档的核对，而非基准测试。

这些缺口是否在收窄

测试期间有一项上游 PR 合并并解决了半个问题；第二项（V-cache padding 修复）在本页首次读取之后于 2026-09-08 合并。这指明了改进方向，却不足以构成整体趋势。本文仅记录了测试当时 gfx11 支持的实际现状，并未衡量上游开发的推进速度。

6此后发生的变化

2026-07-14 · 三个结论中有一个范围自行收窄 上游 PR vllm#40977 现已合并，新增的第二个原生内核支持了此前被拒的 checkpoint 类型。该结论的核心事实依然成立：十二个非对称配置中仍有八个在 gfx1100 上缺乏内核支持。但原先最具代表性的案例已不复存在，先前解码速率仅 11.41 tok/s 的模型在当前 main 分支上已提升至 37.32。
2026-08-20 · 一处修复出自发行版日常维护，而非针对报告的响应 Canonical 在 7.0.0-30 中发布了缺失的内核 commit。专门请求该 backport 的 Launchpad bug 至今仍未经分诊，说明该改动只是随常规 stable 维护流程进入系统。提交问题报告与问题得到修复是两码事，本仓库对这两类情况各记录了一例。
状态信息具有时效性 图 3 仅代表特定时间点的快照。除了两处合并，表中所有项目在 2026-09-09 时均处于开启状态。阅读本文时应当直接点击链接查看实时进展，而非单纯依赖表格中的状态列。
2026-08-29 · 中文轴标签曾暗示排他性 图 1 中架构轴的原中文标签写作 RDNA3 特有，"架构特有"一词亦在文内另外四处出现。"特有"表达的是"独占"，而英文原文表述为 specifically。本文的完整论点在于这些结论比通常断言的范围更窄，而非为该芯片所独有。目前相关表述均已修订为"特定"。此外，页头日期 chip 原写作"状态核对于"并不通顺，现已统一修正为"状态核查于"。
2026-08-29 · 一场 campaign 落入其中两个类别，另有一例起初被放在类别之间 在两张 Radeon 和一台租用的 A100 上测试二十个配置，每个类别各得出一个结论，将上述分类体系落到了实处。与厂商无关：vllm#45450 仅在其修补的 Triton 内核实际处于执行路径上时方能生效。由于 Qwen3.8-27B 在两家平台上均绕开了该内核（本平台选走 ROCM_ATTN，CUDA 上则走 FLASH_ATTN），导致该补丁在两边虽已合入却均处于闲置状态。AMD 全线：由于 TURBOQUANT 无法与解码器兼容，ROCm 的选择器转向 ROCM_ATTN。在 32K 上下文下，这一抉择拱手让出了 15.0 % 的性能，而其所列出的候选列表中包含的 TRITON_ATTN 本可保全这部分性能。另有一例起初被放在类别之间，结果同样与厂商无关：gemma-4 在 0.27 ROCm 镜像上无法启动。vLLM 0.27 的 Gemma4 converter 经由预期捕获 AttributeError 的 getattr 回退读取全局 head_dim，而 transformers 5.x 的按层访问器抛出的是自己的异常；回溯中的 AMD Quark 帧只是原样转发调用。上游 vLLM 已在 vllm#49797 修正这次读取，0.28.0 含而 0.27.1 不含，同一 checkpoint 在 CUDA 上的 0.28.0 可以服务。这是 ROCm 镜像所搭配的版本组合问题，不是任一厂商代码单独的过失；新镜像能否服务尚未实测。

八篇专题文章。 混合 SSM 的性能塌陷 · 单一模型中的两个问题 · GQA 闸门 · 权重加载瓶颈 · MoE 与 eager 模式 · 投机解码收益翻转 · 双卡 Radeon 对比单卡 A100 · RCCL 崩溃机理。测试方法论详见 解码速率测量专文， 非复现实验的报告规范见否定结论报告一文。

完整生态调研见 docs/architecture-notes.md。 本页所有图表均由 verify_doc_figures.py 基于仓库数据直接重算。