不用英伟达，Gemini 3是如何训练的？

经过一年多的蛰伏，谷歌带着全新升级的多模态Gemini3来袭，前端UI升级性能拉满，虽然深度推理、上下文一致性等与ChatGPT5.1 thinking相比还有差距，但总体上已经能满足绝大多数用户的基本AI需求。

Gemini 3是如何训练的？是完全基于谷歌TPU吗？大家都在关注这些核心问题！

Gemini 3 = 稀疏 Mixture-of-Experts（MoE）Transformer + 原生多模态（文本/图像/音频/视频）+ 超长上下文（输入最多 1M token、输出 64k）+ RL 强化“多步推理/定理证明”的一整套栈，并且是用 Google 自家 TPU Pod + JAX + Pathways 从零训练出来的新模型。

下面分几层讲：架构、训练数据与流程、算力/系统设计，再讲一下“这套设计背后的逻辑”。

架构：稀疏 MoE Transformer + 原生多模态 + 超长上下文

1. 核心骨架：Sparse Mixture-of-Experts Transformer

官方模型卡直接写了：

• 架构 = 稀疏 Mixture-of-Experts（MoE）Transformer

• 原生支持文本、视觉（图像）、音频输入（视频通常拆成图像帧+音频序列送进来）。

MoE 的关键点：

• 每一层有很多“专家子网络”（experts）；

• 前面有个 routing/gating 子网络，对每个 token 决定送到哪几个专家；

• 每个 token 只激活少数几个专家，不是所有参数都跑一遍；

• 这样可以做到：总参数量很大（外界估计总体容量>1T 级）但单次推理算力成本可控。

相当于，不是每个问题都叫公司里所有员工一起开会，而是路由到 2–3 个最合适的小组来处理。

2. 原生多模态（Text + Vision + Audio + Video）

模型从设计上就是 “多模态优先”，而不是 “先做文本，再外挂一个视觉编码器”。文本 token、图像 patch、音频帧，都会进同一个 Transformer 主干，只是前端有不同的编码器，把不同模态统一到同一向量空间。Google 还在此基础上做了 Nano Banana Pro 这种图像模型，直接把 Gemini 3 Pro 当成图像生成/编辑的“主脑”。

这类原生多模态的好处：

• 可以跨模态推理：例如看视频+讲解文字，一起理解“这个实验为什么失败”；

• 对产品场景（搜索界面截图、代码+报错截图、讲课视频+PDF）非常友好。

3. 超长上下文：1M Token 输入、64k 输出

• 官方模型卡：输入上下文上限 1,000,000 token，输出上限 64,000 token。

• MarkTechPost 文章也确认了这点，并强调它是“让 agent 能吃完整代码库/长文档/多小时视频”的关键。

在实现上，Google 没公开全部细节，但结合他们开源的 Gemma 3 报告可以看出最近的思路：更多 local attention 层 + 更短的 local span，减少 KV-cache 爆炸；把“少量 global attention 层”用在关键信息汇总上。

所以你可以理解为：局部窗口里用 cheap 的 local attention，偶尔插一层“全局视角”做信息整合，再配合 MoE 把计算分散到不同专家上，共同支撑 1M context。

4. 和 Gemini 2.5 的差异

官方说得很清楚：

• 不是 2.5 的微调版，而是从头训练的新一代架构。

• 在各种推理、多模态、长上下文基准上，都显著超过 2.5 Pro。

训练数据：多模态 + 多来源 + 大规模清洗

1. 预训练数据构成

模型卡里披露得相当详细：

多模态、多领域的大规模语料：

• 公开网页文档 & 文本

• 代码（多种语言）

• 图像

• 音频（含语音和其他音频类型）

• 视频

数据来源类型：

• 公共可下载数据集

• 爬虫抓取数据（遵守 robots.txt）

• 商业授权数据（licensed）

