GPU pod capacity reservation - Container Compute Service - Centre de documentation Alibaba Cloud

La réservation de capacité basée sur les pods garantit la disponibilité des ressources pour les charges de travail élastiques. La réservation de capacité pour pods GPU ne nécessite pas d'association à un cluster spécifique. Lors de l'achat, spécifiez des attributs tels que les spécifications du pod, la zone de disponibilité et la durée de réservation. Le système assure alors le lancement des pods correspondants à la demande en quelques minutes, à un tarif inférieur à celui des pods en paiement à l'utilisation.

Fonctionnalités

Garantie des ressources : pendant la période de validité d'une réservation de capacité pour pods GPU, le système garantit le lancement réussi des ressources.
Réduction des coûts : un pod lancé est facturé au tarif de paiement à l'utilisation. Lorsqu'il n'est pas en cours d'exécution, la facturation s'effectue au tarif réduit de réservation de capacité. Lancez et arrêtez les pods selon vos besoins métier.
Flexibilité des ressources : créez des réservations de capacité pour pods GPU avec différentes spécifications afin de répondre à divers besoins métier.

Remarque

La réservation de capacité pour pods GPU ne prend pas en charge les pods de type de calcul BestEffort.
Ce service est compatible avec les Savings Plans dont les attributs correspondent, tels que la région et le type.
La création d'une réservation de capacité pour pods GPU dépend du stock disponible.

Cas d'utilisation

Besoins périodiques en ressources pour des charges de travail en temps réel : votre activité présente des schémas de demande quotidiens ou hebdomadaires prévisibles, et les tâches doivent s'exécuter en temps réel (par exemple, des services d'inférence en temps réel).
Pics soudains de demande : votre entreprise fait face à des besoins imprévus en calcul temps réel nécessitant une mise à disposition et une mise à l'échelle rapides des ressources pour éviter tout impact négatif. C'est le cas lors de pics déclenchés par des événements viraux dans une activité Internet.

Exemple d'utilisation et de facturation

La réservation de capacité pour pods GPU repose sur un modèle de facturation à l'utilisation. Pendant la période active d'une réservation, vos frais se composent :

Des frais de paiement à l'utilisation pour la partie non utilisée de la réservation de capacité.
Des frais de paiement à l'utilisation pour les pods lancés.

L'exemple suivant illustre le flux de travail et la facturation aux différentes étapes, basé sur un scénario comprenant deux réservations de capacité pour pods GPU et deux pods en paiement à l'utilisation (Pod1 et Pod2).

Étape 1 : Achat et création d'une réservation de capacité

Avant de commencer, Activez la réservation de capacité GPU .

Dans la console Container Service, accédez à Capacity Reservations > Create GPU capacity reservation. Configurez les paramètres et cliquez sur Create capacity reservation.

Paramètre

Description

Capacity reservation name

Nom personnalisé pour la réservation de capacité.

Resource Reservation

Type de GPU.

Region

Région dans laquelle vous souhaitez réserver des ressources.

Zone

Zone de disponibilité dans laquelle vous souhaitez réserver des ressources.

Resource Type

Spécifications de la réservation de capacité. Sélectionnez le nombre de GPU ; le système associe automatiquement les spécifications vCPU et mémoire les plus élevées disponibles pour ce nombre de GPU.

Reservation mode

Réservation de pod (non modifiable).

Billing model

Paiement à l'utilisation (non modifiable).

Quantity

Nombre de réservations de capacité pour pods GPU correspondant aux spécifications de ressources indiquées.

Le calcul de facturation pour cette étape est le suivant :

Étape

Frais

Description

Étape 1

Aucun

Aucune réservation de capacité n'a encore été créée.

Étapes 2 à 6 : Période active de la réservation

Pendant la période active, créez des instances de pod à tout moment, à condition que leurs configurations ne dépassent pas les spécifications réservées. Le système garantit le lancement réussi des pods et la réservation de capacité correspondante est consommée. Le GPU du pod (type et quantité), les vCPU et la mémoire ne doivent pas excéder la configuration réservée. Une correspondance réussie consomme entièrement la réservation. Par exemple, si vous achetez une réservation pour un GPU, 10 vCPU et 80 Go de mémoire, puis créez un pod avec un GPU, un vCPU et 2 Go de mémoire, la réservation est totalement utilisée. Lorsque le pod est arrêté, la réservation de capacité redevient disponible.

Les calculs de facturation pour ces étapes sont les suivants :

Étape

Frais

Étape 2

2 × prix unitaire de la réservation de capacité × Durée de l'étape 2

Étape 3

1 × prix unitaire de la réservation de capacité × Durée de l'étape 3 +

prix unitaire paiement à l'utilisation du Pod1 × Durée de l'étape 3

Étape 4

prix unitaire paiement à l'utilisation du Pod1 × Durée de l'étape 4 +

prix unitaire paiement à l'utilisation du Pod2 × Durée de l'étape 4

Étape 5

1 × prix unitaire de la réservation de capacité × Durée de l'étape 5 +

prix unitaire paiement à l'utilisation du Pod2 × Durée de l'étape 5

Étape 6

2 × prix unitaire de la réservation de capacité × Durée de l'étape 6

Le prix unitaire d'une réservation de capacité correspond aux frais de paiement à l'utilisation pour une réservation non utilisée. Les prix unitaires à l'utilisation du Pod1 et du Pod2 correspondent aux frais standard de paiement à l'utilisation pour ces pods après leur lancement.

Étape 7 : Expiration de la réservation

À l'expiration de la réservation de capacité, le système la libère automatiquement.

Spécifications

Suite à la mise à niveau des spécifications de réservation de capacité, les types et spécifications GPU suivants sont pris en charge :

