ROCm on Windows 性能排查：RX 6650 XT 跑 PyTorch，为什么加速不明显？

事情是这样的我手上有一张 RX 6650 XT (gfx1032)想在 Windows 上跑 PyTorch 做深度学习。AMD 官方的 HIP SDK for Windows 并不正式支持 gfx1032但我还是通过自编译 ROCm 7.11.0a PyTorch 2.9.1 把环境搭起来了。torch.cuda.is_available()返回Truerocm-sdk test也过了Qwen3-0.6B 能加载到 GPU 上生成文本看起来一切正常。但跑 benchmark 的时候发现GPU 加速只有 1.7-2.0 倍任务管理器里 GPU 利用率也不高。这到底是怎么回事测试环境#项目配置GPUAMD Radeon RX 6650 XT (gfx1032)ROCm7.11.0a / 自编译PyTorch2.9.1rocm7.11.0a模型Qwen/Qwen3-0.6B精度float16系统Windows 10 ProBenchmark 结果#用 5 类 prompt 各跑 3 次max_new_tokens256CPU 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架构RuntimeHIP SDKRX 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 warnings55 个检查项里54 个成功返回了 CUDA/HIP tensor。失败的两个batch_norm 报错——MIOpen 在运行时编译 kernel 的时候HIPRTC 找不到type_traits这个 C 标准库头文件。这是编译环境的问题不是 GPU 不支持。后续装上 VS Build Tools 的 C 工具链应该能修。但要注意这并不意味着修好之后 BatchNorm 就一定有高性能 GPU kernel——还得复测。sdpa 有警告——PyTorch 编译时没启用 memory efficient attentionscaled_dot_product_attention走的是数学 fallback。功能没问题但长序列和大 batch 场景下性能差距会比较明显。需要强调的是这个测试结果不能直接解读成54/55 个算子有 GPU kernel覆盖率 98%。因为检查输出 device 只能证明 PyTorch 的设备语义成立CUDA tensor 的结果还在 CUDA 上不能证明底层调用了什么 backend、用了什么 kernel、有没有隐式同步。低加速比到底是什么原因#说实话我没有一个确定的答案。目前比较合理的判断是多个因素叠加自回归 decode 天生吃不满 GPU。每次只生成一个 tokenbatch1 的时候 kernel 粒度很小launch latency 和调度开销占比就上去了。这是 LLM 推理的通病不独属于 ROCm。Qwen3-0.6B 太小了。600M 参数fp16 权重才 1.2GB。小模型在 batch1 的 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 加速低大概率是 batch1 自回归、小模型、attention fallback、非官方支持、框架开销这些因素叠加大模型或大 batch 会好吗很可能但得实测不能从冒烟测试推断升级新版 ROCm 有用吗可能修一些 bug但官方支持矩阵是硬约束gfx1032 短期内大概率不会被正式支持小结#给同样想在 RDNA2 Windows 上跑深度学习的朋友把自编译 ROCm/PyTorch 当实验环境别当生产环境。先跑冒烟测试确认常见操作不会直接报错。性能问题要用 profiler 和 backend 日志定位光看输出 device 说明不了什么。LLM 推理要单独分析 prefill/decode、batch size 和 attention backend。如果要稳定跑、追求可预期的性能优先考虑 Linux ROCm或者换一张 Windows 上官方支持的 GPU。