AI 數據中心優先考量的是電力與冷卻（水路）。電要安全到櫃、留有保護與餘裕；冷卻要選對方案（RDHx／液冷），並把供回水、排水、水質、偵漏與配管／維保動線一次想清楚；其後才是網路、儲存與叢集上線。
多數情況的做法，是在現有機房裡先把一小區升級成高密度專區，讓它扛得起更高瓦數的 GPU 叢集——電力更大、散熱更貼近熱源、網路更粗、儲存更快、運維更精細：
- 電力要更大（像工廠用電，三相大電直達機櫃）
- 散熱要更貼近熱源（先「水冷背板」RDHx，不夠再上直接液冷）
- 網路要更粗更快（機器彼此大量互傳，常見 400/800G）
- 儲存不只看容量，還要看出菜速度（吞吐 GB/s）
- 運維要把每張 GPU 用到位，不閒置、不悶熱
若計畫導入液冷或單櫃密度將大幅提升，需同步評估重新設計／新建，把水路、載重與消防一次做到位。
接下來用 5 個生活比喻，3 分鐘就懂差在哪、要不要重做、怎麼分階段升級。
1. 電力＝家用插座 vs 工廠插座
一般機房像住家插座；AI 專區像工廠插座，要把三相大電（例：415V）拉到每個機櫃，線路更粗、PDU 更穩。
重點在於：插得上去還不夠，還要確定不會把那一櫃的電吃到超標。最簡單的作法就是預留大概兩到三成的空間，真的出狀況它會自己跳開，不會整排一起掛。
2. 散熱 ＝ 冷氣房 vs 水冷空調房
傳統機房多半是吹冷風；AI 專區改成「把熱帶走」的做法，通常先在機櫃背後加一片像水冷散熱器的背板（RDHx），不夠再把冷卻液接到晶片旁邊（直接液冷 DLC）。
好處在於：效率高、風扇不用狂轉，現場更安靜、更省電、粉塵更少。
3. 網路 ＝ 小巷弄 vs 高速公路
一般網站是人去找資料，流量比較單向；AI 訓練則像是一堆機器大量互傳資料，量大傳輸的通道就要夠大，才能乘載得住不塞車。以道路來比喻的話，就像是要把小巷子換成高速公路（400G/800G），而且路權要調好，才不會塞車或掉資料（通常會把「不塞車」的設定先調好）。
4. 儲存 ＝ 冰箱有多大 vs 出菜有多快
很多人直覺是「容量越大越好」，但 AI 在意的是吞吐（GB/s）與穩定度，「一次能送多少、會不會卡」；常用像 BeeGFS/Lustre 這種平行檔案系統配 NVMe，讓很多人同時拿資料也不會排隊，就像廚房能一直出菜不用排隊等待。
5. 運維 ＝ 健身房器材利用率
GPU 很貴，閒著就是浪費；把它想成健身房的跑步機／重訓架：數量有限，用「訂場系統」（Slurm／Kubernetes 排程）決定誰先上機，現場空調通風（RDHx／液冷＋氣流）要跟上才不會過熱降速，櫃台看板（Grafana／Prometheus 監控）告訴我們哪台空、哪台出狀況，並且固定做保養（韌體／驅動更新與健檢）。把排程、散熱、監控、維護這四件事做好，目標很簡單，就是讓每張卡都有事做、輸出穩定。
▌公司需要「重做」嗎？
通常不用。最保守、也最實際的做法是：先切 4～8 櫃出來當 AI-Ready 區，把電力拉好、先用 RDHx 把散熱上限撐起來，網路和儲存先做分區跟最小升級。第一批應用跑起來之後，再決定要不要上液冷、要不要擴到更多櫃，或是搭配雲端做混合。
如果用步驟看，先切 4–8 櫃做 AI-Ready 區後：
- 415V 到櫃＋智慧 PDU
- 先上 RDHx，再評估液冷
- 網路與儲存分區，先做最小可行升級
- 上線後再視負載擴編
▌Cloudmax 匯智如何幫您
2 週健檢（量電/看熱/估網）→ 90 天上線計畫（分期投資、不停服務）→ 代管服務（叢集、監控、SLA）。
- 首先進行健檢：看電力餘裕、熱點、網路拓樸，評估目前的情況。
- 安排一個 90 天上線計畫：分區分時做，不影響現有服務。
- 代管叢集：幫您把排程、監控、平行檔案系統都顧好，算力買了就用得到。
- 效率與永續：建立 PUE/WUE 的量測與記錄機制，提供簡單月／季摘要；若需對應 ESG 披露格式，再行確認。
▌下一步怎麼評估與決策
1. 網路跟儲存如何評估升級？
先做三件事：
- 看症狀：
GPU 常「閒著等資料」、任務排很久、載資料特別慢，多半是 I/O 在卡。 - 做小測試（不需要大工程）：
主機 ↔ 主機傳大檔，看內網實速與抖動（判斷是否塞車）。
主機 ↔ 資料倉讀寫一批檔案，看多人同時是否變慢（判斷儲存是否卡）。 - 先做最小改動：
把 AI 區分區，先拉100–400G主幹（預留到 400/800G），放一座共用快倉（平行檔案系統＋NVMe 快取），跑一段再決定下一步。
2. 規模不大，要做到多快才「夠用」？
照「先能跑、再變快」原則。4–8 櫃起步多以100–400G骨幹就順跑；任務變多再往400/800G擴。儲存先用共用快倉解「同時多人拿資料」的痛點。
3. 會不會影響現在的服務？
規劃採分區／分時施工，核心服務照常運作。
4. 液冷是什麼？一定要嗎？
液冷 ＝ 把冷卻液帶到晶片附近把熱帶走；多採雙回路＋快拆接頭＋漏液偵測。不是每案都要，用後門熱交換器（RDHx）撐到一定密度，再評估是否導入 DLC。
*液冷，DLC，Direct liquid cooling
5. 液冷會很耗水嗎？
多數是閉環循環，不是一直用新水；在許多情境反而比高風量空冷更節水。
6. 需要 InfiniBand 嗎？乙太 RoCE 可以嗎？
多數起步案 RoCE 就夠；規模很大、延遲超敏感再考慮 IB。簡單選法：
- 要快起步、沿用乙太與控成本 → RoCE。
- 規模上百～上千卡、同步很吃延遲 → IB。
不確定就RoCE 起步，預留升級到 400/800G 或 IB 的空間。
7. 升級後怎麼驗收「有效」？
看三指標：GPU 平均利用率是否明顯上升（如 50–60%→70%+）、尖峰排隊時間是否下降、是否還會因過熱或讀寫慢而降速／失敗。
8. 我們應該先準備哪些資料讓廠商評估？
機房平面圖、到櫃電力與餘裕、散熱作法、既有交換器／佈線、現行儲存拓撲（誰在用＋同時人數）、近期常見性能抱怨與尖峰時段。
名詞解釋：
- RDHx（後門熱交換器）
機櫃後門的水冷背板；冷卻水在背板把機櫃排出的熱風帶走，伺服器本體仍為空冷（風扇＋散熱片），屬於機櫃級／間接液冷。適合在現地快速改造、少動伺服器、先把單櫃上限拉高的情境使用。
優點是好改造、不中斷，常見可把單櫃能力提升至約 20–40 kW（部分主動式產品可更高）；限制與風險則是仍受限於機箱風路與風扇功耗，極高密度時會吃力，背板、水路與偵漏系統需要持續維護。
- 直接液冷 DLC（Direct Liquid Cooling）
把冷卻液直接帶到晶片（CPU/GPU 冷板）散熱，並含歧管、管路、快拆接頭與CDU 等配套，屬於伺服器級／直接液冷。當目標密度> ~50–80 kW/櫃、單機熱通量很高、或希望更安靜/更省電/可做熱回收時會採用此方式。
優點是貼近熱源、散熱能力強、風扇功耗低、晶片溫度更穩，可支撐60–100+ kW/櫃等高密度，熱回收也較容易；限制與風險則是需對應機型（DLC-ready）、水質管理與偵漏、定期維護；配管空間、排水與維保動線都要事先規劃。
- CDU（冷卻分配單元）
IT 側與大樓側水路之間的換熱／控溫中介站（含泵、換熱器、過濾與控制），讓 IT 區域有獨立水溫與流量。用於導入 DLC 或多櫃 RDHx 時，用來隔離 IT 水路與大樓水路、提升安全與維護性。
優點是水路隔離降低風險、可控供回水溫與流量、易監控告警；限制與風險則是占空間、要用電與維保，需規劃旁路／冗餘（N+1）、排水與噪音，安放位置與施工動線要先定。
- 415V 三相到櫃（大電到櫃）
像工廠用電，把較高電壓直接送到機櫃，搭配智慧 PDU與選擇性保護設計，讓機櫃能「插得上也用得住」。AI 專區、高電流負載，需要提高效率、降低線損、讓單櫃容量上得去時，採取此方式。
優點是效率佳、導線線徑可控、易擴充（常配合母線槽），可承載更高瓦數；限制與風險則是需做保護協調/標示並符合在地規範；試車/驗收要確實，注意電弧故障與操作安全。
- 平行檔案系統（＋NVMe 快倉）
多人同時讀寫也不塞的共用儲存，把資料分散成多條「車道」，常搭配 NVMe 做快取，重點是把吞吐（GB/s）拉高、讓 GPU 不用等資料。
- RoCE（乙太 RDMA）與 InfiniBand（IB）
兩種高速、低延遲的內部網路做法（都可達 200/400/800G 等級）。RoCE 易與既有乙太整合、供應商選擇多；IB 低延遲穩定、訓練同步表現好。
- Slurm／Kubernetes（GPU Operator）
多人共用叢集的排程與資源管理；像行事曆/訂場，決定哪個任務用哪張 GPU、用多久、優先順序。GPU Operator 會自動部署 NVIDIA 驅動、CUDA 工具、監控元件，維運更省力。
- GPUDirect Storage（GDS）
把資料從儲存系統直接搬到 GPU 記憶體的方案，減少經過 CPU/主記憶體的繞路。
歡迎轉載！請見：轉載原則。
Image by Alexandra_Koch from Pixabay
