論文閱讀：基於強化學習的數據中心冷卻控制

2022 年 10 月 8 日
筆記
🍵 論文閱讀

全文主旨【省時間快讀】

寫在前面：

本次全文快讀，使用了 Dmitry Berenson 的讀論文方法（感覺很實用，所以特意寫了一篇部落格）。
論文標題：Transforming Cooling Optimization for Green Data Center via Deep Reinforcement Learning，用深度強化學習做數據中心冷卻的優化。發表於 2019 年，已經被引 116 次。
不清楚這篇 2019 年的論文是否算 RL 做此類優化的早期工作；
- Google Scholar 上，最早的相關工作是在 2017 年，18 年開始變多；
- 除了數據中心冷卻之外，建築的 HVAC（Heating Ventilation and Air Conditioning，供暖通風與空氣調節）也比較多。
最後，這篇部落格是我斷斷續續寫了將近兩個月才發出來的，中間跑去實習、又跑去保研、學運籌學、干各種事情，一直擱置到現在。
- 前幾天有在讀《Lessons from AlphaZero》，並且參加一些組會，對自動化有了一些新的認識。現在看來，下文的部落格內容，可能有些太激進、過於偏頗了。
- 對於我的個人觀點，讀者隨便看看就好。RL 是否純粹，可能沒那麼重要，重要的是我們把問題解決了，這就足夠了。

layer 1：知道 main idea

【問題定義】作者試圖解決 / 研究什麼類型的問題 / 現象？
1. 我們希望幫助數據中心節能。數據中心的能耗主要分為三部分：① 電腦跑程式的能耗，② 冷卻電腦的能耗，③ 房間照明、監控等其他 misc 事情（一般不考慮）。
2. 然而，我們不能影響數據中心的任務調度（比如 A 機器已經很忙了，再幹活就過熱了，所以把任務強行塞給 B 機器），只能影響冷卻系統（比如空調、冷卻水等），控制冷卻系統的功率、運作方式等。
3. 我們的目標是：合理控制冷卻系統，使得 ① 機器不過熱 ② 能耗盡量小。
【問題重要性】讀者為什麼要關心這個問題 / 現象？
1. 因為數據中心耗能很多，冷卻耗能佔一大部分，所以，如果能節省 15% 的冷卻耗能，就已經是很大一筆。
【novelty】proposed method 與 previous works 有什麼不同？
1. previous works：一般採用 two-step 的形式，先（基於物理方程、專家經驗等）建 DC 的模型，再基於進行控制。
2. proposed method： end-to-end、RL-based method（雖然感覺 proposed method 不算典型 end-to-end，並且也不能算是典型 RL）。
【為何勝出】比 previous works 好在哪裡？（比如性能更好 / 更 general / 更快）
1. general：用 neural net 代替一些模組，可以省去很多物理建模的複雜度吧。（但是隨之而來的調參複雜度，不知道怎麼樣）
2. 性能：貌似在某些情況下，性能＞baseline（一個魔改的 two-step method）。
【論文在文獻樹上的位置】這是什麼類型的方法？（通常有幾種方法可以解決相同的問題）
1. 文中有提到傳統的 two-step 解決方案，先物理建模數據中心，然後再 somehow 給出控制訊號。
2. 月出個人猜測，還會有一些用 ai 取代部分模組的方案，比如神經網路建模數據中心、啟發式演算法跑出控制訊號。
3. 這篇論文提出了全部採用 ai 技術的方案，並且採用了類似 RL 的框架。
【實際應用】這項工作有哪些應用？
1. 用來給出更好的控制，或者控制參考建議。
2. 不過在這方面有個隱憂：如果 ai 的可靠性 / 可解釋性不足夠，萬一對於某些狀態，給出了很離譜的控制。
3. 感覺我們可以添加一個安全性模組，用來攔截住離譜的控制訊號，或者做一些 model ensemble，進行一個去除最大最小的 voting。
4. 不過，那天導師說我們項目採用人工閉環，也就是程式僅提供一個控制的參考值，這是因為自動控制太貴了，人工控制便宜一點 🙁 所以如果不解決這個問題，追求人工閉環是沒有工業意義的，學術意義倒是未嘗不可。

