Gemini 能耗怎麼算？TPU、備援與冷卻的完整拆解

Gemini 一次文字提示到底耗多少電？Google 在 2025 年公開一份針對 Gemini Apps 的推論能耗研究，估計 2025 年 5 月的中位數文字提示使用 0.24 Wh 電力、排放 0.03 gCO₂e、耗用 0.26 mL 水。比起把這個數字當成每次 AI 對話的固定帳單，更值得看的其實是它的計算方式：模型加速器並不是唯一的耗能來源。

舊有說法提到 TPU 只占 58%、冷卻與備援可能是「最大元凶」，後半句並不準確。依該研究的完整口徑，TPU 等主動 AI 加速器是最大的單一項目；但主機、預留的閒置容量與資料中心支援系統合計仍占相當比重。這正說明，評估 AI 能耗不能只看晶片的理論瓦數。

0.24 Wh 是怎麼拆出來的？

Google 的完整測量把所有 Gemini Apps 的生產環境服務因素納入，而非只量正在運算的 TPU。對 2025 年 5 月的中位數文字提示，報告列出以下分布：

• 主動 AI 加速器：0.14 Wh，約 58%。
• 主機 CPU 與 DRAM：0.06 Wh，約 25%。
• 預留但閒置的機器容量：0.02 Wh，約 10%。這是為了尖峰流量與故障切換而保留的可用性成本。
• 資料中心 overhead：0.02 Wh，約 8%。包含冷卻、電力轉換與配電等，並以 PUE 納入。

百分比因四捨五入可能不完全相加為 100%。重點是：TPU 的確是最大單一項目，但 CPU／DRAM 才是最大的非加速器項目；冷卻與其他資料中心 overhead 在這個特定測量中約為 8%，並非最大部分。把「不是 100% TPU」直接推成「冷卻最大」會失真。

為何只看活躍晶片會低估？

若只採較窄的口徑、只量活躍 TPU／GPU，Google 對相同類型中位數文字提示的估計是 0.10 Wh；納入主機、閒置容量與資料中心 overhead 後則為 0.24 Wh。兩者的差異不是哪個數字「造假」，而是系統邊界不同。

這是看 AI 能耗時最常被忽略的一點。實際線上服務必須預留容量、維持低延遲、容忍硬體故障，也需要主機、網路與散熱支援。若只用滿載晶片的 benchmark 功耗推估使用者提示，就很容易得到一個過度樂觀的數字；若把資料中心、訓練、儲存、使用者裝置與供電生命週期全混在一起，又無法比較不同服務。好的報告應先說清楚自己量到哪裡。

這個數字能代表所有 Gemini 使用嗎？

不能。報告衡量的是 Gemini Apps 在 2025 年 5 月的中位數文字生成提示，不是每個模型、每種功能或每次輸入的固定耗能。長輸出、複雜推理、多模態輸入、圖片生成、工具呼叫與低利用率時段，都可能與中位數差很多。研究也排除了終端使用者裝置，以及模型訓練與資料儲存的能耗。

排放與用水也需要分開閱讀。0.03 gCO₂e 使用 Google 資料中心的市場基礎電力排放係數；0.26 mL 是依資料中心用水效率推估的消耗量。它們有助於理解該服務的運行狀況，但不能直接替代所在地電網、供水壓力或完整生命週期的影響判斷。Google 也在說明中註明，這些數據與主張尚未經獨立第三方驗證。

33 倍效率提升，又代表什麼？

Google 表示，從 2024 年 5 月到 2025 年 5 月，Gemini Apps 中位數文字提示的每次能耗下降約 33 倍、總碳足跡下降約 44 倍。報告將原因歸於模型與軟體效率、機器利用率改善，以及較低的市場基礎電力排放係數。這是同一套方法、同一產品情境下的時間比較，不等於所有 AI 模型在一年內都節電 33 倍，也不能據此推論整體 AI 用電總量已下降。

企業或團隊該如何比較 AI 能耗？

1. 先標註工作負載：模型版本、輸入與輸出 token、是否使用圖片／搜尋／工具、快取命中率與延遲目標，都會改變結果。
2. 先定義系統邊界：是只量活躍加速器，還是包括主機、閒置容量、網路與資料中心 PUE？不同邊界的數字不可直接排高低。
3. 同時報告中位數與高分位數：中位數描述典型使用，但成本與容量規劃通常由長輸出、複雜任務等尾端案例決定。
4. 把能源、碳與水分開：每度電的碳強度與用水壓力會隨地點和時間改變；降低電量不必然在每個地區以同樣比例降低環境影響。
5. 優先減少不必要的推論：用較小或較適合的模型處理簡單任務、限制無用長輸出、重用快取結果、批次化非即時工作，通常比事後估算一個漂亮的 Wh 數字更能直接降低資源使用。

結論：AI 能耗是整個服務系統的帳

Gemini 的 0.24 Wh 報告提供了一個重要方向：把能耗從「晶片跑了幾秒」改為「服務一個使用者請求所需的整個系統」。TPU 58% 是有用的事實，但不是用來淡化其餘 42%，也不是冷卻成為最大耗能來源的證據。對使用者與團隊而言，最可靠的做法是先問清楚測量邊界、工作負載與時間點，再比較效率並改善真正不必要的運算。