<div id="readability-page-1">经过一年多的蛰伏，谷歌带着全新升级的多模态 Gemini3 来袭，前端 UI 升级性能拉满，虽然深度推理、上下文一致性等与 ChatGPT5.1 thinking 相比还有差距，但总体上已经能满足绝大多数用户的基本 AI 需求。 <img src="https://imageproxy.pbkrs.com/https://wpimg-wscn.awtmt.com/ebfc96fa-2aee-4048-9758-c548569570fc.jpeg?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" width="875" height="655" original-src="https://imageproxy.pbkrs.com/https://wpimg-wscn.awtmt.com/ebfc96fa-2aee-4048-9758-c548569570fc.jpeg"/> Gemini 3 是如何训练的？是完全基于谷歌 TPU 吗？大家都在关注这些核心问题！ <img src="https://imageproxy.pbkrs.com/https://wpimg-wscn.awtmt.com/fd929b6e-913f-4477-8beb-ff2e0cd41549.jpeg?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" width="1024" height="670" original-src="https://imageproxy.pbkrs.com/https://wpimg-wscn.awtmt.com/fd929b6e-913f-4477-8beb-ff2e0cd41549.jpeg"/> Gemini 3 = 稀疏 Mixture-of-Experts（MoE）Transformer + 原生多模态（文本/图像/音频/视频）+ 超长上下文（输入最多 1M token、输出 64k）+ RL 强化 “多步推理/定理证明” 的一整套栈，并且是用 Google 自家 TPU Pod + JAX + Pathways 从零训练出来的新模型。 下面分几层讲：架构、训练数据与流程、算力/系统设计，再讲一下 “这套设计背后的逻辑”。 <h2>架构：稀疏 MoE Transformer + 原生多模态 + 超长上下文</h2> 1. 核心骨架：Sparse Mixture-of-Experts Transformer 官方模型卡直接写了： <ul> <li> 架构 = 稀疏 Mixture-of-Experts（MoE）Transformer </li> <li> 原生支持文本、视觉（图像）、音频输入（视频通常拆成图像帧 + 音频序列送进来）。 </li> </ul> MoE 的关键点： <ul> <li> 每一层有很多 “专家子网络”（experts）； </li> <li> 前面有个 routing/gating 子网络，对每个 token 决定送到哪几个专家； </li> <li> 每个 token 只激活少数几个专家，不是所有参数都跑一遍； </li> <li> 这样可以做到：总参数量很大（外界估计总体容量&gt;1T 级）但单次推理算力成本可控。 </li> </ul> 相当于，不是每个问题都叫公司里所有员工一起开会，而是路由到 2–3 个最合适的小组来处理。 2. 原生多模态（Text + Vision + Audio + Video） 模型从设计上就是 “多模态优先”，而不是 “先做文本，再外挂一个视觉编码器”。文本 token、图像 patch、音频帧，都会进同一个 Transformer 主干，只是前端有不同的编码器，把不同模态统一到同一向量空间。Google 还在此基础上做了 Nano Banana Pro 这种图像模型，直接把 Gemini 3 Pro 当成图像生成/编辑的 “主脑”。 这类原生多模态的好处： <ul> <li> 可以跨模态推理：例如看视频 + 讲解文字，一起理解 “这个实验为什么失败”； </li> <li> 对产品场景（搜索界面截图、代码 + 报错截图、讲课视频 +PDF）非常友好。 </li> </ul> 3. 超长上下文：1M Token 输入、64k 输出 <ul> <li> 官方模型卡：输入上下文上限 1,000,000 token，输出上限 64,000 token。 </li> <li> MarkTechPost 文章也确认了这点，并强调它是 “让 agent 能吃完整代码库/长文档/多小时视频” 的关键。 </li> </ul> 在实现上，Google 没公开全部细节，但结合他们开源的 Gemma 3 报告可以看出最近的思路：更多 local attention 层 + 更短的 local span，减少 KV-cache 爆炸；把 “少量 global attention 层” 用在关键信息汇总上。 所以你可以理解为：局部窗口里用 cheap 的 local attention，偶尔插一层 “全局视角” 做信息整合，再配合 MoE 把计算分散到不同专家上，共同支撑 1M context。 4. 和 Gemini 2.5 的差异 官方说得很清楚： <ul> <li> 不是 2.5 的微调版，而是从头训练的新一代架构。 </li> <li> 在各种推理、多模态、长上下文基准上，都显著超过 2.5 Pro。 </li> </ul> <h2>训练数据：多模态 + 多来源 + 大规模清洗</h2> 1. 预训练数据构成 模型卡里披露得相当详细： 多模态、多领域的大规模语料： <ul> <li> 公开网页文档 &amp; 文本 </li> </ul> <ul> <li> 代码（多种语言）</li> </ul> <ul> <li> 图像 </li> </ul> <ul> <li> 音频（含语音和其他音频类型）</li> <li> 视频 </li> </ul> 数据来源类型： <ul> <li> 公共可下载数据集 </li> </ul> <ul> <li> 爬虫抓取数据（遵守 robots.txt）</li> </ul> <ul> <li> 商业授权数据（licensed）</li> </ul> <ul> <li> Google 产品中的用户数据 &amp; 与模型的交互数据（在对应 TOS/隐私政策和用户控制下）</li> </ul> <ul> <li> Google 内部业务产生的数据 </li> <li> AI 合成数据（synthetic data）</li> </ul> 所以整体可以理解为：“公共互联网 + 授权版权库 + 自家产品行为日志 + 内部 &amp; 合成数据” 的大杂烩，而且是多模态同步喂的。 2. 数据清洗与安全过滤 同一份模型卡也写了数据处理流程： <ul> <li> 去重（deduplication）</li> <li> 遵守 robots.txt </li> <li> 各类 安全过滤（屏蔽色情、暴力、CSAM 等内容）</li> <li> 质量过滤，去掉垃圾/无关内容 </li> </ul> 这些既是安全要求，也是为了稳定训练（脏数据太多会直接拉垮收敛）。 <h2>训练流程：预训练 + 指令微调 + RL（人类 &amp; critic 反馈）</h2> 官方没有给出超细节的损失函数和 schedule，但框架是比较典型的 “三阶段”： 1. 阶段一：自监督预训练（大模型基座） 在上面那堆多模态数据上，做类似「下一个 token 预测」的自监督训练；文本/代码用标准的 autoregressive objective；图像/音频/视频通过适配的编码方式，把 patch/帧也当 token 来预测。 目标：学到通用语言 + 世界知识 + 多模态表征，不管任务、不管指令。 2. 阶段二：监督式指令微调（SFT） <ul> <li> 用 “人类写的高质量多模态指令数据” 进行微调： <ul> <li> 问答、对话、代码生成、推理题目 </li> <li> 图文问答、视频理解、音频理解 </li> </ul> </li> <li> 这一步类似于把 “会说话的大脑” 变成 “会听指令做事的助手”。 </li> </ul> 模型卡把这部分统称为 instruction tuning data。 3. 阶段三：强化学习 + 安全部署 Gemini 3 在 RL 上写得比之前代更直白：使用 reinforcement learning from human and critic feedback： 人类标注哪种回答更好；再加 “critic 模型” 自动给出评分；强化学习用到的内容特别强调： <ul> <li> 多步推理数据 </li> </ul> <ul> <li> 问题求解数据 </li> <li> 定理证明类数据 </li> </ul> 也就是说，他们专门用 RL 把模型往 “会慢慢推理、拆解问题、做数学/证明” 这个方向拉。这也解释了：Gemini 3 在 Humanity’s Last Exam、ARC AGI 2 等高难度推理 benchmark 上比 2.5 和不少竞品强。 安全相关：他们把 数据过滤 + 条件预训练 + SFT + RLHF + 产品级安全过滤 都当成安全 “层级防护”。并按照自家的 Frontier Safety Framework 做红队和能力评估。 <h2>算力与系统：TPU 全栈 + JAX + Pathways</h2> 这次 Gemini 3 的一个重要 “元叙事” 是：“不用 NVIDIA 也能在前沿”。 1. 硬件：完全用 Google 自家 TPU 训练 模型卡写得很清楚： <ul> <li> 训练全部在 Google Tensor Processing Units（TPUs）上完成； </li> <li> 使用 TPU Pods（大规模 TPU 集群），支持多设备分布式训练； </li> <li> 利用 TPU 的高带宽内存和大 batch 做到了更好的模型质量 + 能效。 </li> </ul> 外部文章因此强调：Gemini 3 证明了一条 “自研芯片 + 自家云” 的完整路径，可以在不依赖 GPU 供应链的情况下做到 frontier 级别。 2. 软件栈：JAX + ML Pathways 模型卡：训练用的是 JAX + ML Pathways。Pathways 是 Google 自己的多机多任务训练框架，比较适合这种 MoE + 超长上下文的大模型并行。结合 MoE 架构，你可以想象它在系统层面需要解决： <ul> <li> 专家参数在 TPU Pod 上怎么切片/放置； </li> <li> token 的 routing 怎么跨设备做负载均衡； </li> <li> 超长上下文的 KV cache 怎么 sharding 和回收； </li> <li> 在这些约束下还要保证训练吞吐和稳定性。 </li> </ul> 这些实现细节没公开，但从他们强调的 “sparse MoE + 1M context 实用化” 可以看出，系统工程占了很大比重。 <h2>从 “设计选择” 看 Gemini 3 的几个洞察：</h2> 站在方法论角度，可以大概总结出 Google 这代模型的取向： <ol> <li> 容量 vs 成本：用 MoE 换算力效率 想要万亿级参数的表达力，但又不能每 token 都烧满；Sparse MoE = “只叫对这件事最有用的几个专家出来”，能在相同算力下塞进更多知识和能力。 </li> <li> 场景优先：原生多模态 + 超长上下文 + agent 能力 多模态 + 1M context，是为了直接吃：代码库、产品文档、UI 截图、视频课程、系统日志； 再配合 Antigravity 这类 agent IDE 和 “Generative UI”，把模型变成真正的 “操作系统级助手”，而不是只会聊天。 </li> <li> 推理优先：在 RL 里刻意强化多步推理和定理证明 很多 frontier bench（ARC AGI、GPQA、数学竞赛）都强调 “要一步步想”；所以他们显式用这类数据做 RL，把 reward 设计成 “慢想但答对”。 </li> <li> 安全与合规：从数据到产品的多层防护 数据侧就做过滤；模型训练阶段用安全相关的目标和 RL 惩罚项；部署时再加 policy + 安全过滤 + Frontier Safety 评估。 </li> <li> 全栈一体化：TPU + 框架 + 模型 + 产品的协同优化 完全在自家 TPU 上训练，用 JAX + Pathways 深度绑定硬件特性；再纵向整合到 Search、Workspace、Antigravity IDE、AI Studio 等产品里。 </li> </ol> Gemini 3 更像是 “用 TPUs 驱动的 MoE 多模态大脑”，通过庞杂但干净的多模态数据预训练，再用 RL 把 “多步推理 +Agent 行为” 打磨到实战可用。 为何谷歌选择 Sparse MoE 而不是 Dense LLM？ Sparse MoE vs Dense LLM：到底换来了什么，又付出了什么？ <blockquote> Sparse MoE = 拿 “更多参数容量” 换 “更复杂的系统工程”； Dense LLM = 拿 “简单稳定” 换 “更高的推理成本 / 更有限的容量”。 </blockquote> 1. 参数容量 vs 计算成本 设想一个简化例子： Dense 模型：400B 参数，每一层所有 token 都用到全部参数。 Sparse MoE：假设有 32 个专家（experts），每个 expert 有 50B 参数。模型 “总容量”≈ 32 × 50B = 1.6T 参数；但路由策略：每个 token 只激活 2 个 expert。那么一次前向计算用到的参数 ≈ 2 × 50B = 100B 参数。 所以，对「单次推理」来说： <ul> <li> Dense 400B：固定用 400B； </li> <li> Sparse MoE：逻辑容量 1.6T，但每个 token 实际只跑 100B 左右。 </li> </ul> 这就是 MoE 的核心吸引力： <blockquote> 在「算力可承受」的前提下，把总容量做得远超 Dense，强化 “记忆 &amp; 专业化能力”。 </blockquote> 2. 路由 &amp; 负载均衡：MoE 的第一大坑 但换来的是非常难搞的一堆工程问题： <ol> <li> Routing/gating 的选择 每个 token 要选出 “最合适” 的 1–2 个专家。路由器本身也是一个小网络，要学习 “哪个 token 该找哪类专家”。训练前期很容易变成：少数几个专家被疯狂点名，其余专家闲置 → 训练不收敛。 </li> <li> Load balancing（负载均衡）为了防止 “热门专家爆满”，通常加一个正则/损失项，强制各专家被用得更均匀。太强 → 路由 “被拉平”，失去 “专家专长”；太弱 → 过度偏好少数专家，参数利用率低。 </li> <li> 跨设备通信成本 专家通常分布在不同 TPU/GPU 上；每一层都要把 token 按路由结果 “打散 + 聚合 + 再拼回”，需要大量 All-to-All 通信；通信没设计好，MoE 直接变成一个巨大的网络风暴制造机，吞吐掉到谷底。 </li> </ol> Dense LLM 就简单很多： <ul> <li> 所有层 &amp; 参数按顺序切片，数据并行 / tensor 并行就行； </li> <li> 没有额外路由逻辑，也没有 All-to-All 的专家分发。 </li> </ul> 3. 表达能力：通才 vs 专才 MoE 的 “理论卖点” 是：不同专家可以学不同的 “风格 / 领域 / 任务”： <ul> <li> 有的更擅长代码； </li> </ul> <ul> <li> 有的更擅长数学； </li> </ul> <ul> <li> 有的更擅长对话/闲聊； </li> <li> 对于特定 token/任务，只调用那些 “最适合” 的专家。 </li> </ul> 这会带来几个有意思的现象： <ol> <li> “专家人格”，在可视化路由模式时，能看到某些专家只在「代码块 + 错误信息」附近被激活；另一些专家在「多段数学推导」里用得更多。 </li> <li> 局部过拟合 vs 全局泛化 好处：细分任务的表现可以很强（因为专家参数多，专注范围窄）； 风险：如果路由器没学好，有的专家可能对 “某些写法/数据分布” 过拟合，换个表达就表现下降。 </li> </ol> Dense LLM 则是完全的 “通才模式”：所有 token 都用同一套参数；更容易在分布迁移时保持稳健，但对容量和算力要求更高。 4. 训练 &amp; 推理的稳定性 Dense LLM 优点： <ul> <li> 实现简单，优化稳定； </li> <li> 不会出现 “专家闲置”、“路由崩坏” 的问题； </li> <li> 调参 &amp; debug 难度低很多。 </li> </ul> Sparse MoE 的典型麻烦： <ol> <li> 训练稳定性更差 路由器一旦 bias 到几个专家上，训练会偏；需要 carefully 的 warmup、损失设计、甚至 curriculum 才能稳住。 </li> <li> 调参维度更多 专家数量、每 token 激活专家数、capacity factor（每个 expert 能接多少 token）、负载均衡 loss 权重等等，都是额外的超参数。 </li> <li> 部署 &amp; 推理复杂度高 多设备专家部署布局；路由所带来的延迟和显存碎片问题；实时服务时要和 KV cache / batching 配合，这些都比 Dense 麻烦一大截。 </li> </ol> 但到了 Gemini 3 这种规模： <ul> <li> Dense 再往上堆，推理成本会非常夸张； </li> <li> 在 TPU 上做全栈 MoE 优化对 Google 来说是可控的； </li> <li> 所以他们选了「更高系统复杂度，换更大容量和更低推理成本」这条路。 </li> </ul> 所以，谷歌使用 MoE 是把 “模型容量的 scaling law” 从 “全靠花算力” 变成 “花更多系统工程 + 一部分算力”。 幻觉情况如何？ Gemini 3 在 “知道的事情答得很强” 上是 SOTA，但在 “不知道时老老实实说不知道” 上，做得并不好。 几个关键 benchmark： <ol> <li> SimpleQA Verified（事实问答准确率）也就是说：在简单事实题上，它比竞品明显更 “知道得多”。 <ul> <li> Gemini 3 Pro：72.1% 正确率 </li> <li> Gemini 2.5 Pro：52.9% </li> <li> GPT-5.1：大约 35% 左右，Claude Sonnet 4.5 更低。 </li> </ul> </li> <li> AA-Omniscience（知识 + 幻觉联合测评）这 88% 是啥意思？大意是：当它没有答对时，~88% 的情况都会硬给一个自信的错误答案，而不是说 “我不知道 / 没法确认”。 </li> </ol> Gemini 3 Pro 在 Omniscience Index 总分和 Accuracy（正确率）都是第一。但同一个评测里，它的 Hallucination Rate ≈ 88%，而且和 Gemini 2.5 Pro 差不多。 所以： <ul> <li> “Gemini 3 确实比上一代、也比很多竞品更常给出正确答案”； </li> <li> 但也的确 “一旦不知道，它依然很爱乱编，而且看起来很自信”。 </li> </ul> 不少媒体和分析直接点名这一点——“在可靠性 benchmark 里拿第一，但幻觉率仍然很高”。所以，Gemini 3 的幻觉问题现在看起来 “挺严重”，而且和 2.5 相比在 “会说不知道” 这块几乎没进步。但与此同时，它在很多 推理、多模态和事实准确率 benchmark 上又明显领先。 所以更合理的定位可能是： <blockquote> 这是一个 “知识多、推理强，但自我认知（知道自己不知道）还很差” 的巨大大脑。 </blockquote> 对如何使用 Gemini 用法，我会建议：把它当作 “生成研究结构 + 发掘盲区 + 做 scenario/ontology 的 co-pilot” 更为恰当合适。 风险提示及免责条款 市场有风险，投资需谨慎。本文不构成个人投资建议，也未考虑到个别用户特殊的投资目标、财务状况或需要。用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资，责任自负。</div>

谷歌-C

谷歌推出全新升级的多模态 AI 模型 Gemini 3，采用稀疏 Mixture-of-Experts Transformer 架构，支持文本、图像、音频等多模态输入。该模型使用 Google TPU Pod 和 JAX 从零训练，具备超长上下文处理能力。尽管与 ChatGPT5.1 相比在深度推理上仍有差距，但已能满足大多数用户的 AI 需求。

- 谷歌推出多模态模型 Gemini 3，支持文本、图像、音频和视频输入。  
- 该模型使用稀疏 MoE 架构，具备超长上下文处理能力。  
- Gemini 3 在推理和多模态任务上表现优于前代，但幻觉率仍高。

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