簡介

首先處理即時的安全隱患及共享基礎設施故障。然後，優先處理那些有可信把握能恢復至穩定運作、且具備足夠可回收營運利潤以證明維修成本合理的個別 ASIC 礦機維修項目。能快速且高把握完成的維修值得優先處理，但僅憑速度或銘牌算力本身並不足以作為將其移至維修隊列前端的理由。

管理一批 ASIC 礦機機群的營運方，不可避免地會累積一批離線待修機台。單純按停機時間最長，或銘牌算力最高來排序維修，會忽略以下問題：故障是否屬於硬件相關、是否與其他離線機台共享同一根本原因，以及維修是否能在合理期限內收回成本。

本框架是為場地營運方及維護團隊提供的實務決策輔助工具，並非正式審核程序。即時的安全隱患凌駕於以下排序之上：若明顯存在電氣故障或不安全的溫度狀況，應先將受影響設備處理至安全狀態，再繼續診斷。對於其餘機台，則依序進行：確認狀態、調查共同原因、估算可回收價值，並確定維修優先順序。

步驟一：確認 ASIC 確實處於離線狀態

在將某台機台加入維修隊列之前，應從連接的兩端核實其狀態。礦機端的指標包括本地算力顯示、核心或系統日誌、算力板偵測情況、風扇狀態、晶片與電路板溫度、電源供應狀態，以及網絡連接情況。礦池端的指標則包括礦工（worker）狀態、礦池在相若時間窗口內回報的算力，以及已提交份額（share）的拒絕率。

時間窗口之所以重要，是因為本地端與礦池端的數據計算方式甚少一致。ViaBTC 的說明文件指出，其即時算力顯示是基於過去 10 分鐘的數據，而其每日算力統計則反映過去 24 小時的情況；礦機的本地介面可能每隔數秒刷新一次，且不保證採用相同的平均計算方法（ViaBTC 幫助中心）。因此，一台剛重啟、間歇性斷線，或尚未完成完整 24 小時週期的礦機，即使沒有任何實際硬件故障，也可能顯示出明顯偏低的礦池端數字。兩者讀數之間的差異，應促使我們檢查平均計算窗口、連接穩定性及韌體相容性——而非單憑此點就斷定存在硬件故障。

拒絕率同樣需要審慎看待。偏高的拒絕率可能反映網絡延遲、韌體問題、礦池設定錯誤，或是真實的硬件問題，應結合日誌及連接檢查一併解讀，而非直接視為硬件狀況的衡量指標。

若礦池端出現數據差異，但沒有礦機端故障佐證，此情況仍屬於診斷性任務。在檢查確認存在需要維修的故障之前，不應將其列入硬件維修隊列。

步驟二：區分共同原因故障與個別故障

一旦確認某台機台確實離線（而非誤報），下一步要判斷的是：此故障是該機台獨有的，還是與附近其他機台共享的。若某故障同時影響同一機架、電路、交換器或散熱區域內的多台礦機，一般應先調查此類問題，再處理個別電路板層級的獨立故障。

此階段相關的檢查項目包括：stratum URL、礦工名稱及礦池連接設定；網絡交換器、路由器及纜線的狀況；配電及電源供應器（PSU）輸入；進風口溫度、排風路徑、積塵情況及風扇狀態；以及所安裝的韌體是否與礦機型號相符。BITMAIN 針對 ANTMINER 機型的故障排除文件列出了多項可能導致零算力或低算力的原因，包括網絡不穩定、控制板問題、風扇故障、PSU 故障、溫度保護、韌體異常、算力板缺失，以及晶片不穩定等（BITMAIN 支援）。其中多項原因——例如因氣流受阻而觸發的過熱保護，或是影響整排機台的交換器或共用上行鏈路故障——可能表現得像是多個不相關的電路板故障，但實際原因卻是共享基礎設施或營運條件問題。

一項能同時恢復多台礦機運作的維修，或是能消除可能導致進一步熱損或電氣損壞之條件的維修，一般應優先於修復單一高算力機台，即使該機台個別的預期收益較高。優先處理共同原因，亦可避免白白耗費精力去修復某電路板，結果因潛在問題再次出現而令其再度故障。

步驟三：評估個別維修是否值得進行

