为硬件多样性做架构：Meta 在 AMD GPU 上的端
来自 arXiv · 期号 2026-10-16
摘要
Meta 的数据中心里混着 NVIDIA GPU、AMD GPU 和自研 MTIA 加速器，但大量代码是为 NVIDIA 生态优化的，搬到其他硬件上性能很差。 本文以推荐模型训练为例，把 AMD MI350X 和 NVIDIA B200 做对比，总结了三条可复用的原则：一是硬件与模型要联合设计，不要直接移植，比如 MI350X 的 HBM 容量是 B200 的 1.6 倍，模型结构可以据此调整；二是用分析性能模型实现零预热的最优 kernel 选择，省掉大量调优工作；三是用 agentic 工作流做微架构感知的 kernel 优化和自定义 shim 生成。 相比直接移植，端到端训练吞吐最高提升 1.5 倍。这是第一篇来自超大规模公司的 AMD GPU 生产化报告，相关贡献已上游到 PyTorch、Triton 和 ROCm。
深读
导读 Meta 的数据中心混用 NVIDIA、AMD 和自研 MTIA 加速器，但大量代码为 NVIDIA 生态优化，移植到其他硬件性能骤降。这篇论文以推荐模型训练为例，总结了三条可复用的硬件-模型联合设计原则，将 AMD MI350X 上的端到端训练吞吐提升至直接移植方案的 1.5 倍。这是第一篇来自超大规模公司的 AMD GPU 生产化报告，相关贡献已上游到 PyTorch、Triton 和 ROCm。 关键信息 - 对比对象：AMD Instinct MI350X 与 NVIDIA B200，场景为推荐模型训练。 - MI350X 的 HBM 容量是 B200 的 1.6 倍，模型结构可据此调整以充分利用硬件优势。 - 分析性能模型实现了零预热的最优 kernel 选择，覆盖生产模型中的多种数据类型和矩阵形状。 - 相比直接移植基线，端到端训练吞吐最高提升 1.5 倍。 - 相关优化已上游到 PyTorch、Triton 和 ROCm 开源生态。 逐节讲解 问题背景与动机 Meta 的数据中心部署了异构加速器（NVIDIA GPU、AMD GPU 和自研 MTIA），以降低成本并避免供应商锁定。但长期针对 NVIDIA 生态的优化导致代码在其他硬件上性能不佳。论文以推荐模型训练为案例，展示如何优化 AMD GPU 上的训练性能。 三条可复用原则 原则一：硬件-模型联合设计。 不应简单地将模型从 NVIDIA GPU 直接移植到 AMD GPU，而应根据目标加速器的特性调整模型结构和软件方案。例如，MI350X 的 HBM 容量是 B200 的 1.6 倍，模型结构可以据此重新设计以充分利用更大的显存。 原则二：分析性能模型实现零预热最优 kernel 选择。 生产模型涉及多种数据类型和矩阵形状，传统调优需要大量预热和试错。论文提出的分析性能模型可以在不预热的情况下直接选出最优 kernel，大幅简化调优工作。 原则三：利用 agentic 工作流降低从 CUDA 生态移植的门槛。 随着 agentic 工作流日趋成熟，论文将其扩展用于微架构感知的 kernel 优化和自定义 shim 生成，进一步加速了从 CUDA 到 AMD ROCm 生态的移植。 效果与贡献 相比直接移植的基线，上述方法使端到端训练吞吐最高提升 1.5 倍。论文声称这是第一篇来自超大规模公司（hyperscaler）的 AMD GPU 生产化报告，相关优化已上游到 PyTorch、Triton 和 ROCm 开源生态。 值得注意 原文为论文摘要，信息有限。三条原则的具体实现细节（如分析性能模型如何构建、agentic 工作流的具体设计）在摘要中未展开。推荐模型的具体结构、训练规模、对比测试的软硬件环境等关键信息也未提供。