跳转至

这份文档为你完整复盘了针对 RTX 5090 (WSL2/Docker) 部署 Qwen3.6-35B-A3B-NVFP4 模型 冲刺 26万超长上下文 的全套调优知识库。你可以直接复制保存为 .md 文件。

🚀 RTX 5090 单卡极限长上下文（26万）部署调优指南

文档时效性说明

本文档基于写作时的技术栈编写，下方的版本号、API 参数、镜像 tag、第三方项目活跃度可能已过时。请以官方最新文档为准。

已知过时点（多处事实性错误）：

  • 模型名 Qwen3.6-35B-A3B-NVFP4 不存在（正确为 nvidia/Qwen3-30B-A3B-NVFP4）
  • CUTE_DSL_ARCH=sm_121a 错误（sm_121a 是 DGX Spark GB10，RTX 5090 应为 sm_120/sm_120a）
  • VLLM_FP8_MOE_BACKEND 在 vLLM envs.py 中未注册（这套参数实际来自 NVIDIA/NemoClaw 项目针对 DGX Spark + Nemotron-Nano 的配置）
  • vllm/vllm-openai:latest Docker tag 不存在（应使用 cu129-nightly 或具体版本号）
  • vLLM V1 已成为默认，V0 完全废弃（文档未提及）
  • 5090 上 NVFP4 MoE 仍是 vLLM bleeding edge（issue #35065 启动会失败）

在 Windows WSL2 / Docker 环境下，利用独显跑满大模型极限上下文常会遭遇各类底层物理瓶颈。本指南记录了从“多卡异构陷阱”到“单卡极致压榨”的完整踩坑与调优闭环。

1. 🛠️ 最终通关部署命令

经过多轮对显存、算子及通信协议的极限压榨，以下为单卡稳健啃下 26万上下文 的最终可行 Docker 运行命令：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
docker rm -f vllm-qwen

docker run -d --name vllm-qwen `
  --gpus '"device=0"' `
  -v C:\Users\hxp\.cache\huggingface:/root/.cache/huggingface `
  -p 0.0.0.0:8000:8000 `
  -e CUDA_DEVICE_ORDER=PCI_BUS_ID `
  -e HF_HUB_OFFLINE=1 `
  -e CUTE_DSL_ARCH=sm_121a `
  -e VLLM_FP8_MOE_BACKEND=flashinfer_cutlass `
  -e FLASHINFER_DISABLE_VERSION_CHECK=1 `
  vllm/vllm-openai:latest `
  --model nvidia/Qwen3.6-35B-A3B-NVFP4 `
  --trust-remote-code `
  --dtype auto `
  --quantization modelopt `
  --kv-cache-dtype fp8 `
  --attention-backend flashinfer `
  --gpu-memory-utilization 0.90 `
  --enable-chunked-prefill `
  --max-num-batched-tokens 4096 `
  --max-num-seqs 4

2. 💡 核心踩坑与技术洞察

2.1 1. 为什么不能叫上 RTX 3060 搞双卡？（异构并行致命陷阱）

  • 张量并行（TP）的木桶效应：vLLM 的 TP 并行要求参与的显卡显存完全对齐。如果 5090 (32GB) 与 3060 (12GB) 强行 TP，5090 的可用显存会被强制砍到 12GB。总可用显存不增反降（$12 + 12 = 24\text{ GiB}$），连模型本身都装不下。
  • 流水线并行（PP）的多模态冲突：Qwen3.6-35B-A3B-NVFP4 内置了视觉视觉编码器（Vision Tower）。在 vLLM 架构中，多模态模型的 Vision 部分无法被 PP 切分，强行开启 pipeline-parallel-size 2 会导致后半段 Worker 找不到 Vision 连续算子而闪退（WorkerProc failed to start）。

2.2 2. 为什么启动后显存占了 29.6 GiB 还能吃下 26 万上下文？

  • KV Cache 物理开销：Qwen3.6-35B 在开启 --kv-cache-dtype fp8 后，每个 Token 的 KV Cache 需占用约 $128\text{ KiB}$ 显存。
  • 分块预填充（Chunked-prefill）神技：面对海量提示词输入时，vLLM 默认会一口气处理完（Prefill），引发瞬间显存波峰爆发（OOM 报错）。开启 --enable-chunked-prefill 并限制 --max-num-batched-tokens 4096 后，长文本被切成小片动态喂入，配合 PagedAttention 的虚拟页式管理，从而在剩余极小的物理显存中平滑支撑起了 26 万长上下文。

3. 📋 关键启动参数全景拆解

参数/环境变量 分类 核心调优作用
--gpus '"device=0"' 基础隔离 仅挂载最强的 RTX 5090，彻底丢弃 3060 的多模态与异构干扰。
-e CUDA_DEVICE_ORDER=PCI_BUS_ID 环境控制 强制按物理插槽顺序编号，确保 device=0 锁定的绝对是 5090。
-e CUTE_DSL_ARCH=sm_121a 架构释放 针对 5090 专属的 Blackwell (sm_12x) 架构编译硬件级算子，压榨峰值算力。
-e VLLM_FP8_MOE_BACKEND=flashinfer_cutlass 算子加速 联合 FlashInfer 与 Cutlass 后端，让 MoE 模型在 FP8/NVFP4 矩阵乘法下吞吐最大化。
--quantization modelopt 模型读取 指定解密并读取由 NVIDIA ModelOpt 工具箱转成的 NVFP4（4位浮点） 密集权重。
--kv-cache-dtype fp8 显存压缩 将上下文记忆压缩为 FP8（1字节） 存储，使显存内的上下文坑位空间在物理上直接翻倍。
--gpu-memory-utilization 0.90 空间榨干 允许 vLLM 圈走 5090 物理显存的 90%，扣除 23.5G 权重后，其余全部做成 KV Cache 缓存池。
--enable-chunked-prefill 降维救灾 核心救命开关。将超长提示词分块吞咽，彻底斩断启动期 $1.02\text{ GiB}$ 突发分配带来的 OOM。
--max-num-seqs 1 流量管控 限制全局单并发，全神贯注服务个人 Agent，杜绝多开请求导致的意外显存崩溃。

4. 📊 前后端性能监控与排鱼眼

4.1 1. 为什么 Open WebUI 看不到生成速度（t/s）图标？

  • 成因：Open WebUI 的原生性能信息图标（ⓘ）主要依赖 Ollama 引擎特有的耗时元数据返回。当我们通过 vLLM 模拟 OpenAI 兼容接口时，其返回的 JSON 格式不包含前端高频对齐字段，因此前端界面默认会隐藏该统计。
  • 平替解法：在 Open WebUI 对应回复气泡下方点击 查看源数据（🔑 或 {} 图标），滚动到最下方的 usage 节点，可通过 completion_tokens（Token数）与 total_duration（纳秒耗时）自行换算。

4.2 2. 如何查阅最纯粹的 5090 硬件级输出流速？

不要依赖前端网络及渲染层，直接通过宿主机 PowerShell 查看 vLLM 的后台硬核吞吐监控：

1
docker logs --tail 50 -f vllm-qwen

在大模型吐字（Decode）阶段，重点留意控制台雷打不动刷新的这行指标：

(EngineCore) INFO ... Avg generation throughput: XX.X tokens/s

该数值代表 5090 此时此刻最真实的纯硬件吐字速度，用来评估 NVFP4 量化在 Blackwell 架构下的实际跑分表现。