• Google 产品中的用户数据 & 与模型的交互数据（在对应 TOS/隐私政策和用户控制下）

• Google 内部业务产生的数据

• AI 合成数据（synthetic data）

所以整体可以理解为：“公共互联网 + 授权版权库 + 自家产品行为日志 + 内部 & 合成数据” 的大杂烩，而且是多模态同步喂的。

2. 数据清洗与安全过滤

同一份模型卡也写了数据处理流程：

• 去重（deduplication）

• 遵守 robots.txt

• 各类 安全过滤（屏蔽色情、暴力、CSAM 等内容）

• 质量过滤，去掉垃圾/无关内容

这些既是安全要求，也是为了稳定训练（脏数据太多会直接拉垮收敛）。

训练流程：预训练 + 指令微调 + RL（人类 & critic 反馈）

官方没有给出超细节的损失函数和 schedule，但框架是比较典型的“三阶段”：

1. 阶段一：自监督预训练（大模型基座）

在上面那堆多模态数据上，做类似「下一个 token 预测」的自监督训练；文本/代码用标准的 autoregressive objective；图像/音频/视频通过适配的编码方式，把 patch/帧也当 token 来预测。

目标：学到通用语言+世界知识+多模态表征，不管任务、不管指令。

2. 阶段二：监督式指令微调（SFT）

• 用“人类写的高质量多模态指令数据”进行微调：

  • 问答、对话、代码生成、推理题目

  • 图文问答、视频理解、音频理解

• 这一步类似于把“会说话的大脑”变成“会听指令做事的助手”。

模型卡把这部分统称为 instruction tuning data。

3. 阶段三：强化学习 + 安全部署

Gemini 3 在 RL 上写得比之前代更直白：使用 reinforcement learning from human and critic feedback：

人类标注哪种回答更好；再加“critic 模型”自动给出评分；强化学习用到的内容特别强调：

• 多步推理数据

• 问题求解数据

• 定理证明类数据
  

也就是说，他们专门用 RL 把模型往“会慢慢推理、拆解问题、做数学/证明”这个方向拉。这也解释了：Gemini 3 在 Humanity’s Last Exam、ARC AGI 2 等高难度推理 benchmark 上比 2.5 和不少竞品强。

安全相关：他们把 数据过滤 + 条件预训练 + SFT + RLHF + 产品级安全过滤 都当成安全“层级防护”。并按照自家的 Frontier Safety Framework 做红队和能力评估。

算力与系统：TPU 全栈 + JAX + Pathways

这次 Gemini 3 的一个重要“元叙事”是：“不用 NVIDIA 也能在前沿”。

1. 硬件：完全用 Google 自家 TPU 训练

模型卡写得很清楚：

• 训练全部在 Google Tensor Processing Units（TPUs） 上完成；

• 使用 TPU Pods（大规模 TPU 集群），支持多设备分布式训练；

• 利用 TPU 的高带宽内存和大 batch 做到了更好的模型质量 + 能效。

外部文章因此强调：Gemini 3 证明了一条“自研芯片+自家云”的完整路径，可以在不依赖 GPU 供应链的情况下做到 frontier 级别。

2. 软件栈：JAX + ML Pathways

模型卡：训练用的是 JAX + ML Pathways。Pathways 是 Google 自己的多机多任务训练框架，比较适合这种 MoE + 超长上下文的大模型并行。结合 MoE 架构，你可以想象它在系统层面需要解决：

• 专家参数在 TPU Pod 上怎么切片/放置；

• token 的 routing 怎么跨设备做负载均衡；

• 超长上下文的 KV cache 怎么 sharding 和回收；

• 在这些约束下还要保证训练吞吐和稳定性。

这些实现细节没公开，但从他们强调的“sparse MoE + 1M context 实用化”可以看出，系统工程占了很大比重。

从“设计选择”看 Gemini 3 的几个洞察：

站在方法论角度，可以大概总结出 Google 这代模型的取向：

