計算驅動熱力學基礎設施

從被動散熱到由工作負載、算力狀態與任務預測直接驅動的物理設施控制

English Title: Compute-Driven Thermodynamic Infrastructure: From Reactive Cooling to Workload-Driven Physical-State Orchestration

Series: ANCSI — AI-Native Computational and Scientific Infrastructure
Paper: ANCSI-03
Version: v0.1
Date: 2026-09-23
Type: 公開命題／工程猜想論文（Public Proposition / Engineering Conjecture Paper）

作者： Neo.K
機構： EveMissLab／一言諾科技有限公司

摘要

現代資料中心與高效能計算設施通常將計算系統與冷卻系統視為高度耦合但仍相對獨立的工程子系統：伺服器產生熱，冷卻系統依感測結果將熱排除。近年的熱感知工作負載排程、模型預測控制、液冷、冷量儲存與 AI 資料中心整合設計已開始打破此界線，顯示計算負載、熱管理、能源與冷卻設備可以進行協同最佳化。

本文提出更進一步的「計算驅動熱力學基礎設施（Compute-Driven Thermodynamic Infrastructure, CDTI）」命題：在未來高密度 AI 計算、高效能運算、低溫計算與量子—傳統混合計算設施中，計算狀態不應只被視為熱源，而應成為物理基礎設施的上游控制變數。系統可根據當前與預測的工作負載，提前配置溫度、冷媒流量、熱耦合拓樸、冷量儲備、泵浦、閥門、能源、任務位置與硬體工作模式，使「計算排程」與「熱力學排程」逐步收斂為同一個跨層控制問題。

本文不假設所有計算機都需要低溫，也不主張單純降低溫度必然提高總體能效。相反，CDTI 將低溫、常溫、暖水冷卻與特殊極低溫節點視為異質 thermal states，並將狀態轉換成本、熱循環壽命、冷量儲備、可靠度與計算性能共同納入決策。本文提出 Compute-to-Thermal Compiler、Compute-Thermal State Machine、Thermal Admission Control、Cold-Budget Scheduling、predictive preconditioning 與 local fail-safe autonomy 等初步架構，並將其表述為一組可證偽工程命題。

關鍵詞： compute-driven infrastructure、thermal-aware scheduling、AI data center、model predictive control、liquid cooling、thermal storage、cryogenic computing、workload orchestration、cyber-physical systems、thermal admission control

1. 問題：為什麼「先算、再散熱」可能不再足夠

傳統計算設施的熱管理鏈條通常可簡化為：

\text{workload} \rightarrow \text{compute} \rightarrow \text{heat} \rightarrow \text{cooling response}.

這是一種典型的下游反應模型。

計算系統先決定在哪裡執行工作；功率消耗隨之產生；冷卻系統再根據溫度、壓力與流量感測結果調整風扇、冷水機、泵浦或其他設備。

若計算負載較穩定、設備功率密度低、熱慣性大且冷卻裕度充足，這種架構通常足夠有效。

但高密度 AI 與 HPC 正使下列條件同時出現：

rack 功率密度快速上升；
大型 GPU cluster 可產生同步功率與熱負載變化；
液冷逐漸成為高密度 AI / HPC 的主流路徑；
冷卻設備與計算工作負載具有不同時間尺度；
不同機架、晶片與區域具有不同 thermal margin；
工作負載本身具有可預測性與可遷移性；
部分系統可利用 thermal storage；
部分特殊計算硬體可能工作於顯著低於室溫的環境；
AI scheduler 已能處理高維度、多限制資源配置問題。

ASHRAE、PNNL 與 NEMA 的 AI Data Center Energy Performance Framework 已明確指出，AI 資料中心的 power 與 cooling 不能再被視為可完全分離的領域；高密度 AI rack、液冷、電力架構與整體設施設計必須從一開始共同考慮 [1][2]。美國 DOE 於 2026 年延續 COOLERCHIPS 1.5 計畫，目標包括測試可處理每 rack 約 $1\ \mathrm{MW}$ 熱負載的先進冷卻系統 [3]。

因此，問題開始從：

這個 workload 產生多少熱，我要怎麼把它移走？

轉變為：

在任務執行之前，我應把 workload 放在哪裡、把哪些熱區預先調到什麼狀態、預留多少冷量、開啟哪些流體路徑，才能使整個計算—物理系統成本最低？

本文將這個問題稱為：

\boxed{ \text{Compute-Driven Thermodynamic Infrastructure} }

或簡稱 CDTI。

2. 核心命題：計算狀態不是只有熱源，而是基礎設施控制訊號

在傳統模型中：

P_{\mathrm{compute}}

主要被視為 thermal plant 的 disturbance。

也就是：

x_{k+1} = f(x_k,u_k,P_{\mathrm{compute},k}),

其中 $x_k$ 為熱狀態， $u_k$ 為冷卻控制。

CDTI 則重新定義：

P_{\mathrm{compute}}

不只是 disturbance，而是可預測、可調整、可移動的控制相關變數。

工作負載可以被：

延後；
遷移；
分割；
降速；
批次化；
預取；
重新配置；
映射至不同硬體；
切換到不同 thermal class。

因此計算與熱系統應寫成共同狀態：

X(t) = \left[ C(t), \Theta(t), E(t), R(t) \right],

其中：

C(t) = \text{compute state},

\Theta(t) = \text{thermodynamic state},

E(t) = \text{energy state},

R(t) = \text{reliability / risk state}.

控制量則同時包括：

U(t) = \left[ U_C, U_T, U_E \right].

其中：

U_C = \text{workload scheduling actions},

U_T = \text{thermal / fluid control actions},

U_E = \text{power / storage actions}.

所以控制目標變成：

\boxed{ \min_{U_C,U_T,U_E} J(X,U) }

