Qwen3.8-2.4T稀疏专家模型vLLM部署实战

Qwen3.8-2.4T-A95B 是一个拥有 2.4 万亿参数的混合专家模型，每个 token 激活约 95B 参数。如果你要计划自托管，首先需要知道这是一个真正的大型分布式模型：即使低精度检查点也以 TB 为单位计量。

官方开源检查点为：

Qwen/Qwen3.8-2.4T-A95B

该模型包含 512 个路由专家，每个 token 选择其中 10 个，并配备一个共享专家。其 92 层骨干网络混合了 69 层 Gated DeltaNet 线性注意力层和 23 层全注意力层，全注意力层每四层出现一次。

原生上下文长度为 262,144 个 token，扩展配置可支持约 101 万个 token。

开源检查点是纯文本的，且始终使用推理模式。这与 Qwen 的托管服务 Qwen3.8-Max 不同，后者增加了视觉输入和非思考模式等功能。

对于 GPU 部署，主要决策不是 2.4T 参数能否以某种方式装下，而是哪种精度格式能在你实际拥有的硬件上提供有文档可查的配置。

从匹配 GPU 的检查点开始

目前实用的选项有：

完整 BF16 检查点约 4.45 TiB。官方 FP8 版本约 2.27 TiB，而 NVIDIA 八卡配置方案中使用的 NVFP4 检查点约 1.32 TiB。

这就是为什么如果你目标是简单运行 Qwen3.8 而不立即迁移到 16 卡集群，NVFP4 是最容易上手的 NVIDIA 部署方案。

H100、H200、A100、B200 和更小 GPU 配置不在本文范围内。当前的 vLLM 材料包含部分 GPU 的规模信息，但没有等效的端到端服务方案。本指南不会将内存估算转化为部署声明。

启动模型前

当前的 vLLM 方案推荐使用最近的 nightly build，而非旧版稳定 release。

创建环境：

uv venv
source .venv/bin/activate

uv pip install -U vllm \
  --extra-index-url https://wheels.vllm.ai/nightly

uv pip install -U "transformers>=5.4.0"

一旦有了可用的构建版本，就锁定它。Qwen3.8 依赖最近添加的模型和内核支持，因此持续将生产服务器升级到任意当前的 nightly 版本是不必要的风险。

在 8× B300 或 GB300 上运行 Qwen3.8

对于 NVIDIA，最小有文档可查的配置使用：

Inferact/Qwen3.8-2.4T-A95B-NVFP4

vllm serve Inferact/Qwen3.8-2.4T-A95B-NVFP4 \
  --tensor-parallel-size 8 \
  --max-model-len 262144 \
  --kv-cache-dtype fp8 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --speculative-config '{"method":"mtp","num_speculative_tokens":3}'

此配置适用于八卡 B300 系统，也在跨越两个 NVL4 托盘的八卡 GB300 上有文档记录。

vLLM 优化的 NVFP4 路径还使用：

--linear-backend flashinfer_cutedsl

但该标志依赖匹配的 FlashInfer 环境。在复现对应的 vLLM 容器/软件栈时添加它，而不是假设每个 vLLM 安装都具备所需的后端。

基准测试时保持 MTP 开启

Qwen3.8 内置了 Multi-Token Prediction 头。vLLM 公布的结果表明，使用三个推测性 token 可能产生显著差异。

在其低延迟测试中：

FP8 TP16
Without MTP: 130 output tok/s/user
MTP-3:       307 output tok/s/user

NVFP4 TP8
Without MTP: 133 output tok/s/user
MTP-3:       304 output tok/s/user

这些数据来自 vLLM 的硬件和工作负载测试，而非对每台服务器的承诺性能。它们确实表明 MTP-3 值得从一开始就测试：

--speculative-config '{"method":"mtp","num_speculative_tokens":3}'

在相同测试中，只使用一个推测性 token 的表现远不具说服力。vLLM 测得 MTP-1 的接受率为 64.8%，而在更高并发下，额外的推测工作实际上可能损害吞吐量。

运行官方 FP8 检查点

如果你想要 Qwen 的官方 FP8 检查点：

Qwen/Qwen3.8-2.4T-A95B-FP8

有文档可查的低延迟配置需要 16 张 GPU。

在 B300 上，这通常意味着使用 TP16 的两个八卡节点。

vllm serve Qwen/Qwen3.8-2.4T-A95B-FP8 \
  --tensor-parallel-size 16 \
  --nnodes 2 \
  --node-rank 0 \
  --master-addr $HEAD_ADDR \
  --max-model-len 262144 \
  --kv-cache-dtype fp8 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --speculative-config '{"method":"mtp","num_speculative_tokens":3}'

第二个节点使用相同的分布式配置：

--node-rank 1 \
--headless

只有 rank 0 应该暴露 API 服务器。

还有一个经验证的 12× GB300 FP8 配置，使用：

TP4 × PP3

为什么不是 TP12？Qwen3.8 有 64 个全注意力头，因此其 tensor-parallel 大小需要能被 64 整除。TP12 不能。

vLLM 在 12 张 GB300 GPU 上验证了 TP4 × PP3 布局，包括模型加载、CUDA graph 捕获和生成。当你有三个四卡 GB300 托盘时，这是一个有用的选项，尽管常规的 TP8 和 TP16 设置仍然更简单。

