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

[kop wang]

先上参数：

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

[Xiaote]

先给参数纠个错：你贴的命令里 --mamba-full-memory-ratio 出现了两次（1.0 和 0.2），命令行后值覆盖前值，实际生效的是 0.2。1.0 应该是官方模板残留，建议删掉，免得抄作业的人复制了一串前后矛盾的参数。

再补一个 decode 带宽账，解释"为什么单流 31.3 t/s 上不去了"：

1. RTX PRO 5000 48G 是 384-bit GDDR7，带宽 1344GB/s（不是 1.8TB/s 那档，很多人记错成 5090 的规格）
2. FP8 27B 权重 ≈ 28.5GB → 纯权重上限 = 1344 ÷ 28.5 ≈ 47 t/s
3. 但你在 226K 上下文跑：每 decode 一步，attention 要把全部 KV 读一遍。Qwen3.8-27B 是 64 层里只有 16 个 GatedAttn 层（其余 48 层是 GatedDeltaNet 线性注意力），KV ≈ 16 层 × 2 × 8 heads × 128 dim × 1B（fp8）≈ 32KB/token，226K 上下文就是 ≈ 7.4GB/步，直接吃掉约 1/4 的带宽
4. 两者合计每步读 ≈ 36GB → 上限 ≈ 37 t/s，你实测 31.3 是它的 85%，基本贴满

所以两个推论：

1. 不需要 226K 的场景，把 context 降到 64K：KV 读从 7.4GB 降到 2.1GB，上限回到 ≈ 44 t/s，decode 白赚 15-20%
2. 长上下文下 EAGLE 接受率会掉（论坛 TID:1131 那个 MTP 接受率崩的坑同款），"MTP=3 单线程近 2 倍 decode"是短上下文的结论；你可以用 --enable-cache-report 拉一下实际接受率，如果低于 0.6 就别指望投机解码的倍数了

结论：226K 下 31.3 t/s 已经是这台卡的实际极限附近，数字很扎实；想再快就砍上下文，没有免费午餐。

[Che]

并发数用 --max-mamba-cache-size 控制比 --mamba-full-memory-ratio 更好。

--mamba-radix-cache-strategy extra_buffer_lazy 时，--max-mamba-cache-size = 并发数 x 4

另外，--speculative-num-steps 对 MTP 的影响可能比 --speculative-num-draft-tokens 更大。

[williamlouis]

不错的分享。关注下。准备抄作业。

[terry]

我感觉得好好研究下4比特量化版本了，多空出点显存，开几个会话用

[stxpnet]

3090 遗憾离场【注：该图由27B模型独立上网调研生成】

[用户名违规]

你的卡全量prefill频繁吗？

[用户名违规]

@Che 明白人。弱弱问一下prefill在单用户容易全量prefill 这个咋解决呢？

[Che]

@用户名违规 怎么会全量 prefill 呢？把三级缓存都打开试下？

export SGLANG_HICACHE_FILE_BACKEND_STORAGE_DIR="/path/to/kvcache/folder"

  --mamba-radix-cache-strategy extra_buffer \
  --enable-hierarchical-cache \
  --hicache-size 16 \
  --hicache-storage-backend file \
  --schedule-policy lpm \
  --enable-session-radix-cache \
  --enable-metrics \

hicache-size 根据内存大小设置，或者用 hicache-ratio

[用户名违规]

@Che 二级缓存我已经开了，但是从来不落盘到 RAM，我都 emo 了。

你打开之后会正常落盘吗？我这边直接就是全量 Prefill，十分难受。

目前的 Docker Compose 配置如下：

services:
  sglang:
    image: lmsysorg/sglang:dev
    container_name: sglang-server
    restart: unless-stopped
    runtime: nvidia

    cap_add:
      - SYS_NICE
      - SYS_PTRACE

    environment:
      - NVIDIA_VISIBLE_DEVICES=0
      - CUDA_DEVICE_ORDER=PCI_BUS_ID
      - SGLANG_USE_IPC_POOL_HANDLE_CACHE=0
      - PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True
      - TZ=Asia/Shanghai

    volumes:
      - /mnt/x8/Qmodels:/models:ro
      - /mnt/480/docker/sglang/cache/torch_compile:/root/.cache/torch_compile
      - /mnt/480/docker/sglang/cache/flash_attn_cute_cache:/root/.cache/flash_attn_cute_cache

    command: >
      sglang serve
      --model-path /models/Qwen3.8-27B
      --host 0.0.0.0
      --port 30000
      --trust-remote-code
      --attention-backend flashinfer
      --mamba-backend flashinfer
      --max-mamba-cache-size 15
      --mamba-max-states-per-path 8
      --kv-cache-dtype fp8_e4m3
      --mem-fraction-static 0.94
      --max-running-requests 3
      --cuda-graph-bs-decode 1 2 3
      --num-continuous-decode-steps 4
      --prefill-max-requests 1
      --schedule-policy lpm
      --enable-session-radix-cache
      --tool-call-parser qwen3_coder
      --reasoning-parser qwen3
      --chunked-prefill-size 2048
      --max-prefill-tokens 2048
      --disable-prefill-cuda-graph
      --enable-fused-qk-norm-rope
      --enable-cudagraph-gc
      --log-level info
      --uvicorn-access-log-exclude-prefixes /
      --decode-log-interval 120
      --allow-auto-truncate
      --enable-cache-report

    # 删除 --linear-attn-backend triton
    # 其他参数保持不变

    shm_size: '16gb'
    network_mode: host

    logging:
      driver: json-file
      options:
        max-size: "100m"
        max-file: "3"

    # --enable-cache-report
    # --enable-hierarchical-cache
    # --hicache-ratio 2
    # --hicache-io-backend kernel
    # --hicache-mem-layout page_first
    # --hicache-write-policy write_through

之前尝试的二级缓存相关参数是：

--enable-hierarchical-cache
--hicache-ratio 2
--hicache-io-backend kernel
--hicache-mem-layout page_first
--hicache-write-policy write_through

但是实际运行时，二级缓存始终没有正常落到 RAM。再次请求时依然会进行全量 Prefill。

我看了一遍这些参数，暂时也没发现明显的问题。不知道是当前 sglang:dev 的问题，还是 Qwen3.8-27B、Mamba/FlashInfer 这套组合存在兼容性问题。

有正常使用 SGLang Hierarchical Cache 的朋友可以帮忙看看吗？尤其是开启之后，RAM 二级缓存是否能够正常命中？

[terry]

@用户名违规 我弟你发帖整理下格式，你的帖子怎么经常看不下去呢？你让AI整理下格式。我给你整理了下，下不为例。

[用户名违规]

@terry ，不过找到原因了，hermes 会自动总结技能就会打断sglang的 kvcache缓存。。