AMD 自家的 ROCm，推理时居然跑不过 Vulkan？真正的反转在这里
本文来源： 虾搞代码（公众号：虾搞代码）
原文链接： https://mp.weixin.qq.com/s/ZQbvZlT5xmcbzre-LtHgEg
发布时间： 2026-10-09 11:08
作者： 虾搞代码 发布时间： 2026-10-09 11:08
如果你给 AMD 显卡跑本地大模型，直觉大概是：自家 ROCm，亲生的；Vulkan，跨平台的。亲儿子总该跑得快吧？
偏偏有社区测试记录了一个反直觉场面：在特定 Strix Halo 设备、模型和定制推理引擎下，Vulkan 路径的持续生成速度超过 ROCm 路径。先别急着替 ROCm 写讣告。同一组讨论还指出，长提示词的预填充，ROCm 可能更占优。
这不是一场“谁才是 AMD 真爱”的家庭伦理剧，而是一堂关于推理瓶颈的公开课。
同叫“推理”，其实有两场考试
你问模型一个问题，它先读完提示词，再一个字、一个字往外写。前一段叫预填充，后一段叫解码。
预填充像一次性批改整摞试卷，大块矩阵计算多；解码像每写一个字就把厚厚的模型权重翻一遍，常常受内存带宽、量化算子和调度开销牵制。
所以，某个后端“读题快”，完全可能另一个后端“写答案快”。只晒一张 tok/s 截图就宣布冠军，多少有点像只考百米冲刺，却给人颁马拉松奖杯。
ROCm 是亲儿子，为什么还会输？
ROCm 是 AMD 的 GPU 计算软件栈，提供 HIP、运行时和数学库等工具。Vulkan 是跨厂商图形与计算接口；本地推理项目可以通过 Vulkan 后端，把计算送到 AMD GPU。
但真正跑模型的，不是接口名字，而是这款模型的这些算子，在这个版本里怎么写、怎么编译、怎么搬数据。
拿量化模型来说，权重压成 4 位以后，GPU 得先解包，再计算。某条 Vulkan 路径若恰好对这种量化格式、矩阵指令和线程布局做了针对性优化，ROCm 路径若走了不同实现，结果就可能反转。换一个模型、驱动或后端版本，名次又可能交换。
更何况，Strix Halo 这类设备使用统一内存：装得下大模型是一回事，让每个 token 高效流过内存和计算单元，是另一回事。硬件归 AMD 所有，不等于每条软件路径都自动拿到满分。
真正容易被跑分“碰瓷”的，是测试条件
看到“Vulkan 比 ROCm 快”，先问六件事：
同一台机器吗？同一模型和量化文件吗？同一推理引擎版本吗？上下文与 KV Cache 配置一样吗？是否都开启了 MTP 等推测解码？比的是预填充、单路生成，还是多人并发？
这里最容易藏着“魔术机关”的是 MTP。它让模型先猜接下来的多个 token，再批量验证。猜中得多，速度可能明显上升；猜错得多，验证成本反而拖后腿。把一边的 MTP 成绩拿去打另一边的普通解码，公平程度约等于骑电动车参加步行比赛。
社区里关于 Vulkan 解码占优的记录，涉及 Linux、Mesa RADV Wave64、定制量化和定制引擎。它不能直接套到 Windows 上游版 llama.cpp，更不能推导出“所有 AMD 显卡的 ROCm 都不如 Vulkan”。
这件事对 AMD 用户有什么用？
很简单：按自己的任务选后端，别按出身选。
长文档问答，重点看提示词处理速度和首字等待时间；本地聊天或代码续写，重点看持续生成 tok/s；多人同时用，还要看总吞吐和延迟。测试时固定模型、量化、提示词、输出长度与采样参数，分别记下预填充和解码结果，连续跑几轮。
更长远的变化也藏在这里：一个跨平台后端在某个场景跑赢，会吸引更多人复测、提交优化，再推动另一条路径追赶。开源推理软件的进步，常常就是这样被一张“不讲武德”的成绩单催出来的。但每次升级都可能改写排名，今天的截图不是明年的购机指南。
ROCm 与 Vulkan 的胜负，不该靠姓氏决定。下次看到“亲儿子输了”，最有价值的问题是：它究竟输在读题、写字，还是测试的人悄悄换了卷子？
395经本地测试，Vulkan在decode上确实略胜于ROCm。
资料与说明：本文讨论的社区案例来自q38rocm 项目及本地既有资料整理；ROCm 定义参考AMD 官方文档。
本文转载自微信公众号「虾搞代码」，仅供学习交流使用。
觉得内容不错？我要
