Google Gemma 3:性能“炸裂”還是榜單優化?
一、背景
最近幾天 Google 發布了最新的 Gemma 3 系列開源模型,迅速成為業界熱議的焦點,其中,Gemma 3 27B IT 模型尤為引人注目。如下圖所示為 Google 廣泛宣傳的 Gemma 3 27B IT 模型在 Chatbot Arena Leaderboard [1]上的表現,以 27B 的參數量,不僅超越了更大參數量的 DeepSeek V3(實際激活參數量差不多),并且接近頂尖的 DeepSeek R1。事實上性能真的這么“炸裂”嗎?還是面向 Chatbot Arena 的優化?值得注意的是,Chatbot Arena 的排名基于用戶盲測投票,容易受到寫作風格、響應速度以及特定用戶群體偏好的影響——例如,用戶往往更青睞反應迅速、語言自然且能靈活應對多樣化問題的模型。因此,這一榜單未必能全面反映模型的真實能力。
事實上,當前大模型評測體系的混亂已是不爭的事實:測試基準五花八門切缺乏不一致,許多基準與實際業務需求脫節,數據污染與過擬合問題更是屢見不鮮。這使得挑選一個真正實用的模型變得很有挑戰性,用戶不得不在真實場景中要反復試錯,浪費大量人力與算力資源。很期待未來有一些更全面、更權威的基準。同時,也真的期待有一個 30B 左右規模的 Dense 模型,在性能上全面媲美 DeepSeek R1,將無疑是開源社區和實際應用的一大福音。本文將簡要探討 Gemma 3 27B IT 模型的技術亮點與潛在局限。
相關工作可以參考我們之前的文章:
- ???DeepSeek 模型架構的特殊選擇???
- ???LLM 評估匯總:真的吊打 LLaMA-3,媲美 GPT-4 嗎????
- ???綜述:DeepSeek Infra/V1/MoE/V2/V3/R1 & 開源關鍵技術???
二、Gemma 3 模型
2.1 概覽
如下圖 Table 1 所示,Gemma 3 總共包含 4 個模型:
- 1B 為純 LLM 模型,4B、12B 和 27B 為多模態模型。
- 1B 使用 2T Token 預訓練;4B 使用 4T Token;12B 和 27B 使用 14T Token(PS:目前看 14T - 15T Token 基本成為標配)。
- 現在 32K 序列長度預訓練,然后擴展到 128K 的序列長度。
- 支持 140 種語言。
- 支持 Function Call 和結構化輸出。
- 總詞表大小為 262K,相對而言,常見的開源模型的詞表通常是 128K 左右。
- Vision Encoder 相同,都是 SigLIP 417M,輸入分辨率為 896x896。
- Pan & Scan(P&S):如果圖像比較大,則會采用無重疊的切分,然后分別 Resize 到 896x896(PS:這個也是非常常規的手段)。
對應的論文:Gemma 3 Technical Report [2]
對應的模型:google/gemma-3-27b-it at main [3]
2.2 模型結構
現在 LLM 處理的序列越來越長,為了降低 KV Cache 存儲空間以及 Attention 的計算復雜度,最近一段時間很多模型都采用“混合模型”優化方案:
- MiniMax 01:采用 Linear Attention 和 Softmax Attention 混合方案。為了彌補 Linear Attention 長距離序列建模能力不足的問題,每隔 M 層會采用一個標準的 Full Softmax Attention。
- Hunyuan Turbo S:采用 Mamba + Full Softmax Attention + MoE 的方式,Mamba 作用和 Linear Attention 類似。
- Gemma 3 27B:GQA + 5:1 交錯的 local/global layers。其中的 5:1 交錯是指:5 層為滑動窗口 Attention,1 層為 Full Softmax Attention,交錯排列。
如下圖配置所示為其中 LLM 的具體配置,可以看出,總共 62 層;GQA 中 Attention Head 與 KV Head 的比例為 2:1;滑動窗口的大小為 1024。也就是只要序列長度大于 1024,就可以節約 KV Cache 空間以及 Attention 計算量。
PS:除了上述的混合模型外,最近 Inception Labs 的 Mercury [10] 模型也很值得關注。其不是使用傳統的基于自回歸的 Transformer 模型,而是采用了類似圖像、視頻生成中常用的擴散模型,從噪聲開始逐步優化整個文本序列,而不是逐個生成 token。雖然其在各種基準測試上還無法達到第一梯隊,但是在速度和成本效率上具有非常明顯的優勢,在個別場景上可能也是個不錯的選擇。如下圖所示為其在個別任務上的精度以及吞吐數據:
2.3 量化
除了模型結構的創新外,量化也是降低存儲空間需求、提升處理速度的有效手段。Gemma 3 中,作者除了提供原始模型外,還提供了不同量化精度的量化版本,這些模型都是采用量化感知訓練(Quantization Aware Training, QAT)方法,通過少量 Step(通常是 5000)微調而來。如下圖所示為 32K 序列長度時不同精度下的顯存開銷,FP8 精度時總的顯存開銷也只有 46GB:
2.4 消融實驗
即使滑動窗口層(Local)與標準 Transformer 層(Global)的比例為 7:1,損失依然很小,作者采用了 5:1。
滑動窗口大小為 1024 時幾乎無損,但是小于 1024 時損失開始變大:
更小的滑動窗口,更大的 Local:Global,可以有效降低 KV Cache 開銷:
如下圖 Table 7 所示,作者也進一步評估了不同圖像分辨率對于視覺任務的影響。可以看出,較大的分辨率能明顯提升在視覺基準上的性能:
三、評估
3.1 概覽
如下圖 Table 6 所示,作者僅提供了與自家 Gemini 和 Gemma 模型的比較,而未提供更多開源模型的結果(PS:聲稱是無法保持公平性??)。因此,我們從一些比較可信的數據源收集到一些 DeepSeek 的基準數據以作對比:
如下圖所示為 Grok 3 的 DeepSearch 收集到的部分數據:
3.2 MMLU-Pro
參考:MMLU-Pro Leaderboard - a Hugging Face Space by TIGER-Lab [4]
3.3 LiveCodeBench
參考:
- Introducing Gemini 2.0: our new AI model for the agentic era [5]
- Gemini 2.0 is now available to everyone [6]
- LiveCodeBench Leaderboard [7]
3.4 GPQA Diamond
參考:LLM Leaderboard 2025 [8]
3.5 FACTS Grounding
這個看著是 Google 自己的榜單:https://www.kaggle.com/facts-leaderboard/leaderboard [9]
3.6 評估細節
雖然說 Google 在宣傳上有點雞賊,但是其一般都會比較準確列出基準評估的細節,比如采用的 n-shot 配置,是否使用 CoT 等等,如下圖 Table 19 所示:
四、參考鏈接
- ???https://huggingface.co/spaces/lmarena-ai/chatbot-arena-leaderboard???
- ???https://storage.googleapis.com/deepmind-media/gemma/Gemma3Report.pdf???
- ???https://huggingface.co/google/gemma-3-27b-it/tree/main???
- ???https://huggingface.co/spaces/TIGER-Lab/MMLU-Pro???
- ???https://blog.google/technology/google-deepmind/google-gemini-ai-update-december-2024/???
- ???https://blog.google/technology/google-deepmind/gemini-model-updates-february-2025/???
- ???https://livecodebench.github.io/leaderboard.html???
- ???https://www.vellum.ai/llm-leaderboard???
- ???https://www.kaggle.com/facts-leaderboard/leaderboard???
- ???https://www.inceptionlabs.ai/news????
本文轉載自??AI閑談??,作者:AI閑談
