🏠Accueil 📚Certifications 📱Applications Mobiles

🎓Infos examen

✍️Blog 💼Carrières 📊Progrès 📅Calendrier 💬Support

Politique de Confidentialité Conditions d'Utilisation Nous Contacter Politique des Cookies Avertissement Accessibilité DMCA / Droits d'Auteur

Aller au contenu

NCA-AIIOGuide

Guide — NCA-AIIO NVIDIA-Certified Associate: AI Infrastructure and Operations

Dernière révision : juin 2026

Une référence concise des modèles d'architecture évalués par l'examen NCA-AIIO. Lisez de haut en bas ou sautez à une section.

Sections

Infrastructure IA19 entrées
Connaissances Essentielles en IA18 entrées
Opérations IA11 entrées

Infrastructure IA

Décider si une charge de travail doit être exécutée sur des GPU ou des CPU.

Calcul massivement parallèle (entraînement/inférence de deep-learning, opérations matricielles, simulation) → GPU. Logique de contrôle série à forte ramification, tâches du système d'exploitation, E/S légères → CPU.

Pourquoi: Les GPU ont des milliers de cœurs optimisés pour le débit sur le travail SIMT parallèle ; les CPU sont meilleurs pour la logique série sensible à la latence. La plupart des systèmes IA associent les deux.

Choisir le bloc de construction NVIDIA : une appliance complète ou une carte pour les systèmes OEM.

Serveur IA intégré clé en main (GPU + CPU + NVLink + réseau + logiciel) → DGX. Carte mère GPU autour de laquelle les OEM/fournisseurs de cloud construisent des serveurs → HGX.

Pourquoi: DGX est le système de référence prêt à l'emploi de NVIDIA ; HGX est la carte multi-GPU que les hyperscalers intègrent eux-mêmes.

Les GPU d'un même serveur nécessitent une bande passante GPU-à-GPU plus rapide que ce que le bus offre.

Utiliser NVLink (et NVSwitch pour les connexions tout-à-tout) pour l'interconnexion GPU intra-nœud à haute bande passante ; PCIe est la solution de repli lorsque NVLink n'est pas disponible.

Pourquoi: NVLink offre une bande passante GPU-à-GPU bien plus élevée et une latence plus faible que PCIe — essentiel pour l'entraînement parallèle de modèles et en grands lots à l'intérieur d'un nœud.

Les 8 GPU d'un nœud doivent communiquer entre eux simultanément à pleine bande passante NVLink.

NVSwitch — une matrice de commutation non bloquante qui connecte chaque GPU à tous les autres GPU à pleine vitesse NVLink.

Pourquoi: NVLink point-à-point seul ne fournit pas une bande passante tout-à-tout ; NVSwitch fournit le crossbar pour une communication GPU maillée complète.

Distinguer l'interconnexion de scale-up (à l'intérieur d'un serveur) de celle de scale-out (à travers les serveurs).

Interconnexion GPU scale-up au sein d'un nœud → NVLink/NVSwitch. Scale-out à travers les nœuds d'un cluster → InfiniBand (ou RoCE Ethernet).

Pourquoi: NVLink est intra-nœud ; InfiniBand connecte les nœuds en un cluster pour l'entraînement distribué multi-nœuds.

Choisir le fabric de cluster pour l'entraînement distribué à grande échelle où la latence des opérations collectives est la plus importante.

Latence la plus faible, calcul dans le réseau (SHARP), RDMA natif → InfiniBand. Familier, moins coûteux, écosystème large → RoCE sur Spectrum-X Ethernet.

Pourquoi: InfiniBand avec SHARP décharge l'opération all-reduce dans le switch, réduisant la latence collective ; Spectrum-X est la réponse Ethernet de NVIDIA pour les fabrics IA.

Décharger le traitement réseau, de stockage et de sécurité du CPU afin que les cœurs soient libérés pour le calcul IA.

NVIDIA BlueField DPU — unité de traitement de données programmable qui décharge et isole les services d'infrastructure du CPU/GPU hôte.

Pourquoi: Les DPU accélèrent le réseau est-ouest, le stockage NVMe-oF et la sécurité zero-trust, augmentant l'utilisation effective du GPU/CPU et l'isolation des locataires.

Besoin d'une carte réseau RDMA haute vitesse pour les nœuds GPU sans déchargement DPU complet.

NVIDIA ConnectX SmartNIC — adaptateur InfiniBand/Ethernet à haut débit avec support RDMA et GPUDirect.

Pourquoi: ConnectX offre le RDMA à vitesse de ligne ; BlueField ajoute un sous-système Arm programmable pour un déchargement complet de l'infrastructure.

