AWS Batch 配額管理讓團隊共享 GPU，並收回其配置

AWS Batch 配額管理讓團隊可借出閒置的訓練容量，同時保留從借用工作負載收回容量的能力。這項功能將資源配置與 Amazon SageMaker Training 的排程決策連結起來；後者是 AWS 用於訓練機器學習模型的受管服務。當中的核心取捨很直接：團隊可以使用他人的剩餘容量，但其工作必須能承受資源擁有人回來時失去存取權。

AWS 在 10 月 29 日的操作說明，透過不同的工作負載政策闡述這項取捨。根據公司發布的配額管理公告，該功能本身於 2026 年 3 月 25 日推出。這個分別很重要：本週的發展是既有功能的詳細營運示例，而非其首次發布。

基建團隊熟悉兩種相互競爭的做法：透過嚴格分隔保護配置，或將資源匯集，並在需求碰撞時協商存取權。AWS 把這類協商納入排程政策。壓力因而轉向平台管理員及訓練工作負責人，他們必須判斷哪些實驗值得獲得可預測的存取權，哪些則可以接受中斷。

AWS Batch 配額管理將配置轉化為排程規則

這項改變在於，團隊的配置會連結到其收回其他團隊所借容量的權利。

配額分享是一個設有容量限制及共享規則的虛擬佇列，代表一個團隊、專案或工作負載群組。管理員會將這些分享附加到工作佇列，即承載已提交工作的容器。AWS 文件指出，每個佇列最多可有 20 個分享，而每個分享最多可設五項容量限制。

這些限制使用支援的訓練執行個體類型，即特定的機器設定，而不是一個由可互換 GPU 組成、未作區分的資源池。AWS 的配額分享政策提供三個選擇。RESERVE 為自身分享保留閒置容量。LEND 容許其他人使用閒置容量。LEND_AND_BORROW 容許借出及借用，但受已設定的借用上限規限。

這是一個對臨時存取訂立明確規則的配置系統。團隊的應得權益與目前用量，不再需要在每一刻完全一致。剩餘容量可以服務其他工作，而不會永久改變底層配置。

這個分別令共享基建更容易理解。配置回答的是：需求回升時，誰擁有提出要求的權利。用量回答的是：現在誰正在使用資源。將兩者視為不同問題，讓管理員可在不放棄擁有權的前提下容許彈性。

設想一個假設情境：平台團隊在研究小組之間分配訓練存取權。固定分區可保護各小組免受競爭影響，但可能令資源閒置。無限制資源池可在需求較低時改善存取，卻會令平台團隊難以解釋為何已配置的資源不可用。

配額政策提供中間立場。借用成為設有既定收回機制的有條件存取。這項安排仍需要就配置達成共識，但管理員可以在排程爭議發生前，先將協議編碼為規則。

AWS 文件說明，這項功能適用於連接 SAGEMAKER_TRAINING 服務環境的 SageMaker Training 佇列；後者是與受管訓練執行相關的 Batch 設定。讀者不應把它理解為適用於每種 AWS Batch 工作負載的通用資源共享功能。

評估遷移時，這個範圍相當重要。已提交 SageMaker 工作的團隊，面對的營運決策不同於透過另一套執行系統管理訓練的團隊。排程政策屬於該較大型工作流程的一部分。

因此，實際問題比「是否可以共享」更具體：組織能否透過這些分享表達既有承諾，同時不會就保證存取權造成誤導性的期望。

平台團隊必須界定配置實際承諾甚麼

自動借出只有在團隊就借用容量附帶的條件達成共識後，才會減少排程協調。

即時壓力落在負責共享訓練基建的平台團隊身上。他們的工作不再只是分配存取權，還要分辨持續性的配置與臨時使用未使用資源的許可。

這個分別聽起來像行政工作，直至期限來臨。借用團隊可能把成功完成的訓練執行視為容量可用的證明。借出團隊則可能把同一批資源視為其預期可收回的配置一部分。

兩種理解都可以理解。沒有明確政策時，分歧會變得個人化：必須有人決定誰的實驗要停止。有明確政策時，分歧會提前轉移到配置協議之中。

這正是 GPU 容量共享成為組織議題的原因。排程器可以一致地套用規則，但一致性並不代表規則符合業務優先次序。管理員仍需就每個分享的處理方式提出站得住腳的解釋。

