AMD 2.0：新的紧迫感

自semianalysis在 2024 年 12 月发表一篇详细分析 AMD 软件平庸且缺乏可用性的文章后，AMD 加快了他们的步伐，并在过去4个月针对文章所指的问题取得了快速进展。本文认为，AMD 新的紧迫感是其追赶英伟达过程中的一大积极因素。AMD 现在处于战时状态，并且前方有许多战斗等着他们。

本文将讨论 AMD 所做的许多积极改变。他们正走在正确的轨道上，不过，他们应该增加 GPU 计算时长的研发预算，并在 AI 人才方面进行更多投资。本文还将提供额外建议，并阐述 AMD 管理层的漏洞：AMD薪酬结构以错误的公司为基准，因此在争夺 AI 软件工程师的竞争中缺乏竞争力。

本文还将讨论 AMD 的产品发布节奏：AMD旧一代产品与英伟达的新一代产品同阶段发布。

执行摘要

1. 本文团队与 Lisa Su 进行了会面，并介绍了团队的发现，她认识到了 ROCM 软件栈中的许多差距，并表达了强烈的改进愿望。

2. 在过去四个月中，AMD 在其 AI 软件栈方面取得了快速进展。

3. 2025 年 1 月，AMD 推出了开发者关系（devrel）职能，主要由 AMD 的 AI 软件负责人 Anush Elangovan 领导。他的重点是在 Tech Twitter 和线下活动中与外部开发者互动。

4. 通月，AMD 认识到外部开发者社区是 CUDA 成功的关键，并从此采用了 “开发者优先” 战略。

5. 在本文团队于 12 月发表 AMD 文章之前，AMD 在 PyTorch 持续集成 / 持续交付（CI/CD）中没有 MI300X。此后，AMD 将 MI300 纳入 PyTorch CI/CD。过去四个月，AMD 在 CI/CD 方面取得了巨大进展。

6. AMD 计划借鉴谷歌的 TPU 研究云（TRC）模式，并在即将于 6 月举行的 Advancing AI 活动中推出开发者云。成功的衡量标准是是否在 AMD 的社区开发者云上出现 “GPT-J 时刻”。

7. AI 软件工程薪酬是 AMD 管理层的漏洞，因为他们的总薪酬明显低于英伟达和 AI 实验室等擅长 AI 软件的公司。

8. 过去四个月，AMD 的内部开发集群有了显著改善，但这些增强仍不足以在长期的 GPU 开发格局中有效竞争。

9. AMD 应大幅增加并优先分配其研发资本支出和运营支出计划的投资，为其团队提供更多的 GPU 资源用于软件开发。目前对季度收益的短视关注损害了其长期竞争力。AMD 需要投资更多的 GPU，他们的 GPU 总数不到英伟达的 1/20。

10. 使整个 Cuda 生态系统在 Python 上成为一流是 Jensen 的首要任务。英伟达现在在栈的每一层都有一个 Python 接口。ROCM 没有这个。这对 AMD 与开发者的长期可用性构成了严重威胁。

11. 尽管 RCCL 取得了一些不错的进展，但由于 GTC 2025 上宣布的 NCCL 新改进和功能，NCCL 和 RCCL 之间的差距继续显著扩大。

12. AMD 在过去四个月中在其软件基础设施层（即 Kubernetes、SDC 检测器、健康检查、SLURM、Docker、指标导出器）方面取得了一些进展，但其进展速度远不及 AMD 的 ML 库的进展速度。

13. AMD 目前缺乏许多推理功能的支持，如对分离预填充、智能路由和 NVMe KV 缓存分层的良好支持。英伟达开源了分布式推理框架 Dynamo，进一步普及了英伟达 GPU 的分离服务。

14. MI355X 仍然无法与英伟达的机架规模 GB200 NVL72 解决方案竞争。相反，AMD 将 MI355X 定位为与英伟达的风冷 HGX 解决方案竞争，但这并不是大多数客户进行的购买比较。

自12月文章发表以来，AMD的新情况

在semianalysis 发表了一篇AMD软件的文章后，Lisa Su 联系了该团队，并详细讨论每一项该团队的发现和建议。次日太平洋时间早上 7 点，该团队向 Lisa 展示了研究发现，并向她介绍了过去五个月中与 AMD 团队合作修复其软件以进行各种工作负载基准测试的经历。

期间，本文团队展示了过去提交给 AMD 工程联系人的数十份错误报告。在看过后，Lisa给感受到了用户在使用 ROCM 上的糟糕，认识到 ROCM 软件栈中的诸多不足。随即，Lisa便向她的团队表达了希望 AMD 做得更好的意愿。在接下来的一个半小时里，Lisa 向她的工程团队和本文团队询问了许多有关经验和关键建议的详细问题。

来源：X

认识到不足后的怒火的已经燃到了整个AMD。他们现在处于战时模式，努力解决软件问题，缩小差距。这与 2024 年 AMD 的公关部门拒不承认落后的情况相比，显然是一个巨大的改变。

2025 年至今，AMD 已经认识到他们的软件比英伟达有更多的错误，于是迅速改进，并正在与社区合作，以使 ROCM 达到与英伟达同等水平。特别是，AMD 的 AI 软件负责人 Anush Elangovan 一直在致力于解决 AMD 的问题。

来源：X

AMD 的文化转变 —— 新的紧迫感

伤心的最后阶段通常使接受。AMD 接受了其巨大的软件差距，好在现在还可以解决，还仍有机会在软件和硬件游戏中击败英伟达。

现在，AMD 已经重新振作起来，不过英伟达同样也在全速前进，所以，AMD 要赶上他们，只有他超过他们才能赶上。英伟达的员工清楚地知道，有时需要加班才能在竞争激烈的市场中保持领先地位。AMD 要想获胜，至少需要像英伟达一样努力和聪明，甚至更努力和聪明。

来源:X

xAI 与 OpenAI 的对比就是一个例子，说明文化的转变，采用紧迫感和战时姿态，可以导致公司以惊人的速度赶上竞争对手。

