我用deepseek harness 用RTX 5090 32GB SGLang qwen3.6 35B-A3B NVFP4 跑出奇怪的數字
-
9 轮 50 步·23206 tok/s 6.5M tok·缓存命中 0%
·23206 tok/s ???是咩一回事?
--model-path …/Qwen3.6-35B-A3B-NVFP4-nvidia
--served-model-name Qwen3.6-35B-A3B-NVFP4
--host 0.0.0.0
--port 8000
--api-key deepseek-harness-key
--trust-remote-code
--quantization modelopt_fp4
--json-model-override-args '{"text_config":{"max_position_embeddings":1048576,"rope_parameters":{…"rope_type":"yarn"…"factor":4.0,"original_max_position_embeddings":262144}}}'
--context-length 1000000
--kv-cache-dtype fp8_e4m3
--mem-fraction-static 0.88
--mamba-full-memory-ratio 0.4
--enable-hierarchical-cache
--hicache-size 24
--hicache-write-policy write_through
--hicache-io-backend kernel
--reasoning-parser qwen3
--tool-call-parser qwen3_coder現在出字比用deepseek V4.1 flash 仲快 ( 290 轮 3171 步·278 tok/s 1264M tok·缓存命中 97%), V4.1我最快見過346 tok/s
基本上已經不是串流一個個字吐出嚟了，是成編文章吐出嚟我用Qwen3.6-35B-A3B-NVFP4，唔用Qwen3.8-27B-NVFP4，因為Qwen3.6-35B-A3B-NVFP4夠快，但是快得過份了。唔用Qwen3.8-27B-NVFP4是因為慢同上下文不可以太大上唔到1M
-
那个 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。要感知长上下文，就看第二次同前缀请求的命中率有没有上来。