layer 2：知道 proposed method 的 structure

【畫出整個 method 的框圖】，每一模組的目的功能 + 輸入輸出。

layer 3（不完整）：比較重要的細節

【result & conclusion 匹配嗎】結果是否證明了該方法的合理性？
- 說實話，我並不 sure… 無論如何，它看起來蠻 work 的。
- 總感覺對於一個實驗，如果想 claim 它 outperform 了 baseline，細細想來的話，可操作的點太多了。
【有無遺漏的實驗】是否有應該測試但沒測試的案例 / 場景？
- 不知道測試溫度閾值（希望數據中心氣流溫度＜某個值，就是指的這個閾值）等於其他值的情況，是否有必要。
【performance & complexity 的權衡】（對於某些可量化的指標），proposed method 相比於其他方法的優勢，能否使人接受它新引入的 complexity？
- ai 是可以的！
- 首先，對於物理建模數據中心，1. 太麻煩了，2. 對於不同場景，建模也不一樣，3. 必然會寫近似的物理公式，建模也不精確。但 ai 就可以隱藏這些複雜性，讓建模變得很容易。
  - ai 取代物理建模的劣勢：1. 原數據多樣性不夠時 train 不出模型，2. 可靠性 / 可解釋性讓人隱隱憂慮。
- 然後，對於 somehow 得到控制方案這一步，直接 neural net 輸出控制訊號，時間花費很少，只需做一次 forward，無需複雜的在線優化。
  - 不過，1. 數據不夠、2. 可靠性 / 可解釋性的問題依然存在。
- 最後，想補充一句：感覺 ai 這些優點已經成為共識，全流程 ai 的論文已經有很多了。這篇文章得到了不少引用，可能是因為借鑒了一些 RL 的框架，並且使用了 1. 把先前狀態疊起來、2. action 延後使用等 tricks，所以性能還不錯。
【不 work 的場景】方法在哪些情況下失敗？
- 可能因為測試數據太少、並且不夠多樣（嚴重的聚簇，這確實是個棘手的問題），模型並不能很好處理某些溫度預測：實際溫度會突然出現一個尖峰，這個尖峰很難被預測出來，預測值往往偏低。

0 abstract

背景：
- 數據中心（Data Center / DC）是電子商務、雲計算等領域的基礎設施，數量越來越多、規模越來越大，所以 DC 的耗能問題也備受關注。
- 然而，幾乎一半（其實才 38%）的能源成本是用來冷卻（cooling）DC 的。
- 因此，在保證安全性的前提下，抑製冷卻能源成本，是一個關鍵的操作挑戰。
現有方法：two-step 兩階段。
- 1，根據專家知識建模 DC；
- 2，通過啟發式方法 / best practice，確定冷卻的操作。
- 然而這些方法通常很難 generalize，而且因為 DC 系統的規模很大，如果模型有一點點不準確，就會導致次優解 / 不穩定的解。
- （為什麼不說啟發式方法不靠譜呢？還有不穩定，RL 不是更不穩定嗎？）
本文方法：基於深度強化學習（DRL）的 DC cooling control。
- 基於 DDPG 的 end-to-end 冷卻控制演算法（cooling control algorithm / CCA）。
  - critic network：預測 1. DC 的能源成本 2. 冷卻效果
  - actor network / policy：判定當前優化過的 control setting。
- 為了減少 critic 使用神經網路導致溫度低估（即 overestimate / 過於樂觀的估計），還引入了一個反低估（de-underestimation / DUE）驗證模組。
實驗結果：
- EnergyPlus 模擬：11% cooling 成本降低。
- 從新加坡超頻中心（NSCC）收集的真實數據：15% 成本降低。

1 intro

這個 intro 佔了將近兩頁，大部分都是 abstract 的擴寫，就不在此贅述了。

intro 最後給出了論文的 contributions：