在處理完安全問題及共同原因故障後，可根據維修每台機台的經濟效益，對剩餘的離線機台進行排序。此步驟需要設定一個規劃期——即營運方預期在做出機群決策、託管變更、限電期或硬件更換之前，繼續運行該機台的期間。此規劃期是由營運方自行選定的營運假設，而非行業標準期限。

這裡提出一種組織此項比較的方法，作為實務性決策輔助工具，而非標準的挖礦關鍵績效指標（KPI）：

預期維修價值 = p × H × m − C_repair

此公式估算的是，相較於在同一規劃期內讓該機台持續離線，進行維修所帶來的增量價值：

• p 是指維修令機台恢復穩定運作的估計機率。\n- H 是指若修復成功，在規劃期內可提供的生產性運作時數，當中已扣除診斷、維修、運送及重新安裝所需時間，以及預期的非運作期間。不應因同一項已反映在 p 中的維修失敗風險而再次扣減 H。\n- m 是指每生產性運作時數的估計增量淨營運利潤率。\n- C_repair 是指維修嘗試的預期全部成本，包括零件、外部維修費用、運送及（如適用）人工費用。即使維修失敗，所產生的成本亦應計入。\n\n全程應使用同一種貨幣。例如，若 m 以每小時美元計算，則 H 須以小時為單位，而 C_repair 須以美元計算。在此簡化模型下，一次失敗的維修並不會產生任何已回收的營運利潤。若計算結果為正數，即支持進行維修（相對於讓礦機維持離線狀態）；但這並不代表維修必然優於轉售或更換礦機。\n\n營運利潤率本身可按以下方式估算：\n\nm = R_net − C_electricity − C_other incremental\n\n此處 R_net 是指扣除礦池手續費後，每生產性運作時數的預期挖礦收入；C_electricity 是指該機台每生產性運作時數的實測或預期電力成本；而 C_other incremental 則僅於託管或散熱成本會因機台是否運作而實際改變時，才計入每生產性運作時數的相關成本。三項輸入數值必須採用相同的貨幣及按小時計算的基準。無論礦機狀態如何都須支付的託管費用，不應在此重複扣除；同樣，已反映在 R_net 中的礦池手續費，亦不應再次扣除。\n\n結算方式會影響 R_net 的估算方法。根據 ViaBTC 的說明文件，PPS+ 模式中屬於 PPS 區塊獎勵部分收取 4% 手續費，而屬於 PPLNS 交易手續費部分則收取 2% 手續費；獨立的 PPLNS 模式則統一收取 2% 手續費（ViaBTC 幫助中心）。應將各項手續費率套用於其對應的收入組成部分。若要為 PPS+ 使用單一有效手續費率，應按各組成部分佔預期總收入的比例作加權計算，而非直接相加。應採用與規劃期相符的預期收入估算；短期的 PPLNS 收入可能波動，不應被視為保證的每小時收入來源。\n\n當技術人員時間（而非零件或成本）才是限制因素時，營運單位可採用「預期維修價值除以所需技術人員工時」作為同等優先級工作之間的決勝指標。此方法應作為安全及共因故障分流原則的補充，而非取代。即使是快速維修，仍須具備可接受的經濟效益論證，方能獲列為一般恢復性維修工作的優先項目。\n\n## 實用優先次序框架\n\n下表總結了上述各項考量如何轉化為實際的工作排程。此表為初步架構，而非固定規則；有關成本、停機時間或信心水平的具體門檻，須視乎 ASIC 型號、電力及託管條款、維修可得性，以及該營運單位本身的規劃期而定。\n\n驗證程序是個別硬件維修進入此排程前的必經關卡。若礦池端出現異常卻無相應故障佐證，應維持在診斷階段，而不應直接歸入低優先級的維修層級。\n\n| 優先層級 | 故障類型 | 理據 | 典型下一步行動 |\n|---|---|---|---|\n| 1. 即時安全問題 | 不安全的散熱狀況或電氣故障 | 須於常規診斷或恢復作業前優先處理 | 使受影響設備安全化，並在進一步作業前隔離危險源 |\n| 2. 共用基礎設施問題 | 交換器、共用上行鏈路、配電單元（PDU）或散熱系統故障，影響多台礦機 | 修復共用依賴項目可能一併恢復多台礦機，並防止故障重複發生 | 找出並修正共同成因，然後驗證受影響的機台 |\n| 3. 快速、高信心且具經濟效益的恢復作業 | 鬆脫線纜、風扇故障、礦池設定錯誤、韌體版本不符，或已知的電源供應器（PSU）故障 | 當預期效益足以證明成本合理時，可迅速令機台恢復運作 | 視情況修正連接、設定或韌體，或更換故障元件；並以日誌及礦池端活動紀錄加以確認 |\n| 4. 高價值個別維修 | 離線機台具備有利的利潤率及可信的維修途徑 | 修復該機台可在規劃期內回收可觀的營運利潤 | 取得維修報價，並估算週轉時間、成功機率及預期維修價值 |\n| 5. 條件式維修或退役評估 | 較舊、效能較低，或反覆故障的機台 | 維修成本可能無法在規劃期結束前回收 | 比較維修與讓機台維持離線、更換、轉售，或作為零件來源等各項方案 |\n\n一般維修層級並非單純以維修速度作絕對排序。若某項較耗時的工作所能回收的價值明顯更高，則可能值得優先於快速維修；應以經濟效益估算及實際資源限制，作為解決此取捨的依據。\n\n## 維修或更換：為何機隊世代（Fleet Generation）至關重要\n\n硬件世代之所以重要，是因為按該場址的電價計算，更高效的替代機型可能帶來更佳的經濟效益。然而，替代機型的存在本身，並不會直接降低現有礦機的營運利潤率。只有當舊機台的收入或營運成本出現變化時——例如每單位算力的收入下跌、電價上升，或機台運作表現惡化——其利潤率才會隨之改變。\n\n應以現有機台的實測表現及該場址的實際電力成本，估算維修的價值。然後在相同的規劃期內比較維修與更換方案，並計入購置及安裝成本、週轉時間、基礎設施相容性，以及各方案相關的任何轉售價值。與讓機台維持離線相比，若預期維修價值為正數，是一項有用的初步檢驗，但最佳的機隊決策仍取決於現有的可行方案。\n\n## 結論

