瞭解運算單元

BigQuery 運算單元是 BigQuery 用來執行 SQL 查詢、Python 程式碼或其他虛擬運算單元，也是作業類型。 執行查詢時，BigQuery 會自動判斷查詢使用的運算單元數量。使用的運算單元數量取決於處理的資料量、查詢的複雜程度，以及可用的運算單元數量。一般來說，運算單元越多，就能執行更多並行查詢，複雜查詢的執行速度也會更快。

以量計價和以容量為準的計價方式

所有查詢都會使用運算單元，但您可以選擇兩種計費方式：以量計價模式或以運算資源為準的計價模式。

根據預設，系統會採用以量計價模式收費。採用這個模式時，系統會根據各項查詢處理作業的資料量 (以 TiB 為單位) 向您收費。使用隨選模式的專案須遵守每個專案和每個機構的運算單元限制，並具備暫時爆量功能。對於採用隨選模式的大多數使用者來說，運算單元容量上限已綽綽有餘。不過，視工作負載而定，使用更多運算單元可能會提升查詢效能。如要查看帳戶的時段用量，請參閱「監控健康狀態、資源使用率和工作」。

以容量為基礎的模式會根據查詢分配的運算單元容量計費。這個模式可讓您明確控管總時段容量。您可透過保留項目明確選擇要使用的運算單元數量。您可以將預留的運算單元數量指定為一律會分配的基準量，或是視需要分配的自動調度量。自動調度運算單元預留項目會調度容量，以因應工作負載需求。BigQuery 會在工作負載變更時分配運算單元。您可以根據使用預留項目的工作負載效能或重要性，設定預留項目的運算單元數量。

使用運算單元來執行查詢

BigQuery 執行查詢工作時，會將 SQL 陳述式轉換成執行計畫，其中包含一系列的查詢「階段」。階段則是由一組執行步驟組成。BigQuery 使用分散式平行架構執行查詢。階段會模擬可平行執行的工作單元。階段之間會透過分散式重組架構傳遞資料，如要瞭解詳情，請參閱這篇Google Cloud 網誌文章。

BigQuery 查詢的執行作業是動態的。查詢處理期間，您可以修改查詢方案。隨著階段的加入，工作分配可針對資料分配進行最佳化。此外，查詢執行作業的運算能力可能會隨著其他查詢開始或完成，或是自動調度器將運算單元新增至預留項目而變更。

BigQuery 可同時執行好幾個階段，可使用推測性執行來加快查詢的執行速度，且可將階段以動態的方式重新分割，以便獲得最佳的平行處理能力。

運算單元資源經濟

如果查詢要求的運算單元數量高於可用數量，BigQuery 就會將個別的工作單元加入佇列，並等待運算單元變成可用。隨著查詢作業取得進展及運算單元釋出時，這些佇列中的作業單元會以動態方式開始執行。

BigQuery 可以針對特定的查詢階段，要求任何數量的運算單元。而 BigQuery 要求的運算單元數量，與您購買的運算能力無關，它只代表 BigQuery 針對該階段所選擇的最佳平行處理係數而已。BigQuery 會把工作單位加入佇列，並在有運算單元可用時執行這些工作單位。

當查詢要求的運算單元數量高於您購買的數量時，我們不會針對額外的運算單元向您收費，也不會按照額外的隨選費率向您收費。BigQuery 就只是把個別的工作單位加入佇列而已。

例如，假設使用者要求系統 將文字從英文翻譯成法文

1. 某個查詢階段要求 2,000 個運算單元，但可用的運算單元只有 1,000 個。
2. BigQuery 會用掉所有 1,000 個運算單元，並讓剩下的 1,000 個運算單元加入佇列。
3. 之後，如果有 100 個運算單元完成工作，它們就會以動態的方式，從佇列中的 1,000 個工作單元裡挑出 100 個工作單元。此時佇列中還有 900 個工作單位。
4. 之後，如果有 500 個運算單元完成工作，它們就會以動態的方式，從佇列中的 900 個工作單元裡挑出 500 個工作單元。此時佇列中還有 400 個工作單位。

當需求超出供給時，BigQuery 運算單元會加入佇列

如果工作負載需要的運算單元超出預訂方案的可用量，工作執行時間可能會增加，因為工作會等待運算單元可用。這就是所謂的「運算單元爭用」。如果工作負載需求遠大於預訂可用的時段，時段爭用情況可能會加劇。