Type de GPU	GPU	vCPU	Mémoire (Gio)
L20 (GN8IS)	1 (mémoire vidéo de 48 Go)	16	128
	2 (mémoire vidéo de 48 Go × 2)	32	230
	4 (mémoire vidéo de 48 Go × 4)	64	460
	8 (mémoire vidéo de 48 Go × 8)	128	920
T4	1 (mémoire vidéo de 16 Go)	24	90
T4	2 (mémoire vidéo de 16 Go × 2)	48	180
A10	1 (mémoire vidéo de 24 Go)	16	60
	2 (mémoire vidéo de 24 Go × 2)	32	120
	4 (mémoire vidéo de 24 Go × 4)	64	240
	8 (mémoire vidéo de 24 Go × 8)	128	480
P16EN	1 (mémoire vidéo de 96 Go)	10	80
	2 (mémoire vidéo de 96 Go × 2)	22	225
	4 (mémoire vidéo de 96 Go × 4)	46	450
	8 (mémoire vidéo de 96 Go × 8)	92	900
	16 (mémoire vidéo de 96 Go × 16)	184	1800
GU8TF	1 (mémoire vidéo de 96 Go)	16	128
	2 (mémoire vidéo de 96 Go × 2)	46	230
	4 (mémoire vidéo de 96 Go × 4)	92	460
	8 (mémoire vidéo de 96 Go × 8)	184	920
GU8TEF	1 (mémoire vidéo de 141 Go)	22	225
	2 (mémoire vidéo de 141 Go × 2)	46	450
	4 (mémoire vidéo de 141 Go × 4)	92	900
	8 (mémoire vidéo de 141 Go × 8)	184	1800
L20X (GX8SF)	1 (mémoire vidéo de 141 Go)	22	225
	2 (mémoire vidéo de 141 Go × 2)	46	450
	4 (mémoire vidéo de 141 Go × 4)	92	900
	8 (mémoire vidéo de 141 Go × 8)	184	1800

Règles d'utilisation

Pour qu'un pod utilise une réservation de capacité, toutes les conditions suivantes doivent être remplies :

Le type de GPU du pod doit correspondre exactement au type de GPU réservé. Par exemple, la réservation et le pod utilisent tous deux le type de GPU L20.
Le nombre de GPU du pod doit correspondre exactement au nombre de GPU réservés. Par exemple, la réservation et le pod portent tous deux sur un seul GPU.
Le nombre de vCPU du pod doit être inférieur ou égal au nombre de vCPU réservés.
La quantité de mémoire du pod doit être inférieure ou égale à la quantité de mémoire réservée.

Les scénarios suivants supposent que le type de GPU du pod correspond au type de GPU réservé :

Principe d'utilisation

Scénario

Résultat et description

Correspondance exacte ou compatibilité descendante

Réservation : 1 × (1 GPU, 16 vCPU, 128 Go).

pod créé : 1 × (1 GPU, 8 vCPU, 16 Go).

Résultat : $✓$ Utilisation réussie.

Description : les besoins en ressources du pod (nombre de GPU, vCPU et mémoire) ne dépassent pas les spécifications réservées. La correspondance aboutit et la réservation est entièrement consommée.

Priorité à la plus petite spécification

Réservations :

1 × (1 GPU, 10 vCPU, 80 Go).
1 × (1 GPU, 16 vCPU, 128 Go).

pod créé : 1 × (1 GPU, 5 vCPU, 30 Go).

Résultat : $✓$ La réservation pour 1 GPU, 10 vCPU et 80 Go est utilisée en priorité.

Description : afin d'optimiser l'efficacité des ressources, le système privilégie la plus petite réservation disponible satisfaisant les exigences du pod.

Premier entré, premier sorti (FIFO)

Réservations : 4 × (1 GPU, 10 vCPU, 80 Go), créées à des moments différents.

pods créés : 4 × (1 GPU, 5 vCPU, 30 Go).

Résultat : $✓$ Les quatre pods utilisent les quatre réservations selon leur ordre de création, de la plus ancienne à la plus récente.

Description : pour des réservations aux spécifications identiques, le principe FIFO s'applique.

Atomicité des spécifications multi-GPU (indivisibles)

Réservation : 1 × (4 GPU, 46 vCPU, 450 Go).

pods créés : 4 × (1 GPU, 10 vCPU, 60 Go).

Résultat : $\times$ La réservation n'est pas utilisée.

Description : une réservation multi-GPU est atomique et ne peut être scindée pour satisfaire plusieurs pods plus petits. Ces quatre pods sont donc créés en tant qu'instances en paiement à l'utilisation.

Correspondance de spécifications mixtes

Réservations :

1 × (2 GPU, 22 vCPU, 225 Go).
1 × (4 GPU, 46 vCPU, 450 Go).

pods créés :

2 × (1 GPU, 12 vCPU, 60 Go).
2 × (2 GPU, 20 vCPU, 120 Go).

Résultat : $\times$ Seul un pod avec 2 GPU, 20 vCPU et 120 Go utilise avec succès la réservation pour 2 GPU, 22 vCPU et 225 Go.

Description : les autres pods ne peuvent pas être associés à la réservation restante de 4 GPU et sont par conséquent créés en tant qu'instances en paiement à l'utilisation.

Correspondance dynamique en temps réel

Pod existant en paiement à l'utilisation : 1 × (1 GPU, 5 vCPU, 30 Go)

Nouvelle réservation achetée : 1 × (1 GPU, 10 vCPU, 80 Go)

Résultat : $✓$ Une fois la nouvelle réservation créée avec succès, elle s'associe immédiatement et automatiquement au pod existant en paiement à l'utilisation pour l'utiliser.

Description : les réservations de capacité peuvent être utilisées par des pods existants en paiement à l'utilisation qui satisfont aux critères de correspondance.