提出了一個基於 DRL 的 end-to-end 框架，可用於 DC 冷卻控制優化。並且提出了相配套的演算法，只要有預先收集的 data trace，即可訓練神經網路。
用 EnergyPlus 建立了一個測試平台，並基於複雜的模擬驗證了 proposed method。模擬結果表明，我們相比 baselines（abstract 提到的 two-step method）可以節省 11% 的冷卻成本。
通過研究真實數據中心的 data trace，提出了一種用來消除預測溫度低估（過度樂觀）的技術 DUE。因為 proposed method 沒有在真實數據中心上跑，僅基於真實 data trace 做理論分析，所以結論有必要更保守、安全可信一點。

DC 冷卻的 two-step method [4] - [9] [20]：

第一步：建模 DC。
- 熱動力學（thermal dynamics）建模冷卻效率 [4] - [8] [20]。
- 計算流體動力學（computational fluid dynamics / CFD）分析 aire-flow efficiency [21]。
- [4] 使用了 43 個數學公式，來建模一個特定的製冷系統，即沒法 generalize 到其他結構的系統。
- 為了 generalize，[9] 用神經網路來建模。
第二步：基於 DC 模型，求解決策變數。
- 傳統優化方法 [4] / 隨機的優化方法 [9]。
然而，大多數工作都基於簡化的理想模型。

其他相關工作：

ice-storage system：冷卻優化節省能源 [22] [23]。
DC 在 IT 側的能源節省：
- 通過工作負載調度，優化 DC 的熱力圖，以減少冷卻耗能 [24] - [26]。
- 網路流量管理，減少交換機（switch）個數，以節省能源 [27]。

一些 RL / DRL 工作的羅列，月出就不詳細說了。

3 冷卻優化問題定義

3.1 基於 EnergyPlus 模擬的 RL 模型

模擬環境：
- （其實模擬環境的樣子無所謂，反正都用神經網路模擬，不會用物理建模。但是，我們需要找到最關鍵的幾個指標，作為 RL framework 的 state / observation。）
- DC 的產熱組成：
  1. IT 設備（IT equipment / ITE），負載定義為 α · L，其中 L 是已知的 load density（每平方米），α 隨時間變化。
  2. 其他熱源（如照明），認為照明不隨時間變化，看作常數。
  3. 在房間里工作的人。
- 環境：兩個房間（Zone），一個用 direct expansion (DX) cooling（即通過氣體換熱），一個用 chilled water (CW) cooling（即通過液體換熱），如下圖【圖 1 2】所示。
State Space：1. 工作負載級別 + 2. 環境溫度的元組（連續 state space）。
- 環境溫度的英文是 ambient temperature，百度翻譯為環境溫度、背景溫度、周圍介質溫度。月出推測就是當地氣溫的意思… 這模型在一個前（經典 AI 的）RLer 眼裡，有點太簡陋 😣
- 【state 和 observation 不一樣，詳見第 4 節】
Reward：基於兩個 zone 的 1. PUE（能源效率的倒數）2. ITE 出口溫度。
Action Space：根據兩個 zone 各自的的冷卻原理，action 為五元組（連續 action space），見上圖【圖 2】：
1. DX cooling：DEC 氣流出口溫度 \(T_{dec}\)，
2. DX cooling：IEC 氣流出口溫度 \(T_{iec}\)，
3. DX cooling：線圈氣流出口溫度 \(T_{dx}\)，
4. CW cooling：水循環的出口溫度 \(T_{cw}\)，
5. CW cooling：氣流循環的出口溫度 \(T_{ch}\)。

3.2 Problem Statement

已知數據：環境空氣溫度 \(T_{amb}\) + 負荷係數 \(H_{ite}\) 的元組（隨時間變化）。
action / 決策變數：\(A = [T_{cw}, T_{dx}, T_{dec}, T_{iec}, T_{ch}]\)。
最小化的目標函數：（也可認為是 -reward）
- \[\min_A \bigg[\epsilon_{pue}+\lambda\cdot\ln(1+\exp(T_{z1}-\phi))+ \lambda\cdot\ln(1+\exp(T_{z2}-\phi))\bigg] \\ \text{ s.t. } L_A\le A\le U_A \tag{1} \]
- 其中，\(L_A\)、\(U_A\) 是 action 的 lower / upper bound，\(T_z\) 是兩個 zone 的出口溫度，φ 是溫度閾值。
- 解讀：第一項希望 PUE 最小化，第二、三項是 zone 溫度過熱的懲罰。