而不是先固定 $U_C$ ，再由 $U_T$ 被動補救。

3. 現有工程已經開始走向 Compute-Cooling Co-Optimization

CDTI 並非從零開始。

2019 年已有 HPC 資料中心研究把 resource provisioning、thermal-aware allocation 與 dynamic cooling management 放入同一個控制框架，並使用 economic model predictive control 預測 rack power 變化後調整冷卻狀態 [4]。

2025 年的研究則進一步把 IT workload migration、cold storage tank 與 cooling-system operation 放入同一套 model predictive control 中，以 workload migration 和冷量儲存共同改善資料中心能源效率 [5]。

2026 年一項針對資料中心的研究更直接建立：

\text{thermal-aware workload scheduling} + \text{DRL cooling control}

的聯合架構。該研究建立 server outlet temperature prediction model，依 thermal state 重新分配 workload，並以 Soft Actor-Critic 控制 CRAC；在其模擬條件下，相較傳統方法，冷卻能耗最高降低約 $8.6\%$ ，server outlet temperature threshold violation 由 $184$ 次降至 $1$ 次 [6]。

這些結果不能直接證明本文所提出的設施級 CDTI 一定具有相同比例的效益。

但它們證明了更重要的一件事：

\boxed{ \text{compute scheduling and cooling control are already becoming one optimization problem}. }

CDTI 的新一步，是把這種協同控制由「資料中心 cooling optimization」提升成：

\boxed{ \text{facility physical-state orchestration}. }

4. 從 Compute Load 到 Compute State

單純使用：

P_{\mathrm{compute}}

作為控制輸入仍然太粗糙。

對未來 AI 原生基礎設施而言，應考慮完整計算狀態：

C(t) = \left[ W, H, L, D, Q, S, \tau, \Pi \right]_t.

其中：

W = \text{workload type},

H = \text{hardware mapping},

L = \text{instantaneous load},

D = \text{deadline / latency constraints},

Q = \text{quality-of-service requirements},

S = \text{job state / checkpoint state},

\tau = \text{predicted duration},

\Pi = \text{power / performance profile}.

兩個功率相同的 workload，可能具有完全不同的最佳 thermal policy。

例如：

一個 $20\ \mathrm{MW}$ 、持續 $20$ 秒的 burst；
一個 $20\ \mathrm{MW}$ 、持續 $8$ 小時的 training job；

對 thermal plant 而言並不是同一種事件。

因此：

\boxed{ \text{thermal policy must depend on workload structure, not only instantaneous watts}. }

5. Compute-to-Thermal Compiler

本文提出一個中介層：

\boxed{ \text{Compute-to-Thermal Compiler} }

其作用不是直接控制閥門，而是把計算意圖轉換成可驗證的 thermal plan。

輸入可以是：

Job:
  class: training
  accelerator_count: 8192
  earliest_start: t + 180 s
  duration_estimate: 6 h
  peak_power: 26 MW
  latency_sensitivity: low
  checkpointable: true
  thermal_class_allowed:
    - normal
    - boost

compiler 輸出：

Thermal Plan:
  target_zone: Cluster-B
  preconditioning_start: t + 90 s
  coolant_supply_target: ...
  required_cold_reserve: ...
  thermal_margin: ...
  storage_dispatch_limit: ...
  heat-reuse route: ...
  fallback_zone: Cluster-D
  abort_conditions: ...

形式化表示：

\mathcal{C}_{T} : C_{\mathrm{intent}} \rightarrow \Theta_{\mathrm{plan}}.

但：

\Theta_{\mathrm{plan}}

仍然不是 actuator command。

真正控制鏈應是：

\boxed{ \text{Compute Intent} \rightarrow \text{Thermal Plan} \rightarrow \text{Constraint Validation} \rightarrow \text{Local Control} \rightarrow \text{Physical Actuation} }

這樣高階 AI 可以規劃，但 deterministic controller 與 local safety system 仍保留對物理設備的最後約束。

6. Compute-Thermal State Machine

CDTI 不應假設所有計算硬體永遠工作於同一 thermal state。

可以為每個 compute zone 定義：

M_i(t) \in \mathcal{M}.

例如：

\mathcal{M} = \{ M_0, M_1, M_2, M_3, M_4, M_F \}.

其中：

$M_0$ — Idle / Warm

系統接近適合待機與低基礎設施能耗的狀態。

$M_1$ — Normal Compute

以一般液冷或暖水冷卻執行常態工作負載。

$M_2$ — Performance Boost

預先降低供液溫度、提高流量或啟用 thermal storage，為高密度 workload 提供較大 thermal margin。

$M_3$ — Cold Compute

使用專門設計的低溫硬體，在顯著低於一般資料中心環境的溫度工作。

$M_4$ — Cryogenic Compute

只給經低溫設計、驗證的特殊計算或 quantum-classical interface 使用。

$M_F$ — Fault / Safe State

隔離工作負載並讓設備進入可控制的故障安全狀態。

因此 transition：

M_a \rightarrow M_b

本身有成本：

C_{a\rightarrow b} = f( E, \tau, \Delta T, N_{\mathrm{cycle}}, R ).

所以 scheduler 不能只問：

哪台機器最快？

它還需要問：

為了讓這台機器進入適合狀態，需要多少時間、多少冷量、多少能源與多少熱循環成本？

7. 平時不低溫：CDTI 的重要反直覺原則

若某硬體在常態狀態沒有低溫需求，則讓它永久處於極低溫通常不合理。

因此本文提出：

\boxed{ \text{minimum temperature} \neq \text{optimal operating temperature}. }

對很多 AI / HPC workload，更合理的基準可能仍是：

T_{\mathrm{normal}} \approx \text{warm-water / room-temperature-compatible range}.

