基於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。 |