让 AMD V620 在 Windows 11 上真正跑起 PyTorch——原生 HIP 路线全记录

关注

原创 2026-08-06 22:59:37 377 阅读 AI 写同款· GEO 优化 ›

Python 开发的实践：从数据结构选型到框架决策规模多大？决定用list还是set，Pandas 还是 Polars。瓶颈在哪？I/O 密集用异步，CPU 密集用进程/自由线程，内存受限用列式与惰性执行。代价是什么？消除手动维护窗口的出错面，TaskGroup消除失败任务不被取消的泄漏，消除 N+1，Protocol消除为类型约束而引入的继承层级——每个选择都在消除某类代价，同时也引入新的约束。能回答这三个问题，比记住更多 API 更有用。愿你我都能在各自的领域里不断成长，勇敢追求梦想，同时也保持对世界的好奇与善意! 阅读详情

前言：一个令人沮丧的 “False”

在 Windows 11 工作站上插入 AMD Radeon PRO V620，启动 ComfyUI 准备跑一张图，或者在 Conda 环境里运行 MinerU 解析文档——终端返回的结果是 torch.cuda.is_available() -> False。所有任务默认挤在 CPU 上，32GB 的 HBM2e 显存纹丝不动。

这并非硬件故障，而是软件生态的"墙"。Windows + AMD GPU 的 AI 开发场景下，开发者长期面临"显卡性能强大却无处施展"的尴尬。本文先把 AMD GPU 跑 PyTorch 的底层逻辑讲清楚，再给一套在 V620 上验证过的完整方案。这套方案不仅适用于 ComfyUI，同样能解决 MinerU 及 YOLO 的同类报错，并在原理上支持其它基于 PyTorch 的推理应用。

方案选型：为什么一定要走"原生 HIP 路线"？

在深入原理之前，有必要先厘清 Windows 下 AMD GPU 运行 AI 框架的几条常见道路。

目前业内主流推荐的不外两种妥协方案，但都存在明显短板：

方案一：Torch-DirectML（微软官方兼容层）

这是微软为 Windows 平台推出的 DirectX 12 机器学习加速后端。一行 pip install torch-directml 就能让 PyTorch “跑起来”。

痛点：DirectML 本质上是将 PyTorch 算子通过 DirectML Execution Provider 交给 Direct3D 12 调度执行，走的并不是 AMD 计算驱动。这带来两个实际问题：算子覆盖不全——属于 DirectML Backend 自身的限制——Stable Diffusion 中的自定义 Attention 机制等复杂模型会频繁回退 CPU；显存管理效率偏低，V620 作为专业计算卡的带宽优势发挥不出来。适合尝鲜，不适合深度推理。

方案二：WSL2（Windows 子系统 Linux）

由于 AMD 官方 ROCm 长期将 Linux（尤其是 Ubuntu）作为"一等公民"优化，不少开发者选择在 Windows 内开 WSL2，然后在虚拟 Linux 内核下装原生 ROCm 驱动。

痛点：WSL2 通过 GPU Paravirtualization（GPU-PV）访问 GPU，计算性能损失通常不大，但跨 Windows 与 Linux 文件系统的 I/O 会产生额外开销。MinerU 这类需要频繁读写本地文档的任务，或者 YOLO 训练需要高速加载海量图像数据集的场景，跨文件系统的读写延迟会明显拖慢整体流程。

本文推荐方案：原生 Windows HIP SDK + ROCm 版 PyTorch

随着 AMD 在 2025 年后对 Windows 平台投入加大，最新版本的 HIP SDK 已经能原生支持 Windows 上的计算驱动。本方案不依赖 DX12 翻译层，也无需虚拟化开销，而是让 PyTorch 通过 HIP Runtime 直接与 AMD GPU 驱动进行底层通信。

根据 ROCm GitHub Discussions 中多位开发者的实测反馈，本方案在 V620 的大模型推理场景中通常优于 DirectML 方案，且能兼容大多数基于 PyTorch 的推理应用。不过，部分依赖 CUDA Extension 或 Triton 的项目仍可能存在兼容性限制。当前对 gfx1030 的 Windows 支持仍标注为"可能可用但未经严格测试"，但它确实是 AMD Windows 生态发展的官方方向。

