如果你正在做 AI 應用并且關注能源消耗這個主題值得停下來想一想AI 確實能幫電網調度、天氣預報、工業能效優化做很多事情但 AI 本身的算力增長也帶來了實打實的電力消耗還被大量用在油氣勘探、煉化優化這類直接與化石燃料相關的行業里。所以“AI 對氣候到底是有益還是有害”不能只看某一個模型或某一個場景而要把算力側、應用側、生命周期側放在一起算總賬。下面我從工程視角拆一下這個爭議。不討論宏大敘事只看運行環境、資源占用、應用場景、監控指標這些能動手驗證的部分。1. 這個爭議到底在討論什么AI 的氣候影響不是單點數很多人聽到“AI 氣候效益”時第一反應是 AI 能預測極端天氣、優化風力發電、減少交通擁堵。這些能力確實存在也確實有實際落地案例。但另一面同時存在訓練和運行大模型需要大量高功率 GPU數據中心要散熱電力消耗逐年增加而且不少 AI 項目是被能源公司采購的用于提高勘探效率、優化開采流程。這兩個方向放在一起就形成了題目里的那句判斷AI 的潛在氣候效益可能被“推動化石燃料”這個作用抵消了。1.1 AI 正面價值能優化電網、預測天氣、減少工業浪費先看正面。AI 確實能在很多高排放環節里幫上忙常見的有三塊。第一是電力系統優化。風力發電和光伏發電都有波動性AI 可以用歷史發電數據、天氣預報、負荷數據做功率預測幫調度中心更合理地安排火電、水電、儲能減少不必要的化石能源備用。這類應用不需要特別大的模型往往是一個時間序列模型配一個推理服務就能產生實際價值。第二是工業能效優化。鋼鐵、水泥、化工這類流程工業耗能巨大AI 可以基于傳感器數據做參數推薦比如調整爐溫、燃燒配比、反應時間減少能耗和廢品率。這類項目不是新概念傳統控制理論也在做但 AI 在非線性、多變量場景里更靈活。第三是建筑和交通調度。辦公樓空調、地鐵通風、物流路徑都可以用強化學習或靜態優化來降低能耗。單個場景省電有限規模化之后相當可觀。這些方向都有一個共同特點AI 在這里是“減少能源浪費的工具”而且投入產出相對清晰。1.2 負面問題AI 本身在消耗電力也在服務能源高消耗行業但 AI 不可能只做好事。第一層負面是 AI 自己的能耗。一次大規模模型訓練需要成百上千張 GPU 連續跑幾周耗電量相當于一個中型辦公園區。推理階段更隱蔽一個模型訓練完之后要持續服務用戶每天成千上萬次請求累計耗電往往比訓練還高。這個事實很多項目團隊一開始不關注等賬單出來才開始重視。第二層負面是 AI 被用在化石能源行業。最典型的就是石油天然氣上游勘探AI 用于分析地震勘探數據、識別地下構造、預測油藏分布。這類應用能顯著提高勘探成功率減少無效鉆井從這個角度看它也“節能”了但更直接的效果是幫助發現更多可采儲量維持甚至擴大化石能源開采規模。還有煉化廠參數優化、油品供應鏈調度AI 都在發揮作用。結果就形成一個悖論AI 在一頭幫助節省能源在另一頭幫助更高效地開采和消耗化石能源。到底哪個力量更大取決于具體項目、電力來源、應用規模而不是某一個宣傳口徑。1.3 爭議焦點是“系統變化”不是“某個模型是否好用”從工程角度看最重要的不是爭論“AI 是好的還是壞的”而是建立一個可計算的評估框架。你要先清楚一個 AI 系統在生命周期里消耗了什么、減少了什么、改變了什么。很多項目現在只算“業務價值”比如效率提升了百分之幾、成本降低了多少但不算新增算力帶來的電力消耗也不算使用 AI 之后對上下游能源結構的影響。這種評估方式在單點項目里沒問題放到氣候影響這個大命題下就不夠用了。真正該做的是把每臺 GPU 的功耗、每度電的碳強度、每一條請求的推理開銷以及它服務的業務方向全部放在同一個表里看。2. 算力側訓練和推理的能源賬怎么算如果你想認真回答“AI 到底消耗了多少能源”不能只憑感覺要把訓練階段和推理階段分開看。兩個階段的資源特征完全不一樣。2.1 訓練階段一次大模型訓練消耗什么訓練階段的核心成本是 GPU 集群的持續運行。影響耗電的因素主要有這幾個GPU 數量和型號高端訓練卡和普通商用卡功耗差距很大單卡功耗可以從幾十瓦到幾百瓦甚至更高。訓練時長訓練步數、批量大小、早停條件都會影響總時長。數據中心 PUEPUE 是數據中心總能耗與 IT 設備能耗的比值PUE 越高散熱和供電損耗越大。電力來源同樣是 1 度電水電、風電、光伏和火電對應的碳排放不一樣。我一般會建議項目團隊在訓練之前先做一個“資源預算”。比如你準備用 8 卡跑 3 天每張卡平均 350W那 IT 側耗電大概是 8×350×72 小時201.6 度電。再按數據中心的 PUE 1.5 算總耗電約 302.4 度。如果當地電網每度電的碳強度是 0.6kg CO2那就是大約 181kg 二氧化碳。這只是一個粗略估算但能讓你對訓練成本有個數。注意這里沒有算數據加載、存儲節點和網絡設備的耗電實際數值會更高。這個估算法只適合作為對照真正計量要用硬件功耗監控和電力賬單。2.2 推理階段批量服務和大并發的隱藏成本訓練結束后模型進入推理服務階段。很多人以為推理很輕量單次生成只花幾秒但規模化之后不是這樣。一個模型如果每小時處理 10 萬次請求每次推理平均耗時 200ms那并發壓力下需要多少 GPU 或 CPU 取決于部署方式。推理服務往往要常駐運行不管是否有請求節點都在耗電。而且為了保證響應速度團隊通常不縮容到零等于 24 小時處于待機狀態。待機耗電、自動擴容時啟動的新節點、日志采集、監控邊車這些都會追加資源消耗。更隱蔽的是多模態模型和長上下文場景。輸入一張圖片、解釋一段長視頻、分析長時間語音單次推理的計算量可能比普通文本請求高很多。如果上線前不做壓測只按文本請求的規模預估容量很可能需要開好幾倍節點才能滿足延遲要求能耗曲線直接抬上去。2.3 能耗、碳強度、PUE 和硬件利用率四個關鍵指標要衡量 AI 系統的氣候影響可以先從這四個指標入手。指標說明怎么用能耗度電/kWh某個時間段內訓練或推理服務實際消耗的電量按階段統計訓練按任務算推理按服務周期算碳強度所在地區每度電對應的碳排放量gCO2/kWh不同地區差異很大用來換算碳排放如果要對比需固定時間窗口PUE數據中心總能耗除以 IT 設備能耗PUE 越高冷卻和供電損耗越大盡量選擇 PUE 低的數據中心硬件利用率GPU/CPU 實際使用率、顯存占用率、批處理效率利用率過低時單位有效計算耗電量會明顯偏高這四個指標不是讓你只看某一個而是組合起來看。比如一個集群 GPU 利用率達到 90%說明硬件用得很充分但如果 PUE 是 2.2散熱和供電消耗占比太高整體能耗仍然不理想。反過來GPU 利用率 40% 的集群雖然單卡功耗可能不高但單位有效計算成本會翻倍。2.4 最容易忽略的是“閑置資源”我復盤過不少 AI 項目發現真正浪費的地方不是訓練本身而是閑置資源。訓練任務跑完GPU 節點沒有釋放推理服務流量低谷期還在按高峰配置跑實驗場景開了一堆 Jupyter Notebook人走了進程還掛著。這些閑置資源不會出現在模型指標里但會真實反映在電費和碳排放里。所以做能源核算時要把“節點啟動時長”“GPU 空閑占比”“服務縮容策略”都記錄進去。否則你會覺得模型跑得很快實際資源消耗比想象中大得多。3. 應用側AI 在油氣和工業里的真實角色算力側只是一半另一半是 AI 被用來干什么。同樣是消耗一度電用在電網調峰和用在油氣勘探對能源結構的影響完全不同。要理解“AI 推動化石燃料”這個判斷最好從工程場景拆開看。3.1 上游地震解釋、油藏模擬和鉆探優化油氣上游最常見的 AI 場景是地震數據處理。地震數據量大、噪聲多傳統人工解釋需要投入大量地球物理學家。AI 模型可以自動識別斷層、鹽丘、儲層反射特征將解釋時間從幾周壓縮到幾天。油藏模擬也是典型場景構建地下流體流動模型需要大量迭代計算AI 代理模型可以加速數值模擬。這些應用的直接價值是提高勘探成功率、降低無效鉆井數量。從能源角度看無效鉆井少一個意味著鉆機燃料、材料、人工都省下來。但同樣重要的是更高效、更準確的勘探會提高新儲量發現概率導致后續開采活動繼續延續。這在商業上是合理的但從氣候賬來看它會帶來新增化石能源產量和后續燃燒排放。我不在這里做商業或政策判斷。工程人員要清楚的是AI 在這類項目里的 KPI 往往是“提升勘探成功率”“縮短解釋周期”而不是“降低全生命周期碳排放”。所以當你說“AI 能減少能源浪費”時需要明確減少的是鉆探浪費還是化石燃料消耗總量。這兩個是不同尺度的問題。3.2 中下游煉化、供應鏈和能效優化油氣行業中游是管道運輸和儲存下游是煉化、銷售。AI 在煉化廠里可以做實時參數優化比如根據原油性質、設備狀態、市場需求調整催化裂化、加氫等工藝參數提高輕油收率降低能耗。供應鏈調度也是熱點原油采購、運輸安排、庫存管理都可以做成優化問題減少空駛和倉儲能耗。這類項目相對溫和因為它優化的是“把油品生產得更高效”。但如果生產規模不變甚至擴大單位能耗下降并不意味著總排放下降。所以評估時要有兩個視角一個是“效率提升”一個是“總量變化”。很多 AI 項目只能證明前者后者需要業務數據支持。3.3 工程上的判斷標準整體排放變化既然 AI 可以出現在節能場景也可以出現在勘探和生產優化場景那怎么判斷單個項目的影響我更推薦的做法是設置一個“排放影響評估基線”部署 AI 之前記錄該業務的單位產出能耗、總產出量。部署 AI 之后記錄同樣的指標并考慮新一輪業務擴張帶來的額外產量。如果總產出量不變效率提升帶來單位排放下降那好。如果效率提升導致行業整體產量增加那需要額外計算新增產量的全流程排放。很多 AI 項目不采集這些數據導致“效率提升”和“減排”劃等號。實際工程里這兩個概念經常被混淆。你要做的不是否認 AI 對業務效率的貢獻而是把貢獻放在更大的系統里重新估值。4. 工程實踐AI 系統如何做“氣候友好”設計如果你已經決定在自己負責的 AI 項目里加入能耗和氣候視角下面這些做法都可以直接落到流程中。4.1 需求評估不該用 AI 的地方別用AI 不是所有問題的默認解。有些場景用規則引擎、線性回歸、緩存策略就能解決硬搬大模型只會增加資源開銷。我見過不少項目把“用戶問題分類”從正則升級成大型語言模型準確率提升有限推理成本上漲十幾倍。所以在立項階段先問三個問題用 AI 是否真的能帶來可度量的增益有沒有更輕量的傳統方法可以達到 80% 的效果模型上線后預期請求量、并發量、QPS 是多少如果答案偏向“現有的簡單方法已經夠用”就應該選擇更簡單的方案。這不是排斥 AI而是避免無意義能耗。低能耗 AI 的第一個原則是“盡量不用 AI”。4.2 模型瘦身量化、蒸餾、剪枝如果你的場景確實需要 AI那就要控制模型體積。目前比較成熟的技術包括量化把模型權重從 FP16 壓縮到 INT8、INT4推理時顯存占用變小速度往往也會提升。蒸餾用大模型生成訓練數據訓練一個小模型讓它模仿大模型的輸出。領域簡單時小模型效果可以非常接近大模型。剪枝把網絡中貢獻較低的權重刪掉減少計算量。結構化剪枝對硬件更友好。提前退出對簡單輸入模型在較淺層就能輸出不必跑完全部網絡層。模型瘦身不是越狠越好。量化會導致精度輕微下降蒸餾需要額外訓練成本剪枝需要重新驗證。我建議先拿測試集做對比量化后模型 F1、準確率、生成質量是否在可接受范圍推理延遲和顯存是否明顯下降。能通過就上。4.3 部署優化按需擴容、冷熱分離、調度部署階段是能耗優化的重頭。要點是讓資源使用貼合真實流量曲線。首先是容量規劃。不要按峰值流量一直保留全部節點。可以設置自動擴縮容比如 CPU 超過 70% 持續 2 分鐘再擴容流量下降后縮容。這樣能減少低谷期的空閑浪費。其次是冷熱分離。高頻使用的模型放 GPU 節點低頻使用的模型放到 CPU 節點或者干脆按需加載。很多公司把所有模型都塞在 GPU 集群里低頻模型一天只有幾十次調用GPU 卻一直在線。這種情況用一個輕量 CPU 服務加冷啟動緩存更劃算。然后是調度。如果有多張 GPU盡量把同批次的推理請求聚合到一個批次減少重復計算。常見的 TensorRT、vLLM、ONNX Runtime 都支持動態批處理。生產環境里提高 GPU 利用率是降低單位能耗最直接的手段。4.4 運行監控給服務加能耗指標你無法改進沒有被度量的東西。AI 服務的傳統監控指標是 QPS、延遲、錯誤率、GPU 利用率但很少記錄能耗。我建議在監控面板里增加這幾項每服務每小時耗電kWhGPU/CPU 平均利用率每千次請求平均耗電當前電力碳強度估算如果有第三方 API 或電網數據按模型版本統計的累計能耗和碳排加這些指標不復雜。GPU 可以用 nvidia-smi 輪詢功耗CPU 可以用 RAPL 讀取配合 Prometheus 和 Grafana 就能搭一套基礎能耗看板。有了看板之后你才能回答“上一個模型版本比這個版本更費電嗎”“新上線的量化模型省了多少電”這類具體問題。建議先不要追求精確到毫瓦級別的計量。第一周只需要在原有的可觀測性系統里加上“GPU 功耗匯總”和“每請求功耗”兩個指標就能發現很多意外。5. 一份可落地的綠色 AI 排查清單理論說得再多最終要落到操作。下面這份清單是我自己在項目里經常使用的順序適合從單體 Demo 到批量服務排查能源問題時參考。5.1 從最小樣例到批量任務的能源差異第一步永遠是先跑一個最小樣例。如果一條輸入都跑不通就不要討論批量性能和能耗。最小樣例要驗證的內容包括模型能正常加載輸出結構符合預期。單次推理時顯存占用、時間消耗在合理范圍。輸出目錄、日志路徑、臨時文件不會把磁盤寫滿。跑通之后再進入批量任務。批量任務里要注意輸入順序和數據傾斜。比如一批數據里混入幾張超大分辨率圖片處理時間可能比其他數據高出 10 倍導致整體隊列阻塞。不要一上來就開 30 個并發先用 1 個進程處理 50 條數據記錄總耗時、峰值內存和功耗再逐步加并發。5.2 參數取舍批大小、并發數、早停標準能耗優化需要關注一組參數之間的平衡。常見的有訓練批大小增大批大小能提高 GPU 利用率但顯存不夠時反而需要梯度累積增加時長。推理并發數并發過高會導致排隊和重試浪費資源并發過低則節點利用不充分。一般通過壓測找到“延遲拐點”。訓練輪數沒有早停的模型訓練很浪費。建議設置驗證集指標連續 N 個 epoch 不提升就停止。輸出長度限制大模型的推理耗時和輸出 token 數強相關限制最大輸出長度能顯著降低耗時和能耗。這些參數沒有絕對最優值。我一般會記錄“單位有效輸出的能耗”而不是只盯著“訓練時間”。比如增加批大小讓訓練時間縮短但如果顯存不足導致 OOM 重啟反而更耗資源。5.3 常見誤區速度、占用和碳排之間的關系容易踩的誤區有三個。第一個是“速度快就是能耗低”。不一定。如果提速是通過把模型從 CPU 換到高功耗 GPU 實現的單次耗時下降但單位能耗可能上升。要看整機功耗和響應時間的乘積。第二個是“模型越小一定越環保”。小模型確實推理成本低但如果效果達不到要求需要重復訓練、調參、重寫提示詞整體碳排可能更大。對比時要看達到同樣質量水平下的總成本而不是單看參數量。第三個是“本地跑比云端更環保”。本地和云端的能耗取決于硬件效率、資源利用率和電力來源。本地一臺滿載的舊服務器可能比云端一個高效按需實例更耗電云端如果不縮容同樣浪費。核心是看資源利用率而不是部署位置。5.4 排查順序耗電異常時怎么一步步查如果你的監控發現某個 AI 服務耗電異常升高建議按下面順序排查看流量這個時間段的 QPS、輸入數據量、請求類型是否出現異常。長文本、視頻、圖片請求數量增加會直接推高計算量。看容量節點數量、GPU 利用率和顯存占用是否異常。如果節點沒變化但功耗升高多半是單請求變重如果節點自動擴容了要看擴容閾值是否設置過低。看依賴是否有定時任務、數據同步、日志采集在同一時間搶占 CPU/磁盤/網絡。看模型版本最近是否發布過新模型權重大小、量化方式、推理框架是否變更。看配置批處理大小、最大輸出長度、并發上限、超時時間是否被修改過。這個順序能覆蓋大多數情況。不要上來就懷疑模型本身很多能耗問題其實是流量波動和部署配置引起的。6. 結語AI 不會天然帶來氣候收益工程化時要算總賬把算力側和應用側放在一起看會更清楚這個主題的關鍵AI 的潛在氣候效益是存在的但它不是自動發生的AI 在幫助提高能源效率和幫助發現更多化石能源這兩個方向上同時發揮作用。對工程團隊來說真正能控制的部分不是宏觀能源結構而是自己設計、訓練、部署的 AI 系統到底消耗了多少資源以及它服務的業務方向能不能帶來可持續的收益。6.1 我的實測經驗從三個視角拆開看我做過幾個 AI 項目的能耗復盤最有價值的改變就是拆開算三筆賬。第一筆賬是訓練賬。每次訓練任務跑完先看 GPU 累計功耗、訓練輪數和早停條件。很多訓練任務多跑了十幾輪性能提升微乎其微。第二筆賬是服務賬。推理服務上線后記錄每周 QPS、節點數量和 GPU 利用率。遇到流量下降 70% 的周末節點數沒變這就是最大浪費。第三筆賬是應用賬。這個 AI 系統上線后到底改變了什么。如果是優化電網調度那看單位電量節省如果是油氣勘探那看它對后續業務產量的影響以及能否在業務目標里加入“降低無效鉆探”這類指標。這三筆賬不用做得很復雜Excel 或者一個簡單的統計腳本就能完成。關鍵是形成對照讓每次工程決策都有能耗依據。6.2 給做 AI 項目的人三條建議如果你正在負責 AI 業務我建議從今天開始做三件事第一給現有模型服務加一個“能耗概覽”面板至少記錄 GPU 功耗和每千請求耗電。不一定要立刻優化但要能看到趨勢。第二在模型選型評估表里新增一列“資源成本”把推理耗時、顯存占用、整機功耗和后續擴展成本寫進去。不要只看準確率。第三在項目立項時明確一個問題這個 AI 系統是讓某項活動的總排放下降還是讓單位產出效率更好了如果是后者要意識到它可能被更大的業務增長所掩蓋。不要把這個矛盾藏起來把它寫進風險清單和業務方一起討論。6.3 最后一句話AI 的氣候影響從來不是一句“AI 會毀滅環境”或“AI 能拯救地球”就能說清的。真正值得做的是在每一個 AI 項目的需求、訓練、部署、監控環節里把能耗和業務價值放在同一張表上計算。把這件事做好比單純等一個“綠色 AI 框架”要可靠得多。