来源：xAI

显然，AMD正在上演这样的追赶剧情。理由是AMD 正在执行的一个领域是他们的产品路线图，以实现与英伟达在机架规模解决方案上的 parity。

另一个理由是 AMD 在过去四个月中在其 AI 软件栈方面的快速进展。他们在训练和推理性能以及开箱即用体验方面都有显著改善。他们甚至在训练基准测试中采用了 SemiAnalysis 的代码。

2025 年 1 月，AMD 推出了开发者关系（devrel）职能，因为它终于明白开发者是英伟达 CUDA 成功的关键，现在承认赢得开发者对 ROCM 的成功至关重要。目前，开发者关系团队由 Anush Elangovan 领导，他在现场活动以及 Tech Twitter 等社交媒体论坛上担任 AMD 的唯一 devrel。

6 月，AMD 将推出一个专注于与整个社区互动的开发者云。这是 SemiAnalysis 建议 AMD 缩小差距的直接结果。

来源：SemiAnalysis，AMD

AMD 现在在基准测试和性能声明的可重复性方面已经击败了英伟达。他们开始发布易于遵循的说明，允许用户和开发者复制他们的基准测试运行，而不是发布无法验证的不现实或有偏见的性能声明。一个很好的例子是 AMD 如何发布了一篇关于如何复制他们的 MLPerf Inference 5.0 提交的精彩博客。相比之下，英伟达在最新的 MLPerf 练习中没有提供这样的说明。

CUDA的优势

CUDA 最大的优势不仅在于其内部软件开发者，还在于其生态系统，包括在 CUDA 平台上构建的 400 万外部开发者、数千家企业以及众多 AI 实验室和初创企业。这创造了一个自我强化的工具、教程和现成内核的飞轮，降低了每个新来者的采用门槛，并让老手们快速前进。由于这个庞大的开发者基础，行业知识很快就会与新来者分享。

这个繁荣生态系统的结果便是突破性的想法，无论是新的注意力算法、状态空间模型还是高吞吐量服务引擎，这些几乎总是首先出现在 CUDA 上，最快地收到反馈，并在 CUDA 上进行更严格的调整，然后又吸引下一波开发者。

这种集体能量的回报是显著的：当研究人员发布一个改变游戏规则的内核时，CUDA 版本通常会在第一天发布。Tri Dao 的 FlashAttention 发布了参考 CUDA 代码，ROCM 花了多个季度才实现自己的优化注意力。选择性状态空间模型也是如此，作者只发布了 CUDA 实现，但作者自己没有支持或移植到 ROCM。ROCM mamba 的移植来自 AMD 内部工程师，而不是原作者。在服务方面，加州大学伯克利分校的 vLLM 和 SGLang 的维护者主要在英伟达 GPU 上开发，只有在 CUDA 路径稳定后，维护者才会帮助 AMD 内部开发者移植到 ROCM。

另一个例子是，由于数百万外部 CUDA 生态系统开发者，错误发现和修复速度更快。相比之下，在 ROCM 上，一个错误可能需要数月才能被发现，正如去年本文团队发现并报告的许多错误。例如，2024 年 ROCM 的 torch.scaled_dot_product_attention API。注意力是最先进的 Transformer 模型中最重要的层。

开发者

自 2025 年 1 月以来，AMD 一直高调宣扬 “开发者优先” 的方法，呼应了史蒂夫・鲍尔默（Steve Ballmer）著名的口头禅，也呼应了詹森（Jensen）的方法。在 TensorWave 的 “超越 CUDA 2025” 峰会上，AMD 的 AI 软件负责人 Anush 用三个字概括了 ROCM 的未来 ——“Developers, Developers, Developers（开发者，开发者，开发者）”。本文相信这种 “开发者优先” 的方法和信息将在 AMD 6 月的主题演讲中在更广泛的舞台上得到放大。AMD 也发现，让 CUDA 不可战胜的不仅是出色的芯片，还有大量的外部开发者。本文团队对 AMD 新的 “开发者优先” 方法感到非常赞叹。

2025 年 1 月，Anush 采取了这种 “开发者优先” 的方法，在 Tech Twitter 和 GitHub 上与外部 ROCM 开发者互动，收集反馈，每当 ROCM 出现问题时，开发者会担任客户支持，并亲自回答问题。这种亲力亲为的参与是真正的进步，尽管 AMD 的开发者关系仍然由骨干人员运作：除了 Anush，AMD 基本上没有全职的 devrel 工程师。虽然，AMD 已经开始招聘全职开发者关系工程师，但本文预计AMD要缩小与英伟达大批传道者的差距，该公司至少需要 20 多名 devrel 工程师，定期举办现场黑客马拉松和聚会。

英伟达一年一度的 GTC 开发者大会，“AI 超级碗”，他们会在一周内安排了 500 多场以开发者为中心的深入会议和实践实验室。涵盖从 PyTorch 到 JAX 到 CUTLASS 到 CUDA C++ 到 Assembly 到分析工具的栈的每一层，这为外部开发者提供了一个可靠的学习和推动前沿的地方。

相比之下，AMD 仍然缺乏像 GTC 这样以开发者为中心的会议，只有产品发布主题演讲。该公司 6 月的 “推进 AI” 活动将是揭示路线图的好机会，但该活动本质上是几个产品主题演讲加上几个预先录制的演讲 —— 远不及 GTC 的多轨开发者会议和代码实验室深度。如果 AMD 认真对待其新的 “开发者优先” 立场，它应该举办一年一度的现场 ROCM 开发者大会：三到四天的并行轨道，涵盖内核创作、图形编译器、HIP/Triton 迁移、MI300 集群调优以及使用 ROCM 工具链的实时调试。将这些演讲与由扩大的（20 多人）devrel 团队举办的现场黑客马拉松和后续的地区路演相结合，使ROCM 用户有一个分享经验、发现阻塞性错误和构建社交结构的场所。

来源：NVIDIA

