是什么：Qwen3.8-2.4T-A95B 是什么
Qwen3.8-2.4T-A95B 是 Qwen 团队在 2026 年 8 月 12 日发布的旗舰级开源权重大模型，也是 Qwen-Max 系列首次以开源权重形式公开的版本。它总参数量达到 2.4 万亿，但每次前向计算只激活约 950 亿参数，属于典型的细粒度混合专家（MoE）架构。
该模型采用了一种"线性注意力 + 全注意力"的混合架构，整体由 92 层组成，其中 69 层为带门控的 DeltaNet（线性注意力，用有界循环状态替代不断增长的 KV-cache），23 层为带门控的全注意力层，二者按 3:1 的比例交替排布。原生长上下文为 262K tokens，可扩展至 1M tokens；最大输出长度为 128K tokens。
关键能力与技术原理
细粒度 MoE 与容量分配。模型包含 512 个路由专家加 1 个共享专家，每 token 实际激活 10 个路由专家。这种设计把容量分散到大量小专家中，有助于提升路由效率与任务专精度；同时服务成本主要由激活参数决定，而非全部 2.4T 参数。
混合注意力与长上下文。69 层 DeltaNet 用固定大小的循环状态替代传统 KV-cache，23 层全注意力层保留高保真度的 token 交互。这种结构使得只有 23 层对 KV-cache 的增长有贡献，其余 69 层在上下文变长时内存基本保持稳定。这对会积累工具输出、代码与推理过程的智能体工作流尤为关键。
原生多 token 预测（MTP）。模型在训练阶段就内置了 MTP 草案头，因此无需额外下载或配置单独的草案模型即可启用投机解码，草案头复用主模型的隐状态，单次前向可验证多个 token，从而提升吞吐。
内置推理控制与工具调用。通过 reasoning_effort 参数（low/medium/high）可按请求粒度调节推理深度；模型支持 OpenAI 兼容的 function calling，提供 auto/required/none/具名函数四种 tool_choice 策略，并允许结构化输出（guided_json、guided_regex）与推理共存。
量化与显存预算。BF16 下 2.4T 参数的权重约需 4.8 TB 显存，超出单个 8 卡节点的容量。NVFP4（W4A4）量化把权重压到约 1.2 TB，可以放入 8 张 B300（合计约 2.1 TB HBM3e）的单节点中，并为 KV-cache 与激活留出余量。粗略显存分配为：权重约 1.2 TB、全注意力层 KV-cache 随上下文变化、DeltaNet 循环状态固定约 50–100 GB、激活与开销约 100–200 GB，剩余约 500–700 GB 给批处理与更长上下文使用。
与上一代的差异
与 Qwen 家族之前的开源版本相比，Qwen3.8-2.4T-A95B 主要在以下几个维度发生了显著变化：
- 规模跃升：进入"万亿级参数"行列，总参数 2.4T、激活 95B，定位为 Max 级旗舰。
- 架构升级：引入 3:1 的 Gated DeltaNet + Gated Attention 混合结构，原生支持 262K、可扩展至 1M 的上下文。
- 智能体能力：内置 MTP 投机解码、
reasoning_effort推理档位调节和 OpenAI 兼容的工具调用，把模型从纯文本生成器进一步推向可执行长链路任务的智能体底座。 - 开放策略：首次以完整 Max 级权重开源，允许数据留在自有基础设施内、定制推理行为，并在规模化场景下摆脱按 token 计费的 API 成本，代价是承担部署与运维。
需要说明的是，关于其相对前代在推理质量、长程任务可靠性等方面的具体提升幅度，公开材料并未给出系统对比数据；上文的差异更偏架构与定位层面的描述。
适用场景
官方基准测试结果显示，Qwen3.8-2.4T-A95B 在研究类工作流（PaperBench 93.0）、指令遵循（IFBench 82.8）和终端类编码任务（86.6）上表现突出，与主流前沿模型整体相当；同时在仓库级编码（SWE-bench Pro）和通用工具使用（Toolathlon）上仍有一定提升空间。
基于以上特点与架构属性（事实层面），以下场景与之契合度较高（属于推断与建议）：
- 多步骤编程与代码生成、终端自动化类任务；
- 需要在长上下文中持续累积工具输出与推理轨迹的智能体；
- 复杂研究类工作流，例如论文级综述与多阶段信息整合；
- 对数据出域敏感、希望把推理能力留在自有基础设施内的企业自托管场景。
对于简单的短文本生成或对延迟极敏感的高并发在线服务，单 token 激活 95B 的 MoE 并不一定是最经济的选择，需结合吞吐量目标综合评估。
技术使用方式与上手建议
如何用起来
Qwen3.8-2.4T-A95B 的接入路径有两种主要形态：
- 通过 API 端点接入：在 SageMaker HyperPod 上完成部署后，模型会暴露一个 OpenAI 兼容的
/v1/chat/completions端点，可使用标准 OpenAI SDK 直接调用，按需传reasoning_effort、工具定义与结构化输出约束。 - 自托管开源权重：模型权重以标准 Transformers 格式发布在 Hugging Face，社区提供 MXFP4 与 NVFP4 两种量化方案。NVFP4 量化版本（社区 ID 形如
Inferact/Qwen3.8-2.4T-A95B-NVFP4）约 1.2 TB，可放入单台 8 卡 B300 节点，使用 vLLM 启动服务。
部署前置条件
要在 SageMaker HyperPod 上自托管该模型，需要满足以下条件：
- 通过 Amazon SageMaker 控制台创建一个由 Amazon EKS 编排的 HyperPod 集群，并启用默认 Helm chart 与 Add-on，以确保安装 HyperPod Inference Operator；
- 由于
ml.p6-b300.48xlarge不支持按需容量，必须先通过 Flexible Training Plan 预留 GPU 容量，并在实例组配置中将容量来源设为"Training plan"，目标可用区与计划一致； - 至少配置 1 个
ml.p6-b300.48xlarge实例组，等待集群进入 Active 且 GPU 节点健康后即可开始部署。
vLLM 启动与关键参数
单节点 8 卡部署时，常用的 vLLM 启动参数组合包括：--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}' 启用原生 MTP 投机解码。其中：
enable-prefix-caching对多轮智能体对话非常关键，因为系统提示与历史消息会重复出现；num_speculative_tokens建议从 1 开始，验证高接受率后再逐步提升到 2–3；- 推理默认开启，可在客户端通过
extra_body={"chat_template_kwargs": {"enable_thinking": False}}按请求关闭； - 结构化输出约束只作用于最终
content字段，不影响reasoning_content。
上手路径建议
- 先在 SageMaker HyperPod 上以 1 个
p6-b300节点部署 NVFP4 量化版本，验证 OpenAI 兼容端点与工具调用链路； - 通过
/metrics端点观察投机解码接受率，必要时调整num_speculative_tokens； - 利用推理数据捕获功能记录输入输出，作为后续评估与回归测试的基础；
- 当并发上升、出现 P99 延迟抖动时，再评估是否启用 Disaggregated Prefill and Decode（DPD）等扩展特性。
局限与边界
- 硬件门槛高：
ml.p6-b300.48xlarge仅通过预留容量获取，且必须使用 Flexible Training Plan，对小规模或试验性部署而言成本与采购周期都不友好。 - 量化与精度折损：NVFP4（W4A4）在把权重压到 1.2 TB 的同时会带来精度损失，量化版本的输出质量需要在自身业务数据上做充分回归。
- 冷启动与下载时间：首次部署需要从 Hugging Face 下载约 1.2 TB 权重，整体序列（含模型下载、权重加载、健康检查）通常需要 15–30 分钟；后续可借助本地 NVMe 缓存显著缩短重启时间。
- 吞吐上限：作为参考，NVIDIA 在 GB300 NVL72（FP8、72 卡）上给出大于 4K tokens/sec/GPU 与大于 350 tokens/sec/user 的数字；单节点 8 卡 p6-b300 在 NVFP4 下聚合吞吐会按比例下降，适合中等并发，不适合超大规模在线推理。
- 能力仍有短板：官方基准显示在仓库级编码（SWE-bench Pro）与通用工具使用（Toolathlon）上仍有提升空间，复杂代码工程与开放域工具编排任务仍需结合外部评估谨慎上线。
- 运维成本：自托管意味着团队需要承担容量采购、节点替换、监控与扩缩容等长期运维责任，与使用托管 API 模式相比，运维复杂度显著上升。
如何用起来：通过 OpenStarry 接入
如果你想直接用上 qwen 这类模型/工具，可以通过 OpenStarry 用一个 Key 快速接入，无需各自注册多个平台：
- 一个 Key 接入 13 款模型，完整兼容 OpenAI SDK，两行代码即可迁移；
- 官方原厂通道与自动容灾，节点异常时自动切换；
- 按量付费、人民币结算，模型调用费用以 OpenStarry 官网标价为准。
接入示例：
base_url: https://api.openstarry.com/v1
api_key: <你的 OpenStarry Key>
model: qwen3.7-max