Arquitectura de clúster GPU: cómputo, red, almacenamiento y plano de control

La arquitectura de un clúster GPU es la forma de todo el sistema, no solo el número de GPU. Un clúster de producción tiene que coordinar nodos de cómputo, red de alta velocidad, almacenamiento, un programador, controles de acceso, telemetría y rutas de recuperación antes de poder convertir aceleradores costosos en ejecuciones de entrenamiento útiles o inferencia fiable.

La pregunta práctica es simple: ¿puede tu equipo mover datos, programar trabajos, recuperarse de fallos y medir costes lo bastante rápido como para mantener ocupadas las GPU? Si no, un clúster con mejores tarjetas aún puede ofrecer una economía peor que un servicio de GPU gestionado más pequeño o una API de modelos.

Esta guía ofrece a los equipos de plataforma de IA un modelo de trabajo para la arquitectura de clúster GPU: qué pertenece a la capa de cómputo, qué debe demostrar la red, cómo encajan el almacenamiento y el checkpointing, cómo Kubernetes o Slurm se convierten en el plano de control y qué probar antes de alquilar o comprar capacidad multinodo.

La regla práctica de Flatkey es empezar por el límite de la carga de trabajo. Si el producto solo necesita resultados de modelo, compara primero una ruta de GPU cloud vs model API. Si necesitas pesos personalizados, control de ubicación, entrenamiento de larga duración o infraestructura privada de serving, entonces diseña el clúster GPU en torno a los requisitos de cómputo, red, almacenamiento y plano de control de la carga de trabajo.

Respuesta rápida sobre la arquitectura de clúster GPU

Un clúster GPU útil tiene cuatro planos:

Una arquitectura de clúster gpu multinodo funciona cuando estos planos se diseñan juntos. Cómputo sin fabric es capacidad aislada. Fabric sin almacenamiento solo mueve cuellos de botella. Kubernetes sin cuota, telemetría y runbooks es solo un mecanismo de lanzamiento.

Diagrama de arquitectura de clúster GPU

Usa este diagrama como marco de revisión antes de comparar proveedores o aprobar el diseño de un rack.

                  users / CI / product traffic / API clients
                                  |
                                  v
        +------------------------------------------------------+
        | control plane                                        |
        | Kubernetes or Slurm scheduler, queues, quotas,       |
        | secrets, registry access, policy, telemetry, billing |
        +------------------------------------------------------+
              |                    |                    |
              v                    v                    v
   +-------------------+   +-------------------+   +-------------------+
   | gpu compute node  |   | gpu compute node  |   | gpu compute node  |
   | GPUs, CPU, RAM,   |   | GPUs, CPU, RAM,   |   | GPUs, CPU, RAM,   |
   | local NVMe, NICs  |   | local NVMe, NICs  |   | local NVMe, NICs  |
   +-------------------+   +-------------------+   +-------------------+
              \                  |                  /
               \                 |                 /
                v                v                v
        +------------------------------------------------------+
        | high-speed fabric                                   |
        | NVLink/NVSwitch inside node; InfiniBand, RoCE, EFA, |
        | or Ethernet across nodes; placement and routing     |
        +------------------------------------------------------+
                                  |
                                  v
        +------------------------------------------------------+
        | storage and data path                               |
        | object store, shared filesystem, local scratch,      |
        | model cache, checkpoints, snapshots, backups        |
        +------------------------------------------------------+

Para un kubernetes gpu cluster architecture diagram, añade los objetos específicos de Kubernetes alrededor del plano de control:

cluster admins -> node images -> GPU Operator / device plugin -> GPU nodes
app teams      -> namespace -> quota -> job queue -> Pod / Job / RayJob
finance        -> labels -> usage export -> cost per job / team / model
security       -> secrets -> image policy -> network policy -> audit logs

El diagrama es intencionadamente sencillo. El objetivo no es dibujar cada servicio. El objetivo es detectar responsabilidades que faltan antes de que el clúster se convierta en una dependencia de producción.

Empieza por la carga de trabajo, no por el rack

Antes de elegir Kubernetes, Slurm, una reserva en la nube o un proveedor bare-metal, redacta un resumen de una página de la carga de trabajo.

