超大规模 MoE 模型开放权重：2.8T 参数、104B 激活与百万上下文部署解读

一、这次开放权重意味着什么

近日，一个总参数约 2.8 万亿、单 token 激活约 104B 的混合专家模型正式开放完整权重。对于开发者和企业而言，这不仅是“可以下载模型文件”这么简单，更重要的是将模型结构、量化方式、推理部署、工具调用链路重新带回可控范围。

相比只能通过在线接口调用，开放权重至少带来三类工程收益：

1. 可私有化部署：适合数据敏感、合规要求严格或需要离线推理的业务场景。
2. 可微调与继续训练：团队可以基于自身领域数据做适配，而不是只能依赖固定行为。
3. 可审计与可调试：研究团队可以直接分析专家路由、注意力结构、量化误差和上下文外推表现。

这类规模的模型开放权重并不常见。它既涉及对混合专家结构的设计取舍，也涉及超大模型在真实硬件上的可部署性问题。下文会围绕这些点展开。

---

二、模型结构：MoE、稀疏注意力与视觉模块

该模型总参数约 2.78 万亿，但并非每个 token 都激活全部参数。它采用混合专家结构，每个 token 只激活约 104B 参数。这种设计大幅降低了单次推理的浮点计算量，同时保留了更大参数空间带来的表达能力。

模型共 93 层，其中 69 层采用一种键值缓存更省的长上下文注意力结构，另外 24 层采用门控稀疏注意力。传统全注意力层在处理超长序列时，键值缓存的显存占用会随序列长度显著增长。混合使用稀疏注意力，可以在长文档、长代码、多轮代理任务中降低缓存压力。

专家层共 896 个专家，每个 token 选择 16 个专家，同时存在 2 个共享专家。共享专家通常用于承载跨领域通用知识，而路由专家负责处理更具体的输入模式。与纯稠密模型相比，这种结构的单 token 计算更“窄”，但对路由稳定性和负载均衡要求更高。

视觉侧包含一个约 401M 参数的视觉编码器，使模型支持图文输入。因此，该模型并非纯文本模型，而是具备多模态输入能力。对于需要处理截图、扫描件、图表或文档版面理解的场景，这一点值得关注。

---

三、量化与存储：MXFP4 权重、MXFP8 激活

大规模模型最直接的约束来自显存和存储。该模型采用 MXFP4 保存权重，激活使用 MXFP8。官方说明使用了量化感知训练，意味着模型在训练或继续训练阶段已经考虑量化误差，而不是简单地对训练后权重做后处理。

从实际文件规模看，仓库约占用 1.56TB。这个数字对于个人开发者和小型团队来说压力很大，但对于拥有多卡服务器的企业场景，仍处于可管理范围。

MXFP4 与常见的 INT4 不同。它采用细粒度缩放方式，将浮点数据分块处理，在低位宽下尽量保留数值分布特性。MXFP8 则用于激活，能在推理速度和数值稳定性之间取得折中。对于千亿级参数模型，激活量化对显存占用和计算效率影响明显。

量化感知训练带来的一个实际好处是：部署端不再需要额外做复杂的量化校准，也不容易在极端输入下出现明显的精度塌陷。不过，这也会增加模型训练和重训的技术难度。

---

四、显存与硬件门槛：为什么需要多卡

根据公开信息，该模型仓库约 1.5TB，推理时还需为激活、键值缓存、通信缓冲和框架运行预留额外显存。以常见的高端加速卡为例，单卡显存通常在 80GB 到 192GB 之间，因此单卡无法承载完整模型。

一种可参考的硬件配置是使用 8 张高端加速卡，总显存达到 2TB 级别。这样可以在张量并行、流水线并行与专家并行的组合下完成加载和推理。第三方硬件成本估算约在几十万美元量级，但这只是硬件成本，尚未包含机房、供电、散热、运维与集群软件成本。

对于大多数团队来说，直接购买并维护这样一套服务器并不划算。更现实的选择通常包括：

• 使用云计算平台按需租用多卡实例；
• 采用模型并行方案，将专家分布到多节点；
• 如果业务延迟允许，使用量化加载与分片加载相结合；
• 仅部署模型的部分权重用于蒸馏、评估或离线批处理。

需要注意的是，硬件门槛不仅体现在显存总量上，还体现在卡间互联带宽。专家并行会频繁地在设备之间交换隐藏状态，若带宽不足，吞吐会受到明显拖累。

---

五、推理框架适配与部署思路

