Comment le parallélisme des pipelines répartit-il les couches d’un modèle entre les accélérateurs d’IA domestiques ?
Le parallélisme en pipeline répartit un modèle entre plusieurs accélérateurs d’IA domestiques en attribuant différents groupes de couches à des étapes successives exécutées sur les appareils, puis en transférant les activations entre ces étapes.
Cette méthode est utile lorsqu’un modèle profond est trop volumineux pour un seul accélérateur, mais peut être divisé en groupes de couches tenant sur plusieurs appareils. Contrairement au parallélisme tensoriel, chaque étape possède des couches complètes plutôt que des fragments d’une même matrice. Le principal compromis oppose une moindre quantité de poids résidant sur chaque appareil aux transferts d’activations, au déséquilibre entre les étapes et aux temps d’inactivité du pipeline.
Le parallélisme en pipeline découpe un modèle profond en étapes successives de couches
Un transformeur suit naturellement un ordre précis : les premières couches transforment l’entrée avant que les suivantes puissent s’exécuter. Le parallélisme en pipeline regroupe des sections contiguës de cette profondeur et attribue chaque section à un accélérateur différent.
Le moteur de pipeline de PyTorch divise un modèle en partitions exécutées comme des étapes successives sur différents appareils. Chaque appareil ne stocke que les paramètres de l’étape qui lui est attribuée.
Cela peut réduire suffisamment la mémoire nécessaire sur chaque appareil pour exécuter un modèle qui ne tiendrait pas sur un seul GPU domestique.
Les activations avancent d’une étape à la suivante
Une fois que le GPU 0 a terminé ses couches, il envoie l’activation de l’état caché au GPU 1. Cet appareil applique l’ensemble de couches suivant et transmet une nouvelle activation, jusqu’à ce que l’étape finale produise les logits ou une autre sortie du modèle.
vLLM-Omni décrit le parallélisme en pipeline comme le fait de répartir les blocs du transformeur en étapes successives sur plusieurs GPU. Dans le parcours avantique de base, seules les activations aux frontières doivent être transférées entre les étapes voisines.
Contrairement au parallélisme tensoriel, les appareils ne calculent pas conjointement une matrice au sein d’une même couche. Ils possèdent des couches différentes.
Une seule requête traverse toujours les étapes dans l’ordre
Pour un token ou un micro-lot, les étapes suivantes ne peuvent pas commencer avant la réception de l’activation requise depuis l’étape précédente. Le simple fait de répartir quatre groupes de couches sur quatre GPU ne rend pas une requête séquentielle quatre fois plus rapide.
Le guide de NVIDIA sur le parallélisme définit le PP comme le fait de répartir verticalement les couches du modèle selon leur profondeur. La dépendance séquentielle entre les différentes profondeurs demeure.
Le gain immédiat peut donc concerner la capacité plutôt que la latence. Le débit s’améliore lorsque le moteur peut superposer différentes parties du travail entre les étapes.
Les micro-lots remplissent le pipeline pour faire travailler plusieurs étapes simultanément
Un pipeline devient efficace lorsque l’entrée est divisée en micro-lots ou lorsque plusieurs éléments d’inférence peuvent occuper simultanément différentes étapes. Pendant que l’étape 2 traite un micro-lot, l’étape 1 peut commencer le suivant.
Le guide de Hugging Face sur le parallélisme explique que l’exécution en pipeline utilise des micro-lots pour réduire le temps d’inactivité du pipeline. Le même principe d’utilisation s’applique lorsqu’un moteur d’inférence peut superposer des tâches indépendantes.
La génération interactive de tokens pour un seul utilisateur offre moins de parallélisme naturel, car chaque nouveau token dépend de la sortie du token précédent. Les requêtes groupées ou le trafic de plusieurs utilisateurs peuvent offrir davantage d’occasions de maintenir les étapes actives.
Des durées d’étape inégales créent des bulles et rendent l’étape la plus lente déterminante
Si une étape contient davantage de couches, s’exécute sur un matériel plus lent ou comporte des opérations particulièrement coûteuses, l’étape suivante attend son entrée et l’étape précédente finit par attendre qu’un espace se libère. Ces périodes d’inactivité sont des bulles de pipeline.
Le moteur de pipeline de DeepSpeed met l’accent sur le partitionnement des couches du modèle en étapes de pipeline. Équilibrer les calculs entre les étapes est donc aussi important que d’équilibrer la quantité d’octets de paramètres.
Une configuration domestique composée de plusieurs accélérateurs peut volontairement attribuer moins de couches à un GPU plus lent, mais la capacité mémoire, la taille des activations et la compatibilité des transferts entre appareils limitent cette répartition.
Le parallélisme en pipeline échange une capacité accrue pour les poids contre des transferts d’activations et de la planification
Le PP est intéressant lorsque le modèle est profond et peut être divisé en groupes de couches tenant sur chaque appareil. Il communique les activations aux frontières plutôt que d’effectuer les opérations collectives fréquentes au sein des couches, typiques du parallélisme tensoriel, mais il doit composer avec les dépendances séquentielles et les bulles.
Le guide de ZimaSpace consacré à la concurrence de l’IA domestique entre plusieurs utilisateurs est pertinent, car une charge simultanée plus importante peut contribuer à remplir un pipeline tout en augmentant la pression sur le KV cache et la planification.
Mesurez la mémoire de chaque étape, son temps d’exécution, le temps de transfert des activations, la latence de bout en bout, le débit et le pourcentage d’inactivité des appareils. Une configuration qui permet d’exécuter le modèle, mais laisse la moitié des accélérateurs inactifs, peut nécessiter une autre répartition.
Le guide de ZimaSpace sur le matériel d’IA local fournit la base nécessaire en matière de capacité. Le parallélisme en pipeline est l’un des moyens de dépasser la limite de mémoire d’un seul appareil, mais sa réussite dépend davantage de l’équilibre entre les étapes que du seul nombre de GPU.
Produits recommandés
Centre Tech & IA
Plus à lire
Les caméras domestiques peuvent-elles synchroniser les événements sans services horaires cloud ?
Une explication axée sur les mécanismes de l’heure de la caméra sans cloud, ses compromis liés aux ressources partagées, trois FAQ sur la diffusion...
Un service d’IA local peut-il détecter les couches de modèle corrompues avant l’inférence ?
Une explication axée sur les mécanismes de la détection des couches de modèle corrompues, de ses compromis en matière de ressources partagées, de trois...
Un système RAG peut-il être restauré sans régénérer chaque embedding ?
Une explication de la restauration RAG sans réencodage, axée sur le mécanisme, de ses compromis en matière de ressources partagées, trois FAQ sur la...
