在 AI 基础设施领域，AMD 与 NVIDIA 的竞争已从硬件层面延伸至软件生态的每一寸领地。ROCm 作为 AMD 的核心软件栈，正在通过一系列工程实践逐步缩小与 CUDA 的互操作差距。理解这一互操作现状，不仅关乎技术选型，更直接影响企业多供应商 GPU 部署的战略决策。
从 HIPify 到 Triton：移植范式的根本转变
AMD 对 CUDA 代码的移植支持经历了显著的演进过程。传统的 HIPify 工具链，包括 hipify-clang 和 hipify-perl，能够将 CUDA 源代码转换为 HIP C++ 代码，使其同时支持 AMD 和 NVIDIA GPU 编译。这一技术在 ROCm 5.x 至 7.x 版本中持续得到优化，AMD 承诺 ROCm 7.0 将使 HIP C++ 与 CUDA 的语法对齐更加紧密，从而减少移植过程中的手动调整工作量。
然而，AMD 副总裁 Anush Elangovan 在近期接受采访时指出了一个重要趋势：直接进行 CUDA 到 HIP 的代码转换已不再是主流需求。如今大多数推理客户使用的是 vLLM 或 SGLang 等高层框架，运行着少数主流大语言模型，核心关注点是最大化每秒令牌吞吐量。这一变化使得 Triton 成为真正的 “均衡器”—— 开发者可以编写一次 Triton 内核，即可在 AMD 和 NVIDIA GPU 上运行。
AMD 在 Triton 生态中的投入不可谓不激进。公司内部有核心工程师主导 Triton 开发工作，并与 OpenAI 保持密切合作。这种高层抽象的编译器基础设施，使得新出现的注意力算法实现可以在 24 至 48 小时内完成针对 AMD 硬件的优化版本构建。Elangovan 本人甚至表示，他在日常工作中更依赖 AI 工具（如 Claude）来编写和验证新的 AMD 内核，而非传统的 HIPify 工具，因为 AI 工具具备网络搜索能力，能够更好地理解最新的 CUDA 接口变化。
OneROCm：统一架构的工程实践
ROCm 内部代号为 "OneROCm" 的统一栈建设，是 AMD 近年来最重要的软件工程成就之一。在 2024 年之前，ROCm 更像是各色固件组件的松散集合，不同硬件类型需要不同的加速路径。如今，这一状况已彻底改变 —— 所有 AMD 硬件的加速计算都通过统一的 ROCm 栈完成，实现了不同类型 AMD 硬件之间的代码可移植性。
这种统一架构的设计哲学借鉴了 Google Chrome 团队的开发模式。Elangovan 的目标是让 ROCm 用户如同 Chrome 用户一样，无需关心具体版本号，“开箱即用” 才是真正的成功标准。目前 ROCm 已实现六周发布节奏，Windows 笔记本与 Instinct 数据中心硬件在同一天收到更新。这种一致性的交付节奏，对于需要管理多环境的企业 IT 团队而言尤为关键。
在具体工程实现层面，ROCm 6.4 引入了 AMD GPU Operator，为 Kubernetes 环境下的 GPU 调度和生命周期管理提供了自动化能力。这一改进直接回应了多 GPU 集群部署中最常见的运维痛点 —— 驱动升级、GPU 遥测和健康监控的自动化程度直接决定了集群的运维效率。
多供应商 GPU 集群的工程挑战
部署混合 AMD 与 NVIDIA GPU 集群时，互操作性仍然是最大的技术障碍。当前行业实践中，跨供应商工作负载的统一调度主要依赖两种方式：一是构建统一的 MLOps 层，通过容器化和抽象层屏蔽底层硬件差异；二是利用 UCX 等高性能通信库建立跨后端的传输层。然而，这两种方案都存在显著的工程复杂度。
网络层面的挑战同样不容忽视。大规模分布式训练和推理依赖于高带宽低延迟的互联互通。在某些云配置中，由于 RDMA 支持的不完整或特定实例类型的限制，TCP 传输被迫成为默认选项，这对大规模集群的吞吐性能构成实质性瓶颈。企业在规划百卡以上规模的 ROCm 集群时，必须在部署初期就明确网络拓扑和传输层选择。
heterogeneous cluster orchestration 的成熟度也是关键考量因素。ROCm 7.0 虽然强化了异构集群中 transformer 工作负载的编排支持，但在多节点环境下的调度策略优化、负载均衡以及故障恢复，仍可能需要定制化的编排层实现。对于已经建立成熟 NVIDIA DGX 架构的组织而言，向 ROCm 环境的迁移成本需要与潜在的供应链多元化收益进行谨慎权衡。
开发者生态的实质性进展
ROCm 的 100% 开源策略（固件除外）正在产生切实的开发者社区效应。开源模式使得外部贡献者能够在编译器或运行时的任意层面介入创新，不再受限于 AMD 的合作节奏。去年的一项 GitHub 调查收到了超过 1000 条 ROCm 投诉反馈，一年后这些投诉全部得到了响应和处理。Elangovan 本人保持了在社交媒体上直接回应开发者投诉的习惯，包括那些明确表达不满的声音。
对于 HPC 客户，HIPify 仍然是不可替代的工具 —— 这类用户往往拥有数百万行 CUDA 代码的历史资产，需要渐进式的迁移策略。但在 AI 和推理领域，向上层框架的迁移已经成为主流，Triton 和 MLIR-based 的 Torch.MLIR 为这种过渡提供了可靠的技术桥梁。
企业在评估 ROCm 与 CUDA 的互操作路径时，应根据具体工作负载类型做出差异化决策：对于新的 AI 推理部署，优先考虑 Triton-based 方案以获得跨平台可移植性；对于 HPC 和科学计算场景，HIPify 仍是主力工具但需预留手动调优工作量；对于大规模多供应商集群，统一的 MLOps 抽象层建设是必经之路，而 ROCm 6.4 + 的 GPU Operator 为这一目标提供了起点。
资料来源：EE Times 独家专访、AMD ROCm 官方博客、HIPIFY 文档
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。