Technical Tutorials

Alors que les grands modèles de langage (LLM) continuent de croître en taille et en capacité, les exigences matérielles pour leur service sont devenues un goulot d'étranglement majeur. Passer de l'entraînement à l'inférence n'est pas une tâche anodine ; si l'entraînement nécessite une puissance de calcul massive, le service exige une faible latence, un haut débit et une utilisation efficace des ressources. Lorsqu'un seul GPU ne peut pas contenir les poids du modèle ou lorsque la taille du lot est suffisamment grande pour saturer une seule carte, les ingénieurs doivent se tourner vers l'inférence distribuée multi-nœuds.

Cet article explore les stratégies fondamentales pour mettre à l'échelle le service des LLM, en se concentrant sur le parallélisme de modèle, le parallélisme de données et l'orchestration nécessaire pour assembler efficacement ces éléments.

Comprendre les types de parallélisme

Pour dépasser les limites d'un seul dispositif, nous devons décomposer le calcul du modèle. Les trois paradigmes principaux sont le parallélisme de tenseurs, le parallélisme de pipeline et le parallélisme de données.

Le parallélisme de tenseurs (TP) divise les tenseurs individuels au sein d'une couche sur plusieurs GPU. Par exemple, dans une multiplication matricielle $Y = XW$, $W$ est divisé colonne par colonne sur les GPU. Cela nécessite des communications fréquentes de type all-to-all entre les dispositifs, car chaque GPU a besoin des résultats intermédiaires des autres pour terminer le calcul de la couche. Le TP est idéal pour adapter des modèles très larges sur plusieurs dispositifs avec une faible latence.

Le parallélisme de pipeline (PP) divise les couches du modèle sur les GPU. Le premier GPU traite les premières couches, transmet les activations au GPU suivant, et ainsi de suite. Bien que cela réduise l'empreinte mémoire par GPU, il introduit une latence de « bulle » où les GPU sont inactifs en attendant les données. Des techniques comme le parallélisme de pipeline entrelacé aident à atténuer ce problème en planifiant plusieurs micro-lots.

Le parallélisme de données (DP) réplique l'intégralité du modèle sur plusieurs GPU. Chaque GPU traite un lot de données différent de manière indépendante. Cela permet de mettre à l'échelle le débit linéairement avec le nombre de GPU, mais n'aide pas avec les contraintes de taille du modèle. Dans l'inférence distribuée, cela est souvent adapté sous forme de parallélisme hybride, où le TP/PP gère l'adaptation du modèle et le DP gère l'expansion des lots.

Optimiser la communication avec le parallélisme de tenseurs

Les performances du parallélisme de tenseurs dépendent fortement de la bande passante de l'interconnexion. Des technologies comme NVLink et InfiniBand sont cruciales ici. Lors de l'implémentation du TP, vous devez vous assurer que les opérations all-reduce sont optimisées.

Considérez une représentation simplifiée en pseudo-code de la manière dont le parallélisme de tenseurs pourrait être structuré dans un framework comme Megatron-LM ou DeepSpeed. L'essentiel est de s'assurer que la dimension divisée est gérée correctement lors du passage avant (forward pass) :

class TensorParallelLinear(nn.Module):
    def __init__(self, in_features, out_features, group):
        super().__init__()
        self.group = group
        # Diviser les poids selon la dimension de sortie
        self.weight = nn.Parameter(
            torch.chunk(original_weights, world_size, dim=0)[local_rank]
        )
        self.bias = nn.Parameter(
            torch.chunk(original_bias, world_size, dim=0)[local_rank]
        )

    def forward(self, x):
        # Opération linéaire sur le shard local
        out = F.linear(x, self.weight, self.bias)
        # All-reduce pour agréger les résultats sur les GPU
        out = torch.distributed.all_reduce(out, group=self.group, op=torch.distributed.ReduceOp.SUM)
        return out

Considérations pratiques pour le service

Lors du passage à l'inférence multi-nœuds, la partition statique est rarement suffisante. Vous avez besoin de regroupement dynamique de lots (dynamic batching) et de routage des requêtes. Des frameworks comme vLLM et TGI (Text Generation Inference) sont apparus pour gérer efficacement la gestion du cache KV et le décodage spéculatif. Ces moteurs optimisent l'utilisation de la mémoire en regroupant les blocs du cache KV, permettant ainsi une concurrence plus élevée.

De plus, surveillez de près votre latence inter-nœuds. Si les bulles de votre pipeline sont significatives, envisage de passer à un parallélisme de pipeline entrelacé ou d'augmenter la taille du micro-lot. Testez toujours votre débit (jetons par seconde) par rapport au coût de votre GPU. Si l'ajout d'un nœud n'augmente pas le débit linéairement, vos frais de communication sont probablement le goulot d'étranglement.

Conclusion

La mise à l'échelle du service des LLM est un défi d'ingénierie complexe qui se situe à l'intersection des systèmes distribués et de l'apprentissage automatique. En tirant parti du parallélisme de tenseurs et de pipeline, et en les combinant avec des moteurs d'inférence efficaces, vous pouvez servir des modèles qui seraient autrement impossibles à exécuter. À mesure que le matériel évolue, rester à jour avec les frameworks qui optimisent ces stratégies de parallélisme sera clé pour maintenir une infrastructure d'IA rentable et performante.