尽管乔治・霍茨（George Hotz）本可以接受 AMD 早期提供的带有完整 BMC 访问权限的云托管 MI300X 系统，但他坚持要物理硬件，以便他可以直接 “破解硬件”。AMD 最初犹豫不决 —— 尽管霍茨的目标是帮助在AMD的 GPU 上开源工具。不过，当业内大亨 PyTorch 联合创始人苏米斯・钦塔拉（Soumith Chintala）发推文支持 Geohotz 接收物理盒子时，僵局的发展变成了一场公开的精彩戏剧，这推动的效果是奏效了。

来源：X

Geohotz 3 月 8 日的博客显示，AMD 已经让步，向他发送了两个 MI300X 盒子。对此，AMD 终于通过了 Geohotz 的 “文化测试”。对 AMD 来说，这可以说是比技术上的胜利更大的声誉政变 —— 向知名黑客发送真正的芯片，标志着一种新的 “开发者优先” 精神，这是仅靠营销资金无法买到的，它终于将一场激烈的 Twitter 传奇变成了一个展示 AMD 新的 “开发者优先” 精神的故事。

除了向 Geohotz 发送盒子，本文认为 AMD 还可以通过向学术实验室捐赠物理 AMD GPU 盒子来获得另一个轻松的声誉和营销胜利。詹森和伊恩・巴克（Ian Buck）长期以来一直有向学术实验室捐赠 GPU 的历史，甚至可以追溯到 2014 年。今年，詹森继续支持学术实验室，如卡内基梅隆大学的 Catalyst 实验室、伯克利的 Sky 实验室、加州大学圣地亚哥分校的 HaoAI 实验室等，除了提供对英伟达 GPU 的免费云访问外，还向他们捐赠了镀金的 B200 盒子。

来源：X

来源：X

来源：X

持续集成 / 持续部署（CI/CD）

在 SemiAnalysis 于 12 月发表 AMD 文章之前，AMD 没有 MI300X 参与 PyTorch CI/CD。不过此后，AMD 将 MI300 纳入了 PyTorch CI/CD。

曾经，AMD因提供不完善的软件而备受诟病，而将 MI300 纳入 PyTorch CI 后，这将会大大消除 AMD 软件中的错误。

以前，AMD 不想在 CI/CD 资源上花钱，但在过去四个月里，这种立场已经改变。在 ROCM SF 开发者聚会上，一位 AMD 软件工程师走到本文团队面前，表达了感谢，并说，“多亏你们的努力，AMD现在有了 CI 资源。”

除了单元测试 CI，AMD 还在 TorchInductor 性能 CI 上启用了 MI300，以便在inductor/torch.compile 提交中跟踪性能。英伟达只在这个 CI 中提供了 A100，甚至没有提供任何 H100 或 B200 用于 torchinductor 性能 CI。在这个特定的编译 CI 中，AMD 领先于英伟达。不过，仍有许多进步空间，因为 AMD 的动态形状 torch.compile 通过率仅为 77%，而英伟达的超过 90%。

资料来源： PyTorch

AMD 应该在此基础上开源并公开其所有 CI/CD 和仪表盘，以便任何人都可以看到 AMD 所有 ROCM 库（HipBLASLt、Sglang、vLLM、TransformerEngine 等）的软件通过率。目前，其 ML 库中唯一可公开访问的 ROCM CI 是 PyTorch。

即将推出的社区开发者云

谷歌的 TPU 能够获得外部开发者采用的原因之一是 TPU 的免费 Colab 访问，以及通过 TPU 研究云（TRC）提供的大型集群访问。这使得社区能够快速免费地访问，促成了许多有趣的项目，如 TRC 的亮点和作为 TRC 一部分发表的许多论文。事实上，在 2020 年，远在 ChatGPT 出现之前，一名高中生就能在一个相对巨大的 TPU pod 上免费训练一个与 GPT-2 竞争的模型。除了提供大量较小的 8-16 芯片 pod 外，TRC 还定期向研究人员提供 1-2 周的免费访问 1000 + 芯片 pod 的机会。

著名的开源 GPT-J 模型也是在 TPU 上免费训练的，导致了一个关于如何将 TPU 与 JAX 一起使用的完整开源存储库，并进一步促进了外部社区对 TPU 的采用。TRC 在推广 TPU 和支持开源社区方面非常成功。

AMD 的开发者云计划本质上是借鉴了谷歌的经验。如果 AMD 为这个开发者云计划投入足够的 GPU，使其 GPU 易于免费访问，AMD 的开发者云将能够帮助其扩大 GPU 的采用。这是 AMD 在与英伟达的竞争中必赢得的关键战役。

成功的衡量标准是是否在 AMD 的社区开发者云上出现 “GPT-J 时刻”。

来源：SemiAnalysis，AMD

AMD 管理层的漏洞 ——AMD AI 软件工程师薪酬

AMD 的 AI 软件部门面临着一个关键挑战：即薪酬缺乏竞争力。这严重地影响了其吸引和留住顶尖人才的能力。相比之下，其他以开发优秀 AI 软件而闻名的公司支付的薪酬明显高于 AMD。

虽然薪酬不是一切，但它仍然是影响工程师决策的一个重要因素。工程师通常根据多个因素评估职业机会，包括技术挑战、工作文化和成长机会。然而，有竞争力的薪酬仍是至关重要的，尤其是在 AI 软件工程等高度专业的领域。

在 AI 工程师中，众所周知，AMD 的总薪酬方案（包括基本工资、限制性股票单位（RSU）和奖金）远低于英伟达、特斯拉 Dojo、OpenAI 芯片团队、谷歌 TPU 和 xAI 等竞争对手。

在与顶尖 AI 软件工程师交流为何选择不加入 AMD 时，一方面，许多人指出，在 AMD 从事软件工作感觉像是在移植英伟达工程师两年前开发的功能。相比之下，英伟达为工程师提供了在前沿软件上工作的机会，并为用于 O3 等尖端模型（训练和推理）的芯片构建软件。