Si no puede completar esta tabla, aún no firme un contrato largo de capacidad. Alquile una porción más pequeña, ejecute pruebas de rendimiento y convierta los registros en el resumen de compras. La guía de alquiler de clústeres GPU ofrece la lista de verificación desde el lado de compra una vez que la forma de la arquitectura esté clara.

Plano de cómputo: los nodos GPU no son intercambiables

El plano de cómputo define lo que un trabajo puede usar realmente. Una especificación de cómputo completa incluye más que "8x H100" o "clúster B200".

Solicite:

• Modelo de GPU, tamaño de memoria y PCIe frente a SXM cuando corresponda.
• GPUs por nodo y la topología intra-nodo.
• Modelo de CPU, cantidad de CPU, RAM del sistema y disposición NUMA.
• Capacidad local de NVMe y rendimiento esperado.
• Cantidad de NIC, velocidad de NIC y si se admiten rutas directas de GPU.
• Controlador, CUDA, runtime de contenedores y ciclo de vida de la imagen del sistema operativo.
• Política de asignación de MIG, vGPU, time-slicing o GPU completa.
• Homogeneidad de los nodos y política de reemplazo.

La topología intra-nodo importa porque ocho GPUs en un servidor no equivalen a ocho nodos de una sola GPU. El diseño del nodo define la presión de memoria, los cuellos de botella de CPU, la velocidad de preparación local y lo costosa que se vuelve la comunicación entre nodos.

La documentación de NVIDIA sobre el operador de GPU de Kubernetes es útil aquí porque muestra cómo los controladores, el NVIDIA Container Toolkit, el plugin de dispositivos, la telemetría de DCGM y componentes relacionados pueden gestionarse como una pila de clúster en lugar de como una configuración puntual de cada nodo. La documentación del plugin de dispositivos de Kubernetes explica el punto de extensión general que se usa para exponer dispositivos de proveedores como recursos programables.

Plano de red: demuestre la red con una prueba de rendimiento

El entrenamiento multinodo y el servicio de alto rendimiento dependen de la red. Una especificación de clúster debe indicar la red y la prueba de aceptación, no solo el titular de ancho de banda.

Solicite:

• Detalles de NVLink o NVSwitch intra-nodo.
• Diseño cross-node de InfiniBand, RoCE, EFA o Ethernet.
• Cantidad y velocidad de NIC por nodo.
• Garantía de ubicación y dominio de fallo.
• Relación de sobre suscripción.
• Compatibilidad con GPUDirect RDMA cuando corresponda.
• Modelo de red de contenedores y host.
• Observabilidad de errores de la red, retransmisiones, congestión y fallos de nodo.

Utilice una prueba de aceptación antes de que comience el compromiso:

prueba de aceptación de red:
  ejecute NCCL all_reduce en cada nodo alquilado
  registre ancho de banda, latencia, IDs de nodo, modelo de GPU, driver, CUDA, versión de NCCL
  repita después de instalar la imagen de contenedor de producción
  guarde los registros y compárelos con la topología cotizada por el proveedor

NVIDIA NCCL y las pruebas de NCCL son referencias estándar para validar el comportamiento de la comunicación colectiva en cargas de trabajo GPU distribuidas. La clave no es perseguir un solo número de benchmark. La clave es detectar nodos no coincidentes, mala ubicación, congestión de la red o desviaciones de driver/contenedor antes de que falle una ejecución completa de entrenamiento.

Para inferencia, la prueba de red debe incluir la ruta real del tráfico: entrada de solicitudes, comunicación entre fragmentos del modelo, comportamiento de la KV-cache cuando corresponda, recuperaciones desde almacenamiento y salida. Una red de entrenamiento que parece sólida de forma aislada aún puede producir mala latencia para el usuario si la pila de servicio cruza demasiados límites de red.

Plano de almacenamiento: mantenga datos, pesos y checkpoints fuera de la ruta crítica

El almacenamiento es donde muchos planes de arquitectura de clúster GPU se vuelven costosos. La cotización de GPU es visible. La ruta de datos a menudo permanece oculta hasta la primera ejecución en producción.

Diseñe el almacenamiento alrededor de cuatro flujos:

Para entrenamiento, el rendimiento de los checkpoints y el tiempo de restauración son cuestiones de arquitectura, no detalles de copia de seguridad. Para inferencia, la carga de pesos del modelo, el calentamiento de la caché local y el comportamiento del volumen persistente afectan el tiempo de despliegue y el tiempo de conmutación por error.