4 method

4.1 基於 DDPG 演算法的 CCA（cooling control algorithm）

DDPG：
- Deep Deterministic Policy Gradient，是 model-free、off-policy 的 RL 演算法，支援 continuous action space。
- 結構類似 Actor-Critic，包含 policy network 和 value network，policy network 輸入 observation 輸出 action，用來估計讓 value network 值最大的 action。
DDPG 的參考部落格：
- //zhuanlan.zhihu.com/p/398288352
- 蘑菇書 EasyRL：//datawhalechina.github.io/easy-rl/#/chapter12/chapter12?id=ddpgdeep-deterministic-policy-gradient
actor / policy network \(a=\pi(s)\)：輸入 observation，輸出一個確定性的 action。
- 參數更新：梯度上升，最大化 \(Q(s,\pi(s))\)；即往輸出 \(a=\pi(s)\) 的參數梯度方向，走 \(Q(s,\pi(s))\) 步長。
critic / value network \(Q(s,a)\)：輸入 obs + action，輸出 Q value。
- 參數更新：基於 TD-error / Bellman Equation 的一步更新。
- 為緩解 over-estimation，應用了 target network；即用 target network（Q value + policy）的預測值，來更新當前網路的 Q value，一段時間後更新 target network ← 當前 network。
pretrained policy：
- 在現實情況下，肯定不能讓 policy 從初始的 random 狀態開始與環境交互（random policy 的輸出可能很危險，把整個系統過熱燒掉）；
- 並且再考慮到訓練效率（跑 simulator 比 train RL 還耗時），我們先用收集的 off-line data 進行 pretrain。
- DDPG 是 off-policy 的，所以 off-line pretrain 可行。

4.2 訓練細節

和經典的 RL 不同，我們不用未來的 reward * discount 求和做訓練，而是僅使用單步 reward 做訓練，因為未來的 reward 更多由天氣 / 工作量所決定。（月出表示意料之外 😰 ）
調節 action 帶來的影響有一個延時，因此：
1. 取過去一段時間的 state-action 軌跡，作為 observation。
2. 此刻 observation 得到的 action，等到下一個 time slot 再採用。
critic（輸入最近的 state-action 軌跡 + action，輸出 Q value）：
- Q-network 的第一層是一個 encoding，隨後的 layers 用於預測 PUE 和溫度，然後用 PUE 溫度來算 reward，這樣即可直接監督學習。
- 因為我們僅用單步 reward 進行訓練，所以 Q value（一個 action 的好壞）= reward。
- 訓練：拿真實的 PUE 和溫度，直接監督學習。（reward 是 PUE 和溫度的函數）
actor（輸入最近的 state-action 軌跡 + 當前 obs，輸出 action）：
- 訓練：最大化當前 action 的 Q-network 值。
- （訓好的 Q-network 可以直接拿來訓 policy，可以基於 off-line data trace，不需要與環境交互）
避免過擬合（不是 abstract 提到的 DUE，DUE 用於處理真實場景的溫度低估，見部落格 6.2 節）：
- 用 validation error 驗證集的誤差，取驗證集誤差最小的 policy 和 Q-network。
月出的評價：
- 披著 DDPG 結構（actor-critic）的監督學習 😓
- 不過 tricks 應該有參考意義。

4.3 神經網路設計

如圖所示：

對於 tanh 激活函數，我們把輸入歸一化到 [-1, 1]，把輸出歸一化回來。

5 評測：simulation

5.1 實驗準備

