@applejuice 说:

其实我觉得paiton 不是最好的选择
除非多人一起用
不然个人使用 radiance 比较好

现在是这么用：
1、接入dsh，Strata+QFN-Q4_K_XL做主模型，radiance-100k给子代理用，进行专业文档处理。
2、VS Code里用Codex插件做规划/审核，Claude Code插件接入Strata+QFN-Q4_K_XL进行网页开发。
跑了两天，目前感觉还行。

Radiance · Qwen3.8-27B MXFP4 单卡部署报告（R9700）

部署日期：2026-10-19 · 主机：telloai@100.79.66.47（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 版本不参与：

验证：

• 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. 部署物

启动参数（日常档）：

--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

关键结论：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 功耗墙）

口径说明：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）

• 这组 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。

结论（以当前安装为准）：

• 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%。

看到这帖正好对上我们的配置，把这两个月踩出来的数据摆出来，也给还在折腾 radiance 的人一点参照。

一、硬件

二、软件栈

镜像    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 输出，三次取中位）

TTFT / prefill

两个反直觉的数

1. 接受率单次抖动极大，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%。
2. 功耗墙降下去不值。 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 状态）：

所以 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？

五、踩过的坑（同卡的人可以直接避）

1. radiance_verifyhead.py 第 97 行会申请 2.37 GiB 临时显存（w.data.abs().max() 对 lm_head 全量拷贝）。单卡必 OOM，而且报错的 2.37 GiB 跟 KV 大小、batch、图模式全都无关，很容易误判成 KV 不够。改成分块 4096 行求 max，峰值掉到 ~40 MB 就能起。
2. expandable_segments:True 在 ROCm + Triton 上必挂：Memory access fault ... triton_per_fused__to_copy。别开。
3. --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] 才过。
4. 自建 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) 打不上。
5. 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，没差。
6. 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 单卡基准的对照

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 直接比。

七、想请教的两个问题

1. Cactus：1.0.394 里有 RADIANCE_CACTUS_DELTA 吗？我们日志里没见过，看到你那边 1.5.1 默认开了，代码类 acc 从 6.21 提到 6.39，这个对我们吸引很大。
2. lm_head int4 + embed 4bit：实际省了多少显存、对输出质量有没有可测的影响？如果能把 KV 从 246K 推到 400K，那 2 并发 × 128K 就成立了。

那个「连续跑久了 decode 减半、重启恢复」的问题我们也遇到过类似现象（不过我们多是短会话，重启后 3–5 分钟冷启动里 http=000 也容易误判成挂掉）——你贴的 TheRock issue 我记下了，下次复现前先确认 uptime。

@applejuice 说:
@paul-hou 220k 是不是纯文字？

把vision放在cpu上運算了，沒佔vram。
sly也是一樣放cpu，所以可以有接近500k的上下文可用。