<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 是如何訓練的？