實驗環境：EnergyPlus 模擬平台。
- 由 U.S. Department of Energy Building Technologies Office 提供，用於模擬建築製冷的能耗，廣泛使用的經典模擬平台。支援自定義的演算法、control actions、schedules。
- 模擬配置：採用 EnergyPlus 提供的原始 Data Center 模型，地點（天氣）設為新加坡。模擬期為一年，每 6 分鐘收集一次模擬數據。
數據生成 & 預處理：
- 使用 random 演算法進行一年的模擬，前 55% 作為 offline training data，後 45% 用來測試。
- random 演算法中，為確保 action 平穩變化，對隨機生成的 action 進行平滑處理。
- （simulation 的數據沒有雜訊。）
baselines：
- ①：EnergyPlus 的默認演算法 DefaultE+，根據底層模型（underlying model）的目標區溫度計算設定點；
- ②：改編自 [9] 的 two-step method：
  - 第一步：在第一階段，訓練與 CCA 相同的評價網路（Q-network），對應 [9] 中冷風機（chiller）效率建模的網路。
  - 第二步：使用 SciPy [46] 提供的迭代微分進化（iterative differential evolution）優化演算法，尋找每個測試狀態的最優解。（原論文是遺傳演算法）
    - 作者說，隨便選個靠譜的優化演算法是合理的；如果問題的設定好、建模好，那麼演算法就理應 work。
    - 或許因為遺傳演算法有一些缺點（百度搜到的），然後目前使用的進化演算法，是遺傳演算法的加強版。
proposed CCA method 的細節：
- 網路結構：
  - Q-network 的 hidden-layer 大小為 50-50-3。
  - μ-network 的 hidden-layer 大小為 50-50。
  - 網路權重初始化：zero-sum、0.01-Standard deviation 隨機生成。
- 超參數：
  - 參數優化演算法為 Adadelta [45]。
  - epoch（把所有訓練數據過幾遍）數量 = 200。
  - batch size = 128。
  - 公式 (1) 中的 λ（能源成本 - 冷卻效果的 tradeoff）= 0.01。更多 λ 設置參見原文 Section 5.E。
  - 公式 (1) 中的溫度閾值（預期的目標溫度）φ = 29。
性能評估指標：
- PUE（能源效率的倒數），出口溫度 1，出口溫度 2。

5.2 實驗結果

表1 + 圖4：proposed CCA method 與 baselines 的性能比較。τ 是部落格 4.2 節提到的「過去一段時間的 state-action 軌跡作為 Q-network 輸入」的 stat-action pair 數量。

圖5：一個 proposed CCA method 與 baselines 的模擬軌跡（PUE、兩個出口溫度）。

結論：

PUE：CCA 明顯低（1.37 → 1.33，節省 11% 冷卻功率），TS 比 DefaultE+ 好。
出口溫度：「比其他方法高，但令人滿意。」（倒是能看出來 TS 比 DefaultE+ 明顯好：PUE 沒怎麼變，溫度還低）
- 說實話，月出讀到這裡時，很懷疑 CCA 只是用溫度換 PUE，其實性能沒提升。畢竟，論文怎麼不放出口溫度閾值 ≠ 29℃ 的實驗結果呢，數據中心冷卻非要 29℃ 不可嘛？該不會因為其他不 work 吧 😰
- 部落格 5.3.3 節有其他的結論，證明 CCA（在某種程度上）還是比 TS 性能好的，不過仍沒完全打消疑慮。
Q-network 輸入長度 τ = 3 時：TS 和 CCA 都不太穩定，可能因為模擬數據沒有雜訊，所以 Markov 性質比較好，用過去一步的數據就夠了。用更多的過去數據來參考，反而帶來了干擾。

細節：

學到的 action 符合物理規律。action 里的溫度 \(T_{dec}\)、\(T_{iec}\) > \(T_{dx}\)，因為熱氣流會從 DEC、IEC 逐漸冷卻到 DX 線圈；\(T_{ch}\) > \(T_{cw}\)，因為送風溫度不能低於冷卻氣流的冷卻水溫度。

性能提升＞增加的複雜性？