1. 容量 vs 成本：用 MoE 换算力效率

   想要万亿级参数的表达力，但又不能每 token 都烧满；Sparse MoE = “只叫对这件事最有用的几个专家出来”，能在相同算力下塞进更多知识和能力。

2. 场景优先：原生多模态 + 超长上下文 + agent 能力

   多模态 + 1M context，是为了直接吃：代码库、产品文档、UI 截图、视频课程、系统日志；

   再配合 Antigravity 这类 agent IDE 和“Generative UI”，把模型变成真正的“操作系统级助手”，而不是只会聊天。

3. 推理优先：在 RL 里刻意强化多步推理和定理证明

   很多 frontier bench（ARC AGI、GPQA、数学竞赛）都强调“要一步步想”；所以他们显式用这类数据做 RL，把 reward 设计成“慢想但答对”。

4. 安全与合规：从数据到产品的多层防护

   数据侧就做过滤；模型训练阶段用安全相关的目标和 RL 惩罚项；部署时再加 policy + 安全过滤 + Frontier Safety 评估。

5. 全栈一体化：TPU + 框架 + 模型 + 产品的协同优化

   完全在自家 TPU 上训练，用 JAX + Pathways 深度绑定硬件特性；再纵向整合到 Search、Workspace、Antigravity IDE、AI Studio 等产品里。

Gemini 3 更像是“用 TPUs 驱动的 MoE 多模态大脑”，通过庞杂但干净的多模态数据预训练，再用 RL 把“多步推理+Agent 行为”打磨到实战可用。

为何谷歌选择Sparse MoE 而不是 Dense LLM？

Sparse MoE vs Dense LLM：到底换来了什么，又付出了什么？

Sparse MoE = 拿“更多参数容量”换“更复杂的系统工程”；

Dense LLM = 拿“简单稳定”换“更高的推理成本 / 更有限的容量”。

1. 参数容量 vs 计算成本

设想一个简化例子：

Dense 模型：400B 参数，每一层所有 token 都用到全部参数。

Sparse MoE：假设有 32 个专家（experts），每个 expert 有 50B 参数。模型“总容量”≈ 32 × 50B = 1.6T 参数；但路由策略：每个 token 只激活 2 个 expert。那么一次前向计算用到的参数 ≈ 2 × 50B = 100B 参数。

所以，对「单次推理」来说：

• Dense 400B：固定用 400B；

• Sparse MoE：逻辑容量 1.6T，但每个 token 实际只跑 100B 左右。

这就是 MoE 的核心吸引力：

在「算力可承受」的前提下，把总容量做得远超 Dense，强化“记忆 & 专业化能力”。

2. 路由 & 负载均衡：MoE 的第一大坑

但换来的是非常难搞的一堆工程问题：

1. Routing/gating 的选择

   每个 token 要选出“最合适”的 1–2 个专家。路由器本身也是一个小网络，要学习“哪个 token 该找哪类专家”。训练前期很容易变成：少数几个专家被疯狂点名，其余专家闲置 → 训练不收敛。

2. Load balancing（负载均衡）

   为了防止“热门专家爆满”，通常加一个正则/损失项，强制各专家被用得更均匀。太强 → 路由“被拉平”，失去“专家专长”；太弱 → 过度偏好少数专家，参数利用率低。

3. 跨设备通信成本

   专家通常分布在不同 TPU/GPU 上；每一层都要把 token 按路由结果“打散 + 聚合 + 再拼回”，需要大量 All-to-All 通信；通信没设计好，MoE 直接变成一个巨大的网络风暴制造机，吞吐掉到谷底。

Dense LLM 就简单很多：

• 所有层 & 参数按顺序切片，数据并行 / tensor 并行就行；

• 没有额外路由逻辑，也没有 All-to-All 的专家分发。

3. 表达能力：通才 vs 专才

MoE 的“理论卖点”是：不同专家可以学不同的“风格 / 领域 / 任务”：

