算力加權在線率衡量的是甚麼
算力加權在線率（Hashrate-weighted uptime）是一種礦場可用性計算方式，它根據每部ASIC的算力對其在線時間進行加權，而非將每部機器視為可互換的單一單位。它衡量的是以參考算力加權的在線可用性：在選定期間內，礦場參考算力時長中屬於在線狀態的比例。它並不計算礦機在線期間性能下降的情況。
要計算它，需將每部ASIC的參考算力乘以其在線時間，將結果相加，再除以每部ASIC參考算力乘以完整量測期間之總和，最後乘以100。
本文將算力加權在線率作為一項明確定義的礦場可用性計算方式使用。營運者在匯報此數據時，應同時說明公式、參考算力及在線狀態判定規則，並附上諸如本地算力、礦池估算算力及拒絕率等量測數據。
為何按設備數量計算的在線率在混合礦機群中會造成誤導
以設備數量為基礎的簡單在線率——例如「20台礦機中有18台在線」——會將每部ASIC視為同等重要。在由相同型號機器組成的同質礦機群中，這種近似估算是合理的。但在包含例如250 TH/s與50 TH/s機型的混合礦機群中，情況則不然：一台高算力機器離線所移除的算力，遠多於一台低算力機器離線所移除的算力，即使兩者在統計上都只算作「一台機器離線」。
試考慮兩個停機持續時間相同的情境。若一台250 TH/s的ASIC離線四小時，損失的算力時長為250 × 4 = 1,000 (TH/s)·h。而需要五台50 TH/s的ASIC各自離線四小時，才能損失相同的1,000 (TH/s)·h（5 × 50 × 4 = 1,000）。以設備數量計算的在線率數字會將這兩種情境報告為截然不同——一台離線相對於五台離線——即使礦場損失的算力容量實際上完全相同。算力加權透過以算力時長而非設備時長來表達可用性，解決了這個問題。
計算公式
對於在同一期間T內被觀察的n部ASIC所組成的礦機群，算力加權在線率為：
算力加權在線率 (%) = [ Σ ( Href,i × t_online,i ) ] ÷ [ Σ ( Href,i × T ) ] × 100
其中：
- Href,i = 分配給ASIC i的參考算力，單位為TH/s
- t_online,i = ASIC i在該期間內的在線時間
- T = 總量測期間，對每部ASIC皆一致
- n = 納入計算的ASIC數量
分子與分母皆以算力乘以時間。當算力單位為TH/s、時間單位為小時時，單位為(TH/s)·h；這些單位在比值中會相互抵消，之後再乘以100以得出百分比。
另一種等價形式使用每部機器各自的在線率分數Ui = t_online,i ÷ T。Ui應以0到1之間的數值輸入——例如23/24 ≈ 0.9583，而非95.83：
算力加權在線率 (%) = [ Σ ( Href,i × Ui ) ] ÷ [ Σ Href,i ] × 100
這是一種加權平均，其中算力較高的機器對礦機群層級結果的貢獻，大於算力較低的機器。
實例演算
假設量測期間為24小時，並有三台ASIC：
| ASIC | 參考算力 | 在線時間 | 個別在線率 | 可用算力時長 |
|---|---|---|---|---|
| Miner A | 200 TH/s | 23 h | 95.83% | 4,600 (TH/s)·h |
| Miner B | 100 TH/s | 20 h | 83.33% | 2,000 (TH/s)·h |
| Miner C | 50 TH/s | 12 h | 50.00% | 600 (TH/s)·h |
| 礦機群總計 | 350 TH/s | — | — | 7,200 (TH/s)·h |
該期間可能的最大算力時長為(200 + 100 + 50) × 24 = 8,400 (TH/s)·h。因此算力加權在線率為7,200 ÷ 8,400 × 100% = 85.71%。
作為比較，三個個別在線率數字的簡單平均值為(95.83% + 83.33% + 50.00%) ÷ 3 = 76.39%。這個數字使Miner C——一台50 TH/s的機器——對結果的影響力，與Miner A（一台200 TH/s的機器）相同。對混合礦機群而言，這並不能代表以參考算力加權的在線可用性，而這正是算力加權數字所要呈現的內容。
選擇參考算力
此計算需要在整個報告期間內，對Href採用單一且一致的基準。實務上常見三種方法。
製造商額定算力使用各型號的銘牌規格。這適用於估算規劃可用性，或與已安裝的礦機群計劃進行比較，尤其是在機器接近出廠設定運作時。其主要限制在於，額定算力未必能反映特定機台的實際韌體、功耗模式或環境降額情況。
有紀錄的本地實測基準採用針對每部設備或型號、在其預定運作組態下記錄的場址專屬數值。當礦機處於降頻、超頻或在多種功耗模式下運作時，或當目標是衡量相對於場址正常運作（而非銘牌容量）的可用性時，這種方法更為適合。此基準應在整個報告期間內保持不變；若在期間中途變更而未將各期間分開處理，將使逐月比較變得不可靠。
當運作模式在報告期間內有意變更時，適合採用隨時間變化的參考算力。在此情況下，計算應按區間進行：
算力加權在線率 (%) = [ Σi Σk ( Hi,k,ref × si,k × Δtk ) ] ÷ [ Σi Σk ( Hi,k,ref × Δtk ) ] × 100
其中Hi,k,ref為ASIC i在區間k內所選用的參考算力，si,k在ASIC在線時等於1、離線時等於0，而Δtk為該區間的持續時間。這可防止某台機器目前設定的算力被錯誤套用到其採用不同設定的期間。
定義「在線」：資料來源及其限制
在套用此計算之前，需要有明確且有紀錄的規則，說明何謂「在線」。有多種資料來源可用以訂定此規則，而每種來源所觀察到的內容皆有所不同。
ASIC或礦場管理遙測數據可顯示設備連接狀態、本地算力、溫度及板級數據，但一台已連線的機器仍可能表現不佳，而非完全處於生產狀態。電力監測數據可顯示礦機或電路是否正在耗電，但單憑耗電量並不能確認其正在進行有效挖礦運算。礦池儀表板顯示收到的share數、礦池估算算力及拒絕率數據，但這些數字是以share為基礎計算的，並受限於礦池自身的平均化時間窗口。礦機離線警報則是依照礦池的警報邏輯，標記正常活動的中斷，但警報觸發的時間點未必就是停機的確切開始時刻。
一般而言，礦機或管理系統的遙測數據是以狀態為基礎計算在線率的更直接來源，因為它反映的是設備實際狀態，而非從share到達情況推算出的平均估算值。礦池數據則更適合用作交叉核對——用於確認提交的工作量是否確實到達礦池，這一區別將在下文進一步說明。
在線率並不等同於算力表現
礦機在整段期間可能都處於在線狀態，卻仍因熱降頻（thermal throttling）、算力板劣化或調頻設定不穩定而表現不佳。舉例而言，一台額定200 TH/s的ASIC在24小時內全程保持連線，但本地平均算力僅160 TH/s，此時其以狀態為基礎的在線率為100%，儘管其本地算力僅為所選定200 TH/s參考值的80%。
正因如此，不應將實際測得的本地算力直接代入在線率公式的分子，因為這樣做會改變該指標所代表的意義。另一種單獨的比較方式——將本地算力與參考基準值進行對比——可用於同時捕捉停機與降頻效應，但應明確標註其性質，而非將其當作在線率來報告。
礦池算力可作交叉核對，但不可取代在線率
在礦池挖礦模式下，礦池會根據收到的share來估算某個礦工或帳戶的算力，所使用的share目標難度低於比特幣網絡的區塊目標難度，正是這一點使礦機能夠以足夠頻繁的速率提交share以供測量（Bitcoin Developer Guide）。該估算值反映的是在礦池所述時間窗口內到達礦池的工作量；它並非對設備狀態的直接、連續測量。
ViaBTC幫助中心文件指出，其即時算力數字是根據過去10分鐘計算得出，而其日算力數字則是根據過去24小時計算得出（ViaBTC幫助中心）。為了得到有意義的交叉核對結果，應使用覆蓋相同礦機群組、且與在線率計算完全相同起訖時間的礦池數據，並明確註明所用時區。按日曆日計算的在線率報告，未必能與滾動式「過去24小時」的礦池讀數對齊；在可取得的情況下，應使用已對齊的歷史礦池數據。即便時間窗口一致，也應將兩項測量結果合併用於診斷分析，而非直接比較其數值大小：在線率是以狀態為基礎的可用性百分比，而礦池算力則是以share為基礎、以算力單位表示的估算值。同一份文件指出，網絡延遲、拒絕率、硬件配置及固件兼容性等因素，都可能導致礦池回報算力與本地算力讀數之間出現差距，而這是一個與在線率本身不同的診斷問題。
被拒絕的share應與在線率一併檢視，但不應從以狀態為基礎的在線率數值中扣除，因為拒絕率關乎提交至礦池的工作量，而與礦機在所選定的運作定義下是否在線無關。若使用礦池端通知功能——ViaBTC提供可配置的算力及拒絕率警報，並可透過電郵、應用程式推送及Telegram發送，另有礦機離線警報（ViaBTC幫助中心）——這些功能最好被視為觸發進一步調查的監測信號，而非用來取代帶時間戳記的礦機群組遙測數據。
常見計算錯誤
在實務中應用此計算方式時，常見以下幾類錯誤：
- 不論各台ASIC的算力高低，一律給予相同權重，這會重新引入該計算方式原本旨在避免的「設備數量」問題。
- 在不同機器之間混用額定算力與實測本地算力，卻未註明每台機器所使用的基準值為何。
- 使用不同礦機群組或不同時間窗口的礦池數據，包括使用滾動式「過去24小時」讀數，而該讀數與在線率報告的起訖時間並不對齊。
- 未查核本地遙測數據，便將短期的礦池端算力波動視為設備停機的證明。
- 將已連線但明顯處於降頻狀態的ASIC計為離線，或反之，卻沒有一套明文規定來界定「在線」的含義。
- 從在線率數值中扣除被拒絕的share，之後又另外將礦池算力偏低視為額外的停機扣減項目，造成對同一根本問題的重複計算。
- 在同一統計期間內，將運作模式或參考算力曾經改變過的礦機合併計算，而未按時間區間分段計算。
常見問題
算力加權在線率是否為礦池的官方指標？
在此，該術語指的是本文所定義的礦機群組可用性計算方式，而非歸屬於某個特定礦池的官方指標。任何採用此計算方式的報告，都應明確說明其所用公式、參考算力值及在線狀態判定規則。
能否以礦池估算算力取代ASIC遙測數據來計算在線率？
礦池估算算力反映的是在礦池所述時間窗口內收到的share量，可作為有用的交叉核對依據，但它並不等同於設備狀態，不應被重新標註為在線率。
應使用額定算力還是實測本地算力作為參考值？
兩種方式均可使用，惟須於報告期內記錄所採用的選擇並保持一致；當礦機並非以出廠設定運作時，採用實測的本地基準值通常較具代表性。
若某台 ASIC 在報告期內的運作模式發生變更，應如何處理？
應採用公式的區間版本，使每個已設定的算力數值僅套用於其實際生效的時段。
拒絕率偏高是否代表礦機群的在線率偏低？
並非必然如此。拒絕率關乎所提交份額（share）的結果，而在線率則關乎設備的連線狀態；兩者皆應分別檢視，不應以其中一項推論另一項。
參考資料
- Bitcoin Developer Guide，《Mining》，developer.bitcoin.org — https://developer.bitcoin.org/devguide/mining.html
- ViaBTC 幫助中心，《為什麼礦池顯示的算力比礦機的算力低？》— https://support.viabtc.com/hc/en-us/articles/7574354263183-Why-is-the-Hashrate-Shown-in-the-Mining-Pool-Lower-than-that-of-the-Mining-Machine
- ViaBTC 幫助中心，《如何設定算力或拒絕率通知》— https://support.viabtc.com/hc/en-us/articles/7207414336143-How-to-Set-Hashrate-or-Rejection-Rate-Notification