Comment mieux anticiper les pénuries de capacité pour l’IA

La capacité de l’infrastructure IA dépend de l’offre disponible et des contraintes associées à chaque charge de travail. Une demande qui fixe le temps d’exécution, la configuration machine, la zone et l’allocation d’accélérateurs ne peut utiliser que la capacité qui satisfait à ces quatre conditions. Google Cloud recommande d’assouplir certaines conditions lorsque la charge de travail le permet. Google Cloud commercialise l’infrastructure cloud et les services décrits ici, et a donc un intérêt commercial à ce que les clients adoptent ces mécanismes.

La capacité IA dépend des contraintes des charges de travail

Chaque charge de travail a des exigences et des préférences. Un service en ligne peut nécessiter une exécution immédiate parce que des clients attendent, tandis qu’une tâche de fine-tuning hors ligne peut tolérer un démarrage différé. Une génération de VM ou une zone particulière peut relever de la préférence plutôt que d’une exigence pour une exécution correcte. Les équipes plateforme peuvent exposer des alternatives acceptables au logiciel d’infrastructure tout en maintenant fixes les véritables contraintes.

Cette distinction modifie la question de planification. Les équipes doivent déterminer quelles fenêtres d’exécution, familles de machines, tailles, zones et allocations d’accélérateurs affectent la justesse, les performances ou les échéances métier. Elles peuvent ensuite classer les alternatives acceptables sur les dimensions restantes. Google Cloud présente cette approche comme un moyen de traiter le surprovisionnement, la capacité inutilisée et les goulets d’étranglement lorsque les systèmes d’IA et les applications conventionnelles partagent la même infrastructure.

Le même raisonnement s’applique lorsque le provisionnement échoue. Une capacité supplémentaire en accélérateurs peut encore être nécessaire, en particulier lorsque les contraintes de la charge de travail ne peuvent pas évoluer. Dans d’autres cas, élargir la fenêtre d’exécution approuvée, l’ensemble matériel, l’emplacement ou l’allocation d’accélérateurs donne à l’infrastructure davantage de moyens de répondre à la demande. La décision d’architecture consiste à déterminer quelles contraintes doivent rester fixes et lesquelles peuvent devenir des variables contrôlées.

Quatre variables peuvent élargir la capacité disponible

Google Cloud regroupe ces choix autour du temps, de la configuration matérielle, de l’emplacement et de la quantité d’accélérateurs. Chaque variable donne à un ordonnanceur davantage de résultats acceptables lorsqu’une application peut tolérer ce changement.

Le temps est le premier choix. Le Dynamic Workload Scheduler de Google Cloud est conçu pour fournir un accès à des ressources rares, notamment les GPU, les TPU et certaines familles de machines virtuelles basées sur CPU. Son mode calendrier cible les tâches nécessitant des ressources à un moment fixe pendant une période définie. Flex-start permet aux tâches tolérantes à la latence d’attendre une capacité disponible ; Google Cloud cite comme exemples le traitement par lots, l’entraînement de modèles et le fine-tuning hors ligne.

Pour les équipes plateforme, la distinction est opérationnelle. Une tâche assortie d’une échéance métier fixe peut malgré tout disposer d’une marge sur son heure exacte de démarrage. Encoder cette marge donne au fournisseur une fenêtre plus large pour satisfaire la demande. Les équipes doivent donc classer les tâches qui peuvent attendre et le niveau de délai que leurs échéances autorisent.

La configuration matérielle est le deuxième choix. Google Cloud recommande la flexibilité des instances dans les groupes d’instances gérés ainsi que la création en masse de machines virtuelles pour les utilisateurs de Compute Engine. Les opérateurs peuvent proposer plusieurs options compatibles, permettant au système de choisir une configuration approuvée en fonction de la disponibilité en temps réel. La tâche d’architecture consiste alors à définir quelles configurations machine peuvent exécuter correctement la charge de travail.

Cette politique peut aussi accompagner le renouvellement matériel. Une liste hiérarchisée peut donner la priorité aux générations les plus récentes de machines virtuelles tout en conservant les générations plus anciennes comme solutions de repli. Cela ne fonctionne que si ces générations plus anciennes continuent de répondre aux exigences de l’application.

