CapordiaEspace client Définir l’unité de travail que l’on peut séparer
Écrivez ce qui constitue un résultat accepté : une image, un document traité, un ensemble de simulations ou un état final d’entraînement. Demandez ensuite si une unité peut être calculée sans attendre les autres. Deux documents peuvent être indépendants pendant leur traitement, puis dépendre d’une étape commune de construction d’index. Le découpage doit décrire cette seconde étape au lieu de l’oublier dans une promesse de parallélisme.
Distinguez l’indépendance informatique de l’indépendance métier. Une sortie peut être produite sans échange technique et rester inutilisable avant validation du lot complet. Nommez donc l’unité de calcul, l’unité de livraison et la règle d’assemblage. Ce vocabulaire commun évite que les achats comptent des cartes tandis que l’équipe applicative compte des instances ou des fragments d’un même modèle.
Choisir entre travaux indépendants et coopération étroite
Pour des tâches indépendantes, chaque processus reçoit ses propres entrées et produit une sortie identifiable. Une autre carte peut exécuter une autre tâche sans synchronisation à chaque étape. Ce mode est intéressant lorsque l’objectif porte sur la quantité terminée pendant une fenêtre. Il n’accélère pas automatiquement une tâche isolée et il faut encore vérifier la contention sur les données, le stockage ou les licences.
Pour un travail coopératif, les périphériques échangent des données ou attendent un résultat intermédiaire. Le programme doit gérer cette répartition. Le guide CUDA explique que l’exploitation de plusieurs GPU implique contextes, distribution des données, lancements et communications. Ce sont des propriétés du chemin logiciel et du système observé ; le nom d’une carte du catalogue ne prouve pas que ce chemin existe déjà.
| Question | Travaux indépendants | Travail coopératif |
|---|---|---|
| Que reçoit une carte ? | Une tâche complète distincte | Une partie ou une réplique du travail |
| Que faut-il coordonner ? | Attribution des entrées et collecte des sorties | Échanges, ordre et synchronisations |
| Quel bénéfice vérifier ? | Nombre de résultats acceptés par fenêtre | Résultat identique avec durée ou capacité adaptée |
| Quel échec anticiper ? | Une tâche ou une publication isolée | L’effet d’un participant indisponible sur le groupe |
Ne pas confondre réplication et répartition de mémoire
Plusieurs copies d’un modèle ne signifient pas que ses paramètres sont divisés entre les cartes. PyTorch DistributedDataParallel synchronise les gradients entre processus qui entraînent leurs modèles locaux. Cette approche ne permet donc pas de conclure, par son seul nom, qu’un modèle trop volumineux pour une carte tiendra sur plusieurs. Un mécanisme de partitionnement demande sa propre documentation et sa propre validation.
La mémoire de chaque carte doit couvrir ce que le logiciel y place effectivement : données, état du modèle, espaces temporaires et éventuels échanges. Le pic peut varier avec les réglages et la phase de traitement. Relevez-le par périphérique. Une somme de capacités nominales masque un déséquilibre où une carte manque de mémoire tandis que les autres en gardent. La capacité totale du lot ne suffit pas à accepter le scénario.
Exemple fictif : répartir huit conversions indépendantes
L’équipe fictive « Index des ouvrages » prépare huit conversions de documents. Dans son hypothèse de travail, chaque conversion occupe une carte pendant douze minutes, chargement et sortie inclus. Une tâche tient seule sur la carte et aucun échange n’est nécessaire avant l’assemblage final. Ces durées servent uniquement à construire le raisonnement : elles ne décrivent aucune exécution ni performance de GPU proposée par Capordia.
Avec une carte, huit tâches successives représentent 8 × 12 = 96 minutes. Avec deux cartes et une répartition équilibrée de quatre tâches chacune, la partie parallélisable représente théoriquement 48 minutes. Si l’assemblage final exige dix minutes sur un poste distinct, le chemin complet devient respectivement 106 ou 58 minutes, hors attente avant départ. Ce calcul suppose que les deux cartes ne ralentissent pas leurs chargements réciproques.
| Organisation | Partie parallélisable | Assemblage | Durée calculée |
|---|---|---|---|
| Une carte, huit tâches | 96 min | 10 min | 106 min |
| Deux cartes, quatre tâches chacune | 48 min | 10 min | 58 min |
Faire apparaître ce qui peut annuler ce gain théorique
Dans le même exemple, les documents ne sont peut-être pas de taille égale. Attribuer les quatre plus longs à une carte laisse l’autre attendre en fin de parcours. Une distribution au fil des disponibilités peut améliorer l’équilibre, mais elle exige un mécanisme d’attribution fiable et une politique d’admission. Le guide sur la file traite cette organisation ; le présent calcul n’atteste pas qu’elle soit déjà installée.
Le stockage peut aussi devenir la ressource commune dominante. Deux processus qui lisent les mêmes données ou écrivent simultanément de gros résultats ne disposent pas nécessairement de deux fois le débit. Vérifiez également les limites de concurrence des outils et des licences. Si la partie non parallélisable augmente, refaites le calendrier complet. Le temps gagné sur une phase ne doit pas masquer un délai ajouté ailleurs.
Pour un travail réparti, recevoir la topologie réelle
Demandez quelles cartes sont visibles, comment elles communiquent et quelles ressources hôtes partagent leurs processus. Vérifiez les périphériques accessibles depuis l’environnement utilisé, pas uniquement depuis une console administrateur. CUDA précise que l’accès à la mémoire d’un autre GPU dépend notamment de la topologie et des capacités du système. Le support d’une fonction par un modèle ne démontre pas la présence du lien attendu sur la machine.
Conservez un schéma simple de la circulation des données : entrée, carte ou processus concerné, échanges, rassemblement final et sortie. Pour chaque flèche, identifiez si elle traverse la mémoire hôte, un lien entre GPU ou le réseau. Cette vue sert à choisir les contrôles de réception. Elle n’impose pas une technologie donnée et ne transforme pas une demande multi-GPU en promesse de topologie particulière.
Comparer deux organisations sans déplacer le résultat attendu
Préparez un petit corpus représentatif et exécutez, sur votre cible autorisée, une organisation de référence puis l’organisation candidate. Conservez versions, réglages, qualité attendue et règles d’assemblage. Comparez le temps jusqu’au résultat accepté, le pic mémoire de chaque carte, les erreurs et la consommation des ressources communes. Séparez les observations des estimations ; une commande proposée ne vaut pas résultat déjà obtenu.
Vérifiez en particulier que le nombre de sorties acceptées reste le même et qu’aucune entrée n’est omise. Pour un calcul sensible à l’ordre des opérations, choisissez une tolérance justifiée plutôt qu’une égalité arbitraire. Une organisation qui termine plus vite avec une qualité différente répond à un autre problème. Conservez aussi un cas où le partage n’est pas avantageux : cette limite explique mieux le choix qu’un classement de cartes sans charge commune.
Traduire le choix en capacité demandée
Écrivez finalement le nombre de tâches simultanées, les cartes nécessaires à chacune et les conditions indispensables. Une tâche répartie sur deux cartes et deux tâches d’une carte représentent deux organisations différentes, même si le total de cartes est égal. La configuration choisie doit permettre l’organisation requise ; ne partez pas du total nominal pour lui inventer ensuite un usage.
Le catalogue indique des lots de cartes. Un lot B200 contient deux GPU de 180 Go chacun ; cette composition ne garantit pas qu’un logiciel les exploitera comme une seule mémoire. La prochaine étape est de faire correspondre le besoin au lot puis de réceptionner les propriétés effectivement nécessaires. Le calendrier, le coût et la décision restent provisoires tant que les conditions décisives ne sont pas vérifiées.
Questions pour décider
Deux GPU sont-ils toujours plus rapides qu’un seul ?
Non. Le gain dépend de la fraction parallélisable, des échanges et des ressources communes. Pour une tâche isolée non répartissable, une seconde carte peut rester inutilisée. Comparez le temps jusqu’au même résultat accepté, sur un protocole explicite.
Un lot de deux cartes double-t-il la mémoire disponible pour mon programme ?
Pas automatiquement. Chaque périphérique possède sa mémoire et le programme doit répartir son état ou ses données. La réplication d’un modèle peut au contraire dupliquer une grande partie de cet état. Vérifiez le mécanisme logiciel et le pic par carte.
Quand commencer par des tâches indépendantes ?
Lorsque chaque unité peut être calculée séparément et que le bénéfice recherché est de terminer davantage d’unités. Il faut tout de même valider l’attribution, l’équilibre des charges et l’assemblage final, sans supposer que stockage et licences suivent automatiquement.