【AI 時事解析】從「五滴水」到「四十五毫升」:AI 環境揭露的真相落差
AI 不只消耗算力,更吞噬電與水。Google 近日公布 Gemini 單次推理僅需「五滴水」,營造出高效率的環保形象;但法國新創 Mistral 的完整揭露卻顯示,Large 2 回答一個問題要耗掉 45 毫升水。這場「五滴水 vs 四十五毫升」的落差,凸顯了 AI…
【AI 時事解析】從「五滴水」到「四十五毫升」:AI 環境揭露的真相落差
AI 不只消耗算力,更吞噬電與水。Google 近日公布 Gemini 單次推理僅需「五滴水」,營造出高效率的環保形象;但法國新創 Mistral 的完整揭露卻顯示,Large 2 回答一個問題要耗掉 45 毫升水。這場「五滴水 vs 四十五毫升」的落差,凸顯了 AI 環境成本的透明度缺口。

當我們使用 AI 時,很少人會去想背後需要多少資源。一次問答、一次搜尋,看似只是幾秒鐘的雲端運算,但其實伺服器要用電、要散熱,還要大量用水冷卻。如果這些消耗沒有被誠實記錄,社會就很難知道 AI 的真實環境代價。這也是為什麼最近 Google 與 Mistral 分別公布自家模型的「資源足跡」數據後,引發廣泛討論 ,因為兩組數字差距之大,直接暴露了制度上透明度的落差。
Google 的「五滴水敘事」
Google 在 2025 年 8 月公布 Gemini 模型的環境數據,並特別選擇「Gemini Apps 的文字提示(text prompt)」作為樣本。他們指出,在 2025 年 5 月的測算中,一則文字提示的中位數資源消耗為:0.24 瓦時電力、0.03 公克二氧化碳,以及大約 0.26 毫升的水(約「五滴水」)。與 2024 年同期相比,這些數據分別下降了 33 倍(能源)與 44 倍(碳足跡)。
這些數字聽起來幾乎微不足道,比看九秒鐘電視還省。但需要注意幾個限制:
- 這些數據只涵蓋推理階段,不包括模型的訓練與硬體製造。
- 數據來自「Gemini Apps 文字提示」的中位數,不代表所有場景或所有 Gemini 模型。
- Google 強調估算已納入現實因素:除了 TPU/GPU 的運算,還包括 CPU、RAM、資料中心待機能耗、冷卻系統(PUE)與水使用效率(WUE)。
- 尚未經過獨立第三方驗證,目前仍是 Google 自述結果。
換句話說,這是一張「收據」,而不是一份完整的「總帳」。
Mistral 的「總帳揭露」
法國新創 Mistral 則選擇攤開完整的總帳。他們針對 Large 2 模型做了全面的生命週期分析(Life Cycle Assessment, LCA),並公開所有數據。結果顯示:截至 2025 年 1 月,Large 2 在訓練與 18 個月的推理使用過程中,累積了 20.4 千噸二氧化碳排放、281,000 立方公尺用水,以及 660 公斤 Sb eq(資源消耗指標,主要來自硬體製造)。
更直觀的數字是,單次回覆(約 400 個 token)的平均代價是 1.14 公克二氧化碳、45 毫升用水,以及 0.16 毫克 Sb eq。這些數字顯然比 Google 的「五滴水」高出許多。
報告也揭露了環境負擔的分布:訓練與推理階段合計佔了 85.5% 的碳排與 91% 的用水;而硬體製造則佔了 61% 的資源消耗(Sb eq)。這些數據由低碳轉型與氣候策略顧問公司與法國生態轉型署(Agence de la transition écologique)協助完成,並由另外兩家數位永續發展顧問公司進行同儕審查,方法學遵循《環境管理-生命週期評估-原則與架構》(ISO 14040)、《環境管理-生命週期評估-要求與指引》(ISO 14044)以及 《溫室氣體盤查議定書-產品生命週期盤查與報告準則》(GHG Protocol Product Standard)。
方法學為什麼重要?ISO 與 GHG Protocol
這些標準不是裝飾,而是確保數據可以比較的關鍵。ISO 14040 提供生命週期分析的基本原則與架構,ISO 14044 則進一步規範具體的要求與技術指引。這兩套標準通常是搭配使用,被視為生命週期分析的基礎規範。
而 GHG Protocol Product Standard 則是全球最廣泛採用的溫室氣體核算準則之一,專門針對「產品生命週期」的碳排放進行計算與揭露,涵蓋原料、生產、使用到廢棄處理。採用這些標準,代表 Mistral 公布的數字不僅是公司自述,而是放在一個國際可比的框架中。
這就是為什麼,同樣是 AI 模型,卻會出現「五滴水」與「四十五毫升」的巨大落差。Google 的做法偏向「行銷敘事」,Mistral 則是「總帳揭露」。
效率進步,總量卻可能更糟:傑文斯悖論
即便 Google 的數字完全正確,也不能掉以輕心。因為效率的提升不等於資源的總量會下降。經濟學上有個概念叫 「傑文斯悖論」(Jevons Paradox):當一項技術變得更有效率、更省資源時,反而會刺激需求增加,導致總體消耗更多。
AI 正在重演這個故事。研究指出,一次 AI 強化搜尋的能耗,可能是傳統搜尋的二十多倍。當大家開始大量使用 AI 搜尋、AI 助手、AI 繪圖,即使單次查詢看似更省,總量卻可能飆升,最後造成更大的能源與水資源壓力。
制度的斷層:基礎設施有規範,模型層卻還是空白
歐盟其實已經開始管資料中心。《能源效率指令》(Energy Efficiency Directive, EED)要求資料中心要定期回報能源使用效率、用水量,並建立一個公開資料庫,讓社會可以監督數據中心的環境表現。這是一個往前跨出的制度步驟,確保至少在硬體基礎設施層,我們能知道 AI 擴張帶來的能源與水足跡。
但問題是,AI 的環境成本並不只發生在「機房耗多少電、抽多少水」這一層。模型的訓練與推理本身,就可能在不同地點、不同電網條件下造成巨大差異。Google 的 Gemini 和 Mistral 的 Large 2,就是最明顯的對照:前者選擇性揭露「使用端」的點狀數據,後者攤出整個生命週期的全貌。缺乏統一標準,讓科技公司可以挑自己最有利的版本來說故事。這樣的資訊落差,最後會導致監管者無法比較,投資者無從判斷,連公共採購都可能被誤導。
從行銷到問責:收據與總帳都要上桌
這正是 AI 治理要補的缺口。我們不能只接受「五滴水」這樣的收據式揭露,而是要讓模型同時交出完整的「總帳」。這意味著,除了生命週期的總量數據(訓練、推理、硬體製造、電網來源),也要有場景化的單次能效指標(例如 400 tokens、1,000 tokens、多模態任務)。只有這樣,才能在「全局負擔」和「使用細節」之間建立橋樑。
更進一步,這些數據必須依照國際標準來統一計算,並且經過第三方審核,才算具備公信力。就像金融業有國際會計準則與永續揭露準則(ISSB、SASB 等),企業不能只挑有利的數字報出來,AI 的環境治理也該往這個方向走,甚至可以借鏡金融業的「強制揭露」制度,把 AI 模型環境數據納入法規,要求大型模型或基礎模型一律登錄公開資料庫,提供社會比較。這樣才能避免出現「Google 說五滴水、Mistral 說四十五毫升」的割裂現象。
別讓 AI 成為資源黑箱
AI 治理的討論,往往集中在偏見、透明度與責任,但其實資源消耗才是另一個不容忽視的治理戰場。電與水不像程式碼,無法無中生有;它們是真實的公共財,與人類生活、農業與氣候息息相關。如果我們不補上收據與總帳之間的制度空窗,AI 可能會在效率的美麗數字掩蓋下,成為另一個吞噬資源的黑箱。
這也是一個價值選擇的問題。未來的 AI 要不要被納入 ESG 框架?政府是否該要求大型模型揭露完整的生命週期環境影響?公共採購是否該把「環境績效」列入模型評比標準?這些問題不只是技術細節,而是社會如何為 AI 設下邊界的核心議題。當 Google 提供「五滴水」的收據,Mistral 端出「四十五毫升」的總帳,真正需要的,是制度能夠要求所有人同時交出這兩張表,並且讓數據經得起檢驗。唯有如此,AI 治理才不會停留在行銷,而能回到問責的正軌。
메타데이터
- post_id
- 61c95104f358
- slug
- ai-時事解析-從-五滴水-到-四十五毫升-ai-環境揭露的真相落差-61c95104f358
- url
- https://medium.com/@airiskgovernance/ai-%E6%99%82%E4%BA%8B%E8%A7%A3%E6%9E%90-%E5%BE%9E-%E4%BA%94%E6%BB%B4%E6%B0%B4-%E5%88%B0-%E5%9B%9B%E5%8D%81%E4%BA%94%E6%AF%AB%E5%8D%87-ai-%E7%92%B0%E5%A2%83%E6%8F%AD%E9%9C%B2%E7%9A%84%E7%9C%9F%E7%9B%B8%E8%90%BD%E5%B7%AE-61c95104f358
- canonical_url
- https://medium.com/@airiskgovernance/ai-%E6%99%82%E4%BA%8B%E8%A7%A3%E6%9E%90-%E5%BE%9E-%E4%BA%94%E6%BB%B4%E6%B0%B4-%E5%88%B0-%E5%9B%9B%E5%8D%81%E4%BA%94%E6%AF%AB%E5%8D%87-ai-%E7%92%B0%E5%A2%83%E6%8F%AD%E9%9C%B2%E7%9A%84%E7%9C%9F%E7%9B%B8%E8%90%BD%E5%B7%AE-61c95104f358
- author_url
- https://medium.com/@airiskgovernance
- status
- ok
- fetched_at
- 2026-06-27 07:40:21