Réduire la latence en déplaçant les données dans la mémoire du GPU sans passer par le CPU/la mémoire hôte.

GPUDirect RDMA — les cartes réseau lisent/écrivent directement la mémoire GPU ; GPUDirect Storage fait de même pour le stockage NVMe.

Pourquoi: Le contournement du tampon de rebond du CPU élimine les copies et la latence sur le chemin des données, vital pour le débit d'entraînement multi-nœuds.

Choisir une architecture GPU de centre de données de génération actuelle pour l'entraînement de grands modèles.

Hopper (H100/H200) est la génération établie avec Transformer Engine + FP8 ; Blackwell (B200/GB200) est la nouvelle génération avec un débit plus élevé et FP4 pour les plus grands modèles.

Pourquoi: Les deux ciblent les charges de travail Transformer ; Blackwell pousse encore plus loin l'échelle et l'inférence à faible précision (FP4). À adapter au budget et à la taille du modèle.

Identifier le matériel qui accélère le calcul matriciel du deep-learning.

Tensor Cores — unités spécialisées qui effectuent des multiplications-accumulations matricielles fusionnées en précision mixte (FP16/BF16/FP8/FP4).

Pourquoi: Ils offrent un débit d'un ordre de grandeur supérieur sur les opérations GEMM/convolution que les cœurs CUDA standard, ce qui améliore les performances DL.

Un grand modèle ne rentre pas ; la bande passante mémoire, et non le calcul, est le goulot d'étranglement.

Choisir des GPU avec plus de HBM plus rapide (par exemple H200/B200 avec HBM3e) ; utiliser le parallélisme de modèle multi-GPU lorsque la mémoire d'un seul GPU est insuffisante.

Pourquoi: L'entraînement/inférence de grands modèles est souvent limitée par la capacité mémoire et la bande passante ; HBM fournit la haute bande passante dont les GPU ont besoin.

Mettre en place un supercalculateur IA multi-rack clé en main et validé pour l'entraînement en entreprise.

NVIDIA DGX SuperPOD — architecture de référence de nœuds DGX, fabric InfiniBand, stockage et logiciel Base Command.

Pourquoi: SuperPOD est la conception full-stack pré-validée ; elle élimine les incertitudes liées au câblage du fabric, au stockage et à l'orchestration à grande échelle.

Obtenir une capacité d'entraînement de classe DGX sans posséder le matériel.

NVIDIA DGX Cloud — infrastructure d'entraînement IA gérée hébergée chez les principaux fournisseurs de cloud, accessible en tant que service.

Pourquoi: OpEx vs. CapEx : DGX Cloud convient à l'entraînement ponctuel ou à court terme ; DGX/SuperPOD sur site convient à une utilisation élevée et soutenue et aux contraintes de gravité des données.

Choisir entre un cluster GPU sur site et des GPU cloud pour les charges de travail IA.

Utilisation élevée et soutenue, souveraineté des données, dépenses prévisibles → DGX/SuperPOD sur site. Demande variable/ponctuelle, démarrage rapide, pas d'empreinte de centre de données → cloud ou DGX Cloud.

Pourquoi: Les GPU détenus ne s'amortissent bien qu'à une utilisation constante et élevée ; le matériel détenu inactif est un coût pur.

Un nouveau cluster GPU dépasse le budget de puissance et de refroidissement d'un rack d'un centre de données existant.

Prévoir une alimentation haute densité (dizaines de kW/rack) et un refroidissement liquide pour les GPU les plus récents ; dimensionner les PDU, les chemins de câbles et la capacité thermique avant l'installation.

Pourquoi: Les nœuds GPU modernes (et les racks GB200) consomment beaucoup plus de puissance et génèrent plus de chaleur que les serveurs hérités ; le refroidissement par air et les PDU standard ne peuvent souvent pas suivre.

L'entraînement s'interrompt car le pipeline de données ne peut pas alimenter les GPU assez rapidement.

Utiliser un stockage parallèle/NVMe à haut débit avec GPUDirect Storage ; dimensionner pour une bande passante de lecture soutenue afin de maintenir les GPU saturés.

Pourquoi: Un sous-provisionnement des E/S de stockage laisse des GPU coûteux inactifs en attente de données ; la couche de stockage doit correspondre à la demande de lecture agrégée du GPU.

Un modèle est trop volumineux pour être entraîné sur un seul nœud dans un délai acceptable.

Évoluer vers plusieurs nœuds via InfiniBand en utilisant le parallélisme de données/tenseurs/pipeline ; NCCL gère la communication collective GPU.

