軟體軟體永續：為什麼能源效率
二、軟體到底怎麼耗電：四個真實的能耗來源
要改善能源效率，第一步是停止把「耗電」當成一個整體的黑箱。軟體的能耗主要來自四個地方：運算本身、資料搬移、網路往返、以及閒置。這四者的改善手段完全不同，混在一起談就永遠只能談口號。
演算法與資料結構：最容易被遺忘的效率債
在所有能耗因素裡，演算法複雜度的槓桿最大、也最容易被忽略，因為它的懲罰是非線性的。一個 O(n²) 的迴圈在測試資料只有 100 筆時感覺不到任何問題，等到上線後資料長到 10 萬筆，運算量放大一萬倍，能耗也跟著放大一萬倍——而且是每一次請求都放大。這不是「慢一點」的問題，是「吃掉整個機櫃」的問題。
同樣的道理也發生在資料結構的選擇上。用線性搜尋取代雜湊表、在迴圈裡反覆查詢同一個不變的集合、對已排序資料重新排序、把整張表載入記憶體後才篩選——這些在程式碼審查裡經常被視為「風格問題」的寫法，在規模放大之後都是實打實的能源消耗。真正成熟的團隊會把複雜度當成品質門檻，而不是等到效能出問題才回頭補救。
語言、框架與執行環境：抽象層不是免費的
2017 年葡萄牙里斯本大學團隊發表的《Energy Efficiency across Programming Languages》是這個領域被引用最多的研究之一。他們用 27 種語言跑同一組基準測試，結果相當懸殊：以 C 為基準，部分直譯式語言的執行時間與能耗達到數十倍等級的差距。當然，這個結論不能粗暴地翻译成「大家都該去寫 C」——生產力、生態系、安全性、團隊能力都是真實的成本。但它確實提醒我們一件事：每一次抽象，都有人在某處替它付電費。
實務上的槓桿不在「換語言」，而在「在對的地方用對的抽象」。資料庫的熱路徑用直譯式語言處理、每秒被呼叫上萬次的服務啟動了重量級框架的完整初始化流程、每個 API 請求都重新建立連線池、容器映像檔塞進整個作業系統——這些都是「抽象開銷沒有對應到實際需求」的典型症狀。判斷標準很簡單：這個抽象處理的資料量，是否大到足以攤平它的固定成本？如果答案是否定的，那就是純粹的浪費。
網路往返與資料傳輸：最昂貴的「再問一次」
在多數分散式系統裡，一次跨網路的呼叫（包含序列化、排隊、TLS 握手、路由）所消耗的能量，遠高於在本機記憶體裡做同樣的事。這也是為什麼「聊天輪詢」會被 WebSocket 取代、「N+1 查詢」會被視為反模式——它們的共同點都是把可以一次做完的事，拆成很多次做。
網路的能耗浪費還有幾個常見面貌：未壓縮的 JSON 傳輸（gzip 或 Brotli 可以輕易減半以上）、未最佳化的圖片（一張 3MB 的 PNG 換成 AVIF 可能只剩 150KB）、沒有設定快取標頭的靜態資源（讓使用者每次造訪都重新下載一次）、以及在服務網格中為了「可觀測性」而增加的多層 proxy 跳轉。這些單筆看起來微不足道，乘上真實流量之後就是資料中心的整排機櫃。
閒置與過度配置：最大的浪費是「沒在用」
多份企業 IT 研究指出，典型的內部伺服器平均使用率往往落在 10% 到 20% 之間，但企業習慣按「尖峰需求」配置資源。問題是，一台機器即使什麼都不做，它的閒置功耗（idle power）通常仍占其峰值功耗的三到五成——CPU 待機、記憶體維持刷新、風扇與電源供應器的轉換損耗都不會歸零。也就是說，我們有很大一部分的電，是花在「準備好卻沒用上」。
雲端環境把這件事稍微改善（共租讓使用率提高），但也同時製造了新的浪費：忘了關的測試環境、長期掛著卻沒人用的開發機、設定了 HPA 卻因為指標選錯而永遠開著三倍副本的服務、以及為了「預留尖峰」而買了整年的超額執行個體。能耗優化在這裡的本質是資源治理：把不需要的東西關掉，往往比把需要的東西寫快十倍，省下的能源還更多。
三、從評測角度看：幾個常見架構決策的真實能耗代價
抽象的討論容易失焦，我們改用評測的語言：給定一個具體的決策，能源帳單會怎麼變化？以下三個案例都是實務中極常見的選擇，我們關注的不是「哪個絕對正確」，而是「代價落在哪裡」。
案例一：ORM 與 N+1 查詢——一個數量級的差距
假設有一個訂單列表頁，需要顯示 100 筆訂單與其客戶名稱。最直覺的 ORM 寫法（先查訂單，再逐筆查客戶）會產生 1 + 100 = 101 次資料庫查詢；若改用一次 JOIN 或一次 IN 查詢預先載入，則只有 1 到 2 次。差別不只是「快 100 倍」這種粗略說法——真正的能耗差距在於：每次查詢都要喚醒連線、解析 SQL、走一次網路往返、在資料庫端佔用一個工作執行緒。101 次與 2 次的資料庫喚醒次數，對應的是完全不同的 CPU 與記憶體使用曲線。
值得注意的是，這類問題在單機開發環境幾乎測不出來（本機資料庫延遲極低），只有在真實網路與真實併發下才會暴露。這正是為什麼能源效率必須被納入負載測試，而不能只靠工程師的直覺。
案例二：微服務與單體——分散式的固定成本
微服務架構的價值在於組織解耦與獨立部署，這點毋庸置疑。但它的能耗成本是真實存在的：每個服務都有獨立的執行環境與 JVM／Runtime 暖機、服務之間的通訊需要序列化與網路往返、服務網格的 sidecar 讓每個請求多繞好幾跳、可觀測性套件（日誌、指標、追蹤）再吃掉一層 CPU。對於流量不大的內部系統，這些固定成本往往遠超過它帶來的好處。
我們在一篇評測裡常說的結論是：先把單體寫好，等到組織真的需要拆分時再拆。模組化單體（modular monolith）在很多場景下能同時拿到「程式碼邊界清楚」與「呼叫不跨網路」兩個好處。架構不是越分散越好，而是要讓分散的成本對應到真實的組織需求。
案例三：AI 推論——量化與快取的節能效果驚人
AI 工作負載是這一波能耗討論的主角，但多數討論集中在「訓練」，實際上推論的長期累積能耗往往更高，因為它每天都要跑。推論端最有效的三個節能手段，恰好也是成本優化的手段：模型量化（把 FP32 降到 INT8，記憶體頻寬需求約降為四分之一）、批次處理（把多個請求合併，攤平權重載入成本）、以及結果快取（對重複性高的查詢直接回傳）。
此外，「用大模型解決小問題」也是常見浪費。很多分類、摘要、抽取任務用小型模型就能達到可接受的準確率，能耗卻只有大型模型的零頭。評測時我們會建議團隊先問：這個任務的錯誤容忍度是多少？如果小模型只差 2% 準確率，值得多花十倍能源嗎？
常見做法
能耗主要來源
相對改善空間（示意）
見效速度
ORM 的 N+1 查詢
資料庫喚醒、網路往返
高（可達一個數量級）
快（改寫查詢即可）
服務拆分過細
常駐執行環境、跨服務呼叫
中高
慢（涉及架構重整）
未壓縮的 API 回應
網路傳輸
中（常可減半以上）
快（改設定）
資源過度配置與閒置
閒置功耗、冷卻
中（需治理流程）
未量化的 AI 推論
GPU 運算與記憶體頻寬
中（需重新驗證準確率）
前端 bundle 過大
網路傳輸、終端 CPU
快至中
（上表的「相對改善空間」為質性示意，實際幅度依系統特性差異極大；重點是它提醒我們先修那些見效快、改動小的項目，而不是一開始就投入架構重寫。）
四、把能源效率納入開發流程：從量測到制度
一個品質屬性如果無法量測，它就永遠不會被排進待辦清單。能源效率過去之所以被忽略，很大一部分原因是「看不到」。這幾年工具生態已經成熟很多，關鍵是把量測接進既有的流程節點，而不是另外開一個專案。
先能量化，才能改善：實用的量測工具與指標
在硬體層，Intel 的 RAPL（Running Average Power Limit）介面提供了 CPU 與記憶體的能耗讀取，Linux 上的 powercap 框架讓工具能取得相對準確的數據。在容器與雲端層，Scaphandre、Kepler 這類專案可以把能耗指標以 Prometheus 格式暴露出來，讓它和既有的監控儀表板並列。雲端成本面，Green Software Foundation 推動的 Cloud Carbon Footprint 與各家雲廠商陸續推出的碳足跡報表，則提供了「帳單視角」的估算。
應用層的標準化指標，最值得記住的是 SCI（Software Carbon Intensity）。它的形式簡潔：SCI = ((E × I) + M) / R。E 是執行該軟體所消耗的能源（kWh），I 是當地電網的邊際碳強度（gCO₂eq/kWh），M 是硬體製造與報廢攤提的內嵌排放，R 則是功能單位（例如「每千次請求」或「每位活躍使用者」）。這個公式最有價值的地方不是它的精確度，而是它把討論從「總量」拉回「單位功能的碳排」——只有這樣，成長中的服務才不會因為總量上升就被判定為不永續，也才能比較不同實作方式的效率。
碳感知運算：把「什麼時候算」也當成設計變數
傳統的效能優化只問「怎麼算得更快」，碳感知運算（carbon-aware computing）多問了一個問題：「什麼時候算、在哪裡算」。電網的碳強度會隨時間波動——正午太陽能充沛時可能極低，傍晚尖峰時可能飆高數倍。對於非即時的工作（報表產生、批次 ETL、模型重訓練、備份、索引重建），把它們排到低碳時段或低碳區域執行，可以在不改一行程式碼的情況下顯著降低碳排。
同樣的邏輯也適用於地理排程：把可延遲的工作送到再生能源占比高的區域執行。這需要排程系統支援「碳強度」作為排程依據，也需要團隊接受「非同步完成」的產品設計。這是近年綠色軟體領域最務實的一類做法，因為它把減碳從「工程師的額外負擔」變成「排程器的參數調整」。
編碼與架構層面的具體策略
回到程式碼本身，以下是我們在實務審查中最常建議、也最容易落地的幾項：
五、商業價值與風險：綠色軟體不是只有道德紅利
把能源效率當成工程目標，最實際的說服力往往來自財務報表。能耗與雲端成本高度正相關：減少無效查詢、關掉閒置資源、降低資料傳輸量，這些動作同時反映在電費與雲端帳單上。對多數團隊而言，FinOps 的成果就是綠色軟體最直接的效益證明，只是我們過去沒有用「碳」這個單位去描述它。
第二層價值在供應鏈與法遵。當大型企業被要求揭露 Scope 3 排放，它的軟體供應商與 SaaS 廠商就會開始收到「請提供碳足跡資訊」的通知。具備 SCI 或等效量測能力的廠商，在政府採購、金融業供應商評選、跨國企業的永續採購清單中會取得實質優勢。這不是遙遠的未來，而是正在發生的採購門檻。
但也要談風險。第一個是綠色洗白（greenwashing）：買幾張再生能源憑證、在官網放一片葉子，並不代表軟體本身變有效率了。碳抵換與實際減量是兩件事，混淆兩者會在稽核時出事。第二個是只看碳、不看其他環境衝擊：資料中心的水資源消耗、電子廢棄物、稀有金屬開採，都是同一個硬體生命週期裡的不同面向，只優化其中一項容易顧此失彼。第三個是反彈效應（rebound effect）：效率提升讓單位成本下降，反而刺激用量成長，最終總能耗不減反增。這也是為什麼 SCI 用「單位功能」作為分母——它逼我們誠實面對「我們到底提供了多少價值」這個問題。
六、結語：能源效率是軟體工程的下一個基本功
二十年前，「安全性」被視為額外功能，後來變成所有系統的預設要求；十五年前，「可觀測性」被視為進階配備，如今是上線的基本門檻。能源效率正在走同一條路：從少數人的理想，變成工程團隊的日常素養。它的特別之處在於，它同時是技術問題（演算法、架構、資料傳輸）、流程問題（量測、監控、排程）與產品問題（要不要做這個功能、要不要支援舊機）。
好消息是，你不需要等公司成立永續部門才能開始。下一次 code review 時多問一句「這個查詢為什麼要跑 100 次」；下一次架構討論時多問一句「這些服務真的需要各自常駐嗎」；下一次部署時，把閒置的測試環境關掉。這些動作不需要新的預算，也不需要新的職稱，只需要把能源當成一個你願意為它寫進驗收條件的品質屬性。
軟體之所以被稱為「軟」，是因為它可以被改。而能源效率，正是這個「可以被改」的特性，在氣候時代裡最值得被發揮的一次。當我們把每一毫秒、每一次往返、每一台沒在用的機器都看成一份可以省下的碳排放，軟體永續就不再是報告書裡的一段文字，而是每天在 commit 裡發生的事。