La documentación de GPUDirect Storage de NVIDIA es una fuente útil cuando la arquitectura requiere una ruta de datos directa entre el almacenamiento local o remoto y la memoria de la GPU. No todos los clústeres necesitan GPUDirect Storage, pero los equipos que mueven grandes conjuntos de datos o checkpoints deben decidir explícitamente si la pila de almacenamiento es normal, optimizada o un cuello de botella que aceptan.

Plano de control: ¿Kubernetes, Slurm o ambos?

El plano de control convierte el hardware en una plataforma. Decide quién puede ejecutar qué, cuándo comienzan los trabajos, cómo se reintentan los fallos y cómo los equipos entienden el uso.

Arquitectura de clúster GPU de Kubernetes

Kubernetes encaja en plataformas GPU que necesitan despliegue de servicios, espacios de nombres multiusuario, flujos de trabajo nativos de contenedores, automatización basada en API, políticas e integración con observabilidad nativa de la nube. Una arquitectura de clúster GPU de Kubernetes de producción normalmente incluye:

• Imágenes de nodo y automatización de arranque.
• GPU Operator o gestión de controladores/dispositivos específica del proveedor.
• Complemento de dispositivo o Dynamic Resource Allocation para la exposición de GPU.
• Espacios de nombres, RBAC, secretos, política de extracción de imágenes y política de red.
• Jobs, Deployments, RayJob, operadores de entrenamiento o servicios de inferencia.
• Kueue u otra capa de colas cuando la equidad por lotes es importante.
• Cuotas por equipo, proyecto, entorno o cliente.
• DCGM, Prometheus, registros, trazas y etiquetas de facturación.
• Controles de admisión para imágenes, cargas de trabajo privilegiadas, montajes del host y uso compartido de GPU.

Los complementos de dispositivo de Kubernetes exponen las GPU como recursos extendidos. Kubernetes Dynamic Resource Allocation añade un modelo de recursos más rico basado en solicitudes para dispositivos y otros recursos especializados. Kueue añade conceptos de colas de trabajos como workloads, colas, cohorts y resource flavors para la planificación por lotes y de IA/ML. Juntas, estas herramientas pueden convertir un conjunto de GPU en una plataforma gobernada en lugar de un conjunto de máquinas accesibles por SSH.

Arquitectura de clúster GPU de Slurm

Slurm encaja bien en muchos entornos de estilo HPC e investigación porque está construido alrededor de colas, particiones, contabilidad, reservas y trabajos por lotes. La documentación de GRES de Slurm cubre los recursos GPU y cómo los solicitan los trabajos.

Slurm suele ser una buena opción cuando:

• Los usuarios envían trabajos de entrenamiento por lotes.
• La política de colas es central.
• Los equipos ya tienen experiencia operativa en HPC.
• La carga de trabajo es menos orientada a servicios.
• MPI, pruebas de NCCL y la contabilidad por lotes son primitivas operativas familiares.

Algunas organizaciones usan ambos: Slurm para investigación y grandes colas de entrenamiento, Kubernetes para servicios de inferencia y APIs de plataforma. Eso puede funcionar, pero solo si la identidad, el acceso a datos, la observabilidad y la asignación de costos se diseñan en ambos sistemas.

La observabilidad y los controles de costos deben formar parte del diseño inicial

No añadas telemetría después de que el clúster esté en producción. Las preguntas que importan para ingeniería y finanzas son previsibles:

• ¿Qué trabajos usaron qué GPU?
• ¿Qué espacio de nombres, equipo, cliente, modelo o experimento causó el gasto?
• ¿Cuál fue la utilización útil, no solo el tiempo de GPU asignado?
• ¿Cuánto tiempo se pasó esperando en la cola?
• ¿Qué fallos consumieron más GPU-horas?
• ¿Qué cuello de botella de almacenamiento o red causó GPU inactivas?
• ¿Cuál fue el costo por ejecución completada o salida aceptada?

La telemetría mínima debe incluir:

• Utilización de GPU, utilización de memoria, potencia, temperatura y eventos ECC.
• Tiempo de ejecución por trabajo, tiempo de cola, número de reintentos, motivo de salida y propietario.
• Salud de la red fabric e historial de benchmarks.
• Throughput de almacenamiento, latencia, tiempo de checkpoint y tiempo de restauración.
• Eventos de asignación del programador y denegaciones de cuota.
• Etiquetas de facturación o exportaciones de uso vinculadas a las unidades de negocio.