ASHRAE 的 AI Data Center Energy Performance Framework 指出，高密度 AI / HPC 正大量採用 direct-to-chip liquid cooling，並強調 warm-water cooling、dry cooler 與較高 coolant temperature 所帶來的 chiller reduction 潛力 [1][2]。OCP 亦長期把 liquid cooling、cold plate、CDU、immersion 與 heat reuse 視為高密度計算的重要 cooling technologies [7]。

所以 CDTI 並不以：

T\downarrow

作為唯一目標。

真正目標是：

\boxed{ T^\ast = \operatorname*{argmin}_T J_{\mathrm{system}}. }

而：

T^\ast

會依：

workload；
hardware；
ambient environment；
cooling architecture；
electricity price；
thermal storage；
reliability；
heat reuse；

而變化。

8. 低溫計算必須是 Hardware-Class Aware

如果系統真的包含：

80\ \mathrm{K}, 20\ \mathrm{K}, 4\ \mathrm{K}

甚至更低的 computing zone，不能假設普通室溫 CPU / GPU 可以任意降溫。

低溫電子研究指出，cryogenic CMOS 可能為 quantum control、neuromorphic 與未來高效能計算提供新機會，但低溫條件同時會改變 threshold voltage、carrier transport、noise、reliability 與其他電晶體特性 [8][9]。

所以 CDTI 的 hardware scheduler 必須知道：

H_j = ( T_{\min}, T_{\max}, r_{\max}, N_{\mathrm{cycle,max}}, P(T), R(T) ).

其中：

r_{\max} = \max \left| \frac{dT}{dt} \right|,

P(T) = \text{performance-temperature relation},

R(T) = \text{reliability-temperature relation}.

因此：

\boxed{ \text{thermal state is part of hardware compatibility}. }

而不是單純 environmental parameter。

9. Predictive Preconditioning：任務還沒開始，物理世界先準備

如果大型 AI job 在：

t_0+\Delta t

才開始，thermal plant 不需要等到：

t_0+\Delta t

才反應。

系統可以使用：

\hat{C}(t+\tau)

提前做：

cold-storage preparation；
coolant rerouting；
pump ramp；
valve reconfiguration；
compute-zone pre-cooling；
thermal isolation；
heat-reuse destination preparation；
electrical reserve preparation。

因此：

\boxed{ \text{compute prediction} \rightarrow \text{physical preconditioning}. }

若 thermal state equation 為：

x_{k+1} = f(x_k,u_k,w_k),

其中：

w_k = \text{future workload},

則 MPC 可求：

u^\ast_{k:k+H} = \operatorname*{argmin} \sum_{\tau=k}^{k+H} J(x_\tau,u_\tau,w_\tau).

這比單純 reactive cooling 更能利用熱系統本身的慣性。

10. Thermal Admission Control

一般 cluster admission control 會檢查：

GPU 數量；
memory；
network；
quota；
deadline。

CDTI 還需要：

\boxed{ \text{Thermal Admission Control}. }

一個 job $J$ 可以啟動，只有當：

\mathcal{F}(J,S_t)=1,

其中條件可能包括：

Q_{\mathrm{available}} \ge Q_{\mathrm{required}},

M_{\mathrm{thermal}} \ge M_{\min},

\dot{m}_{\mathrm{available}} \ge \dot{m}_{\mathrm{required}},

P_{\mathrm{facility}} \le P_{\max},

以及：

R_{\mathrm{predicted}} \le R_{\max}.

也就是：

有 GPU 不代表可以立刻跑。

因為這些 GPU 所需的熱力學支撐可能尚未準備完成。

這在超高密度計算中特別重要。

11. Cold Budget：把冷量正式變成可排程資源

如果系統具有 cold thermal storage 或有限 cryogenic refrigeration capacity，則可以像 memory budget 一樣定義：

B_c(t) = \text{available cold budget}.

某工作負載需要：

b_j = \text{expected cold consumption}.

則：

\sum_j b_j \le B_c.

對一般暖水液冷區，這個 budget 可能不是必要抽象。

但在：

cold-storage burst；
sub-ambient cooling；
cryogenic accelerator；
quantum-classical interface；
稀缺低溫冷量；

等情境中，它會非常重要。

因此資源排程可能由：

\{ GPU, RAM, \text{network} \}

擴張為：

\boxed{ \{ GPU, RAM, \text{network}, \text{power}, \text{cold}, \text{thermal margin} \}. }

12. Thermal Storage：解耦計算時間尺度與冷凍時間尺度

計算工作負載可以在秒級或更短時間內劇烈改變。

大型冷凍設備、冷水系統與熱交換網路卻通常具有較慢的機械與熱時間尺度。

因此：

\tau_{\mathrm{compute}} \ll \tau_{\mathrm{plant}}

可能成立。

這時 thermal storage 的重要作用不是提高最低溫度能力，而是：

\boxed{ \text{decouple time scales}. }

定義：

S_c(t)

為冷量儲備。

則：

\frac{dS_c}{dt} = Q_{\mathrm{charge}} - Q_{\mathrm{discharge}} - Q_{\mathrm{loss}}.

當 compute burst 發生：

Q_{\mathrm{discharge}} \uparrow.

當負載下降：

Q_{\mathrm{charge}} \uparrow.

2025 年已有研究直接把 cold storage 與 workload migration 放進資料中心共同控制策略 [5]。NREL 也在研究 Cold Underground Thermal Energy Storage 對資料中心 peak cooling demand 與長期 cooling infrastructure 的潛力 [10]。

因此：

\boxed{ \text{cold storage can act as a thermal buffer between digital demand and physical plant}. }

13. Compute Migration 不只是 IT 技術，而是 Thermal Actuator

如果 workload 可以在不同區域遷移：

W: i \rightarrow j,

則 heat generation 同時被遷移：

Q_i\downarrow, \quad Q_j\uparrow.

因此 workload migration 本身就是一個：

