AWS博客：HyperPod上部署Qwen3.8-2.4T推理模型实战

2026年8月12日，阿里巴巴 Qwen 团队发布了 Qwen3.8-2.4T-A95B。这是 Qwen-Max 级模型首次以开放权重的方式发布。该模型拥有 2.4 万亿总参数（每次 Token 激活 950 亿参数）、混合线性加全注意力架构，以及最高 262K Token（可扩展至 1M）的原生上下文长度，Qwen3.8 瞄准的是最苛刻的 AI 智能体和推理工作负载。其应用场景包括多步编程、长周期规划以及自主工具调用。

开放权重模型赋予你完全的控制权。数据保留在你的基础设施内，推理行为可以自定义，大规模使用时没有按 Token 计费的 API 费用。代价是运维层面的：托管一个 2.4T 参数模型需要专用 GPU 基础设施和优化的服务栈。

在本文中，我们展示如何在 Amazon SageMaker HyperPod 上使用 vLLM 部署 Qwen3.8-2.4T-A95B，运行环境为 ml.p6-b300 实例（8× NVIDIA B300 Blackwell Ultra GPU）。我们涵盖从集群配置到 OpenAI 兼容端点的完整路径，包括 NVFP4 量化的 vLLM 配置、内置推理、工具调用以及原生 Multi-Token Prediction（MTP）投机解码。

这是我们 SageMaker HyperPod 上部署开放万亿参数模型系列的第二篇文章。第一篇涵盖 Kimi K3，请参阅《在 Amazon SageMaker HyperPod 和 Amazon EKS 上部署 Kimi K3》。

Qwen3.8-2.4T-A95B 概览

Qwen3.8-2.4T-A95B（Qwen3.8-Max 的开放权重版本）是 Qwen 系列中最大、最强的模型。以下是与其部署相关的关键架构细节摘要。

混合注意力设计是高效率长上下文推理的关键。Gated DeltaNet 层（92 层中的 69 层）使用线性注意力配合有界循环状态，用固定大小的内存替代了不断增长的 KV-cache。Gated Attention 层（92 层中的 23 层）使用全二次注意力进行高保真 Token 交互。这一 3:1 的配比使计算和内存在上下文扩展至 1M Token 时均保持有界。这对于 AI 智能体工作负载至关重要，因为这类负载在多轮对话中会累积工具输出、代码和推理痕迹。

细粒度 MoE 将容量分布在 512 个小型专家而非几个大型专家上，提高了路由效率和专业化程度。每次前向传播只有约 950 亿参数处于激活状态，因此服务成本与激活参数挂钩，而非完整的 2.4T。

能力和推理控制

Qwen3.8 为 AI 智能体执行而设计：多步编程、自主工具调用、长周期规划以及复杂研究工作流程。它通过 reasoning_effort 参数（low、medium、high）提供内置推理控制，开发者可以按请求在推理深度和计算成本之间进行权衡。困难的多步问题调高参数，高吞吐量任务调低参数。

模型权重和量化

开放权重以标准 Transformers 格式发布在 Hugging Face 上。社区量化包括 MXFP4 和 NVFP4（W4A4），可将模型压缩至约 1.2 TB，足以适配配备 B300 Blackwell Ultra GPU 的单台 8-GPU 节点。

根据厂商的基准测试结果，Qwen3.8-2.4T-A95 在研究工作流程（PaperBench 93.0）、指令遵循（IFBench 82.8）和终端编程（86.6）方面表现尤为突出。在大多数类别中与前沿领先模型表现相当，在更具难度的代码库级任务（SWE-bench Pro）和通用工具使用（ToolAthlete）上仍有提升空间。对于正在评估自托管替代方案以取代专有 API 的组织而言，这些结果使 Qwen3.8-2.4T-A95 成为可信的前沿级选项，尤其适用于编程 AI 智能体和研究流水线。

为什么选择 Amazon SageMaker HyperPod 进行大规模 MoE 推理