Pourquoi: Le scaling multi-nœuds nécessite un fabric à faible latence et une bibliothèque de collectives optimisée (NCCL) ; un fabric lent réduit l'efficacité du scaling.

Un seul A100/H100 est excessif pour les petites tâches d'inférence ; vous voulez des tranches isolées par le matériel.

Multi-Instance GPU (MIG) — partitionner un GPU en jusqu'à 7 instances isolées, chacune avec un calcul et une mémoire dédiés.

Pourquoi: MIG offre une véritable isolation matérielle et une QoS prévisible pour l'inférence multi-locataire, contrairement au découpage temporel logiciel.

Connaissances Essentielles en IA

Distinguer l'IA du machine learning et du deep learning.

L'IA est l'objectif général ; le ML est un sous-ensemble qui apprend des données ; le DL est un sous-ensemble du ML utilisant des réseaux de neurones multi-couches.

Pourquoi: Ils s'imbriquent : DL ⊂ ML ⊂ IA. Le DL est à l'origine de la demande actuelle de GPU car les réseaux de neurones sont massivement parallèles.

Distinguer le profil de calcul de l'entraînement de celui de l'inférence.

Entraînement = gourmand en calcul et en mémoire, longue durée, par lots, nombreux GPU. Inférence = sensible à la latence, plus léger, souvent un seul/partiel GPU, fonctionne en continu en production.

Pourquoi: Ils ont des besoins différents en matériel et en scaling ; dimensionner un cluster nécessite de séparer les deux charges de travail.

Choisir un paradigme d'apprentissage : données étiquetées, données non étiquetées ou essai-erreur basé sur la récompense.

Étiqueté → supervisé. Clustering/structure non étiqueté → non supervisé. L'agent apprend de la récompense → apprentissage par renforcement.