另一方面，被 “大卫与歌利亚”（小公司对抗巨头）情境吸引的工程师通常会选择谷歌 TPU 或 OpenAI 芯片团队，而非 AMD。因为这些团队提供更高的薪酬，且由于拥有大量内部工作负载作为自身客户，在与英伟达竞争时被认为成功概率更高，对有抱负的工程师更具吸引力。

AMD 内部对薪酬结构的基准对比似乎存在选择性偏差。通过与 Juniper Networks、Cisco 和 ARM 等不以软件见长的半导体公司进行基准对比，AMD 可能错误地认为自己的薪酬具有竞争力。然而，当与在 GPU 内核、GEMM、PyTorch 内部开发、分布式训练基础设施和推理引擎等 AI 软件领域闻名的公司进行合理对比时，薪酬差距就变得十分明显。

以英伟达 PyTorch 负责人与 AMD 同岗位对比，或英伟达 NCCL 工程师与 AMD RCCL 工程师对比，英伟达的薪酬明显更高，因此能够吸引和留住顶尖人才。

这一问题是 AMD 管理层战略中的关键漏洞。AMD 是清楚软件工程师对其长期竞争力和创新的重要性的，并希望将他们置于战略核心，但盲区源于不准确的基准对比和笼统的比较 —— 可以说是 “战争迷雾” 所致。这不幸导致了对软件人才的持续低估，并可能进一步加剧其相对于直接竞争对手的软件能力劣势。

AMD 应保持 AI 软件工程师的基本工资稳定，但大幅增加限制性股票单位（RSU）。通过将工程师薪酬与 AMD 的未来增长更紧密地挂钩，公司可以直接将顶尖人才的利益与组织长期绩效结合起来。

鉴于 AMD 拥有超过 50 亿美元的现金储备，公司有充足的财务能力对软件人才进行战略投资。领导层现在必须决定通过有意义的薪酬提升来优先留住和吸引高素质工程师。若不采取行动，AMD 可能会继续落后于英伟达，削弱其在快速发展的 AI 市场中的进步。

内部开发集群需要更多预算

过去四个月，AMD 的内部开发集群已有显著改善，但这些提升仍不足以在长期 GPU 开发竞争中有效立足。

目前，AMD 声称从云服务提供商租用了总计约 8,000 颗 MI300 GPU，分布在多个集群中，其中最大的单一集群包含约 2,000 颗 MI300 GPU。然而，深入分析显示，由于 AMD 内部采用 “突发模式”（按需临时调用），实际持续可用的 GPU 数量可能仅为 3,000 至 4,000 颗。内部开发者目前可获得充足的单节点开发资源，但多节点和大规模集群开发仍受限制。这一限制严重影响了大型项目和协作开发，亟需大幅增加 GPU 的绝对数量和可用性稳定性。

此外，随着行业采用数据中心规模的分离预填充优化进行推理，即使开发推理解决方案也需要集群级资源。AMD 当前为内部开发者提供的有限集群资源，进一步加剧了其在这一不断演进的领域中有效创新和竞争的难度。

AMD 内部集群采购的短期突发模式（大多数合同期限不足一年）是进一步扩张和创新的主要障碍。这与英伟达的战略形成鲜明对比 —— 英伟达采用持续多年的集群部署，使工程师能够自由探索创意和高风险项目，无需持续受到财务控制的监督。例如，英伟达运营着庞大的内部 GPU 资源，包括配备数千颗 GPU 的 A100 Selene 集群、两个 EOS 集群（一个含 4,600 颗 H100 GPU，另一个含 11,000 颗 H100 GPU），以及数十个 64-1024 颗 H100/H200 GPU 的小型集群（部署在本地或从 OCI、Azure、CoreWeave、Nebius 等云提供商租用）。今年AMD还将获得大规模的 GB200 集群，上述数字还不包括用于 DGX Cloud 的数十亿美元集群。

AMD 当前的模式下，每个 GPU 小时都直接与损益挂钩，这阻碍了必要的探索性项目和战略长期开发。

AMD 必须紧急从当前的亚年度集群战略转向签署长期（多年期）协议，并专门投资建设包含 10,000 颗以上旗舰级 GPU 的大规模集群。这种承诺将展示 AMD 对每一代 GPU 的长期投入，类似英伟达对每一代 GPU 提供跨多年的强大软硬件支持。现有的突发模式正严重损害 AMD 的内部开发工作并限制创新潜力。转向持续多年的投资模式将使其能够追求战略创新和竞争优势。

凭借超过 50 亿美元的现金储备，AMD 显然有财务灵活性转向更具战略性的长期投资方式。当前对季度收益的短视关注正损害其未来创新和开发领导力。对 GPU 代际采用多年期承诺将显著增强长期支持，使 AMD 的内部能力更贴近客户预期。这一战略调整还将让客户确信 AMD 对持续支持和创新的承诺，从而增强市场信心和长期合作伙伴关系。

ROCm 缺乏一流的 Python 支持

过去 12 个月，使整个 CUDA 生态系统在 Python 上成为一流体验一直是英伟达的首要任务，詹森本人亲自参与并管理这一工作。2010 年代，詹森率先认识到投资 CUDA 软件对 AI 的价值；2025 年，他的关键洞察是，AI 的事实上门语言是 Python，支持英伟达当前 C++ CUDA 栈的每一层进入 Python 世界将带来高回报。在今年的 GTC 上，英伟达发布了数十个 Python 库，从 GEMM 库（如 nvmath-python）到 cuBLASLt 绑定（cuda.binding），再到内核 DSL（如 cuTile、Warp、Triton、CuTe Python）。不幸的是，ROCM 库在 Python 中的支持远不及英伟达 —— 英伟达在栈的每一层都有 Python 接口，而 AMD 尚未提供。

来源：NVIDIA

通过在 CUDA 中优先支持 Python，终端用户可以用更少时间实现相同性能，或用相同时间实现更高性能。CUDA Python 实际上将 “应用性能与优化时间” 的帕累托前沿曲线向左移动。