一、核心原理：AMD GPU 运行 PyTorch 的技术栈

要解决问题，首先要理解 PyTorch 与 GPU 之间的"对话"机制。

1. PyTorch 的多后端架构

PyTorch 并非只支持 NVIDIA CUDA。它采用统一的前端接口，针对不同硬件平台提供相应的底层实现：

PyTorch 为不同硬件平台实现了不同的计算后端，其中 CUDA 后端最为成熟。需要特别说明的是，PyTorch 并没有提供独立的 **torch.rocm** 命名空间。为了保持与现有 CUDA 生态的兼容性，在 AMD ROCm 平台上仍然使用 torch.cuda API。不同之处在于，这些 API 会根据编译目标调用对应的 GPU Runtime：在 NVIDIA 平台调用 CUDA Runtime，在 AMD ROCm 平台则调用 HIP Runtime。因此，torch.cuda.is_available()、torch.cuda.device_count() 等接口在 AMD 显卡上同样适用，绝大多数基于 PyTorch 的代码无需修改。

当执行 torch.cuda.is_available() 时，PyTorch 实际检查的是当前编译时链接的是否为 HIP Runtime，以及该 Runtime 能否成功初始化对应的 GPU 驱动。

2. ROCm：AMD 的通用计算平台

ROCm（Radeon Open Compute）是 AMD 提供的 GPU 通用计算平台，定位与 NVIDIA CUDA 类似。它包含驱动程序、运行时库、编译器工具链以及各种计算库（如 rocBLAS、rocFFT 等），是 AMD GPU 进行通用计算和 AI 训练的底层基石。

3. HIP：兼容 CUDA 编程模型的接口层，与 PyTorch 中的体现

HIP（Heterogeneous-compute Interface for Portability）是一套兼容 CUDA 编程模型的异构计算接口。它向下对接 ROCm Runtime，向上对开发者提供类似 CUDA 的编程体验。对于现有的 CUDA 项目，可以通过 hipify 工具将 CUDA API 自动转换为 HIP API，也可以直接编写原生 HIP 程序。

那么，为什么在 PyTorch 中，AMD GPU 依然使用 torch.cuda.xxx 命名空间呢？

torch.cuda.is_available()      # AMD 显卡上同样有效
torch.cuda.device_count()      # 返回 AMD GPU 数量
torch.cuda.get_device_name()   # 返回 "Radeon PRO V620"

这是因为 PyTorch 并未为 ROCm 单独设计一套 torch.rocm API。为了最大程度兼容海量现有代码，PyTorch 的"CUDA 后端"在 AMD 平台上直接复用了相同的接口命名，底层实际链接的是 HIP Runtime 而非 NVIDIA CUDA Runtime。

换言之，torch.cuda.is_available() 在 AMD 机器上检查的是 HIP Runtime 能否成功初始化。对于绝大多数纯 PyTorch 应用（如 ComfyUI、MinerU 的推理脚本），无需修改任何业务代码，即可在 NVIDIA 与 AMD 显卡之间无缝切换。这也正是本方案能够"零代码改动"直接适配这些工具的根本原因。

4. 软件栈全景图

为了让读者对整个调用链有清晰认知，这里给出完整的软件栈结构：

注：在 Windows 平台上，驱动层和运行时层的具体实现细节可能与 Linux 有所差异，但上述层次关系适用于本文讨论的范围。

5. 架构代号（gfx）与环境变量的作用

AMD 每一代 GPU 架构都有内部代号：RDNA2 对应 gfx1030，RDNA3 对应 gfx1100。V620 核心架构正是 RDNA2（gfx1030）。

需要说明的是，V620 采用的 RDNA2 属于 ROCm Windows 适配中已较为成熟的基础架构。本方案的适配逻辑（环境变量覆盖 + HIP Runtime 调度）理论上适用于 RDNA2 及此后更新的 AMD 架构（如 RDNA3 的 gfx1100、RDNA4 等）。若您手中的是 RDNA3 架构显卡（如 RX 7900 系列），同样可按本文步骤操作。只需将 HSA_OVERRIDE_GFX_VERSION 的值从 10.3.0 改为对应架构的版本号（例如 RDNA3 通常设为 11.0.0，具体请以 ROCm 官方文档或 rocminfo 检测结果为准）。本文以 gfx1030 为例展开，其他架构的适配思路完全一致。

