Ce guide présente les fondamentaux du fonctionnement conjoint du processeur central (CPU) et des cartes graphiques (GPU) dans le contexte du calcul parallèle pour l’intelligence artificielle, avec un focus sur les GPU NVIDIA, largement utilisés pour les charges de travail IA. L’architecture des GPU intégrés, comme ceux des puces Apple Silicon, n’est pas abordée ici. Le concept clé à comprendre est le paradigme hôte-dispositif : le programme débute toujours sur le CPU, appelé l’hôte, qui envoie des instructions et des données au GPU, le dispositif, pour exécuter des calculs intensifs, comme la multiplication de matrices. Cette interaction se fait via un système de file d’attente : le CPU ne bloque pas l’exécution, mais place les commandes dans une CUDA Stream, une file d’ordre pour les opérations GPU. Cette exécution asynchrone permet au CPU de continuer à traiter d’autres tâches, comme préparer les données suivantes, tandis que le GPU travaille en arrière-plan. Une CUDA Stream est une file d’opérations ordonnées. Les opérations dans une même stream s’exécutent séquentiellement, mais plusieurs streams peuvent fonctionner en parallèle. Par défaut, PyTorch utilise une stream par défaut, ce qui garantit une exécution simple mais limite les performances. Pour optimiser, on peut utiliser plusieurs streams, notamment pour superposer le transfert de données (CPU → GPU) et le calcul (GPU). Par exemple, pendant que le GPU traite un lot de données, le CPU peut transférer le lot suivant, grâce à une stream de transfert et une stream de calcul distinctes. L’option non_blocking=True est cruciale ici : elle permet au transfert de s’exécuter en arrière-plan sans bloquer le CPU. Pour synchroniser les streams, on peut utiliser torch.cuda.synchronize() pour attendre toutes les opérations, mais cette méthode est lourde. Une solution plus fine consiste à utiliser des événements CUDA. Un événement marque un point dans une stream, et une autre stream peut attendre cet événement sans bloquer le CPU, permettant une coordination précise sans perte de performance. Les tenseurs PyTorch sont constitués de métadonnées (forme, type) stockées en mémoire hôte (RAM du CPU), et des données réelles (valeurs numériques) en mémoire GPU (VRAM). L’accès à ces données depuis le CPU peut provoquer une synchronisation hôte-dispositif, un goulot d’étranglement fréquent. Par exemple, print(gpu_tensor) force le CPU à attendre que le GPU ait terminé son calcul et copié les résultats en RAM. Pour éviter cela, il est préférable de créer directement les tenseurs sur le GPU avec device=device, plutôt que de les créer d’abord sur le CPU puis de les transférer. Enfin, pour entraîner des modèles massifs comme les grands modèles linguistiques (LLM), une seule GPU n’est pas suffisante. On passe à un calcul distribué, où chaque GPU est associé à un rang (rank). Sur une même machine, plusieurs instances du script Python s’exécutent indépendamment, chacune gérant un GPU (par exemple, cuda:0 pour le rang 0, cuda:1 pour le rang 1). Grâce à l’identifiant de rang, on peut répartir les données ou les calculs entre les GPU. Cette architecture ouvre la voie à des opérations collectives et point-à-point, essentielles pour l’entraînement distribué. Comprendre ces concepts — streams, synchronisation, mémoire hôte-dispositif, rangs — est fondamental pour optimiser les performances et diagnostiquer les goulets d’étranglement dans les applications GPU. Ces mécanismes sont au cœur des frameworks modernes comme PyTorch, même si la plupart des utilisateurs ne les manipulent pas directement, grâce à des fonctionnalités comme pin_memory=True ou le préchargement des données. Évaluation et contexte : Les experts en IA et en calcul haute performance soulignent que maîtriser le paradigme hôte-dispositif est indispensable pour tirer pleinement parti des GPU, surtout dans les déploiements industriels. Des entreprises comme NVIDIA, Meta (via PyTorch), et Google (via TensorFlow) investissent massivement dans l’optimisation de ces flux. Les développeurs qui comprennent ces couches basses peuvent concevoir des systèmes plus rapides, plus scalables, et mieux adaptés aux contraintes réelles des infrastructures.