Última revisión: junio de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen NCA-AIIO. Lee de arriba a abajo o salta a una sección.
Decidir si una carga de trabajo debe ejecutarse en GPUs o CPUs.
Matemáticas masivamente paralelas (entrenamiento/inferencia de deep learning, operaciones matriciales, simulación) → GPU. Lógica de control serial con muchas bifurcaciones, tareas del SO, E/S ligera → CPU.
Por qué: Las GPUs tienen miles de núcleos optimizados para el rendimiento en trabajos SIMT paralelos; las CPUs ganan en lógica serial sensible a la latencia. La mayoría de los sistemas de IA combinan ambos.
Elegir el bloque de construcción de NVIDIA: un dispositivo completo frente a una placa para sistemas OEM.
Servidor de IA integrado "llave en mano" (GPUs + CPUs + NVLink + redes + software) → DGX. Placa base de GPU alrededor de la cual los OEMs/proveedores de la nube construyen servidores → HGX.
Por qué: DGX es el sistema de referencia listo para usar de NVIDIA; HGX es la placa multi-GPU que los hyperscalers integran por sí mismos.
Las GPUs en un servidor necesitan un ancho de banda GPU a GPU más rápido del que proporciona el bus.
Usar NVLink (y NVSwitch para "todos a todos") para interconexión de GPU dentro del nodo de alto ancho de banda; PCIe es la alternativa cuando NVLink no está disponible.
Por qué: NVLink ofrece un ancho de banda GPU a GPU mucho mayor y menor latencia que PCIe — crítico para el entrenamiento de modelos paralelos y lotes grandes dentro de un nodo.
Las 8 GPUs en un nodo deben comunicarse entre sí a todo el ancho de banda de NVLink simultáneamente.
NVSwitch — un tejido de conmutación no bloqueante que conecta cada GPU con cualquier otra GPU a la velocidad máxima de NVLink.
Por qué: NVLink punto a punto por sí solo no proporciona ancho de banda "todos a todos"; NVSwitch proporciona la interconexión para la comunicación GPU de malla completa.
Distinguir la interconexión de escalado vertical (dentro de un servidor) de la de escalado horizontal (entre servidores).
Interconexión de GPU de escalado vertical dentro de un nodo → NVLink/NVSwitch. Escalado horizontal entre nodos en un clúster → InfiniBand (o RoCE Ethernet).
Por qué: NVLink es intra-nodo; InfiniBand conecta nodos en un clúster para entrenamiento distribuido multi-nodo.
Elegir el tejido del clúster para entrenamiento distribuido a gran escala donde la latencia de las operaciones colectivas es lo más importante.
Menor latencia, computación en red (SHARP), nativo de RDMA → InfiniBand. Familiar, menor costo, amplio ecosistema → RoCE en Spectrum-X Ethernet.
Por qué: InfiniBand con SHARP descarga todas las reducciones en el switch, reduciendo la latencia colectiva; Spectrum-X es la respuesta de NVIDIA basada en Ethernet para tejidos de IA.
Descargar el procesamiento de red, almacenamiento y seguridad de la CPU para liberar núcleos para la computación de IA.
NVIDIA BlueField DPU — unidad de procesamiento de datos programable que descarga y aísla los servicios de infraestructura de la CPU/GPU del host.
Por qué: Las DPUs aceleran las redes este-oeste, el almacenamiento NVMe-oF y la seguridad de confianza cero, aumentando la utilización efectiva de GPU/CPU y el aislamiento de inquilinos.
Necesitar una NIC RDMA de alta velocidad para nodos GPU sin descarga completa de DPU.
NVIDIA ConnectX SmartNIC — adaptador InfiniBand/Ethernet de alto rendimiento con soporte para RDMA y GPUDirect.
Por qué: ConnectX proporciona RDMA a velocidad de línea; BlueField añade un subsistema Arm programable en la parte superior para una descarga completa de la infraestructura.
Reducir la latencia moviendo datos a la memoria de la GPU sin pasar por la CPU/memoria del host.
GPUDirect RDMA — las NICs leen/escriben directamente en la memoria de la GPU; GPUDirect Storage hace lo mismo para el almacenamiento NVMe.
Por qué: Omitir el búfer de rebote de la CPU elimina copias y latencia en la ruta de datos, vital para el rendimiento del entrenamiento multi-nodo.
Elegir una arquitectura de GPU de centro de datos de generación actual para el entrenamiento de modelos grandes.
Hopper (H100/H200) es la generación establecida con Transformer Engine + FP8; Blackwell (B200/GB200) es la generación más nueva con mayor rendimiento y FP4 para los modelos más grandes.
Por qué: Ambas se dirigen a cargas de trabajo de transformer; Blackwell impulsa aún más la escala y la inferencia de menor precisión (FP4). Coincide con el presupuesto y el tamaño del modelo.
Identificar el hardware que acelera las operaciones matriciales de deep learning.
Tensor Cores — unidades especializadas que realizan operaciones de multiplicación-acumulación de matrices fusionadas con precisión mixta (FP16/BF16/FP8/FP4).
Por qué: Ofrecen un rendimiento órdenes de magnitud superior en GEMM/convolución que los núcleos CUDA estándar, lo que impulsa el rendimiento de DL.
Un modelo grande no encaja; el ancho de banda de la memoria, no la computación, es el cuello de botella.
Elegir GPUs con más y más rápida HBM (ej. H200/B200 con HBM3e); usar paralelismo de modelo multi-GPU cuando la memoria de una GPU es insuficiente.
Por qué: El entrenamiento/inferencia de modelos grandes a menudo está limitado por la capacidad y el ancho de banda de la memoria; HBM proporciona el alto ancho de banda que las GPUs necesitan.
Implementar un superordenador de IA multi-rack "llave en mano" y validado para el entrenamiento empresarial.
NVIDIA DGX SuperPOD — arquitectura de referencia de nodos DGX, tejido InfiniBand, almacenamiento y software Base Command.
Por qué: SuperPOD es el diseño de pila completa pre-validado; elimina las conjeturas de cablear el tejido, el almacenamiento y la orquestación a escala.
Obtener capacidad de entrenamiento de clase DGX sin poseer el hardware.
NVIDIA DGX Cloud — infraestructura de entrenamiento de IA gestionada alojada en los principales proveedores de la nube, a la que se accede como un servicio.
Por qué: OpEx vs. CapEx: DGX Cloud es adecuado para entrenamiento intermitente o a corto plazo; DGX/SuperPOD en las instalaciones es adecuado para una alta utilización sostenida y limitaciones de gravedad de datos.
Elegir un clúster de GPU en las instalaciones frente a GPUs en la nube para cargas de trabajo de IA.
Alta utilización sostenida, soberanía de datos, gasto predecible → DGX/SuperPOD en las instalaciones. Demanda variable/intermitente, inicio rápido, sin huella de centro de datos → nube o DGX Cloud.
Por qué: Las GPUs propias se amortizan bien solo con una alta utilización constante; el hardware propio inactivo es puro coste.
Un nuevo clúster de GPU excede el presupuesto de energía y refrigeración del rack de un centro de datos existente.
Planificar para energía de alta densidad (decenas de kW/rack) y refrigeración líquida para las GPUs más nuevas; dimensionar PDUs, busways y capacidad térmica antes de la instalación.
Por qué: Los nodos de GPU modernos (y los racks GB200) consumen mucha más energía y generan más calor que los servidores heredados; la refrigeración por aire y las PDUs estándar a menudo no pueden seguir el ritmo.
El entrenamiento se detiene porque la tubería de datos no puede alimentar a las GPUs lo suficientemente rápido.
Usar almacenamiento paralelo/NVMe de alto rendimiento con GPUDirect Storage; dimensionar para un ancho de banda de lectura sostenido para mantener las GPUs saturadas.
Por qué: Una E/S de almacenamiento insuficiente deja las costosas GPUs inactivas esperando datos; el nivel de almacenamiento debe coincidir con la demanda de lectura agregada de las GPUs.
Un modelo es demasiado grande para entrenar en un solo nodo en un tiempo aceptable.
Escalar a múltiples nodos a través de InfiniBand utilizando paralelismo de datos/tensor/pipeline; NCCL gestiona la comunicación colectiva de GPU.
Por qué: El escalado multi-nodo necesita un tejido de baja latencia y una biblioteca de colectivos optimizada (NCCL); un tejido lento anula la eficiencia del escalado.
Una sola A100/H100 es excesiva para trabajos de inferencia pequeños; se quieren divisiones aisladas por hardware.
Multi-Instance GPU (MIG) — particionar una GPU en hasta 7 instancias aisladas, cada una con computación y memoria dedicadas.
Por qué: MIG proporciona un verdadero aislamiento de hardware y QoS predecible para la inferencia multi-inquilino, a diferencia del time-slicing suave.
Distinguir IA vs. machine learning vs. deep learning.
La IA es el objetivo general; ML es un subconjunto que aprende de datos; DL es un subconjunto de ML que utiliza redes neuronales multicapa.
Por qué: Se anidan: DL ⊂ ML ⊂ AI. DL impulsa la demanda moderna de GPU porque las redes neuronales son masivamente paralelas.
Distinguir el perfil de computación de entrenamiento vs. inferencia.
Entrenamiento = intensivo en computación y memoria, de larga duración, por lotes, muchas GPUs. Inferencia = sensible a la latencia, más ligero, a menudo GPU única/parcial, se ejecuta continuamente en producción.
Por qué: Tienen diferentes necesidades de hardware y escalado; dimensionar un clúster requiere separar las dos cargas de trabajo.
Elegir un paradigma de aprendizaje: datos etiquetados, datos sin etiquetar o prueba y error impulsado por recompensa.
Etiquetado → supervisado. Agrupación/estructura sin etiquetar → no supervisado. El agent aprende de la recompensa → aprendizaje por refuerzo.
Por qué: Los datos que se tienen (y el objetivo) dictan el paradigma; RLHF es aprendizaje por refuerzo dirigido por la retroalimentación humana para alinear LLMs.
Explicar por qué las redes neuronales se asignan bien a las GPUs.
Son capas de multiplicaciones matriciales ponderadas y activaciones no lineales — álgebra lineal paralela densa que las GPUs ejecutan eficientemente.
Por qué: Las pasadas hacia adelante/hacia atrás son intensivas en GEMM; Tensor Cores aceleran exactamente esto, por lo que el DL se ejecuta en GPUs.
Identificar la arquitectura detrás de los LLMs modernos y la IA generativa.
El transformer — arquitectura basada en atención que escala con datos y parámetros; los foundation models y LLMs se construyen sobre ella.
Por qué: Los Transformers son altamente paralelizados, por lo que impulsan la demanda de grandes clústeres de GPU y hardware de Transformer Engine.
Acelerar el entrenamiento y reducir el uso de memoria sin afectar materialmente la precisión.
Usar precisión mixta — FP16/BF16 (y FP8 en Hopper/Blackwell) para matemáticas, FP32 para acumulación; Tensor Cores aceleran las operaciones de menor precisión.
Por qué: Una menor precisión reduce a la mitad la memoria y multiplica el rendimiento; el escalado de la pérdida / BF16 preserva la estabilidad numérica.
Nombrar la base que permite que el software se ejecute en GPUs NVIDIA.
CUDA — la plataforma de computación paralela y el modelo de programación de NVIDIA; CUDA-X es la capa de bibliotecas (cuDNN, cuBLAS, NCCL, RAPIDS, etc.).
Por qué: Frameworks como PyTorch/TensorFlow llaman a las bibliotecas CUDA-X internamente; CUDA es la barrera que vincula el software de IA a las GPUs NVIDIA.
Acelerar las primitivas de deep learning (convoluciones, atención) dentro de un framework.
cuDNN proporciona primitivas de DL optimizadas para GPU; cuBLAS maneja el álgebra lineal densa; ambos se encuentran debajo de PyTorch/TensorFlow.
Por qué: Estas bibliotecas son la razón por la que los frameworks obtienen velocidad de GPU sin que escribas CUDA kernels.
Obtener contenedores, modelos y Helm charts optimizados por NVIDIA y listos para GPU.
Catálogo NGC (NVIDIA GPU Cloud) — registro curado de contenedores optimizados (frameworks, NIM, Triton), modelos preentrenados y SDKs.
Por qué: Los contenedores NGC vienen ajustados y probados para GPUs NVIDIA, eliminando las conjeturas sobre dependencias y compatibilidad de drivers.
Servir muchos modelos de múltiples frameworks detrás de un único endpoint estandarizado y eficiente para GPU.
NVIDIA Triton Inference Server — servicio de modelos multi-framework con procesamiento por lotes dinámico, ejecución concurrente de modelos y compartición de GPU.
Por qué: Triton maximiza la utilización de la GPU para la inferencia mediante el procesamiento por lotes y la concurrencia de modelos en lugar de un proceso por modelo.
Desplegar rápidamente un foundation model como un microservicio de inferencia optimizado y listo para producción.
NVIDIA NIM — microservicios de inferencia preconstruidos y contenerizados con motores optimizados y APIs estándar para modelos populares.
Por qué: NIM empaqueta el modelo + el tiempo de ejecución optimizado (TensorRT-LLM/Triton) + API en una unidad desplegable, reduciendo el tiempo de puesta en producción.
Reducir la latencia de inferencia y aumentar el rendimiento para un modelo entrenado.
Compilar el modelo con TensorRT (o TensorRT-LLM para LLMs) — fusión de capas, calibración de precisión (INT8/FP8) y auto-tuning del kernel.
Por qué: TensorRT produce un motor de inferencia optimizado para la GPU de destino, a menudo multiplicando el rendimiento en comparación con el framework original.
Acelerar la preparación de datos al estilo pandas/scikit-learn y el ML clásico en GPUs.
NVIDIA RAPIDS — cuDF (DataFrames), cuML (ML), cuGraph (grafos) ejecutan el flujo de trabajo de ciencia de datos en GPUs.
Por qué: RAPIDS mantiene el ETL tabular y el ML clásico en la GPU, evitando cuellos de botella de la CPU en el pipeline.
Gestionar cargas de trabajo de IA, trabajos y usuarios en un clúster DGX/SuperPOD.
NVIDIA Base Command — programación de trabajos, gestión de clústeres y orquestación de cargas de trabajo para la infraestructura DGX.
Por qué: Base Command es el plano de control de operaciones para sistemas DGX; maneja el envío de trabajos multiusuario y el seguimiento de recursos.
Necesitar software de IA compatible, seguro y de grado de producción con SLAs empresariales.
NVIDIA AI Enterprise — el conjunto de software compatible (frameworks, NIM, Triton, RAPIDS, GPU Operator) con parches de seguridad y soporte empresarial.
Por qué: Agrupa la pila validada con soporte y garantías de ciclo de vida, lo que los entornos regulados/de producción requieren.
Definir un foundation model y cómo los equipos lo adaptan.
Modelo grande preentrenado con datos amplios, adaptable a muchas tareas mediante prompting, RAG o fine-tuning en lugar de entrenar desde cero.
Por qué: La adaptación (prompt/RAG/fine-tune) es mucho más barata que el preentrenamiento; la mayoría de las empresas consumen foundation models, no los construyen.
Añadir conocimiento privado/actual a una aplicación respaldada por LLM.
Hechos que cambian con frecuencia → RAG (recuperar de un vector store en la inferencia). Enseñar nuevo comportamiento/estilo/habilidad de dominio → fine-tuning.
Por qué: RAG mantiene los datos externos y actualizables sin reentrenamiento; el fine-tuning incorpora el comportamiento en los pesos y es más costoso de actualizar.
Juzgar si las costosas GPUs se están utilizando eficientemente.
Rastrear la utilización de la GPU, el uso de memoria y la actividad de SM/Tensor-Core; una baja utilización indica cuellos de botella en el pipeline de datos, el tamaño del lote o la programación.
Por qué: Una alta "ocupación" de la GPU en tiempo real aún puede enmascarar una baja computación efectiva; observar la ocupación de Tensor-Core/SM, no solo el indicador de utilización.
Monitorizar la salud, utilización, temperatura, energía y errores de la GPU en un clúster.
NVIDIA DCGM (Data Center GPU Manager) — telemetría, comprobaciones de salud y diagnósticos; exportar métricas a Prometheus/Grafana.
Por qué: DCGM es la fuente estándar de telemetría de GPU; el DCGM Exporter alimenta Prometheus para paneles y alertas de todo el clúster.
Aprovisionar drivers de GPU, el kit de herramientas de contenedores y monitorización en un clúster de Kubernetes sin configuración manual por nodo.
NVIDIA GPU Operator — automatiza la configuración de driver, tiempo de ejecución de contenedores, plugin de dispositivo, DCGM y MIG en Kubernetes.
Por qué: Gestiona el ciclo de vida completo del software de GPU de forma declarativa, eliminando las frágiles instalaciones de drivers nodo por nodo.
Elegir un orquestador para cargas de trabajo de GPU.
Microservicios/inferencia, cloud-native, cargas de trabajo mixtas → Kubernetes. Trabajos de entrenamiento por lotes estilo HPC, gang scheduling, clústeres tradicionales → Slurm.
Por qué: Kubernetes sobresale en servicios de larga duración y elasticidad; Slurm sobresale en trabajos por lotes en cola con programación estilo MPI.
Los pods de Kubernetes necesitan solicitar y ser programados en GPUs.
El plugin de dispositivo de NVIDIA anuncia las GPUs como recursos programables; los pods solicitan `nvidia.com/gpu` y el programador los asigna.
Por qué: Sin el plugin de dispositivo, Kubernetes no puede ver ni asignar GPUs; es lo que convierte a las GPUs en un recurso de primera clase.
Muchos trabajos/usuarios pequeños deben compartir GPUs para aumentar la utilización.
Aislamiento de hardware → MIG. Compartición suave de una GPU → time-slicing o MPS. Combinar con cuotas de namespace para equidad.
Por qué: MIG ofrece garantías de QoS; time-slicing/MPS sobresuscriben una GPU sin aislamiento. Elegir según el requisito de aislamiento.
El entrenamiento de alta prioridad debe preceder a los experimentos de baja prioridad en un clúster compartido.
Usar prioridad/preemption y colas en el programador (particiones de Slurm o Kubernetes PriorityClasses con cuota); programar trabajos multi-GPU en grupo (gang-schedule).
Por qué: El gang scheduling evita bloqueos por asignación parcial; las clases de prioridad imponen el orden de negocio en GPUs disputadas.
Mantener las versiones de drivers de GPU, CUDA y el kit de herramientas de contenedores consistentes y compatibles entre nodos.
Estandarizar a través del GPU Operator (Kubernetes) o contenedores NGC; hacer coincidir el driver con las versiones de CUDA que sus frameworks necesitan y aplicar actualizaciones en ventanas de mantenimiento.
Por qué: Las inconsistencias de Driver/CUDA/framework son una de las principales causas de fallos del clúster; CUDA fijado a contenedor desacopla la aplicación del driver del host dentro de los rangos soportados.
Dimensionar un clúster de GPU para la demanda prevista de entrenamiento e inferencia.
Separar el entrenamiento (pico, por lotes) de la inferencia (sostenida, limitada por latencia); planificar el margen de energía/refrigeración/tejido y apuntar a una alta utilización constante.
Por qué: Sobredimensionar desperdicia CapEx en GPUs inactivas; subdimensionar estrangula la entrega. Planificar según la mezcla de cargas de trabajo, no un solo pico.
Las GPUs se ralentizan o fallan bajo carga pesada sostenida.
Monitorizar temperatura y energía vía DCGM; asegurar refrigeración adecuada (líquida para racks densos), establecer límites de energía razonables y alertar sobre umbrales térmicos.
Por qué: La limitación térmica reduce silenciosamente el rendimiento; la telemetría proactiva y el diseño de refrigeración protegen tanto el rendimiento como la vida útil del hardware.
Ofrecer aceleración de GPU a múltiples VMs o usuarios de VDI desde hardware compartido.
El software NVIDIA vGPU particiona una GPU física entre VMs con programación y aislamiento; MIG puede respaldar perfiles vGPU para particionamiento duro.
Por qué: vGPU permite el acceso a GPU virtualizadas/multi-inquilino (VDI, cloud) que el passthrough bare-metal no puede compartir.
Un nodo devuelve errores Xid o trabajos fallidos; se deben aislar las GPUs defectuosas antes de que corrompan más ejecuciones.
Ejecutar diagnósticos DCGM y comprobaciones de salud activas; acordonar/drenar el nodo, reemplazar o reiniciar la GPU, y solo entonces devolverla al pool.
Por qué: Los errores Xid y las fallas ECC señalan GPUs defectuosas; el control de salud automatizado evita que una GPU enferma contamine el pool de programación.