前言

事情是这样的：我手上有一张 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 利用率也不高。这到底是怎么回事？

测试环境

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 各档的支持情况是这样的：

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"。

下一步怎么查

为了进一步研究，可能还需要做这些事：

1. 用 torch.profiler 看 CPU 和 CUDA/HIP activity 的时间分布。
2. 把 prefill 和 decode 分开计时，看瓶颈到底在哪。
3. 用真实 LLM 的 tensor shape 单独测 linear、RMSNorm、RoPE、SDPA、KV cache 这些关键路径。
4. 开 MIOpen/rocBLAS 日志，确认关键操作到底走了哪个库。
5. 试不同 batch size，看 tok/s 曲线怎么变。
6. 如果条件允许，和 Linux ROCm 或者官方支持的 RDNA3 GPU 做对比。

结论

小结

给同样想在 RDNA2 + Windows 上跑深度学习的朋友：

1. 把自编译 ROCm/PyTorch 当实验环境，别当生产环境。
2. 先跑冒烟测试确认常见操作不会直接报错。
3. 性能问题要用 profiler 和 backend 日志定位，光看输出 device 说明不了什么。
4. LLM 推理要单独分析 prefill/decode、batch size 和 attention backend。
5. 如果要稳定跑、追求可预期的性能，优先考虑 Linux ROCm，或者换一张 Windows 上官方支持的 GPU。