Pipeline Parallelism
iaDéfinition
Le Pipeline Parallelism (PP) est une technique de parallelisme distribue qui partitionne les couches d'un LLM en 'stages' et assigne chaque stage a un GPU different. Contrairement au Tensor Parallelism (qui partitionne les operations au sein d'une couche), le Pipeline Parallelism partitionne le modele en profondeur (couches 1-16 sur GPU 1, couches 17-32 sur GPU 2, etc.). Le defi principal du Pipeline Parallelism est la 'pipeline bubble' : GPU 2 doit attendre que GPU 1 finisse sa forward pass avant de commencer la sienne. La proportion de temps perdu en attente est de (P-1)/P ou P est le nombre de stages. Des schedules comme PipeDream (1F1B) et GPipe avec micro-batches divisent le batch en mini-batches pour remplir le pipeline et reduire cette inefficacite. Le Pipeline Parallelism est particulierement utile quand les tenseurs intermediaires (activations) sont trop grands pour la bande passante GPU-GPU (NVLink), car les communications inter-stages ne portent que les activations a la frontiere entre stages (beaucoup moins volumineuses que les activations internes d'une couche dans le Tensor Parallelism). En pratique, les grands modeles utilisant une combinaison 3D : Data Parallelism (batches independants), Tensor Parallelism (matrices dans une couche), et Pipeline Parallelism (couches sur des machines differentes). LLaMA 3.1 405B a ete entraine avec TP=8 (8 GPU par machine) et PP=8 (8 machines en pipeline) et DP=N (N repliques). Pour l'inference en production, le Pipeline Parallelism est moins utilise car la latence de batch unique est augmentee par le nombre de stages. Le Tensor Parallelism seul (dans une machine multi-GPU avec NVLink) est souvent preferable pour l'inference interactive.
Pipeline Parallelism avec DeepSpeed
import deepspeed
# Configuration 3D Parallelism avec DeepSpeed
ds_config = {
'train_micro_batch_size_per_gpu': 1,
'pipeline': {
'stages': 4, # 4 GPUs en pipeline
'num_micro_batches': 8 # 8 micro-batches par batch (reduit pipeline bubble)
},
'zero_optimization': {'stage': 1} # + ZeRO Stage 1 pour les optimiseurs
}
model_engine = deepspeed.PipelineEngine(
model=model,
config=ds_config,
num_stages=4
)Pipeline bubble et micro-batches
Avec 4 stages et 1 micro-batch : 75% du temps est perdu (3/4 GPUs en attente). Avec 8 micro-batches : seulement ~43% de temps perdu en pratique. C'est pourquoi il faut maximiser le nombre de micro-batches pour l'efficacite.
Articles liés
Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.
Services
- Audit Infrastructure
- Audit Kubernetes
- Audit Microsoft 365
- Audit Sécurité Réseau
- Analyse de Risques
- Audit Active Directory
- Audit Application Web
- Audit Cloud (AWS/Azure/GCP)
- Audit Messagerie
- Audit API (OWASP Top 10)
- Audit DevSecOps & CI/CD
- Audit Code Source (SAST)
- Audit Postes de Travail
- Audit Sauvegarde & Résilience
- Audit OT/SCADA (IEC 62443)
- Développement IA
- Formations
Ressources
Projets & Outils
© 2026 Ayi NEDJIMI Consultants. Tous droits réservés.
Un projet cybersécurité ?
Expert dispo · Réponse 24h