超大规模稀疏模型开源：万亿参数时代的架构、部署与商用许可解读

一、背景：万亿参数模型为什么值得重新讨论

大语言模型进入万亿参数区间后，能力的提升不再只依赖“堆参数”。更关键的问题变成：如何在训练成本、推理延迟、显存占用和实际任务表现之间取得平衡。过去一段时间，业界对“更大模型一定更好”的假设进行了多轮修正。部分中等规模模型通过高质量数据与精细训练策略，在特定任务上超过了参数规模更大的模型；而另一些超大规模模型则凭借新的结构设计，在保持能力上限的同时压缩了实际推理成本。

本次引发关注的，是一个总参数量达到 2.8 万亿、每次推理仅激活其中约 1040 亿参数的混合专家模型。它选择开放权重，并且许可证主体接近宽松开源协议，同时加入了面向大型 API 提供商和超级应用的补充条款。这一做法既延续了开放模型生态的惯例，也反映了当前大模型商业化进程中的现实考量。

从技术角度，这类模型最重要的信号是：超大规模模型正在从“实验室指标”走向“工程可用”。它是否值得企业试用，取决于架构合理性、长上下文处理能力、终端任务可用性、单位任务成本以及部署许可是否清晰。下文逐一拆解。

二、混合专家结构：大参数规模与可控推理成本的折中

2.1 总参数与激活参数的区别

在传统稠密模型中，前向计算会使用全部参数。例如一个 700 亿参数的稠密模型，每次推理都需要加载并计算所有参数。参数规模越大，显存需求和计算量通常也越高。

混合专家模型改变了这一前提。它将网络中的若干层拆分为多个“专家”子网络，每个专家只负责一部分输入。每次推理时，路由器会根据 token 特征选择少量专家参与计算。因此，模型可以拥有极大的总参数规模，却只激活其中一小部分。

以本次开源的模型为例：总参数 2.8 万亿，每次推理激活约 1040 亿。这意味着它的单次前向计算量更接近一个千亿级稠密模型，而不是直观感受中的“两万亿级模型”。训练阶段仍然需要足够算力支撑全部专家，但在推理阶段，这种结构显著降低了单位请求成本。

2.2 为什么专家数量与路由策略很重要

混合专家模型的质量不仅取决于总参数，还取决于专家划分粒度、路由稳定性和负载均衡。如果路由器总是把大部分 token 分给少数几个专家，其余专家得不到充分训练，模型能力就会退化。如果路由切换过于频繁，推理时又可能产生额外通信开销。

优秀的混合专家结构通常具备以下特征：

• 专家之间存在明确分工，不同专家对不同领域或不同语义模式敏感；
• 路由决策稳定，相似输入不会导致专家选择大幅波动；
• 训练过程中包含负载均衡约束，避免专家利用率两极分化；
• 推理时专家激活数量固定，便于工程上预估延迟和显存占用。

本次开源模型选择在部分层中引入专家并行结构，并将每次激活的参数量控制在 1040 亿左右。这种设计适合那些希望在单卡或少量多卡环境中运行大参数模型的团队，因为它比同规模稠密模型更容易做显存规划与推理优化。

2.3 工程上的意义

对企业开发者来说，混合专家结构带来的直接收益是推理吞吐的提升。即便总参数达到万亿级，单位请求所需算力仍可被控制在一定范围内。对于需要批量处理文档、日志、代码或客服对话的场景，这种结构比同能力等级的稠密模型更易于估算成本。

同时也要注意，混合专家模型在训练和微调阶段仍需较多资源。如果企业计划进行全参数微调或大规模持续预训练，成本仍然较高。更实际的做法通常是：使用开放权重进行推理，或在其上做轻量适配，而不是从零训练。

三、稀疏注意力：让百万级上下文变得更可行

3.1 全注意力在长上下文中的瓶颈

标准注意力机制的计算复杂度随序列长度呈平方级增长。假设序列长度为 L，隐藏维度固定，注意力矩阵的规模约为 L×L。当上下文从 8K token 扩展到 128K 或 1M token 时，计算量和显存占用会急剧上升。

