💡 快速答案:GPU Servers日常維運要監控哪些指標?
三件事:用nvidia-smi與DCGM監控溫度(告警設80°C)、功耗與ECC錯誤;機房進風維持18到27°C;建立故障SOP,掉卡先記錄再重置。不想自組團隊,戰國策等託管方案月租內含維運,故障4小時更換。
GPU Servers的維運說穿了三件事:看得到、壓得住、修得快。看得到是監控——nvidia-smi與DCGM把溫度、功耗、ECC錯誤攤在儀表板上;壓得住是散熱與功耗管理,讓卡不降頻、電費不失控;修得快是故障SOP,掉卡、驅動出包時照表操課,不用半夜猜原因。這篇把三件事的實作細節,加上我們在機房現場累積的判斷經驗,一次整理給你。
GPU Servers監控基本盤:nvidia-smi先看懂,再上DCGM
nvidia-smi是每個維運工程師的第一個工具。基本輸出先盯四個欄位:GPU溫度(負載中60到80°C屬正常)、功耗(H100 SXM上限700W)、GPU使用率、記憶體用量。進階用法:nvidia-smi dmon看每秒刷新的趨勢;nvidia-smi -q -d ECC檢查錯誤計數;nvidia-smi topo -m確認NVLink拓撲是否完整——8卡機少一條鏈路,多卡訓練效能可能直接掉兩成,而且不看拓撲根本不會發現。
把常用檢查包成腳本排程執行:每小時記錄一次溫度與ECC計數、每天比對一次拓撲與卡數、每週彙整一份健康摘要送進團隊頻道。這些都是十行內的shell腳本,卻能把「不知道什麼時候壞的」變成「幾點幾分開始異常」,對照工作負載紀錄,九成問題的因果關係一眼就看得出來。告警通道建議至少兩條,即時訊息加email,重大事件再加電話——單一通道漏接的機率,比多數團隊想像的高。
單機看nvidia-smi夠用,一個機櫃以上就該上DCGM(Data Center GPU Manager)。標準組合是dcgm-exporter把指標吐給Prometheus、Grafana畫儀表板、Alertmanager發告警。DCGM還提供主動健康檢查:dcgmi diag的分級診斷可以在上線前抓出體質不良的卡,比等它在訓練跑到第三天時暴斃便宜太多——一次8卡叢集的中斷重跑,浪費的算力就值好幾千元。
指標要留歷史。溫度、功耗、使用率、ECC計數至少保存90天,月報整理各卡的溫度分布與錯誤趨勢——同一台機器裡永遠比別人熱5度的那張卡、ECC計數緩慢爬升的那張卡,就是下一個要壞的。維運的價值不在事故後修得快,在事故前就把嫌疑犯圈出來,趁排程空檔先處理。
告警閾值的實務建議
溫度80°C警告、85°C嚴重,多數資料中心卡在85°C上下開始降頻;不可修正ECC錯誤出現1次就告警;功耗長時間貼著上限、使用率卻異常低,常是程式卡死或資料管線塞住的訊號。閾值不是設完就忘,每季拿歷史資料回頭校一次,誤報率太高的告警,很快就沒有人看,那比沒有告警更危險。