关键点在于：**Windows 版本的 ROCm 对 gfx1030 的官方支持状态为"可能可用但未经充分验证"**（该结论源自 AMD ROCm GitHub Discussions 中开发者的说明）。为了绕过官方的硬件白名单检查，需要通过环境变量手动干预 ROCm Runtime 的行为：

**HSA_OVERRIDE_GFX_VERSION=10.3.0**：告诉 ROCm Runtime 按指定 gfx 架构（10.3.0）加载对应的 Code Object，而不是重新识别 GPU ISA。这可以绕过针对未认证 GPU 的拒绝加载逻辑。
**HIP_VISIBLE_DEVICES=0**：类似 CUDA 的可见性控制，在多卡工作站中指定使用第一块 AMD GPU。

二、实操步骤

下面进入实操。请严格按顺序执行，特别注意环境变量的配置。

1. 下载并安装 HIP SDK

访问 AMD 官方资源库，下载 Windows 专用的 HIP SDK 安装包（如 AMD-Software-PRO-Edition-26.Q1-Win11-For-HIP.exe）。

官方文档：Install HIP SDK for Windows
下载入口：AMD HIP SDK for Windows

安装过程保持默认选项即可，安装完成后建议重启系统，确保环境变量 PATH 中包含 HIP 的 bin 目录。

2. 配置关键环境变量（重中之重）

在终端（PowerShell 或 CMD）执行 PyTorch 任务之前，必须设置以下变量。为了避免每次手动输入，建议直接添加到系统环境变量中。（若您的显卡非 gfx1030 架构，请参考第一章第 5 小节末尾的说明调整 HSA_OVERRIDE_GFX_VERSION 的值。）

# PowerShell 临时设置（推荐先运行此行测试）
$env:HIP_VISIBLE_DEVICES="0"
$env:HSA_OVERRIDE_GFX_VERSION="10.3.0"

:: CMD 临时设置
set HIP_VISIBLE_DEVICES=0
set HSA_OVERRIDE_GFX_VERSION=10.3.0

注意：若您使用 PyCharm 或 VS Code 的集成终端，请确保在启动 IDE 前设置好系统环境变量，否则子进程无法继承。

常用调试环境变量

除上述两个核心变量外，以下变量在排查问题时非常有用：

**HIP_LAUNCH_BLOCKING=1**：使 GPU Kernel 同步执行，方便定位真正报错的位置，避免异步执行带来的错误信息模糊。
**TORCH_USE_HIP_DSA=1**：启用 Device Side Assert 调试，帮助定位 Kernel 内部的断言失败。

这些变量可在排查问题时临时启用，生产环境建议关闭以免影响性能。

3. 创建独立 Conda 环境并安装 ROCm 版 PyTorch

绝对不要使用 conda install pytorch，这会拉取默认的 CPU 或 CUDA 版本。当前（本文验证时），Windows + gfx103X 需要使用 ROCm PyTorch Nightly 版本。后续若 Stable 版本已支持，建议优先使用 Stable。

# 创建环境
conda create -n comfy_env python=3.12 pip -y
conda activate comfy_env

# 强制重装预发布版本的 ROCm PyTorch（关键命令）
pip install --force-reinstall --pre torch torchvision torchaudio --index-url https://rocm.nightlies.amd.com/v2-staging/gfx103X-all/

4. 验证 HIP 可用性

执行以下单行 Python 脚本，验证 GPU 是否被正确识别。

python -c "import torch; print('HIP可用性:', torch.cuda.is_available()); print('显卡名称:', torch.cuda.get_device_name(0) if torch.cuda.is_available() else '无')"

期望输出：HIP可用性: True，且显卡名称应正确显示为 Radeon PRO V620 或包含 gfx1030 字样的设备名。