即使采用 FlashAttention 等加速技术，底层复杂度仍然是平方级。这意味着，如果模型对每个 token 都完整关注全部历史 token，长上下文的推理成本会变得难以接受。

3.2 稀疏注意力的基本思路

解决思路之一，是不让每个 token 关注全部历史，只选择最相关的部分。主要方法包括：

• 滑动窗口注意力：只关注相邻的一定数量 token；
• 全局 token 注意力：在长序列中设置少量全局可关注的 token；
• top-k 稀疏注意力：为每个 token 动态选择相关度最高的前 k 个历史 token；
• 层次化注意力：先做粗粒度块选择，再做块内精确注意力。

本次发布的模型将部分原来的全注意力层替换为稀疏注意力层。每个 token 只选取最相关的约 2048 个 token 进行计算。这样处理长上下文时，计算复杂度从平方级大幅下降，百万 token 窗口的推理成本不再呈爆炸式增长。

3.3 对实际任务的影响

稀疏注意力并非没有代价。它要求模型学习如何筛选关键 token，否则可能遗漏重要信息。对于需要全局一致理解的复杂推理任务，稀疏注意力需要与其他机制配合，例如在关键位置保留若干全局 token，或在不同层中交错使用全注意力与稀疏注意力。

从工程收益看，稀疏注意力让长文档摘要、代码库理解、多轮法律合同分析等场景变得更具可行性。以往这些任务受限于推理成本和显存，很难在同一上下文中处理完整输入。现在，开发者可以在更长上下文中运行模型，而不必先将内容切成多个小段再拼接，从而降低分段带来的信息损失。

四、能力与成本：第三方评估说明了什么

4.1 综合智能评估

在第三方评测机构发布的综合智能指数中，该模型获得了 46.5 分。此前开放权重模型中表现较好的一个模型得分为 32.6 分。单从分数看，二者差距约为 14 分。由于该指数综合了多项能力指标，这一差距说明模型在多个维度上都有提升，而非仅在某项测试中占优。

需要谨慎看待的是，榜单分数不等于真实业务收益。第三方评测的测试集、提示方式与评分口径各有不同，企业用户应结合自身场景做小规模评估，例如选取数十条真实业务请求进行人工核验，观察模型的回答质量、格式稳定性与错误模式。

4.2 终端代理能力

另一个值得关注的测试是终端代理任务。该测试考察模型在计算机终端中执行真实操作的能力，例如查看文件、运行命令、修改配置、处理错误等。这类任务比单纯问答更接近“让 AI 干活”。

在该测试中，模型得分为 63.64%，在 59 个参评模型中排名第三，仅次于两家头部闭源模型。平均每题花费约 4.57 美元，而排名靠前的闭源模型所需成本约为其 3 倍。将“成功执行率”与“单题成本”放在一起看，该模型在终端代理方向上表现出较好的性价比。

4.3 成本为什么是模型能力的一部分

过去，模型选型常只看准确率或排行榜分数。随着大模型进入生产环境，单位任务成本、延迟和稳定性同样重要。一个分数略低但成本大幅下降的模型，在批处理、自动化脚本、终端操作等高频场景中可能更具实际价值。

预计未来模型评估会进一步从“静态能力分数”扩展到“单位成本下的任务完成率”。企业在选型时，也应当把推理成本纳入评估链路，而不是等到上线后才计算账单。

五、部署与使用建议

5.1 硬件规模预估

虽然推理时只激活约 1040 亿参数，但完整权重仍需要较大存储空间。以常见精度估算：

• 若使用 FP16 存储，每 10 亿参数约占 2GB；
• 1040 亿激活参数对应约 208GB 显存；
• 如果采用 8bit 量化，可降至约 104GB；
• 若采用 4bit 量化，则可能在约 52GB 左右。

这意味着在高质量量化条件下，少数高端 GPU 即可承载推理。如果使用多卡并行，还可进一步扩展上下文长度和吞吐能力。对于普通企业而言，更现实的方式是使用支持该类模型的云上推理服务，而不是自行采购硬件。

5.2 量化与推理优化

混合专家模型涉及路由器与专家网络两部分。量化时，路由部分通常需要保持较高精度，以免影响专家选择；专家网络则可承受更激进的量化。常见的工程实践包括：