容量優先順序

當特定區域的運算單元資源需求量過高時，BigQuery 會優先處理容量，藉此管理爭用情形。這項優先順序設定可確保容量模型層級較高的客戶較不受影響。系統會依下列順序決定容量優先順序：

1. Enterprise Plus 和 Enterprise 版本的基準和承諾容量。
2. Enterprise Plus 自動調整容量。
3. Enterprise 版自動調度資源的容量。
4. 標準版和隨選容量。

如果區域發生爭用情形，系統會優先將資源分配給較高層級的版本，因此標準版和隨選容量要求較有可能發生存取延遲。

BigQuery 中的公平排程

BigQuery 會使用稱為「公平排程」的演算法，在單一保留項目中分配運算單元容量。

BigQuery 排程器會強制將運算單元平均分配給保留項目中執行查詢的專案，然後再分配給指定專案中的工作。排程器會提供最終公平性。在短時間內，某些工作可能會分配到不成比例的運算單元數量，但排程器最終仍會修正這個問題。排程器的目標是找出平衡點，避免過於嚴格的作業 (清空執行中的工作會浪費運算單元時間) 和過於寬鬆的作業 (長時間執行作業的工作會佔用不成比例的運算單元時間)。

公平排程可確保每個查詢隨時都能存取所有可用的運算單元，並在每個查詢的運算能力需求改變時，動態地將運算能力自動重新分配給所有執行中的查詢。在下列情況下，每當有查詢執行完畢，以及新的查詢送交執行時：

• 每當您提交新的查詢時，系統會自動把運算能力重新分配給所有執行中的查詢。隨著每個查詢可用的運算能力越來越多，個別的工作單元就能順利地、暫停、繼續執行，以及加入佇列。
• 每當有查詢執行完畢時，系統會立刻自動將該查詢占用的運算能力提供給所有其他的查詢使用。
• 每次有查詢因為自己動態 DAG 的改變，導致運算能力的需求變更時，BigQuery 都會自動重新評估該查詢與所有其他查詢的運算能力可用性，並在必要時重新分配及暫停使用運算單元。

BigQuery 中的公平排程

視查詢的複雜程度和大小而定，查詢要求的運算單元數量，可能會低於或高於自己有權限使用的所有運算單元數量。BigQuery 會在公平排程的原則下，以動態的方式確保所有運算單元隨時都會受到充分的運用。

如果重要工作持續需要比排程器分配的運算單元數量更多，請考慮建立額外的保留項目，並分配所需數量的運算單元，然後將工作指派給該保留項目。

以公平調度為例，假設您有下列預訂設定：

• 預留項目「A」有 1,000 個基準運算單元，且未啟用自動調度資源
• 指派給預留項目的專案 A 和專案 B

情境 1：在專案 A 中，您執行需要大量運算單元的查詢 A (一個並行查詢)，並在專案 B 中執行 20 個並行查詢。雖然共有 21 個查詢使用預留項目 A，但運算單元分配情形如下：

• 專案 A 收到 500 個運算單元，查詢 A 則以 500 個運算單元執行。
• 專案 B 收到 500 個運算單元，由 20 個查詢共用。

情境 2：在專案 A 中，您執行查詢 A (一項並行查詢)，需要 100 個運算單元才能執行；在專案 B 中，您執行 20 項並行查詢。由於查詢 A 不需要 50% 的預留項目，因此運算單元分配如下：

• 專案 A 收到 100 個運算單元，查詢 A 則以 100 個運算單元執行。
• 專案 B 收到 900 個運算單元，由 20 個查詢共用。

反之，請參考下列預訂設定：

• 預留項目 B，有 1,000 個基準運算單元，且未啟用自動調度資源。
• 10 個專案，全都指派給預留項目 B。

假設這 10 個專案執行的查詢都有足夠的運算單元需求，則每個專案都會獲得總預留運算單元的 1/10 (或 100 個運算單元)，與每個專案執行的查詢數量無關。

配額和限制

運算單元配額和限制可為 BigQuery 提供安全防護。不同的定價模式會使用不同的時段配額類型，如下所示：

• 以量計價模式：您須遵守專案和機構的運算單元限制，並具備暫時的爆量功能。視工作負載而定，使用更多運算單元可提升查詢效能。

