基于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容量预留根据库存情况反馈创建是否成功。
使用场景
-
周期性实时业务的资源需求：业务在每天/每周的周期中呈现"潮汐"特征，任务需要保证实时执行和完成。例如实时推理业务等。
-
偶发性的大量资源需求：业务中存在突发性的实时计算需求，需要保证资源的快速交付和扩容，避免对业务的影响。例如互联网业务中的热点事件引发的资源需求等。
使用与计费示例
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。 |