• 对注意力层和路由器采用高精度；
• 对前馈专家层使用 8bit 或 4bit 量化；
• 使用专家并行，将不同专家分布到多张 GPU；
• 对长上下文任务启用稀疏注意力加速。

这些优化策略在各类开源推理框架中已较为成熟。开发者可以根据自身基础设施选择合适的推理引擎与量化方案。

5.3 使用场景建议

从当前公开的评估结果看，该模型较适合以下场景：

• 长文档理解与信息抽取；
• 终端代理与自动化任务执行；
• 代码补全与代码库级问答；
• 需要较强多模态图像理解的流程；
• 对推理成本较敏感的中等规模生产流量。

对于实时性要求极高的客服场景或轻量端侧任务，仍需评估具体延迟与成本。超大规模模型即使经过优化，在某些场景下仍可能不如更小的专用模型划算。

六、许可证：宽松开源与商业限制的边界

6.1 许可证主体

该模型权重采用与 MIT 协议相近的文本。MIT 协议以简洁著称，允许个人和企业免费使用、修改、复制、分发，也允许商用。本次开源在主体部分延续了这一思路，对绝大多数开发者和企业而言，可以免费商用。

6.2 两个额外限制

在宽松协议基础上，设置了两类补充条款。

第一类针对提供模型 API 的大型服务商。如果一家公司或其关联方通过 API 对外销售模型服务，且集团任意连续 12 个月总收入超过 2000 万美元，商用前需要与模型发布方另行签署协议。这一限制主要覆盖大型云平台和专职模型 API 提供商，对大多数企业自用或内部系统不构成障碍。

第二类针对超级应用。如果基于该模型构建的产品月活跃用户超过 1 亿，或月收入超过 2000 万美元，则需要在界面显著位置标注模型名称。该条款不禁止商用，只要求署名。

6.3 企业如何判断自身是否受影响

企业可依次检查以下问题：

• 是否在对外销售模型 API？若否，通常不受第一条限制；
• 是否通过官方产品、官方 API 或经认证的推理服务使用？若是，则不受影响；
• 自身产品月活是否超过 1 亿？若否，不需额外署名；
• 是否仅在内部系统调用？若是，基本可免费商用。

这种“主体宽松、对超大型平台另设条款”的模式，正在成为大模型开源的一种常见做法。它既保留了社区的开放体验，也对可能形成大规模商业变现的渠道保留了一定控制权。

七、开源与开放权重：概念澄清

有必要区分“开源”与“开放权重”。严格意义上的开源不仅包括权重，还包括训练数据、训练代码、数据处理流程、评估细节等。当前大多数大模型开放的是权重文件，并不等同于完整开源。

开放权限的价值在于：企业可以在本地或自有云环境中部署模型，无需把数据发送给第三方，也能基于权重做微调、适配和二次分发。对于数据合规要求较高的行业，例如金融、医疗、政务与大型制造企业，这一能力尤为重要。

同时，开放权重也意味着企业需要自己承担部署、安全、内容管理、模型更新等责任。模型不会自动适应业务数据，仍需通过检索增强、提示工程、监督微调等方式进行适配。

八、总结与展望

万亿参数模型走向开放权重，是大模型工程化的重要节点。混合专家结构让超大参数规模不再必然意味着不可承受的推理成本；稀疏注意力则为长上下文处理提供了更实际的路径；第三方评估显示其在终端代理等复杂任务中具备较强竞争力，同时单位任务成本明显低于部分闭源方案。

对于企业和开发者，关注点不应只停留在参数规模与榜单排名，更应关注：

• 模型是否适合自身业务场景；
• 部署所需硬件与推理成本是否可接受；
• 许可证是否覆盖计划中的使用方式；
• 数据合规与模型管理是否具备长期可行性。

正如这类模型的发布方所表达的那样，模型权重按时开放，只是大模型生态走向实用化的一步。后续更值得观察的，是围绕开放权重形成的推理工具、行业适配方案与企业部署实践。只有将能力转化为真实场景中的生产力，万亿参数模型才算真正落地。