Buckets:
| # Inférence distribuée | |
| L'inférence distribuée répartit la charge de travail sur plusieurs GPU. Elle est utile pour faire tenir des modèles plus volumineux en mémoire et pour traiter davantage de prompts simultanément. | |
| Diffusers prend en charge quatre stratégies. Chacune dispose de son propre guide, et cette page vous aide à en choisir une. | |
| ## Choisir une stratégie | |
| Chaque stratégie résout un problème différent, choisissez donc celle qui correspond à la ressource qui vous limite. | |
| | Stratégie | Splits | Réduit | Latence pour un seul prompt | Le plus adapté | | |
| |---|---|---|---|---| | |
| | [Parallélisme de données](../optimization/data_parallelism) | prompts entre les répliques | rien, car chaque GPU détient une copie complète | inchangé | le modèle tient déjà et vous avez de nombreux prompts | | |
| | [device_map](../optimization/device_map) | composants sur les différents appareils | mémoire des poids | légèrement moins bon | le modèle ne tient pas et l'interconnexion est lente | | |
| | [Parallélisme de contexte](../optimization/context_parallelism) | la séquence d'entrée | mémoire d'activation | lower | les séquences sont longues, comme des images haute résolution ou des vidéos | | |
| | [Parallélisme de tenseurs](../optimization/tensor_parallelism) | matrices de poids | mémoire des poids | lower | les poids d'un composant ne tiennent pas et l'interconnexion est rapide | | |
| Quelques conseils pratiques : | |
| - Si le modèle tient déjà en mémoire et que vous avez de nombreux prompts, utilisez le parallélisme de données. Il augmente le débit en fonction du nombre de GPU sans modifier le modèle, et il laisse la latence des prompts unitaires inchangée. Configurez-le avec [Accelerate](../optimization/data_parallelism#accelerate) ou [PyTorch Distributed](../optimization/data_parallelism#pytorch-distributed). | |
| - Si les poids d'un seul composant ne tiennent pas, essayez d'abord le parallélisme de tenseurs, car il réduit à la fois la mémoire et la latence. Le parallélisme de tenseurs communique à chaque frontière de bloc, il a donc besoin d'un interconnect rapide comme NVLink. Sur PCIe, le trafic par couche peut dépasser le calcul qu'il économise, et `device_map` devient alors le meilleur choix. `device_map` gère également le cas où les composants sont individuellement corrects mais collectivement trop volumineux. | |
| - Si ce sont les activations, et non les poids, qui posent problème, utilisez le parallélisme de contexte. Cela est utile pour les séquences longues, comme les grandes images et les vidéos avec de nombreuses images. Choisissez un backend à partir des benchmarks du guide [Context parallelism](../optimization/context_parallelism). | |
| - Si les poids et la séquence sont tous deux trop volumineux, Diffusers ne peut pas appliquer le parallélisme de tenseurs et le parallélisme de contexte au même modèle. `ParallelConfig` lève une erreur si vous passez les deux configurations, et `enable_parallelism` ne peut pas être appelé une seconde fois sur un modèle déjà parallélisé. | |
| Les intégrations communautaires [xDiT](../optimization/xdit) et [ParaAttention](../optimization/para_attn) proposent leurs propres implémentations du parallélisme de contexte. | |
Xet Storage Details
- Size:
- 3.25 kB
- Xet hash:
- cf40a7a4f0abb33feebad550d18239835957701f7507973a67ccf8aef20e9082
·
Xet efficiently stores files, intelligently splitting them into unique chunks and accelerating uploads and downloads. More info.