重要提示：torch.cuda.is_available() 返回 True 仅表示 HIP Runtime 成功初始化，并不代表所有算子均能正常执行。部分算子可能因编译或兼容性问题失败，需结合实际模型测试。

三、翻车现场与回滚策略

如果验证输出依然是 False，按以下路径排查：

检查是否混装了 CPU 版 PyTorch：
运行 pip list | findstr torch，如果看到 torch 版本号后不带 +rocm 字样，说明装错了。必须先执行 pip uninstall torch torchvision torchaudio 彻底卸载，再重试步骤 3。
版本锁定策略：
若 Nightly 最新版运行时出现 Kernel Launch Failure、HIPRTC Compilation Error、Access Violation 等异常，说明最新二进制与当前 HIP SDK 存在 ABI 兼容性问题。此时需要回退到特定的稳定组合：

   # 示例：回退到 2.13 版本组合（具体日期号需查阅 nightly 归档）
   pip install --force-reinstall --pre torch==2.13.0a0+rocm7.14.0a20260612 torchvision==0.28.0a0+rocm7.14.0a20260612 --index-url https://rocm.nightlies.amd.com/v2-staging/gfx103X-all/

深度清理：
如果环境变量无误但仍报错，可能需要卸载所有 ROCm 相关的 pip 包（pip uninstall rocm-*），甚至重装 HIP SDK。在 Windows 上，注册表残留偶尔会导致驱动冲突。

四、适用范围与框架兼容性

本文方案适用于基于 PyTorch 的 AI 推理应用，不适用于采用其他计算后端的框架。

已验证框架及兼容性

框架 / 库	状态	说明
PyTorch（ROCm）	✅	本方案核心
torchvision	✅	常用 CV 算子支持
torchaudio	✅	可正常使用
HuggingFace Transformers	✅	大多数纯 PyTorch 模型可直接运行
ComfyUI	✅	扩散模型推理，已实际验证
MinerU	✅	文档解析（布局/OCR/公式），已实际验证
Ultralytics YOLO	✅	目标检测推理，已实际验证

特别说明： 上表反映的是本文验证环境及当前（2026 年）的社区兼容性情况。随着 ROCm Windows 和 PyTorch 的持续迭代，部分项目的支持状态可能会发生变化。

五、关于版本兼容性

Windows ROCm 仍处于快速演进阶段。影响兼容性的通常不是某一个单独组件，而是多个组件的组合：

建议读者优先保证版本组合兼容，而不是盲目升级到最新版本。具体做法是：

先查看 ROCm Windows Release Notes，了解当前官方推荐的版本组合。
选择与 HIP SDK 版本匹配的 PyTorch Nightly 版本。
若遇到问题，降级 PyTorch 而非升级 HIP SDK，后者的回滚代价更大。

六、现状与风险提示

在 Windows 上使用这套方案，有几个技术现状需要了解：

官方支持状态：ROCm 团队明确表示，其全功能工具链（rocminfo、多卡通信、容器化部署）在 Ubuntu 系统上拥有最完善的优化。Windows 版本属于"跟进支持"，gfx1030 在 Windows 上的测试覆盖度远低于 Linux。
已知的稳定性问题：根据 ROCm GitHub 论坛的社区反馈，在 gfx1030 架构上进行大规模矩阵运算时，若显存占用超过 85%，可能会触发驱动重置或 hipErrorOutOfMemory 异常。此外，部分 PyTorch 算子（如 torch.scatter）在 ROCm Windows 后端上的性能表现可能不及预期。
性能参考：目前缺少官方的 Windows 基准测试数据，但社区实测表明 V620 在推理场景中通常优于 DirectML 方案。具体性能与模型结构、算子实现、驱动版本密切相关，建议以实际测试为准。

总结：本文提供的方案是一套能用的工程化方案。它能让 AMD V620 在 Windows 下"动起来"，满足开发调试和推理需求。对比 Torch-DirectML 的兼容层损耗和 WSL2 的虚拟化 I/O 开销，原生 HIP 方案在长期运维和性能释放上有明显优势。但若要用于 7x24 小时的生产级训练任务，建议优先考虑官方支持更完善的 Linux 系统，或等待 AMD 后续驱动迭代。