\boxed{ \text{virtual thermal actuator}. }

這是一個非常重要的概念。

傳統 thermal control 透過：

pump；
valve；
fan；
chiller；

移動冷量。

但 compute scheduler 可以直接移動：

\text{heat source}.

於是：

\text{coolant routing}

與：

\text{workload routing}

成為對偶控制手段。

系統可以選擇：

方法 A

把更多冷量送到 workload。

方法 B

把 workload 搬到已經較冷的區域。

方法 C

同時做 A 與 B。

因此：

\boxed{ \text{move heat removal capacity} \quad\leftrightarrow\quad \text{move heat generation}. }

這正是 compute-cooling co-optimization 的核心。

14. 計算排程器必須看見設備的熱歷史

對可動態溫控硬體而言，目前溫度還不夠。

系統還需要 thermal history：

H_i^{T} = \{ T_i(t-\tau:t), N_{\mathrm{cycle}}, r_T, \Delta T_{\mathrm{cum}} \}.

因為：

thermal cycling 可能造成 solder / package fatigue；
快速溫變可能導致 mechanical stress；
condensation risk 取決於過去與當前環境；
cryogenic cycling 可能限制元件壽命；
fluid system 狀態具有滯後。

因此 scheduler 不應只問：

T_i(t)=?

還要問：

\boxed{ \text{這個節點是怎麼來到這個溫度的？} }

這將 thermal management 從 memoryless control 變成 history-aware scheduling。

15. Power、Compute、Cooling 三者應形成共同控制問題

高密度 AI 計算的另一個特徵是：

P_{\mathrm{IT}}

與：

P_{\mathrm{cool}}

同時作用於場區電力系統。

所以：

P_{\mathrm{facility}} = P_{\mathrm{IT}} + P_{\mathrm{cool}} + P_{\mathrm{aux}}.

如果 scheduler 只最佳化 IT performance，可能讓 cooling peak 與 compute peak 完全重合。

反之，如果 thermal storage 可以在高峰釋放：

P_{\mathrm{cool,grid}} \downarrow,

則可以降低：

P_{\mathrm{facility,max}}.

這表示未來 scheduler 最佳化目標可能變成：

\min \left[ E_{\mathrm{IT}} + E_{\mathrm{cool}} + C_{\mathrm{demand}} + C_{\mathrm{transition}} + C_{\mathrm{wear}} \right].

而不是只有：

\min E_{\mathrm{IT}}.

ASHRAE 的最新 AI Data Center Framework 也明確主張 power 與 cooling 應從設計初期就作為統一系統處理 [1]。

16. Heat Reuse 也應由計算排程感知

幾乎所有 processor consumption 最終都會成為熱。OCP Heat Reuse Project 直接指出，處理器使用的能量幾乎全部轉成熱，而適當設計可把冷卻系統從單純成本轉化為 heat-management opportunity [11]。

因此 CDTI 不只可以問：

哪裡最容易散熱？

還可以問：

哪裡產生的熱最容易被利用？

如果兩個計算區：

A,\ B

在算力方面等價，但：

T_{\mathrm{return},A} > T_{\mathrm{return},B},

且 A 的熱可直接送往有效 heat sink / heat reuse load，則某些時段選擇 A 可能具有更高 exergy value。

因此 scheduler objective 可以加入：

-V_{\mathrm{heat}}.

即：

J = C_{\mathrm{energy}} + C_{\mathrm{cooling}} - V_{\mathrm{recovered\ heat}}.

當然：

V_{\mathrm{heat}}

不可能憑空大於輸入能源價值。

其意義只是減少原本要被拋棄的 thermal exergy destruction。

17. 多種計算硬體需要多種 thermal policy

未來大型中心可能同時擁有：

\mathcal{H} = \{ H_{\mathrm{CPU}}, H_{\mathrm{GPU}}, H_{\mathrm{ASIC}}, H_{\mathrm{memory}}, H_{\mathrm{cryo}}, H_{\mathrm{quantum}} \}.

不同 hardware class 對 thermal infrastructure 的要求不同。

因此：

\pi_T = \pi_T(H,W,S).

而不是：

\pi_T = \pi_T(\text{room}).

例如：

CPU / storage tier

可能偏好較高供液溫度與高 heat-reuse potential。

GPU / AI accelerator tier

需要高流量 direct-to-chip cooling 與較大的 transient thermal headroom。

Cryogenic classical tier

需要經驗證的低溫 CMOS / interconnect / memory design。

Quantum tier

可能有完全不同的 millikelvin thermal budget。

因此未來「同一棟機房一個供水溫度」未必是最佳抽象。

18. Cryogenic Burst Compute

本文提出一個需要後續實驗驗證的特殊模式：

\boxed{ \text{Cryogenic Burst Compute}. }

其基本概念不是：

永久把所有計算機放在極低溫。

而是：

專用硬體平時維持較高 standby temperature；
cold reserve 慢速累積；
特定高價值 workload 到達；
局部 compute island 進入 cold / cryogenic state；
在限定時間執行；
之後依熱力學與硬體壽命需求回到較高溫狀態。

其必要條件是：

\Delta V_{\mathrm{compute}} > C_{\mathrm{cooling}} + C_{\mathrm{transition}} + C_{\mathrm{wear}}.

其中：

\Delta V_{\mathrm{compute}}

代表低溫狀態帶來的總性能／科研價值提升。

如果不滿足，則不應啟動。

因此 Cryogenic Burst Compute 是經濟與工程狀態，不是低溫崇拜。

19. 量子—傳統混合計算會讓問題更加明顯

量子計算本身已經自然存在多溫級。

典型 dilution refrigerator 具有多個 thermal stages，而 control electronics、readout、classical preprocessing 與 quantum device 未必工作在同一溫度。

