Reserva de capacidade de pods GPU - Container Compute Service: Central de Documentação do Alibaba Cloud

A reserva de capacidade baseada em pods oferece garantia de recursos para workloads elásticos. A reserva de capacidade de pods GPU não exige vinculação a um cluster específico. Especifique atributos como especificações do pod, zona de disponibilidade e duração da reserva no momento da compra. O sistema garante a inicialização sob demanda dos pods correspondentes em poucos minutos, com preço inferior ao dos pods de pagamento conforme o uso.

Recursos

Garantia de recursos: Durante o período de vigência de uma reserva de capacidade de pods GPU, o sistema assegura a inicialização bem-sucedida dos recursos.
Economia de custos: Após a inicialização de um pod, a cobrança ocorre pela taxa de pagamento conforme o uso. Quando o pod não está em execução, aplica-se a taxa reduzida de reserva de capacidade. Inicie e encerre os pods conforme as necessidades do seu negócio.
Flexibilidade de recursos: Crie reservas de capacidade de pods GPU com diferentes especificações para atender a diversos requisitos de negócio.

Nota

A reserva de capacidade de pods GPU não suporta pods do tipo de computação BestEffort.
Essa reserva é compatível com Savings Plans que possuam atributos correspondentes, como região e tipo.
A criação de uma reserva de capacidade de pods GPU está sujeita à disponibilidade de estoque.

Casos de uso

Demandas periódicas de recursos para workloads em tempo real: Seu negócio apresenta padrões previsíveis de demanda diária ou semanal, e as tarefas precisam ser concluídas em tempo real. Por exemplo, serviços de inferência em tempo real.
Picos repentinos de demanda: Seu negócio enfrenta necessidades inesperadas de computação em tempo real que exigem entrega rápida de recursos e dimensionamento para evitar impactos. Por exemplo, picos gerados por eventos virais em negócios na internet.

Exemplo de uso e faturamento

A reserva de capacidade de pods GPU utiliza o modelo de faturamento de pagamento conforme o uso. Durante o período ativo de uma reserva, suas taxas incluem:

Taxas de pagamento conforme o uso referentes à parte não utilizada da reserva de capacidade.
Taxas de pagamento conforme o uso referentes aos pods iniciados.

O exemplo a seguir ilustra o fluxo de trabalho e o faturamento em diferentes etapas, considerando um cenário com duas reservas de capacidade de pods GPU e dois pods de pagamento conforme o uso (Pod1 e Pod2).

Etapa 1: Comprar e criar uma reserva de capacidade

Antes de começar, Ative a reserva de capacidade GPU.

No Container Service console, acesse Capacity Reservations > Create GPU capacity reservation. Configure os parâmetros e clique em Create capacity reservation.

Parâmetro	Descrição
Capacity reservation name	Nome personalizado para a reserva de capacidade.
Reservation type	Tipo de GPU.
Region	Região onde você deseja reservar recursos.
Availability zone	Zona de disponibilidade onde você deseja reservar recursos.
Resource specification	Especificações da reserva de capacidade. Selecione a quantidade de GPUs e o sistema corresponderá automaticamente às maiores especificações de vCPU e memória disponíveis para essa quantidade.
Reservation mode	Reserva de pod (não modificável).
Billing model	Pagamento conforme o uso (não modificável).
Quantity	Quantidade de reservas de capacidade de pods GPU para as especificações de recurso indicadas.

O cálculo de faturamento para esta etapa é o seguinte:

Etapa	Taxa	Descrição
Etapa 1	Nenhuma	Nenhuma reserva de capacidade foi criada.

Etapas 2–6: Período ativo da reserva

Durante o período ativo, crie instâncias de pod a qualquer momento, desde que suas configurações não excedam as especificações reservadas. O sistema garante a inicialização bem-sucedida dos pods e a utilização da reserva de capacidade correspondente. A GPU (tipo e quantidade), vCPU e memória do pod não devem ultrapassar a configuração reservada. Uma correspondência bem-sucedida utiliza totalmente a reserva. Por exemplo, se você adquirir uma reserva para uma GPU, 10 vCPUs e 80 GB de memória e criar um pod com uma GPU, uma vCPU e 2 GB de memória, a reserva será totalmente utilizada. Ao encerrar o pod, a reserva de capacidade fica disponível novamente.

Os cálculos de faturamento para estas etapas são os seguintes:

Etapa	Taxa
Etapa 2	2 × preço unitário da reserva de capacidade × Duração da Etapa 2
Etapa 3	1 × preço unitário da reserva de capacidade × Duração da Etapa 3 + preço unitário de pagamento conforme o uso do Pod1 × Duração da Etapa 3
Etapa 4	preço unitário de pagamento conforme o uso do Pod1 × Duração da Etapa 4 + preço unitário de pagamento conforme o uso do Pod2 × Duração da Etapa 4
Etapa 5	1 × preço unitário da reserva de capacidade × Duração da Etapa 5 + preço unitário de pagamento conforme o uso do Pod2 × Duração da Etapa 5
Etapa 6	2 × preço unitário da reserva de capacidade × Duração da Etapa 6

O preço unitário de uma reserva de capacidade corresponde à taxa de pagamento conforme o uso para uma reserva não utilizada. Os preços unitários de pagamento conforme o uso do Pod1 e do Pod2 referem-se às taxas padrão aplicáveis a esses pods após a inicialização.

Etapa 7: Expiração da reserva

Quando a reserva de capacidade expira, o sistema a libera automaticamente.

Especificações

Após a atualização de especificações de reserva de capacidade, os seguintes tipos e especificações de GPU são suportados:

