程序设计实验室
微信公众号
前言
事情是这样的：我手上有一张 RX 6650 XT (gfx1032)，想在 Windows 上跑 PyTorch 做深度学习。AMD 官方的 HIP SDK for Windows 并不正式支持 gfx1032，但我还是通过自编译 ROCm 7.11.0a + PyTorch 2.9.1 把环境搭起来了。
torch.cuda.is_available() 返回 True，rocm-sdk test 也过了，Qwen3-0.6B 能加载到 GPU 上生成文本，看起来一切正常。
但跑 benchmark 的时候发现，GPU 加速只有 1.7-2.0 倍，任务管理器里 GPU 利用率也不高。这到底是怎么回事？
测试环境
| 项目 | 配置 |
|---|---|
| GPU | AMD Radeon RX 6650 XT (gfx1032) |
| ROCm | 7.11.0a / 自编译 |
| PyTorch | 2.9.1+rocm7.11.0a |
| 模型 | Qwen/Qwen3-0.6B |
| 精度 | float16 |
| 系统 | Windows 10 Pro |
Benchmark 结果
用 5 类 prompt 各跑 3 次，max_new_tokens=256：
CPU vs GPU Comparison
╔════════════════════╤══════════════╤══════════════╤════════════╗
║ Prompt │ CPU tok/s │ GPU tok/s │ Speedup ║
╟────────────────────┼──────────────┼──────────────┼────────────╢
║ Short Factual │ 16.8 │ 30.0 │ 1.8x ║
║ Summarization │ 14.8 │ 30.3 │ 2.0x ║
║ Reasoning │ 18.0 │ 30.2 │ 1.7x ║
║ Code Generation │ 18.4 │ 30.4 │ 1.7x ║
║ Long-form │ 18.0 │ 30.6 │ 1.7x ║
╚════════════════════╧══════════════╧══════════════╧════════════╝
几个直观的观察：
- GPU 路径确实有效，加速约 1.7-2.0x。
- 但这个加速比对一张独显来说，实在算不上好。
- GPU 端吞吐稳定在 ~30 tok/s，不管 prompt 类型怎么变都差不多——说明瓶颈不在 prompt 内容上。
先看 AMD 怎么说的
AMD HIP SDK for Windows 的官方支持矩阵里，RDNA2 各档的支持情况是这样的：
| GPU | 架构 | Runtime | HIP SDK |
|---|---|---|---|
| RX 6950/6900/6800 系列 | gfx1030 | ✅ | ✅ |
| RX 6750/6700 系列 | gfx1031 | ✅ | ❌ |
| RX 6650/6600 系列 | gfx1032 | ✅ | ❌ |
Runtime 支持意味着 HIP/OpenCL runtime 能跑起来；HIP SDK 不支持意味着官方预编译的 HIP SDK 库不覆盖这块硬件，运行时可能出各种问题。
这是最关键的一点：gfx1032 在 Windows 上根本不在官方 HIP SDK 支持范围内。所以即使自编译能跑，也应该对兼容性和性能有心理准备。
冒烟测试：到底哪些操作能跑在 GPU 上？
为了搞清楚 PyTorch 操作在当前环境下的实际表现，我写了一个冒烟测试脚本（tests/test_operators.py）。思路很简单：创建 CUDA/HIP tensor，执行操作，检查输出是不是还在 GPU 上。
结果：
Summary: 54/55 returned CUDA/HIP tensors | 1 errors | 1 warnings
55 个检查项里，54 个成功返回了 CUDA/HIP tensor。失败的两个：
batch_norm 报错——MIOpen 在运行时编译 kernel 的时候，HIPRTC 找不到 <type_traits> 这个 C++ 标准库头文件。这是编译环境的问题，不是 GPU 不支持。后续装上 VS Build Tools 的 C++ 工具链应该能修。但要注意，这并不意味着修好之后 BatchNorm 就一定有高性能 GPU kernel——还得复测。
sdpa 有警告——PyTorch 编译时没启用 memory efficient attention，scaled_dot_product_attention 走的是数学 fallback。功能没问题，但长序列和大 batch 场景下性能差距会比较明显。
需要强调的是，这个测试结果不能直接解读成"54/55 个算子有 GPU kernel，覆盖率 98%"。
因为检查输出 device 只能证明 PyTorch 的设备语义成立（CUDA tensor 的结果还在 CUDA 上），不能证明底层调用了什么 backend、用了什么 kernel、有没有隐式同步。
低加速比到底是什么原因？
说实话，我没有一个确定的答案。目前比较合理的判断是多个因素叠加：
自回归 decode 天生吃不满 GPU。 每次只生成一个 token，batch=1 的时候 kernel 粒度很小，launch latency 和调度开销占比就上去了。这是 LLM 推理的通病，不独属于 ROCm。
Qwen3-0.6B 太小了。 600M 参数，fp16 权重才 1.2GB。小模型在 batch=1 的 decode 阶段，瓶颈往往在内存访问和框架开销上，而不是 GPU 算力。
SDPA 没走高性能路径。 编译 warning 已经提示了，memory efficient attention 没启用。对 Transformer 模型来说这是个不小的性能因素。
Windows + gfx1032 本身就不是官方支持场景。 自编译能让操作跑起来，但 kernel 选择、库集成、性能调优这些方面，很难指望和官方支持的硬件一样。
CPU 使用率高 ≠ forward 在 CPU 上算。 任务管理器里 CPU 20% 左右的使用率，其实大部分是 Python 解释器、Transformers generation loop、tokenizer 处理、kernel launch、同步这些工作，不能直接推导出"大部分计算回退到了 CPU"。
下一步怎么查
为了进一步研究，可能还需要做这些事：
- 用
torch.profiler看 CPU 和 CUDA/HIP activity 的时间分布。 - 把 prefill 和 decode 分开计时，看瓶颈到底在哪。
- 用真实 LLM 的 tensor shape 单独测
linear、RMSNorm、RoPE、SDPA、KV cache 这些关键路径。 - 开 MIOpen/rocBLAS 日志，确认关键操作到底走了哪个库。
- 试不同 batch size，看 tok/s 曲线怎么变。
- 如果条件允许，和 Linux ROCm 或者官方支持的 RDNA3 GPU 做对比。
结论
| 问题 | 回答 |
|---|---|
| PyTorch 能在 RX 6650 XT 上跑吗？ | 自编译后可以跑基础 workload，但不在官方 HIP SDK 支持范围内 |
| 算子覆盖率是多少？ | 冒烟测试只能说 54/55 个检查项返回了 CUDA/HIP tensor，不是严格的算子覆盖率 |
| 有没有 CPU fallback 的证据？ | 目前没有。batch_norm 是编译报错，不是 fallback |
| 为什么 GPU 加速低？ | 大概率是 batch=1 自回归、小模型、attention fallback、非官方支持、框架开销这些因素叠加 |
| 大模型或大 batch 会好吗？ | 很可能，但得实测，不能从冒烟测试推断 |
| 升级新版 ROCm 有用吗？ | 可能修一些 bug，但官方支持矩阵是硬约束，gfx1032 短期内大概率不会被正式支持 |
小结
给同样想在 RDNA2 + Windows 上跑深度学习的朋友：
- 把自编译 ROCm/PyTorch 当实验环境，别当生产环境。
- 先跑冒烟测试确认常见操作不会直接报错。
- 性能问题要用 profiler 和 backend 日志定位，光看输出 device 说明不了什么。
- LLM 推理要单独分析 prefill/decode、batch size 和 attention backend。
- 如果要稳定跑、追求可预期的性能，优先考虑 Linux ROCm，或者换一张 Windows 上官方支持的 GPU。