隨著 cryogenic control electronics 發展，部分 classical processing 可能被移往較低溫級，以降低 wiring complexity、latency 或其他系統成本 [8][9]。

因此 hybrid system 的最佳化問題天然接近：

\boxed{ \text{compute placement} + \text{thermal placement}. }

工作不能只問：

在 CPU 還是 QPU 執行？

還可能需要問：

哪一部分 classical computation 應留在 $300\ \mathrm{K}$ 、哪一部分移至較低 thermal stage，才能降低整體系統成本？

這使 CDTI 對量子—傳統混合架構尤其具有研究價值。

20. Thermal SLA

若 thermal state 成為算力資源，就可以建立：

\boxed{ \text{Thermal Service Level Agreement}. }

例如某 workload 可以宣告：

\mathrm{SLA}_{T} = \left[ T_{\max}, T_{\mathrm{preferred}}, r_T, Q_{\mathrm{reserve}}, \tau_{\mathrm{recovery}} \right].

其中：

T_{\max} = \text{maximum tolerated device temperature},

T_{\mathrm{preferred}} = \text{preferred operating range},

r_T = \text{maximum temperature slew rate},

Q_{\mathrm{reserve}} = \text{required thermal reserve},

\tau_{\mathrm{recovery}} = \text{allowed thermal recovery time}.

scheduler 就可以把：

\mathrm{SLA}_{T}

和 GPU、RAM、network requirements 一起處理。

21. Thermal Margin 應像 Memory Headroom 一樣可觀測

定義：

M_T = Q_{\max,\mathrm{safe}} - Q_{\mathrm{current}}.

或更一般地：

M_T = f( T, \dot{m}, P, S_c, R ).

則：

M_T

可被視為：

\boxed{ \text{thermal headroom}. }

如果：

M_T\rightarrow0,

系統應：

拒絕新 workload；
降低 clock；
遷移 job；
釋放 cold storage；
啟用額外冷卻；
進入 degraded compute mode。

所以 future scheduler 不只顯示：

GPU utilization: 92%
Memory utilization: 81%

還應該顯示：

Thermal headroom: 24%
Cold reserve: 61%
Heat rejection margin: 37%

這才是完整 cyber-physical compute resource view。

22. Degraded Compute Mode

傳統冷卻故障往往被視為：

\text{cooling failure} \rightarrow \text{shutdown}.

CDTI 可以有更細緻的降級：

M_{\mathrm{normal}} \rightarrow M_{\mathrm{degraded}}.

例如：

降低 power cap；
降低 frequency；
停止非關鍵 training；
保留控制與 checkpoint；
遷移 latency-sensitive service；
關閉 cryogenic boost；
重新分配 coolant；
將機器人與科研負載暫停。

因此：

\boxed{ \text{compute can participate in physical fault recovery}. }

這是 computation 與 infrastructure coupling 的另一面。

23. Local AI 必須擁有部分自主權

如果：

\tau_{\mathrm{fault}} < \tau_{\mathrm{cloud}},

那麼遠端批准不可能處理所有 physical event。

因此現場 AI 應在預先定義的：

\mathcal{A}_{\mathrm{local}}

中自主執行：

workload shedding；
thermal rerouting；
safe-mode transition；
cold-storage dispatch；
compute throttling；
local isolation。

但所有動作仍需滿足：

u_{\mathrm{AI}} \in \mathcal{U}_{\mathrm{safe}}(x).

因此：

\boxed{ \text{Local AI authority} \neq \text{unbounded authority}. }

而是：

\boxed{ \text{fast autonomy inside a deterministic safety envelope}. }

24. AI 不應直接控制每一顆閥

CDTI 中一個極重要的工程原則是分離：

\text{reasoning}

與：

\text{actuation}.

高階 AI 可以決定：

180 秒後 Cluster B 需要額外 $12\ \mathrm{MW}$ thermal headroom。

但不應直接產生：

Valve 18 開 $63.147\%$ 。

更合理的是：

\text{AI intent} \rightarrow \text{optimizer} \rightarrow \text{validated setpoints} \rightarrow \text{PLC / deterministic controller}.

這樣即使 AI：

hallucinate；
失去 context；
model drift；
network partition；

底層仍維持可證明的 physical constraint。

25. Digital Twin 與 Shadow Scheduling

在 CDTI 實際控制物理設施之前，可以先運行：

\boxed{ \text{shadow scheduler}. }

即：

真實系統仍使用既有控制；
CDTI scheduler 讀取相同 telemetry；
產生假想 compute + thermal decisions；
digital twin 模擬結果；
與真實系統比較。

因此可以得到：

\Delta J = J_{\mathrm{baseline}} - J_{\mathrm{CDTI}}.

而不需要一開始就讓新系統控制昂貴設備。

當 shadow mode 累積足夠證據後，再進入：

\text{advisory mode}

然後：

\text{bounded autonomous mode}.

這是大型 critical facility 較合理的驗證路徑。

26. 計算驅動的熱力學狀態轉換需要時間預算

對任何 transition：

M_i \rightarrow M_j,

都應計算：

\tau_{i\rightarrow j}.

如果 workload deadline：

D_{\mathrm{job}} < \tau_{i\rightarrow j},

則該 transition 沒有意義。

因此 scheduler 可以定義：

\text{thermal readiness time}.

一個 zone 的 readiness：

R_i^{T} = t_{\mathrm{ready},i} - t_{\mathrm{now}}.

並像 queue latency 一樣參與排程。

這將產生新的 cluster state：

\{ \text{ready-now}, \text{preconditioning}, \text{cold-ready}, \text{recovering}, \text{maintenance} \}.

27. 多時間尺度控制

CDTI 涉及至少五個時間尺度：

$T_0$ — 微秒至毫秒

晶片 DVFS、hardware protection、power electronics。

$T_1$ — 毫秒至秒

