R9700 - vllm radiance 分支
-
-
-
同卡（单张 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 比较好 -
-