L’emplacement est le troisième choix. Google Cloud recommande d’utiliser plusieurs zones au sein d’une région lorsqu’une charge de travail peut tolérer ce placement. Approuver plusieurs zones permet aux systèmes de provisionnement de considérer la capacité sur un ensemble de placement plus large. Une exigence mono-zone reste appropriée lorsque l’application en dépend réellement.

Les ComputeClasses personnalisées de Google Kubernetes Engine combinent les choix de matériel et d’emplacement. Google Cloud indique que les équipes plateforme peuvent définir des combinaisons acceptables de familles de machines, tailles, ratios de performance, modèles tarifaires et zones, puis les classer par priorité. Si la configuration de nœud préférée n’est pas disponible, Google Kubernetes Engine peut passer à une autre option approuvée. La plateforme peut alors sélectionner parmi des configurations que les équipes applicatives et d’infrastructure ont déjà validées.

Le repli nécessite aussi une politique de retour. La migration active de Google Cloud déplace les charges de travail vers des configurations de priorité plus élevée lorsque ces configurations deviennent disponibles, offrant un tel mécanisme dans Google Kubernetes Engine. Une solution de repli temporaire peut ainsi rester temporaire lorsque la capacité préférée revient. Les équipes doivent néanmoins décider quelles charges de travail doivent être déplacées et quelles configurations sont considérées comme préférées.

La quantité d’accélérateurs est le quatrième choix. Google Cloud met en avant l’allocation dynamique des ressources dans Google Kubernetes Engine comme moyen pour les applications de demander une partie d’un GPU ou d’un TPU, y compris des exigences exprimées en mémoire ou en nombre de cœurs. La plateforme attribue ensuite une portion correspondante du matériel. Lorsque les exigences d’isolation et de performance permettent le partage, cela peut mieux aligner l’allocation des accélérateurs sur les besoins en ressources de l’application.

Google Cloud présente ce mécanisme comme une réponse au sous-usage des accélérateurs lorsqu’ils sont alloués en grands blocs. Son effet métier dépend de la forme des charges de travail, des exigences de performance et des contraintes de partage propres à chaque organisation. Les dirigeants peuvent l’évaluer en mesurant l’utilisation des accélérateurs et les performances des charges de travail dans leur propre environnement. Ces mesures peuvent montrer si une allocation plus fine modifie l’économie d’une charge de travail donnée.

D’autres dépendances peuvent contraindre cette même charge de travail. Google Cloud indique que Compute Engine peut utiliser les signaux de capacité des machines virtuelles Spot et privilégier les types de machines susceptibles d’offrir une durée de fonctionnement plus longue avec un risque de préemption plus faible ; la préemption signifie que le fournisseur peut récupérer cette capacité Spot. Pour le stockage, Google Cloud recommande les paramètres de disque par défaut de base pour de nombreuses instances de courte durée de vie, et Hyperdisk lorsque les disques de données doivent survivre aux machines virtuelles associées à travers plusieurs générations de machines. Ces recommandations étendent la substitution au-delà du choix initial de calcul.

La capacité garantie répond à une demande prévisible

Certains profils de demande justifient de sécuriser les ressources à l’avance. Google Cloud le recommande explicitement pour une demande prévisible, comme les lancements de produits, les migrations, les exécutions d’entraînement hors ligne et les pics de trafic saisonniers. Le mode calendrier de Dynamic Workload Scheduler répond aux exigences à heure fixe et durée définie. Google Cloud conseille également aux clients d’envisager des modèles d’engagement de dépenses offrant des remises tout en préservant la flexibilité entre types de machines et emplacements.

La décision dépend de la prévisibilité et de la tolérance de la charge de travail. Une migration qui doit s’exécuter pendant une fenêtre planifiée peut justifier une planification de capacité en amont. Une hausse inattendue provoquée par un événement d’actualité ou un changement de marché appelle une réponse différente, car son calendrier est incertain. Des configurations de repli prédéfinies et des choix de placement plus larges donnent alors à l’infrastructure davantage d’options approuvées.

Les charges de travail tolérantes au délai créent un autre mode opératoire. Le traitement par lots ou une exécution d’entraînement hors ligne avec une heure de démarrage flexible peuvent utiliser flex-start. Les machines virtuelles Spot peuvent aussi être candidates lorsque les applications peuvent supporter le risque de préemption. Le propriétaire de la charge de travail doit donc préciser le niveau d’incertitude acceptable concernant l’heure de démarrage, la continuité et la configuration matérielle.