溫度與功耗管理:散熱要用機房層級思考
一張H100 SXM功耗700W,8卡機加上CPU、記憶體與風扇,整機輕鬆超過10kW——等於四台家用冷氣全速運轉的熱量,塞在一個機櫃裡。散熱要從機房層級想:進風溫度依ASHRAE建議控制在18到27°C,冷熱通道確實隔離,空櫃位裝滿盲板,不然熱風回流會讓最上層的機器永遠比別人熱5度,故障率也跟著高一截。
機櫃功率密度要先跟機房對齊。一般商辦機房單櫃供電3到5kW,GPU機櫃動輒15到20kW,放進去前要確認供電迴路、PDU規格與該區的散熱能力;硬塞的結果是全櫃跳電或長期過熱。這也是GPU託管要挑專門機房的原因——供電與散熱是建築等級的限制,後天補強的成本非常高。
功耗管理有兩個實用手段。一是power capping:用nvidia-smi -pl把單卡上限從700W壓到500W,多數訓練任務效能只掉5%到10%,散熱壓力與電費卻明顯下降,機房供電吃緊時是救命招。二是排程錯峰:台電高壓時間電價的尖離峰價差可觀,把每天8小時的批次任務移到夜間,一台8卡機一年電費能省下數萬元。自建的話,一台8卡機滿載月耗電約7,200度,以工業電價每度約NT$4計就是近3萬元,還沒算空調——這也是很多公司評估後選擇託管或租用的原因,像戰國策這類供應商的GPU主機方案,月租直接內含電力與空調,總帳好算得多。
濕度與粉塵常被忽略:相對濕度建議40%到60%,太乾容易靜電、太濕會凝結;濾網每季更換,風扇積塵會讓同樣轉速下的散熱效率悄悄變差,等你發現溫度曲線上移,通常已經髒了半年。行有餘力,把每卡功耗與任務對應起來算單位成本:同一個訓練在不同批次大小下的每epoch耗電,常能找到快10%又省8%電的甜蜜點,長期跑的任務值得花一個下午調。
故障排除一:ECC錯誤與記憶體問題
HBM3記憶體出錯是GPU老化最常見的訊號。ECC錯誤分兩種:可修正(correctable)是虛驚,硬體自己救回來,但要記錄趨勢,短期內快速累積就是預警;不可修正(uncorrectable)會讓行程直接當掉,出現一次就要嚴肅對待。H100支援row remapping,壞掉的記憶體列會由備用列取代,nvidia-smi -q裡的remapped rows欄位看得到累計數字——備用列用罄,這張卡就到了該送修的時候。
處置SOP建議三步:記錄(時間、Xid代碼、當下的工作負載)、重置(先試GPU reset,不行就排程重開機)、觀察(72小時內重發就申請RMA或要求供應商換卡)。租用方案要確認合約有沒有把「不可修正ECC錯誤累計達標即視為故障」寫進換卡條件,避免和供應商在「卡還能用啊」的認知落差上耗時間——那種來回,一次就是兩三個工作天。
新機上線與長假前,建議跑一輪burn-in壓測:gpu-burn或同類工具連續24小時滿載,搭配dcgmi diag完整診斷,把體質不良的卡在沒有工作負載的時候逼出來。我們的經驗是新到貨的卡約有1%到2%會在burn-in階段暴露問題,這種卡進了生產環境,就是未來三個月的定時炸彈。
故障排除二:掉卡、Xid錯誤與驅動地雷
「掉卡」是機房最讓人心跳加速的詞。症狀是nvidia-smi突然少一張卡,dmesg出現Xid 79(GPU has fallen off the bus),常見原因依機率排:PCIe或SXM接觸不良、供電不穩、卡本體故障。處理順序:重開機、重插拔(託管環境請機房人員執行)、換槽位交叉測試,三步內能定位九成問題。交叉測試的判讀:同一槽位換卡後仍掉,問題在主機板;同一張卡換槽位仍掉,問題在卡本身。
驅動問題多半發生在「手癢升級」之後。生產環境的GPU實體主機有一條鐵律:驅動與CUDA版本鎖定,升級前在測試機驗證兩週;韌體(VBIOS、BMC)只在原廠公告修復重大問題時動,沒事不要碰。多卡機還有fabric manager要顧,它負責NVLink與NVSwitch的初始化,服務沒起來,卡看得到但NCCL多卡通訊跑不了,900GB/s的NVLink頻寬直接歸零。用容器把CUDA runtime跟應用綁在一起,主機只管驅動版本,相容性矩陣可以簡單一半。
多機叢集還有一層網路故障要認識:NCCL逾時、all-reduce卡住、跨節點頻寬掉到個位數GB/s,問題常出在網卡韌體、交換器埠或線材,而不是GPU本身。排查順序:先用iperf3驗基礎頻寬,再用NCCL tests驗集合通訊,分層定位,不要一開始就拆卡。
還有一類「假故障」值得認識:溫度降頻造成的效能衰退。訓練速度莫名慢兩成,卡沒壞、程式沒改,查nvidia-smi -q -d PERFORMANCE發現thermal slowdown作用中——回頭看,八成是空調或濾網的問題。先量體溫再懷疑硬體,是GPU維運的基本素養,也省下很多冤枉的RMA來回。
一個實際案例:客戶的8卡機每逢週三凌晨訓練就變慢,查了兩週,懷疑過驅動、NCCL、儲存,最後發現是機房同區另一租戶固定在那個時段跑滿載,空調短暫追不上,進風溫度升了4度、卡群集體降頻。解法很無聊——跟機房協調錯開排程、補一組盲板,效能就回來了。維運的難,常常不在技術深度,在於願不願意把時間軸攤開來對。
GPU Servers的備援與備份策略
訓練任務的備援核心是checkpoint:依任務時長設定間隔,大型訓練建議每30到60分鐘存一次,checkpoint寫到獨立於GPU主機的儲存,壞卡重跑時最多損失一個間隔的算力。寫入時間也要留意:模型越大存越久,搭配非同步寫入或分段儲存,才不會讓存檔本身吃掉5%的訓練時間。推論服務靠多副本與健康檢查:至少兩個replica分散在不同實體機,load balancer健康檢查抓到異常自動摘除流量,單卡故障就不會升級成服務中斷。
資料備份守3-2-1原則:三份副本、兩種媒介、一份異地。範圍要涵蓋模型權重、訓練資料、程式碼與環境定義(Dockerfile、套件清單)——我們看過重訓一次要價數十萬的模型,因為只備份了資料、沒備份前處理程式碼,整組流程重建花了兩週。異地那份放物件儲存或另一座機房,頻寬允許就每日增量。
儲存的選型也影響備援設計:訓練資料放共享儲存(NFS或平行檔案系統),checkpoint與模型放物件儲存,系統碟壞了就重灌、資料不落在本機——把運算節點當成可拋棄的單元,任何一台掛掉都能在30分鐘內於另一台重建,這是把MTTR壓到最低的架構性做法。
備份沒演練等於沒備份。每季做一次還原演練:從異地副本把模型與環境完整拉起來,量測實際的RTO與RPO;每半年做一次故障演練,模擬單卡故障與整機斷電,驗證告警、切換與通報流程真的會動。演練的成本是半天工時,換到的是事故當下不用猜。
硬體備援層面,自建AI實體主機要自備備品卡(占總卡數3%到5%)、備用電源模組與風扇;租用則把這題外包給供應商,重點變成合約——4小時更換時效、備品保證、99.9% SLA,白紙黑字簽清楚,比機櫃裡多放兩張卡實在。
常見故障速查表與升級時機
把現場最常見的狀況整理成速查表,適合貼在維運頻道的置頂:
| 症狀 | 可能原因 | 初步處置 | 升級時機 |
|---|---|---|---|
| 訓練變慢兩成 | 溫度降頻 | 查溫度與空調、清濾網 | 降頻持續超過1天 |
| nvidia-smi少一張卡 | 掉卡(Xid 79) | 重開機、重插拔 | 重現2次即要求換卡 |
| 行程隨機當掉 | 不可修正ECC | 記錄、重置、盯remapped rows | 72小時內重發 |
| 多卡效能異常低 | NVLink或fabric manager | 查topo -m與服務狀態 | 鏈路實體故障 |
| 卡在但程式跑不動 | 驅動或CUDA版本不合 | 回滾版本、查dmesg | 回滾後仍無效 |
升級的判斷原則:能用軟體手段復原的自己處理;涉及實體操作、或同一問題重複發生的,交給供應商或原廠,不要讓工程師在機房外隔空抓藥。把問題升級出去時,附上這包資訊能把來回次數砍半:
- 事件時間軸:發生、發現、已嘗試的處置與結果
- nvidia-smi -q完整輸出與dmesg裡的Xid紀錄
- 當時的工作負載描述、可否重現
- 環境版本:驅動、CUDA、框架、韌體
託管與租用的客戶,記得把每次事件的時間軸留存下來——通報時間、回應時間、恢復時間。這些紀錄在SLA賠償主張與續約談判時,都是你手上最硬的籌碼。