Tipo de GPU	GPU	vCPU	Memória (GiB)
L20 (GN8IS)	1 (48 GB de memória de vídeo)	16	128
	2 (48 GB × 2 de memória de vídeo)	32	230
	4 (48 GB × 4 de memória de vídeo)	64	460
	8 (48 GB × 8 de memória de vídeo)	128	920
T4	1 (16 GB de memória de vídeo)	24	90
T4	2 (16 GB × 2 de memória de vídeo)	48	180
A10	1 (24 GB de memória de vídeo)	16	60
	2 (24 GB × 2 de memória de vídeo)	32	120
	4 (24 GB × 4 de memória de vídeo)	64	240
	8 (24 GB × 8 de memória de vídeo)	128	480
P16EN	1 (96 GB de memória de vídeo)	10	80
	2 (96 GB × 2 de memória de vídeo)	22	225
	4 (96 GB × 4 de memória de vídeo)	46	450
	8 (96 GB × 8 de memória de vídeo)	92	900
	16 (96 GB × 16 de memória de vídeo)	184	1800
GU8TF	1 (96 GB de memória de vídeo)	16	128
	2 (96 GB × 2 de memória de vídeo)	46	230
	4 (96 GB × 4 de memória de vídeo)	92	460
	8 (96 GB × 8 de memória de vídeo)	184	920
GU8TEF	1 (141 GB de memória de vídeo)	22	225
	2 (141 GB × 2 de memória de vídeo)	46	450
	4 (141 GB × 4 de memória de vídeo)	92	900
	8 (141 GB × 8 de memória de vídeo)	184	1800
L20X (GX8SF)	1 (141 GB de memória de vídeo)	22	225
	2 (141 GB × 2 de memória de vídeo)	46	450
	4 (141 GB × 4 de memória de vídeo)	92	900
	8 (141 GB × 8 de memória de vídeo)	184	1800

Regras de utilização

Para que um pod utilize uma reserva de capacidade, todas as condições a seguir devem ser atendidas:

O tipo de GPU do pod deve corresponder exatamente ao tipo de GPU reservado. Por exemplo, tanto a reserva quanto o pod utilizam o tipo de GPU L20.
A quantidade de GPUs do pod deve corresponder exatamente à quantidade reservada. Por exemplo, tanto a reserva quanto o pod são para uma GPU.
A quantidade de vCPUs do pod deve ser menor ou igual à quantidade de vCPUs reservada.
A quantidade de memória do pod deve ser menor ou igual à quantidade de memória reservada.

Os cenários a seguir consideram que o tipo de GPU do pod corresponde ao tipo de GPU reservado:

Princípio de utilização

Cenário

Resultado e descrição

Correspondência exata ou compatibilidade retroativa

Reserva: 1 × (1 GPU, 16 vCPUs, 128 GB).

pod criado: 1 × (1 GPU, 8 vCPUs, 16 GB).

Resultado: $✓$ Utilização bem-sucedida.

Descrição: Os requisitos de recursos do pod (quantidade de GPUs, vCPUs e memória) não excedem as especificações reservadas, portanto a correspondência é bem-sucedida e a reserva é totalmente utilizada.

Menor especificação primeiro

Reservas:

1 × (1 GPU, 10 vCPUs, 80 GB).
1 × (1 GPU, 16 vCPUs, 128 GB).

pod criado: 1 × (1 GPU, 5 vCPUs, 30 GB).

Resultado: $✓$ A reserva de 1 GPU, 10 vCPUs e 80 GB é utilizada primeiro.

Descrição: Para maximizar a eficiência dos recursos, o sistema prioriza a menor reserva disponível que atenda aos requisitos do pod.

First-In, First-Out (FIFO)

Reservas: 4 × (1 GPU, 10 vCPUs, 80 GB), criadas em momentos diferentes.

pods criados: 4 × (1 GPU, 5 vCPUs, 30 GB).

Resultado: $✓$ Os quatro pods utilizam as quatro reservas na ordem em que foram criadas, da mais antiga para a mais recente.

Descrição: Para reservas com especificações idênticas, aplica-se o princípio FIFO.

Atomicidade de especificações multi-GPU (indivisível)

Reserva: 1 × (4 GPUs, 46 vCPUs, 450 GB).

pods criados: 4 × (1 GPU, 10 vCPUs, 60 GB).

Resultado: $\times$ A reserva não é utilizada.

Descrição: Uma reserva multi-GPU é atômica e não pode ser dividida para atender a vários pods menores. Esses quatro pods são criados como instâncias de pagamento conforme o uso.

Correspondência de especificações mistas

Reservas:

1 × (2 GPUs, 22 vCPUs, 225 GB).
1 × (4 GPUs, 46 vCPUs, 450 GB).

pods criados:

2 × (1 GPU, 12 vCPUs, 60 GB).
2 × (2 GPUs, 20 vCPUs, 120 GB).

Resultado: $\times$ Apenas um pod com 2 GPUs, 20 vCPUs e 120 GB utiliza com sucesso a reserva de 2 GPUs, 22 vCPUs e 225 GB.

Descrição: Os demais pods não podem ser correspondidos à reserva restante de 4 GPUs e, portanto, são criados como instâncias de pagamento conforme o uso.

Correspondência dinâmica em tempo real

Pod existente de pagamento conforme o uso: 1 × (1 GPU, 5 vCPUs, 30 GB)

Nova reserva adquirida: 1 × (1 GPU, 10 vCPUs, 80 GB)

Resultado: $✓$ Após a criação bem-sucedida da nova reserva, ela corresponde e utiliza imediata e automaticamente o pod existente de pagamento conforme o uso.

Descrição: As reservas de capacidade podem ser utilizadas por pods existentes de pagamento conforme o uso que atendam aos critérios de correspondência.