hipEngine：面向RDNA3（Strix Halo、7900 XTX）的快速原生Qwen 3.6推理引擎

几周前，在完成[FastDMS](https://www.reddit.com/r/LocalLLaMA/comments/1t3vlrx/fastdms_64x_kvcache_compression_running_faster/)后，我开始尝试编写一些RDNA3内核，看看能让Qwen 3.6 MoE跑多快。结果相当不错，所以在过去几周里，我把这些实验变成了[hipEngine](https://github.com/shisa-ai/hipEngine)——一个新的开源（AGPLv3）ROCm原生本地LLM推理引擎。它基于Python，但没有依赖庞大的PyTorch。所有热路径都是用HIP/C++编写的，大量使用了AMD原生库如hipBLASLt、hipGraph、AOTriton等。 ### gfx1100（Radeon RX 7900 XTX / Radeon Pro W7900） 初始实现中，Qwen 3.6（MoE和密集模型）的性能与llama.cpp相当，其中[ParoQuant](https://github.com/shisa-ai/paroquant)（我也已将其移植为ROCm兼容）的4.68bpw在gfx1100（W7900/7900 XTX）上，在所有测试的上下文长度（512-128K）下，c=1预填充（“提示处理”）表现更优： ### 预填充 tok/s | 工作负载 | hipEngine PARO | hipEngine GGUF Q4_K_S | llama.cpp HIP | llama.cpp Vulkan | | --- | ---: | ---: | ---: | ---: | | 512/128 | **2718.497** | 2258.847 | 2436.049 | 1816.927 | | 4K/128 | **2838.773** | 2576.673 | 2176.905 | 1705.093 | | 32K/128 | **2074.699** | 1893.967 | 1496.409 | 1128.554 | | 128K/128 | **1055.454** | 998.143 | 710.213 | 480.539 | ### 解码 tok/s | 工作负载 | hipEngine PARO | hipEngine GGUF Q4_K_S | llama.cpp HIP | llama.cpp Vulkan | | --- | ---: | ---: | ---: | ---: | | 512/128 | 103.460 | 109.152 | 85.487 | **127.515** | | 4K/128 | 101.964 | 100.048 | 87.375 | **120.163** | | 32K/128 | 90.438 | 86.774 | 76.994 | **98.073** | | 128K/128 | 59.598 | 57.954 | 57.341 | **64.478** | ### 峰值 GiB | 工作负载 | hipEngine PARO | hipEngine GGUF Q4_K_S | llama.cpp HIP | llama.cpp Vulkan | | --- | ---: | ---: | ---: | ---: | | 512/128 | 20.962 | 25.108 | 21.125 | **20.844** | | 4K/128 | 21.906 | 25.108 | 21.197 | **20.969** | | 32K/128 | 22.016 | 25.108 | 21.738 | **21.533** | | 128K/128 | **22.122** | 25.108 | 23.605 | 23.596 | 在128K时，其峰值内存使用率也是最低的。hipEngine还拥有近乎无损的INT8 KVCache（几乎没有速度损失），这意味着你可以在RDNA3上用<24GB（例如在专用7900 XTX上）以良好性能运行完整的Qwen 3.6 256K上下文窗口： | 模型 | 上下文 | KV缓存 | 采样峰值 | 分配器峰值 | 保留KV | 预填充 | 解码 | | -------------------- | ------: | -------- | -----------: | -------------: | ----------: | -----------: | ---------: | | Qwen3.6 35B-A3B PARO | 128K | BF16 | 21.04 GiB | 21.88 GiB | 2.69 GiB | 1091.9 tok/s | 62.2 tok/s | | Qwen3.6 35B-A3B PARO | 128K | INT8 | 19.80 GiB | 20.89 GiB | 1.36 GiB | 1076.5 tok/s | 60.0 tok/s | | Qwen3.6 35B-A3B PARO | 256K | INT8 | 21.96 GiB | 23.71 GiB | 2.71 GiB | 670.2 tok/s | 40.3 tok/s | ## gfx1151（AMD Ryzen AI MAX+ 395 / Radeon 8060S） 我目前没有专用的Strix Halo机器来打磨内核，但我很高兴地说，仅经过最小的针对性优化，它在gfx1151上已经相当快了： ### 预填充 tok/s | 工作负载 | hipEngine PARO | llama.cpp HIP | llama.cpp Vulkan | | --- | ---: | ---: | ---: | | 512/128 | 983.206 | **1058.738** | 638.008 | | 4K/128 | **1029.402** | 1004.220 | 595.400 | | 32K/128 | **792.296** | 735.534 | 407.984 | | 128K/128 | **413.489** | 376.070 | 181.453 | ### 解码 tok/s | 工作负载 | hipEngine PARO | llama.cpp HIP | llama.cpp Vulkan | | --- | ---: | ---: | ---: | | 512/128 | **62.060** | 50.537 | 57.615 | | 4K/128 | **63.605** | 49.379 | 55.027 | | 32K/128 | **50.629** | 43.435 | 44.576 | | 128K/128 | 30.245 | **31.286** | 26.935 | ## GGUF 你可能会在gfx1100表中注意到，hipEngine*现在*也初步支持GGUF。我本以为这很容易添加（其实不然，比预期多花了几天时间，背景中嗡嗡运行着数十亿缓存的智能体编码token），但我已经将Q4_K_M和Q4_K_S带入了“足够好”的初始状态——速度上略落后于ParoQuant路径，但它打开了未来的兼容性，并且不需要任何自定义训练（ParoQuant模型量化可能需要*数天*）。 ## 实现说明 hipEngine主要是作为一个有趣的副线/实验打包的，但受DS4启发，它似乎足够有用，可以打包并分享给任何RDNA3用户。它被设计为允许扩展到不同的模型架构（接下来可能是Gemma 4或StepFun 3.5），以及不同的硬件。我还分享了一些`docs/`给感兴趣的人： - `KERNELS.md` - 这是100多个自定义内核的列表，包括融合和非融合内核（以及CPU参考预测），用于正确性检查 - `ROOFLINE.md`和`ROOFLINE-gfx1151.md` - 面向AMD GPU爱好者，这是我决定走这条路的部分原因，因为理论上有太多性能潜力可挖掘，尽管即使减少了内核启动和多次迭代，事实证明—— - `LESSONS-LEARNED.md` - 一些关于优化过程中哪些有效、哪些无效的笔记。 我鼓励任何有兴趣的人四处看看，查阅文档，生成自己的代码/优化等，但关于hipEngine代码库有几点特别需要注意： hipEngine采用AGPLv3许可——这是一个强Copyleft许可。任何人都可以自由使用和修改，但如果你重新分发其任何部分，你必须以相同方式共享。 另外，虽然这篇文章完全由手动输入文本框，但内核优化是数百（数千？）轮AI辅助生成的结果，不适合被那些有严格反AI政策的代码库使用/采用。 注意：这是非常早期的代码——所有数值都经过了仔细测试，模型推理对我来说表现良好，但如果你尝试安装它，遇到HIP/ROCm问题时，你可能需要使用AI代理来帮助解决。