R9700 - vllm radiance 分支
-
我买r9700 之前 感觉r9700 在论坛很火 radiance, paiton 都很高讨论度
我就跑去买了r9700
但是买了过后 vllm 27b 好像被strata 抢完风头了但是最近radiance 分支也一直在进步
所以发起一个帖 看有没有人还在用 vllm radiance首先为什么我不用paiton, 其中一个原因 是paiton 是闭源引擎
再来paiton 好像只支持65k，纯文字 200k
而且质量 radiance 好像也比paiton 差一丢丢
paiton 唯一的好处就是快(paiton QNF vs strata 也同理)昨天 vllm-sly-radiance 分支更新了 Cactus dflash 检查逻辑
进一步把decode 推高但是用下来我遇到一个问题
vLLM 在 R9700 上连续运行很久后，偶尔会出现解码速度减半的情况，重启服务即可恢复，测速前最好先确认运行时长。这个现象社区也有报告：ROCm/TheRock#9228（2026-06 起，仍未关闭）
以下由ai总结 基本上就是数据 有兴趣可以继续看
一、一句话总结
- 单请求解码：代码约 185 tok/s，英文约 96~100，中文对话约 56~60，中文散文约 47~52（采样，temperature 1.0）。
- 4 路并发：代码总吞吐 515 tok/s（单请求的 2.8 倍），四种内容混合 163 tok/s。
- Prefill：19K 约 2,400 tok/s，43K 约 2,150 tok/s。
- 单请求上下文 200K，带图片；KV 池 40 万 token，可同时放下约 2 个 200K 请求。
二、硬件
部件 配置 显卡 AMD Radeon AI PRO R9700，32 GB GDDR6（RDNA4，gfx1201） 功耗 限 210 W（默认 300 W；解码受显存带宽限制，210 W 基本不掉速） PCIe 卡本身 PCIe 5.0 x16；主板是 PCIe 4.0，实际到 CPU 约 28 GB/s CPU AMD EPYC 7452，32 核（Zen 2） 内存 256 GB DDR4-2666 ECC RDIMM，8 通道（约 139 GB/s） 主板 华南 H12D-8D 系统 / 驱动 Ubuntu 24.04，内核 6.8.0-142；amdgpu DKMS 6.16.13（ROCm 7.2.4 的驱动包） 四、模型
项 配置 主模型 amd/Qwen3.8-27B-Quark-AWQ-MXFP4（约 19 GB）权重量化 Quark MXFP4（4-bit），矩阵乘用 Radiance 的 W4A8 内核（ RADIANCE_MXFP4_W4A8=1）其他省显存 输出头（lm_head）和词嵌入表用 int4（ RADIANCE_LMHEAD_INT4=1、RADIANCE_EMBED_BITS=4），省下的显存给 KV视觉 开：每个请求 1 张图，最大约 100 万像素，不支持视频 五、KV 缓存与上下文
项 配置 KV 类型 fp8（16 个全注意力层）；线性注意力层（GDN/Mamba 状态）用 bf16 KV 池 401,454 token（200K 请求可同时放约 1.96 个） 单请求最大上下文 204,800 token（200K；模型原生 262,144，开视觉后选 200K 留足 KV） 长上下文验证 192K 大海捞针：找到 为什么不用 4-bit KV：
- MXFP4 做 KV： Radiance 自己测过（MXFP4 块大小 32/16、INT4 等），注意力误差约是 fp8 的 2.8 倍，没通过他们的质量门槛，所以不提供。
- TetraAttention 4-bit KV（1.5.0 起可选，
--kv-cache-dtype int4_per_token_head）：我实测 KV 池 64.4 万（+60%），prefill +7~8%，但精度降低后草稿接受变少，解码反而慢：贪心中文散文 −32%，英文 −10~12%。所以保持 fp8。
六、草稿模型与草稿接受
项 配置 草稿模型 DFlash2： syvai/Qwen3.8-27B-DFlash2-W4A16（约 1.2 GB）每步草稿 7 个 token（ num_speculative_tokens 7），按概率采样草稿（draft_sample_method probabilistic）草稿接受 Cactus 开（ RADIANCE_CACTUS_DELTA=0.5，1.5.1 默认）实测接受情况（每步平均产出 token；最多 8 = 1 + 7 个草稿）：
内容 Cactus 关 Cactus 开 草稿接受率（开） 中文散文 1.70 1.71~1.90 ~10~13% 中文对话 1.79 2.06~2.15 ~15% 英文技术 2.89 3.40~3.54 ~35% 写代码 6.21 6.39~6.56 ~77% 七、性能
1. 单请求解码（tok/s，1,024 token 输出，中位数）
内容 采样，Cactus 关（1.3.2） 采样，Cactus 开（1.5.1） 贪心（temperature 0） 中文散文 46.3 47.4~51.6 63.2 中文对话 50.0 56.4~60.2 50.4 英文技术 81.6 96.0~100.0 86.1 写代码 175.8 184.8~185.9 187.1 （采样每次生成的文字不同，所以给出两次测量的范围。）
2. 并发（采样，每路 1,024 token，3 次中位数）
并发 代码：每路 代码：总吞吐 混合内容：每路 混合内容：总吞吐 首 token 1 186.6 182 47.3 47 0.1 s 2 171.3 329（1.8 倍） 46.2 88 0.1~0.2 s 4 138.8 515（2.8 倍） 82.0 163 0.1~0.2 s - "代码"是 4 个不同的写代码题。"混合内容"是中文散文、中文对话、英文、代码各一题；并发 1 时只有中文散文，并发 2 时是散文加对话，并发 4 时四种都有。
- 4 路混合时各路速度：中文散文 53.5、中文对话 50.7、英文 94.5、代码 154.8。
- 并发时每路会变慢（代码从 187 降到 139），但总吞吐上升很多；4 路时草稿接受基本不变（代码每步 6.3 token）。
- 贪心模式结果相近：代码 4 路总吞吐 501，混合 150。
3. Prefill（冷启动，不命中缓存）
提示长度 tok/s 19K 2,705~2,738 43K 2,304~2,403 并发 prefill（冷启动，同时发出，每个请求只生成 1 个 token）：
同时请求数 每个请求长度 总 prefill（tok/s） 每个请求的首 token 时间 1 ~19K 2,570 7.5 s 2 ~19K 2,542 7.5 / 15.1 s 4 ~19K 2,478 7.7 / 15.4 / 23.2 / 31.0 s 1 ~43K 2,172 19.8 s 2 ~43K 2,174 20.1 / 39.6 s 4 ~43K 2,171 20.2 / 39.7 / 59.8 / 79.2 s Prefill 受算力限制，一个请求就已经把卡跑满，所以并发不会提高总 prefill 速度：多个长提示是一个接一个读的，排在后面的请求要等前面的读完。解码不一样，多个请求共用同一次权重读取，所以并发解码的总吞吐会明显上升（见上表 515 tok/s）。
-
-
-
-
同卡（单张 R9700 32G）来交个作业：radiance 分支，Qwen3.8-27B MXFP4 + DFlash2，附全量实测数据
看到这帖正好对上我们的配置，把这两个月踩出来的数据摆出来，也给还在折腾 radiance 的人一点参照。
一、硬件
项 配置 显卡 单张 R9700 32G（RDNA4，gfx1201，ReBAR 开） 功耗墙 240 W（见下面的取舍实验） CPU Intel i5-13600K，20 线程 内存 32 GB DDR4 系统 Ubuntu，内核 7.0.0-38-generic ROCm 主机没装 ROCm 用户态，只有内核自带 amdgpu + /dev/kfd，全部靠镜像内 ROCm 7.14 二、软件栈
镜像 magiccodingman/vllm-radiance:1.0.394 vLLM 0.30.0 / torch 2.12.0+rocm7.14 / hip 7.14.60850 / libr4d 0.5.0（20 kernels，13/13 queries） 主模型 amd/Qwen3.8-27B-Quark-AWQ-MXFP4 19.03 GiB 草稿 tcclaviger/Qwen3.8-27B-DFlash2-FP8 2.12 GB，spec=7，probabilistic关键环境（就是 common.sh 那套，加上投机解码栈）：
RADIANCE_FAST_DRAFT=1 # int2 draft head + exact rerank RADIANCE_DRAFT_RERANK=80 # 不是 64：VERIFY_HEAD 需要 4×top_k(20) 和 4×selector_top_k(16) RADIANCE_VERIFY_HEAD=1 # int2 target verify head RADIANCE_GDN_FUSED_UPDATE=1 R4D_ATTN_FP8=3 RADIANCE_DYNAMIC_WIDTH=1三、性能（全部本机实测，同机同权重）
decode（单流，320 token 输出，三次取中位）
内容 ms/step decode 接受率 tok/step 写代码 37.5 96.4 tok/s 37.8% 3.64 中文散文 37.3 49.4 tok/s 12.1% 1.85 纯 dense（SPEC=0） 31.5 31–32 tok/s — 1.00 TTFT / prefill
场景 结果 短问题 TTFT p50 94 ms（仅 1 个 token 的 prompt 也要 110 ms） 2K prompt 903 ms → 2,182 tok/s 8K prompt 3,118 ms → 2,456 tok/s 40K prompt 17.6 s → 2,281 tok/s 50K prompt 22.3 s → 2,232 tok/s 157K prompt 94.5 s → 1,660 tok/s（衰减 26%） 两个反直觉的数
- 接受率单次抖动极大，ms/step 才是稳定指标。 同一配置、同一道代码题连打三次：接受率 28.0% / 34.2% / 33.2%，decode 66.7 / 76.8 / 74.9 tok/s——但 ms/step 是 43.6 / 43.8 / 43.8，纹丝不动。所以别用单次 tok/s 比配置，会被接受率带走 15%。
- 功耗墙降下去不值。 240 W → 210 W：ms/step 44.1 → 44.3（无变化），2K prefill 2,182 → 2,040（−6%）。我们的卡 300 W 会 108–111℃ 硬关机，所以最终停在 240 W。
四、上下文与并发的取舍（32G 显存的真实账）
权重 19.03 GiB + 图捕获 ~0.6 GB，留给 KV 只有 9 GB，单价 36.5–39.8 KiB/token（fp8 KV + fp16 GDN 状态）：
并发 max_model_len KV 池 KV 并发 8 65,536 140,036 2.14× 2 112,640 221,029 1.96× 2 131,072 227,191 1.73×（不够两条全长） 1 245,000 246,580 1.01× 所以 2 并发 × 128K 在单卡 32G 上做不到（要 262,144 tokens ≈ 10.4 GB KV）。
看到你的 KV 池 401,454 tokens / 单请求 204,800，比我们多出 60%——你应该就是靠
RADIANCE_LMHEAD_INT4=1+RADIANCE_EMBED_BITS=4把权重压下去的。这是我们下一步要试的：1.0.394 里这两个开关有效吗？还是必须 1.5.x？五、踩过的坑（同卡的人可以直接避）
radiance_verifyhead.py第 97 行会申请 2.37 GiB 临时显存（w.data.abs().max()对 lm_head 全量拷贝）。单卡必 OOM，而且报错的 2.37 GiB 跟 KV 大小、batch、图模式全都无关，很容易误判成 KV 不够。改成分块 4096 行求 max，峰值掉到 ~40 MB 就能起。expandable_segments:True在 ROCm + Triton 上必挂：Memory access fault ... triton_per_fused__to_copy。别开。--max-num-seqs 1时compile_sizes必须传空数组，否则静态形状编译直接断言失败：
AssertionError: Expected exactly one compiled range_entry for static shape compilation, but found N（N = len(compile_sizes)+1）。我们试了 [1]、[1,2,4] 都是这个错，传[]+cudagraph_capture_sizes=[1,8]才过。- 自建 libr4d 是降级，不要碰：拉 codeberg 的 b9e42ab（0.4.0）打 rx10 patch，能编出 22 个 kernel、包含那些 fused/narrow-state 的私货，但 radiance 只解析 10/13 queries（镜像自带的 0.5.0 是 13/13）。而且 rx10 patch 对 main(0.5.0) 打不上。
- fused GDN 不值得追：源码注释自己写着 "in the serve the fused step measured -0.4% … single-stream unchanged"，而且它硬性要求 fp32 ssm state（会砍掉一半 KV 池）。我们实测 fp32 state：ms/step 44.2 vs fp16 的 43.8，没差。
FAST_DRAFT=0是错的方向：我们一开始照旧警告关掉了它，结果 ms/step 43.8、decode 79；打开FAST_DRAFT=1 + RERANK=80 + VERIFY_HEAD=1之后 37.5 ms / 96.4 tok/s（+22%）。dflash 分支默认就该是 1。
六、和 GGZ14 单卡基准的对照
指标 我们 GGZ14 TP=1 TTFT p50 94 ms 95 ms ms/step 37.5 ms 35.7 ms decode（代码） 96.4 tok/s launcher 注释实测 96.4–101.3 prefill 2K 2,258 tok/s 2,737（210W） TTFT 和 decode 基本打平，step 差 5%，prefill 差 20%。
顺便说一句：README 里 TP=1 表的 145.2 tok/s（代码）跟他们自己 launcher 注释里的 96.4–101.3 对不上，怀疑是 bench 口径不同（短输出把 prefill 摊进去了？）。建议复现时以 ms/step 和 acc/draft 为准，别拿 t/s 直接比。
七、想请教的两个问题
- Cactus：1.0.394 里有
RADIANCE_CACTUS_DELTA吗？我们日志里没见过，看到你那边 1.5.1 默认开了，代码类 acc 从 6.21 提到 6.39，这个对我们吸引很大。 - lm_head int4 + embed 4bit：实际省了多少显存、对输出质量有没有可测的影响？如果能把 KV 从 246K 推到 400K，那 2 并发 × 128K 就成立了。
那个「连续跑久了 decode 减半、重启恢复」的问题我们也遇到过类似现象（不过我们多是短会话，重启后 3–5 分钟冷启动里
http=000也容易误判成挂掉）——你贴的 TheRock issue 我记下了，下次复现前先确认 uptime。 -
正好前两天也在R9700 32G上部署了Radiance，简要汇报一下。
Radiance · Qwen3.8-27B MXFP4 单卡部署报告（R9700）
部署日期：2026-10-19 · 主机：
[email protected]（Ubuntu，kernel 7.0.0-31）
硬件：Ryzen 7 9700X / 123 GB DDR5 / RTX PRO 5000 48G + R9700 32G（gfx1201）
目标：在 R9700 上用 radiance 跑 Qwen3.8-27B MXFP4，4 并发，替换/对比 paiton-65k
1. 用 Docker（ROCm 7.2 的问题）
宿主机装的是 ROCm 7.2.4，但 radiance 镜像自带 ROCm 10.1 userspace，主机 ROCm 版本不参与：
层 谁提供 本机 内核 amdgpu/ KFD宿主机内核 7.0.0-31，支持 ROCm 10.x ROCm userspace / HIP 容器镜像 10.1（镜像内） 验证：
- paiton 的 ROCm 10.0 容器已在本机跑通（225.5 tok/s），说明内核支持 10.x；
- radiance 镜像拉起后输出
I device: AQL backend, 1 device(s) [0:gfx1201]； - R9700 的 BAR0 = 32G（ReBAR 已开），
cwsr_enable=1，/data为 ext4。
2. 部署物
项 路径 / 值 镜像 stilldeadcode/radiance:latest（582 MB，radiance 1.8.1）模型 /data/ai/models/radiance/qwen3.8-27b-mxfp4.rad（18.05 GiB）模型 sha256 a4908940c568f5f9dd24e88f46aefe9ac2ae07dfec023a2eaa1d14dcaa3df4f8（已校验）模型名 Qwen3.8启动参数（日常档）：
--model /models/qwen3.8-27b-mxfp4.rad --host 127.0.0.1 --port 18982 --served-model-name Qwen3.8 --tp 1 --max-num-seqs 4 --max-model-len 200000 --kv-cache-dtype fp8 --max-num-batched-tokens 4096 --num-speculative-tokens 7 --prefix-cache-mib 8192 --reasoning-effort none --gpu-headroom-mib 160
3. 启动报告（实际值，非估算）
card total 31.86 GiB already held 226.59 MiB activation arena 1.50 GiB step staging 135.74 MiB hardware queues 66.73 MiB --gpu-headroom-mib 160.00 MiB claimable 29.77 GiB static weights 15.70 GiB (vision 879 MiB 在 VRAM，embedding 2.37 GiB 去 host) elastic 14.07 GiB kv cache 14.07 GiB = 418,976 tokens = 2.1 × 200,000 其中 1.16 GiB 是 per-sequence linear state资源 实测 VRAM 占用 31.68 / 31.86 GiB（99.5%），空闲 ~177 MiB 主机 RAM（radiance pin） 17.27 GiB = embedding 2.37 + prefix paged KV 8 + linear checkpoints 5.99 + staging 系统 available 部署前 61 GiB → 部署后 48 GiB（Strata 仍占 ~98 GB RSS） 进程 1 个容器，16 threads 启动耗时 约 15 秒（18 GB 从 NVMe 以 ~4 GB/s 读入） 关键结论：KV 池按
--max-num-seqs × --max-model-len封顶。 三个档位：radiance-100k：4 seats × 100K = 400,000 token，100% backing（当前运行档）radiance-200k：1 seat × 200K = 200,000 token，100% backing（单条超长会话）- 旧的 4 seats × 200K：418,976 token，53% backing（一条 200K 会话 + 余量）
4. 实测性能（本机，240 W 功耗墙）
测试 结果 单流 code 768 tokens（Go LRU） TTFT 0.04 s，132.1 tok/s，5.85 s 单流短回复 208 tokens 179 tok/s，1.21 s 4 并发 × 512 tokens 每条 116.4 tok/s，合计 465.6 tok/s，4.47 s 16K prompt prefill TTFT 5.23 s，2,924 tok/s 16K prompt decode 102.4 tok/s（32 tokens，样本短） thinking reason=0，默认关闭口径说明：paiton 记录的 225.5 tok/s 是“英文 code、纯 decode”；本次 132.1 是 768 token 端到端 decode，prompt 内容不同。必须用同一批 prompt 做 A/B 才能定论。
4.1 同 harness 基准（
/data/ai/radiance/bench_ab.py，prose 输出 256 token）输入形状 TTFT prefill decode 64 0.043 s — 91.1 tok/s 4K 1.38 s 2,909 tok/s 81.4 tok/s 16K 5.53 s 2,852 tok/s 78.3 tok/s 32K 11.96 s 2,629 tok/s 72.3 tok/s - 这组 prompt 输出是 prose（RAID 风险分析），DFlash2 接受率低，所以 78–91；换成 code prompt（Go LRU）是 132 tok/s，官方对应 prose 77 / code 164。
- 4 并发短 prompt（37-token prompt，4×512 token）decode 聚合 465 tok/s（每条 116）。
- 4×16K 长 prompt 端到端 27.4 s、1,024 token，是 prefill 主导（约 64K prompt token），不能当 decode 聚合看。
5. A/B 结果：radiance vs paiton-65k（2026-10-19，同一脚本）
同一
/data/ai/radiance/bench_ab.py，同一批 prompt（nonce 防缓存、cached_tokens==0），
prose 输出 256 token，3 次取中位数；paiton 侧带chat_template_kwargs.enable_thinking=false。形状 Radiance TTFT / prefill / decode Paiton TTFT / prefill / decode 64 0.043 s / — / 91.1 0.086 s / — / 43.0 4K 1.38 s / 2,909 / 81.4 1.14 s / 3,533 / 38.3 16K 5.53 s / 2,852 / 78.3 4.58 s / 3,443 / 34.6 32K 11.96 s / 2,629 / 72.3 9.69 s / 3,246 / 36.6 4×16K 端到端 27.4 s / 37.4 聚合 26.3 s / 38.9 聚合 code 768 tokens 132.1 tok/s 65.3 tok/s 结论（以当前安装为准）：
- decode：radiance 快约 2.0–2.3×（prose 72–91 vs 34–43；code 132 vs 65）。
- prefill：paiton 快约 1.21–1.23×（3.2–3.5K vs 2.6–2.9K tok/s）。
- 4 条 16K 长 prompt 同时跑时，端到端几乎打平（prefill 主导）。
重要保留：paiton 启动日志出现
[radiance.w4] no w4a16 gemm_nt kernel in this r4d build, disabled [radiance.gemm] no gemm_nt kernel for M<=64 bf16, disabled这两个 kernel 被禁用；且 paiton 记录里的 225.5 tok/s（英文 code、decode-only）远高于这次的 65.3。
所以 paiton 当前这版可能不是它的最佳状态（镜像/内核覆盖有回退），2× 的 decode 差距里有多少是
引擎差异、有多少是这版 kernel 缺失，需要修好 paiton 镜像后再复测才能定论。在修好之前，按“当前可用的配置”选型：radiance 在 decode 和上下文容量（418,976 token vs 174,634）上占优，paiton 只在 prefill 上快约 20%。
-
-
其实我觉得paiton 不是最好的选择
除非多人一起用
不然个人使用 radiance 比较好 -
其实我觉得paiton 不是最好的选择
除非多人一起用
不然个人使用 radiance 比较好现在是这么用：
1、接入dsh，Strata+QFN-Q4_K_XL做主模型，radiance-100k给子代理用，进行专业文档处理。
2、VS Code里用Codex插件做规划/审核，Claude Code插件接入Strata+QFN-Q4_K_XL进行网页开发。
跑了两天，目前感觉还行。 -
其实我觉得paiton 不是最好的选择
除非多人一起用
不然个人使用 radiance 比较好 -
-