Les réservations et les politiques de repli traitent des risques distincts et peuvent coexister sur une même plateforme. Les réservations sécurisent la capacité pour des exigences prévisibles. Les politiques de repli élargissent les ressources capables de satisfaire une charge de travail lorsque la capacité préférée n’est pas disponible. Différentes applications, ou différentes phases d’une même application, peuvent nécessiter des combinaisons différentes des deux.

Le modèle opérationnel s’articule autour de résultats acceptables

Cette approche exige des politiques qui définissent des résultats d’exécution acceptables. Les équipes plateforme peuvent classer les familles et tailles de machines, approuver des zones, identifier les charges de travail qui peuvent être mises en file d’attente, définir les cas où le partage des accélérateurs est sûr et préciser les modèles tarifaires acceptables. Ces décisions déterminent la marge de choix dont dispose le logiciel d’infrastructure lorsque la capacité préférée n’est pas disponible. Elles déplacent aussi des décisions clés hors de la fenêtre d’incident pour les intégrer à l’architecture et à la politique plateforme.

Les ComputeClasses personnalisées illustrent ce modèle opérationnel. Une équipe plateforme peut encoder de manière centralisée des combinaisons de famille de machines, taille, ratio de performance, modèle tarifaire et zone. Les équipes applicatives peuvent ensuite consommer des politiques dont les choix de repli ont déjà été approuvés. La rareté déclenche une substitution prédéfinie au lieu de forcer les équipes à inventer des alternatives sous pression opérationnelle.

L’architecture applicative fixe la limite de cette liberté. Une charge de travail couplée à une génération de machine spécifique donne à l’ordonnanceur moins de choix acceptables. Il en va de même lorsqu’une application nécessite une seule zone ou un accélérateur entier. Les équipes plateforme et applicatives doivent donc identifier ce couplage et décider si sa modification justifie l’effort d’ingénierie.

Certaines contraintes resteront fixes parce que la justesse, les performances ou les échéances métier l’exigent. Les charges de travail liées à une famille de machines, un type de machine, une zone ou une fenêtre d’exécution particulière disposent de moins d’options de substitution. Les applications qui ne peuvent pas tolérer le partage d’accélérateurs ou la préemption Spot réduisent également les choix disponibles. Dans ces cas, la planification de capacité doit respecter l’exigence fixe et sécuriser les ressources en conséquence.

La décision métier peut être testée charge de travail par charge de travail. Les équipes peuvent identifier les contraintes requises pour la justesse, les performances et les échéances, encoder des alternatives approuvées, et mesurer l’utilisation, le comportement de provisionnement et les performances des charges de travail dans leur propre environnement. Cela transforme la flexibilité en politique d’ingénierie explicite avec des résultats observables et donne aux dirigeants une base concrète pour décider où une offre supplémentaire reste nécessaire.

Points clés

• La capacité IA dépend des contraintes des charges de travail : Les dirigeants doivent distinguer les exigences fixes des préférences en matière de temps d’exécution, de matériel, d’emplacement et d’allocation d’accélérateurs. Assouplir les contraintes non essentielles peut donner à l’infrastructure davantage de moyens de répondre à la demande.
• Quatre variables peuvent élargir la capacité disponible : Les équipes plateforme doivent définir une flexibilité approuvée concernant le temps, la configuration matérielle, l’emplacement et la quantité d’accélérateurs. Les mécanismes de Google Cloud peuvent ensuite utiliser ces alternatives lorsque la capacité préférée n’est pas disponible.
• La capacité garantie répond à une demande prévisible : Réservez de la capacité pour les charges de travail dont le calendrier est connu et les exigences fixes, tout en utilisant des politiques de repli pour une demande moins prévisible. Les deux approches répondent à des risques de capacité différents et peuvent être combinées.
• Le modèle opérationnel s’articule autour de résultats acceptables : Encodez les choix de repli avant que la capacité ne devienne rare, y compris le matériel approuvé, les zones, les délais d’ordonnancement et les politiques de partage. Mesurez le provisionnement, l’utilisation et les performances des charges de travail pour déterminer où la flexibilité fonctionne et où une offre supplémentaire reste nécessaire.