• 以容量為準的價格模式：預留項目配額和限制會定義您在某個位置的所有預留項目中，可分配的運算單元數量上限。如果使用自動調度資源，預留項目大小上限的總和不得超過這個限制。您只需支付預留項目和承諾的費用，不必支付配額費用。如要瞭解如何提高運算單元配額，請參閱「申請提高配額」一文。

如要查看您使用的運算單元數量，請參閱 BigQuery 監控。

閒置的運算單元

在任何時間點，部分運算單元可能處於閒置狀態。這些實用資源包括：

• 未分配給任何預留項目基準的運算單元使用承諾。
• 已分配給預留項目基準，但未使用的運算單元。

使用以量計價模式時，閒置運算單元不適用。

根據預設，在預留項目中執行的查詢會自動使用相同區域和管理專案中其他預留項目的閒置運算單元。BigQuery 會在需要時，立即將閒置運算單元分配給已指派的預留項目。如果原始預留項目需要，系統會快速搶占其他預留項目使用的閒置運算單元。您可能會在短時間內看到所有預留項目的運算單元總消耗量超過指定上限，但這額外的運算單元用量不會計費。

舉例來說，假設您有下列預訂設定：

• project_a 指派給 reservation_a，後者有 500 個基準運算單元，且未啟用自動調度資源。
• project_b 指派給 reservation_b，後者有 100 個基準運算單元，且未啟用自動調度資源。
• 兩個預留項目位於相同區域和管理員專案，且沒有其他專案指派給這些預留項目。

您在 project_b 中執行 query_b。如果 project_a 中沒有執行任何查詢，query_b 就能使用 reservation_a 的 500 個閒置運算單元。query_b 仍在執行時，最多可能會使用 600 個運算單元：100 個基準運算單元加上 500 個閒置運算單元。

假設 query_b 正在執行，而您在 project_a 中執行 query_a，這項作業可能會使用 500 個運算單元。

• 由於您已為 project_a保留 500 個基準運算單元，query_a 會立即啟動並分配到 500 個運算單元。
• 分配給 query_b 的運算單元數量會迅速減少至 100 個基準運算單元。
• 在 project_b 中執行的其他查詢會共用這 100 個運算單元。 如果後續查詢沒有足夠的運算單元可供啟動，就會加入佇列，直到執行中的查詢完成，運算單元變成可用為止。

在這個範例中，如果 project_b 已指派給沒有基準運算單元或自動調度資源的預留項目，則 query_a 開始執行後，query_b 就沒有運算單元。BigQuery 會暫停 query_b，直到有閒置運算單元可用或查詢逾時為止。project_b 中的其他查詢會排隊，直到有閒置運算單元為止。

如要確保預訂只使用已佈建的時段，請將 ignore_idle_slots 設為 true。不過，設為 true 的預留項目可以與其他預留項目共用閒置運算單元。ignore_idle_slots

不同版本的預留項目無法共用閒置運算單元。您只能分享基準運算單元或承諾運算單元。自動調度的運算單元可能暫時可用，但無法做為其他預留項目的閒置運算單元共用，因為這些運算單元可能會縮減。

只要 ignore_idle_slots 設為 False，保留項目就可以將運算單元數量設為 0，並存取未使用的運算單元。如果只使用default預訂功能，建議關閉ignore_idle_slots。接著，您可以將專案或資料夾指派給該預留項目，這樣一來，專案或資料夾就只會使用閒置運算單元。

但類型為 ML_EXTERNAL 的指派作業是例外情況，因為 BigQuery ML 外部模型建立作業使用的運算單元不具先占特性。如果保留項目同時指派了 ML_EXTERNAL 和 QUERY 類型，只有在 ML_EXTERNAL 工作未佔用運算單元時，其他查詢工作才能使用這些運算單元。此外，這些工作無法使用其他預留項目的閒置運算單元。

以預留項目為準的公平性

注意： 您必須先啟用以預留項目為準的公平性，才能建立可預測的預留項目。

採用以保留項目為準的公平分配機制後，BigQuery 會優先處理同一管理員專案中所有保留項目的工作，並平均分配閒置運算單元，每個預留項目都會在閒置運算單元集區中獲得類似的可用容量配額，然後運算單元會平均分配給專案。這項功能僅適用於 Enterprise 或 Enterprise Plus 版本。

下圖顯示未啟用以預訂為準的公平性時，閒置時段的分配情形：