Pourquoi: Les données dont vous disposez (et l'objectif) dictent le paradigme ; RLHF est l'apprentissage par renforcement guidé par le feedback humain pour aligner les LLM.

Expliquer pourquoi les réseaux de neurones s'adaptent bien aux GPU.

Ce sont des couches de multiplications matricielles pondérées et d'activations non linéaires — de l'algèbre linéaire parallèle dense que les GPU exécutent efficacement.

Pourquoi: Les passes avant/arrière sont gourmandes en GEMM ; les Tensor Cores accélèrent précisément cela, c'est pourquoi le DL s'exécute sur les GPU.

Identifier l'architecture derrière les LLM modernes et l'IA générative.

Le transformer — architecture basée sur l'attention qui s'adapte aux données et aux paramètres ; les modèles de fondation et les LLM en sont construits.

Pourquoi: Les Transformers sont hautement parallélisables, c'est pourquoi ils stimulent la demande de grands clusters GPU et de matériel Transformer Engine.

Accélérer l'entraînement et réduire l'utilisation de la mémoire sans nuire matériellement à la précision.

Utiliser la précision mixte — FP16/BF16 (et FP8 sur Hopper/Blackwell) pour le calcul, FP32 pour l'accumulation ; les Tensor Cores accélèrent les opérations à faible précision.

Pourquoi: Une précision plus faible divise la mémoire par deux et multiplie le débit ; le scaling de la perte / BF16 préserve la stabilité numérique.

Nommer la fondation qui permet aux logiciels de fonctionner sur les GPU NVIDIA.

CUDA — la plateforme de calcul parallèle et le modèle de programmation de NVIDIA ; CUDA-X est la couche de bibliothèques (cuDNN, cuBLAS, NCCL, RAPIDS, etc.).

Pourquoi: Des frameworks comme PyTorch/TensorFlow appellent les bibliothèques CUDA-X en arrière-plan ; CUDA est le fossé qui lie les logiciels IA aux GPU NVIDIA.

Accélérer les primitives de deep-learning (convolutions, attention) au sein d'un framework.

cuDNN fournit des primitives DL optimisées pour GPU ; cuBLAS gère l'algèbre linéaire dense ; les deux se trouvent sous PyTorch/TensorFlow.

Pourquoi: Ces bibliothèques expliquent pourquoi les frameworks atteignent la vitesse GPU sans que vous n'ayez à écrire de kernels CUDA.

Obtenir des conteneurs, des modèles et des Helm charts optimisés NVIDIA et prêts pour le GPU.

Catalogue NGC (NVIDIA GPU Cloud) — registre organisé de conteneurs optimisés (frameworks, NIM, Triton), de modèles pré-entraînés et de SDK.

Pourquoi: Les conteneurs NGC sont réglés et testés pour les GPU NVIDIA, éliminant les incertitudes de dépendance et de compatibilité des pilotes.

Servir de nombreux modèles de plusieurs frameworks derrière un seul point d'accès standardisé et efficace pour le GPU.

NVIDIA Triton Inference Server — service de modèles multi-framework avec batching dynamique, exécution de modèles concurrente et partage de GPU.

Pourquoi: Triton maximise l'utilisation du GPU pour l'inférence via le batching et la concurrence des modèles au lieu d'un processus par modèle.

Déployer rapidement un modèle de fondation en tant que microservice d'inférence optimisé et prêt pour la production.

NVIDIA NIM — microservices d'inférence pré-construits et conteneurisés avec des moteurs optimisés et des API standard pour les modèles populaires.

Pourquoi: NIM regroupe le modèle + l'exécution optimisée (TensorRT-LLM/Triton) + l'API en une seule unité déployable, réduisant le temps de mise en production.

Réduire la latence d'inférence et augmenter le débit pour un modèle entraîné.

Compiler le modèle avec TensorRT (ou TensorRT-LLM pour les LLM) — fusion de couches, calibration de précision (INT8/FP8) et auto-optimisation du kernel.

Pourquoi: TensorRT produit un moteur d'inférence optimisé pour le GPU cible, multipliant souvent le débit par rapport au framework brut.

Accélérer la préparation de données de type pandas/scikit-learn et le ML classique sur les GPU.

NVIDIA RAPIDS — cuDF (DataFrames), cuML (ML), cuGraph (graphs) exécutent le flux de travail de science des données sur les GPU.

Pourquoi: RAPIDS maintient l'ETL tabulaire et le ML classique sur le GPU, évitant les goulots d'étranglement du CPU dans le pipeline.

Gérer les charges de travail IA, les tâches et les utilisateurs sur un cluster DGX/SuperPOD.

NVIDIA Base Command — planification des tâches, gestion de cluster et orchestration des charges de travail pour l'infrastructure DGX.

Pourquoi: Base Command est le plan de contrôle des opérations pour les systèmes DGX ; il gère la soumission de tâches multi-utilisateurs et le suivi des ressources.

Besoin d'un logiciel IA de qualité production, sécurisé et pris en charge avec des SLA d'entreprise.

NVIDIA AI Enterprise — la suite logicielle prise en charge (frameworks, NIM, Triton, RAPIDS, GPU Operator) avec des correctifs de sécurité et un support d'entreprise.

Pourquoi: Elle regroupe la pile validée avec un support et des garanties de cycle de vie, ce qui est requis par les environnements réglementés/de production.

Définir un modèle de fondation et comment les équipes l'adaptent.

Grand modèle pré-entraîné sur de vastes données, adaptable à de nombreuses tâches via le prompting, RAG ou le fine-tuning plutôt que l'entraînement à partir de zéro.

Pourquoi: L'adaptation (prompt/RAG/fine-tune) est bien moins chère que le pré-entraînement ; la plupart des entreprises consomment des modèles de fondation, elles ne les construisent pas.

Ajouter des connaissances privées/actuelles à une application basée sur un LLM.

Faits fréquemment changeants → RAG (récupérer à partir d'un magasin de vecteurs lors de l'inférence). Enseigner un nouveau comportement/style/compétence de domaine → fine-tuning.

Pourquoi: RAG maintient les données externes et actualisables sans ré-entraînement ; le fine-tuning intègre le comportement dans les poids et est plus coûteux à rafraîchir.

Juger si les GPU coûteux sont utilisés efficacement.

Suivre l'utilisation du GPU, l'utilisation de la mémoire et l'activité des SM/Tensor-Core ; une faible utilisation signale des goulots d'étranglement au niveau du pipeline de données, de la taille des lots ou de la planification.

Pourquoi: Une "occupation" GPU élevée en temps réel peut masquer une faible efficacité de calcul ; examinez l'occupation des Tensor-Core/SM, pas seulement l'indicateur d'utilisation.

Opérations IA

Surveiller la santé, l'utilisation, la température, la puissance et les erreurs des GPU à travers un cluster.

NVIDIA DCGM (Data Center GPU Manager) — télémétrie, contrôles de santé et diagnostics ; exporter les métriques vers Prometheus/Grafana.

Pourquoi: DCGM est la source standard de télémétrie GPU ; le DCGM Exporter alimente Prometheus pour les tableaux de bord et les alertes à l'échelle du cluster.

Provisionner les pilotes GPU, le toolkit de conteneurs et la surveillance sur un cluster Kubernetes sans configuration manuelle par nœud.

NVIDIA GPU Operator — automatise la configuration du pilote, du runtime de conteneur, du plugin de périphérique, de DCGM et de MIG sur Kubernetes.

Pourquoi: Il gère le cycle de vie complet du logiciel GPU de manière déclarative, supprimant les installations de pilotes fragiles nœud par nœud.

Choisir un orchestrateur pour les charges de travail GPU.

Microservices/inférence, cloud-native, charges de travail mixtes → Kubernetes. Tâches d'entraînement par lots de style HPC, planification par gang, clusters traditionnels → Slurm.

Pourquoi: Kubernetes excelle dans les services de longue durée et l'élasticité ; Slurm excelle dans les tâches par lots en file d'attente avec une planification de style MPI.

Les pods Kubernetes doivent demander et être planifiés sur des GPU.

Le plugin de périphérique NVIDIA annonce les GPU comme des ressources planifiables ; les pods demandent `nvidia.com/gpu` et le planificateur les place.

Pourquoi: Sans le plugin de périphérique, Kubernetes ne peut pas voir ou allouer de GPU ; c'est ce qui fait des GPU une ressource de première classe.

De nombreuses petites tâches/utilisateurs doivent partager des GPU pour augmenter l'utilisation.

Isolation matérielle → MIG. Partage logiciel d'un GPU → découpage temporel ou MPS. Combiner avec des quotas de namespace pour l'équité.

Pourquoi: MIG offre des garanties de QoS ; le découpage temporel/MPS sur-alloue un GPU sans isolation. Choisir selon l'exigence d'isolation.

L'entraînement à haute priorité doit préempter les expériences à faible priorité sur un cluster partagé.

Utiliser la priorité/préemption et les files d'attente dans le planificateur (partitions Slurm ou Kubernetes PriorityClasses avec quota) ; planifier en gang les tâches multi-GPU.

Pourquoi: La planification en gang évite les blocages d'allocation partielle ; les classes de priorité imposent l'ordre métier sur les GPU en concurrence.

Maintenir les versions des pilotes GPU, CUDA et du toolkit de conteneurs cohérentes et compatibles entre les nœuds.

Standardiser via le GPU Operator (Kubernetes) ou les conteneurs NGC ; faire correspondre le pilote aux versions de CUDA dont vos frameworks ont besoin et déployer les mises à jour pendant les fenêtres de maintenance.

Pourquoi: Les incohérences pilote/CUDA/framework sont une cause majeure de pannes de cluster ; CUDA épinglé au conteneur découple l'application du pilote hôte dans les plages prises en charge.

Dimensionner un cluster GPU pour la demande prévisionnelle d'entraînement et d'inférence.

Séparer l'entraînement (pic, lot) de l'inférence (soutenu, limité par la latence) ; prévoir une marge pour l'alimentation/refroidissement/fabric et viser une utilisation élevée et stable.

Pourquoi: Le surdimensionnement gaspille les dépenses en capital sur les GPU inactifs ; le sous-dimensionnement entrave la livraison. Planifier en fonction du mix de charges de travail, pas d'un seul pic.

Les GPU se limitent ou échouent sous une charge lourde soutenue.

Surveiller la température et la puissance via DCGM ; assurer un refroidissement adéquat (liquide pour les racks denses), définir des limites de puissance raisonnables et alerter sur les seuils thermiques.

Pourquoi: La limitation thermique réduit silencieusement le débit ; la télémétrie proactive et la conception du refroidissement protègent à la fois les performances et la durée de vie du matériel.

Fournir l'accélération GPU à plusieurs VM ou utilisateurs VDI à partir de matériel partagé.

Le logiciel NVIDIA vGPU partitionne un GPU physique entre les VM avec planification et isolation ; MIG peut prendre en charge les profils vGPU pour un partitionnement matériel.

Pourquoi: vGPU permet un accès GPU virtualisé/multi-locataire (VDI, cloud) que le passthrough bare-metal ne peut pas partager.

Un nœud renvoie des erreurs Xid ou des tâches échouées ; vous devez isoler les GPU défectueux avant qu'ils ne corrompent davantage d'exécutions.

Exécuter les diagnostics DCGM et les contrôles de santé actifs ; cordonner/drainer le nœud, remplacer ou réinitialiser le GPU, et seulement ensuite le remettre dans le pool.

Pourquoi: Les erreurs Xid et les défauts ECC signalent les GPU défaillants ; la validation de santé automatisée empêche un GPU défectueux de contaminer le pool de planification.