GPU 主機常見問題 FAQ
GPU Servers委外維運要多少錢?
台灣託管與租用方案多把維運內含在月租:H100單卡月租約NT$50,000、8卡叢集約NT$350,000,涵蓋機房電力、散熱、監控與4小時硬體更換。自建則要另計電費與至少一名維運人力的成本。
8卡GPU主機一個月電費多少?
一台8卡H100滿載約10kW,月跑720小時耗電約7,200度,以工業電價每度約NT$4計約NT$28,800;加上空調換算,實際上看4萬元。租用方案通常內含電費,自建務必把這筆列入總成本。
nvidia-smi要看哪些欄位?
四個核心欄位:溫度(負載中60到80°C正常)、功耗(H100 SXM上限700W)、GPU使用率、記憶體用量。進階用dmon看趨勢、-q -d ECC查錯誤計數、topo -m驗NVLink拓撲是否完整。
GPU出現ECC error要怎麼處理?
可修正錯誤先記錄趨勢即可;不可修正錯誤依SOP:記錄Xid與當時負載、執行GPU重置或重開機、觀察72小時。同時盯remapped rows,備用記憶體列用罄或錯誤重發,就申請換卡或RMA。
GPU溫度多高算異常?
資料中心卡負載中60到80°C屬正常,建議80°C警告、85°C嚴重告警,多數卡在85°C上下開始降頻。機房進風溫度依ASHRAE建議維持18到27°C,冷熱通道隔離做好,上層機器才不會長期偏熱。
DCGM和nvidia-smi差在哪?
nvidia-smi適合單機即時查看;DCGM是機房等級方案,dcgm-exporter串Prometheus與Grafana做長期趨勢與告警,還有dcgmi diag主動診斷,上線前可篩出不良卡。規模到4到8台以上建議直接上DCGM。
GPU主機自己管和託管怎麼選?
自管適合有專職團隊且長期滿載的公司;託管把散熱、電力、備品、4小時更換都包進月租。一名資深維運工程師年薪破百萬,規模在16卡以下的團隊,託管通常更划算,也少揹半夜的告警。
租GPU Server時SLA要載明哪些維運條款?
四個數字:30分鐘內回應、1小時內判定、4小時內完成硬體更換、99.9%可用率。另加備品比例3%以上、不可修正ECC累計視為故障、賠償自動折抵月租,少一項,實際保障就打一次折。
掉卡(Xid 79)是什麼原因造成的?
Xid 79代表GPU從匯流排上消失,常見原因依序是接觸不良、供電不穩、卡體故障。處置:重開機、重插拔、換槽位交叉測試定位;同槽換卡仍掉是主機板問題,同卡換槽仍掉就送修那張卡。
台灣機房的散熱條件對GPU壽命有影響嗎?
有。台灣夏季濕熱,機房空調與濕度控制(建議40%到60%)是關鍵,進風溫度偏高會讓風扇轉速與故障率同步上升。選有N+1空調備援、ISO 27001管理的台北機房,長期故障率明顯較低。
延伸閱讀
戰國策 GPU 主機:領先的 AI 算力服務平台
NVIDIA H100 GPU 主機(GPU Server)台灣機房直供:月租 NT$15,000 起、2 小時部署、99.9% SLA、24 小時中文支援。從 MIG 切割到 8 卡叢集,AI 訓練與推論的實體主機方案一次到位。