超大规模稀疏模型开源：万亿参数推理成本再下探

一、开源大模型的新变量：参数规模不再是唯一焦点

过去一年，开源大模型社区对“最大参数规模”的关注正在降温。原因并不复杂：当模型总参数量突破万亿级别后，如果每次推理都必须激活全部参数，那么部署成本、显存需求与首 token 延迟都会迅速超出多数团队的承受范围。于是，行业讨论逐渐从“总参数量有多大”，转向“实际推理时激活多少参数”“长上下文是否真正可用”以及“许可证是否允许企业安全商用”。

在这种背景下，最新开源的一类超大规模稀疏模型提供了一个值得长期跟踪的样本。该模型总参数量达到 2.8 万亿，但并非每个 token 都激活全部权重，而是采用混合专家结构，在推理时只激活其中约 1040 亿参数。这种设计使模型在保持较高表达容量的同时，显著降低单次推理的计算密度。

更重要的是，其权重以接近 MIT 许可的方式开放，允许个人与企业免费使用、修改、二次分发和商用。对于希望在自己的基础设施或云上环境中部署大模型的企业来说，这种许可边界相对清晰。

二、混合专家结构：用“稀疏激活”换取推理效率

超大规模稀疏模型的核心思路，是让不同输入 token 激活不同的专家子网络，而不是让整个网络对每个 token 都执行完整前向计算。

在一个典型的混合专家模型中，前馈层会被拆分为多个专家模块，同时引入一个门控机制。门控根据 token 的表征，从众多专家中选择若干个进行计算，其余专家不参与本次 token 的前向过程。这样做的好处是，总参数量可以做得很大，从而提升模型容量；但每一步实际参与计算的参数量相对有限，推理延迟和显存带宽压力因此降低。

以本次开源的模型为例，总参数 2.8 万亿，而每个 token 激活约 1040 亿参数。也就是说，在任意一次前向计算中，只有约 3.7% 的参数处于活跃状态。这种稀疏性并不等同于模型能力被削弱，而是将能力分散存储在不同专家中，再根据输入动态调度。

对于开发者而言，这种结构带来几个直接收益：

1. 推理吞吐提升：在相同硬件条件下，相比激活同等规模稠密参数，混合专家模型可以获得更高的 token 吞吐。
2. 显存利用更灵活：虽然完整权重仍然需要较大存储空间，但计算设备不需要在每一步同时加载全部参数。
3. 扩展路径更平滑：当需要增加模型容量时，可以优先扩展专家数量或专家宽度，而不必线性增加每个 token 的计算量。

不过，混合专家结构也并非没有工程门槛。专家负载均衡、通信开销、权重切分策略都会影响最终训练与推理效率。尤其是当模型部署到多卡甚至多节点时，门控调度与专家并行之间的通信模式，往往比稠密模型更复杂。

三、长上下文优化：从全注意力到稀疏注意力

长上下文能力是大模型走向复杂文档分析、代码库理解和长周期智能体任务的关键。然而，传统全注意力机制的显存与计算开销会随着序列长度呈二次方增长。对于 100 万 token 级别的上下文窗口来说，如果每个 token 都对所有历史 token 做全注意力计算，实际成本难以接受。

本次开源的模型在长上下文处理上做了一个重要调整：将部分层从“全注意力”替换为“稀疏注意力”。在稀疏注意力机制下，每个 token 不再与全部历史 token 交互，而是仅从上下文窗口中选择最相关的若干 token 进行计算。以该模型的设计为例，每个 token 只挑选约 2048 个相关 token。

这种做法的核心假设是：在处理超长序列时，并非所有历史 token 对当前 token 都同等重要。很多 token 只需与局部邻域或少数关键片段交互，就能完成大部分语义理解。稀疏注意力将“全局注意力”的完备性，替换为“相关注意力”的工程可实现性。

从工程角度看，稀疏注意力带来两个明显变化：

• 计算复杂度下降：长上下文的注意力计算不再随序列长度平方增长，而是趋向于与序列长度线性相关。
• 长文本推理可行性提升：在相同硬件下，模型可以处理更长的输入，同时避免显存快速耗尽。

需要注意的是，稀疏注意力并不是万能的。对于需要全局精确匹配的任务，例如长距离指代或复杂逻辑推理，稀疏注意力可能引入信息损失。因此，很多长上下文模型会采用混合策略：部分层保留全注意力，部分层使用稀疏注意力，以在效率与效果之间取得平衡。

四、智能体与终端任务：模型能力的新考场

除了传统文本理解与生成任务，终端智能体正在成为衡量大模型实用价值的重要场景。所谓终端智能体，是指让模型在命令行或终端环境中执行操作，例如查看文件、运行脚本、修改配置、调试程序等。这类任务要求模型具备多步规划能力、环境理解能力和错误恢复能力。