在這個圖表中，閒置運算單元會平均分配給各個專案。

如果未啟用以預留項目為準的公平性，系統會將可用的閒置運算單元平均分配給預留項目中的專案。

下圖顯示啟用以預訂為準的公平性後，閒置時段的分配情形：

在這張圖表中，閒置運算單元會平均分配給預留項目，而非專案。

啟用以預留項目為準的公平性後，系統會將可用的閒置運算單元平均分配給各個預留項目。

啟用以預留項目為準的公平性後，請查看資源用量，管理可用的時段和查詢效能。

如果正式環境工作負載有嚴格的時間限制，請避免只使用閒置運算單元，這類工作必須使用基準或自動調度運算單元。建議您將閒置運算單元用於低優先順序工作，因為運算單元隨時可能遭到搶占。

自動調度運算單元

下一節將討論自動調度資源的時段，以及如何搭配預訂使用。

使用自動調度資源預留項目

您不需要購買運算單元承諾，即可建立自動調整規模的預留項目。運算單元承諾使用合約可為持續使用的運算單元提供折扣價，但使用自動調度預留資源時，這類合約並非必要。如要建立自動調度預留項目，請為預留項目指派運算單元數量上限 (預留項目大小上限)。如要找出自動調度資源運算單元數量上限，請從預留項目大小上限中，扣除指派給預留項目的任何基準運算單元。

建立自動調度資源預留項目時，請注意下列事項：

• BigQuery 會近乎即時地擴充預留項目，直到達到執行工作所需的運算單元數量，或是達到預留項目可用的運算單元數量上限為止。運算單元一律會自動調度，且數量為 50 的倍數。
• 系統會根據實際用量向上調整，並將用量進位至最接近的 50 個時段增量。
• 自動調整的運算單元會按照相關版本的容量運算定價計費。系統會根據運算單元數量收費，而非實際使用的運算單元數量。即使導致 BigQuery 擴充的工作失敗，我們還是會收取這筆費用。因此，請勿使用工作資訊結構定義來比對帳單。請改為參閱「使用資訊結構定義監控自動調度」。
• 雖然配額數量一律會以 50 的倍數調整，但單一步驟中可能會調整超過 50 個配額。舉例來說，如果工作負載需要額外 450 個運算單元，BigQuery 可以嘗試一次擴充 450 個運算單元，以滿足容量需求。
• 當與預留項目相關聯的工作不再需要容量時，BigQuery 會縮減容量 (最少 1 分鐘)。

系統會保留自動調整的容量至少 60 秒。這段 60 秒的期間稱為縮減視窗。容量出現任何新尖峰時，系統會重設縮減窗口，並將整個容量層級視為新的授權。不過，如果自上次增加容量後已過 60 秒以上，且需求量較少，系統就會減少容量，但不會重設縮減時間範圍，因此可連續減少容量，不會造成延遲。

舉例來說，如果初始工作負載容量擴充至 100 個時段，系統會保留尖峰容量至少 60 秒。如果在縮減時間區間內，工作負載擴展至 200 個新尖峰時段，則會開始新的 60 秒縮減時間區間。如果在縮減期間沒有出現新的尖峰，工作負載會在 60 秒結束時開始縮減。

請參考以下詳細範例：在 12:00:00，初始容量會擴充至 100 個運算單元，且用量會持續一秒。該尖峰值會保留至少 60 秒，從 12:00:00 開始。60 秒過後 (12:01:01)，如果新的用量為 50 個時段，BigQuery 會縮減至 50 個時段。如果 12:01:02 的新用量為 0 個時段，BigQuery 會再次立即縮減至 0 個時段。縮減時間範圍結束後，BigQuery 可以連續多次縮減，不需要新的縮減時間範圍。

如要瞭解如何使用自動調度功能，請參閱「使用自動調度配額」。

搭配基準和自動調度資源運算單元使用預留項目

除了指定預留項目大小上限，您也可以選擇指定每個預留項目的基準運算單元數量。「基準數量」是指一律會分配給預留項目的運算單元最小數量，而且必定會產生這個數量的運算單元費用。只有在所有基準運算單元 (和閒置運算單元，如有) 都用完後，才會新增自動調度運算單元。您可以將一項預留項目的閒置基準運算單元，分享給需要運算能力的預留項目。