研究工作提供一個有用的假設對比。探索性實驗通常有彈性的完成時限，而與評估期限掛鈎的訓練執行則較難等待。這些差異可以支持不同的共享政策，並不表示某個團隊的工作價值較低。

困難的情況亦會出現在同一團隊內。一個小組可以同時負責探索性實驗、發布準備及緊急調查。為整個小組指定單一政策，可能會把中斷成本不同的工作負載視作相同。

按專案或工作負載組織分享，有助表達這些差異，但也會增加需要維護的政策邊界。正確的分組方式取決於使用者能否在提交前可靠地分類工作。

優先次序帶來另一個管治問題。若使用者可以在期限將至時提高工作的緊急程度，優先級數值可能失去意義。每個團隊都有誘因保護自己的完成時間。

應對方法應具體落實在營運層面。團隊需要共用的緊急程度定義、例外情況的負責人，以及審閱變更的方法。否則，自動化排程可能只會透過設定變更重現同一場協商。

例如，一個組織可能會區分未達實驗目標與發布決策受阻。這是示例性的政策選擇，而非 AWS 內建分類。它的價值在於，於容量出現爭議前讓後果變得易於理解。

文件記錄有助促成這項協議。工程團隊可將配置決策、收回假設及例外情況保存在可搜尋的知識庫。有用的記錄會說明政策為何存在，以及誰可以修改它。

即使排程器接手執行，這項工作也不會消失。它只會變得更明顯。過去只存在於訊息或會議中的借用協議，現在必須經得起實際工作負載行為的考驗。

這亦是為何推出時應先由工作負載特性著手，而非只看團隊名稱。中斷容忍度、復原行為及期限敏感度，較組織架構圖更能為政策提供穩健基礎。

借用容量附帶中斷契約

AWS 的示例把中斷容忍度視為選擇共享政策的理由，而不是事後才考慮的因素。

10 月的操作說明設定了三個分享，每個獲配置一個 ml.g5.xlarge 執行個體。其背景工作分享可以借出及借用，並啟用基於優先級的中斷。AWS 明確說明，這些工作會使用檢查點，即在中斷後支援復原的已儲存訓練狀態。

中等優先級分享會借出閒置容量，但不會借用。當其配置正忙碌時，工作會等待。受保護分享既不借出也不借用，並停用其自身工作之間的中斷。

在SageMaker 配額示例中，借出分享中的新工作會令 Batch 從借用分享收回容量。另一方面，提高等待中工作的優先級，會令同一分享內的另一項工作讓出資源。

這些是不同機制。跨分享搶佔，即停止工作以向配置該容量的分享恢復容量，會執行借出協議。分享內搶佔，即在一個分享中停止較低優先級工作，則會執行該分享內部的緊急程度規則。

該示例表明，不同政策可以在同一整體安排中共存。但它並未證明每種工作負載都能從最寬鬆的借用設定中受益。

對背景實驗而言，借用容量提供更早取得進展的機會。其負責人接受完成時間的不確定性。對有期限約束的工作而言，避免這種不確定性可能比在需求較低時取得額外容量更有價值。

這個分別改變團隊描述借用的方式。它是可能遭中斷的臨時存取，而不是團隊可靠配置的延伸。

中斷契約應回答幾個實際問題。工作負載能否復原？誰負責處理復原失敗？預期完成時間是否假設持續存取？同一工作反覆讓出資源時會怎樣？

即使系統負責停止及重新提交工作，這些問題仍然重要。自動化控制執行轉換，但應用程式負責人仍要判斷所產生的行為是否可以接受。

當中亦涉及溝通問題。一項工作開始執行會帶來進度預期。使用者需要明白，在借用容量上執行，並不具備在自身配置內執行的相同連續性預期。

否則，成功借用本身可能造成採用問題。團隊習慣使用剩餘容量，將其納入交付假設，然後把合理的收回行為視為服務故障。

因此，政策需要出現在規劃用語之中，而不只是設定中。預測應區分由已配置容量支援的工作，以及透過機會性存取加速的工作。

這並不會令借用執行變得較沒用。反而令其價值更容易評估。只要團隊不據此承諾完成時間，在原本閒置的時段取得進展即使時機不確定，仍然有價值。

AWS 操作說明帶來的更廣泛啟示是：不同工作負載可對資源使用率及可預測性採取不同處理方式。管理員毋須在所有地方施加相同取捨。

復原品質決定共享能否帶來有用進展