La línea base de modelo/API de Flatkey importa aquí. Si una API de modelo gestionada produce la misma salida aceptada con un costo unitario más claro y menos carga operativa, el clúster tiene que superar esa línea base después de contabilizar el tiempo de inactividad, los reintentos, el almacenamiento y la mano de obra.

La seguridad, el aislamiento y el diseño de acceso forman parte de la arquitectura

Los clústeres GPU a menudo comienzan como proyectos de ingeniería y se convierten en infraestructura compartida. Trate el diseño de acceso como parte de la arquitectura.

Defina:

• Autenticación y fuente de identidad.
• Aislamiento por espacio de nombres, proyecto o cuenta.
• Política SSH, si la hay.
• Registro de imágenes de contenedor, firma y análisis.
• Gestión de secretos.
• Política de salida de red.
• Eliminación de datos y limpieza después de los trabajos.
• Retención de registros de auditoría.
• Acceso de emergencia.
• Acceso del soporte del proveedor y flujo de trabajo de intervención remota.

Para clústeres multiusuario, decida si se permite compartir GPU. La asignación de GPU completa es más simple. MIG, vGPU o time-slicing pueden mejorar la utilización, pero también cambian el aislamiento, la telemetría, la programación y las expectativas de rendimiento.

Dimensionamiento del clúster: convierta la arquitectura en números

El dimensionamiento debe estar impulsado por la unidad útil:

required_gpu_capacity =
  target_work_completed_per_month
  / useful_work_per_gpu_month_after_failures_idle_and_retries

Después, sométalo a pruebas de presión:

Para un modelo de costos, conecte este artículo con su hoja de cálculo de TCO de clúster GPU:

effective_cluster_unit_cost =
  (compute + network + storage + support + operations + idle + retries)
  / accepted workload units

El denominador debe coincidir con el producto: ejecuciones de entrenamiento completadas, tokens de inferencia aceptados, trabajos de medios generados, actualizaciones de índices de búsqueda o solicitudes de clientes.

Lista de verificación de revisión de arquitectura

Use esta lista de verificación antes de aprobar un multi node gpu cluster architecture diagram o una cotización del proveedor.

Referencias oficiales que conviene tener abiertas

Use la documentación oficial como verificación de fuente durante la revisión de arquitectura:

Tome estas referencias como arquitectura de referencia, no como sustituto de las pruebas de aceptación en el clúster exacto que va a ejecutar.

Cuándo un clúster GPU es la arquitectura equivocada

No construya ni reserve un clúster solo porque el precio por hora de GPU parezca atractivo. Un clúster GPU directo puede ser la arquitectura equivocada cuando:

• El producto solo necesita salidas del modelo.
• La mezcla de modelos cambia cada semana.
• El equipo no puede operar controladores, planificadores, almacenamiento, redes e incidentes.
• La carga de trabajo es intermitente y de baja utilización.
• El movimiento de datos domina el cómputo.
• Compras quiere un compromiso de tres años antes de que exista evidencia de benchmarks.
• Finanzas no puede vincular el gasto del clúster con las salidas aceptadas.

En esos casos, compare primero los precios de alquiler de GPU en la nube, GPU serverless o una API de modelo. La arquitectura correcta es la que ofrece una salida aceptada confiable con el menor costo operativo total, no la que tiene el mayor inventario de aceleradores. Para un análisis de mercado a nivel de proveedor, use la comparación de nube GPU antes de solicitar cotizaciones.

Conclusión final

Una sólida arquitectura de clúster GPU es un diseño de sistema: nodos de cómputo que se ajustan a la carga de trabajo, una infraestructura de red validada por benchmarks, almacenamiento que no prive de recursos a las GPU y un plano de control que pueda programar, asegurar, observar y repercutir el uso.

Para experimentos pequeños, comience con APIs alquiladas o gestionadas. Para entrenamiento multinodo serio o inferencia privada, utilice el diagrama y la lista de verificación anteriores antes de comprometerse con un proveedor, un rack o una reserva. El error costoso no es elegir Kubernetes en lugar de Slurm, o H100 en lugar de H200. El error costoso es comprar capacidad GPU antes de que la arquitectura demuestre que puede convertir esa capacidad en trabajo útil.