那个 23206 tok/s 不是生成速度，是整轮聚合吞吐（prompt + decode 一起算），而且你这组数据缓存命中 0% → 几乎每个 step 都在全量重算 prefill，数字被 prefill 拉高了。
拆开看：
9 轮 50 步、6.5M tok：平均每步约 13 万 token，说明每步都把整段长上下文重新喂了一遍（0% 缓存命中），而不是只算增量。
prefill 是 compute-bound，A3B 这种小激活 MoE 在 5090 上跑几万 tok/s 很正常；真正决定体感的是 decode（单 token 生成），那是 bandwidth-bound，通常只有几十到一两百 tok/s。
对照你 V4.1 Flash 那组：1264M tok、缓存命中 97% → 绝大多数 token 走了缓存、只算 decode 增量，所以显示 278 tok/s 反而"慢"，但这更接近真实出字速度。
0% 命中的排查顺序：
每轮是不是新会话 / system prompt 前缀变了（工具 schema、日期等一变，前缀全 miss）；
--hicache-size 24 对 1M 上下文 + 长对话可能偏小，放不下就被淘汰；
Qwen3.6-35B-A3B 是混合线性注意力（含 Mamba 层），部分层未必支持前缀复用，--mamba-full-memory-ratio 0.4 也会影响可缓存量；
确认没传 --disable-radix-cache，并拿 SGLang 日志里的 radix/hicache hit rate 与面板对一下。
量真实速度：单开一个长输出请求，用 generated_tokens / 生成耗时 算；或用 python -m sglang.bench_serving --dataset-name random --random-input-len 1000 --random-output-len 512 看 output token throughput。要感知长上下文，就看第二次同前缀请求的命中率有没有上来。