• 有的更擅长代码；

• 有的更擅长数学；

• 有的更擅长对话/闲聊；

• 对于特定 token/任务，只调用那些“最适合”的专家。

这会带来几个有意思的现象：

1. “专家人格”，在可视化路由模式时，能看到某些专家只在「代码块 + 错误信息」附近被激活；另一些专家在「多段数学推导」里用得更多。
   

2. 局部过拟合 vs 全局泛化

   好处：细分任务的表现可以很强（因为专家参数多，专注范围窄）；

   风险：如果路由器没学好，有的专家可能对“某些写法/数据分布”过拟合，换个表达就表现下降。

Dense LLM 则是完全的“通才模式”：所有 token 都用同一套参数；更容易在分布迁移时保持稳健，但对容量和算力要求更高。

4. 训练 & 推理的稳定性

Dense LLM 优点：

• 实现简单，优化稳定；

• 不会出现“专家闲置”、“路由崩坏”的问题；

• 调参 & debug 难度低很多。

Sparse MoE 的典型麻烦：

1. 训练稳定性更差

   路由器一旦 bias 到几个专家上，训练会偏；需要 carefully 的 warmup、损失设计、甚至 curriculum 才能稳住。

2. 调参维度更多

   专家数量、每 token 激活专家数、capacity factor（每个 expert 能接多少 token）、负载均衡 loss 权重等等，都是额外的超参数。

3. 部署 & 推理复杂度高

   多设备专家部署布局；路由所带来的延迟和显存碎片问题；实时服务时要和 KV cache / batching 配合，这些都比 Dense 麻烦一大截。

但到了 Gemini 3 这种规模：

• Dense 再往上堆，推理成本会非常夸张；

• 在 TPU 上做全栈 MoE 优化对 Google 来说是可控的；

• 所以他们选了「更高系统复杂度，换更大容量和更低推理成本」这条路。

所以，谷歌使用MoE 是把“模型容量的 scaling law”从“全靠花算力”变成“花更多系统工程 + 一部分算力”。

幻觉情况如何？

Gemini 3 在“知道的事情答得很强”上是 SOTA，但在“不知道时老老实实说不知道”上，做得并不好。

几个关键 benchmark：

1. SimpleQA Verified（事实问答准确率）

   也就是说：在简单事实题上，它比竞品明显更“知道得多”。

   • Gemini 3 Pro：72.1% 正确率

   • Gemini 2.5 Pro：52.9%

   • GPT-5.1：大约 35% 左右，Claude Sonnet 4.5 更低。

2. AA-Omniscience（知识 + 幻觉联合测评）

   这 88% 是啥意思？大意是：当它没有答对时，~88% 的情况都会硬给一个自信的错误答案，而不是说“我不知道 / 没法确认”。

Gemini 3 Pro 在 Omniscience Index 总分和 Accuracy（正确率）都是第一。但同一个评测里，它的 Hallucination Rate ≈ 88%，而且和 Gemini 2.5 Pro 差不多。

所以：

• “Gemini 3 确实比上一代、也比很多竞品更常给出正确答案”；

• 但也的确 “一旦不知道，它依然很爱乱编，而且看起来很自信”。

不少媒体和分析直接点名这一点——“在可靠性 benchmark 里拿第一，但幻觉率仍然很高”。所以，Gemini 3 的幻觉问题现在看起来“挺严重”，而且和 2.5 相比在“会说不知道”这块几乎没进步。但与此同时，它在很多 推理、多模态和事实准确率 benchmark 上又明显领先。

所以更合理的定位可能是：

这是一个“知识多、推理强，但自我认知（知道自己不知道）还很差”的巨大大脑。

对如何使用Gemini用法，我会建议：把它当作“生成研究结构 + 发掘盲区 + 做 scenario/ontology 的 co-pilot”更为恰当合适。

本文来源：贝叶斯之美