Dernière révision : juin 2026
Une référence concise des modèles d'architecture évalués par l'examen NCA-ADS. Lisez de haut en bas ou sautez à une section.
Un pipeline pandas existant sur un CSV de 40 Go est trop lent sur CPU.
Remplacer pandas par cuDF ; la plupart des appels read/filter/groupby/join conservent la même API et s'exécutent sur le GPU.
Pourquoi: cuDF reflète l'API pandas par conception, la migration est donc principalement un changement d'importation plutôt qu'une réécriture.
L'équipe souhaite des accélérations GPU sans toucher au code pandas existant.
Charger l'accélérateur cudf.pandas (%load_ext cudf.pandas ou python -m cudf.pandas) ; il exécute les opérations sur GPU et revient au CPU automatiquement.
Pourquoi: L'accélération sans modification de code avec un retour transparent au CPU permet de maintenir le fonctionnement des opérations non prises en charge.
Nécessite le chargement par colonne le plus rapide d'un grand ensemble de données analytiques sur GPU.
Stocker au format Parquet et lire avec cudf.read_parquet ; l'élagage des colonnes et le predicate pushdown minimisent le transfert vers l'appareil.
Pourquoi: Le format Parquet columnar se mappe proprement à Arrow-backed cuDF et se lit beaucoup plus rapidement que le CSV orienté ligne.
cuDF est plus lent que pandas sur un fichier de 50 Mo.
Conserver les petites données sur CPU ; les transferts hôte-vers-appareil et le coût de lancement du noyau dominent en dessous de ~1-2 Go.
Pourquoi: L'accélération GPU est rentable à grande échelle ; pour les données minuscules, le coût de copie dépasse le gain de calcul.
Agréger des milliards de lignes par clé avec plusieurs statistiques.
Utiliser df.groupby(key).agg({...}) dans cuDF ; les agrégations s'exécutent comme des noyaux GPU parallèles.
Nettoyer et normaliser une colonne de texte à forte cardinalité à l'échelle du GPU.
Utiliser l'accesseur .str de cuDF (lower, strip, replace, contains, split) ; les opérations de chaînes sont accélérées par le GPU via libcudf.
Pourquoi: cuDF dispose d'une couche de chaînes GPU dédiée, de sorte que le nettoyage de texte n'a pas besoin de revenir au CPU.
Joindre deux grands DataFrames d'appareil sur une clé partagée.
Utiliser cudf.merge / df.merge avec la clé de jointure ; les jointures par hachage s'exécutent sur le GPU.
Pourquoi: Les deux frames doivent déjà être sur l'appareil pour éviter un aller-retour ; mélanger pandas et cuDF force une copie sur l'hôte.
L'ensemble de données contient des valeurs manquantes qui interrompent l'entraînement cuML en aval.
Utiliser cuDF fillna/dropna et des casts de type de données explicites avant l'ajustement ; cuML s'attend à des tableaux d'appareils numériques propres.
Les types de données mixtes/objet provoquent des erreurs ou un gonflement de la mémoire dans cuDF.
Convertir tôt vers des types de données numériques ou catégoriels compacts (int32/float32, category) pour réduire l'empreinte mémoire du GPU.
Pourquoi: La conversion vers un type de données inférieur réduit la pression de la mémoire de l'appareil, le goulot d'étranglement le plus courant sur un seul GPU.
Nécessite un encodage d'étiquettes/one-hot pour les caractéristiques catégorielles avant l'entraînement.
Utiliser le type de données catégorielles cuDF avec .cat.codes ou les encodeurs de pré-traitement cuML pour garder les données sur l'appareil.
Nécessite des opérations mathématiques brutes sur des tableaux numériques non exposées par l'API DataFrame de cuDF.
Convertir via df.values ou to_cupy() et opérer avec CuPy (tableaux GPU compatibles NumPy), puis ramener les résultats.
Pourquoi: cuDF et CuPy partagent la mémoire de l'appareil via l'__cuda_array_interface__, la conversion est donc sans copie.
Porter un script d'entraînement scikit-learn vers le GPU.
Utiliser les estimateurs cuML (LinearRegression, LogisticRegression, KMeans, RandomForest) ; fit/predict reflètent l'API sklearn.
Pourquoi: cuML vise la compatibilité de l'API sklearn, il est donc généralement suffisant d'échanger l'importation.
Arbres à gradient boosté sur un grand ensemble de données tabulaires, entraînement trop lent sur CPU.
Entraîner XGBoost avec device="cuda" (tree_method="hist") ; il consomme directement les données cuDF/CuPy.
Pourquoi: La méthode d'histogramme GPU native d'XGBoost offre de grandes accélérations et s'intègre étroitement avec RAPIDS.
Regrouper rapidement des millions de points pour la segmentation.
Utiliser cuML KMeans (ou DBSCAN pour les méthodes basées sur la densité) ; les deux s'exécutent entièrement sur le GPU.
Réduire les données de haute dimensionnalité en 2D pour la visualisation à grande échelle.
Utiliser cuML UMAP ou t-SNE ; les implémentations GPU gèrent des ensembles de données qui seraient impraticables sur CPU.
Pourquoi: UMAP/t-SNE sont gourmands en calcul ; les versions GPU rendent les embeddings à échelle interactive réalisables.
Nécessite un classifieur d'ensemble précis avec des importances de caractéristiques.
Utiliser cuML RandomForestClassifier ; entraîner sur des tableaux d'appareil et exporter vers FIL pour une inférence rapide.
Déployer un modèle d'arbre pour un scoring par lots à haut débit.
Charger le modèle dans la Forest Inference Library (FIL) pour exécuter des prédictions accélérées par GPU sur de grands lots.
Pourquoi: FIL accélère l'inférence pour les forêts XGBoost/LightGBM/cuML bien au-delà du scoring CPU par arbre.
Un algorithme dont vous avez besoin n'a pas d'implémentation GPU cuML.
Confirmer la couverture dans la documentation cuML ; si elle est absente, garder cette étape sur scikit-learn et accélérer le reste.
Pourquoi: Tous les estimateurs ne sont pas supportés par le GPU - connaître l'ensemble supporté plutôt que d'assumer une parité complète.
Éviter les copies hôtes silencieuses pendant l'entraînement cuML.
Passer directement les données d'appareil cuDF/CuPy à fit() ; mélanger NumPy/pandas déclenche un transfert hôte-vers-appareil.
L'ensemble de données est plus grand que la mémoire d'un seul GPU.
Utiliser dask-cuDF pour partitionner les données sur plusieurs GPU/nœuds et traiter les partitions en parallèle.
Pourquoi: Dask gère la distribution hors-mémoire et multi-GPU qu'un seul cadre cuDF ne peut pas gérer.
Vouloir utiliser tous les GPU sur une machine multi-GPU.
Démarrer un LocalCUDACluster depuis dask-cuda et connecter un Client ; un worker est épinglé par GPU.
Pourquoi: LocalCUDACluster connecte chaque worker Dask à un GPU distinct afin que le planificateur puisse équilibrer la charge de travail.
Construction d'un pipeline Dask multi-étapes qui recalcule trop souvent.
Composer de manière paresseuse et appeler .compute() une fois à la fin ; utiliser persist() pour mettre en cache les intermédiaires réutilisés dans la mémoire GPU.
Pourquoi: Dask est paresseux - déclencher le calcul trop tôt ou de manière répétée refait le travail.
Des partitions asymétriques entraînent un ralentissement de certains workers GPU.
Repartir en tailles équilibrées et aligner les clés de partition avec les jointures/groupbys en aval.
Pourquoi: Les partitions inégales créent des traînards qui bloquent l'ensemble du travail.
Maintenir un workflow ETL → entraînement → score entièrement sur GPU.
Enchaîner la préparation cuDF dans cuML/XGBoost sans convertir en pandas entre les étapes, en gardant les données résidentes sur l'appareil.
Pourquoi: Chaque aller-retour CPU ajoute un coût de transfert ; rester sur l'appareil préserve l'accélération de bout en bout.
Nécessite un workflow qui se réexécute de manière identique pour examen.
Épingler les versions RAPIDS/CUDA, définir des graines aléatoires et paramétrer les entrées afin que le pipeline soit déterministe et ré-exécutable.
Calculer des statistiques descriptives sur une table d'un milliard de lignes.
Utiliser cuDF describe/mean/std/quantile et corr ; les agrégations s'exécutent comme des noyaux GPU.
Un nuage de points de 100 millions de points se superpose et est illisible.
Rendu avec Datashader, qui rasterise les points sur GPU en une image de densité au lieu de dessiner chaque marqueur.
Pourquoi: Datashader agrège en pixels, de sorte que le coût du tracé est limité par la taille de l'image, et non par le nombre de points.
Nécessite un tableau de bord interactif de filtrage croisé sur un énorme DataFrame GPU.
Utiliser cuxfilter pour lier des graphiques avec un filtrage croisé accéléré par GPU sur des données cuDF.
Pourquoi: cuxfilter conserve les données sur l'appareil afin que le brossage/filtrage reste interactif à l'échelle.
Visualiser la distribution d'une grande colonne numérique.
Discrétiser avec cuDF/CuPy sur GPU, puis tracer le petit résultat agrégé avec Plotly ou Matplotlib.
Pourquoi: Agréger d'abord sur GPU ; seul le minuscule résumé doit atteindre la bibliothèque de traçage.
Évaluer les relations entre les caractéristiques avant la modélisation.
Calculer df.corr() dans cuDF sur GPU, puis rendre la petite matrice sous forme de carte thermique.
Vouloir des graphiques interactifs déclaratifs basés sur des données GPU.
Associer HoloViews/hvPlot à Datashader et cuDF pour des visualisations interactives à grand volume.
Justifier l'accélération GPU pour une charge de travail de données.
Utiliser les GPU pour des opérations massivement parallèles aux données, limitées par le débit sur de grands ensembles de données ; garder les tâches petites, ramifiées ou sensibles à la latence sur CPU.
Pourquoi: Les GPU excellent en parallélisme SIMT sur de nombreux éléments ; ils sont moins performants sur les tâches petites ou gourmandes en contrôle.
Expliquer comment RAPIDS partage les données entre cuDF, CuPy et les bibliothèques ML sans copies.
RAPIDS est construit sur le format de mémoire columnar Apache Arrow, permettant un échange sans copie entre les bibliothèques GPU.
Pourquoi: Une disposition columnar partagée sur l'appareil permet aux composants de transmettre des données sans sérialisation.
Un pipeline est accéléré par GPU mais est à peine plus rapide.
Profiler le mouvement des données ; les copies répétées hôte↔appareil dominent souvent. Garder les données résidentes sur le GPU entre les étapes.
Pourquoi: Le transfert PCIe est la taxe cachée - minimiser les copies est généralement le plus grand gain unique.
Comprendre ce qui exécute le travail sur le GPU.
CUDA lance des noyaux à travers des milliers de threads regroupés en blocs/grilles selon le modèle SIMT ; les bibliothèques RAPIDS les encapsulent pour que vous écriviez rarement des noyaux vous-même.
La charge de travail échoue avec une erreur de mémoire insuffisante sur un seul GPU.
Réduire les tailles de dtype, traiter par blocs, ou étendre avec Dask ; la VRAM du GPU est beaucoup plus petite que la RAM de l'hôte.
Pourquoi: La mémoire de l'appareil est la première contrainte en science des données GPU - concevez en conséquence.
Mapper une tâche de science des données CPU à la bonne bibliothèque RAPIDS.
cuDF pour les DataFrames, cuML pour le ML, cuGraph pour les graphiques, cuSpatial pour le géospatial, Dask pour la mise à l'échelle.
Nécessite de comparer de nombreuses exécutions d'entraînement et leurs métriques.
Enregistrer les paramètres, les métriques et les artefacts dans MLflow Tracking ; interroger et comparer les exécutions depuis l'interface utilisateur.
Pourquoi: Le suivi centralisé des expériences rend les résultats reproductibles et comparables entre les exécutions.
Vouloir des tableaux de bord en direct et des journaux d'expériences partagés par l'équipe.
Utiliser Weights & Biases (wandb.init/log) pour diffuser les métriques et partager des tableaux de bord visuels d'expériences.
Suivre quel modèle entraîné est en staging vs production.
Enregistrer les versions dans le MLflow Model Registry et les promouvoir à travers des étapes avec des métadonnées.
Pourquoi: Un registre fournit une source unique de vérité pour la lignée et la promotion des modèles.
Un modèle ne peut pas être reproduit des mois plus tard.
Versionner les données, le code, l'environnement et les graines ensemble ; enregistrer la configuration complète avec chaque exécution.
Pourquoi: La reproductibilité nécessite de capturer les quatre - le code seul ne suffit pas.
Déplacer un modèle entraîné vers le service.
Packager le modèle et les dépendances (par exemple, image conteneur), puis exposer l'inférence par lots ou REST ; utiliser FIL pour un scoring rapide des arbres GPU.
Classer les nœuds par influence dans un grand graphe.
Construire un graphe cuGraph à partir d'une liste d'arêtes et exécuter cugraph.pagerank sur le GPU.
Pourquoi: cuGraph exécute PageRank, BFS et la centralité sur des graphes trop grands pour les bibliothèques CPU.
Trouver des clusters/communautés dans un ensemble de données réseau.
Utiliser les composants connectés de cuGraph ou Louvain ; ingérer les arêtes d'un DataFrame cuDF.
Les données sont de haute dimensionnalité et contiennent principalement des zéros.
Utiliser des formats GPU creux (CSR/COO via CuPy sparse) au lieu de tableaux denses pour économiser la mémoire et accélérer le calcul.
Pourquoi: Le stockage creux évite de gaspiller la VRAM et les noyaux sur les entrées nulles.
Configurer un environnement RAPIDS fonctionnel.
Installer via conda, pip ou Docker en utilisant le sélecteur de version RAPIDS pour correspondre à vos versions CUDA/Python.
Pourquoi: Le sélecteur épingle les builds de packages compatibles, la source la plus courante d'échecs d'installation.
L'importation de RAPIDS échoue ou ne voit pas de GPU après l'installation.
Vérifier que les versions du pilote NVIDIA et du toolkit CUDA satisfont les exigences de build RAPIDS ; exécuter nvidia-smi pour confirmer le GPU.
Pourquoi: L'incompatibilité pilote/CUDA est la principale cause des erreurs "no CUDA device".
Vouloir un environnement RAPIDS reproductible et préconfiguré.
Extraire le conteneur RAPIDS de NVIDIA NGC ; il contient les versions compatibles de CUDA, des pilotes et des bibliothèques.
Pourquoi: Les images NGC éliminent les incertitudes de correspondance de version et standardisent l'environnement sur toutes les machines.