万亿参数 MoE 模型权重开放下载：架构、部署与调用全解析

大模型的能力竞争正在从”榜单排名”转向”可获得性”。当一个总参数达到万亿级别的混合专家（MoE）模型把完整权重放到公开模型仓库上，对开发者而言真正的变化不是又多了一个可以调用的接口，而是多了一条可以审计、可以微调、可以私有化部署的技术路径。本文围绕一次典型的万亿级 MoE 权重开放事件，拆解其结构设计、量化存储方案、部署门槛与调用细节，为计划自建推理服务的团队提供一份可执行的技术参考。

一、开放权重意味着什么

过去一年，头部模型多以 API 形式对外提供能力，权重不公开，开发者只能在其划定的接口边界内使用。权重开放则把三件事同时交给了使用方：

• 可审计性：结构配置、专家数量、层类型、精度方案都可以直接读取配置文件核实，而不是仅凭官方描述。
• 可微调性：可以在自有数据上做继续预训练或参数高效微调，把通用能力对齐到垂直领域。
• 可私有化：数据不出内网，推理链路自主可控，满足合规与数据主权要求。

这次开放的是一个总参数约 2.8 万亿、单 token 激活约 104B 的 MoE 模型，支持百万级 token 上下文与图文输入。模型仓库显示权重占用约 1.56TB，权重文件统计的参数量约 2.78 万亿。对想要自建推理服务的团队来说，这是一份”可以真正落地”的资产，但同时也是一份对硬件和工程能力要求极高的资产。

二、结构设计：稀疏注意力与细粒度专家

2.1 层级构成

从公开的模型配置看，整体为 93 层结构，其中 69 层采用线性注意力类模块（KDA），24 层采用门控稀疏注意力（Gated DSA）。这一代的关键变化在于：把原先的全注意力门控 MLA 层替换为门控稀疏注意力层，目标是在长上下文场景下显著降低注意力计算与显存开销。

长上下文建模的成本主要来自注意力矩阵随序列长度平方增长。稀疏注意力通过让每个 token 只关注一部分历史位置，把复杂度压到更可控的量级；而”门控”机制则让模型自行学习在不同层、不同位置应当聚合多少信息，避免稀疏化带来的信息损失。两者结合，是在百万级上下文下维持可用推理成本的主流工程思路。

2.2 专家层配置

专家层共 896 个专家，每个 token 路由选择 16 个，另设 2 个共享专家。这组数字值得注意：

• 专家数量多、单专家容量小：896 个专家的细粒度切分提升了参数利用率，使不同语义领域的 token 能路由到更专门的子网络。
• 激活专家数 16：相比早期 MoE 常见的 top-2 路由，top-16 的单 token 计算量明显更高，但换来了更强的表达能力和更平滑的路由分布，训练稳定性更好。
• 共享专家：始终参与计算的共享专家承担通用知识，减少各路由专家之间的知识冗余，这是近期 MoE 设计中较为普遍的实践。

由此形成的参数账目是：总参数 2.8 万亿，单 token 实际参与计算的约 104B。换句话说，推理时的算力开销大致对应一个千亿级稠密模型，而知识容量来自万亿级参数池。这正是 MoE 的核心价值主张，也是它能在效果与成本之间取得平衡的原因。

2.3 视觉通路

多模态部分由一个约 401M 参数的视觉编码器承担，负责图像输入的特征提取，再与文本 token 在统一序列中联合建模。相对于主干网络的体量，视觉侧参数占比很小，属于”轻编码器 + 重主干”的典型搭配。

三、量化方案：MXFP4 存储与 MXFP8 激活

权重以 MXFP4 格式存储、激活使用 MXFP8，官方说明训练阶段引入了量化感知训练（QAT）。这组选择直接决定了 1.56TB 这个仓库体积。

粗算一下：2.78 万亿参数若以 4 bit 存储，理论下限约 1.39TB，加上缩放因子、元数据与部分非量化张量，落在 1.56TB 是合理的。若不量化，以 16 bit 存储将需要约 5.5TB 以上，绝大多数团队连下载和加载都会成为问题。

几个工程要点值得展开：

