基於Pod的容量預留為彈性業務形態提供資源確定性保障。GPU Pod容量預留不需要直接綁定叢集，您只需要購買時指定Pod規格、可用性區域、鎖定時間等屬性，ACS會保證在需要資源時，分鐘級啟動相應規格的Pod。通過GPU Pod容量預留，可以保障資源確定性，同時Pod預留價格相比於隨用隨付Pod更低。本文介紹GPU Pod容量預留的功能和特點。
功能特點
資源確定性：在GPU Pod容量預留生效期間，系統保障資源成功拉起。
降低成本：Pod拉起後按照按量價格收費，Pod銷毀後按照容量預留價格收費，您可以根據業務流量靈活配置Pod拉起和銷毀時間點。
資源靈活性：可以建立多種不同規格的GPU Pod容量預留，以滿足不同業務的需求。
GPU Pod容量預留不支援為BestEffort算力類型的Pod提供保障。
GPU Pod容量預留支援地區、類型等屬性相匹配的節省計劃。
GPU Pod容量預留根據庫存情況反饋建立是否成功。
使用情境
周期性即時業務的資源需求：業務在每天/每周的周期中呈現"潮汐"特徵，任務需要保證即時執行和完成。例如即時推理業務等。
偶發性的大量資源需求：業務中存在突發性的Realtime Compute需求，需要保證資源的快速交付和擴容，避免對業務的影響。例如互連網業務中的熱時間點事件引發的資源需求等。
使用與計費樣本
GPU Pod容量預留採用隨用隨付方式。在容量預留生效期間，支付費用包括：
未使用的容量預留按量費用。
啟動Pod的按量費用。
本文以購買兩個GPU Pod容量預留並分別建立隨用隨付Pod1和隨用隨付Pod2的業務情境為例，展示使用流程以及不同階段的計費演算法，如下圖所示。
階段1：購買建立容量預留
執行以下操作前請先開通GPU容量預留。
在容器計算服務控制台中，選擇容量預留 > 建立GPU容量預留，配置容量預留參數，單擊建立容量預留。
配置項 | 說明 |
容量預留名稱 | 使用者自訂容量預留名稱。 |
預留類型 | GPU卡型。 |
地區 | 需要預留資源的地區。 |
可用性區域 | 需要預留資源的可用性區域。 |
資源規格 | 容量預留的規格。僅需選擇GPU卡數，系統會自動匹配該卡數下最高規格的CPU和記憶體。 |
預留方式 | Pod預留（不可修改）。 |
計費模式 | 隨用隨付（不可修改）。 |
數量 | 此規格GPU Pod容量預留的數量。 |
對應階段的費用演算法如下：
階段 | 費用 | 說明 |
階段1 | 無 | 未建立容量預留 |
階段2-6：容量預留生效期
在生效期內，您可以隨時建立不超過預留配置的Pod執行個體，系統保證建立成功，同時扣除對應數量的容量預留額度。抵扣需要滿足GPU（卡型和數量）、CPU和Memory不超過預留配置的前提來進行匹配，匹配成功則全部抵扣。例如，您購買了1個容量預留（規格為1卡 10核 80GB），建立規格為1卡 1核 2GB的Pod時，系統會完全抵扣該容量預留。Pod銷毀後，相應配置的GPU Pod容量預留額度會同時恢複。
對應階段的費用演算法如下：
階段 | 費用 |
階段2 | 2×容量預留單價×階段2時間長度 |
階段3 | 1×容量預留單價×階段3時間長度+ Pod1按量單價×階段3時間長度 |
階段4 | Pod1按量單價×階段4時間長度+ Pod2按量單價×階段4時間長度 |
階段5 | 1×容量預留單價×階段5時間長度+ Pod2按量單價×階段5時間長度 |
階段6 | 2×容量預留單價×階段6時間長度 |
其中容量預留單價為未使用的容量預留按量費用，Pod1和Pod2的按量單價以Pod啟動後的按量費用計算。
階段7：容量預留到期
容量預留到期後，系統會自動釋放GPU Pod容量預留。
規格說明
容量預留規格升級後，容量預留支援以下卡型及規格：
卡型 | GPU | vCPU | Memory（GiB） |
L20（GN8IS） | 1（48G顯存） | 16 | 128 |
2（48Gx2顯存） | 32 | 230 | |
4（48Gx4顯存） | 64 | 460 | |
8（48Gx8顯存） | 128 | 920 | |
T4 | 1（16G顯存） | 24 | 90 |
2（16Gx2顯存） | 48 | 180 | |
A10 | 1（24G顯存） | 16 | 60 |
2（24Gx2顯存） | 32 | 120 | |
4（24Gx4顯存） | 64 | 240 | |
8（24Gx8顯存） | 128 | 480 | |
P16EN | 1（96G顯存） | 10 | 80 |
2（96Gx2顯存） | 22 | 225 | |
4（96Gx4顯存） | 46 | 450 | |
8（96Gx8顯存） | 92 | 900 | |
16（96Gx16顯存） | 184 | 1800 | |
GU8TF | 1（96G顯存） | 16 | 128 |
2（96Gx2顯存） | 46 | 230 | |
4（96Gx4顯存） | 92 | 460 | |
8（96Gx8顯存） | 184 | 920 | |
GU8TEF | 1（141G顯存） | 22 | 225 |
2（141Gx2顯存） | 46 | 450 | |
4（141Gx4顯存） | 92 | 900 | |
8（141Gx8顯存） | 184 | 1800 | |
L20X（GX8SF） | 1（141G顯存） | 22 | 225 |
2（141Gx2顯存） | 46 | 450 | |
4（141Gx4顯存） | 92 | 900 | |
8（141Gx8顯存） | 184 | 1800 |
抵扣說明
容量預留的抵扣需同時滿足以下條件：
GPU卡型與預留卡型完全符合。例如，預留卡型和Pod卡型均為L20。
GPU卡數量與預留配置完全符合。例如，預留卡型和Pod卡數量均為1卡。
Pod的vCPU ≤ 預留的vCPU。
Pod的記憶體 ≤ 預留的記憶體。
以下抵扣情境以Pod的卡型與預留卡型相同為前提舉例：
抵扣原則 | 情境描述 | 抵扣結果與說明 |
完全符合或向下相容 | 預留：1 x（1卡16核128GB）。 建立Pod：1 x（1卡8核16GB）。 | 結果： 說明：Pod所需資源（卡數、CPU、記憶體）均未超過預留規格，因此匹配成功。該Pod將完全抵扣此容量預留。 |
最小規格優先 | 預留：
建立Pod：1 x（1卡5核30GB）。 | 結果： 說明：最大化資源使用率，系統優先選擇最貼合Pod需求的最小規格預留進行抵扣。 |
先進先出（FIFO） | 預留：4 x（1卡10核80GB），建立時間不同。 建立Pod：4 x（1卡5核30GB）。 | 結果： 說明：對於同規格的預留，遵循先進先出原則。 |
多卡規格原子性（不可拆分） | 預留：1 x（4卡46核450GB）。 建立Pod：4 x（1卡10核60GB）。 | 結果： 說明：多卡預留是一個原子單位，無法拆分來滿足多個單卡Pod的需求。這4個Pod將以隨用隨付的形式建立。 |
混合規格匹配 | 預留：
建立Pod：
| 結果： 說明：其餘Pod均無法匹配剩餘的4卡預留，因此將以隨用隨付的形式建立。 |
即時動態匹配 | 已有按量Pod：1 x（1卡5核30GB） 新購預留：1 x（1卡10核80GB） | 結果： 說明：容量預留可以抵扣存量的、合格隨用隨付Pod。 |