經過一年多的蟄伏,谷歌帶著全新升級的多模態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 這代模型的取向:

容量 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 行為”打磨到實戰可用。

為何谷歌選擇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 來說是可控的;

所以他們選了「更高系統復雜度,換更大容量和更低推理成本」這條路。

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

幻覺情況如何?

Gemini 3 在“知道的事情答得很強”上是 SOTA,但在“不知道時老老實實說不知道”上,做得并不好。

幾個關鍵 benchmark:

SimpleQA Verified(事實問答準確率)

也就是說:在簡單事實題上,它比競品明顯更“知道得多”

Gemini 3 Pro:72.1% 正確率

Gemini 2.5 Pro:52.9%

GPT-5.1:大約 35% 左右,Claude Sonnet 4.5 更低。

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”更為恰當合適。