淺看了 [9] 的原方法，大概是用一個 ANN 擬合出模型（特定控制變數下，溫度是多少、能源消耗是多少），然後用遺傳演算法確定控制變數（冷水系統負載是多少、冷水流量是多少）。
相比於 [9]，我們的方法用神經網路確定控制變數，而不是用啟發式方法。policy network 不是完全監督訓練的，而是儘可能最大化 Q-network，比如走 Q-network 輸出值這麼大的梯度步。
對於每次控制，遺傳演算法貌似每次都要跑一整遍，而 neural net 只要跑個 forward 即可。用訓練時間變長，換測試時間變短，值得。

5.3 更換某個組件後的實驗

5.3.1 改變 DRL 演算法

DRL 演算法的 counterpart：

A3C（fake）：
- A3C 簡介：
  - Asynchronous Advantaged Actor Critic，是 actor-critic 演算法 1. 將 value function 或者 Q function 寫成 advantage 的形式，2. 進行非同步的多 CPU 操作。
  - 具體的，（如果多 CPU）每個 CPU 對應一個 agent，這些 agent 在不同地方獨立運行。一個 agent 跑完之後，把策略梯度傳給中心進程 / 執行緒，中心進程 / 執行緒更新參數，再把最新參數傳給這個 agent。
  - 參考部落格：蘑菇書 EasyRL，it's enough，鏈接。
- 作者的魔改：
  - 作者認為 advantage 是沒意義的，「因為無法判斷某個負荷水平是否良好」。月出感到質疑：
    - 目前，state 是 1. 工作負載級別 + 2. 環境溫度的 tuple，action 是一些冷卻系統的出口溫度設定。感覺可以判斷一個 state 是否優於另一個 state、一個 action 是否優於另一個 action。
  - 所以，A3C 被魔改成了多個 CCA 模型的集成（月出直呼離譜 😱 ）並且，「multi-agent」這詞也不興這麼用呀 😣
  - ~~看來，只能指望月出本人做出很強的工作，進行 RL 和自動化的神妙結合了！~~ 哈哈哈 😝 嚴肅的說，月出最想做的，是對工業界真正有意義的事情，無論是否 RL。
TRPO（半 fake）：
- TRPO 簡介：
  - Trust Region Policy Optimization，是一種 model-free、 on-policy、policy gradient 的演算法，核心思想是：在 vanilla policy gradient 的基礎上，保證每次策略更新都有性能提升。
  - 參考部落格：
- 作者的魔改：
  - 通過每次隨機選取 off-line data，裝作是當前 policy 新跑出來的 trajectory，實現 on-policy → off-policy 的轉換。
  - 月出看到這裡，直呼 on-policy 不能這麼改 😱😱 不過仔細想想，如果只考慮一步 reward，相當於每個 episode 長度都為 1，初始狀態是唯一的狀態；而經典 RL 認為，初始狀態是系統隨機給的，和策略沒關係，所以隨機取樣的初始狀態，和 on-policy 的初始狀態等價…… 竟意外的說通了。
  - （所以，所以，只考慮單步 reward 真的合理嘛 😰 ）

表2：

結論：

模型集成的 CCA 比單個 CCA 好一點。
TRPO 不太穩定，可能因為它是 policy gradient，沒有用到 value / Q network（CCA 用到了）。
anyway，CCA 算是不錯的設計。

5.3.2 改變 network design

網路設計的 counterpart：

target network：DDQN / DDPG 減少 Q network 高估的 trick，原理是「避免打移動靶」。
ReLU net：將 CCA 的激活函數從 tanh 替換成 relu。
LSTM net：用 LSTM 層來處理最近的歷史軌跡，而非直接 concat 成 state-action trace。（使用了部落格前文 5.2 節中 τ = 3 的情況）

表3：原來 CCA 與 1. target network，2. relu net，3. LSTM net 的性能比較。

結論：

target network 和 CCA 差不多，作者說，因為 CCA 的 Q function 收斂非常快。
- 難道不是因為，Q-network 是用 PUE / 出口溫度 監督訓練 的嘛，不會出現打移動靶的問題 😓
ReLU 明顯弱於 tanh，可能 ReLU 還是太線性了，表達能力不強。進一步實驗表明，ReLU 配上更多 hidden-layers 會好一些。
LSTM 和 CCA 差不多，不過不太穩定。作者認為合理，因為 LSTM 的訓練更複雜。