来源：NVIDIA

举个简单例子：过去，开发者若想调用带自定义尾声的 cuBLASLt，需编写 C++ 扩展并通过 Pybind 绑定到 Python，这一过程复杂且增加了 ML 工程师需处理的间接层。现在有了 nvmath-python，同样的任务只需 3 行 Python 代码即可自动调优完成，耗时从 30 分钟缩短至 2 分钟。这些英伟达 Python 库并非半吊子绑定，而是以性能为核心的一流实现。

来源：NVIDIA

另一个例子：借助 cuda.cooperative 设备端库，开发者现在可以通过 Python 接口访问光速 CUDA 预构建算法（如块归约），而此前这些性能仅在 C++ CUDA 中通过 CUB 可用。

来源：NVIDIA

对于需要 1:1 Python 绑定（而非高阶 Python 库）的用户，英伟达还通过 cuda.binding 和 cuda.core 提供支持。英伟达在栈的每一层都有 Python 接口，AMD 则无。

来源：NVIDIA

AMD 最近推出了 AITER 的 Python 接口（相当于 cuDNN-python，支持 OAI Triton 进行内核创作），但在栈的其他层，ROCM 尚无同类产品，甚至尚未考虑支持一流的 Python 体验。

Python GPU 内核创作 DSL

在 GTC 2025 上，除了推出整体 Python CUDA 库，英伟达还发布了 Python 内核创作 DSL—— 即 Python CuTe 4.0、cuTile Python 和 Warp。这是在英伟达现有 Triton DSL 支持之外的新增功能！AMD 在 Python 内核 DSL 领域缺乏竞争力，以至于英伟达团队现在用多个新 DSL 相互竞争 —— 目前已公开推出五种不同的英伟达 Python DSL（OAI Triton、CuTe Python、cuTile Python、Numba、Warp），还有更多内部开发中的 DSL 尚未公开。

Python 内核 DSL 可按抽象单元分为两类：程序员在基于线程的语言中描述单线程行为，而在基于分块的语言中描述矩阵分区操作。

CuTe Python 是英伟达推荐的基于线程的 Python 内核 DSL 中编写光速内核的路径。它提供低级原语作为自定义内核的构建块，并使用强大的抽象 cuTe（CUDA Tensor）描述数据和线程布局。CUTLASS Python 的 API 设计基于 CUTLASS，新用户可利用 CUTLASS 丰富的概念和用法文档快速上手。AMD 虽有类似 CUTLASS 的 C++ 库 CK（Composable Kernel），但其概念和用法文档相对稀疏且不清晰。CK Python 接口正在为其高级接口开发，但尚未计划为类似 CuTe 的原子层提供接口。

更重要的是，AMD 目前普遍缺乏用于线程级内核编程的 Python DSL，而这是实现光速性能的关键。

来源：NVIDIA

对于基于分块（Tile）和 SIMT 的混合分块 / SIMT 内核创作 Python DSL，英伟达在 GTC 2025 上推出了 cuTile。cuTile 并非追求 100% 光速性能，而是以 10% 的时间编写内核实现 98% 的光速性能，编写内核相对容易。遗憾的是，AMD 在混合 SIMT / 分块的 Python 内核 DSL 领域尚无产品。

来源：NVIDIA

Triton 在张量核心时代普及了基于分块的编程模型，其有效抽象位于分块层而非单线程层。英伟达将在支持 cuTile 分块 DSL 的同时，继续全面支持 Triton 的分块 DSL。

来源：NVIDIA

对于微分模拟 AI，英伟达发布了 Warp Python DSL。Warp 是混合分块和 SIMT 的编程模型，适用于编写模拟和几何处理代码。Warp 相较 cuTile 的优势在于其自动微分功能，这在模拟中生成反向传播时极为有用。AMD 在这种混合 SIMT / 分块的可微分 Python 内核 DSL 领域同样没有产品。

来源：NVIDIA

来源：NVIDIA

英伟达在推出所有新 Python DSL 的同时，继续全面支持 OpenAI Triton Python DSL。Triton 的主要维护者是 OpenAI，其使命是构建安全的 AGI。在 2025 年 SemiAnalysis Blackwell PTX 黑客马拉松上，Triton 的 OpenAI 首席维护者 Phil Tilet 甚至表示：“AGI 不会来自 10% 更快的矩阵乘法”，这也是 Triton 优先支持功能的指导思想。因此，若 AI 芯片厂商想拥有最快的 AI 芯片，仅支持 Triton 是不够的。本文团队认为，AI 芯片厂商应在支持其他 Python DSL 的同时，继续全面支持 Triton。

来源：OpenAI，SemiAnalysis Blackwell PTX 黑客马拉松

这种立场导致目标错位：OpenAI Triton 不关心实现绝对光速性能，而英伟达、MTIA、MAIA、AMD 等 AI 芯片厂商则非常重视内核语言中的峰值性能。

英伟达的 Triton 性能尚未接近光速，而 AMD 的 Triton 性能则更远离光速。AMD 需要大量招聘和投资，以大幅提升 Triton 性能，并支持 / 发明其他 Python 内核 DSL。

AMD 有一个实验性内核语言 Wave，采用基于 warp 的编程模型，但其开发仍处于早期阶段，尚未获得公司的全面支持。这与 cuTile、CuTe、Warp 等获得詹森和英伟达全力支持的 DSL 相去甚远。此外，考虑到行业正转向基于 warp 组的 MMA 硬件和 2-CTA MMA 硬件，而非基于 warp 的 MMA，基于 warp 的内核 DSL 是否提供了正确的抽象层仍存疑问。

AMD RCCL 与英伟达 NCCL 的差距扩大

集体通信库对 AI 训练和推理至关重要，因为这些库使多个 GPU 能够协同处理同一工作负载。英伟达的集体通信库是 NCCL，AMD 的库是 NCCL 的 “复制粘贴” 分支，称为 RCCL。