目前，主流的分布式推理方案已经提供部署配置。开发者可以选择支持大规模 MoE、量化权重加载和专家并行的推理框架。常见部署重点包括：

1. 张量并行与专家并行

对于超过单卡显存的层，需要按张量维度切分；对于专家层，则更适合按专家维度分布到不同设备。一个常见的组合策略是：

整体采用张量并行 + 流水线并行
专家层采用专家并行
注意力层根据序列长度选择重计算或缓存策略

2. 量化权重加载

由于权重本身以 MXFP4 保存，推理时需要框架支持对应格式的解量化计算。若框架不支持原生低精度计算，则需要先转换为可识别的分块表示，这会额外增加显存和启动时间。

3. 长上下文缓存管理

该模型支持百万 token 上下文，但真实部署中不能无限制地分配键值缓存。合理的策略包括：

• 根据请求长度动态分配缓存；
• 对超长输入采用分块预填充；
• 对历史轮次进行摘要或截断；
• 将缓存分布到多卡，避免单卡成为显存瓶颈。

4. 服务化封装

推理引擎可以进一步封装为模型服务，对外提供统一接口。工程侧通常需要处理请求排队、批处理、超时、重试、流式输出和并发限制。

---

六、API 接入与工具调用约定

如果团队暂时不具备本地部署条件，也可以使用模型服务。API 模型名已公开，兼容常见对话协议。服务商提供标准版与高速版，其中高速版宣称速度为标准版的 2 到 3 倍。

调用时需要注意推理强度参数。模型支持多档推理强度，默认使用最高档。对于简单任务，降低推理强度可以显著缩短响应时间；对于复杂多步任务，则可以保持高档推理。

该模型的多轮工具调用有一个关键约定：在多轮工具交互过程中，需要将上一轮的推理内容与工具调用结果一并回传。否则模型会丢失中间推理链，导致后续工具选择出现偏差。

下面是一个抽象化的接口调用流程示意：

用户输入
   │
   ▼
模型生成推理内容 + 工具调用
   │
   ▼
业务侧执行工具调用，得到结果
   │
   ▼
将上一轮的推理内容 + 工具调用结果 + 本轮输入
   │
   ▼
模型继续生成下一轮推理内容或最终答案

这个流程并不依赖特定平台，而是展示了长上下文代理任务中的状态保持逻辑。如果开发者自行封装服务，应特别关注中间推理内容的传递，避免仅保存工具结果而导致模型行为退化。

---

七、哪些场景适合考虑该模型

从能力定位看，该模型更偏向需要长上下文、多轮工具调用和复杂推理的任务。适合评估的场景包括：

• 大型代码库理解与跨文件修改；
• 长文档审阅、合同比对与知识库问答；
• 多步骤自动化任务，例如数据查询、报告生成与流程编排；
• 图文混合输入场景，例如截图分析、图表解释与界面理解；
• 需要私有化部署与领域微调的企业场景。

但如果业务只是简单分类、短文本生成或高并发低延迟服务，这类超大模型可能不是最优选择。部署成本、维护复杂度和响应延迟都需纳入评估。

---

八、能力边界与工程建议

该模型在开放模型评测中处于靠前位置，但这不意味着它在所有任务上都优于其他方案。对开发者来说，更稳妥的做法是基于真实业务样本构造评测集，而不是只看榜单分数。

在工程落地阶段，建议关注以下几点：

1. 先评估再部署：用离线批处理方式测试延迟、吞吐与显存占用。
2. 分层降级：简单任务使用低推理强度，复杂任务再切换到高推理强度。
3. 缓存复用：对于重复前缀或相似输入，复用键值缓存可以降低成本。
4. 监控专家负载：如果业务输入高度集中，可能出现专家负载不均，需要观察路由分布。
5. 做好回退机制：长任务可能中途失败，需要在服务层设计断点续传或状态恢复。

---

九、总结

这次开放权重，为希望掌握模型细节、私有化部署和面向领域微调的团队提供了较完整的基础材料。它的价值不只是“一个高分模型”，而是将混合专家结构、稀疏注意力、量化感知训练和长上下文工具调用能力放在了一个可下载、可检查、可改造的范围内。

但与此同时，1.5TB 级存储、2TB 级推理显存以及复杂的分布式部署要求，意味着它仍主要面向具备一定基础设施能力的团队。对于大多数业务场景，更现实的路径可能是先用在线接口验证能力边界，再在明确价值后考虑私有化部署与后续优化。模型越大，部署越不只是技术问题，而是成本、稳定性与业务收益之间的持续权衡。