local liquid control、valves、pump response、local workload throttling。

$T_2$ — 秒至分鐘

workload migration、thermal storage discharge、zone preconditioning。

$T_3$ — 分鐘至小時

large-job scheduling、chiller / refrigerator optimization、heat reuse。

$T_4$ — 小時至月份

maintenance、thermal-cycle management、capacity planning、energy market coupling。

因此：

\boxed{ \pi = \{ \pi_0, \pi_1, \pi_2, \pi_3, \pi_4 \}. }

不應由單一 controller 處理全部尺度。

28. Objective Function 不應只看 PUE

PUE 仍然有用：

PUE = \frac{P_{\mathrm{facility}}} {P_{\mathrm{IT}}}.

但在 CDTI 中可能不足。

假設方案 A：

PUE 較低；
compute job 完成較慢。

方案 B：

PUE 稍高；
相同科研計算提前完成一倍。

單看 PUE 可能選錯。

因此可以提出：

\eta_{\mathrm{useful}} = \frac{\text{useful completed computation}} {\text{total facility energy}}.

進一步加入：

J = w_1E + w_2T_{\mathrm{job}} + w_3C_{\mathrm{peak}} + w_4R + w_5C_{\mathrm{wear}} - w_6V_{\mathrm{heat}}.

這樣評價的是：

\boxed{ \text{facility-level useful computation efficiency}. }

ASHRAE 最新 AI data-center framework 本身也已鼓勵在 PUE 之外，同時追蹤 water、carbon 與 IT work capacity 等更完整指標 [2]。

29. CDTI 的最小原型

第一代實驗完全不需要 cryogenic facility。

可以建：

Hardware

$8$ 至 $32$ 個可獨立排程 compute nodes；
direct-to-chip cold plates；
$2$ 至 $4$ 個 thermal zones；
variable-speed pumps；
electronically controlled valves；
small thermal storage；
power meters；
inlet / outlet temperature sensors；
flow / pressure sensors。

Software

workload scheduler；
thermal digital twin；
MPC / optimization controller；
local deterministic safety；
telemetry store；
provenance log。

Baseline

\pi_{\mathrm{baseline}} = \text{compute-first + reactive cooling}.

Experimental policy

\pi_{\mathrm{CDTI}} = \text{joint predictive scheduling}.

然後比較：

\{ E, P_{\max}, T_{\max}, T_{\mathrm{job}}, N_{\mathrm{violation}}, C_{\mathrm{transition}} \}.

若連這個尺度都沒有收益，就沒有理由直接蓋大型 CDTI。

30. 第二階段原型：加入 Cold Storage

下一步加入：

S_c(t).

測試：

Experiment A

固定 workload，不使用 storage。

Experiment B

固定 workload，使用 storage。

Experiment C

workload migration + storage。

若：

J_C<J_B<J_A,

則支持 compute + thermal storage co-scheduling。

2025 年相關研究已提供早期證據，顯示這類聯合控制值得進一步實驗 [5]。

31. 第三階段原型：加入不同 Thermal Classes

再建立：

\mathcal{T} = \{ T_A,T_B,T_C \}.

其中例如：

$T_A$ ：warm-water；
$T_B$ ：sub-ambient；
$T_C$ ：特殊 cold compute。

每個 workload 有：

P_j(T),

E_j(T),

R_j(T).

讓 scheduler 自己選：

T_j^\ast.

這才真正開始驗證：

\boxed{ \text{thermal state as compute resource}. }

32. 可證偽命題

H1 — Compute-Driven Control Hypothesis

對具有顯著時變 workload 的高密度計算設施：

J_{\mathrm{joint}} < J_{\mathrm{reactive}}

可在相同 reliability / QoS constraint 下成立。

若長期實驗顯示 joint control 沒有改善，則 CDTI 的核心命題被削弱。

H2 — Predictive Preconditioning Hypothesis

當：

\tau_{\mathrm{forecast}} \gtrsim \tau_{\mathrm{thermal}},

預測式 thermal preconditioning 可降低：

T_{\max}, \quad P_{\max}, \quad E_{\mathrm{cool}}

至少其中一項。

H3 — Workload-as-Thermal-Actuator Hypothesis

在多區域 compute cluster 中，workload migration 可以作為有效 thermal actuator，並與 coolant routing 形成互補控制。

H4 — Cold-Budget Scheduling Hypothesis

在具有有限 cold reserve 的系統中，顯式將：

B_c

加入 scheduler，比不感知 cold budget 的策略具有更低的 thermal violation 或 peak cooling demand。

H5 — Thermal Admission Control Hypothesis

對接近 thermal capacity limit 的高密度 cluster，thermal admission control 可以降低：

P( T>T_{\max} )

而不造成不可接受的 throughput loss。

H6 — Thermal-State Heterogeneity Hypothesis

對異質 hardware：

\text{one thermal policy for all}

並非最優。

存在：

\pi_i^T

使不同 compute class 採用不同 thermal state，可改善 total system objective。

H7 — Cryogenic Burst Hypothesis

對至少某類經低溫設計的計算硬體，短時間 cold / cryogenic operation 的總效益：

\Delta V_{\mathrm{compute}}

可能大於：

C_{\mathrm{cool}} + C_{\mathrm{transition}} + C_{\mathrm{wear}}.

若長期不存在此硬體類型，則該命題被否定，而不影響 CDTI 在常溫與暖水液冷範圍的成立。

33. 反例與失敗條件

CDTI 並不適用於所有系統。

33.1 Workload 不可預測且不可遷移

如果：

\hat{W}

沒有預測價值，且 workload 無法轉移，predictive coupling 收益降低。

33.2 Thermal plant 足夠大且效率近似固定

若冷卻系統在所有 workload 下皆有大量 margin，聯合最佳化可能不值得複雜度。

