RadixArk

/

Qwen3.8-27B-NVFP4

like 56

Follow

RadixArk 140

感谢分享 vLLM 配置。3 并发 × 160k 在 32GB 显存上 SGLang 是可以跑的，关键是 fp8 KV + HiCache 分层缓存。

先算一下显存：这个模型是 hybrid 架构：64 层里每 4 层有 1 层 full attention（共 16 层），其余 linear attention 的状态大小固定、不随上下文增长。KV cache 只来自这 16 个 full attention 层（4 KV head × 256 head_dim），即每 token 约 64 KB（bf16）/ 32 KB（fp8）。3 并发 × 160k = 48 万 token 全部打满时：

• bf16 KV：约 30 GB——单这一项就塞不下 32 GB 显存
• fp8 KV：约 15 GB——加上 ~15 GB NVFP4 权重、CUDA graph 和激活，刚好卡在 OOM 边缘

vLLM 那边的 --kv-offloading-size 16 对应 SGLang 的 HiCache：--enable-hierarchical-cache 把 GPU 放不下的 KV（包括 hybrid 模型的 linear-attn state）分层卸载到 host 内存，前缀命中时直接取回而不是重算。

5090 上的推荐配置（需要 CUDA ≥ 12.8 的较新镜像，支持 sm_120）：

sglang serve \
  --model-path RadixArk/Qwen3.8-27B-NVFP4 \
  --trust-remote-code \
  --mem-fraction-static 0.85 \
  --kv-cache-dtype fp8_e4m3 \
  --context-length 163840 \
  --max-running-requests 3 \
  --chunked-prefill-size 4096 \
  --cuda-graph-max-bs 4 \
  --enable-hierarchical-cache \
  --hicache-size 16 \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_coder

几点说明：

• --kv-cache-dtype fp8_e4m3 把 KV 显存减半，是这个量级显存下跑长上下文的关键；代价是长程 agentic 任务上有轻微精度损失（日常对话类任务基本无感）。上下文不长且对精度敏感的话可以去掉。
• --hicache-size 单位是 GB，指 host 内存池大小；32GB 内存的机器建议留余量，12~16 比较稳妥。不给的话默认按 --hicache-ratio 2.0（host 池 = 2× GPU KV 池）。
• 注意运行中请求的 live KV 仍然要在 GPU 上（这一点 vLLM 也一样），fp8 KV 下 480k token 约 15 GB，扣除权重后余量不大；如果实际负载经常打满，可以把 --max-running-requests 降到 2。
• MTP 在 SGLang 上是验证过的（model card 推荐配置就开 NEXTN）：追加 --speculative-algorithm NEXTN --speculative-num-steps 3 --speculative-eagle-topk 1 --speculative-num-draft-tokens 4。但 MTP 额外吃显存，建议先不开验证稳定后再叠加。你在 vLLM 上高负载开 MTP 崩溃的问题，欢迎开 issue 附日志，我们也确认下 SGLang 侧有没有同样现象。
• 如果启动阶段就直接崩（而不是跑起来后 OOM），请到 sglang GitHub 开 issue 附完整日志，我们看下 sm_120 上的 kernel 路径。

另外好奇：用 froggeric 的 fixed chat template 是遇到了什么问题？模型自带 template 在 SGLang 上应该可以直接用，如果官方 template 有 bug 欢迎反馈。