5.3.3 改變能源成本 - 冷卻效果的權衡 λ

圖6：從 0.0 到 0.04 調整 λ 的結果。

結論：

λ ↗，溫度的重要性 ↗，PUE ↗，溫度 ↘，合理。
如果想達到像 TS 那樣的 26℃，可以 λ = 0.04，此時 PUE 大概 1.365，比 TS 的 1.371 好。現在我相信 CCA 比 TS 好了。
- 但是 anyway，感覺作者不會對 TS 做像調整 λ 這樣精細的操作，所以，好性能也可能是調出來的。

細節：

作者說，可以通過由粗到細的直線搜索來調整 λ，簡單並且效果好。

6 評測：真實數據

6.1 實驗準備

真實環境：
- 數據來源：新加坡國家安全中心（NSCC of Singapore）。
  - 數據收集：2017年3月1日 ~ 3月15日，每 3min 收集一次數據，前 85% 用來訓練，後 15% 用來測試。
- 場景：
  - 房間里有 26 個機架，三個 PCU（precision cooling unit，精密冷卻裝置）提供冷空氣，冷空氣溫度約為 20℃，如圖所示：
  - 冷空氣的循環路徑：首先進入冷通道（cold aisle），然後穿過機架，最後返回 PCU。
  - 其他冷卻設施：對 1-20 號機架，即超頻機架，附加一個溫水冷卻系統（warm water cooling system）；對 21-26 號機架，即用來管理的機架，附加一個後門冷卻系統（rear-door cooling system）。
- 優化目標：
  - 我們希望，在保持機架平均進口溫度的同時，最小化 PCU 功耗。也就是說，提供剛好夠用的冷空氣，避免額外冷空氣的浪費。
  - 目標函數：
  - \[\min_{f_{pcu}}\bigg[\epsilon_{pcu} + λ\cdot\ln(1+\exp(T_{intake}-\phi))\bigg] \tag{2} \]
  - 其中，\(f_{pcu}\) 是控制動作（氣流速率），\(\epsilon_{pcu}\) 是 PCU 功耗。溫度閾值 Φ 設定為 27℃，因為我們的目標是將進氣溫度控制在 27℃ 以下。

問題定義（見原文表 4）：

state：

功率型	flow rate 型	溫度型
P1：機架 1~26 的總功耗	F1：溫水冷卻系統的 water flow rate	T1：溫水冷卻系統的溫水溫度
P2：其他機架的總功耗	F2：其他 PCU 的 air flow rate	T2：要優化的這三個 PCU 的平均冷風溫度
P3：溫水冷卻系統的 heat load 總和	F3：後門冷卻系統的 water flow rate	T3：其他 PCU 的平均冷風溫度

action：
- flow rate 型
  
  F4：要優化的這三個 PCU 的 air flow rate
reward：
- 功率型溫度型
  
  P4：要優化的這三個 PCU 的功耗 T4：平均機架進口溫度

實驗細節：
- 訓練方法：先讓 Q-network 學預測溫度（監督學習），確保溫度能預測好，然後用 Q-network 訓練 μ-network，得到 policy。
- 測試方法：對測試數據的每個場景，用 μ-network 給出 action，然後把 (state, μ 輸出的 action) 輸入 Q-network，將 Q-network 預測的溫度作為性能評測依據。
- Q-network（critic）：
  - 在 episode 長度 = 1 的 RL 下，Q-network 預測特定 state 特定 action 下的預期 reward。
  - 本場景中的 reward 由 ① PCU 功耗 ② 機架進口溫度決定。由於功耗可以直接拿 air flow rate 算出來，air flow rate 是我們的 action，所以 Q-network 只需要預測進口溫度。
  - 只要進口溫度預測足夠精準，即可算出 reward。所以，最後變成了 監督學習 預測進口溫度。