33.3 Compute / thermal coupling 過弱

若 workload placement 幾乎不影響 thermal distribution，則 workload-as-thermal-actuator 沒有價值。

33.4 Transition cost 太高

若：

C_{\mathrm{transition}} \gg \Delta V,

動態 thermal-state switching 不值得。

33.5 Hardware 對溫度不敏感

若：

\frac{\partial P_{\mathrm{compute}}}{\partial T} \approx0

且 reliability 也無顯著改善，則不需要低溫 compute state。

33.6 控制與安全成本過高

更多 sensors、valves、AI、digital twin 與 control software 都有成本。

CDTI 必須證明：

C_{\mathrm{lifecycle,CDTI}} < V_{\mathrm{benefit}}

而不是只展示技術可行性。

34. 安全原則

34.1 Compute 不得突破物理安全 envelope

即使 workload 極度重要：

u_{\mathrm{compute}} \notin \mathcal{U}_{\mathrm{safe}}

則拒絕執行。

34.2 Thermal system 不可依賴單一 AI

local deterministic control 必須在：

\text{AI unavailable}

時仍能保持：

x(t)\in\mathcal{X}_{\mathrm{safe}}.

34.3 Job priority 不等於 physical priority

高優先任務也不能覆寫 pressure、flow、material、fire 或 cryogenic safety constraints。

34.4 所有跨狀態轉換應有 provenance

記錄：

E_t = ( C_t, \Theta_t, I_t, A_t, M_t, P_t, V_t ).

其中：

$C_t$ ：compute state；
$\Theta_t$ ：thermal state；
$I_t$ ：intent；
$A_t$ ：action；
$M_t$ ：decision model；
$P_t$ ：policy；
$V_t$ ：verification。

如此才可在事後重建：

為什麼這個 cluster 在這個時間被預冷？

35. 與 ANCSI-02 的差異

ANCSI-02 問的是：

\boxed{ \text{熱場能不能被程式化？} }

ANCSI-03 問的是：

\boxed{ \text{如果可以，誰來驅動它？} }

本文提出：

\boxed{ \text{compute state} \rightarrow \text{thermal state}. }

但這個箭頭不是單向獨裁。

因為 thermal state 又會反過來限制 compute：

\Theta(t) \rightarrow \mathcal{C}_{\mathrm{available}}(t).

因此完整閉環是：

\boxed{ C(t) \leftrightarrow \Theta(t). }

這就是 Compute-Thermal Coupling。

36. 與 ANCSI-04 的銜接

當 compute system 開始要求：

將更多冷量送到 Zone C。

真正的下一個問題就是：

冷量如何被輸送？

這需要：

管路；
真空隔熱；
流體；
壓力；
泵浦；
閥門；
多介質網路；
bypass；
return path；
logistics conduit。

因此下一篇 ANCSI-04 將研究：

\boxed{ \text{Vacuum-Jacketed Multi-Medium Pipe Field} }

把 thermal transport 從設備層提升成可重構的基礎設施網路。

37. 結論

本文提出計算驅動熱力學基礎設施作為 ANCSI 的第三個核心命題。

其最簡單形式是：

\boxed{ \text{Compute is not merely cooled; compute participates in controlling the cooling world.} }

在這個架構下：

workload 是熱源，也是可移動 thermal actuator；
thermal state 是環境，也是 compute resource；
cold storage 是冷卻設備，也是時間緩衝資源；
coolant routing 是熱管理，也是 compute scheduling 的一部分；
compute migration 是 IT 行為，也是物理熱流控制手段；
local AI 是 scheduler，也是 cyber-physical orchestrator；
deterministic controller 不是被 AI 取代，而是成為 AI 自治的物理安全底層。

因此未來大型計算中心的 scheduler 可能不再只回答：

哪裡還有 GPU？

而是回答：

哪一個物理區域目前具有足夠的電力、熱餘量、冷量、流體容量與硬體狀態，可以在最低總成本與可接受風險下完成這項計算？

可以將這個問題形式化為：

\boxed{ i^\ast = \operatorname*{argmin}_i J( C_i, \Theta_i, E_i, R_i, t ). }

這代表計算排程開始跨越數位世界的邊界。

它不再只分配 processor time。

它開始分配：

\boxed{ \text{physical state}. }

如果這個命題在實驗中成立，那麼未來 AI 原生計算中心的真正作業系統，可能不只管理 CPU、GPU、memory 與 network。

它還會管理：

\boxed{ \text{temperature}, \text{flow}, \text{pressure}, \text{cold reserve}, \text{energy}, \text{thermal topology}. }

也就是：

\boxed{ \text{the physical world required by computation itself}. }

參考文獻

[1] ASHRAE / PNNL / NEMA. Integrated Design Principles — AI Data Center Energy Performance Framework.
https://www.ashrae.org/technical-resources/ai-data-center-framework/integrated-design-principles

[2] ASHRAE / PNNL / NEMA. Energy and Thermal Efficiency — AI Data Center Energy Performance Framework.
https://www.ashrae.org/technical-resources/ai-data-center-framework/energy-and-thermal-efficiency

[3] U.S. Department of Energy. (2026). COOLERCHIPS 1.5 — Cooling Operations Optimized for Leaps in Energy, Reliability, and Carbon Hyperefficiency for Information Processing Systems.
https://www.energy.gov/nepa/articles/cx-271071-cooling-operations-optimized-leaps-energy-reliability-and-carbon

[4] Fang, Q., Gong, Q., Wang, J., & Wang, Y. (2019). Optimization based resource and cooling management for a high performance computing data center. ISA Transactions, 90, 202–212.
https://doi.org/10.1016/j.isatra.2018.12.038

[5] Research on collaborative control strategy of cold storage and IT workload migration in data center. Energy, 323, 135802 (2025).
https://doi.org/10.1016/j.energy.2025.135802

