不用輝達，Gemini 3是如何訓練的？

2025/11/25

•

經過一年多的蟄伏，Google帶著全新升級的多模態Gemini3來襲，前端UI升級性能拉滿，雖然深度推理、上下文一致性等與ChatGPT5.1 thinking相比還有差距，但總體上已經能滿足絕大多數使用者的基本AI需求。

Gemini 3是如何訓練的？是完全基於GoogleTPU嗎？大家都在關注這些核心問題！

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 這代模型的取向：

容量 vs 成本：用 MoE 換算力效率
想要兆級參數的表達力，但又不能每 token 都燒滿；Sparse MoE = “只叫對這件事最有用的幾個專家出來”，能在相同算力下塞進更多知識和能力。
場景優先：原生多模態 + 超長上下文 + agent 能力
多模態 + 1M context，是為了直接吃：程式碼庫、產品文件、UI 截圖、視訊課程、系統日誌；
再配合 Antigravity 這類 agent IDE 和“Generative UI”，把模型變成真正的“作業系統級助手”，而不是只會聊天。
推理優先：在 RL 裡刻意強化多步推理和定理證明
很多 frontier bench（ARC AGI、GPQA、數學競賽）都強調“要一步步想”；所以他們顯式用這類資料做 RL，把 reward 設計成“慢想但答對”。
安全與合規：從資料到產品的多層防護
資料側就做過濾；模型訓練階段用安全相關的目標和 RL 懲罰項；部署時再加 policy + 安全過濾 + Frontier Safety 評估。
全端一體化：TPU + 框架 + 模型 + 產品的協同最佳化
完全在自家 TPU 上訓練，用 JAX + Pathways 深度繫結硬體特性；再縱向整合到 Search、Workspace、Antigravity IDE、AI Studio 等產品裡。

Gemini 3 更像是“用 TPUs 驅動的 MoE 多模態大腦”，通過龐雜但乾淨的多模態資料預訓練，再用 RL 把“多步推理+Agent 行為”打磨到實戰可用。

為何Google選擇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 的第一大坑

但換來的是非常難搞的一堆工程問題：

Routing/gating 的選擇
每個 token 要選出“最合適”的 1–2 個專家。路由器本身也是一個小網路，要學習“那個 token 該找那類專家”。訓練前期很容易變成：少數幾個專家被瘋狂點名，其餘專家閒置 → 訓練不收斂。
Load balancing（負載平衡）
為了防止“熱門專家爆滿”，通常加一個正則/損失項，強制各專家被用得更均勻。太強 → 路由“被拉平”，失去“專家專長”；太弱 → 過度偏好少數專家，參數利用率低。
跨裝置通訊成本
專家通常分佈在不同 TPU/GPU 上；每一層都要把 token 按路由結果“打散 + 聚合 + 再拼回”，需要大量 All-to-All 通訊；通訊沒設計好，MoE 直接變成一個巨大的網路風暴製造機，吞吐掉到谷底。

Dense LLM 就簡單很多：

所有層 & 參數按順序切片，資料平行 / tensor 平行就行；
沒有額外路由邏輯，也沒有 All-to-All 的專家分發。

3. 表達能力：通才 vs 專才

MoE 的“理論賣點”是：不同專家可以學不同的“風格 / 領域 / 任務”：

有的更擅長程式碼；
有的更擅長數學；
有的更擅長對話/閒聊；
對於特定 token/任務，只呼叫那些“最適合”的專家。

這會帶來幾個有意思的現象：

“專家人格”，在可視化路由模式時，能看到某些專家只在「程式碼塊 + 錯誤資訊」附近被啟動；另一些專家在「多段數學推導」裡用得更多。
局部過擬合 vs 全域泛化
好處：細分任務的表現可以很強（因為專家參數多，專注範圍窄）；
風險：如果路由器沒學好，有的專家可能對“某些寫法/資料分佈”過擬合，換個表達就表現下降。

Dense LLM 則是完全的“通才模式”：所有 token 都用同一套參數；更容易在分佈遷移時保持穩健，但對容量和算力要求更高。

4. 訓練 & 推理的穩定性

Dense LLM 優點：

實現簡單，最佳化穩定；
不會出現“專家閒置”、“路由崩壞”的問題；
調參 & debug 難度低很多。

Sparse MoE 的典型麻煩：

訓練穩定性更差
路由器一旦 bias 到幾個專家上，訓練會偏；需要 carefully 的 warmup、損失設計、甚至 curriculum 才能穩住。
調參維度更多
專家數量、每 token 啟動專家數、capacity factor（每個 expert 能接多少 token）、負載平衡 loss 權重等等，都是額外的超參數。
部署 & 推理複雜度高
多裝置專家部署佈局；路由所帶來的延遲和視訊記憶體碎片問題；即時服務時要和 KV cache / batching 配合，這些都比 Dense 麻煩一大截。

但到了 Gemini 3 這種規模：

Dense 再往上堆，推理成本會非常誇張；
在 TPU 上做全端 MoE 最佳化對 Google 來說是可控的；
所以他們選了「更高系統複雜度，換更大容量和更低推理成本」這條路。

所以，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”更為恰當合適。 (貝葉斯之美)