RTX PRO 5000（或其他 48GB 显存）的 Qwen3.8-27B-FP8 配置交流（prefill 5000+t/s， decode 60+t/s）
先上参数：
```bash
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](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](https://github.com/kop1989/dsh-localqwen-rolefix)
---
原文链接：[点击查看](https://www.v2ex.com/t/1235518)
```bash
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](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](https://github.com/kop1989/dsh-localqwen-rolefix)
---
原文链接：[点击查看](https://www.v2ex.com/t/1235518)
· 0 个赞
· 0 个赞