您可以每隔幾分鐘增加預留項目的基準運算單元數量。如要減少基準運算單元，如果最近變更了基準運算單元處理量，且基準運算單元超出承諾使用運算單元，則每小時只能減少一次。否則，您可以每隔幾分鐘減少基準廣告空間。

基準和自動調度資源的運算單元會根據您最近的工作負載提供容量。如果您預期工作負載量會大幅增加，且與近期工作負載量差異極大，建議您在活動前增加基準容量，而不是依賴自動調度資源功能來涵蓋工作負載容量。如果增加基準容量時發生問題，請等待 15 分鐘後再重試要求。

如果預留項目沒有基準運算單元，或未設定從其他預留項目借用閒置運算單元，BigQuery 會嘗試擴充。否則，必須先充分運用基準時段，才能進行擴充。

預留項目會依據下列優先順序使用及新增運算單元：

1. 基準運算單元。
2. 閒置運算單元共用功能 (如果已啟用)。預留項目只能共用以相同版本和區域建立的其他預留項目中的閒置基準或已承諾運算單元。
3. 自動調度運算單元。

在下列範例中，廣告空間會從指定基準金額開始調整。etl 和 dashboard 預留項目的基準大小分別為 700 和 300 個運算單元。

在這個範例中，etl 預留項目可調度至 1300 個運算單元 (700 個基準運算單元加上 600 個自動調度運算單元)。如果 dashboard 預留項目未使用中，且 dashboard 預留項目沒有執行任何工作，etl 預留項目就能使用 dashboard 預留項目的 300 個運算單元，因此最多可使用 1,600 個運算單元。

dashboard 預留項目可擴充至 1100 個運算單元 (300 個基準運算單元加上 800 個自動調度運算單元)。如果 etl 預留項目完全閒置，dashboard 預留項目最多可擴充至 1800 個運算單元 (300 個基準運算單元 + 800 個自動調度資源運算單元 + etl 預留項目中的 700 個閒置運算單元)。

如果 etl 預留項目需要超過 700 個一律可用的基準運算單元，系統會依序嘗試使用下列方法新增運算單元：

1. 700 個基準運算單元。
2. 與 dashboard 預留項目中 300 個基準運算單元共用閒置運算單元。只有以相同版本建立的預留項目，才能共用預留項目的閒置基準運算單元。
3. 將 600 個額外運算單元擴充至預留項目大小上限。

使用運算單元承諾

以下範例顯示如何使用容量承諾自動調整資源配置。

與預留項目的基準運算單元類似，運算單元承諾使用合約可讓您分配固定數量的運算單元，供所有預留項目使用。與基準運算單元不同，承諾用量在約期內無法減少。運算單元承諾使用合約為選用項目，但如果長期需要基準運算單元，可藉此節省費用。運算單元承諾使用合約可用於支付預留項目的基準運算單元費用。任何未使用的運算單元容量，都會以閒置運算單元的形式，在其他預留項目之間共用。運算單元承諾使用合約不適用於自動調度資源運算單元。如要確保獲得承諾運算單元的折扣費率，請確認承諾的運算單元足以涵蓋基準運算單元。

在本範例中，您需要為容量承諾運算單元支付預先定義的費率。自動調度資源功能啟用後，預訂的自動調度資源配額會擴增，您需要支付擴增配額的費用。自動調度費率的收費依據為調度的運算單元數量，而非使用的運算單元數量。

以下範例顯示預訂內容，其中基準時段數超過已承諾時段數。

在本範例中，這兩個預留項目共有 1000 個基準運算單元，其中 500 個來自 etl 預留項目，另外 500 個來自 dashboard 預留項目。不過，承諾僅涵蓋 800 個時段。在這種情況下，超額運算單元會按照即付即用 (PAYG) 費率計費。

可用的運算單元數量上限

如要計算預留項目可使用的運算單元數量上限，請將基準運算單元數量、自動調度運算單元數量上限，以及以相同版本建立且不屬於基準運算單元的承諾運算單元數量加總。上圖中的範例設定如下：

• 承諾使用 1000 個年度運算單元。這些運算單元會指派為 etl 預留項目和 dashboard 預留項目的基準運算單元。
• 指派給 etl 預留項目的 700 個基準運算單元。
• 指派給 dashboard 預留項目的 300 個基準運算單元。
• 將「etl」預訂的運算單元自動調度上限設為 600。
• 為「dashboard」預留項目自動調度 800 個運算單元。

