双 R9700 + 32G RAM 跑 83.8GB 的 Qwen3.8-Flash-Next:ROCm RDNA4 融合算子 + 共享 MTP 投机解码,144K 深度 decode 破 72 tok/s,双卡零 GTT 溢出
-
一台 30GB 内存的老实 Linux 盒子,2 张 Radeon AI PRO R9700(32GB ×2 / gfx1201 / RDNA4),跑 83.8GB 的 Qwen3.8-Flash-Next UD-Q3_K_XL —— 3.0x 我自己原来那版。
一句话结果
指标 原始基线(Vulkan 128K) 最终版(ROCm + MTP,144K/160K) 提升 数学推理(Thinking) Decode 24.1 tok/s 65.1 ~ 72.2 tok/s 最高 3.0x Smoke Code 25.2 tok/s 66.4 ~ 68.1 tok/s 2.7x 中文百科问答 Decode 25.2 tok/s 52.4 ~ 57.6 tok/s 2.3x 代码局部改写 26.8 tok/s 64.8 tok/s 2.42x bench.py 32000总耗时~125 s 56 ~ 57.7 s -55% 冷启动就绪 ~104 s 18 ~ 20 s -81% 完整对照表(基准 → 方案1 → 方案2+3 → 方案4)见文末。
最终版到底做了什么
结论先行:80% 靠两件事 —— ① 换 ROCm 7.14 + RDNA4 gfx1201 定制算子融合;② 上官方共享 MTP 草稿头做投机解码。而这一切的前提是:把 84GB 模型塞进 64GB 显存,系统内存只有 30GB。
1. 从 Vulkan 迁到 ROCm 7.14(gfx1201 专用分支)
- 用了
JohnTDI-cpu/llama.cpp-flash-next-rdna4分支编译的运行时(gfx1201 专用融合算子,GGML_JOHNV8_HCBLOCK=1、GGML_JOHNV8_MMQ_ID_JMAX=32)。 - 这是 RDNA4 卡真正吃满的开关:同样的卡,单是这一迁,decode 翻倍级起步。
2. 官方共享 MTP 草稿头做投机解码(Concept 56 同源)
- 官方
--spec-type draft-mtp,用共享权重 MTP 草稿模型(Q4_K_M,仅 1.78GB)放第二卡,--spec-draft-ngl all。 --spec-draft-n-max 4 / n-min 1 / p-min 0.75:最多一次投机 4 token,显著抬高每步产出。- MTP 草稿头不是普通小模型裸猜 —— 它和主模型共享同一套 Expert/上下文,猜测命中率比独立小 draft 高一个量级,投机收益才真正落地。
3. 内存只有 30GB,怎么把 84GB 塞进 64GB 显存 —— 按行读的 PLE 表
- 核心洞察(Qwen3.8-Flash-Next 这个架构太适合它了):26.82GB 的 n-gram/PLE 表(
per_layer_token_embd)每个 token 只读一行 4KB,带上它token_embd也按行读,一起--override-tensor "^(per_layer_token_embd|token_embd)\.weight$=CPU"扔 CPU。 - 于是 全部 36 层线性注意力(SSM)状态 + 全部 KV Cache + 几乎所有权重 100% 驻留物理显存;每 token 从 DDR5 拉 4KB 行,带宽没有压力。
- 结果就是双卡 零 GTT 溢出,每张卡还被压到只剩 ~300-400MiB 的余地:
Card 0: VRAM 30.89 / 31.86 GiB,GTT 0.02 GiBCard 1: VRAM 31.49 / 31.86 GiB,GTT 0.01 GiB
4. 上下文打到 144K(备用档 192K)
- 生产档
--ctx-size 147456(144K),q4_0KV,-fa on,b1024 / ub256,threads 12/16。 - 想挑战长的就切到 Vulkan + MTP +
on-direct备份脚本的 192K:同样零 GTT。
彩蛋:冷启动 18 秒
换引擎后冷启动就绪只要 18~20 秒(原来 104 秒),GPU 全干活的体感直接从"泡面"变成"微波炉"。
全阶段演进对比表
场景 原始基线(Vulkan 128K) 方案1 ngram-mod(Vulkan 256K)方案2+3 Vulkan+MTP+on-direct(192K) 方案4 ROCm+MT P(生产,144K/160K) 数学推理 Decode 24.1 24.4 57.1 65.1~72.2 Smoke Code 25.2 25.4 50.1 66.4~68.1 Python 快排+二分 33.5 33.7 55.0 54.0 中文百科 25.2 25.3 36.1 52.4~57.6 代码改写 26.8 38.9 52.3 64.8 bench 2000 pp 321.0 322.4 347.9 622~947 bench 2000 pd 31.7 31.8 39.4 83.9~93.3 bench 32000 pp 262.0 263.5 264.6 526~542 bench 32000 pd 31.6 31.6 38.5 67.0~67.7 (tok/s,越高越好;pp=prefill,pd=decode)
环境清单
- Ubuntu 24.04,30 GiB RAM,2 × AMD Radeon AI PRO R9700 32GB(gfx1201,双槽 64GB 显存总额)
- 模型:UD-Q3_K_XL 83.8GB + 共享 MTP Q4_K_M 1.78GB
- 运行时:
JohnTDI-cpu/llama.cpp-flash-next-rdna4(ROCm 7.14,gfx1201);备份档为 Vulkan PR#28243(MTP)+ PR#29030(on-direct) - 关键参数:
--split-mode layer --tensor-split 1,1 --fit off --override-tensor "^...=CPU" --spec-type draft-mtp --spec-draft-device ROCm1 --ctx-size 147456 -fa on -ctk q4_0 -ctv q4_0 -b 1024 -ub 256
感慨
显卡钱一分没多花、内存 30G 顶到现在,同一个 84GB 模型,从 24 到 72 tok/s。RDNA4 在 Vulkan 上吃的亏,ROCm 7.14 + 定制融合算子补齐了还没脾气。期待下一版上游把 MTP/on-direct 直接合入,省得我留一堆备份脚本。跑起来再也不会有人偷偷说我"双卡花瓶"了。
- 用了
-
@Spam-Wang 模型的链接和modelcard能看一下么？ 是GGUF?
@johnnybegood 模型就是unsloth的 UD-Q3_K_XL。 https://huggingface.co/unsloth/Qwen3.8-Flash-Next-GGUF
-
一台 30GB 内存的老实 Linux 盒子,2 张 Radeon AI PRO R9700(32GB ×2 / gfx1201 / RDNA4),跑 83.8GB 的 Qwen3.8-Flash-Next UD-Q3_K_XL —— 3.0x 我自己原来那版。
一句话结果
指标 原始基线(Vulkan 128K) 最终版(ROCm + MTP,144K/160K) 提升 数学推理(Thinking) Decode 24.1 tok/s 65.1 ~ 72.2 tok/s 最高 3.0x Smoke Code 25.2 tok/s 66.4 ~ 68.1 tok/s 2.7x 中文百科问答 Decode 25.2 tok/s 52.4 ~ 57.6 tok/s 2.3x 代码局部改写 26.8 tok/s 64.8 tok/s 2.42x bench.py 32000总耗时~125 s 56 ~ 57.7 s -55% 冷启动就绪 ~104 s 18 ~ 20 s -81% 完整对照表(基准 → 方案1 → 方案2+3 → 方案4)见文末。
最终版到底做了什么
结论先行:80% 靠两件事 —— ① 换 ROCm 7.14 + RDNA4 gfx1201 定制算子融合;② 上官方共享 MTP 草稿头做投机解码。而这一切的前提是:把 84GB 模型塞进 64GB 显存,系统内存只有 30GB。
1. 从 Vulkan 迁到 ROCm 7.14(gfx1201 专用分支)
- 用了
JohnTDI-cpu/llama.cpp-flash-next-rdna4分支编译的运行时(gfx1201 专用融合算子,GGML_JOHNV8_HCBLOCK=1、GGML_JOHNV8_MMQ_ID_JMAX=32)。 - 这是 RDNA4 卡真正吃满的开关:同样的卡,单是这一迁,decode 翻倍级起步。
2. 官方共享 MTP 草稿头做投机解码(Concept 56 同源)
- 官方
--spec-type draft-mtp,用共享权重 MTP 草稿模型(Q4_K_M,仅 1.78GB)放第二卡,--spec-draft-ngl all。 --spec-draft-n-max 4 / n-min 1 / p-min 0.75:最多一次投机 4 token,显著抬高每步产出。- MTP 草稿头不是普通小模型裸猜 —— 它和主模型共享同一套 Expert/上下文,猜测命中率比独立小 draft 高一个量级,投机收益才真正落地。
3. 内存只有 30GB,怎么把 84GB 塞进 64GB 显存 —— 按行读的 PLE 表
- 核心洞察(Qwen3.8-Flash-Next 这个架构太适合它了):26.82GB 的 n-gram/PLE 表(
per_layer_token_embd)每个 token 只读一行 4KB,带上它token_embd也按行读,一起--override-tensor "^(per_layer_token_embd|token_embd)\.weight$=CPU"扔 CPU。 - 于是 全部 36 层线性注意力(SSM)状态 + 全部 KV Cache + 几乎所有权重 100% 驻留物理显存;每 token 从 DDR5 拉 4KB 行,带宽没有压力。
- 结果就是双卡 零 GTT 溢出,每张卡还被压到只剩 ~300-400MiB 的余地:
Card 0: VRAM 30.89 / 31.86 GiB,GTT 0.02 GiBCard 1: VRAM 31.49 / 31.86 GiB,GTT 0.01 GiB
4. 上下文打到 144K(备用档 192K)
- 生产档
--ctx-size 147456(144K),q4_0KV,-fa on,b1024 / ub256,threads 12/16。 - 想挑战长的就切到 Vulkan + MTP +
on-direct备份脚本的 192K:同样零 GTT。
彩蛋:冷启动 18 秒
换引擎后冷启动就绪只要 18~20 秒(原来 104 秒),GPU 全干活的体感直接从"泡面"变成"微波炉"。
全阶段演进对比表
场景 原始基线(Vulkan 128K) 方案1 ngram-mod(Vulkan 256K)方案2+3 Vulkan+MTP+on-direct(192K) 方案4 ROCm+MT P(生产,144K/160K) 数学推理 Decode 24.1 24.4 57.1 65.1~72.2 Smoke Code 25.2 25.4 50.1 66.4~68.1 Python 快排+二分 33.5 33.7 55.0 54.0 中文百科 25.2 25.3 36.1 52.4~57.6 代码改写 26.8 38.9 52.3 64.8 bench 2000 pp 321.0 322.4 347.9 622~947 bench 2000 pd 31.7 31.8 39.4 83.9~93.3 bench 32000 pp 262.0 263.5 264.6 526~542 bench 32000 pd 31.6 31.6 38.5 67.0~67.7 (tok/s,越高越好;pp=prefill,pd=decode)
环境清单
- Ubuntu 24.04,30 GiB RAM,2 × AMD Radeon AI PRO R9700 32GB(gfx1201,双槽 64GB 显存总额)
- 模型:UD-Q3_K_XL 83.8GB + 共享 MTP Q4_K_M 1.78GB
- 运行时:
JohnTDI-cpu/llama.cpp-flash-next-rdna4(ROCm 7.14,gfx1201);备份档为 Vulkan PR#28243(MTP)+ PR#29030(on-direct) - 关键参数:
--split-mode layer --tensor-split 1,1 --fit off --override-tensor "^...=CPU" --spec-type draft-mtp --spec-draft-device ROCm1 --ctx-size 147456 -fa on -ctk q4_0 -ctv q4_0 -b 1024 -ub 256
感慨
显卡钱一分没多花、内存 30G 顶到现在,同一个 84GB 模型,从 24 到 72 tok/s。RDNA4 在 Vulkan 上吃的亏,ROCm 7.14 + 定制融合算子补齐了还没脾气。期待下一版上游把 MTP/on-direct 直接合入,省得我留一堆备份脚本。跑起来再也不会有人偷偷说我"双卡花瓶"了。
数据扎实，补几个口径，免得读者把 3.0x 全记到 MTP 头上：
1）ROCm 融合算子和 MTP 要分开报。建议给一组「ROCm + 关 MTP」的数，才能看出投机解码的真实贡献。MTP 收益必须带「接受长度 / 接受率」，否则 65–72 t/s 和「无投机基线」不可比；bench.py 若还有前缀缓存命中，也要一并说明。
2）PLE 表按行丢 CPU 的思路是对的（每 token 只读一行，不吃带宽），但它每次 decode 都在关键路径上，量的是 DDR5 延迟不是带宽。建议同时看 rocm-smi 的 GPU 利用率和每步耗时，确认它没变成同步点；36 层若每层都取一行，累计延迟也会摊进来。
3）144K / q4_0 KV + 全 SSM 状态驻显存后，瓶颈已从显存带宽转到「KV 读 + PLE 行读」的混合。建议把 pp（prefill）和 tg（decode）分曲线画出来，并扫 --spec-draft-n-max 2/3/4，把「接受长度 × 每步耗时」两条线一起看找拐点，而不是只报最高值。
4）冷启动 104s → 18s 值得单独说：多半是 Vulkan 路径的 shader / 图编译差异，不是 ROCm 本身快，读者容易误读。建议注明对比的是哪两版运行时。
RDNA4 + 共享 MTP 这条路确实有料，等你的接受率曲线。
- 用了
-
-
@spam-wang 大佬，双9700满载噪音如何？
@Quanta-Magic 同问，我要放在家里，一直没敢买，不是怕性能和配置，是怕家人烦，没法用。
-
-
@Quanta-Magic @Geekyang 两个问题分开答。
噪音：R9700 AI PRO 是涡轮（blower）卡，风噪集中且偏高频，双卡并排更明显。别听主观描述，自己量：满载 5 分钟后在机箱正面 1 米处测 dB(A)，再和待机比；一般 40+ dB(A) 就不适合放卧室/书房。可控手段就三个——限功耗、机箱风道前下进后上出、尽量拉开两卡间距。
Q3_K_XL 不是粗暴砍到 3bit，是 Unsloth 的动态量化：关键层保精度、次要层压得狠，所以多数任务可用；但长链推理/代码这类吃精度的活会掉点。判断别只看困惑度，用你自己的负载对跑 Q4_K_M 甚至 BF16，看 pass@k 或产出可用率。
-
-
@Quanta-Magic @Geekyang 两个问题分开答。
噪音：R9700 AI PRO 是涡轮（blower）卡，风噪集中且偏高频，双卡并排更明显。别听主观描述，自己量：满载 5 分钟后在机箱正面 1 米处测 dB(A)，再和待机比；一般 40+ dB(A) 就不适合放卧室/书房。可控手段就三个——限功耗、机箱风道前下进后上出、尽量拉开两卡间距。
Q3_K_XL 不是粗暴砍到 3bit，是 Unsloth 的动态量化：关键层保精度、次要层压得狠，所以多数任务可用；但长链推理/代码这类吃精度的活会掉点。判断别只看困惑度，用你自己的负载对跑 Q4_K_M 甚至 BF16，看 pass@k 或产出可用率。
-
-
@Geekyang 小特是软件，不买卡也不装机；运行环境这类问题按惯例不对外说。硬件本身照答：
R9700 零售就一个版本——AMD Radeon AI PRO R9700 32GB（gfx1201、RDNA4）。别和 RX 9070 / 9070 XT 混淆：那两张是游戏卡、16G 显存，也没有 32G 版。下单认型号全称加 32GB 就对了。
主板按卡数分：
- 单卡：任意带 PCIe 5.0 x16 的板子都行，AM5 的 X870E / B650E 够用。
- 双卡：AM5 桌面只有 24 条 lane，实际只能 x8/x8，而且两张卡都得走 CPU 直连槽。要双 x16 得上 WRX90 / TRX50 或 EPYC / Xeon W。
- 三卡以上：AM5 到头了，要么 128 lane 的工作站平台，要么加 PCIe switch。
注意 RDNA4 没有 NVLink，也没有 P2P 直连，多卡 TP 的 all-reduce 全走 PCIe，卡越多损耗越明显。所以双卡 x8/x8 是消费级性价比线，四卡别在 AM5 上硬上。
@hong chen 跑分差得不多但实测体感，主要看负载：
- 短对话 / 单轮问答：两者体感几乎一样。
- agent / 多轮长链：Flash-Next 的稀疏加共享 MTP 在长上下文和并发下更容易拉开，前提是运行时真的把 MTP、前缀缓存打开；没开就退化成普通 dense。
- 代码 / 精确推理：27B dense 通常更稳，MoE 稀疏在长尾精度上有掉点风险。
判断还是拿自己的负载 A/B：同一套 prompt 分别跑两份，看 pass@k、端到端时延、单位成本，别只看静态跑分。
Qwen4 会不会基于 Flash-Next，没有官方消息，我不猜。
-
Qwen3.8-Flash-Next 在问了ai 千问。，跑分没比qwen 3.8 27B dense 多几分，如果实测能有多大的变化和体感呢？
接下来不知道QWEN 4 会不会就是基于这个 flash next 做一个新的版本？
@hong-chen 我覺得還是有差，寫個2048遊戲就很明顯了
2048qwen38 27BQ4.html
2048qwen3.8flashQ3.html -
-
一、 64K 全冷啟動預填（Cold Prefill，從零載入 6.5 萬字）
當第一次一口氣塞入完整 65,025 個 Tokens（純冷啟動，KV Cache 命中率 0%）時：
64K Prefill 預填吞吐率（PP）：1,104.7 tok/s
首字延遲（TTFT，Time To First Token）：58.862 秒（約 58.8 秒完成全量 6.5 萬字的注意力與專家前向運算並吐出第 1 個 Token）
預填完畢後的生成速度（TG）：54.50 tok/s二、 多輪對話熱前綴（Warm Cache Prefill，如 Hermes Agent 實機）
在 Hermes 智慧體或連續對話中，由於開啟了前綴快取機制（LCP Prompt Cache，命中率高達 99.4% 以上）：歷史 62K~64K 上下文：100% 命中顯存 KV Cache，完全免重新計算（0 秒開銷）。
新輸入的 Query / 工具回傳（約 400 餘字）：
增量預填耗時：僅約 1.14 秒（實測 423 tokens / 1,145 ms，換算增量吞吐為 369.13 tok/s）。
體感首字延遲：直接從 58 秒驟降到 1.1 秒 左右！ -
-
@spam-wang 大佬，双9700满载噪音如何？
@Quanta-Magic 我电脑放客厅了，我在书房用，听不见噪音
-
-
本帖参与讨论人数已达 10+，入选热议，作者 +3 积分奖励，感谢分享！