RTX PRO 5000（或其他 48GB 显存）的 Qwen3.8-27B-FP8 配置交流（prefill 5000+t/s， decode 60+t/s）

sentinelK

先上参数：

python -m sglang.launch_server \
  --model-path Qwen3.8-27B-FP8 \
  --attention-backend flashinfer \
  --kv-cache-dtype fp8_e4m3 \
  --mamba-radix-cache-strategy extra_buffer_lazy \
  --mamba-full-memory-ratio 1.0 \
  --chunked-prefill-size 2048 \
  --context-length 262144 \
  --mem-fraction-static 0.90 \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_coder \
  --mm-feature-transport cpu \
  --speculative-algorithm EAGLE \
  --speculative-num-steps 3 \
  --speculative-eagle-topk 1 \
  --speculative-num-draft-tokens 4 \
  --host 0.0.0.0 \
  --port 30000 \
--enable-cache-report \
--mamba-full-memory-ratio 0.2 \
--mamba-ssm-dtype bfloat16

介于 ds-flash-0731 大幅度涨价，导致 MinimaxH3-Maker （我的开源视频提示词生成+视频生成导演台）进度放缓，也就有时间再研究研究本地 LLM 。

结果可以说相当喜人，如果说当年的 pp1500+tg40 的 qwen3.6-27B 算是可用的话。
Agent 和工具能力与 0731 有来有回的 qwen3.8-27B-FP8 ，就可以说是生产副手级别的 LLM 了。

更令人惊喜的是，sg-lang 架构的大幅度进步，在 rtx-pro-5000 上，226000 上下文下，可以跑到如下的成绩（非 MTP 、bench_one_batch ）：

batch
输入长度
Prefill 吞吐 (token/s)
Decode 吞吐 (token/s, 聚合)
Decode 单步时延

1
1024
5,322 → 5,449
31.3 → 31.8
31.5 ms / token

1
4096
5,006 → 5,089
31.3 → 31.5
31.8–32.0 ms

2
1024
5,097 → 5,185
60.8 → 61.3
32.6–32.9 ms

2
4096
3,286 → 4,988
54.3 → 60.5
33.1–36.9 ms

4
1024
4,408 → 5,190
109.8 → 120.6
33.2–36.4 ms

4
4096
593 → 443 ⚠️
33 → 30 ⚠️
121–132 ms ⚠️

7
1024
974 → 989 ⚠️
53 → 59 ⚠️
119–132 ms ⚠️

7
4096
329 → 184 ⚠️
52 → 52 ⚠️
~135 ms ⚠️

这里面有几个核心决策点，要和大家讨论：

1 、如何释放最大的可用上下文长度

Qwen 官方推荐的 mamba-full-memory-ratio 是 1.0 ，这会导致 mamba 层和 kvcache 平分剩下的显存。但如果你并非高并发场景（正常个人使用顶多 2 并发），如此分配 mamba 层是极度浪费的行为。所以我取的是 0.2 ，也就是 1 比 5 的比例分配剩余显存。这也就使得总显存分配 90%的情况下，48GB 显存可以得到 226000 的上下文长度。

注，上表格之所以 4 并发后的性能异常，就是因为 mamba 层不够用导致。
所以需要读者根据自身并发情况灵活控制占用配比。

2 、MTP 参数的设定

根据官方信息，MTP=3 是最大甜蜜点，可以单线程获得将近 2 倍的 decode 性能提升，prefill 性能几乎不受到影响。

3 、测试环境

以官方说明为参考： https://docs.sglang.io/docs/developer_guide/benchmark_and_profiling
采用 bench_one_batch 来测定。

4 、推荐的使用环境。

codex 或 dsh 。如果使用 dsh ，可以通过我的 dsh 插件来解决改变思考强度导致 error400 的问题： https://github.com/kop1989/dsh-localqwen-rolefix

defunct9

有安装教程么，有个 5090 32G

clemente

RTX PRO 5000 你是自己买的嘛 本地部署 耗电和维护如何

sentinelK

@defunct9 32G 的话，跑 nvfp4 量化的更合适一些，否则上下文过短了，不够实用。
但是 nvfp4 有一系列的问题：
1 、官方并没有 nvfp4 量化的模型，目前最资深的第三方就是 unsloth 家的。
2 、unsloth 家的 nvfp4 明确不支持 sglang 。
3 、4bit 量化，对于能力还是有比较明显的损失。

sentinelK

@clemente 半年前自购，京东自营，38000 。全功率运行 300 瓦，超静音风扇策略（锁死控温 85°）。双槽涡轮，所以不会导致机箱集热。

Yserver

我看到 sglang 好像是可以使用 dspark 的 --speculative-algorithm DSPARK  这个应该也会对性能有较大提升吧

sentinelK

@Yserver 感谢提点，测一下看看

Yserver

可以参考下 https://docs.sglang.io/cookbook/autoregressive/Qwen/Qwen3.8-27B#deployment 的 Speculative Decoding

BingoXuan

@sentinelK
sglang 推荐 nvfp4 量化是 RadixArk/Qwen3.8-27B-NVFP4 版本。unsloth 家的 nvfp4 量化可能还不如自家的 gguf 。NVIDIA 的 3.6 27B 的 nvfp4 量化明显比 unsloth 好得多。qwen3.8 的 kv cache 量化最多只能去到 fp8 ，到目前 nvfp4 的 kv cache 量化各家支持还是半残废。Blackwell 的硬件潜力还没有完全挖掘出来。

hejw19970413

我有个 4090 48G 用 vllm 部署的