Scalability

L’évolutivité est la capacité d’un système à gérer une charge de travail croissante — plus de données, d’utilisateurs, de requêtes ou un modèle plus grand — en ajoutant des ressources tout en maintenant des performances et un coût par unité de travail acceptables. Un système évolue bien lorsque le doublement du matériel lui permet presque de doubler le travail effectué, et mal lorsque les machines ajoutées passent leur temps à s’attendre les unes les autres. En intelligence artificielle, l’évolutivité intervient à trois étapes : les pipelines de données qui doivent ingérer et prétraiter les mégadonnées, les tâches d’entraînement réparties sur de nombreux accélérateurs et les services d’inférence qui doivent répondre à davantage de requêtes sans augmenter la latence d’inférence.

Mise à l’échelle verticale et horizontale#

La mise à l’échelle verticale, ou montée en puissance, consiste à déplacer une charge de travail vers une machine plus puissante : davantage de cœurs CPU, plus de RAM ou un GPU doté de plus de mémoire. Elle ne nécessite aucune modification du code, mais elle est limitée à la machine la plus puissante disponible et laisse un point de défaillance unique. La mise à l’échelle horizontale, ou montée en charge, ajoute des machines et répartit le travail entre elles ; elle n’a pas de plafond fixe, mais exige que le logiciel répartisse le travail, équilibre la charge et coordonne les résultats. Les services Web et d’inférence se mettent facilement à l’échelle horizontale lorsqu’ils sont sans état, en conservant les sessions et les données dans des espaces de stockage partagés afin que n’importe quelle réplique puisse répondre à n’importe quelle requête ; les bases de données se mettent à l’échelle horizontale par partitionnement, en répartissant leurs données par clé entre les machines.

Les plateformes infonuagiques automatisent la mise à l’échelle horizontale. Sur Kubernetes, l’Horizontal Pod Autoscaler calcule le nombre de répliques en multipliant le nombre actuel par le rapport entre la métrique observée et sa valeur cible, puis en arrondissant au supérieur : 4 répliques utilisant en moyenne 90 % du CPU pour une cible de 60 % passent à 6. Cette automatisation correspond à l’élasticité dans l’informatique en nuage, et l’informatique sans serveur l’étend jusqu’à zéro réplique lorsque le trafic s’interrompt.

Limites de la mise à l’échelle#

Chaque tâche parallèle comprend une part de travail impossible à répartir, comme la lecture du lot suivant, la synchronisation des résultats ou l’écriture d’un point de contrôle. En 1967, Gene Amdahl a montré que cette fraction sérielle plafonne l’accélération, quel que soit le nombre de processeurs ajoutés. Ce résultat est maintenant appelé loi d’Amdahl :

# Amdahl's law: speedup on n workers when a fraction p of the work runs in parallel
p = 0.95  # parallel fraction; the other 5% runs on one worker

for n in (1, 8, 64, 512):
    speedup = 1 / ((1 - p) + p / n)
    efficiency = speedup / n  # share of the added hardware doing useful work
    print(f"{n:>4} workers: {speedup:5.1f}x speedup, {efficiency:4.0%} efficiency")

print(f"Limit with unlimited workers: {1 / (1 - p):.0f}x")

Lorsque 95 % du travail est parallélisable, 8 travailleurs offrent une accélération de 5,9x avec une efficacité de 74 %, 64 travailleurs une accélération de 15,4x avec une efficacité de 24 %, et 512 travailleurs une accélération de 19,3x avec une efficacité de 4 % ; aucun nombre de travailleurs ne peut dépasser 20x. En 1988, John Gustafson a fait remarquer que les utilisateurs réels augmentent la taille du problème avec celle de la machine : la partie parallèle augmente donc et la part sérielle diminue. Mesurer l’accélération sur un problème fixe s’appelle la mise à l’échelle forte ; augmenter la taille du problème avec le matériel s’appelle la mise à l’échelle faible, le régime dans lequel fonctionnent les grands entraînements. La communication impose une limite supplémentaire : chaque GPU ajouté à un entraînement parallèle sur les données doit échanger ses gradients avec les autres à chaque étape ; la bande passante réseau détermine donc souvent jusqu’où une tâche peut évoluer.

Mise à l’échelle de l’entraînement et de l’inférence#

L’entraînement distribué choisit une stratégie de parallélisme selon que le modèle tient ou non sur un seul appareil. En parallélisme des données, chaque GPU conserve une copie complète du modèle, traite sa propre partie de chaque lot et calcule la moyenne des gradients avec les autres au moyen d’une opération all-reduce, comme avec DistributedDataParallel de PyTorch. Les modèles trop volumineux pour un seul GPU sont répartis avec le parallélisme des données entièrement fragmenté, le parallélisme tensoriel ou le parallélisme en pipeline. L’accumulation des gradients permet d’atteindre de grandes tailles de lot effectives avec moins d’appareils.

Ultralytics YOLO utilise le parallélisme des données pour l’entraînement multi-GPU : passer device=[0, 1] lance des processus de travail DistributedDataParallel via torch.distributed.run et répartit le lot équitablement. Ainsi, batch=64 sur deux GPU donne 32 images par étape à chaque GPU.

L’inférence évolue différemment, car chaque requête est petite et indépendante. Le regroupement des requêtes en lots augmente l’utilisation du GPU et le débit au prix d’une légère hausse de la latence. Le regroupement continu applique le même principe à la génération des LLM token par token, et les systèmes de mise en service des modèles ajoutent des répliques derrière un répartiteur de charge lorsque le trafic augmente. La quantification des modèles et l’élagage réduisent le coût de chaque réplique, de sorte que le même matériel traite plus de requêtes. L’IA en périphérie passe à l’échelle en répartissant l’inférence sur des milliers d’appareils plutôt que dans un seul centre de données.

Évolutivité et notions connexes#

• Performances : Vitesse ou précision d’un système pour une charge donnée, mesurée par la latence, le débit ou la précision. L’évolutivité décrit la façon dont ces mesures résistent à l’augmentation de la charge et des ressources.
• Élasticité : Ajout et retrait automatiques de ressources en fonction de l’évolution de la demande au cours de la journée, le plus souvent en ajoutant et supprimant des répliques d’un service à mise à l’échelle horizontale.
• Lois d’échelle : Relations empiriques entre la perte d’un modèle, ses paramètres, ses données d’entraînement et les ressources de calcul. Elles prédisent la qualité du modèle, et l’évolutivité du système détermine si les ressources de calcul requises peuvent être utilisées efficacement.