部署 2.4T 参数模型不仅仅是一个 GPU 问题。它需要编排层来处理模型下载、容器调度、健康监控、自动扩缩容，以及节点故障恢复而无需人工干预。Amazon SageMaker HyperPod 正是为这类工作负载量身打造的。

图 1：Amazon SageMaker HyperPod 高级架构

EKS 编排的集群。HyperPod 集群使用 Amazon Elastic Kubernetes Service（Amazon EKS）作为控制平面。你可以获得完整的 Kubernetes 生态（kubectl、Helm chart、自定义资源定义），而 AWS 则管理底层基础设施生命周期：网络、存储、GPU 驱动安装以及 NVIDIA 设备插件。

推理 Operator。HyperPod 推理 Operator（自动安装或作为 EKS Add-on 安装）提供了一个自定义资源定义（CRD）InferenceEndpointConfig，可声明式地指定你的模型、容器镜像、GPU 资源请求和 vLLM 启动参数。Operator 负责：

从 Hugging Face Hub、Amazon Simple Storage Service（Amazon S3）或 Amazon FSx 下载模型权重。

容器调度和 GPU 分配。

健康检查和就绪门控。

滚动更新和端点生命周期管理。

通过 KEDA 与 Amazon CloudWatch 或 Prometheus 指标实现自动扩缩容。

灵活训练计划的预留容量。ml.p6-b300.48xlarge 实例类型需要预留容量。灵活训练计划提供可分配至 HyperPod 集群的承诺 GPU 预留。与按需池无竞争，也无冷启动容量风险。

弹性。HyperPod 持续监控节点健康状况并自动替换降级节点。对于 24/7 运行持续推理工作负载，这减轻了手动检测和从硬件故障中恢复的运维负担。

其他推理功能（推理 Operator v3.x）：

分解的 Prefill 和 Decode（DPD）—— 将 prefill 和 decode 分离到不同的 GPU 池，在并发负载下实现可预测的每 Token 延迟。

推理数据捕获—— 在端点、负载均衡器或 Pod 级别记录输入/输出。

本地 NVMe 模型部署—— 从节点本地存储加载权重以减少冷启动延迟。

Amazon Route 53 DNS 管理—— 为你的端点自动生成自定义域名记录。

简而言之：你编写一个 YAML 清单来描述要部署什么，HyperPod 负责如何可靠地大规模运行它。

基础设施规模：硬件与模型的匹配

ml.p6-b300.48xlarge 提供了单节点服务 Qwen3.8 所需的计算密度：

为什么选择 NVFP4 量化

以 BF16 精度，Qwen3.8 的 2.4T 参数仅权重就需要约 4.8 TB 内存，超出了单台 8-GPU 节点的容量。NVFP4（W4A4）量化将权重压缩至每参数约 4 bit，使总权重占用降至约 1.2 TB。这可以舒适地容纳在 p6-b300 实例上 2.1 TB 的聚合 GPU 内存中，同时为 KV-cache 和激活值留出余量。

单台 p6-b300 节点的大致内存分解：

混合注意力架构在这里是一个关键优势：69 个 DeltaNet 层维护一个固定大小的循环状态，与上下文长度无关，不像传统模型那样 KV-cache 随每层线性增长。只有 23 个全注意力层才会产生随上下文增长的内存。

吞吐量预期

NVIDIA 在 GB300 NVL72（FP8，72 GPU）上的 Day-0 基准参考数字：>4K tokens/sec/GPU，>350 tokens/sec/user。配备 NVFP4 的单台 8-GPU p6-b300 节点的总吞吐量会相应较低，但仍然非常适合中等并发量的生产推理工作负载。

ml.p6-b300.48xlarge 实例类型不提供按需选项。你必须通过灵活训练计划获取容量，这是为你的 HyperPod 集群预留的 GPU 承诺。在配置实例组时，将目标可用区设置为与你的计划分配相匹配。

vLLM 配置深度解析

本节详述在单台 p6-b300 节点上使用 vLLM 服务 Qwen3.8 的服务参数。该配置基于 vLLM 在 B300（NVFP4）上运行 Qwen3.8 的配方。