- μ-network（actor）：
  - 拿到足夠精準的 Q-network 之後，相當於得到了環境的溫度模型。μ-network 只需在該模型下，學習自己輸出什麼功率，才能 ① 維持機架溫度合適 ② 自己功率不太高即可。
  - （和前面實驗一樣，也基本相當於監督學習。）
- baseline：就是原數據，跟原本情況比較 ① 功耗是否更低 ② 溫度是否更低。沒有其他演算法的 baseline。

flow rate 型
F4：要優化的這三個 PCU 的 air flow rate

功率型	溫度型
P4：要優化的這三個 PCU 的功耗	T4：平均機架進口溫度

6.2 實驗結果（包含 DUE）

圖8：Q-network 輸出溫度在不同 τ 下的結果，τ 是部落格 4.2 節提到的「過去一段時間的 state-action 軌跡作為 Q-network 輸入」的 state-action pair 數量。

結論：τ = 4 時，Q-network 擬合溫度模型效果最好，MAE = 0.094℃。

作者說，儘管誤差看起來很小，但可能因為模型更多去擬合落在中間的數據，（對過熱過冷的情況全部無腦輸出中間溫度），導致低估了過熱情況的溫度，給出了過度樂觀的估計。

DUE：

因為沒法在真實 DC 上跑我們的演算法，所以重要的是，我們要首先產生一些可靠的理論結果。低估溫度是不可靠的情況，要盡量避免其發生。
為了解決這個問題，作者使用了一個叫做 DUE 的 trick，具體的，在計算驗證誤差時（原論文 CCA 演算法 11 行，如果目前 Q-network 誤差＜原先 Q-network 誤差，則更新 Q-network），將原來的平方誤差替換成只考慮低估誤差。
- （內心 OS：好不優雅 😑 不過 maybe works）

圖9：（並沒有說 τ 是多少）溫度擬合的一小段數據，🔴 是真實值，📗 是不使用 DUE 的擬合結果，🔵 是使用 DUE 的結果。

作者說，雖然加了 DUE 之後，誤差變大了好多，整個曲線都往上漂移了，但至少低估溫度的情況有所緩解。

月出發現，對於某些尖刺，目前的擬合結果都不太好。對於這種異常值，或許可以考慮用 AdaBoost 來做？

然後，我們研究了懲罰參數 λ（目標函數 (1) 中，溫度超出預設的 penalty 的權重）不同的情況。

圖10：在不同的 λ 下，藍線是能源節省的百分比，紅線是最大入口氣溫。

能源節省率 ↑，氣溫 ↑，相當於用更少的能源去開空調了，合理。作者聲稱，如果設定的溫度閾值＞26.6℃，則可以輕鬆節能 15%。

雖然但是，現在不是變化 λ 嘛，已經把溫度閾值設為 27℃ 了。……Hang on，溫度閾值 = 27℃，最大入口氣溫才不到 26.6℃，相當於溫度完全不超標呀！這是真的嘛？（那麼變化 λ 的意義是什麼）
月出有一點懷疑實驗結果 😓

圖11：在不同的 λ 下，控制動作（air flow rate）和氣溫（預測值）的比較。黑十字是真實值，🔶 線的顏色越深，λ 越小（氣溫越不重要）。

λ ↑，氣溫重要性 ↑，air flow rate ↑，預測的氣溫 ↓，合理。

7 conclusion

問題背景、方法概述、實驗結果就不多說了，不過 conclusion 的第三段，提到了一些問題：
1. 數據清潔度：收集到的數據雜訊 / 異常值太多。據作者說，當問題規模較大時，這個問題會帶來比較大的影響，需要在應用演算法之前，先仔細處理數據。
2. 數據多樣性：在真實數據中，（舉個例子）比如空調一直開 26℃，所以拿 26℃ 的數據訓練，就完全學不到如果空調開 25℃，溫度會怎麼變化。
3. 調超參數：將演算法應用於不同數據中心時，調超參數（如 λ、τ）是不可避免的。

Tags: 🍵 論文閱讀