排程器可以將被中斷的工作重新放回佇列，卻未必能確保應用程式保留先前的工作成果。

AWS 的工作搶佔行為明確說明了執行語義。搶佔會停止處於已排程、正在啟動或執行中狀態的工作，以容納可執行的工作。預設情況下，被搶佔的工作會回到可執行狀態，且不設搶佔次數上限。

管理員可以設定 preemptionRetriesBeforeTermination，為這種行為設定界限。數值為零時，工作在首次被搶佔後便會失敗。AWS 亦表示，其選擇啟發式方法會考慮借用的執行個體資源、相對優先順序及工作持續時間。

這些細節說明，對「最高優先順序先執行」的理解需要保留條件。資源要求及共享安排都會參與排程決策。優先順序是一項輸入條件，並非任何緊急工作都能立即啟動的普遍承諾。

應用程式層面的關鍵在於復原。工作可能已有資格再次執行，卻仍未具備高效繼續所需的狀態。佇列管理與復原處理相關問題，但並不是同一件事。

AWS 的訓練檢查點支援會儲存模型狀態，並將已設定的檢查點檔案與其物件儲存服務 Amazon S3 同步。自訂訓練程式碼必須正確儲存及載入相關狀態。AWS 亦將檢查點儲存頻率的控制權交予訓練指令碼。

這表示，借用政策應建基於已證實的復原途徑。單是啟用儲存目的地，並不能證明特定訓練應用程式能重建所需的一切。

以假設性的實驗為例，模型參數可能只是所需狀態的一部分。應用程式擁有人應檢視其框架所預期的完整續行行為。合適的測試是：中斷執行後，是否仍能產生可接受的進度及有效結果。

檢查點頻率亦帶來另一項取捨。更頻密地儲存可保留較新的進度，但儲存本身亦會消耗資源。合適的間隔取決於工作負載，而非某項普遍的排程偏好。

這些是工程考量，並非 AWS 功能失效的證據。它們說明為何使用率主張需要工作負載測量作支持。執行個體忙碌，並不自動代表完成了更多訓練。

有用的評估應包括重複計算、重新啟動準備、中斷後的等待時間，以及成功完成的情況。只看被佔用的資源，可能忽略取得該使用率的成本。

當團隊把每項可執行工作都視為同樣適合借用資源時，風險最大。有些實驗能良好容忍碎片化存取；另一些則有足夠高的復原開銷，以致等待穩定存取反而是更實際的選擇。

重複中斷亦值得獨立關注。反覆恢復的工作可以持續消耗資源，卻仍錯過完成時限。重試上限提供了一項控制措施，但在達到上限時如何選擇該值，需要相應的營運處置。

必須有人負責該處置。失敗後應導向清晰的決定，例如重新分類、重新提交，或採用不同的容量安排。否則，受限的重試政策只是把協調負擔轉移至事故處理。

受保護的政策同樣有其條件。AWS 文件指出，降低某個 share 的容量上限，可能使其既有工作符合被搶佔的資格。因此，管理員應將配置變更視為會影響執行的變更。

團隊對持續執行的預期，取決於其共享政策及配置的穩定性。配置審查相當重要，因為一次政策修改可以改變執行中工作維持受保護狀態的條件。

AWS 公開的範例是營運示範，而非客戶節省成本的獨立基準測試。它提供了一個可供評估的機制，卻沒有就吞吐量或完成時間給出普遍答案。

最有力的採用理據，將來自那些在貼近現實的資源競爭下量度過復原行為的工作負載。這類證據會把排程彈性與實用成果連結起來，而不是假設兩者必然同步。

Kueue 為共享訓練基礎設施提供比較基準

AWS 將熟悉的資源共享問題納入受管理訓練之中，而 Kubernetes 使用者亦可透過 Kueue 採取另一條路徑。

Kueue 是 Kubernetes 原生的工作負載佇列系統，其文件說明了相關佇列之間的借用及搶佔機制。其搶佔政策區分了佇列內中斷與涉及其他佇列的資源回收。它亦提供多種共享可借用資源存取權的方法。

這項比較為 AWS 功能提供了背景。對未使用配置作有條件存取，是既有的排程方法。AWS 的發展，是把這種方法帶入使用 SageMaker Training 的團隊工作流程。

因此，相關比較在於營運層面。已投入受管理訓練的團隊，會評估 Batch 如何表達其資源配置協議。運行 Kubernetes 的團隊，則會連同既有的工作負載控制器及平台責任一併評估這些協議。