在 Terminal-Bench 4.0 的独立测试中，本次开源的超大规模稀疏模型取得约 63.64% 的成绩，在 59 个受测模型中排名靠前。更值得关注的是成本指标：该模型平均每题花费约 4.57 美元，而部分表现相近的闭源模型需要 13 美元以上，差距接近 3 倍。

这种“高得分、低成本”的组合，对于企业自动化流程具有实际意义。终端智能体任务通常需要反复调用模型、维持长上下文状态，并对推理成本高度敏感。如果模型每次执行一个多步终端任务都要消耗大量费用，那么即使成功率很高，也难以规模化落地。

对开发者来说，评估智能体能力时不能只看最终通过率，还应关注：

• 单任务平均步骤数：步骤越多，通常意味着模型规划不够稳定或环境中反馈不够清晰。
• 错误恢复能力：当命令失败或输出不符合预期时，模型能否根据报错调整下一步操作。
• 成本稳定性：同一个任务在不同输入下，推理 token 消耗是否可控。
• 安全边界：在终端环境中执行操作时，模型是否能够识别高风险命令并谨慎决策。

在这些维度上，开源模型的优势在于，企业可以在自己的环境中加入权限控制、命令白名单和审计日志，而不必把敏感终端操作完全交给外部闭源服务。

五、开源许可与商用确定性

大模型开源并不等同于“可以放心商用”。很多模型的许可证会对用户规模、商业用途、竞争条款或二次分发做出限制。因此，企业在选择开源模型时，许可证条款往往与模型能力同等重要。

本次开源的模型，其许可证主体部分沿用 MIT 协议的写法。这意味着：

• 个人和企业可以免费使用；
• 可以修改模型权重；
• 可以二次分发；
• 可以用于商业用途。

这种许可方式显著降低了企业的法律审查成本。团队不需要在法务层面反复确认模型是否只能用于研究、是否限制月活用户数、是否禁止与某些产品竞争等。对于希望快速搭建原型、随后转向生产环境的中小团队来说，这种确定性非常有价值。

当然，即使许可证接近 MIT，企业在实际部署时仍应关注数据集来源、模型输出合规性以及下游应用场景中的额外法律要求。开源许可解决的是权重使用与分发权限，并不能覆盖所有业务层面的合规风险。

六、云上部署与私有化落地的工程考量

对于普通开发者或中小型企业，直接从头部署万亿参数模型并不现实。更常见的方式有两种：一是通过云平台提供的模型服务按量调用；二是在自有或租用的 GPU 集群上进行私有化部署。

如果选择云上推理，开发者通常不需要关心权重切分、专家并行和显存优化等底层细节，只需通过 API 提交请求。此时需要重点关注的是：

• 单次请求的输入输出 token 费用；
• 长上下文请求的首 token 延迟；
• 并发能力与限流策略；
• 数据是否会被用于后续训练；
• 日志与审计能力是否满足行业要求。

如果选择私有化部署，则必须认真评估模型权重体积、推理框架支持、显存容量与多卡互联带宽。以 2.8 万亿总参数、1040 亿激活参数为例，仅权重存储就需要数百 GB 级别的空间，具体取决于量化方案。多卡部署时，如何平衡专家并行与张量并行，如何减少门控调度带来的通信抖动，都会直接影响推理吞吐和延迟。

一种常见的优化思路是先对权重进行低比特量化，再结合专家缓存与稀疏注意力索引，把长上下文场景下的活跃显存控制在合理范围。需要注意的是，量化对模型输出质量的影响需要在具体任务上重新评估，不能简单沿用全精度模型的经验。

七、对开发者与大模型选型的启示

超大规模稀疏模型的开源，给开发者带来一个新的选型参考。相比过去单纯追求参数规模，现在的选择逻辑更强调实际推理成本与任务匹配度。

对于文档处理、代码分析、长报告总结等任务，稀疏注意力与混合专家结构可以在较长上下文中保持可接受的推理成本。对于终端智能体类任务，模型的多步规划能力、错误恢复能力以及单任务成本，往往比纯粹的文本生成质量更重要。对于企业应用，许可证清晰度和私有化部署能力则是决定能否进入生产环境的门槛。

可以预见，未来一段时间内，开源大模型的技术竞争将集中在三个方面：

1. 更高效的稀疏结构：如何在保持模型容量的同时，进一步降低激活参数比例。
2. 更稳的长上下文推理：让稀疏注意力在效率提升之外，尽可能接近全注意力的语义保真度。
3. 更透明的成本结构：让开发者在选型时，能够直接评估单任务成本、首 token 延迟与并发性能。

当“开源”逐渐成为大模型生态的基础属性时，真正的竞争会回到工程能力与应用落地效率上。对于开发者而言，理解模型背后的结构与许可逻辑，比记住某个具体版本号更为重要。