本文记录 Qwen3.8-Flash-Next NVFP4 在单张 RTX PRO 6000 Blackwell 上的 SGLang 部署参数，以及短上下文、32K、128K、262K 的 Prefill 和 Decode 实测结果。
构建 Docker 镜像
首先构建运行镜像。基础镜像使用 lmsysorg/sglang:dev-cu13，保留其中已经适配 CUDA 13 和 Blackwell 的 sgl-kernel、FlashInfer 等依赖，再覆盖安装指定 commit 的 SGLang Python 包。
FROM lmsysorg/sglang:dev-cu13
ARG SGLANG_REPO=https://github.com/LingZ315/sglang.git
ARG SGLANG_COMMIT=3df8e1e7dbc5807696622afe2929b6c33c185ca3
RUN git clone "${SGLANG_REPO}" /tmp/sglang \
&& cd /tmp/sglang \
&& git checkout "${SGLANG_COMMIT}" \
&& pip install --no-deps --no-build-isolation ./python \
&& rm -rf /tmp/sglang
执行构建：
docker build --progress=plain \
-t your-registry/sglang:qwen38flashnext-fp8kv .
这里使用 --no-deps --no-build-isolation，是为了避免 pip 根据开发分支的依赖声明替换基础镜像中已经适配 GPU 的 CUDA组件。该镜像包含 Qwen3.8-Flash-Next、SM120 FlashInfer 路由和 FP8 QSA KV Cache 相关支持。
正式部署时，建议同时固定基础镜像 digest 和 SGLang commit，确保后续可以复现，避免滚动 tag 变化。
测试环境
| 项目 | 配置 |
|---|---|
| GPU | NVIDIA RTX PRO 6000 Blackwell，约 96 GB 显存 |
| 系统内存 | 183 GiB |
| NVIDIA Driver | 580.178.04 |
| CUDA | 13.0.3 |
| PyTorch | 2.13.0+cu130 |
| Triton | 3.7.1 |
| FlashInfer | 0.6.17 |
| 模型量化 | ModelOpt NVFP4 |
| KV Cache | FP8 E4M3 |
启动参数
下面使用占位路径和示例镜像名。实际部署时替换模型、HiCache 和镜像地址即可。
docker run -d \
--name qfn \
--init \
--restart on-failure:3 \
--gpus all \
--ipc host \
--shm-size 32g \
-p 8000:8000 \
-e SGLANG_ALLOW_OVERWRITE_LONGER_CONTEXT_LEN=1 \
-e TOKENIZERS_PARALLELISM=false \
-e NVIDIA_DRIVER_CAPABILITIES=compute,utility \
-e SGLANG_HICACHE_FILE_BACKEND_STORAGE_DIR=/hicache \
-v /path/to/Qwen3.8-Flash-Next-NVFP4:/models/qfn:ro \
-v /path/to/hicache:/hicache:rw \
your-registry/sglang:qwen38flashnext-fp8kv \
sglang serve \
--model-path /models/qfn \
--served-model-name qwen3.8-flash-next \
--tp-size 1 \
--quantization modelopt_fp4 \
--attention-backend flashinfer \
--ple-offload-embedding \
--kv-cache-dtype fp8_e4m3 \
--context-length 262144 \
--mem-fraction-static 0.960 \
--chunked-prefill-size 8192 \
--max-running-requests 6 \
--max-mamba-cache-size 24 \
--mamba-ssm-dtype bfloat16 \
--mamba-radix-cache-strategy extra_buffer_lazy \
--linear-attn-prefill-backend triton \
--linear-attn-decode-backend flashinfer \
--hicache-size 46 \
--hicache-io-backend kernel \
--hicache-write-policy write_through_selective \
--hicache-mem-layout page_first \
--hicache-storage-prefetch-policy timeout \
--enable-hierarchical-cache \
--hicache-storage-backend file \
--hicache-storage-backend-extra-config \
'{"max_size":"384G","min_free_space":"50G"}' \
--page-size 64 \
--enable-metrics \
--uvicorn-access-log-exclude-prefixes /metrics \
--enable-cache-report \
--enable-multimodal \
--reasoning-parser auto \
--host 0.0.0.0 \
--port 8000
这里没有启用 NEXTN/MTP。实测启用 NEXTN 后，主 KV Pool 会从数十万 tokens 降到约 155K，无法处理 250K 输入。
当前 Mamba 配置为：
--max-mamba-cache-size 24
--mamba-ssm-dtype bfloat16
--mamba-radix-cache-strategy extra_buffer_lazy
该配置实测可以同时运行 6 个请求，没有被 SGLang 自动降低并发。
启动结果
模型启动后的主要资源分配：
| 项目 | 结果 |
|---|---|
| 模型权重 | 约 82.45 GB |
| 主 KV Pool | 532,736 tokens |
| KV Cache 显存 | K 3.05 GB + V 3.05 GB |
| Mamba Cache | 24 slots，约 1.37 GB |
| 最大运行请求 | 6 |
| GPU 显存余量 | 约 5.66 GB |
250K 请求实测可以正常完成。完整长上下文测试的实际输入约为 261.7K tokens，也能够正确生成 128 tokens。
性能测试
每种上下文分别测试并发 1/2/4/6。每个请求固定生成 128 tokens，并关闭 thinking。
指标口径：
- Prefill：输入处理吞吐，单位为输入 tokens/s；
- Decode：SGLang scheduler 日志中的稳态生成吞吐；
- TTFT：从发出请求到收到第一个输出 token；
- 端到端输出：包含 Prefill、排队和 Decode 的整体输出吞吐。
Prefill
| 上下文 | 输入 tokens/请求 | 并发 | Prefill tokens/s | TTFT P95 |
|---|---|---|---|---|
| 32K | 32,679 | 1 | 11,592 | 2.82s |
| 32K | 32,679 | 2 | 21,535 | 2.92s |
| 32K | 32,679 | 4 | 20,227 | 6.15s |
| 32K | 32,679 | 6 | 22,542 | 7.59s |
| 128K | 130,984 | 1 | 10,624 | 12.33s |
| 128K | 130,984 | 2 | 21,522 | 12.17s |
| 128K | 130,984 | 4 | 21,806 | 22.56s |
| 128K | 130,984 | 6 | 28,457 | 24.71s |
| 262K | 261,672 | 1 | 10,217 | 25.61s |
| 262K | 261,672 | 2 | 19,142 | 26.16s |
| 262K | 261,672 | 4 | 13,482 | 73.71s |
| 262K | 261,672 | 6 | 12,318 | 121.25s |
128K 并发 6 的聚合 Prefill 数字较高，但尾延迟已经明显增加。在线服务不应只根据聚合吞吐选择并发，还要同时考虑 TTFT。
Decode
| 活跃 Decode 并发 | 稳态聚合 Decode tokens/s | 平均每请求 tokens/s |
|---|---|---|
| 1 | 93-99 | 93-99 |
| 2 | 174-189 | 87-94 |
| 4 | 335-373 | 84-93 |
| 6 | 543-547 | 90-91 |
不同上下文下，单请求 Decode 速度为：
| 上下文 | Decode tokens/s |
|---|---|
| 短上下文 | 98-99 |
| 32K | 95-96 |
| 128K | 96-97 |
| 262K | 93-94 |
从短上下文增加到 262K 后，单请求 Decode 只下降约 6%。并发 6 的稳态聚合 Decode 吞吐约为 545 tokens/s。
端到端输出
端到端吞吐包含输入 Prefill 和排队时间，因此长上下文数值会明显低于纯 Decode。
| 上下文 | C1 | C2 | C4 | C6 |
|---|---|---|---|---|
| 短上下文 | 75.72 | 129.10 | 252.25 | 371.73 |
| 32K | 30.13 | 57.10 | 63.98 | 76.44 |
| 128K | 9.35 | 18.72 | 19.98 | 26.14 |
| 262K | 4.74 | 8.91 | 6.48 | 5.96 |
单位均为输出 tokens/s。
HiCache 工作情况
当前缓存分为三层：
GPU KV/Mamba Cache
-> 46 GB 宿主内存 HiCache
-> 最大 384 GB NVMe 文件缓存
启动时实际分配的宿主缓存约为：
KV host pool: 约 23.8 GB
Mamba host cache: 约 22.2 GB
完成短上下文、32K、128K 和 262K 并发矩阵后：
- 50 个请求全部成功；
- 没有 OOM、retract、watchdog 或容器重启；
- GPU KV Pool 一度只剩约 640 tokens，说明长前缀确实进入缓存；
- 新请求到来时由 Radix Cache/LRU 淘汰旧前缀，不是显存泄漏；
- NVMe HiCache 目录增长到数 GB，文件层缓存确实在工作。
对 Agent 场景，多个请求如果携带相同的系统提示词、工具定义和历史前缀，公共前缀只需要缓存一份。这样可以显著减少重复 Prefill 和 GPU KV占用。为了提高命中率，应保持公共前缀的 token 序列完全一致，并把时间戳、请求 ID 等动态字段放到提示词后部。
结论
当前配置在单张 RTX PRO 6000 上实现了：
主 KV Pool: 532,736 tokens
最大并发: 6
最大实测输入: 约 261.7K tokens
单请求 Decode: 约 93-99 tokens/s
并发 6 稳态 Decode: 约 543-547 tokens/s
推荐并发：
| 场景 | 建议并发 |
|---|---|
| 短上下文 | 6 |
| 32K | 4-6 |
| 128K | 2 |
| 262K | 1-2 |
extra_buffer_lazy + 24 Mamba slots 在 KV容量和并发之间取得了较好的平衡。对于 Agent工作负载，固定公共前缀、保持会话粘性路由，并利用 GPU、宿主内存和 NVMe三级 HiCache，可以获得比完全独立长请求更好的实际吞吐和 TTFT。
浙公网安备 33010602011771号