Gemini3.1Pro的MoE架构解密
Google在2026年2月19日发布的Gemini 3.1 Pro,官方明确将其定义为"稀疏混合专家模型(Sparse Mixture of Experts)"。

接下来我们把重点放回技术本身——MoE架构在大模型领域已经不新鲜,但3.1 Pro在路由策略上做了一些值得拆解的选择。
MoE的核心问题:不是"有多少专家",而是"谁来干活"
先厘清一个基本概念。MoE架构的核心思路是:模型内部包含多个"专家子网络",每次推理时并非所有专家都参与计算,而是由一个"路由器"(Router/Gate)根据输入内容动态选择激活其中一部分。这带来一个关键优势——模型的总参数量可以很大(存储大量知识),但单次推理只激活一小部分参数(控制计算成本)。
难点在于路由策略。选对了专家,模型又快又准;选错了,不仅浪费算力,还可能输出质量下降。这就是为什么各家在MoE架构上的核心竞争力,往往不在参数规模,而在路由机制的设计。
Gemini 3.1 Pro的"稀疏"到底有多稀疏
Google官方只披露了3.1 Pro是"稀疏MoE模型",但没有公开具体的专家数量、每层激活比例等关键参数。这种信息留白在Google的发布策略中很常见——竞争对手无法精确复现,社区也只能从性能数据反推架构特征。
不过,从3.1 Pro的性能表现可以做一些合理推断。它的推理成本与前代3 Pro持平(2/2/12 per million tokens,200K以内),但ARC-AGI-2得分从31.1%跃升到77.1%,GPQA Diamond达到94.3%。在定价不变的前提下实现这样的性能跳变,大概率意味着路由效率的显著提升——同样的计算预算下,模型把算力分配给了更相关的专家。
差分注意力:路由策略的另一块拼图
3.1 Pro官方技术说明中提到了一个关键词——"差分注意力"(Differential Attention)。这个机制在2024年微软研究院的论文中被提出,核心思路是用两组注意力分数做差分运算,消除噪声信号,让模型更精准地聚焦于真正相关的信息。
把差分注意力和MoE放在一起看,逻辑就通了。路由策略本质上是一个分类问题——给定当前token,应该分配给哪个专家?差分注意力可以帮助路由器更准确地判断输入内容的特征,从而做出更精准的专家选择。这或许可以解释为什么3.1 Pro在长上下文任务中的表现格外突出——当输入达到百万token级别时,噪声过滤能力直接决定了路由质量。
三级深度调节:把路由选择权交给用户
3.1 Pro在API层面新增了一个值得关注的参数——思维深度级别(Low / Medium / High)。这个设计表面上看是推理时长控制,但从架构角度看,它实际上是在调节MoE的激活策略。
低深度模式下,模型可能只激活少数核心专家,快速给出响应;高深度模式下,更多专家参与计算,模型在多个"思考路径"之间做更充分的比较和验证。对于开发者来说,这意味着可以根据任务复杂度灵活选择:日常代码补全用Low,复杂架构设计用High,在速度和质量之间找到自己的平衡点。
没有公开的部分:我们在等什么
坦率地说,Google在MoE架构细节上的信息披露相当有限。专家总数、每层Top-K激活比例、路由器的训练目标函数、专家负载均衡策略——这些决定架构效率的核心参数,目前都没有官方说明。
社区中已有一些基于推理行为的逆向分析,比如通过观察不同输入长度下的延迟变化来推测激活专家数量的变化模式。但这类分析受限于黑盒测试的天然局限,结论只能作为参考。
Google大概率会在后续发布技术论文时披露更多细节。在那之前,与其猜测具体数字,不如关注一个更本质的问题:3.1 Pro用同等成本实现了远超前代的性能,这说明MoE架构在路由策略上的优化空间仍然很大。对于正在做自研模型或MoE相关研究的团队来说,这本身就是一个值得深入跟踪的信号。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐

所有评论(0)