La reserva de capacidad basada en pods proporciona certeza de recursos para las cargas de trabajo elásticas. La reserva de capacidad de pods de GPU no requiere vincularse a un clúster específico. Al momento de la compra, especifique atributos como las especificaciones del pod, la zona de disponibilidad y la duración de la reserva. De este modo, el sistema garantiza que los pods coincidentes se inicien bajo demanda en cuestión de minutos, con un precio menor al de los pods pay-as-you-go.
Funciones
Certeza de recursos: durante el periodo de vigencia de una reserva de capacidad de pods de GPU, el sistema garantiza que los recursos se inicien correctamente.
Ahorro de costos: cuando un pod se inicia, se factura a la tarifa pay-as-you-go. Mientras el pod no está en ejecución, se le cobra a la tarifa más baja de la reserva de capacidad. Inicie y finalice los pods según sus necesidades de negocio.
Flexibilidad de recursos: cree reservas de capacidad de pods de GPU con distintas especificaciones de recursos para cubrir diversos requisitos de negocio.
La reserva de capacidad de pods de GPU no admite pods del tipo de cómputo BestEffort.
La reserva de capacidad de pods de GPU es compatible con savings plans que tengan atributos coincidentes, como la región y el tipo.
Crear una reserva de capacidad de pods de GPU está sujeto al inventario disponible.
Casos de uso
-
Demandas periódicas de recursos para cargas de trabajo en tiempo real: su negocio presenta patrones predecibles de demanda de recursos diarios o semanales, y las tareas deben completarse en tiempo real. Por ejemplo, servicios de inference en tiempo real.
-
Picos repentinos de demanda de recursos: su negocio tiene necesidades inesperadas de cómputo en tiempo real que requieren entrega y escalado rápidos de recursos para evitar impactos. Por ejemplo, picos provocados por eventos virales en un negocio de internet.
Ejemplo de uso y facturación
La reserva de capacidad de pods de GPU utiliza un modelo de facturación pay-as-you-go. Durante el periodo activo de una reserva de capacidad, sus cargos incluyen lo siguiente:
Cargos pay-as-you-go por la porción no utilizada de la reserva de capacidad.
Cargos pay-as-you-go por los pods iniciados.
A continuación se ilustra el flujo de trabajo y la facturación en distintas etapas, mediante un escenario con dos reservas de capacidad de pods de GPU y dos pods pay-as-you-go (Pod1 y Pod2).
Etapa 1: comprar y crear una reserva de capacidad
Antes de empezar, habilite la reserva de capacidad de GPU .
En la consola de Container Service, vaya a Capacity Reservations > Create GPU capacity reservation. Configure los parámetros y haga clic en Create capacity reservation.
|
Parámetro |
Descripción |
|
Capacity reservation name |
Nombre personalizado para la reserva de capacidad. |
|
Resource Reservation |
Tipo de GPU. |
|
Region |
Región donde desea reservar los recursos. |
|
Zone |
Zona de disponibilidad donde desea reservar los recursos. |
|
Resource Type |
Especificaciones de la reserva de capacidad. Seleccione la cantidad de GPU y el sistema asignará automáticamente las especificaciones máximas de vCPU y memoria disponibles para esa cantidad. |
|
Reservation mode |
Reserva de pods (no se puede modificar). |
|
Billing model |
Pay-as-you-go (no se puede modificar). |
|
Quantity |
Cantidad de reservas de capacidad de pods de GPU para las especificaciones de recursos indicadas. |
El cálculo de facturación para esta etapa es el siguiente:
|
Etapa |
Cargo |
Descripción |
|
Etapa 1 |
Ninguna |
No se ha creado ninguna reserva de capacidad. |
Etapas 2 a 6: periodo activo de la reserva
Durante el periodo activo, cree instancias de pod en cualquier momento, siempre que sus configuraciones no superen las especificaciones reservadas. El sistema garantiza que los pods se inicien correctamente y se utilice la reserva de capacidad correspondiente. La GPU (tipo y cantidad), la vCPU y la memoria del pod no deben superar la configuración reservada. Una coincidencia exitosa consume la reserva por completo. Por ejemplo, si compra una reserva de una GPU, 10 vCPU y 80 GB de memoria, y crea un pod con una GPU, una vCPU y 2 GB de memoria, la reserva se utiliza en su totalidad. Cuando el pod finaliza, la reserva de capacidad vuelve a estar disponible.
Los cálculos de facturación para estas etapas son los siguientes:
|
Etapa |
Cargo |
|
Etapa 2 |
2 × precio unitario de la reserva de capacidad × duración de la etapa 2 |
|
Etapa 3 |
1 × precio unitario de la reserva de capacidad × duración de la etapa 3 + precio unitario pay-as-you-go de Pod1 × duración de la etapa 3 |
|
Etapa 4 |
precio unitario pay-as-you-go de Pod1 × duración de la etapa 4 + precio unitario pay-as-you-go de Pod2 × duración de la etapa 4 |
|
Etapa 5 |
1 × precio unitario de la reserva de capacidad × duración de la etapa 5 + precio unitario pay-as-you-go de Pod2 × duración de la etapa 5 |
|
Etapa 6 |
2 × precio unitario de la reserva de capacidad × duración de la etapa 6 |
El precio unitario de una reserva de capacidad corresponde al cargo pay-as-you-go de una reserva no utilizada. Los precios unitarios pay-as-you-go de Pod1 y Pod2 son los cargos estándar de ese modelo para dichos pods después de iniciarse.
Etapa 7: vencimiento de la reserva
Cuando la reserva de capacidad vence, el sistema la libera automáticamente.
Especificaciones
Después de capacity reservation specification upgrade, se admiten los siguientes tipos y especificaciones de GPU:
|
Tipo de GPU |
GPU |
vCPU |
Memoria (GiB) |
|
L20 (GN8IS) |
1 (48 GB de memoria de video) |
16 |
128 |
|
2 (48 GB × 2 de memoria de video) |
32 |
230 |
|
|
4 (48 GB × 4 de memoria de video) |
64 |
460 |
|
|
8 (48 GB × 8 de memoria de video) |
128 |
920 |
|
|
T4 |
1 (16 GB de memoria de video) |
24 |
90 |
|
2 (16 GB × 2 de memoria de video) |
48 |
180 |
|
|
A10 |
1 (24 GB de memoria de video) |
16 |
60 |
|
2 (24 GB × 2 de memoria de video) |
32 |
120 |
|
|
4 (24 GB × 4 de memoria de video) |
64 |
240 |
|
|
8 (24 GB × 8 de memoria de video) |
128 |
480 |
|
|
P16EN |
1 (96 GB de memoria de video) |
10 |
80 |
|
2 (96 GB × 2 de memoria de video) |
22 |
225 |
|
|
4 (96 GB × 4 de memoria de video) |
46 |
450 |
|
|
8 (96 GB × 8 de memoria de video) |
92 |
900 |
|
|
16 (96 GB × 16 de memoria de video) |
184 |
1800 |
|
|
GU8TF |
1 (96 GB de memoria de video) |
16 |
128 |
|
2 (96 GB × 2 de memoria de video) |
46 |
230 |
|
|
4 (96 GB × 4 de memoria de video) |
92 |
460 |
|
|
8 (96 GB × 8 de memoria de video) |
184 |
920 |
|
|
GU8TEF |
1 (141 GB de memoria de video) |
22 |
225 |
|
2 (141 GB × 2 de memoria de video) |
46 |
450 |
|
|
4 (141 GB × 4 de memoria de video) |
92 |
900 |
|
|
8 (141 GB × 8 de memoria de video) |
184 |
1800 |
|
|
L20X (GX8SF) |
1 (141 GB de memoria de video) |
22 |
225 |
|
2 (141 GB × 2 de memoria de video) |
46 |
450 |
|
|
4 (141 GB × 4 de memoria de video) |
92 |
900 |
|
|
8 (141 GB × 8 de memoria de video) |
184 |
1800 |
Reglas de utilización
Para que un pod utilice una reserva de capacidad, deben cumplirse todas las condiciones siguientes:
El tipo de GPU del pod debe coincidir exactamente con el tipo de GPU reservado. Por ejemplo, tanto la reserva como el pod usan el tipo de GPU L20.
La cantidad de GPU del pod debe coincidir exactamente con la cantidad de GPU reservada. Por ejemplo, tanto la reserva como el pod corresponden a una GPU.
La cantidad de vCPU del pod debe ser menor o igual a la cantidad de vCPU reservada.
La cantidad de memoria del pod debe ser menor o igual a la cantidad de memoria reservada.
En los siguientes escenarios se asume que el tipo de GPU del pod coincide con el tipo de GPU reservado:
|
Principio de utilización |
Escenario |
Resultado y descripción |
|
Coincidencia exacta o compatibilidad descendente |
Reserva: 1 × (1 GPU, 16 vCPU, 128 GB). pod creado: 1 × (1 GPU, 8 vCPU, 16 GB). |
Resultado: Descripción: los requisitos de recursos del pod (cantidad de GPU, vCPU y memoria) no superan las especificaciones reservadas, por lo que la coincidencia es exitosa y la reserva se utiliza por completo. |
|
Primero la especificación más pequeña |
Reservas:
pod creado: 1 × (1 GPU, 5 vCPU, 30 GB). |
Resultado: Descripción: para maximizar la eficiencia de los recursos, el sistema prioriza la reserva disponible más pequeña que cubra los requisitos del pod. |
|
Primero en entrar, primero en salir (FIFO) |
Reservas: 4 × (1 GPU, 10 vCPU, 80 GB), creadas en momentos distintos. pods creados: 4 × (1 GPU, 5 vCPU, 30 GB). |
Resultado: Descripción: para reservas con especificaciones idénticas, se aplica el principio FIFO. |
|
Atomicidad de las especificaciones de varias GPU (indivisibles) |
Reserva: 1 × (4 GPU, 46 vCPU, 450 GB). pods creados: 4 × (1 GPU, 10 vCPU, 60 GB). |
Resultado: Descripción: una reserva de varias GPU es atómica y no se puede dividir para satisfacer varios pods más pequeños. Estos cuatro pods se crean como instancias pay-as-you-go. |
|
Coincidencia de especificaciones mixtas |
Reservas:
pods creados:
|
Resultado: Descripción: los demás pods no coinciden con la reserva restante de 4 GPU, por lo que se crean como instancias pay-as-you-go. |
|
Coincidencia dinámica en tiempo real |
Pod pay-as-you-go existente: 1 × (1 GPU, 5 vCPU, 30 GB) Nueva reserva comprada: 1 × (1 GPU, 10 vCPU, 80 GB) |
Resultado: Descripción: los pods pay-as-you-go existentes que cumplen los criterios de coincidencia pueden utilizar las reservas de capacidad. |