自 2024 年 12 月的文章中分享对 RCCL 的看法以来，RCCL 团队已取得一些进展。MI300X 投产一年多后，RCCL 团队终于在 MI300X 上支持了 LL128 协议，这是重大改进，但相比之下，Blackwell（英伟达产品）在第一天就支持所有三种集体协议（SIMPLE、LL、LL128）。

此外，RCCL 终于支持铁路优化树（rail optimized trees），通过减少流向主干交换机的流量来提升网络性能，减少路径冲突。而 NCCL 支持这一功能已多年。

来源： Github

尽管 RCCL 取得了一些进展，但由于 GTC 2025 上宣布的 NCCL 新改进和功能，NCCL 与 RCCL 的差距持续显著扩大。RCCL 团队需要更多访问大型计算集群等资源，才能追赶 NCCL。大体上，RCCL 要获得至少 1,024 颗 MI300 级 GPU 的专属持续集群访问权限。此外，AMD 领导层需要大幅提高 RCCL 工程师的 RSU 薪酬，以吸引和留住这一关键任务软件库的核心人才。

由于 AMD 的 RCCL 库是英伟达 NCCL 的直接分支，NCCL 2.27 和 2.28 的大规模重构将继续扩大 CUDA 的护城河，迫使 AMD 的 RCCL 团队花费数千工程小时将英伟达的重大重构同步到 RCCL。当 AMD 工程团队忙于同步更改时，英伟达将利用这段时间继续推进集体通信软件栈和算法的前沿。这种动态使得 AMD 几乎不可能在维持 RCCL 现有开发的同时，实现与 NCCL 的 parity，更遑论超越。

AMD 已表示，目前正计划从头重写 RCCL，以不再作为 NCCL 的分支。

在 GTC 2025 的演讲中，本文团队开玩笑地问 NCCL 负责人 Sylvain Jeaugey，鉴于即将发布的 2.28 版本中 NCCL 的重大重构，英伟达是否会支持 AMD 的 RCCL 分支。他拒绝了我们的建议：

鉴于即将发布的 2.28 版本中的重大重构，英伟达会为 AMD 的 RCCL 分支提供支持吗？

Sylvain：我们会帮助 RCCL 迁移到新版本吗？我认为不会 —— 通常我们不会参与该开发。

在演讲中，Sylvain 还宣布了即将推出的大规模重构中的许多新 NCCL 功能，包括原生支持对称内存（symmetric memory），以及运行速度更快、占用 SM 更少（从而释放更多 SM 用于计算）的新算法。

来源：NVIDIA

PyTorch 引入了 SymmetricMemory API，使用户能够轻松利用多 GPU 扩展可编程性，并在 CUDA 或 Triton 中编写集体或融合计算 / 通信内核。此前，编写多 GPU 融合计算 / 通信内核需要大量工作，而 SymmetricMemory 大幅减少了所需工作量。高性能推理内核（如单次和两次集体操作，以及全收集融合矩阵乘法内核）可通过 SymmetricMemory 轻松编写。

资料来源： PyTorch

这一功能在英伟达 GPU 上已可用 8 个月，而 AMD GPU 仍不支持。AMD 已表示将在 2025 年第二季度初步支持 PyTorch SymmetricMemory API。

资料来源： PyTorch， YiFu

在即将发布的 2.27 版本中，allreduce 在相同消息大小下实现 4 倍更低的缩减，并在 4 倍更小的消息大小下达到相同算法带宽。

来源：NVIDIA

在即将发布的 2.28 版本中，NCCL 提供设备端 API，使用户能够轻松编写自定义通信 / 计算融合内核。

来源：NVIDIA

即将发布的 NCCL 2.28 版本还将支持 InfiniBand 和 RoCEv2 以太网的 GPUDirect Async（IBGDA）。目前，在 NCCL 和 RCCL 中，CPU 代理用于控制扩展通信的流程。尽管数据流不经过 CPU，但控制流经过 CPU 仍限制了实际性能。通过英伟达 NCCL 2.28 与 IBGDA 的集成（支持 RoCEv2 和 InfiniBand），控制流由 GPU 初始化，不经过 CPU，从而提升了小到中等消息大小下 all2all 及基于 all2all 算法的性能。

来源：NVIDIA

来源：NVIDIA

另一项目前仅英伟达支持的功能是用户缓冲区注册（user buffer registration）。该功能避免在用户张量和 NCCL 内部缓冲区之间创建额外副本，有助于减少集体操作所需的 SM 数量并缓解内存压力，使端到端训练性能提升 5-20%。

来源：NVIDIA

大多数经验丰富的 ML 工程师都遇到过可怕的 NCCL_TIMEOUT/RCCL_TIMEOUT 或 NCCL/RCCL 停滞问题。英伟达 NCCL 支持 ncclras，简化了这些问题的调试。遗憾的是，RCCL 目前不包含任何调试功能。

来源：NVIDIA

基础设施软件进展缓慢

过去四个月，AMD 在软件基础设施层（如 Kubernetes、SDC 检测器、健康检查、SLURM、Docker、指标导出器）取得了有意义的进展，但其进展速度远不及 AMD 的 ML 库。

直到七个月前，AMD 还完全没有 GPU 指标导出功能，意味着集群管理员无法观测 GPU 状态。尽管 ROCM 声称是开源生态系统，但 AMD 的 GPU 指标导出器直到 SemiAnalysis 向 AMD 高管提出这一点，倡导他们以紧迫感践行所宣称的 “开源” 生态系统承诺后，才实现开源。

幸运的是，经过多次跟进，AMD 终于开源了其 GPU 导出器。请注意，该导出器仍在开发中，许多功能尚未实现，与英伟达的开源 GPU 指标导出器仍有差距。例如，AMD 的 GPU 导出器目前仍不支持矩阵核心活动、CU 占用率或 CU 活动等指标，而这些是衡量工作负载性能的重要指标。当前唯一可用的利用率指标是 GPU_UTIL，而大多数经验丰富的 ML 工程师都知道，该指标对英伟达和 AMD GPU 而言都无法真正衡量利用率。

