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

先上参数：

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

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

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