1. 存储与计算精度分离：权重用 4 bit 存放以压缩体积和显存占用，计算时反量化到 8 bit 激活精度，在吞吐与数值稳定性之间取折中。
2. 量化感知训练的必要性：4 bit 权重若直接对训练后模型做训练后量化，精度损失通常难以接受。QAT 在训练过程中模拟量化误差，让模型参数分布主动适应低精度表示，这是万亿级模型敢用 4 bit 存储的前提。
3. 微调的现实约束：在 4 bit 权重上做微调，通常采用低秩适配（LoRA 类）方案，只训练少量附加参数，避免全参数更新的显存爆炸。计划微调的团队应优先确认推理框架对量化权重加适配器的支持程度。

四、本地部署：硬件门槛与框架选择

4.1 硬件估算

第三方技术社区的估算给出了一种可行配置：8 张高端数据中心 GPU、约 2.3TB 显存总量的服务器，整机硬件成本大致在 55 万至 65 万美元区间。需要强调这是第三方推算，官方并未给出硬件建议，实际需求取决于并发量、上下文长度与是否启用 KV Cache 优化。

从工程角度看，显存占用大致由三部分构成：

• 权重常驻：1.56TB 量级的权重需要分布在多卡上，单机 8 卡是常见起点；
• KV Cache：百万 token 上下文下，KV Cache 会成为不可忽视的开销，稀疏注意力结构正是为压制这部分成本而设计；
• 激活与临时缓冲：随批大小和序列长度变化。

这也解释了为什么这类模型的自建门槛不在于”能不能跑起来”，而在于”能不能在可接受的并发和延迟下跑起来”。

4.2 推理框架支持

主流的高吞吐推理框架、结构化生成框架以及面向低延迟的服务框架，均已针对该模型给出部署方案（recipe）。落地时的通用路径大致如下：

# 通用部署流程示意（以容器化推理服务为例）
# 1. 拉取模型仓库权重（约 1.56TB，建议内网镜像或高速通道）
# 2. 校验权重文件完整性与分片索引
# 3. 按框架文档配置张量并行度、量化后端与 KV Cache 策略
# 4. 启动推理服务并做小批量冒烟测试
# 5. 逐步提升并发，观察首 token 延迟与吞吐曲线

工程上建议注意几点：张量并行度需与卡数匹配；量化后端要显式开启以走通 4 bit 权重加载路径；长上下文场景下应优先启用分页 KV Cache 与前缀缓存，否则重复的系统提示会反复占用显存。

五、托管调用：接口与参数细节

不愿承担自建成本的团队可以走托管接口。该模型提供标准版与高速版两个模型标识，后者官方称速度约为标准版的 2 到 3 倍，适合对延迟敏感的在线场景；标准版更适合批量离线任务。

接口层面兼容两套主流的请求协议风格，迁移成本较低。几个容易被忽略但直接影响效果的细节：

• 推理强度参数：reasoning_effort 可选 low、high、max，默认为 max。对简单任务下调该参数可显著减少思考 token 消耗、降低成本与延迟；复杂推理任务则应保持高值。
• 多轮工具调用：把上一轮的 reasoning_content 与 tool_calls 一并回传是正确做法。遗漏思考内容会导致模型丢失中间推理链路，在多步工具编排中表现为重复调用或逻辑断裂。

# 多轮工具调用回传结构示意
messages.append({
    "role": "assistant",
    "content": previous_content,
    "reasoning_content": previous_reasoning,   # 必须回传
    "tool_calls": previous_tool_calls           # 必须回传
})

六、选型建议：自建还是托管

给出一个可操作的判断框架：

维度	自建部署	托管调用
数据合规	数据完全不出内网	依赖服务方合规承诺
前期投入	硬件数十万美元级 + 运维人力	按 token 计费，无固定资产
定制能力	可微调、可改结构、可审计	仅限接口参数
弹性	扩容周期长	即时弹性
适用场景	长期高频、强合规、需深度定制	验证期、波动负载、快速上线

比较务实的路径是：先用托管接口做效果验证与成本测算，确认业务价值后再评估自建。若选择自建，建议先做单机小并发压测，拿到真实的显存占用与延迟数据，再决定采购规模——万亿级模型的硬件账，纸面估算和实测往往有可观偏差。

权重开放的意义，最终不在于参数数字的大小，而在于它把”能力”变成了”可工程化的组件”。对开发者而言，真正要回答的问题始终是同一个：这套组件的成本结构，是否匹配你的业务负载。