正如 12 月的 AMD 文章中所述，AMD 的 Docker 用户体验（UX）相较英伟达差很多。AMD 已承认这一不足，并表示正在努力改进，预计本季度晚些时候会公布路线图。

来源：SemiAnalysis

与英伟达栈不同，AMD 栈上 Slurm + 容器的当前状态令人感到沮丧。在英伟达上使用开源 Pyxis Slurm，通过 Slurm 启动容器只需运行 “srun –container-name=pytorch”。而在 AMD 上，用户必须经过极其复杂的流程，需要大量间接操作才可以。

考虑到所有 AMD 内部 AI 工程师都在使用带容器的 SLURM，当前 AMD Slurm + 容器的糟糕用户体验和大量间接操作令人担忧。

资料来源：GitHub、AMD

本文团队多次建议 AMD 优先修复这一问题，并通过付费咨询 SchedMD（Slurm 的维护者）来支持一流的 Slurm + 容器体验，但尚未看到任何具体的时间线或路线图。

此外，英伟达的数据中心管理器工具（DCGM）直接集成了 NVVS（英伟达验证套件），运行诊断只需 “sudo dcgmi diag -r <diag_level>”。而在 AMD 上，RVVS（ROCM 验证套件）与数据中心工具（RDC）分离，迫使用户下载另一个库。本文建议 AMD 将 RVVS 集成到 RDC 中，使用户体验与英伟达的 DCGM 一样简单。

AMD 的用户体验感和验证覆盖范围也不如 DCGM。英伟达的 DCGM 使用表示不同级别的符号（r1, r2, r3, r4），而 AMD 的 NVVS 未采用任何此类符号。

来源：NVIDIA

AMD 缺乏分离预填充推理和 NVMe KV 缓存分层

AMD 目前缺乏对分离预填充、智能路由和 NVMe KV 缓存分层等许多推理功能的支持。分离服务已成为行业标准多年，上个月英伟达开源了分布式推理框架 Dynamo，进一步普及了英伟达 GPU 的分离服务。分离预填充将预填充阶段和解码阶段分配到不同 GPU。甚至谷歌也推出了自己的分离推理框架。

来源：北京大学

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

在解码阶段，确保序列长度和请求在解码 GPU 之间均匀分布和平衡至关重要。Dynamo 提供的 GPU Planner 可复制流量较高的专家节点，帮助负载均衡。

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

Dynamo 的 GPU Planner 是预填充和解码节点的自动扩展器，可根据白天的需求波动启动额外节点。它能在 MoE 模型的许多专家之间实现一定程度的负载均衡，在预填充和解码节点中均可动态分配节点。GPU Planner 还可根据需要在预填充和解码节点之间动态重新分配节点，进一步最大化资源利用率。

这还有助于改变用于解码和预填充的 GPU 比例 —— 对于 Deep Research 等场景尤其有用，这些应用需要大量上下文审查，但生成量相对较小，因此需要更多预填充而非解码。

来源：NVIDIA

英伟达 Dynamo 的 KV 缓存卸载管理器通过将先前用户对话的 KV 缓存存储在 NVMe 存储中而非丢弃，实现了更高效的预填充执行。

来源：NVIDIA

来源：NVIDIA

当用户与 LLM 进行持续的多轮对话时，LLM 需要将对话中的先前问题和回答作为输入令牌， naive 实现中推理系统会丢弃用于生成这些内容的 KV 缓存，导致重复计算。

借助 Dynamo 的 NVMe KV 缓存卸载功能，当用户离开时，KV 缓存可卸载到 NVMe 存储系统，待用户返回对话时快速检索，避免重新计算 KV 缓存。

这释放了预填充节点的容量以处理更多传入流量，或可减少所需的预填充部署规模。用户还将获得更快的首令牌时间，因为检索 KV 缓存的时间远少于重新计算的时间。

来源：NVIDIA

随着 RLVR（强化学习与虚拟机器人）和带工具使用的多智能体系统越来越普遍，KV 缓存卸载功能将变得愈发重要。

对 AMD 的建议总结

semianalysis期待看到英伟达有一个有效的竞争对手，并希望帮助 AMD 达到这一地位。过去四个月，AMD 取得了巨大进展，但仍需做出许多改变才能与英伟达竞争。此前，本文团队已向 Lisa Su 和 AMD 领导层详细阐述建议，以下是总结：

保持紧迫感：AMD 需要保持（甚至加强）紧迫感，才有机会与英伟达并驾齐驱。

调整薪酬基准：AMD 领导层最大的漏洞是 AI 软件工程师的总薪酬（基本工资 + RSU + 奖金）因错误地以半导体公司而非顶尖 AI 软件公司为基准而偏低。建议大幅提高薪酬，将工程师利益与 AMD 的成功绑定，否则将继续输给英伟达。

投资 Python 生态：AMD 应在 ROCM 栈的每一层大力投资 Python 接口，而不仅仅是 Python 内核创作 DSL。

扩大开发者关系团队：AMD 需要招聘 20 多名开发者关系工程师，举办线下活动并深入社区互动。

举办开发者大会：与英伟达 GTC 不同，AMD 目前缺乏以开发者为中心的会议，仅举办产品发布会。建议举办线下 “ROCM 开发者大会”。

推进推理功能：英伟达已推出 Dynamo 分离预填充推理框架和 NIXL 推理 KV 缓存分层库，AMD 需快速在分离预填充和 NVMe KV 缓存分层上取得进展，否则将在推理领域落后。

强化 RCCL 资源：AMD 应向 ROCM 集体通信工程师提供至少 1,024 颗 MI300 级 GPU 的专属持续集群，帮助 RCCL 追赶 NCCL。

透明化性能指标：英伟达在芯片规格中夸大 TFLOP/s，AMD 更甚。AMD 应在公开新的内部模型训练结果时，公布模型 FLOPS 利用率（MFU）和每 GPU 的 TFLOP/s，目前 AMD 尚未做到，这可能暗示其 MFU 较低。

