Profils de charge IA : entraînement vs inférence
Distinguer les profils de charge entraînement et inférence pour anticiper leur impact sur l'infrastructure.
À retenir
- L'entraînement impose une charge soutenue proche de 100 % avec forte dépendance au réseau inter-GPU.
- L'inférence est variable, tolérante aux pannes et suit le trafic utilisateur.
- Les métriques et alertes pertinentes diffèrent totalement entre les deux profils.
- Le ratio training/inference conditionne le facteur de foisonnement électrique à retenir.
Deux charges, deux comportements
Les workloads d'intelligence artificielle ne se ressemblent pas tous : l'entraînement (training) et l'inférence sollicitent l'infrastructure de manière radicalement différente, et confondre les deux dans le dimensionnement mène à du sur-provisionnement ou, pire, à des incidents de production.
Entraînement : puissance soutenue et synchronisation
L'entraînement d'un grand modèle mobilise des centaines à des milliers de GPU pendant des jours ou semaines, avec une utilisation quasi constante proche de 100 % (« flat top » de charge), de gros volumes d'échanges inter-GPU (all-reduce) et une forte sensibilité à la latence réseau. Une seule carte lente ou un lien réseau dégradé ralentit l'ensemble du cluster car les GPU se synchronisent à chaque étape.
| Caractéristique | Entraînement | Inférence |
|---|---|---|
| Durée de charge | Jours à semaines, continue | Millisecondes à secondes, en rafales |
| Profil de puissance | Plateau élevé et stable | Pics variables selon le trafic |
| Sensibilité réseau | Très forte (all-reduce, NVLink/InfiniBand) | Modérée (latence de requête) |
| Tolérance à la panne | Faible (checkpoint coûteux) | Élevée (requête suivante indépendante) |
| Élasticité | Peu élastique pendant un run | Très élastique (autoscaling) |
Point clé
un cluster d'entraînement dimensionné pour tourner à charge constante ne doit jamais être confondu, en gestion capacitaire, avec une flotte d'inférence dont la charge suit le trafic utilisateur.
Inférence : variabilité et sensibilité à la latence
L'inférence, elle, répond à des requêtes utilisateur en temps réel. Sa charge suit des cycles journaliers marqués (pic en journée, creux la nuit) et exige une latence P99 basse. Contrairement à l'entraînement, une requête d'inférence peut être routée vers n'importe quel nœud disponible : la charge est massivement parallélisable et tolère la perte d'une instance sans tout arrêter.
Sur le terrain
dans un centre hébergeant les deux types de charge, il est fréquent de constater des courbes de consommation électrique en « plateau » pour les racks d'entraînement et en « dents de scie » corrélées au trafic pour les racks d'inférence — un bon diagnostic visuel avant même de consulter la télémétrie applicative.
Observabilité adaptée
Pour l'entraînement, les métriques clés sont l'utilisation GPU (nvidia_smi_utilization_gpu), la bande passante d'interconnexion et le temps passé en synchronisation collective. Pour l'inférence, on surveille plutôt la latence par requête, le débit (requêtes/s) et le taux d'erreur :
histogram_quantile(0.99, sum(rate(inference_request_duration_seconds_bucket[5m])) by (le))
Attention
appliquer les seuils d'alerte pensés pour l'inférence (latence P99) à un cluster d'entraînement n'a aucun sens : ce dernier doit être surveillé sur la durée du run et le taux d'échec de checkpoint, pas sur la latence de requête.
Impact sur le dimensionnement du site
Un site hébergeant de l'entraînement doit provisionner l'alimentation et le refroidissement pour une charge quasi constante au niveau nominal de la carte GPU, sans marge de foisonnement significative. Un site d'inférence pure peut, à l'inverse, exploiter du foisonnement électrique car toutes les instances n'atteignent jamais leur pic simultanément.
Astuce
demandez systématiquement le ratio training/inference prévu par le client avant de dimensionner l'alimentation électrique : ce seul paramètre change fondamentalement le facteur de foisonnement à retenir.