第179章 給熱量記帳
第十二次廢土之行，第二十四年七月三日。
前哨站二號工作間。
四台伺服器沿牆排開，二十七張170HX分布在四組節點裡，風扇壓著最低轉速，發出很有耐心的嗡鳴。
它們已經學會了騙人。
不拆開看，誰也想不到這批本該老老實實待在礦場裡計算哈希值的板卡，已經被江臨從固件、驅動和運行時一路撬開，湊出接近一TiB的穩定可計算HBM。
礦場給它們安排的工作很單純，日復一日搬同一種磚。
到江臨手裡，矩陣分塊、模型推理、代碼索引和證明依賴圖都能往裡塞。
可一批板卡能計算，與一座計算集群能長期工作，中間還隔著一道很熱的門檻。
江臨把四天前新建的文件調到主屏。
【MPS-ThermalFabric_v0.1】
TM-7交出的本地服務包已經轉入只讀封存。
未來設備編號、介質參數和原始服務協議都被隔離在實驗鏈之外，控制系統只能讀取江臨重新定義過的接口。
維護港原來的熱管理表很簡單。
每條支路後面跟著一個數字，以兆焦為單位，代表還能吞下多少熱量。
這套寫法適合相變緩衝單元。
那東西像一隻預先騰空的水庫，剩下多少庫容，能接多大的洪峰，一眼就能看清。
眼前這套用水和乙二醇拼出來的液冷迴路麻煩得多，它一邊吃熱，一邊又把熱量送去末端換熱器。
只記剩餘容量，就像只盯著倉庫里還有多少空地，卻把每天進出多少貨忘了個乾淨。
於是江臨給每條支路開了兩本帳。
【持續排熱能力：kW】
【響應窗口內瞬態熱預算：MJ】
第一本帳管長久。
一條支路每秒能送走多少熱量，決定任務能跑一個小時，還是能跑一年。
第二本帳管眼前。
泵組提速要時間，閥門轉動要時間，冷卻液從干管走到冷板同樣要時間。
在這幾十秒里，晶片已經產生的熱峰由誰接住，決定板卡是繼續計算，還是先把自己燙到降頻。
算力有隊列，顯存有窗口，故障有帳本。
現在，熱量也得入帳。
江臨切斷本地服務包與實驗控制網的最後一條連接，開始改造四台伺服器。
原有風道保留下來，繼續照顧主板、供電、存儲和其他沒壓冷板的器件。
二十七張170HX的GPU與HBM區域分別覆蓋銅冷板，四組節點對應四條並聯液冷支路。
三隻循環泵負責公共供回水，每條主路旁邊再加一段常閉冗餘旁路。
正常時，旁路閉著。
主路斷流以後，它才有資格開口。
支路末端是一組翅片式液—氣換熱器，十二台工業風機負責把熱空氣送出工作間。
入口溫度、出口溫度、流量和供回水壓力都有獨立測點。GPU核心、HBM區域和板上供電區域的測溫結果取最高值，統一記作板卡熱點溫度。
兩隻廢棄壓力容器完成清洗和初次探傷後，被拖進工作間。
江臨在內部焊入金屬翅片，完成封裝，再重新進行焊縫探傷、水壓與氣密性測試，最後灌入水—乙二醇混合液，改作顯熱緩衝罐。
這兩隻罐子顯然談不上先進。
它們又大又重，單位體積吸熱能力也很普通，和TM-7的相變緩衝單元擺在一起，大致相當於鐵皮水桶參加未來工業品評獎。
可鐵皮水桶有鐵皮水桶的好處。
材料能買到，焊縫能檢查，壞了能拆，拆完還能照著再做一隻。
現實世界接得住這樣的東西。
管路完工以後，江臨仍然沒讓熱織網接管控制權。
他先把二十七張卡留在待機狀態，在四組冷板迴路上接入可調電阻加熱塊，一檔一檔地往冷卻液里灌熱。
六千瓦。
八千瓦。
十千瓦。
十一千瓦。
十一點八千瓦。
到最後一檔，末端換熱器的出液溫度緩慢上移。兩小時後，曲線停住，沒再往上爬。
江臨在測試頁上記下結果。
【末端持續排熱能力：11.8kW（當前進風溫度、額定風量下）】
這不是一條脫離環境成立的常數。
進風溫度、風機轉速和液側流量一併寫入標定記錄。
【四節點集群預計滿載IT功率：9.6kW至10.1kW】
換熱器夠用，泵組的總流量也夠用。
這是一條好消息，甚至好得有些可疑。
硬體明明能端走整套集群的熱量，四台伺服器此前卻始終無法同時跑滿。
熱去了哪裡？
第二十四年七月十七日，固定閥位基準測試開始。
四條支路按額定熱負荷完成靜態水力平衡。
閥門開度寫入記錄，測試期間全部鎖死。
二十七張170HX建立影子窗口，統一任務隊列依次進入四組節點。
前二十分鐘，曲線很漂亮。
第三十一分鐘，NODE-D的板卡熱點溫度首先越過七十五攝氏度。
這組節點承擔的檢查點壓縮和顯存搬運更多，GPU核心尚有餘地，HBM與板上供電區域已經開始積熱。
第四支路的回水溫度向上抬，第二、第三支路卻仍然涼快，NODE-B甚至空著接近一半的冷卻餘量。
十一點八千瓦的末端能力還在。
只是它平均分在四條管子裡，誰也沒問今天究竟是哪一組節點發熱更多。
第四十六分鐘，NODE-D最高板卡熱點溫度達到七十九點八攝氏度，第一張卡觸發降頻。
江臨繼續等待。
單獨壓低NODE-D沒有用。
這批矩陣分塊存在同步屏障，它慢下來，另外三組節點就得在檢查點前陪它站著。
此時遷走活動顯存窗口，還要重新建立映射。
MPS-Scheduler最終只能把整批任務的並發度一檔一檔往下砍。
百分之九十。
百分之八十。
百分之七十。
總負載降至百分之六十四，NODE-D的溫度曲線終於壓平。
其餘三條支路仍有餘量。
固定閥位模式繼續運行六小時，設備完整，過溫保護一次也沒觸發。
代價同樣很清楚：按九點八千瓦的滿載IT功率歸一化，固定閥位下，四節點只能釋放百分之六十四的安全持續計算負載。
【固定閥位基準】
【測試硬體：27張170HX】
【末端排熱能力：11.8kW（同標定工況）】
【四節點集群滿載IT功率基準：9.8kW】
【安全持續負載上限：64%】
【限制來源：局部支路熱量堆積】
【閒置冷卻能力：存在】
四條支路加起來明明夠用，最熱的那一條仍然吃不到別處剩下的冷量。
一座倉庫里糧食充足，餓著的人卻站在另一扇鎖死的門後。
繼續往倉庫里堆糧毫無意義，得先把門打開。
江臨在基準報告首頁寫下問題定義。
【冷卻系統總能力充足，局部冷卻能力無法隨計算任務轉移。】
最省事的補救有兩種。
重新調一次靜態水力平衡，或者按最熱節點的需求提高總流量和風機轉速。
前一種方案只認一種穩定負載，任務一換，平衡就得跟著重做。
後一種方案更直截了當，只要肯長期支付電耗、泵組餘量和換熱冗餘，總能把最壞工況壓住。
工程上經常這麼幹，可靠，省腦子，主要缺點是費錢。
成熟算力中心早已配備變頻泵、溫控閥和熱感知調度。
江臨此刻推進的也並非給水泵加一隻自動開關。
他要把任務即將產生的熱峰、管路尚未送到的在途熱量、支路恢復時間和檢查點遷移資格，全都壓進同一套可驗證的運行狀態。
任務計劃、在途熱量、閥門響應和檢查點遷移，必須進入同一張狀態表。
冷卻能力要像計算任務一樣可測量、可預留、可遷移，也要知道什麼時候該拒絕。
第二十四年八月十二日，MPS熱織網第一次接管四條支路。
NODE-A與NODE-B進入計算狀態，另外兩組待機。
這一輪只驗證穩定工況下的聯合調流：兩組節點進入穩定負載後，板卡熱點溫度必須維持在七十五攝氏度以下。
任務啟動四分二十秒，NODE-A溫升斜率超出預測。
第一支路閥門開大。
流量增加，支路壓力上升，公共干管壓差隨之變化，NODE-B獲得的流量開始下降。
四十秒後，NODE-B溫度抬頭。
系統轉而打開第二支路閥門。
NODE-B得救，NODE-A又開始升溫。
兩條支路圍著同一組泵打起了拉鋸。
電磁閥在百分之三十四與百分之七十一開度之間往返，壓力曲線先動，流量曲線隨後，溫度曲線拖在最後，等溫度終於把消息送到控制器，上一輪命令早已把局面改得面目全非。
第十一分鐘，NODE-B第一張170HX降頻。
第十三分鐘，第二張卡逼近保護邊界。
江臨按下終止鍵。
風扇還在轉，閥門也還在忙。
它們嚴格執行了每一道命令，問題恰恰出在命令太勤快。
【第一次聯合調流測試】
【結果：失敗】
【故障類型：支路耦合振盪】
【設備損失：0】
TM-7原有邏輯面對的是高速閥組、精密壓差控制和相變緩衝。
那裡的支路剛收到指令，新的冷卻能力已經在路上。
現實電磁閥更講規矩。
它從接到命令到穩定流量需要數秒，循環泵改變轉速以後，整條迴路還得重新找一次平衡。
把未來系統的控制節奏原樣塞給它，好比拿戰鬥機的動作口令去催一輛滿載叉車。
叉車已經很努力了，貨還是會翻。
江臨給控制器加上三條約束。
【任何流量調整，必須等待當前支路完成響應。】
【禁止依據單一溫度值連續反向修正。】
【壓力變化優先於溫度變化進入預測模型。】
第二十四年十二月，第二輪控制邏輯上線。
四條支路各自有了動態帳本。
持續排熱能力、響應窗口熱預算、冷卻液質量、出入口溫度、流量、冷板熱滯後和緩衝罐狀態，一項項寫進去。
第二次測試的前四十分鐘順利得多。
NODE-A和NODE-B保持穩定。NODE-C啟動後，第三支路帳面仍有百分之三十八餘量。
系統據此批准下一組矩陣任務進入。
七分鐘後，NODE-C連續三張卡越過警戒溫度。
出口溫度正常。
流量正常。
帳上的餘量也還在。
江臨盯著曲線看了幾秒，關閉任務。
那百分之三十八的餘量從頭到尾都沒存在過。
晶片剛產生的熱量先進入導熱層，再進入銅冷板、軟管和冷卻液，最後才會抵達支路出口。
傳感器看到的溫度屬於一百多秒以前，帳本拿著舊消息批准了新任務。
簡單地說，熱已經出發，報表卻還當它沒上路。
【第二次聯合調度測試】
【結果：失敗】
【故障類型：在途熱量未計入】
【觸發降頻：3張】
【設備損失：0】
江臨拆下NODE-C的冷板，把測點沿著整條導熱路徑一路鋪開。
晶片附近。
冷板入口。
冷板出口。
支路回水。
緩衝罐入口。
末端換熱器。
同一份熱量在六個位置留下了六個時間戳。
從晶片溫升出現，到回水溫度足以穩定反映負載，中間相差一百一十七秒。
一百一十七秒，足夠交換機搬完許多批數據，也足夠三張170HX把自己逼進降頻區。
對於水而言，這只是一段管路的正常路程。
響應窗口熱預算隨之改寫。
【響應窗口熱預算＝分配給本支路的可用顯熱容量＋窗口內預計排熱量－在途熱量－安全餘量】
兩隻緩衝罐由四條支路共享，同一份容量不能同時記進四本帳。系統必須先為各條支路預留容量，再根據罐內溫度、流量和恢復狀態更新可用部分。
分配容量和窗口內預計排熱量，可以通過標定與傳感器估算；安全餘量預先設定。
最難的是在途熱量。
它藏在導熱層、冷板、軟管和流動的液體裡，既無法靠一個測點直接讀出，也不會因為報表暫時看不見就自行消失。
江臨把每張170HX的功耗曲線、窗口映射規模、內核類型和預計持續時間送進MPS-Scheduler。
矩陣計算有矩陣計算的熱峰。
模型推理有模型推理的熱峰。
日誌索引和檢查點寫入的平均功耗相近，短時脈衝卻完全不同。
從這一輪疊代開始，算力調度器會提前提交任務計劃。
任務尚未進入GPU，它將在未來幾分鐘產生的熱量已經先記到支路帳上。
第二十五年四月，第三輪控制邏輯進入測試。
NODE-A的矩陣任務啟動前三十秒，第一支路開始增流。
任務真正進入計算時，冷卻液已經抵達冷板。
第二組任務原本準備送往NODE-C。
NODE-C此刻的表面溫度更低，帳本卻顯示它的緩衝恢復速度慢於NODE-B。
系統放棄這塊看上去更涼的節點，把任務送進溫度略高、熱預算更充足的NODE-B。
二十分鐘後，兩條支路都沒越線。
第一階段通過。
江臨隨即關閉NODE-B主回水閥的百分之七十，模擬主回水通路故障。
流量計首先報錯。
熱織網凍結NODE-B的新任務，正在運行的分塊開始寫檢查點，NODE-A與NODE-C收到遷移計劃。
順序正確。
十七秒後，NODE-A第一張卡還是降頻了。
任務跨過交換機只用了不到一秒。
NODE-A原有分塊尚未結束，新的影子窗口已經建立，算力負載瞬間抬升。
對應支路從收到計劃到建立有效流量，需要二十六秒。
第九秒，溫升斜率越線。
第十七秒，降頻觸發。
江臨終止遷移。
【第三次故障遷移測試】
【結果：失敗】
【故障類型：算力遷移快於冷卻響應】
【丟失檢查點：0】
【觸發降頻：1張】
數據可以抄近路，水還得老老實實走管子。
冷卻能力抵達以前，空閒算力只是帳面資產。
誰先把任務塞進去，誰就會收到一張過溫帳單。
江臨在任務遷移狀態機前加了一道門。
【COOLING_READY】
五項條件全部滿足，目標節點才允許接收遷移負載。
支路流量達到計劃值。
入口溫度進入允許範圍。
供回水壓差進入穩定區間。
在途熱量低於安全邊界。
緩衝罐已為新任務預留容量。
算力節點等著。
泵和閥門先走。
第二十五年秋，MPS-ThermalFabric完成第七輪內部疊代。
四組節點後面都多出一套熱狀態。
【NODE-A】
【可用顯存：284GiB】
【可用計算窗口：7】
【響應窗口熱預算：31.2MJ】
【預計恢復時間：18min】
【故障遷入：允許】
【NODE-B】
【可用顯存：301GiB】
【可用計算窗口：8】
【響應窗口熱預算：8.7MJ】
【預計恢復時間：43min】
【故障遷入：拒絕】
NODE-B的顯存更多，空閒計算窗口也更多，任務仍被擋在門外。
熱預算第一次取得了否決算力調度的權力。
這道權力在接下來的半年裡被反覆使用。
高溫啟動。
低溫啟動。
泵組降速。
風機失效。
過濾網堵塞。
流量傳感器漂移。
單支路泄漏模擬。
伺服器風扇停轉。
檢查點寫入延遲。
二號工作間的過濾棉換了一批又一批，閥門執行器拆開七次，兩隻緩衝罐外壁上多了新的測點和焊補痕跡。
荒原從秋天走到冬天，又從冬天走進第二十六年的春天。
七十六組故障場景被送進系統，留下七十六份記錄。
MPS熱織網從不保證每項任務都能繼續。
證據不足，負載不升。
熱預算蓋不住下一階段，任務凍結在檢查點。
支路恢復時間長於任務窗口，負載轉去其他節點。
所有安全路徑都被堵死，任務退出隊列。
一套可靠系統的本事，既包括把工作做完，也包括知道哪項工作此刻做不完。
第二十六年五月十九日，最終對照驗證開始。
此前六天，前哨站停掉大型加工設備，光伏陣列持續給儲能充電。
兩台廢土風機做完軸承和變槳檢查，八十千瓦時儲能達到百分之九十三荷電狀態。
江臨把最終測試拆成兩個階段。
二十七張170HX。
四台伺服器。
四條液冷支路。
三隻循環泵。
兩隻熱緩衝罐。
同一套閥門、傳感器、冷板與末端換熱器。
任務隊列也完全相同。
第一階段鎖死閥位。
第二階段接入MPS-ThermalFabric。
測試中不更換任何硬體。
【穩定工況板卡熱點溫度上限：75℃】
【斷流故障瞬態板卡熱點溫度上限：76℃】
連天氣都要儘量相同。
末端換熱器進風端接入可調混風箱。
固定閥位組經歷的八小時進風溫度曲線會被完整記錄，兩天後按同樣順序復現。
供水初溫、支路壓力、任務初始檢查點和儲能荷電狀態都要回到同一窗口。
否則一邊趕上涼快天氣，一邊碰上熱風，再漂亮的結果也只配拿去哄自己。
五月十九日上午七點三十分，固定閥位組啟動。
為了壓住NODE-D，集群負載限制在百分之六十四。
八小時後，任務隊列完成百分之六十三點七。
無板卡過溫，換熱器的平均能力只用了百分之六十七。
【固定閥位模式】
【集群安全持續負載：64%】
【任務隊列完成率：63.7%】
【觸發過溫保護：0】
【自動旁路接管與任務聯動：關閉】
【末端換熱能力使用率：67%】
測試結束，伺服器停機，循環泵繼續運轉。
等冷板、軟管和緩衝罐里滯留的熱量全部回落，儲能重新補至百分之九十三，任務隊列恢復到同一初始檢查點。
兩天後的上午八點，第二階段開始。
MPS-ThermalFabric接管集群。
二十七張170HX重新建立影子窗口。
同一批矩陣分塊、模型推理、代碼索引和證明依賴圖進入隊列。
【穩定可計算HBM：約1TiB】
【目標持續時間：8h】
【允許過溫保護：0】
【允許丟失檢查點：0】
基礎矩陣塊、模型權重和索引文件已經在備用節點建立只讀影子映射。
MPS-Checkpoint只保存當前分塊的增量狀態。
故障發生時，真正需要搬走的只剩上一個檢查點之後的變化，而非NODE-B整組顯存。
第一小時，集群IT負載穩定在九點八千瓦附近。
四條支路各跑各的流量。
NODE-A承擔持續矩陣計算，冷卻流量最高。
NODE-C以短時模型任務為主，熱峰交給緩衝罐；NODE-D內部板卡差異最大，帳上始終留著更厚的安全餘量。
第二小時，復現進風曲線進入升溫段。
末端換熱效率下降。
系統延後兩組低優先級任務十七分鐘，等第一隻緩衝罐恢復，再把它們放回隊列。
十二颱風機沒被粗暴地同時拉滿。
第三小時，一隻流量傳感器的讀數無故向下漂了八個百分點。
EvidenceGate核對供回水壓差、泵速和閥位反饋，三項數據都不支持支路流量真的下降。
漂移傳感器被降為低置信度來源，控制器繼續執行原計劃。
第五小時十二分，江臨走到主迴路旁，握住NODE-B主回水通路的切斷閥。
前面七十六組故障測試里，這個動作做過很多次。
最終驗證只認這一次。
閥門落到底。
第二支路流量迅速歸零。
【BRANCH-B主路：流量丟失】
【疑似故障：等待壓力／流量雙證據】
【凍結新任務下發】
【發起當前檢查點寫入】
NODE-B上的八張卡仍在運行。冷板和支路內殘留的冷卻液給了它們一小段熱慣性窗口，按當前負載算，撐不過兩分鐘。
第六秒，當前分塊結束。
供回水壓差同時越過故障確認閾值。
【故障確認：壓力／流量雙證據】
【啟動NODE-B備用旁路】
第九秒，檢查點寫入完成。
第十一秒，NODE-A與NODE-D收到預遷移計劃。
兩組節點都沒有立即接收遷移負載。
NODE-B備用旁路開始建立回水能力。
循環泵同步提速，NODE-A與NODE-D兩條遷移目標支路提前增流，分別建立新的水力狀態。
【NODE-A：等待COOLING_READY】
【NODE-D：等待COOLING_READY】
第十八秒，NODE-D入口流量達到計劃值。
第二十一秒，NODE-A壓差穩定。
第二十三秒，兩組狀態轉綠。
【COOLING_READY】
遷移開始。
剩餘運行時間最長的矩陣分塊最先轉移，隨後是模型推理。日誌索引凍結在檢查點，證明依賴圖掃描降到最低優先級。
NODE-B負載迅速下降，板卡熱點溫度還在憑慣性往上走。
七十三攝氏度。
七十四點二攝氏度。
七十五點一攝氏度。
穩態溫度線已經越過，距離故障瞬態上限只剩零點九攝氏度。
第四十六秒，備用旁路完成接管，新的冷卻液進入NODE-B冷板。
溫升曲線停住。
第七十一秒，曲線開始回落。
【主回水通路：已隔離】
【備用旁路：已接管】
【任務遷移：完成】
【丟失檢查點：0】
【觸發過溫保護：0】
【集群計算狀態：繼續】
江臨沒把切斷閥重新打開。
接下來的兩小時四十八分鐘，NODE-B一直依靠備用旁路運行。
遷移期間，集群總算力短暫下降百分之十三。
冷卻狀態穩定以後，部分任務重新回到NODE-B。
下午四點，八小時結束。
最後一個矩陣分塊寫入存儲。
二十七張170HX依次退出計算狀態，循環泵仍然運轉了三十七分鐘。
計算任務可以說停就停，熱量不接受行政命令。
它還留在冷板、軟管和緩衝罐里，必須一段一段送出去。
供電記錄同步生成。
【測試期間平均光伏與風機輸出：8.3kW】
【測試系統平均總電負荷：10.5kW】
【儲能用途：承擔功率缺口與切換波動】
【測試結束儲能荷電狀態：70%】
八十千瓦時儲能只填補發電與負載之間的缺口，光伏和風機承擔了大部分連續供電。
若把整場測試都算到儲能頭上，帳在第二眼就會穿幫。
最終報告在主屏上展開。
【MPS-ThermalFabric_v0.1最終驗證】
【測試硬體：與固定閥位模式完全相同】
【新增泵組：0】
【新增換熱器：0】
【新增冷板：0】
【固定閥位模式安全持續負載：64%】
【熱織網模式平均有效負載：96.8%】
【同任務隊列完成率：97.6%】
【相對固定閥位基準的平均有效負載提升：51.2%】
【模擬主回水通路完全斷流：1條】
【故障確認時間：6s】
【檢查點完成時間：9s】
【冷卻就緒與任務遷移啟動：23s】
【備用旁路接管：46s】
【觸發過溫保護：0】
【丟失檢查點：0】
【不可恢復任務：0】
【斷流故障瞬態溫度上限：76℃】
【實測最高板卡熱點溫度：75.1℃】
【結果：通過】
二十七張卡沒變。
泵組、閥門、冷板和換熱器也沒變。
固定閥位模式只能安全釋放百分之六十四的持續負載，熱織網把平均有效負載推到了百分之九十六點八。
系統從頭到尾沒多造出一瓦冷量。
它只做了三件事。
提前知道熱會在哪裡產生，給那條支路留出接住熱峰的預算，讓冷卻能力先於遷移任務抵達目標節點。
現在，算力、顯存和冷卻能力終於出現在同一張調度表上。
江臨在報告最後寫入適用邊界。
【以上提升僅對當前四節點異構集群成立。】
【不得直接外推至其他機櫃、板卡或冷卻架構。】
【任何新硬體必須重新標定熱阻、流量、響應延遲與安全餘量。】
百分之五十一點二無法當成通用節能率塞進宣傳頁。
換一批板卡，換一種冷板，甚至把軟管縮短几米，原有參數都可能作廢。
破解隱藏窗口以後，二十七張170HX擁有了更多可用顯存。
接入MPS熱織網以後，它們才第一次組成一座能在冷卻故障中繼續工作的計算集群。
江臨建立現實成果包。
【MPS-ThermalFabric_Reality_v0.1】
成果包拆成六個部分。
TF-Runtime負責算力任務與冷卻支路的聯合調度。
TF-BranchLedger記錄持續排熱能力、響應窗口熱預算、在途熱量和恢復時間。
TF-CoolingReady_API把冷卻就緒狀態送進任務遷移鏈。
TF-CabinetController管理溫度、壓力、流量、閥組與泵組。
TF-FaultTest保存斷流、泄漏、傳感器漂移、泵組降級和旁路接管規範。
TF-CommissioningKit負責新機櫃接入時的熱阻、流量和響應延遲標定。
TM-7的材料參數、設備編號、維護港結構和原始服務協議全部留在廢土封存區。
【RING-3_LOCAL_THERMAL_SERVICE_PACKAGE】
【權限層級：絕對封存】
現實成果包里只有標準銅冷板、普通泵組、電磁閥、板式換熱器、乾式冷卻器和工業傳感器能夠實現的東西。
未來工程師留下了一套思路。
從第二十四年夏天到第二十六年五月，江臨用了近兩年，把它改寫成2022年的管子、閥門、銅板和代碼。
隨後，他打開現實轉譯規劃頁。
【低熵異構算力中心一期】
【建設位置：江城主機房】
【北京研發中心：保留驗證節點】
【一期目標入櫃：96張通過穩定性篩選的170HX級板卡】
【目標可調度顯存：不低於3TiB】
【冷卻架構：MPS-ThermalFabric】
【調度架構：MPS-Scheduler】
【故障帳本：MPS-FaultLedger】
【證據邊界：MPS-EvidenceGate】
現實採購清單隨之向下展開。
伺服器，機櫃，配電櫃，泵組，冷板，傳感器，板式換熱器，室外乾式冷卻器，儲能和備用電源。
這已經超出紫荊公寓，也超出了北京研發中心那幾間測試房能夠容納的範圍。
大量伺服器會帶來噪聲、熱量、供電負荷、消防要求和二十四小時維護。北京適合保留小規模開發、標定和故障復現節點，真正的主機房放回江城，靠近低熵工坊的製造、採購與長期運維體系。
算力設備走哪條路線，已經有了答案。
局部冷卻故障發生以後，任務如何留下來，也有了第一版答案。
第二十六年五月二十二日，江臨完成代碼、圖紙、測試記錄和失敗帳本的三重校驗。
RING-3原始服務包繼續封存在前哨站存儲陣列，未寫入任何準備返回現實的載體。
兩塊從現實帶來、專門為回歸預留的硬碟，只保存經過現實材料、現實部件和現實接口重新驗證的代碼、圖紙、測試記錄與失敗帳本。
四台伺服器依次退出計算狀態。
循環泵繼續轉，直到冷板、軟管和緩衝罐里的餘熱全部回落。
隨後，泵組、閥門和伺服器斷電，液冷迴路保持封閉。
A100留在基準節點。
二十七張170HX留在四組伺服器里，另外五張備用卡重新封裝，收入二號工作間的防靜電櫃。
四台伺服器、兩組存儲和整套液冷系統，也全部留在前哨站。
二十六年的存放、啟停、拆裝和維修，已經吃掉了這些設備的大部分剩餘壽命。
把它們帶回2022年沒有多少價值，留在前哨站，至少還能繼續承擔驗證、計算和備件。
江臨最後接入主連接帶的，只有這兩塊完成鏡像校驗的回歸硬碟。
OR-MAINT-NE73通信鏈路降至最低維持功率。
TM-7外殼維護港依舊埋在東北七十三地下。那道外殼維護門已經打開，江臨沒再向更深處提交權限請求。
第十二次廢土任務表重新展開。
【恢復並擴建前哨站供電、通風與存儲環境：完成】
【建立A100基準節點：完成】
【確認170HX限制所在層級：完成】
【獲得可長期運行的計算節點：完成】
【推進MPS-Agent α現實適配：完成】
【進入TM-7外殼維護港：完成】
清單下方，是這二十六年留下的四項核心成果。
【170HX隱藏資源運行時：完成】
【一TiB級異構近存儲計算集群：完成】
【MPS-EvidenceGate現實適配：完成】
【MPS-ThermalFabric現實降維：完成】
工作間逐漸安靜下來，只剩廢土存儲陣列與低功耗監測節點運行。
風機還在低速旋轉，葉片每轉過一圈，都把一小段風聲送進前哨站。
二十六年前，四台伺服器剛落到這裡時，二號工作間裡連一條液冷管都沒有。
如今，四台伺服器仍沿牆排開。機殼與接口上留著反覆拆裝的編號，牆邊多出四條支路、兩隻焊補過的緩衝罐、成排的測點和寫滿失敗編號的標籤。
這些設備和痕跡都會留在廢土。
江臨帶走的只有兩塊硬碟，以及已經留在他腦中的知識、判斷和二十六年的失敗記錄。
他握住主連接帶。
風機聲斷了。
北京研發中心的燈光落進視野，牆上的電子鐘剛跳過一格。
【2022年9月30日】
【06：01：00】
門外走廊里，清潔人員推著車經過轉角，滾輪聲由近到遠。
今天上午八點半，低熵工坊要開首批交付生產準備會。
下午兩點半，南京那場人工智慧討論還等著他線上接入。
江臨坐到電腦前，把硬碟接入離線校驗終端。
兩份鏡像依次通過。
新建文檔。
【低熵異構算力中心一期採購與建設任務書】
第一行，板卡採購。
第二行，伺服器與機櫃。
第三行，供配電。
第四行，液冷支路與末端換熱。
第五行，江城主機房選址條件。
光標落到第六行。
江臨寫下首要驗收指標。
【任意一條可隔離主支路斷流後，已經開始的任務仍能安全留下來。】
廢土裡的二十六年到這裡結帳。
現實世界的一分鐘剛剛結束。
低熵工坊自己的算力中心，從第六行開始。
前哨站二號工作間。
四台伺服器沿牆排開，二十七張170HX分布在四組節點裡，風扇壓著最低轉速，發出很有耐心的嗡鳴。
它們已經學會了騙人。
不拆開看，誰也想不到這批本該老老實實待在礦場裡計算哈希值的板卡，已經被江臨從固件、驅動和運行時一路撬開，湊出接近一TiB的穩定可計算HBM。
礦場給它們安排的工作很單純，日復一日搬同一種磚。
到江臨手裡，矩陣分塊、模型推理、代碼索引和證明依賴圖都能往裡塞。
可一批板卡能計算，與一座計算集群能長期工作，中間還隔著一道很熱的門檻。
江臨把四天前新建的文件調到主屏。
【MPS-ThermalFabric_v0.1】
TM-7交出的本地服務包已經轉入只讀封存。
未來設備編號、介質參數和原始服務協議都被隔離在實驗鏈之外，控制系統只能讀取江臨重新定義過的接口。
維護港原來的熱管理表很簡單。
每條支路後面跟著一個數字，以兆焦為單位，代表還能吞下多少熱量。
這套寫法適合相變緩衝單元。
那東西像一隻預先騰空的水庫，剩下多少庫容，能接多大的洪峰，一眼就能看清。
眼前這套用水和乙二醇拼出來的液冷迴路麻煩得多，它一邊吃熱，一邊又把熱量送去末端換熱器。
只記剩餘容量，就像只盯著倉庫里還有多少空地，卻把每天進出多少貨忘了個乾淨。
於是江臨給每條支路開了兩本帳。
【持續排熱能力：kW】
【響應窗口內瞬態熱預算：MJ】
第一本帳管長久。
一條支路每秒能送走多少熱量，決定任務能跑一個小時，還是能跑一年。
第二本帳管眼前。
泵組提速要時間，閥門轉動要時間，冷卻液從干管走到冷板同樣要時間。
在這幾十秒里，晶片已經產生的熱峰由誰接住，決定板卡是繼續計算，還是先把自己燙到降頻。
算力有隊列，顯存有窗口，故障有帳本。
現在，熱量也得入帳。
江臨切斷本地服務包與實驗控制網的最後一條連接，開始改造四台伺服器。
原有風道保留下來，繼續照顧主板、供電、存儲和其他沒壓冷板的器件。
二十七張170HX的GPU與HBM區域分別覆蓋銅冷板，四組節點對應四條並聯液冷支路。
三隻循環泵負責公共供回水，每條主路旁邊再加一段常閉冗餘旁路。
正常時，旁路閉著。
主路斷流以後，它才有資格開口。
支路末端是一組翅片式液—氣換熱器，十二台工業風機負責把熱空氣送出工作間。
入口溫度、出口溫度、流量和供回水壓力都有獨立測點。GPU核心、HBM區域和板上供電區域的測溫結果取最高值，統一記作板卡熱點溫度。
兩隻廢棄壓力容器完成清洗和初次探傷後，被拖進工作間。
江臨在內部焊入金屬翅片，完成封裝，再重新進行焊縫探傷、水壓與氣密性測試，最後灌入水—乙二醇混合液，改作顯熱緩衝罐。
這兩隻罐子顯然談不上先進。
它們又大又重，單位體積吸熱能力也很普通，和TM-7的相變緩衝單元擺在一起，大致相當於鐵皮水桶參加未來工業品評獎。
可鐵皮水桶有鐵皮水桶的好處。
材料能買到，焊縫能檢查，壞了能拆，拆完還能照著再做一隻。
現實世界接得住這樣的東西。
管路完工以後，江臨仍然沒讓熱織網接管控制權。
他先把二十七張卡留在待機狀態，在四組冷板迴路上接入可調電阻加熱塊，一檔一檔地往冷卻液里灌熱。
六千瓦。
八千瓦。
十千瓦。
十一千瓦。
十一點八千瓦。
到最後一檔，末端換熱器的出液溫度緩慢上移。兩小時後，曲線停住，沒再往上爬。
江臨在測試頁上記下結果。
【末端持續排熱能力：11.8kW（當前進風溫度、額定風量下）】
這不是一條脫離環境成立的常數。
進風溫度、風機轉速和液側流量一併寫入標定記錄。
【四節點集群預計滿載IT功率：9.6kW至10.1kW】
換熱器夠用，泵組的總流量也夠用。
這是一條好消息，甚至好得有些可疑。
硬體明明能端走整套集群的熱量，四台伺服器此前卻始終無法同時跑滿。
熱去了哪裡？
第二十四年七月十七日，固定閥位基準測試開始。
四條支路按額定熱負荷完成靜態水力平衡。
閥門開度寫入記錄，測試期間全部鎖死。
二十七張170HX建立影子窗口，統一任務隊列依次進入四組節點。
前二十分鐘，曲線很漂亮。
第三十一分鐘，NODE-D的板卡熱點溫度首先越過七十五攝氏度。
這組節點承擔的檢查點壓縮和顯存搬運更多，GPU核心尚有餘地，HBM與板上供電區域已經開始積熱。
第四支路的回水溫度向上抬，第二、第三支路卻仍然涼快，NODE-B甚至空著接近一半的冷卻餘量。
十一點八千瓦的末端能力還在。
只是它平均分在四條管子裡，誰也沒問今天究竟是哪一組節點發熱更多。
第四十六分鐘，NODE-D最高板卡熱點溫度達到七十九點八攝氏度，第一張卡觸發降頻。
江臨繼續等待。
單獨壓低NODE-D沒有用。
這批矩陣分塊存在同步屏障，它慢下來，另外三組節點就得在檢查點前陪它站著。
此時遷走活動顯存窗口，還要重新建立映射。
MPS-Scheduler最終只能把整批任務的並發度一檔一檔往下砍。
百分之九十。
百分之八十。
百分之七十。
總負載降至百分之六十四，NODE-D的溫度曲線終於壓平。
其餘三條支路仍有餘量。
固定閥位模式繼續運行六小時，設備完整，過溫保護一次也沒觸發。
代價同樣很清楚：按九點八千瓦的滿載IT功率歸一化，固定閥位下，四節點只能釋放百分之六十四的安全持續計算負載。
【固定閥位基準】
【測試硬體：27張170HX】
【末端排熱能力：11.8kW（同標定工況）】
【四節點集群滿載IT功率基準：9.8kW】
【安全持續負載上限：64%】
【限制來源：局部支路熱量堆積】
【閒置冷卻能力：存在】
四條支路加起來明明夠用，最熱的那一條仍然吃不到別處剩下的冷量。
一座倉庫里糧食充足，餓著的人卻站在另一扇鎖死的門後。
繼續往倉庫里堆糧毫無意義，得先把門打開。
江臨在基準報告首頁寫下問題定義。
【冷卻系統總能力充足，局部冷卻能力無法隨計算任務轉移。】
最省事的補救有兩種。
重新調一次靜態水力平衡，或者按最熱節點的需求提高總流量和風機轉速。
前一種方案只認一種穩定負載，任務一換，平衡就得跟著重做。
後一種方案更直截了當，只要肯長期支付電耗、泵組餘量和換熱冗餘，總能把最壞工況壓住。
工程上經常這麼幹，可靠，省腦子，主要缺點是費錢。
成熟算力中心早已配備變頻泵、溫控閥和熱感知調度。
江臨此刻推進的也並非給水泵加一隻自動開關。
他要把任務即將產生的熱峰、管路尚未送到的在途熱量、支路恢復時間和檢查點遷移資格，全都壓進同一套可驗證的運行狀態。
任務計劃、在途熱量、閥門響應和檢查點遷移，必須進入同一張狀態表。
冷卻能力要像計算任務一樣可測量、可預留、可遷移，也要知道什麼時候該拒絕。
第二十四年八月十二日，MPS熱織網第一次接管四條支路。
NODE-A與NODE-B進入計算狀態，另外兩組待機。
這一輪只驗證穩定工況下的聯合調流：兩組節點進入穩定負載後，板卡熱點溫度必須維持在七十五攝氏度以下。
任務啟動四分二十秒，NODE-A溫升斜率超出預測。
第一支路閥門開大。
流量增加，支路壓力上升，公共干管壓差隨之變化，NODE-B獲得的流量開始下降。
四十秒後，NODE-B溫度抬頭。
系統轉而打開第二支路閥門。
NODE-B得救，NODE-A又開始升溫。
兩條支路圍著同一組泵打起了拉鋸。
電磁閥在百分之三十四與百分之七十一開度之間往返，壓力曲線先動，流量曲線隨後，溫度曲線拖在最後，等溫度終於把消息送到控制器，上一輪命令早已把局面改得面目全非。
第十一分鐘，NODE-B第一張170HX降頻。
第十三分鐘，第二張卡逼近保護邊界。
江臨按下終止鍵。
風扇還在轉，閥門也還在忙。
它們嚴格執行了每一道命令，問題恰恰出在命令太勤快。
【第一次聯合調流測試】
【結果：失敗】
【故障類型：支路耦合振盪】
【設備損失：0】
TM-7原有邏輯面對的是高速閥組、精密壓差控制和相變緩衝。
那裡的支路剛收到指令，新的冷卻能力已經在路上。
現實電磁閥更講規矩。
它從接到命令到穩定流量需要數秒，循環泵改變轉速以後，整條迴路還得重新找一次平衡。
把未來系統的控制節奏原樣塞給它，好比拿戰鬥機的動作口令去催一輛滿載叉車。
叉車已經很努力了，貨還是會翻。
江臨給控制器加上三條約束。
【任何流量調整，必須等待當前支路完成響應。】
【禁止依據單一溫度值連續反向修正。】
【壓力變化優先於溫度變化進入預測模型。】
第二十四年十二月，第二輪控制邏輯上線。
四條支路各自有了動態帳本。
持續排熱能力、響應窗口熱預算、冷卻液質量、出入口溫度、流量、冷板熱滯後和緩衝罐狀態，一項項寫進去。
第二次測試的前四十分鐘順利得多。
NODE-A和NODE-B保持穩定。NODE-C啟動後，第三支路帳面仍有百分之三十八餘量。
系統據此批准下一組矩陣任務進入。
七分鐘後，NODE-C連續三張卡越過警戒溫度。
出口溫度正常。
流量正常。
帳上的餘量也還在。
江臨盯著曲線看了幾秒，關閉任務。
那百分之三十八的餘量從頭到尾都沒存在過。
晶片剛產生的熱量先進入導熱層，再進入銅冷板、軟管和冷卻液，最後才會抵達支路出口。
傳感器看到的溫度屬於一百多秒以前，帳本拿著舊消息批准了新任務。
簡單地說，熱已經出發，報表卻還當它沒上路。
【第二次聯合調度測試】
【結果：失敗】
【故障類型：在途熱量未計入】
【觸發降頻：3張】
【設備損失：0】
江臨拆下NODE-C的冷板，把測點沿著整條導熱路徑一路鋪開。
晶片附近。
冷板入口。
冷板出口。
支路回水。
緩衝罐入口。
末端換熱器。
同一份熱量在六個位置留下了六個時間戳。
從晶片溫升出現，到回水溫度足以穩定反映負載，中間相差一百一十七秒。
一百一十七秒，足夠交換機搬完許多批數據，也足夠三張170HX把自己逼進降頻區。
對於水而言，這只是一段管路的正常路程。
響應窗口熱預算隨之改寫。
【響應窗口熱預算＝分配給本支路的可用顯熱容量＋窗口內預計排熱量－在途熱量－安全餘量】
兩隻緩衝罐由四條支路共享，同一份容量不能同時記進四本帳。系統必須先為各條支路預留容量，再根據罐內溫度、流量和恢復狀態更新可用部分。
分配容量和窗口內預計排熱量，可以通過標定與傳感器估算；安全餘量預先設定。
最難的是在途熱量。
它藏在導熱層、冷板、軟管和流動的液體裡，既無法靠一個測點直接讀出，也不會因為報表暫時看不見就自行消失。
江臨把每張170HX的功耗曲線、窗口映射規模、內核類型和預計持續時間送進MPS-Scheduler。
矩陣計算有矩陣計算的熱峰。
模型推理有模型推理的熱峰。
日誌索引和檢查點寫入的平均功耗相近，短時脈衝卻完全不同。
從這一輪疊代開始，算力調度器會提前提交任務計劃。
任務尚未進入GPU，它將在未來幾分鐘產生的熱量已經先記到支路帳上。
第二十五年四月，第三輪控制邏輯進入測試。
NODE-A的矩陣任務啟動前三十秒，第一支路開始增流。
任務真正進入計算時，冷卻液已經抵達冷板。
第二組任務原本準備送往NODE-C。
NODE-C此刻的表面溫度更低，帳本卻顯示它的緩衝恢復速度慢於NODE-B。
系統放棄這塊看上去更涼的節點，把任務送進溫度略高、熱預算更充足的NODE-B。
二十分鐘後，兩條支路都沒越線。
第一階段通過。
江臨隨即關閉NODE-B主回水閥的百分之七十，模擬主回水通路故障。
流量計首先報錯。
熱織網凍結NODE-B的新任務，正在運行的分塊開始寫檢查點，NODE-A與NODE-C收到遷移計劃。
順序正確。
十七秒後，NODE-A第一張卡還是降頻了。
任務跨過交換機只用了不到一秒。
NODE-A原有分塊尚未結束，新的影子窗口已經建立，算力負載瞬間抬升。
對應支路從收到計劃到建立有效流量，需要二十六秒。
第九秒，溫升斜率越線。
第十七秒，降頻觸發。
江臨終止遷移。
【第三次故障遷移測試】
【結果：失敗】
【故障類型：算力遷移快於冷卻響應】
【丟失檢查點：0】
【觸發降頻：1張】
數據可以抄近路，水還得老老實實走管子。
冷卻能力抵達以前，空閒算力只是帳面資產。
誰先把任務塞進去，誰就會收到一張過溫帳單。
江臨在任務遷移狀態機前加了一道門。
【COOLING_READY】
五項條件全部滿足，目標節點才允許接收遷移負載。
支路流量達到計劃值。
入口溫度進入允許範圍。
供回水壓差進入穩定區間。
在途熱量低於安全邊界。
緩衝罐已為新任務預留容量。
算力節點等著。
泵和閥門先走。
第二十五年秋，MPS-ThermalFabric完成第七輪內部疊代。
四組節點後面都多出一套熱狀態。
【NODE-A】
【可用顯存：284GiB】
【可用計算窗口：7】
【響應窗口熱預算：31.2MJ】
【預計恢復時間：18min】
【故障遷入：允許】
【NODE-B】
【可用顯存：301GiB】
【可用計算窗口：8】
【響應窗口熱預算：8.7MJ】
【預計恢復時間：43min】
【故障遷入：拒絕】
NODE-B的顯存更多，空閒計算窗口也更多，任務仍被擋在門外。
熱預算第一次取得了否決算力調度的權力。
這道權力在接下來的半年裡被反覆使用。
高溫啟動。
低溫啟動。
泵組降速。
風機失效。
過濾網堵塞。
流量傳感器漂移。
單支路泄漏模擬。
伺服器風扇停轉。
檢查點寫入延遲。
二號工作間的過濾棉換了一批又一批，閥門執行器拆開七次，兩隻緩衝罐外壁上多了新的測點和焊補痕跡。
荒原從秋天走到冬天，又從冬天走進第二十六年的春天。
七十六組故障場景被送進系統，留下七十六份記錄。
MPS熱織網從不保證每項任務都能繼續。
證據不足，負載不升。
熱預算蓋不住下一階段，任務凍結在檢查點。
支路恢復時間長於任務窗口，負載轉去其他節點。
所有安全路徑都被堵死，任務退出隊列。
一套可靠系統的本事，既包括把工作做完，也包括知道哪項工作此刻做不完。
第二十六年五月十九日，最終對照驗證開始。
此前六天，前哨站停掉大型加工設備，光伏陣列持續給儲能充電。
兩台廢土風機做完軸承和變槳檢查，八十千瓦時儲能達到百分之九十三荷電狀態。
江臨把最終測試拆成兩個階段。
二十七張170HX。
四台伺服器。
四條液冷支路。
三隻循環泵。
兩隻熱緩衝罐。
同一套閥門、傳感器、冷板與末端換熱器。
任務隊列也完全相同。
第一階段鎖死閥位。
第二階段接入MPS-ThermalFabric。
測試中不更換任何硬體。
【穩定工況板卡熱點溫度上限：75℃】
【斷流故障瞬態板卡熱點溫度上限：76℃】
連天氣都要儘量相同。
末端換熱器進風端接入可調混風箱。
固定閥位組經歷的八小時進風溫度曲線會被完整記錄，兩天後按同樣順序復現。
供水初溫、支路壓力、任務初始檢查點和儲能荷電狀態都要回到同一窗口。
否則一邊趕上涼快天氣，一邊碰上熱風，再漂亮的結果也只配拿去哄自己。
五月十九日上午七點三十分，固定閥位組啟動。
為了壓住NODE-D，集群負載限制在百分之六十四。
八小時後，任務隊列完成百分之六十三點七。
無板卡過溫，換熱器的平均能力只用了百分之六十七。
【固定閥位模式】
【集群安全持續負載：64%】
【任務隊列完成率：63.7%】
【觸發過溫保護：0】
【自動旁路接管與任務聯動：關閉】
【末端換熱能力使用率：67%】
測試結束，伺服器停機，循環泵繼續運轉。
等冷板、軟管和緩衝罐里滯留的熱量全部回落，儲能重新補至百分之九十三，任務隊列恢復到同一初始檢查點。
兩天後的上午八點，第二階段開始。
MPS-ThermalFabric接管集群。
二十七張170HX重新建立影子窗口。
同一批矩陣分塊、模型推理、代碼索引和證明依賴圖進入隊列。
【穩定可計算HBM：約1TiB】
【目標持續時間：8h】
【允許過溫保護：0】
【允許丟失檢查點：0】
基礎矩陣塊、模型權重和索引文件已經在備用節點建立只讀影子映射。
MPS-Checkpoint只保存當前分塊的增量狀態。
故障發生時，真正需要搬走的只剩上一個檢查點之後的變化，而非NODE-B整組顯存。
第一小時，集群IT負載穩定在九點八千瓦附近。
四條支路各跑各的流量。
NODE-A承擔持續矩陣計算，冷卻流量最高。
NODE-C以短時模型任務為主，熱峰交給緩衝罐；NODE-D內部板卡差異最大，帳上始終留著更厚的安全餘量。
第二小時，復現進風曲線進入升溫段。
末端換熱效率下降。
系統延後兩組低優先級任務十七分鐘，等第一隻緩衝罐恢復，再把它們放回隊列。
十二颱風機沒被粗暴地同時拉滿。
第三小時，一隻流量傳感器的讀數無故向下漂了八個百分點。
EvidenceGate核對供回水壓差、泵速和閥位反饋，三項數據都不支持支路流量真的下降。
漂移傳感器被降為低置信度來源，控制器繼續執行原計劃。
第五小時十二分，江臨走到主迴路旁，握住NODE-B主回水通路的切斷閥。
前面七十六組故障測試里，這個動作做過很多次。
最終驗證只認這一次。
閥門落到底。
第二支路流量迅速歸零。
【BRANCH-B主路：流量丟失】
【疑似故障：等待壓力／流量雙證據】
【凍結新任務下發】
【發起當前檢查點寫入】
NODE-B上的八張卡仍在運行。冷板和支路內殘留的冷卻液給了它們一小段熱慣性窗口，按當前負載算，撐不過兩分鐘。
第六秒，當前分塊結束。
供回水壓差同時越過故障確認閾值。
【故障確認：壓力／流量雙證據】
【啟動NODE-B備用旁路】
第九秒，檢查點寫入完成。
第十一秒，NODE-A與NODE-D收到預遷移計劃。
兩組節點都沒有立即接收遷移負載。
NODE-B備用旁路開始建立回水能力。
循環泵同步提速，NODE-A與NODE-D兩條遷移目標支路提前增流，分別建立新的水力狀態。
【NODE-A：等待COOLING_READY】
【NODE-D：等待COOLING_READY】
第十八秒，NODE-D入口流量達到計劃值。
第二十一秒，NODE-A壓差穩定。
第二十三秒，兩組狀態轉綠。
【COOLING_READY】
遷移開始。
剩餘運行時間最長的矩陣分塊最先轉移，隨後是模型推理。日誌索引凍結在檢查點，證明依賴圖掃描降到最低優先級。
NODE-B負載迅速下降，板卡熱點溫度還在憑慣性往上走。
七十三攝氏度。
七十四點二攝氏度。
七十五點一攝氏度。
穩態溫度線已經越過，距離故障瞬態上限只剩零點九攝氏度。
第四十六秒，備用旁路完成接管，新的冷卻液進入NODE-B冷板。
溫升曲線停住。
第七十一秒，曲線開始回落。
【主回水通路：已隔離】
【備用旁路：已接管】
【任務遷移：完成】
【丟失檢查點：0】
【觸發過溫保護：0】
【集群計算狀態：繼續】
江臨沒把切斷閥重新打開。
接下來的兩小時四十八分鐘，NODE-B一直依靠備用旁路運行。
遷移期間，集群總算力短暫下降百分之十三。
冷卻狀態穩定以後，部分任務重新回到NODE-B。
下午四點，八小時結束。
最後一個矩陣分塊寫入存儲。
二十七張170HX依次退出計算狀態，循環泵仍然運轉了三十七分鐘。
計算任務可以說停就停，熱量不接受行政命令。
它還留在冷板、軟管和緩衝罐里，必須一段一段送出去。
供電記錄同步生成。
【測試期間平均光伏與風機輸出：8.3kW】
【測試系統平均總電負荷：10.5kW】
【儲能用途：承擔功率缺口與切換波動】
【測試結束儲能荷電狀態：70%】
八十千瓦時儲能只填補發電與負載之間的缺口，光伏和風機承擔了大部分連續供電。
若把整場測試都算到儲能頭上，帳在第二眼就會穿幫。
最終報告在主屏上展開。
【MPS-ThermalFabric_v0.1最終驗證】
【測試硬體：與固定閥位模式完全相同】
【新增泵組：0】
【新增換熱器：0】
【新增冷板：0】
【固定閥位模式安全持續負載：64%】
【熱織網模式平均有效負載：96.8%】
【同任務隊列完成率：97.6%】
【相對固定閥位基準的平均有效負載提升：51.2%】
【模擬主回水通路完全斷流：1條】
【故障確認時間：6s】
【檢查點完成時間：9s】
【冷卻就緒與任務遷移啟動：23s】
【備用旁路接管：46s】
【觸發過溫保護：0】
【丟失檢查點：0】
【不可恢復任務：0】
【斷流故障瞬態溫度上限：76℃】
【實測最高板卡熱點溫度：75.1℃】
【結果：通過】
二十七張卡沒變。
泵組、閥門、冷板和換熱器也沒變。
固定閥位模式只能安全釋放百分之六十四的持續負載，熱織網把平均有效負載推到了百分之九十六點八。
系統從頭到尾沒多造出一瓦冷量。
它只做了三件事。
提前知道熱會在哪裡產生，給那條支路留出接住熱峰的預算，讓冷卻能力先於遷移任務抵達目標節點。
現在，算力、顯存和冷卻能力終於出現在同一張調度表上。
江臨在報告最後寫入適用邊界。
【以上提升僅對當前四節點異構集群成立。】
【不得直接外推至其他機櫃、板卡或冷卻架構。】
【任何新硬體必須重新標定熱阻、流量、響應延遲與安全餘量。】
百分之五十一點二無法當成通用節能率塞進宣傳頁。
換一批板卡，換一種冷板，甚至把軟管縮短几米，原有參數都可能作廢。
破解隱藏窗口以後，二十七張170HX擁有了更多可用顯存。
接入MPS熱織網以後，它們才第一次組成一座能在冷卻故障中繼續工作的計算集群。
江臨建立現實成果包。
【MPS-ThermalFabric_Reality_v0.1】
成果包拆成六個部分。
TF-Runtime負責算力任務與冷卻支路的聯合調度。
TF-BranchLedger記錄持續排熱能力、響應窗口熱預算、在途熱量和恢復時間。
TF-CoolingReady_API把冷卻就緒狀態送進任務遷移鏈。
TF-CabinetController管理溫度、壓力、流量、閥組與泵組。
TF-FaultTest保存斷流、泄漏、傳感器漂移、泵組降級和旁路接管規範。
TF-CommissioningKit負責新機櫃接入時的熱阻、流量和響應延遲標定。
TM-7的材料參數、設備編號、維護港結構和原始服務協議全部留在廢土封存區。
【RING-3_LOCAL_THERMAL_SERVICE_PACKAGE】
【權限層級：絕對封存】
現實成果包里只有標準銅冷板、普通泵組、電磁閥、板式換熱器、乾式冷卻器和工業傳感器能夠實現的東西。
未來工程師留下了一套思路。
從第二十四年夏天到第二十六年五月，江臨用了近兩年，把它改寫成2022年的管子、閥門、銅板和代碼。
隨後，他打開現實轉譯規劃頁。
【低熵異構算力中心一期】
【建設位置：江城主機房】
【北京研發中心：保留驗證節點】
【一期目標入櫃：96張通過穩定性篩選的170HX級板卡】
【目標可調度顯存：不低於3TiB】
【冷卻架構：MPS-ThermalFabric】
【調度架構：MPS-Scheduler】
【故障帳本：MPS-FaultLedger】
【證據邊界：MPS-EvidenceGate】
現實採購清單隨之向下展開。
伺服器，機櫃，配電櫃，泵組，冷板，傳感器，板式換熱器，室外乾式冷卻器，儲能和備用電源。
這已經超出紫荊公寓，也超出了北京研發中心那幾間測試房能夠容納的範圍。
大量伺服器會帶來噪聲、熱量、供電負荷、消防要求和二十四小時維護。北京適合保留小規模開發、標定和故障復現節點，真正的主機房放回江城，靠近低熵工坊的製造、採購與長期運維體系。
算力設備走哪條路線，已經有了答案。
局部冷卻故障發生以後，任務如何留下來，也有了第一版答案。
第二十六年五月二十二日，江臨完成代碼、圖紙、測試記錄和失敗帳本的三重校驗。
RING-3原始服務包繼續封存在前哨站存儲陣列，未寫入任何準備返回現實的載體。
兩塊從現實帶來、專門為回歸預留的硬碟，只保存經過現實材料、現實部件和現實接口重新驗證的代碼、圖紙、測試記錄與失敗帳本。
四台伺服器依次退出計算狀態。
循環泵繼續轉，直到冷板、軟管和緩衝罐里的餘熱全部回落。
隨後，泵組、閥門和伺服器斷電，液冷迴路保持封閉。
A100留在基準節點。
二十七張170HX留在四組伺服器里，另外五張備用卡重新封裝，收入二號工作間的防靜電櫃。
四台伺服器、兩組存儲和整套液冷系統，也全部留在前哨站。
二十六年的存放、啟停、拆裝和維修，已經吃掉了這些設備的大部分剩餘壽命。
把它們帶回2022年沒有多少價值，留在前哨站，至少還能繼續承擔驗證、計算和備件。
江臨最後接入主連接帶的，只有這兩塊完成鏡像校驗的回歸硬碟。
OR-MAINT-NE73通信鏈路降至最低維持功率。
TM-7外殼維護港依舊埋在東北七十三地下。那道外殼維護門已經打開，江臨沒再向更深處提交權限請求。
第十二次廢土任務表重新展開。
【恢復並擴建前哨站供電、通風與存儲環境：完成】
【建立A100基準節點：完成】
【確認170HX限制所在層級：完成】
【獲得可長期運行的計算節點：完成】
【推進MPS-Agent α現實適配：完成】
【進入TM-7外殼維護港：完成】
清單下方，是這二十六年留下的四項核心成果。
【170HX隱藏資源運行時：完成】
【一TiB級異構近存儲計算集群：完成】
【MPS-EvidenceGate現實適配：完成】
【MPS-ThermalFabric現實降維：完成】
工作間逐漸安靜下來，只剩廢土存儲陣列與低功耗監測節點運行。
風機還在低速旋轉，葉片每轉過一圈，都把一小段風聲送進前哨站。
二十六年前，四台伺服器剛落到這裡時，二號工作間裡連一條液冷管都沒有。
如今，四台伺服器仍沿牆排開。機殼與接口上留著反覆拆裝的編號，牆邊多出四條支路、兩隻焊補過的緩衝罐、成排的測點和寫滿失敗編號的標籤。
這些設備和痕跡都會留在廢土。
江臨帶走的只有兩塊硬碟，以及已經留在他腦中的知識、判斷和二十六年的失敗記錄。
他握住主連接帶。
風機聲斷了。
北京研發中心的燈光落進視野，牆上的電子鐘剛跳過一格。
【2022年9月30日】
【06：01：00】
門外走廊里，清潔人員推著車經過轉角，滾輪聲由近到遠。
今天上午八點半，低熵工坊要開首批交付生產準備會。
下午兩點半，南京那場人工智慧討論還等著他線上接入。
江臨坐到電腦前，把硬碟接入離線校驗終端。
兩份鏡像依次通過。
新建文檔。
【低熵異構算力中心一期採購與建設任務書】
第一行，板卡採購。
第二行，伺服器與機櫃。
第三行，供配電。
第四行，液冷支路與末端換熱。
第五行，江城主機房選址條件。
光標落到第六行。
江臨寫下首要驗收指標。
【任意一條可隔離主支路斷流後，已經開始的任務仍能安全留下來。】
廢土裡的二十六年到這裡結帳。
現實世界的一分鐘剛剛結束。
低熵工坊自己的算力中心，從第六行開始。