优化 SLURM 支持：与英伟达的 Pyxis 解决方案相比，AMD 对 SLURM 容器的一流支持尚不存在。建议 AMD 投资 SchedMD 咨询，使 SLURM 容器支持与英伟达看齐。

开源 CI/CD 仪表盘：AMD 应开源并公开所有 ROCM 库（HipBLASLt、Sglang、vLLM、TransformerEngine 等）的 CI/CD 和仪表盘，目前仅 PyTorch 的 ROCM CI 可公开访问。

长期集群投资：AMD 目前的内部集群采用短期突发模式，导致开发项目受限于 GPU 小时的损益计算。英伟达的集群是多年期持续部署，AMD 应改变采购策略，进行多年期投资，以支持每代 GPU 的长期开发，增强客户对其长期支持的信心。

平衡基础设施开发：AMD 的软件基础设施层（Kubernetes、SLURM、Docker 等）进展缓慢，需投入更多工程资源，匹配 ML 库的快速进步。

支持学术生态：詹森已向伯克利 Sky 实验室、CMU Catalyst 研究组等学术实验室捐赠 DGX B200 盒子，AMD 应效仿，通过捐赠硬件和宣传提升品牌形象。

对英伟达的建议

过去几年，英伟达领导层内部将华为视为最可能与其竞争的公司。鉴于 AMD 的快速进步和他们地迫切追赶，本文认为英伟达应将 AMD 视为主要竞争对手。若想保持市场领先，本文向詹森提出以下建议：

快速扩展 API 表面：若英伟达以比 AMD 更快的速度扩展 API 功能，使其难以复制 / 移植到 ROCM，将继续保持领先。近期 CUDA Python 栈的发布就是大规模增加 API 表面的成功案例。

开放消费级 GPU 到 CI/CD：许多开发者通过英伟达消费级 GPU 进入 CUDA 生态系统，但由于消费级 EULA 限制，PyTorch 等 ML 库无法在 CI/CD 中使用消费级 GPU，导致体验不佳。建议英伟达探索将消费级 GPU 纳入 PyTorch CI/CD 的策略。

整合用户缓冲区注册：NCCL 的用户缓冲区注册功能可减少内存压力，提升 5-10% 性能，但目前尚未整合到 DistributedDataParallel（DDP）、DTensors 或 FullySharedDataParallel（FSDP）等常用 API 中。建议英伟达将该功能整合到整个 PyTorch 栈。

优化开箱即用体验：尽管英伟达的开箱即用体验优于 AMD，但仍有改进空间。例如，开发者需使用 NVIDIA/apex 库才能为 RMSNorm 获取最佳性能，而 RMSNorm 是 SOTA LLMs 中的常见层。建议英伟达与 Meta PyTorch 团队合作，将快速 RMSNorm 内核和其他 cuDNN 内核直接整合到 PyTorch 中。

增加 CI 资源：英伟达需为 PyTorch 的 TorchInductor Benchmark CI 提供更多 H100 GPU，目前 AMD 已为 MI300 启用该 CI，而英伟达仅提供 A100。

提升基准可重复性：过去四个月，AMD 通过提供可复现的基准说明（如 MLPerf Inference 5.0 提交博客）赢得社区信任。若英伟达希望 ML 社区对其基准结果有信心，建议在发布基准时提供可复现说明和解释性博客。

践行开源精神：英伟达的部分开源库（如 NCCL、CUTLASS）在 “开源” 精神上表现不佳，每次发布仅进行代码转储。trt-llm 转向 GitHub 优先方法后已有进步，建议英伟达在所有开源库中践行开源精神。

规范性能指标：停止宣传 “詹森数学” 式的 2:4 稀疏 FLOPS 规格，避免未公开的双向带宽惯例，减少生态系统混乱。避免夸大密集 FLOPS 规格，转而发布反映真实输入分布（而非不现实的 [-4,4] 均匀离散整数分布）下可实现的 FLOPS 指标。

挖掘 AMD 人才：通过 GitHub 上的贡献者标签（如 “[ROCm]”PR 标签），挖掘为 RCCL、ComposableKernels、hipBLASLt、ROCm/PyTorch 等库做出贡献的 AMD 工程师并招聘。

MI325X 和 MI355X 的客户兴趣

正如一年来所言，客户对购买 MI325X 兴趣寥寥。它本应与 H200 竞争，但 MI325X 于 2025 年第二季度开始发货，比 H200 晚了三个季度，且与 Blackwell 大规模生产同时推出。客户显然选择性价比更低的 Blackwell，因此 MI325X 的发布太迟太少，AMD 仅售出少量。

本文团队的加速器模型需求分析显示，微软在 2024 年初感到失望，全年未对 AMD GPU 下达后续订单。不够，本文认为，OpenAI 通过甲骨文和其他主要客户重新对 AMD GPU 产生兴趣，但微软仍未感兴趣，除非前提是与 AMD 达成优惠定价。需要明确的是，MI355X 仍无法与英伟达的机架规模 GB200 NVL72 解决方案竞争，因其扩展规模仅为 8 GPU，而英伟达 GB200 NVL72 为 72 GPU。

AMD 将 MI355X 的竞争力定位为无需直接芯片液冷（DLC），这确实有一定道理，但颇具讽刺意味的是，AMD 仍将下一代 MI355X 定位为英伟达上一代经济型产品的竞争对手。由于上述较小的扩展规模，MI355X 无法与英伟达旗舰 GB200 NVL72 在前沿推理上竞争，因此转而定位为与风冷 HGX B200 NVL8 和 B300 NVL16 竞争。

尽管如此，该产品细分市场仍将实现可观销量，且取决于 MI355X 的软件质量和 AMD 的定价，其在性能与总拥有成本（TCO）比上可能与英伟达 HGX 具有竞争力，尤其适用于不依赖大规模扩展的中小模型。但本文认为，在受益于大规模分离部署或专家混合的推理模型和前沿推理中，GB200 NVL72 将在性能和 TCO 上占优。