兩個產品的文件都未能證明存在普遍的勝方。現有證據支持比較政策適配度及營運責任，而不是聲稱某個系統總能實現更高使用率。

這點重要，因為機構可能過於狹窄地界定排程決策。借用固然吸引，但排程器只是訓練環境的一部分。執行工具、復原實務、存取控制及支援責任都會影響結果。

對 SageMaker 使用者而言，將資源配置整合至既有訓練路徑，可減少管理員需要協調的獨立系統數目。這項好處是否足以支持採用，取決於機構現行的工作流程。

對 Kubernetes 使用者而言，若只是為了配額共享而引入另一條受管理訓練路徑，便需要作更廣泛的評估。單憑功能比較，無法涵蓋改變執行環境所帶來的後果。

共同問題依然不變：已分配的容量在其擁有人閒置時應保持有用，同時擁有人仍保有可信的復原途徑。兩種方法都要求團隊決定臨時存取可容許甚麼。

這亦解釋了為何嚴格分隔仍是合理的比較選項。當中斷風險帶來更大後果時，機構可以理性地接受閒置資源。使用率只是多個目標之一。

相反，擁有彈性實驗的機構可理性地優先考慮機會式進展。其工作負載及交付承諾支持另一種平衡。排程政策應表達這種平衡，而非強加抽象的使用率目標。

當 GPU 容量共享以人們理解的政策，取代既有的協調負擔時，最具說服力。若機構無法說明哪些工作應讓出資源或如何復原，其說服力便較低。

因此，競爭壓力部分落在內部平台實務上。維持手動分配流程的團隊，現在有一個受管理選項可供評估。他們需要證據證明，現行方法帶來的好處值得其協調成本。

AWS 的功能並沒有消除這些比較的需要。它為 SageMaker 使用者提供另一種實行配額與臨時存取之間協議的方法。

關注完成時間、復原行為及政策穩定性

最有用的證據，將把資源共享與已完成的工作及分配團隊可預測的存取權連結起來。

首個值得關注的訊號，是在貼近現實的資源競爭下的完成時間。有意義的評估應比較工作何時完成，包括借出資源的團隊回來時會發生甚麼。單靠較高的佔用率，只會提供不完整的證據。

若借用能加快彈性工作，同時為分配團隊保留可接受的存取權，採用的理據便會更強。若中斷造成的延誤抵銷收益，管理員便有理由收窄可借用的工作負載範圍。

第二個訊號，是具代表性應用程式的復原行為。中斷後能成功續行，將支持更廣泛使用借用機制。反覆重新啟動、無效的續行，或大量重複計算，則會削弱這個理據。

這些證據需要應用程式背景。一個訓練指令碼的成功示範，不能證明每個模型工作流程都會有相同行為。團隊應記錄附於每個工作負載分類的復原假設。

第三個訊號，是使用者開始依賴共享存取後的政策穩定性。管理員應觀察配置規則是否仍然容易理解，還是會帶來頻繁例外、優先順序改動及爭議。

穩定的政策會顯示機構已將其優先事項轉化為可用的排程規則。持續的覆寫，則會顯示已配置的 share 與實際承諾不相符。

在未來數月，這些訊號比啟用該功能的團隊數量更重要。採用反映興趣；完成行為、復原品質及可管理的管治，才證明安排是否奏效。

十月的示範為平台團隊提供具體的評估起點。它按工作負載對中斷的容忍度作區分，並展示資源回收如何改變執行方式。下一步取決於機構本身的工作負載證據。

對工程領導者而言，決策應把基礎設施行為與交付承諾連結起來。訓練環境可以支援更多機會式工作，卻不會令每個完成期限都同樣可預測。

對研究人員而言，直接含意是較早獲得存取權，可能附帶有條件的持續性。實驗計劃應反映已分配資源與借用資源之間的差異。

從團隊了解其受中斷影響行為的代表性工作負載開始。記錄其完成時間、復原結果，以及分配團隊收回容量的影響。在擴大存取範圍前，將這些結果與現有安排作比較。把資源配置協議與結果一併保存，讓審閱者能判斷政策是否達到原定目的。AWS Batch 配額管理提供了自動化借出及收回的具體方法，但工作負載證據應決定其適用位置。哪些實驗可以接受臨時存取，哪些需要更可預測的執行時段？