在雲環境中，GPU作為一種稀缺且高價值的計算資源，其按需擷取存在不確定性，可能導致關鍵業務在需要時無法及時獲得資源而中斷或延遲。為解決此問題，阿里雲容器計算服務ACS (Alibaba Cloud Container Service) 的Serverless Kubernetes為使用者提供了兩種資源預留模式，旨在為您的GPU應用提供確定性資源保障。
GPU Pod容量預留（Pod-level Reservation）
工作原理： 執行個體預留是一種面向工作負載的、規格化的容量預留。您需要明確指定Pod的規格（如：2xA10 GPU, 16 vCPU, 32 GiB記憶體）以及需要預留的Pod數量（如：12個）。平台將為您預留出剛好能容納這12個特定規格Pod的計算容量。
提供的確定性： 它提供的是“工作負載容量確定性”。您可以確信，在任何時候發起建立請求，系統都保證有能力運行您指定的比如12個該規格的Pod。這極大地簡化了容量規劃，您無需關心底層的節點規格和資源片段，只需關注您的應用Pod需求即可。
適用情境：
同構工作負載： 當您的應用（如大規模分布式訓練、線上推理服務）由大量規格完全相同的 Pod 組成時，此模式是最佳選擇。
簡化營運： 希望將底層資源規劃的複雜性完全交由平台處理，只專註於應用程式層面的容量需求。
GPU-HPN容量預留（Node-level Reservation）
工作原理： 此模式為您在ACS的底層資源集區中預留並鎖定專用的GPU計算節點容量。這些資源被鎖定給您的賬戶專用，確保當您需要建立新的GPU Pod時，總有可用的硬體資源來承載它們，避免了因資源集區緊張而導致的Pod調度失敗（Pending 狀態）。
提供的確定性： 它提供的是“實體資源確定性”。它保證了您在需要擴容時，底層基礎設施（GPU 節點）是確定可用的。您可以自行決定如何在這些節點上調度和組合不同規格的Pod（即所謂的“裝箱”）。
適用情境：
異構工作負載： 當您需要在同一資源集區中運行多種不同規格的GPU Pod時，此模式提供了最高的靈活性。
精細化資源控制：希望通過自訂調度策略（如Taints/Tolerations、Node Affinity）來精細化控制Pod的物理布局，以實現效能最佳化或資源隔離。
總結與對比
特性 | GPU Pod容量預留 (Pod-level) | GPU-HPN容量預留 (Node-level) |
預留對象 | 特定規格Pod的數量。 | 底層GPU計算節點容量。 |
預留粒度 | 邏輯工作負載（如12個 1A10GPU8C16G的Pod）。 | 物理節點資源（如2台P16EN節點）。 |
保障層級 | 工作負載容量確定性。 | 物理節點資源確定性。 |
靈活性 | 較低（綁定特定Pod規格）。 | 極高（可運行靈活規格Pod）。 |
管理複雜度 | 低（平台負責資源匹配）。 | 較高（需要響應節點營運事件）。 |
選擇建議 |
| 中大規模、且規格複雜多變的混合應用。 |
通過選擇合適的預留模式，您可以根據業務對確定性不同要求，有效規避GPU資源擷取的風險，確保AI應用的穩定、可靠運行。