AMD 方案

有文档可查的 AMD 方案使用：

Inferact/Qwen3.8-2.4T-A95B-MXFP4

vllm serve Inferact/Qwen3.8-2.4T-A95B-MXFP4 \
  --tensor-parallel-size 8 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --reasoning-parser qwen3 \
  --speculative-config '{"method":"mtp","num_speculative_tokens":3}'

与 NVIDIA 命令的一个值得保留的差异：当前的 vLLM 方案不建议在此 ROCm 配置上盲目添加 FP8 KV cache。

--kv-cache-dtype fp8

在每个 ROCm/vLLM 组合上都能工作。只在确认了运行在该节点上的确切软件构建后才添加它。

amd/Qwen3.8-2.4T-A95B-Quark-MXFP4

适用于 MI350 和 MI355 硬件。

在该转换中，路由专家使用 OCP MXFP4，而注意力、路由器、共享专家、LM head 和 MTP 层等组件保持更高精度。

AMD 公布的 GSM8K 复现结果：

FP8 baseline: 97.49
MXFP4:        97.49

该结果在 MI35x 硬件上使用 SGLang 在 TP8 下复现。这是 AMD 量化质量的证据，而非 vLLM 吞吐量基准测试。

你实际应该分配多少上下文？

开源检查点原生支持：

262,144 tokens

可扩展至约：

1,010,000 tokens

export VLLM_ALLOW_LONG_MAX_MODEL_LEN=1

--max-model-len 1010000 \
--hf-overrides '{"max_position_embeddings":1010000}'

没有理由自动启用 1M 上下文。

长上下文消耗的内存本可用于并发请求。vLLM 自己的 NVFP4 测试说明了这种权衡：一个围绕 262K 窗口配置的系统可在可用 KV-cache 预算中容纳约 25 个并发请求，而一个更短的工作负载（8K 输入 + 1K 输出）可允许数百个。

如果你要服务于仓库级 coding agent，很长的上下文可能值得付出成本。如果大多数请求是 10K 或 20K token，为 100 万 token 预留主要会减少 GPU 同时能服务的用户数量。

根据你实际预期的工作负载设置：

--max-model-len

推理和工具调用

Qwen3.8 是一个推理模型。开源检查点不暴露正常的非思考模式。

它支持三种推理努力设置：

xhigh
medium
low

xhigh 是默认值。

Qwen 还默认保留跨轮次的思考，这对 agentic 会话很重要——因为早期的推理和工具交互是持续上下文的一部分。

--reasoning-parser qwen3 \
--enable-auto-tool-choice \
--tool-call-parser qwen3_coder

Qwen 推荐的生成设置包括：

temperature = 1.0
top_p = 0.95
top_k = 20
min_p = 0.0
presence_penalty = 0.0
repetition_penalty = 1.0

一个普通的 OpenAI 兼容客户端：

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="EMPTY",
    timeout=3600,
)

response = client.chat.completions.create(
    model="Inferact/Qwen3.8-2.4T-A95B-NVFP4",
    messages=[
        {
            "role": "user",
            "content": "Review this distributed queue design and identify its failure modes."
        }
    ],
    reasoning_effort="medium",
    temperature=1.0,
    top_p=0.95,
    max_tokens=16384,
)

print(response.choices[0].message)

对于硬编码和 agent 任务，保留足够的输出预算给推理轨迹。过于激进的 max_tokens 限制可能在模型得出最终答案之前终止生成。

加载如此大规模的模型

在 Qwen3.8 的规模下，启动时间成为操作服务器的一部分。

vLLM 的 NVFP4 测试发现：

--load-format fastsafetensors \
--safetensors-load-strategy lazy

在测试所用的共享存储上，模型加载时间从 545 秒减少到 306 秒。

该结果会因存储性能而异，但持久化模型存储显然优于每次机器重启时下载或重复复制 TB 级检查点。

vLLM 还使用更大的引擎启动超时：

export VLLM_ENGINE_READY_TIMEOUT_S=3600

并且不要仅根据进程是否存活来做就绪判断。向：

/v1/chat/completions

发送一个小请求，验证模型实际能够生成。

你应该使用哪种 GPU 配置？

如果你租用 GPU 专门用于 Qwen3.8-2.4T-A95B，当前的有文档可查的选择相当直接。

8× B300 + NVFP4 是当前 vLLM 方案中最简单的 NVIDIA 配置。

8× GB300 + NVFP4 在两个 NVL4 托盘上给你等效的 Grace Blackwell 路径。

当你特别需要官方 FP8 检查点且有足够硬件做 TP16 时，使用 16× B300 或 GB300 + FP8。

如果你有三个 GB300 托盘，12× GB300 FP8 + TP4 × PP3 是一个上游验证过的替代方案。

在 AMD 上，使用 8× MI355X + MXFP4。

H100、H200、A100、B200 和更小 GPU 数量不在本文推荐范围内。这些部分配置可能有足够的总内存，但当前来源没有提供相同的可复现端到端部署证据。

对于 Qwen3.8， 选择 GPU 只是部署的一部分。精确的量化、tensor-parallel 布局、KV-cache 预算、vLLM 构建版本、网络拓扑和 MTP 配置都会影响结果服务器在真实流量开始时是否有用。