[6] Ran, J., Zhang, Q., Zhu, Y., Zhai, J., Li, J., Guo, Z., & Wang, T. (2026). Co-optimization of thermal-aware workload scheduling with deep reinforcement learning-based cooling control in data centers. Energy, 344, 139965.
https://doi.org/10.1016/j.energy.2026.139965

[7] Open Compute Project. Cooling Environments.
https://www.opencompute.org/community/cooling-environments

[8] Zhao, Q.-T., Han, Y., Han, H.-C., et al. (2025). Ultra-low-power cryogenic complementary metal oxide semiconductor technology. Nature Reviews Electrical Engineering, 2, 277–290.
https://doi.org/10.1038/s44287-025-00157-7

[9] Bashir, F., Abbas, H., Nisar, A., et al. (2025). Cryogenic electronics for high performance computing applications: A comprehensive review. Materials Today Physics, 59, 101960.
https://doi.org/10.1016/j.mtphys.2025.101960

[10] National Renewable Energy Laboratory. (2025). Reducing Data Center Peak Cooling Demand and Energy Costs With Underground Thermal Energy Storage.
https://www.nrel.gov/news/program/2025/reducing-data-center-peak-cooling-demand-and-energy-costs-with-underground-thermal-energy-storage.html

[11] Open Compute Project. Heat Reuse.
https://www.opencompute.org/community/heat-reuse

文件狀態

本文為 ANCSI 系列第三篇公開命題稿 v0.1。

本文所有數學原始碼僅使用 $...$ 與 $$...$$ 作為 canonical delimiter。本文不依賴作者其他私人理論；所提出之 Compute-Driven Thermodynamic Infrastructure、Compute-to-Thermal Compiler、Thermal Admission Control、Cold Budget 與 Cryogenic Burst Compute 均屬待驗證的工程架構／研究命題，不宣稱目前已完成完整大型實體部署。

計算驅動熱力學基礎設施

計算驅動熱力學基礎設施

從被動散熱到由工作負載、算力狀態與任務預測直接驅動的物理設施控制

摘要

1. 問題：為什麼「先算、再散熱」可能不再足夠

2. 核心命題：計算狀態不是只有熱源，而是基礎設施控制訊號

3. 現有工程已經開始走向 Compute-Cooling Co-Optimization

4. 從 Compute Load 到 Compute State

5. Compute-to-Thermal Compiler

6. Compute-Thermal State Machine

M0M_0M0​ — Idle / Warm

M1M_1M1​ — Normal Compute

M2M_2M2​ — Performance Boost

M3M_3M3​ — Cold Compute

M4M_4M4​ — Cryogenic Compute

MFM_FMF​ — Fault / Safe State

7. 平時不低溫：CDTI 的重要反直覺原則

8. 低溫計算必須是 Hardware-Class Aware

9. Predictive Preconditioning：任務還沒開始，物理世界先準備

10. Thermal Admission Control

11. Cold Budget：把冷量正式變成可排程資源

12. Thermal Storage：解耦計算時間尺度與冷凍時間尺度

13. Compute Migration 不只是 IT 技術，而是 Thermal Actuator

方法 A

方法 B

方法 C

14. 計算排程器必須看見設備的熱歷史

15. Power、Compute、Cooling 三者應形成共同控制問題

16. Heat Reuse 也應由計算排程感知

17. 多種計算硬體需要多種 thermal policy

CPU / storage tier

GPU / AI accelerator tier

Cryogenic classical tier

Quantum tier

18. Cryogenic Burst Compute

19. 量子—傳統混合計算會讓問題更加明顯

20. Thermal SLA

21. Thermal Margin 應像 Memory Headroom 一樣可觀測

22. Degraded Compute Mode

23. Local AI 必須擁有部分自主權

24. AI 不應直接控制每一顆閥

25. Digital Twin 與 Shadow Scheduling

26. 計算驅動的熱力學狀態轉換需要時間預算

27. 多時間尺度控制

T0T_0T0​ — 微秒至毫秒

T1T_1T1​ — 毫秒至秒

T2T_2T2​ — 秒至分鐘

T3T_3T3​ — 分鐘至小時

T4T_4T4​ — 小時至月份

28. Objective Function 不應只看 PUE

29. CDTI 的最小原型

Hardware

Software

Baseline

Experimental policy

30. 第二階段原型：加入 Cold Storage

Experiment A

Experiment B

Experiment C

31. 第三階段原型：加入不同 Thermal Classes

32. 可證偽命題

H1 — Compute-Driven Control Hypothesis

H2 — Predictive Preconditioning Hypothesis

H3 — Workload-as-Thermal-Actuator Hypothesis

H4 — Cold-Budget Scheduling Hypothesis

H5 — Thermal Admission Control Hypothesis

H6 — Thermal-State Heterogeneity Hypothesis

H7 — Cryogenic Burst Hypothesis

33. 反例與失敗條件

33.1 Workload 不可預測且不可遷移

33.2 Thermal plant 足夠大且效率近似固定

33.3 Compute / thermal coupling 過弱

33.4 Transition cost 太高

33.5 Hardware 對溫度不敏感

33.6 控制與安全成本過高

34. 安全原則

34.1 Compute 不得突破物理安全 envelope

34.2 Thermal system 不可依賴單一 AI

34.3 Job priority 不等於 physical priority

34.4 所有跨狀態轉換應有 provenance

$M_0$ — Idle / Warm

$M_1$ — Normal Compute

$M_2$ — Performance Boost

$M_3$ — Cold Compute

$M_4$ — Cryogenic Compute

$M_F$ — Fault / Safe State

$T_0$ — 微秒至毫秒

$T_1$ — 毫秒至秒

$T_2$ — 秒至分鐘

$T_3$ — 分鐘至小時

$T_4$ — 小時至月份