Última revisión: junio de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen NCA-ADS. Lee de arriba a abajo o salta a una sección.
Un pipeline existente de pandas en un CSV de 40 GB es demasiado lento en la CPU.
Reemplace pandas por cuDF; la mayoría de las llamadas de lectura/filtro/agrupación/unión mantienen la misma API y se ejecutan en la GPU.
Por qué: cuDF emula la API de pandas por diseño, por lo que la migración es principalmente un cambio de importación en lugar de una reescritura.
El equipo desea aceleraciones de GPU sin tocar el código existente de pandas.
Cargue el acelerador cudf.pandas (%load_ext cudf.pandas o python -m cudf.pandas); ejecuta operaciones en la GPU y recurre a la CPU automáticamente.
Por qué: La aceleración sin cambios en el código con un respaldo transparente a la CPU mantiene las operaciones no admitidas funcionando.
Necesita la carga columnar más rápida de un gran conjunto de datos analíticos en la GPU.
Almacene como Parquet y lea con cudf.read_parquet; la poda de columnas y el predicate pushdown minimizan la transferencia de dispositivos.
Por qué: Parquet columnar se asigna limpiamente a cuDF basado en Arrow y se lee mucho más rápido que CSV orientado a filas.
cuDF es más lento que pandas en un archivo de 50 MB.
Mantenga los datos pequeños en la CPU; la transferencia de host a dispositivo y la sobrecarga de lanzamiento de kernels dominan por debajo de ~1–2 GB.
Por qué: La aceleración de GPU vale la pena a escala; para datos pequeños, el costo de copia excede la ganancia computacional.
Agregue miles de millones de filas por clave con múltiples estadísticas.
Use df.groupby(key).agg({...}) en cuDF; las agregaciones se ejecutan como kernels de GPU paralelos.
Limpie y normalice una columna de texto de alta cardinalidad a escala de GPU.
Utilice el accesor .str de cuDF (lower, strip, replace, contains, split); las operaciones de cadenas se aceleran con la GPU a través de libcudf.
Por qué: cuDF tiene una capa de cadenas de GPU dedicada, por lo que la limpieza de texto no necesita recurrir a la CPU.
Una dos grandes DataFrames de dispositivos en una clave compartida.
Use cudf.merge / df.merge con la clave de unión; las uniones hash se ejecutan en la GPU.
Por qué: Ambos marcos deben estar ya en el dispositivo para evitar un viaje de ida y vuelta; mezclar pandas y cuDF fuerza una copia del host.
El conjunto de datos tiene valores faltantes que interrumpen el entrenamiento posterior de cuML.
Use cuDF fillna/dropna y conversiones de dtype explícitas antes del ajuste; cuML espera arreglos numéricos de dispositivos limpios.
Los dtypes mixtos/de objeto causan errores o hinchazón de memoria en cuDF.
Convierta a dtypes numéricos o categóricos compactos (int32/float32, category) temprano para reducir el consumo de memoria de la GPU.
Por qué: La reducción de tipo (downcasting) reduce la presión de la memoria del dispositivo, el cuello de botella más común en una sola GPU.
Necesita codificación label/one-hot para características categóricas antes del entrenamiento.
Use el dtype categórico de cuDF con .cat.codes o los codificadores de preprocesamiento de cuML para mantener los datos en el dispositivo.
Necesita operaciones matemáticas con arrays numéricos en bruto no expuestas por la API de cuDF DataFrame.
Convierta a través de df.values o to_cupy() y opere con CuPy (arrays de GPU compatibles con NumPy), luego devuelva los resultados.
Por qué: cuDF y CuPy comparten memoria de dispositivo a través de la __cuda_array_interface__, por lo que la conversión es de copia cero.
Portar un script de entrenamiento de scikit-learn a la GPU.
Use estimadores cuML (LinearRegression, LogisticRegression, KMeans, RandomForest); fit/predict reflejan la API de sklearn.
Por qué: cuML apunta a la compatibilidad con la API de sklearn, por lo que cambiar la importación suele ser suficiente.
Árboles potenciados por gradiente en un gran conjunto de datos tabulares, el entrenamiento es demasiado lento en la CPU.
Entrene XGBoost con device="cuda" (tree_method="hist"); consume datos cuDF/CuPy directamente.
Por qué: El método de histograma nativo de GPU de XGBoost proporciona grandes aceleraciones y se integra estrechamente con RAPIDS.
Agrupe millones de puntos rápidamente para segmentación.
Use cuML KMeans (o DBSCAN para métodos basados en densidad); ambos se ejecutan completamente en la GPU.
Reduzca datos de alta dimensión a 2D para visualización a escala.
Use cuML UMAP o t-SNE; las implementaciones de GPU manejan conjuntos de datos que son poco prácticos en la CPU.
Por qué: UMAP/t-SNE son computacionalmente intensivos; las versiones de GPU hacen que los embeddings a escala interactiva sean factibles.
Necesita un clasificador de conjunto preciso con importancias de características.
Use cuML RandomForestClassifier; entrene en arreglos de dispositivos y exporte a FIL para inferencia rápida.
Implementar un modelo de árbol para puntuación por lotes de alto rendimiento.
Cargue el modelo en la Forest Inference Library (FIL) para ejecutar predicciones aceleradas por GPU en grandes lotes.
Por qué: FIL acelera la inferencia para bosques XGBoost/LightGBM/cuML mucho más allá de la puntuación por árbol en la CPU.
Un algoritmo que necesita no tiene implementación en GPU de cuML.
Confirme la cobertura en la documentación de cuML; si no está, mantenga ese paso en scikit-learn y acelere el resto.
Por qué: No todos los estimadores están respaldados por GPU; conozca el conjunto compatible en lugar de asumir una paridad total.
Evite copias de host silenciosas durante el entrenamiento de cuML.
Pase los datos del dispositivo cuDF/CuPy directamente a fit(); mezclar NumPy/pandas activa una transferencia de host a dispositivo.
El conjunto de datos es más grande que la memoria de una sola GPU.
Use dask-cuDF para particionar los datos en múltiples GPU/nodos y procesar particiones en paralelo.
Por qué: Dask maneja la distribución fuera del núcleo y multi-GPU que un solo marco cuDF no puede.
Quiere usar todas las GPU en una caja multi-GPU.
Inicie un LocalCUDACluster desde dask-cuda y conecte un Cliente; un worker se asigna por cada GPU.
Por qué: LocalCUDACluster conecta cada worker de Dask a una GPU distinta para que el planificador pueda equilibrar el trabajo.
Construyendo un pipeline Dask de múltiples pasos que recalcula con demasiada frecuencia.
Componga de forma perezosa y llame a .compute() una vez al final; use persist() para almacenar en caché intermedios reutilizados en la memoria de la GPU.
Por qué: Dask es perezoso; activar el cálculo demasiado pronto o repetidamente rehace el trabajo.
Las particiones sesgadas hacen que algunos trabajadores de GPU se retrasen.
Reparticione a tamaños equilibrados y alinee las claves de partición con las uniones/agrupaciones posteriores.
Por qué: Las particiones desiguales crean rezagados que embotellan todo el trabajo.
Mantenga un flujo de trabajo ETL → entrenar → puntuar completamente en la GPU.
Encadene la preparación de cuDF en cuML/XGBoost sin convertir a pandas entre pasos, manteniendo los datos residentes en el dispositivo.
Por qué: Cada viaje de ida y vuelta a la CPU añade costo de transferencia; permanecer en el dispositivo conserva la aceleración de principio a fin.
Necesita un flujo de trabajo que se ejecute de forma idéntica para su revisión.
Fije las versiones de RAPIDS/CUDA, establezca semillas aleatorias y parametrice las entradas para que el pipeline sea determinista y re-ejecutable.
Calcule estadísticas de resumen en una tabla de mil millones de filas.
Use cuDF describe/mean/std/quantile y corr; las agregaciones se ejecutan como kernels de GPU.
Un diagrama de dispersión de 100M puntos se superpone y es ilegible.
Renderice con Datashader, que rasteriza los puntos en la GPU en una imagen de densidad en lugar de dibujar cada marcador.
Por qué: Datashader agrega en píxeles, por lo que el costo del gráfico está limitado por el tamaño de la imagen, no por el recuento de puntos.
Necesita un panel de control interactivo de filtrado cruzado sobre un enorme DataFrame de GPU.
Use cuxfilter para vincular gráficos con filtrado cruzado acelerado por GPU en datos cuDF.
Por qué: cuxfilter mantiene los datos en el dispositivo para que el brushing/filtrado permanezca interactivo a escala.
Visualice la distribución de una gran columna numérica.
Clasifique con cuDF/CuPy en la GPU, luego grafique el pequeño resultado agregado con Plotly o Matplotlib.
Por qué: Agregue primero en la GPU; solo el pequeño resumen necesita llegar a la biblioteca de gráficos.
Evalúe las relaciones entre características antes del modelado.
Calcule df.corr() en cuDF en la GPU, luego renderice la pequeña matriz como un mapa de calor.
Quiere gráficos interactivos declarativos respaldados por datos de GPU.
Empareje HoloViews/hvPlot con Datashader y cuDF para visualizaciones interactivas de gran volumen.
Justifique la aceleración de GPU para una carga de trabajo de datos.
Use GPU para operaciones masivamente paralelas a los datos, limitadas por el rendimiento, sobre grandes conjuntos de datos; mantenga el trabajo pequeño, ramificado o sensible a la latencia en la CPU.
Por qué: Las GPU ganan en paralelismo SIMT a través de muchos elementos; pierden en tareas pequeñas o con mucha lógica de control.
Explique cómo RAPIDS comparte datos entre cuDF, CuPy y bibliotecas de ML sin copias.
RAPIDS está construido sobre el formato de memoria columnar Apache Arrow, lo que permite el intercambio de copia cero entre bibliotecas de GPU.
Por qué: Un diseño columnar compartido en el dispositivo permite que los componentes entreguen datos sin serialización.
Un pipeline está acelerado por GPU pero apenas es más rápido.
Perfile el movimiento de datos; las copias repetidas host↔dispositivo a menudo dominan. Mantenga los datos residentes en la GPU entre pasos.
Por qué: La transferencia PCIe es el impuesto oculto; minimizar las copias suele ser la mayor ganancia individual.
Comprenda qué ejecuta el trabajo en la GPU.
CUDA lanza kernels a través de miles de hilos agrupados en bloques/rejillas bajo el modelo SIMT; las bibliotecas RAPIDS los envuelven para que rara vez escriba kernels usted mismo.
La carga de trabajo falla por falta de memoria en una sola GPU.
Reduzca los tamaños de dtype, procese en fragmentos o escale con Dask; la VRAM de la GPU es mucho menor que la RAM del host.
Por qué: La memoria del dispositivo es la primera restricción en la ciencia de datos con GPU; diseñe en torno a ella.
Asigne una tarea de ciencia de datos de CPU a la biblioteca RAPIDS correcta.
cuDF para DataFrames, cuML para ML, cuGraph para gráficos, cuSpatial para geoespacial, Dask para escalamiento.
Necesita comparar muchas ejecuciones de entrenamiento y sus métricas.
Registre parámetros, métricas y artefactos en MLflow Tracking; consulte y compare ejecuciones desde la UI.
Por qué: El seguimiento centralizado de experimentos hace que los resultados sean reproducibles y comparables entre ejecuciones.
Desea paneles en vivo y registros de experimentos compartidos en equipo.
Use Weights & Biases (wandb.init/log) para transmitir métricas y compartir paneles visuales de experimentos.
Rastree qué modelo entrenado está en staging vs producción.
Registre versiones en el MLflow Model Registry y promuévalas a través de etapas con metadatos.
Por qué: Un registro proporciona una única fuente de verdad para el linaje y la promoción del modelo.
Un modelo no puede reproducirse meses después.
Versione datos, código, entorno y semillas juntos; registre la configuración completa con cada ejecución.
Por qué: La reproducibilidad requiere capturar los cuatro: el código por sí solo no es suficiente.
Mueva un modelo entrenado hacia la implementación (serving).
Empaquete el modelo y las dependencias (por ejemplo, imagen de contenedor), luego exponga la inferencia por lotes o REST; use FIL para una rápida puntuación de árboles en GPU.
Clasifique nodos por influencia en un grafo grande.
Construya un cuGraph Graph a partir de una lista de aristas y ejecute cugraph.pagerank en la GPU.
Por qué: cuGraph ejecuta PageRank, BFS y centrality en grafos demasiado grandes para las bibliotecas de CPU.
Encuentre clusters/comunidades en un conjunto de datos de red.
Use cuGraph connected-components o Louvain; ingiera aristas de un cuDF DataFrame.
Los datos son de alta dimensión y en su mayoría ceros.
Use formatos dispersos de GPU (CSR/COO a través de CuPy sparse) en lugar de arreglos densos para optimizar la memoria y acelerar el cómputo.
Por qué: El almacenamiento disperso evita el desperdicio de VRAM y kernels en entradas cero.
Configure un entorno RAPIDS funcional.
Instale a través de conda, pip o Docker usando el Selector de Versiones de RAPIDS para que coincida con sus versiones de CUDA/Python.
Por qué: El selector fija compilaciones de paquetes compatibles, la fuente más común de fallos de instalación.
La importación de RAPIDS falla o no detecta la GPU después de la instalación.
Verifique que las versiones del controlador NVIDIA y del CUDA toolkit cumplan los requisitos de compilación de RAPIDS; ejecute nvidia-smi para confirmar la GPU.
Por qué: La falta de coincidencia del controlador/CUDA es la principal causa de los errores "no CUDA device".
Desea un entorno RAPIDS reproducible y preconfigurado.
Extraiga el contenedor RAPIDS de NVIDIA NGC; este incluye CUDA, controladores y bibliotecas coincidentes.
Por qué: Las imágenes NGC eliminan las conjeturas sobre la coincidencia de versiones y estandarizan el entorno en todas las máquinas.