完整的 vllm serve 调用：

vllm serve Inferact/Qwen3.8-2.4T-A95B-NVFP4 \
    --tensor-parallel-size 8 \
    --quantization nvfp4 \
    --load-format fastsafetensors \
    --trust-remote-code \
    --enable-prefix-caching \
    --moe-backend auto \
    --reasoning-parser qwen3 \
    --enable-auto-tool-choice \
    --tool-call-parser qwen3 \
    --speculative-config '{"method":"mtp","num_speculative_tokens":1}' \
    --served-model-name Qwen3.8

--tensor-parallel-size 8 – 将模型分片到全部 8 块 B300 GPU 上。

--quantization nvfp4 – 激活 NVIDIA FP4（W4A4）量化，使 2.4T 模型能够装入 2.1 TB 的 GPU 内存。

--load-format fastsafetensors – 使用加速权重反序列化以加快冷启动。

--trust-remote-code – Hugging Face 上 Qwen3.8 的自定义建模代码需要此参数。

You've shared a detailed technical guide about deploying Qwen3.8 on AWS SageMaker HyperPod using vLLM. This covers:

• vLLM engine configuration with FlashInfer/CUTEDSL backend
• Reasoning/thinking content parsing (separate from final answer)
• Tool calling with --enable-auto-tool-choice and qwen3_coder parser
• Speculative decoding with MTP (Multi-Token Prediction)
• Complete SageMaker HyperPod deployment manifest
• API usage examples (OpenAI-compatible /v1/chat/completions)

What would you like me to help you with regarding this content? For example:

• Add this as documentation to your project?
• Create a deployment script/helm chart based on the manifests?
• Extract code examples for a specific use case?
• Something else — just let me know!

top_k=20 – 在每个步骤限制词表大小，降低长文本生成中的退化输出。

max_tokens – 启用思考功能时应设得宽松一些，因为 reasoning_content 也会占用 token 预算。对于复杂推理任务，32,768–65,536 是一个合理的上限。

快速验证的 curl 示例：

curl http://<service-endpoint>:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen3.8",
    "messages": [{"role": "user", "content": "Hello, Qwen3.8!"}],
    "temperature": 0.6,
    "max_tokens": 256
  }'

性能调优技巧

服务运行后，以下调优开关可以针对具体工作负载模式进行优化。

我们在单个 p6-b300 实例（8× B300 GPU）上对 Qwen3.8-2.4T-A95B 进行了基准测试，使用 512 个请求，每个请求 1,024 输入 token 和 1,024 输出 token，并发数为 32。我们测试了四种配置，以隔离专家并行（Expert Parallelism，EP）和多 Token 预测（Multi-Token Prediction，MTP）投机解码的影响：

TP – 仅 Tensor Parallelism（TP=8），作为基准。

TP+MTP – TP=8，启用原生 MTP 投机解码（num_speculative_tokens: 1）。

TP+EP – TP=8，启用 Expert Parallelism。

TP+EP+MTP – TP=8，同时启用 EP 和 MTP。

图 2：p6-b300 节点上 TP、MTP 和 EP 配置的基准对比

关键发现（相对于 TP 基准的百分比改进）：

MTP 是 TTFT 的主导优化。启用投机解码（即使每个步仅 1 个草稿 token）可将首个 token 的生成时间（TTFT）缩短近 59%，从 1,244 ms 降至 513 ms。这是因为 MTP 草稿头在最终预填充步骤并行的同时预测首批输出 token，实现了计算重叠。

单独使用 EP 效果有限（TTFT 约提升 3.5%，吞吐量约提升 1%）。在更高并发级别下优势更明显，此时专家路由争用会成为瓶颈。

EP+MTP 组合带来最佳整体效果：TTFT 降低 59.7%，延迟降低 12.2%，输出吞吐量提升 12.6%。两种优化互补：EP 减少专家分派开销，而 MTP 减少解码延迟。

