如果你最近在關(guān)注算力基礎(chǔ)設(shè)施一定繞不開“智算中心”這個關(guān)鍵詞。簡單說智算中心就是專門為AI訓(xùn)練和推理設(shè)計的超大規(guī)模計算集群園區(qū)它跟傳統(tǒng)數(shù)據(jù)中心的區(qū)別不在于是不是掛了幾張GPU卡而是整個園區(qū)從供配電、制冷到網(wǎng)絡(luò)拓?fù)涠紴椴⑿杏嬎阒匦屡帕艘槐?。這類工程動輒涉及幾億到幾十億的資金投入周期長、專業(yè)交叉嚴(yán)重前期稍有不慎后面就是成百上千萬的電費浪費和反復(fù)改造。這也是我寫這篇指南的原因把我這些年從立項調(diào)研到機(jī)房亮燈驗收踩過的坑沉淀成一條可對照的路線圖順便把“液冷可研”這個最容易在規(guī)劃階段被漏掉的關(guān)鍵環(huán)節(jié)單獨拎出來講透。不管你是數(shù)據(jù)中心運維轉(zhuǎn)智算、云廠商的交付工程師還是項目負(fù)責(zé)人接下來的內(nèi)容應(yīng)該都能用上。1. 智算中心整體設(shè)計邏輯與建設(shè)前必須想清楚的事1.1 智算中心不是“機(jī)房里多放幾臺GPU服務(wù)器”很多人一聽智算中心第一反應(yīng)是買機(jī)器、灌軟件、跑訓(xùn)練但真正動起來才發(fā)現(xiàn)瓶頸根本不在GPU。傳統(tǒng)數(shù)據(jù)中心的單機(jī)柜功率密度普遍在5到10千瓦空調(diào)吹一吹就壓得住智算中心的訓(xùn)練機(jī)柜動不動就是20到40千瓦甚至更高。拿現(xiàn)在主流的8卡訓(xùn)練服務(wù)器來說單臺設(shè)備功耗輕松到6到7千瓦一個機(jī)柜放上4到6臺功率密度直接拉滿傳統(tǒng)風(fēng)冷在這種熱量面前基本沒有還手之力。所以我的建議一直是做智算中心不要先畫機(jī)房平面圖也不要先選服務(wù)器品牌第一件事是把功率密度和散熱方式定下來。先算清楚“這個機(jī)房未來要裝多少千瓦的IT設(shè)備、用什么制冷方式”再去反推土建、供電、機(jī)柜布局和空調(diào)選型。定功率密度就是定整棟建筑的天花板這一步錯了后面所有圖紙都要重來。1.2 全生命周期成本里電費才是真正的大頭智算中心的全生命周期成本不是采購服務(wù)器那一下子的錢而是五年甚至十年持續(xù)不斷的水電開銷。我習(xí)慣用一個很簡單的公式來評估一個項目C_total C_capex C_opex × YC_capex 是建設(shè)投資C_opex 是年度運營成本Y是運營年限。很多團(tuán)隊在立項時把預(yù)算幾乎全壓在硬件采購上對電費只給一個粗略估值等到真實賬單下來才發(fā)現(xiàn)錢根本不是這么花的。舉一個直觀例子。假設(shè)一個中型項目部署1000臺8卡訓(xùn)練服務(wù)器單臺整機(jī)功耗按6千瓦算IT負(fù)載合計6000千瓦。如果設(shè)計PUE是1.5總輸入功率就是9000千瓦如果采用較好的液冷方案把PUE做到1.2總輸入功率是7200千瓦。兩者相差1800千瓦一年8760小時就是1577萬度電。按0.6元/度估算光一年電費就差了946萬元十年就是接近一個億。這個數(shù)量級已經(jīng)和一批服務(wù)器本身的價格差不多了。所以我給所有準(zhǔn)備立項的團(tuán)隊一個忠告不要在PPT里把PUE當(dāng)成宣傳數(shù)字要把PUE當(dāng)成成本模型的核心變量來算。液冷可研的意義就在這里——它決定的不只是散熱效果更是整個數(shù)據(jù)中心五年期的成本曲線。1.3 不同建設(shè)模式的適用場景要先想清楚智算中心的落地方式?jīng)]有標(biāo)準(zhǔn)答案常見的有自建、改造、代建和租賃這幾種。自建適合長期戰(zhàn)略投入、對基礎(chǔ)設(shè)施有強(qiáng)掌控要求的團(tuán)隊前期重、后期穩(wěn)舊機(jī)房改造適合預(yù)算有限、希望在已有物業(yè)上快速出算力的場景但電力余量和樓板承重往往卡脖子代建則把工程風(fēng)險交給專業(yè)EPC團(tuán)隊適合沒有基建經(jīng)驗的團(tuán)隊前提是要有足夠的項目管理能力去把控質(zhì)量和進(jìn)度算力租賃最輕但長期成本不可控且很難做深度定制。我遇到過不少團(tuán)隊前期沒選對建設(shè)模式項目做到一半才發(fā)現(xiàn)“原有電力不夠”“樓板承重扛不住液冷載荷”最后被迫改方案追加預(yù)算。所以這個選擇題應(yīng)該在需求調(diào)研階段就完成而不是等設(shè)計完成之后再換。2. 需求分析與算力規(guī)劃把業(yè)務(wù)語言翻譯成機(jī)柜數(shù)量2.1 從模型、數(shù)據(jù)和訓(xùn)練時間倒推總算力需求智算中心的建設(shè)規(guī)模不是拍腦袋說“我們要買幾千張卡”拍出來的而是從業(yè)務(wù)目標(biāo)倒推出來的。你要訓(xùn)練什么模型、參數(shù)量多大、數(shù)據(jù)量多少、希望多長時間訓(xùn)練完一個版本、線上推理的峰值并發(fā)是多少這些信息匯總起來才能換算成總算力需求。做規(guī)劃時我會用一個工程估算公式用6倍乘法的近似方法來估算訓(xùn)練所需算力總算力FLOPs ≈ 6 × 模型參數(shù)量 × 訓(xùn)練Token數(shù)舉個簡化例子如果目標(biāo)是一個70億參數(shù)的模型用1萬億Token的數(shù)據(jù)訓(xùn)練那么總算力需求大約是6 × 7×10^9 × 10^12 4.2×10^22 FLOPs。如果希望30天訓(xùn)練完成也就是2592000秒換算下來是1.62×10^16 FLOP/s約16.2 PFLOPS。但這只是理論下限還要算上多卡并行通信開銷、故障重試、框架損耗實際規(guī)劃時建議打2到3倍余量按40到50 PFLOPS來選型。這個部分很考驗規(guī)劃人員的功力因為業(yè)務(wù)給的需求往往是“我們要支持千億級模型訓(xùn)練”但千億模型訓(xùn)練和百億模型訓(xùn)練對顯存、網(wǎng)絡(luò)帶寬、存儲吞吐的要求完全不是一個量級。一定要把業(yè)務(wù)語言翻譯成工程參數(shù)再往下拆裝硬件。2.2 從算力需求折算成機(jī)柜和建筑面積總算力指標(biāo)定了以后下一步是把FLOPs折算成GPU卡數(shù)量、服務(wù)器數(shù)量、機(jī)柜數(shù)量最后變成建筑面積和供配電容量。這里每個環(huán)節(jié)都有損耗和冗余系數(shù)。以目前主流的8卡訓(xùn)練服務(wù)器為參照一臺整機(jī)功率約6到7千瓦單卡顯存和算力按產(chǎn)品規(guī)格計算?？紤]供電余量和散熱余量后一個標(biāo)準(zhǔn)機(jī)柜通常放4到6臺對應(yīng)單柜功率密度20到40千瓦。加上網(wǎng)絡(luò)機(jī)柜、存儲機(jī)柜、管理節(jié)點整個集群的機(jī)柜數(shù)會在計算節(jié)點數(shù)量的基礎(chǔ)上增加15%到25%。規(guī)劃機(jī)柜時還要把機(jī)房分區(qū)當(dāng)作一件正事來做。訓(xùn)練區(qū)、推理區(qū)、存儲區(qū)、網(wǎng)絡(luò)區(qū)對供電和制冷的要求完全不同訓(xùn)練區(qū)高密高電耗適合液冷推理區(qū)負(fù)載波動大有時適合風(fēng)冷存儲區(qū)對振動和散熱要求特殊網(wǎng)絡(luò)區(qū)對物理鏈路安全要求高。分區(qū)做得越清晰后期運維越省心。2.3 規(guī)劃階段一定要產(chǎn)出的三份文檔我踩過最大的坑之一就是規(guī)劃階段“只在會議室里討論沒形成文檔”。智算中心這類項目參與方太多需求方、設(shè)計院、集成商、機(jī)房施工隊誰的理解都可能產(chǎn)生偏差。所以規(guī)劃完成后至少要落三份文檔需求規(guī)格說明書列出業(yè)務(wù)場景、算力指標(biāo)、可用性要求、擴(kuò)展計劃。機(jī)柜功率譜每個區(qū)域的機(jī)柜數(shù)量、單柜功率、總負(fù)荷、冗余要求。系統(tǒng)架構(gòu)圖從GPU節(jié)點到網(wǎng)絡(luò)交換、存儲、管理平臺的整體邏輯圖。這三份文檔就是項目的地基。別看它們只是幾張紙和幾張圖后面所有詳細(xì)設(shè)計和招采參數(shù)都是從這里面長出來的。文檔寫不清楚招標(biāo)階段一定會被供應(yīng)商反復(fù)追問施工階段更會處處扯皮。3. 液冷系統(tǒng)可行性研究與關(guān)鍵參數(shù)為什么它是智算中心的必答題3.1 液冷可研不是“可選項分析”而是“形式選擇”很多人以為液冷可研是論證“要不要用液冷”其實在智算中心這個場景下答案基本已經(jīng)確定訓(xùn)練區(qū)必須用液冷可研真正要回答的是“用哪種液冷、冷量怎么配、風(fēng)險怎么控”。原因很簡單當(dāng)單柜功率超過15千瓦后傳統(tǒng)風(fēng)冷的制冷能效比會明顯下降空調(diào)風(fēng)機(jī)功率、噪聲、氣流組織復(fù)雜度都在漲局部熱點幾乎無法根除。硬要用風(fēng)冷把40千瓦的機(jī)柜壓住不是做不到是電費和運維成本高到不劃算。液冷的主流路線有冷板式和浸沒式兩種。冷板式通過金屬冷板直接接觸CPU、GPU等發(fā)熱器件冷卻液在冷板內(nèi)部循環(huán)帶走熱量浸沒式則把整臺服務(wù)器泡在絕緣冷卻液里。落地實踐中冷板式因為對現(xiàn)有服務(wù)器結(jié)構(gòu)改動小、維護(hù)難度低、產(chǎn)業(yè)鏈成熟是當(dāng)前多數(shù)智算中心采用的主流方案。浸沒式散熱極限更高但設(shè)備重量、運維便利性、介質(zhì)成本都需要復(fù)雜評估。3.2 冷板式液冷系統(tǒng)的核心部件與參數(shù)冷板式液冷系統(tǒng)可以理解成一套“體外循環(huán)系統(tǒng)”。GPU產(chǎn)生的熱量通過冷板傳導(dǎo)給冷卻液冷卻液在服務(wù)器內(nèi)部循環(huán)后被匯集到分歧管Manifold再進(jìn)入CDU冷量分配單元在CDU里和室外側(cè)的冷卻水做熱交換最后把熱量帶到室外的冷卻塔或干冷器散掉。這套系統(tǒng)里有兩個關(guān)鍵設(shè)計參數(shù)一次側(cè)和二次側(cè)的供回水溫度。所謂一次側(cè)就是CDU連接到室外散熱設(shè)備那一路二次側(cè)就是進(jìn)入服務(wù)器冷板的那一路。典型的二次側(cè)供/回水溫度可以做到45℃/55℃這個溫度遠(yuǎn)高于傳統(tǒng)機(jī)房空調(diào)的7℃/12℃冷凍水意味著大部分時間里可以不開壓縮機(jī)只用自然冷卻就把熱量帶走。這也就是液冷能把PUE做到1.15甚至更低的核心原因。需要注意的是不同服務(wù)器廠商對冷卻液溫度、流量、水質(zhì)的要求有差異設(shè)計參數(shù)必須以設(shè)備廠商的認(rèn)證值為準(zhǔn)。關(guān)于水質(zhì)千萬不能直接用自來水。冷卻液需要是去離子水或?qū)Ｓ美鋮s液電導(dǎo)率、pH值、顆粒度都有嚴(yán)格要求。我見過有項目在運維階段隨意補(bǔ)水結(jié)果管道內(nèi)壁結(jié)垢換熱效率急劇下降GPU溫度一路報警。這個細(xì)節(jié)小但后果極重。3.3 液冷可行性研究到底要研究什么一份真正可用的液冷可研不能只寫“液冷方案可行”這幾個字。它至少應(yīng)該覆蓋以下內(nèi)容熱量負(fù)荷計算明確訓(xùn)練區(qū)、推理區(qū)、存儲區(qū)分別需要帶走多少千瓦熱量。系統(tǒng)路由和機(jī)房布局CDU放哪、管道怎么走、有沒有泄漏風(fēng)險點。水質(zhì)與防腐方案材質(zhì)匹配、水質(zhì)監(jiān)控指標(biāo)、補(bǔ)水策略。冷源方式選擇冷卻塔、干冷器、水源熱泵等不同方案在本地氣候下的全年能效模擬。供電與自控聯(lián)動CDU水泵、室外散熱風(fēng)機(jī)的供電冗余和控制邏輯。應(yīng)急工況分析市電中斷、CDU故障、單臺水泵失效時系統(tǒng)能否維持安全運行時間。很多團(tuán)隊把液冷可研做成了“設(shè)備選型清單”忽略了水力計算和全年能效模擬。實際上冷卻塔的逼近度、水泵揚程、管網(wǎng)阻力每一項數(shù)據(jù)都會影響室外設(shè)備的臺數(shù)選型和管路直徑。如果這些沒有算清楚等施工圖出來再改代價極高。3.4 液冷方案避坑混合冷卻是常態(tài)不是可選項我建議初次建設(shè)智算中心的團(tuán)隊別一上來就把整個機(jī)房全部液冷。更務(wù)實的做法是混合冷卻訓(xùn)練區(qū)高密機(jī)柜用冷板式液冷推理區(qū)、存儲區(qū)、網(wǎng)絡(luò)區(qū)保留風(fēng)冷。理由很實際推理服務(wù)器功率波動大液冷系統(tǒng)的流量調(diào)節(jié)響應(yīng)往往跟不上突發(fā)的負(fù)載變化存儲和網(wǎng)絡(luò)設(shè)備對改造敏感風(fēng)冷能降低改造風(fēng)險。另外要注意液冷不是“水進(jìn)機(jī)房”冷卻液只經(jīng)過服務(wù)器內(nèi)部的冷板和密閉管路不會直接淋到電路板上。真正需要防范的是快接頭松動、軟管老化導(dǎo)致的微滲漏。設(shè)計階段就要在機(jī)柜底部做漏液檢測管路連接處做防滴漏快插運維階段要有可視化監(jiān)控。這些“臟活累活”想清楚液冷才有資格成為你說的高可用系統(tǒng)。4. IT基礎(chǔ)設(shè)施網(wǎng)絡(luò)、存儲與集群調(diào)度最容易拖后腿的隱形瓶頸4.1 網(wǎng)絡(luò)架構(gòu)東向流量才是智算中心的主角智算中心的網(wǎng)絡(luò)和傳統(tǒng)數(shù)據(jù)中心的差異可以概括成一句話東西向流量爆發(fā)式增長南北向入口只是配角。GPU訓(xùn)練任務(wù)里AllReduce、參數(shù)同步、流水線并行都需要在節(jié)點間高速交換海量數(shù)據(jù)一次千卡規(guī)模訓(xùn)練網(wǎng)絡(luò)里的瞬時流量可以輕松達(dá)到每秒數(shù)TB級別。因此網(wǎng)絡(luò)拓?fù)浔仨毑捎脽o阻塞或低過載比設(shè)計。主流方案是脊葉Spine-Leaf架構(gòu)也叫Clos網(wǎng)絡(luò)。Leaf交換機(jī)連接GPU節(jié)點Spine交換機(jī)負(fù)責(zé)高速轉(zhuǎn)發(fā)任意兩臺Leaf之間有多條等價路徑既保證帶寬又提供冗余。技術(shù)選型上InfiniBand和RoCE是兩種主要路線。InfiniBand在性能、可靠性和生態(tài)成熟度上有優(yōu)勢但成本更高、兼容性受限RoCE能跑在普通以太網(wǎng)交換機(jī)上成本相對低但對網(wǎng)絡(luò)調(diào)優(yōu)能力要求很高擁塞控制參數(shù)沒調(diào)好性能可能大打折扣。這里給一個樸素建議如果團(tuán)隊網(wǎng)絡(luò)經(jīng)驗扎實RoCE完全可以支撐大規(guī)模訓(xùn)練如果希望開箱即用、少踩調(diào)優(yōu)的坑InfiniBand值得多花預(yù)算。不管選哪個網(wǎng)絡(luò)設(shè)備的端口速率、緩存容量、路由策略都要和訓(xùn)練框架的通信模式匹配不要等上線了才做性能驗證。4.2 存儲設(shè)計不能讓數(shù)據(jù)加載拖慢計算訓(xùn)練任務(wù)對存儲的核心要求是“高帶寬、低延遲、高并發(fā)”。比如一個數(shù)據(jù)加載流程它可能是從對象存儲讀原始數(shù)據(jù)、轉(zhuǎn)換格式后寫入并行文件系統(tǒng)、訓(xùn)練時再從并行文件系統(tǒng)隨機(jī)讀取。這些環(huán)節(jié)里最容易卡住的往往是并行文件系統(tǒng)的聚合帶寬。做存儲規(guī)劃時我會重點計算兩個指標(biāo)一是訓(xùn)練集全量加載時間二是斷點續(xù)訓(xùn)時檢查點保存的時間。如果集群規(guī)模是1000張GPU卡每張卡每秒鐘需要讀取幾百兆字節(jié)的訓(xùn)練樣本聚合帶寬就要達(dá)到幾十GB/s級別這個指標(biāo)對存儲設(shè)備、網(wǎng)絡(luò)鏈路和存儲客戶端的壓力都很大。建議存儲方案選擇成熟并行文件系統(tǒng)搭配智能分層緩存兼顧成本和性能。另外檢查點寫爆存儲是真實發(fā)生過的災(zāi)難。訓(xùn)練到一半如果節(jié)點故障要從最近檢查點恢復(fù)檢查點文件可能達(dá)到幾十TB甚至更大存儲系統(tǒng)如果扛不住突發(fā)寫入訓(xùn)練就得長時間空等。所以存儲規(guī)劃一定要把檢查點寫入峰值當(dāng)作一個獨立場景來設(shè)計而不是只按業(yè)務(wù)數(shù)據(jù)的平均吞吐來算。4.3 算力調(diào)度與容器平臺別把集群管成一張靜態(tài)資源表硬件裝完只是開始真正持續(xù)運營的核心是上層調(diào)度系統(tǒng)。常見的調(diào)度平臺有Slurm和Kubernetes兩類Slurm擅長傳統(tǒng)HPC批處理作業(yè)排隊和資源管理直觀Kubernetes更靈活適合多租戶、容器化部署和彈性伸縮。很多智算中心采用二者結(jié)合底層用Slurm管理訓(xùn)練任務(wù)上層用Kubernetes承載推理服務(wù)和數(shù)據(jù)預(yù)處理任務(wù)。無論選哪個平臺都要重點處理GPU共享與隔離問題。訓(xùn)練任務(wù)對顯存和算力的獨占性要求高建議默認(rèn)整卡分配推理任務(wù)則可以借助MIG或時間片等技術(shù)做細(xì)粒度切分避免一個輕量推理服務(wù)占走整塊GPU浪費資源。在實際運營里多租戶場景必須做好配額管理否則某個團(tuán)隊一次性提交幾百個任務(wù)很容易把整個集群的CPU內(nèi)存打滿影響所有人的工作。5. 建設(shè)實施的關(guān)鍵路徑與工程管理從設(shè)計圖紙到亮燈跑訓(xùn)練5.1 全流程里程碑從可研到驗收的路線圖一個智算中心的建設(shè)流程通常可以按這幾個里程碑推進(jìn)可行性研究立項、初步設(shè)計、施工圖設(shè)計、設(shè)備招采、土建施工、機(jī)電安裝、聯(lián)調(diào)測試、試運行、驗收交付。每個里程碑之前都應(yīng)該設(shè)置明確的評審關(guān)口上一階段沒歸檔不進(jìn)入下一階段。施工階段我最想提醒的是“設(shè)備招采與土建施工要并行推進(jìn)”。GPU服務(wù)器、交換機(jī)這類IT設(shè)備交付周期長如果等機(jī)房建好再采購項目周期會被拉長幾個月。更合理的做法是初步設(shè)計確定后立即啟動長周期設(shè)備采購意向確認(rèn)把服務(wù)器、網(wǎng)絡(luò)設(shè)備、液冷CDU的交期和土建機(jī)電施工排在一個時間軸上。當(dāng)然并行推進(jìn)的前提是設(shè)計凍結(jié)否則設(shè)備買回來發(fā)現(xiàn)接口對不上比晚到更麻煩。5.2 聯(lián)調(diào)測試階段順序和耐心比速度重要機(jī)房通電之后最容易出問題的不是單臺設(shè)備而是各系統(tǒng)之間的協(xié)同。我的建議是聯(lián)調(diào)測試按“供電優(yōu)先、制冷次之、網(wǎng)絡(luò)第三、存儲第四、算力最后”的順序來。第一步驗證供配電系統(tǒng)UPS和柴發(fā)切換是否正常、列頭柜支路開關(guān)是否對應(yīng)正確、電壓波動時設(shè)備會不會重啟。第二步驗證液冷系統(tǒng)在服務(wù)器上電前先把CDU、管路、冷板進(jìn)行打壓保壓測試通常要求24小時以上無壓降再檢查漏液傳感器是否都能正常報警。第三步驗證網(wǎng)絡(luò)用帶寬測試工具打滿所有端口確認(rèn)丟包和延遲在指標(biāo)范圍。第四步驗證存儲用并發(fā)讀寫工具打高負(fù)載檢查帶寬是否達(dá)標(biāo)、是否有報錯。最后才輪到GPU集群跑一個短時間的小規(guī)模訓(xùn)練任務(wù)逐步擴(kuò)大到全集群觀察是否有節(jié)點掉卡、通信超時、溫度漂移。很多團(tuán)隊恨不得一天把所有設(shè)備全跑起來結(jié)果一出故障根本定位不了是供電、散熱還是網(wǎng)絡(luò)問題。聯(lián)調(diào)階段多花一周后面運維階段能少花一個月。5.3 驗收指標(biāo)要和規(guī)劃目標(biāo)逐條對應(yīng)驗收不是“機(jī)房蓋好了能開門”就算結(jié)束而是所有當(dāng)初寫在需求規(guī)格說明書里的指標(biāo)逐條驗證通過才算完。建議驗收時至少核對以下表格驗收維度驗收項參考指標(biāo)計算性能GPU集群實際算力、穩(wěn)定性跑真實訓(xùn)練模型算力達(dá)到設(shè)計值多卡擴(kuò)展效率在合理范圍網(wǎng)絡(luò)質(zhì)量東西向帶寬、延遲、丟包率無阻塞帶寬達(dá)標(biāo)跨Leaf延遲在數(shù)微秒級以內(nèi)存儲性能聚合讀寫帶寬、檢查點保存時間達(dá)到設(shè)計指標(biāo)無明顯性能抖動制冷系統(tǒng)液冷供回水溫度、流量PUE實測溫度穩(wěn)定在設(shè)計范圍PUE接近可研預(yù)測值供配電冗余切換時間、電壓擾動耐受UPS切換無設(shè)備重啟柴發(fā)帶載正常運營監(jiān)控告警準(zhǔn)確率、自動化巡檢能力關(guān)鍵指標(biāo)歷史可追溯告警無漏報和大量誤報驗收前建議提前和供應(yīng)商約定好測試場景。因為不同廠商的基準(zhǔn)測試工具不一樣benchmark出來的數(shù)據(jù)可能差異很大。與其口頭爭論不如把測試場景固化到驗收文檔里雙方照著同一套流程執(zhí)行結(jié)果才有公信力。6. 常見問題與運維避坑交付不是終點運行期才是考驗6.1 高頻故障速查表智算中心投運后我遇到最多的故障類型相對固定把它們整理成一張速查表方便日常巡檢參考故障現(xiàn)象可能原因處理措施訓(xùn)練任務(wù)頻繁中斷節(jié)點間網(wǎng)絡(luò)擁塞、RoCE參數(shù)不合理檢查流控和擁塞參數(shù)必要時更換故障鏈路GPU掉卡或報XID錯誤固件問題、供電不穩(wěn)、散熱異常查看系統(tǒng)日志刷新固件無法修復(fù)則申請備卡替換機(jī)柜溫度持續(xù)偏高盲板缺失、氣流短路、液冷流量不足補(bǔ)齊盲板檢查冷熱通道封閉核對CDU流量液冷系統(tǒng)壓力緩慢下降快接頭滲漏、密封圈老化打壓保壓用漏液檢測試紙定位必要時更換快接頭存儲性能突然下降元數(shù)據(jù)節(jié)點壓力過大、碎片化嚴(yán)重擴(kuò)容元數(shù)據(jù)節(jié)點定期做數(shù)據(jù)分層遷移訓(xùn)練擴(kuò)展效率低并行策略和網(wǎng)絡(luò)拓?fù)洳黄ヅ湔{(diào)整通信后端優(yōu)化拓?fù)涓兄{(diào)度6.2 智算中心運維的三個基本功我自己的體會是智算中心運維和傳統(tǒng)機(jī)房運維有本質(zhì)區(qū)別。傳統(tǒng)機(jī)房很多工作圍繞“環(huán)境保障”展開智算中心卻要同時兼顧環(huán)境、硬件、操作系統(tǒng)和應(yīng)用性能運維人員至少要把三件事做扎實第一件事是熱管理臺賬。每臺服務(wù)器的進(jìn)風(fēng)溫度、GPU溫度、液冷出口溫度都要采集并留存形成趨勢曲線。溫度不是越低越好但要保證每條曲線沒有突變?nèi)魏瓮蝗簧仙贾档梅罩九挪?。第二件事是固件和?qū)動基線管理。GPU服務(wù)器的固件版本、驅(qū)動版本、網(wǎng)絡(luò)設(shè)備固件要保持統(tǒng)一、受控不能今天張三升級一個驅(qū)動、明天李四更新一個固件。我見過太多“奇怪故障”最后定位下來就是驅(qū)動版本不一致。第三件事是備品備件策略。GPU卡的故障率在數(shù)據(jù)中心里確實偏高電源、風(fēng)扇、液冷快接頭也算易耗件。建議按集群規(guī)模的3%到5%儲備備件小故障自己換大故障再走廠商流程能把故障恢復(fù)時間從幾天壓縮到幾個小時。6.3 給準(zhǔn)備啟動智算中心項目的團(tuán)隊一個兜底建議最后分享一點個人經(jīng)驗。我踩過最貴的坑是把液冷當(dāng)作“后期優(yōu)化項”項目都快開工了才補(bǔ)做液冷可研結(jié)果導(dǎo)致機(jī)房布局、電力容量和管路路由全部返工預(yù)算和工期雙雙超支。所以我特別強(qiáng)調(diào)智算中心建設(shè)的成敗在規(guī)劃階段就決定了七成。與其著急買卡、動土不如先把算力需求、功率密度、冷卻方式這三件事算清楚再去找設(shè)計院和供應(yīng)商談細(xì)節(jié)。我這幾年養(yǎng)成的習(xí)慣是每個新項目啟動前先建兩個非常簡單的電子表格一張是算力需求換算表把業(yè)務(wù)目標(biāo)逐步換算成卡數(shù)、機(jī)柜數(shù)和電力容量另一張是熱量和電量平衡表把IT負(fù)載、空調(diào)功耗、液冷功耗、照明等其他負(fù)載全部列進(jìn)去看總輸入功率和PUE目標(biāo)是否對得上。所有爭論到了表格上都變得異常清晰。這套方法不一定高級但真的能幫團(tuán)隊少走很多彎路。