維修排序應優先處理即時危害、確認哪些機台確實需要處理、調查共同成因，然後再根據可回收價值與所需資源為個別維修排定優先次序。這樣可避免將測量差異誤判為硬件故障，也可避免以忽視共用基礎設施與實際維修經濟效益的順序來維修機台。

具體數字會因場地、硬件世代及結算方式而異。決策原則仍然實用：優先處理在營運時限內能證明其成本合理的可信修復，並將不確定或邊際效益的維修與現有替代方案進行比較。

常見問題

礦池端算力較低是否一定代表硬件故障？

不一定。礦池端數據與礦機端數據通常是在不同時間窗口內計算，並以不同頻率刷新，因此僅憑數據差異並不能確認存在實際故障。應先確認兩者的時間窗口是否可比較，並檢查拒絕率、連接狀態及日誌記錄，然後才拆開硬件檢查。

是否應該永遠優先維修單一高算力的 ASIC，而非多部低算力機台？

不一定。若多部低算力機台存在共同成因，例如交換器故障或影響整排機架的散熱問題，處理該共同成因可恢復更多總算力，並防止進一步損壞，這可能使其優先於單一高算力機台的個別維修。

預期維修價值公式是否為礦業的標準指標？

不是。這只是一個簡化的決策輔助工具，用於在選定時限內比較維修候選方案與讓機台持續離線之間的優劣，並非既定的礦業關鍵績效指標。營運者應根據自身成本與營運假設調整其輸入參數，並應另行評估轉售或更換的可能性。

結算方式是否會影響維修經濟效益的估算方式？

會。不同的結算方式在手續費結構、發放時間及收益波動性方面各有差異。應將手續費套用於相關收益組成部分，並使用符合規劃時限的預期收益估算，而非假設近期收款代表有保證的每小時現金流入。

參考資料

• ViaBTC 幫助中心，「為什麼礦池顯示的算力比礦機的算力低？」
• ViaBTC 幫助中心，「收益是如何計算的？」
• BITMAIN 支援中心，「ANTMINER 故障排查與解決方案」