以 etl 預留項目為例，運算單元數量上限等於 etl 基準運算單元 (700 個) 加上 dashboard 基準運算單元 (300 個，前提是所有運算單元都處於閒置狀態)，再加上自動調度資源的運算單元數量上限 (600 個)。因此，在這個範例中，etl 預留項目可使用的運算單元數量上限為 1600 個。這個數字超過容量承諾中的數字。

在下列範例中，年約方案的運算單元數量超過指派的基準運算單元。

在這個範例中，我們有：

• 承諾使用 1600 個年度運算單元。
• 預留項目大小上限為 1500 (包括 500 個自動調度運算單元)。
• 指派給 etl 預留項目的 1000 個基準運算單元。

預留項目可用的運算單元數量上限，等於基準運算單元數量 (1000) 加上未專用於基準運算單元的任何承諾閒置運算單元 (1600 個年約運算單元 - 1000 個基準運算單元 = 600)，再加上自動調度運算單元數量 (500)。因此，這個預留項目的最大潛在運算單元數為 2100 個。自動調度的運算單元是承諾容量以外的額外運算單元。

自動調度最佳做法

1. 首次使用自動調度資源功能時，請根據過去和預期成效，將自動調度資源運算單元數量設為有意義的數字。預訂建立完成後，請主動監控失敗率、效能和帳單，並視需要調整自動調度資源的配額數量。

2. 自動調度器縮減資源前，至少會等待 1 分鐘，因此請務必設定自動調度資源的上限，以平衡效能和成本。如果自動調度運算單元數量上限過高，且工作可以在幾秒內用完所有運算單元，您仍須支付一整分鐘的最高運算單元費用。如果將最大時段數調降為目前的一半，預訂的時段數就會減少，工作在這段時間內可使用更多 slot_seconds，進而減少浪費。如需判斷所需配額的相關說明，請參閱「監控工作效能」。如要瞭解判斷運算單元需求的替代方法，請參閱「查看版本運算單元建議」。

3. 運算單元用量有時可能會超過基準運算單元加上調度運算單元的總和。如果運算單元用量超過基準值加上擴充運算單元，您就不必支付相關費用。

4. 自動配置器最適合長時間執行的繁重工作負載，例如含有多個並行查詢的工作負載。請避免一次傳送一項查詢，因為每項查詢都會擴充預留量，且至少會維持 1 分鐘。如果您持續傳送查詢，導致工作負載不斷增加，設定基準並購買承諾可提供持續的容量，且享有折扣價。

5. BigQuery 自動調度資源取決於運算能力可用性。BigQuery 會根據過往用量，盡量滿足客戶的容量需求。如要確保容量，您可以設定選用的運算單元基準，也就是保留項目中保證的運算單元數量。使用基準時，系統會立即提供配額，無論您是否使用，都必須付費。如要確保容量可因應大型非自然需求 (例如高流量的節慶假日)，請提前數週聯絡 BigQuery 團隊。

6. 系統一律會收取基準運算單元費用。如果容量承諾到期，您可能需要手動調整預留項目中的基準運算單元數量，以免產生不必要的費用。舉例來說，假設您有 1 年期承諾，其中包含 100 個運算單元，以及 100 個基準運算單元的預訂。承諾期限到期，且沒有續約方案。使用承諾到期後，您需要按照即付即用費率，支付 100 個基準運算單元的費用。

監控自動調度資源

如要瞭解如何監控自動調度資源的時段用量和工作效能，請參閱「監控自動調度資源」。

運算單元用量超出上限

如果工作佔用運算單元的時間過長，可能會獲得不公平的運算單元分配量。為避免延遲，BigQuery 允許其他工作借用額外的運算單元，因此總運算單元用量可能會超過您指定的運算單元容量。只有獲得超過公平分配額度的工作，才會計入任何超出額度的使用量。

系統不會直接向您收取超出配額的費用。工作會繼續執行，並根據公平分享原則累積使用配額，直到您分配的容量足以支付所有超額用量為止。系統會從回報的時段用量中排除多餘的時段，但某些詳細的執行統計資料除外。

請注意，系統可能會預先借用部分時段，以減少日後延遲，並提供其他好處，例如降低時段成本變異性和尾端延遲。運算單元借用量不得超過運算單元總容量的一小部分。