Token 间延迟（图中未显示）也有改善：17.97 ms（TP）→ 17.33 ms（TP+MTP）→ 16.36 ms（TP+EP+MTP），全配置下降低 9%。

建议：对于生产部署，同时启用 EP 和 MTP（--enable-expert-parallel + --speculative-config '{"method":"mtp","num_speculative_tokens":1}')。组合配置以最小的额外复杂度提供最佳延迟和吞吐量表现。

配合 --enable-prefix-caching 使用（已在我们的配置中启用）。vLLM 的自动前缀缓存（Automatic Prefix Caching，APC）可在共享相同提示词前缀的请求之间复用 KV-cache 块。这在多轮 AI 智能体对话中很常见，因为系统提示词和对话历史会重复出现。对于前缀重叠度高的工作负载，这可使重复轮次的 TTFT 降低 50–80%。对于无前缀共享的工作负载没有负面影响。未使用的缓存块会被自动驱逐。

投机解码（MTP）调优

我们的配置以 num_speculative_tokens: 1 起步（每步多生成一个 token）。调优指导：

对于吞吐量敏感、低并发的工作负载，可增至 2–3。每增加一个投机 token 会提高每步可接受的 token 数量，但也会增加草稿开销和验证成本。

通过 vLLM 的 /metrics 端点监控接受率（spec_decode_acceptance_rate）。如果接受率保持在 70–80% 以上，增加 num_speculative_tokens 是合算的。低于 50% 时，减少该值或禁用投机。

高并发注意事项：在高每秒查询数（QPS）下，投机解码会消耗额外的 GPU 算力进行草稿生成和验证。在饱和情况下，开销会降低总吞吐量。考虑在重负载下禁用 MTP，仅在延迟敏感的单流请求时启用。

MTP 对内存受限的解码工作负载（长输出、低批大小）效果最好——正是带长 <think> 跟踪的 AI 智能体推理任务的典型模式。

内存与上下文长度

--gpu-memory-utilization（默认：0.9）控制 vLLM 预分配给 KV-cache 的 GPU 内存比例。对于 NVFP4 的 Qwen3.8，模型权重约占 GPU 内存的 57%，剩余约 43%（约 900 GB）用于缓存和开销。调优：

保持 0.9 以获得最大吞吐量（更多 KV-cache 槽位 = 更多并发请求）。

如果在长上下文请求期间遇到内存不足（OOM）错误，可降至 0.85。这会牺牲批处理容量，但有助于防止内存抢占级联。

--max-model-len 限制 vLLM 可接受的最大序列长度。设置低于模型完整 262K 上下文的长度，可为更短请求释放更多 KV-cache 槽位，提高并发。设置为与实际工作负载最大上下文需求匹配的值。例如，典型编码 AI 智能体用 32,768，长文档分析用 131,072。

批处理与调度

--max-num-seqs（默认：256）限制批次中的并发序列数。对于每个 token 计算量大的 MoE 模型，将其降至 64–128 可减少调度开销，并确保每个请求获得足够的 GPU 注意力，以每请求延迟的牺牲换取更好的单请求延迟（在聚合吞吐量方面会有损失）。

--max-num-batched-tokens 控制每次调度步骤的总 token 预算（预填充 + 解码合并）。vLLM V1 默认使用分块预填充。大预填充被拆分为多个块，并与解码步骤交织：

较低的值（例如 8192）提供更好的 Token 间延迟（ITL），因为解码不会被大预填充阻塞。

较高的值（例如 32768+）带来更好的 TTFT，因为每批次处理更多预填充 token。

对于混合短请求和长请求的 AI 智能体工作负载，从 16384 开始，根据观察到的 P99 ITL 进行调整。

MoE 后端选择

--moe-backend auto 让 vLLM 选择最优内核。在 Blackwell GPU 上，这通常会选择融合 MoE 内核，将稀疏专家视为一个整体集合而不是单独的专家。这种配置在服务 MoE 模型时提供更高的每 GPU 吞吐量。