Un rack de servidores GPU no es solo un gabinete lleno de aceleradores. Es un límite de despliegue donde la topología de GPU, la estructura de red, el almacenamiento, la gestión, la alimentación, la refrigeración y la planificación trabajan conjuntamente, o generan costosos cuellos de botella.
Para los desarrolladores de IA y los ingenieros de infraestructura de ML, la pregunta útil no es «¿Cuántas GPU caben en un rack?». Es: ¿puede este rack proporcionar el comportamiento de comunicación, ruta de datos y recuperación que necesita la carga de trabajo? Esta guía convierte esa pregunta en una lista de verificación de arquitectura y un plan de aceptación en la nube.
¿Qué es un rack de servidores GPU?
Un rack de servidores GPU es un rack físico o una asignación a escala de rack gestionada por un proveedor que contiene uno o más servidores GPU, además de los componentes de red, alimentación, refrigeración y gestión necesarios para operarlos. En un despliegue en la nube, quizá no controle el gabinete en sí, pero aun así debería preguntar qué partes de la topología están garantizadas: GPU por host, interconexión dentro del host, estructura de host a host, ruta de almacenamiento, dominio de mantenimiento y política de colocación.
Un único servidor GPU es un nodo. Un rack de servidores GPU es el sistema que rodea a varios nodos. Un clúster de GPU puede abarcar uno o más racks. Estas distinciones importan porque un servicio de inferencia puede estar limitado por la memoria GPU y la ruta PCIe/NVLink de un único host, mientras que el entrenamiento distribuido o la inferencia a gran escala pueden quedar limitados por las rutas de red y almacenamiento entre hosts.
La arquitectura de referencia BasePOD de NVIDIA ilustra la diferencia: separa una red de computación InfiniBand, una estructura Ethernet de gestión y almacenamiento, y una red de gestión fuera de banda. Su diseño no tiene que copiar esa arquitectura de referencia, pero debe hacer explícitas las rutas equivalentes antes de comprometer capacidad. Arquitectura de referencia NVIDIA DGX BasePOD
Arquitectura de un rack de servidores GPU: los seis elementos que se deben mapear
Comience con un diagrama del rack que muestre la ubicación física y las rutas lógicas. Si un proveedor no puede revelar todos los componentes, registre qué está garantizado y pruebe el resto durante el período de aceptación.
| Capa | Qué documentar | Por qué cambia los resultados |
|---|---|---|
| Nodos de cómputo | Modelo de GPU, cantidad de GPU por host, CPU/RAM, NVMe local, dominio de reemplazo | Define la capacidad de memoria, la capacidad de preprocesamiento del lado del host y el radio de impacto de un fallo de nodo. |
| Topología dentro del nodo | Diseño PCIe, disponibilidad de NVLink/NVSwitch, afinidad GPU-NIC | Determina si las GPU de un host pueden intercambiar datos de manera eficiente. |
| Estructura entre nodos | Tipo de red, cantidad y velocidad de NIC, nivel de conmutadores, política de sobresuscripción, colocación en el mismo rack | Determina el comportamiento de la comunicación colectiva una vez que el trabajo sale de un servidor. |
| Ruta de almacenamiento | Caché local, sistema de archivos compartido o almacenamiento de objetos, destino de puntos de control, ruta de red | Evita que la carga de datos y los puntos de control resten tiempo de cómputo. |
| Gestión y control | Acceso BMC/fuera de banda, inventario, planificador, métricas, control de cambios | Hace que un rack sea operable cuando falla un host o un controlador. |
| Entorno de infraestructura | Asignación de potencia del rack, redundancia de PDU, diseño de flujo de aire o refrigeración líquida, acceso de servicio | Restringe la densidad sostenible y el mantenimiento, no solo lo que cabe físicamente. |
1. Trate la topología como una entrada de la carga de trabajo
La cantidad de GPU es una descripción incompleta de la capacidad. Para un host, examine cómo se conectan las GPU entre sí y con las NIC. Entre hosts, identifique si un trabajo permanecerá en un servidor, en un rack o cruzará racks. Registre la regla de colocación esperada en la especificación de la carga de trabajo, en lugar de asumir que «ocho GPU» describe la misma máquina en todas partes.
NCCL utiliza rutas directas de igual a igual cuando CUDA informa que las GPU relevantes pueden acceder a la memoria de las demás. NVIDIA documenta nvidia-smi topo -p2p como una forma de inspeccionar el estado de igual a igual; úselo como dato de validación, no como sustituto de un benchmark de carga de trabajo. Guía de solución de problemas de GPU de NCCL
2. Separe el tráfico de cómputo, datos y gestión
Un rack de servidores GPU necesita más que una red de entrenamiento rápida. El tráfico de gestión, las descargas de artefactos, la telemetría, el almacenamiento compartido y el acceso de usuarios pueden interferir con el tráfico de las cargas de trabajo cuando comparten una ruta insuficiente. Utilice rutas lógicas o físicas separadas donde su arquitectura lo requiera y, a continuación, defina qué ruta transporta cada uno de los siguientes elementos:
- comunicación colectiva y tráfico directo a GPU;
- descargas de imágenes, pesos de modelos, conjuntos de datos y puntos de control;
- tráfico de Kubernetes, SSH, BMC, registro y monitorización;
- salida hacia API, almacenamiento de objetos o servicios posteriores.
Esto es especialmente importante en la capacidad en la nube: pregunte si las cifras de ancho de banda describen el ancho de banda de host a host, el enlace ascendente del rack, el rendimiento de almacenamiento o un agregado de mejor esfuerzo. No son intercambiables.
3. Diseñe la alimentación y la refrigeración como restricciones de capacidad
No dimensione un rack de servidores GPU únicamente a partir de las unidades de rack. Una configuración que cabe físicamente puede estar limitada por la alimentación de la instalación, la redundancia de PDU, la dirección del flujo de aire, los requisitos de refrigeración líquida, el radio de curvatura de los cables o el espacio libre para mantenimiento. NVIDIA señala que los diseños de rack varían según la potencia máxima local y la infraestructura de refrigeración; utilice la documentación actual de su proveedor de servidores y de su proveedor de colocación para conocer la asignación real. Preguntas frecuentes de NVIDIA DGX SuperPOD
Antes del despliegue, solicite una respuesta por escrito a estas preguntas:
- ¿Cuál es el margen de potencia sostenida del rack y qué supuesto de redundancia incluye?
- ¿El diseño de refrigeración es por aire, líquida directa al chip, intercambio de calor mediante puerta trasera o una combinación?
- ¿Qué componente desencadena primero la limitación de rendimiento o un evento de mantenimiento: el host, la PDU, el switch de red o el circuito de la instalación?
- ¿Puede un técnico realizar el mantenimiento de un nodo, cable o componente de puerta trasera sin interrumpir la capacidad adyacente?
Si el despliegue es solo en la nube, traduzca las mismas preguntas a los términos del proveedor: colocación en host dedicado, dominio de mantenimiento, política de sustitución de hosts y si la asignación puede cambiar de topología después del aprovisionamiento.
4. Dé al programador conocimiento del rack solo cuando sea útil
Las etiquetas de rack son valiosas cuando la carga de trabajo depende de la localidad o los dominios de fallo. Un trabajo de entrenamiento distribuido puede preferir una colocación en un solo rack antes de expandirse entre racks. Un servicio de inferencia de alta disponibilidad puede distribuir deliberadamente las réplicas entre racks o hosts. Comience con un conjunto pequeño y auditable de etiquetas, como topology.rack, topology.host-class, topology.fabric y topology.failure-domain, y luego verifique que la colocación del programador las siga.
Para Kubernetes, valide toda la pila de software de GPU con respecto a su sistema operativo, Kubernetes, controlador, tiempo de ejecución y opción de despliegue compatibles, no solo la versión del clúster. La matriz de compatibilidad de GPU Operator de NVIDIA distingue entre bare metal, máquinas virtuales con GPU passthrough y despliegues vGPU, y publica detalles de compatibilidad para entornos compatibles. Compatibilidad de plataformas de NVIDIA GPU Operator
Cómo elegir un rack de servidores GPU para su carga de trabajo
Utilice el resumen de la carga de trabajo para decidir si necesita un único host de alta densidad, un rack o un clúster de varios racks.
| Patrón de carga de trabajo | Normalmente se prioriza | Pregunte al proveedor o al equipo de plataforma |
|---|---|---|
| Ajuste fino o inferencia en un solo nodo | Memoria de GPU, topología dentro del nodo, almacenamiento local, sustitución fiable del host | ¿Qué GPU e interconexiones están conectadas a un host? ¿Se pueden asignar juntas todas las GPU necesarias? |
| Entrenamiento distribuido | Colocación en el mismo rack, tejido de red, afinidad de NIC, rendimiento de checkpoints | ¿Qué se garantiza para la red de host a host? ¿Cómo se expone o se evita la colocación entre racks? |
| Inferencia multinodo | Latencia de cola, comunicación entre fragmentos del modelo, seguridad de los despliegues, observabilidad | ¿Se pueden distribuir las réplicas por dominio de fallo mientras los rangos paralelos del modelo mantienen conocimiento de la topología? |
| Cargas de trabajo por lotes o de renderizado | Comportamiento de la cola, caché local, gestión de interrupciones, preparación de imágenes y datos | ¿Cuál es la garantía de colocación y cómo se recuperan los trabajos interrumpidos? |
| Plataforma interna compartida | Aislamiento, cuota, política del programador, visibilidad de capacidad, control de cambios | ¿Cómo se gobiernan las particiones de GPU, los límites de inquilinos, los controladores y las actualizaciones? |
Para un nuevo despliegue, compare la decisión del rack con una alternativa más sencilla. Si el trabajo no requiere control sobre la topología, la localidad de los datos o una pila de servicio personalizada, una API de modelos gestionada puede tener una menor carga operativa. Utilice esta comparación entre nube de GPU y API de modelos como parte de la decisión, en lugar de tratar un rack de servidores GPU como la respuesta predeterminada.
Cómo evaluar el rendimiento de un rack de servidores GPU
No acepte un rack de servidores GPU basándose únicamente en una cifra máxima del acelerador. Elabore una prueba de aceptación breve que separe las principales rutas de rendimiento.
Paso 1: Capture un inventario y una línea base de topología
Para cada host asignado, recopile la identidad de la GPU, las versiones del controlador y de CUDA, la topología de GPU a GPU, la afinidad de GPU a NIC, la disposición NUMA de la CPU, el almacenamiento local y las interfaces de red. Conserve este registro con la revisión del despliegue. Le proporciona un punto de comparación cuando el rendimiento cambia después de una sustitución de imagen, firmware, controlador o host.
nvidia-smi -L
nvidia-smi topo -m
nvidia-smi topo -p2p p
nvidia-smi topo -p2p n
No cambie la configuración del kernel, BIOS, IOMMU o control de acceso PCIe siguiendo una lista de verificación genérica. NVIDIA documenta el comportamiento de peer-to-peer sensible a la configuración en sistemas Linux bare metal; utilice la configuración compatible para el servidor y la plataforma en la nube que realmente opera. Solución de problemas de topología y peer-to-peer de NCCL
Paso 2: Pruebe en los límites que importan
Ejecute pruebas representativas en tres ámbitos:
- Nodo único para validar la visibilidad de la GPU y la ruta local de NVLink/NVSwitch o PCIe.
- Mismo rack para validar la colocación de host a host y el tejido local.
- Entre racks para comprender la ruta que utilizará su programador cuando la capacidad se expanda o se produzca una conmutación por error.
La guía de pruebas NCCL de NVIDIA utiliza explícitamente ejecuciones de nodo único, un solo rack y varios racks para validar la visibilidad de la GPU, la interconexión dentro del nodo, el tejido entre nodos y la colocación. Registre la latencia y el ancho de banda junto con el comando de prueba, el digest de la imagen de contenedor, la lista de nodos y las etiquetas de colocación para que un resultado pueda reproducirse. Tutorial de validación de NCCL
Paso 3: Mida la ruta real de la aplicación
A continuación, ejecute la carga de trabajo que pretende ofrecer. Para entrenamiento, informe el tiempo por paso, la espera de datos, el tiempo de comunicación colectiva, el tiempo de punto de control y el comportamiento de recuperación. Para inferencia, informe el tiempo hasta el primer token, el rendimiento de salida, la latencia de cola, el retraso en la cola, el comportamiento de la caché y las tasas de error o reinicio. Mantenga el mismo modelo, perfil de lote/concurrencia, longitud de contexto y estado de caché al comparar ubicaciones.
Así es como se distingue un problema de GPU de un problema de datos, red, planificador o configuración.
Paso 4: Pruebe un fallo planificado
Un rack de servidores GPU operativo necesita una ruta de recuperación. Antes del tráfico de producción, verifique qué sucede cuando se drena un trabajador, un nodo deja de estar disponible, un trabajo es interrumpido o un punto de control debe reanudarse en otro lugar. Confirme que los datos persistentes estén separados del cómputo reemplazable y que las credenciales, las imágenes y la observabilidad sigan funcionando en la ruta de reemplazo.
Despliegue un rack de servidores GPU en la nube: una secuencia práctica
El despliegue en la nube cambia el límite de control, no el trabajo de ingeniería. Aún debe hacer visibles las suposiciones de hardware y ubicación.
- Redacte el contrato de la carga de trabajo. Especifique el tamaño del modelo, el número de GPU, el requisito de memoria, el SLO de latencia o rendimiento, la sensibilidad de red, la fuente de datos, la ubicación de los puntos de control, el objetivo de disponibilidad y la barrera presupuestaria.
- Elija el límite de topología. Decida si el trabajo debe permanecer dentro de un host, un rack o una estructura multirrack definida. Trate esto como un requisito en la solicitud al proveedor, no como una preferencia informal.
- Solicite una hoja de asignación. Solicite la clase de host, el número de GPU, la interconexión de GPU, las NIC, la estructura de red, las opciones de almacenamiento, la garantía de ubicación, la política de mantenimiento y cualquier metadato de topología expuesto a su planificador.
- Fije el contrato de software. Registre el sistema operativo, el kernel, el controlador NVIDIA, CUDA, el tiempo de ejecución de contenedores, la versión de Kubernetes, la versión de GPU Operator, la imagen del framework y el resumen de la imagen de la aplicación. Valide la combinación con la matriz compatible antes del lanzamiento.
- Cree una ventana de aceptación limitada. Ejecute pruebas de inventario, topología, comunicación en el mismo nodo/mismo rack/entre racks, almacenamiento, aplicación y recuperación antes de mover tráfico sostenido.
- Instrumente cada capa. Configure alertas por separado para la salud de las GPU, errores de la estructura, espera de almacenamiento, espera del planificador, eventos térmicos o de limitación y SLO de la aplicación. Una única métrica de utilización no puede explicar un incidente a escala de rack.
- Mantenga opciones de salida y recuperación. Mantenga definiciones de imágenes, configuración de infraestructura, ubicaciones de datos persistentes, puntos de control y un plan de reversión independientes de una asignación concreta.
Para las partes de esta secuencia a nivel de host, consulte la guía de despliegue de servidores GPU. Para la perspectiva del plano de control y la estructura multinodo, consulte la guía de arquitectura de clústeres GPU.
Lista de verificación de aceptación de racks de servidores GPU
Utilice esta lista de verificación antes de aceptar un nuevo rack de servidores GPU, una asignación dedicada en la nube o una implementación de colocación.
- [ ] El contrato de la carga de trabajo nombra un límite de topología: un host, el mismo rack o multirrack.
- [ ] La hoja de asignación identifica el número de GPU por host, la interconexión de aceleradores, las NIC, la estructura de red y la ruta de almacenamiento.
- [ ] La alimentación, la refrigeración, la redundancia de PDU, los requisitos de flujo de aire o refrigeración líquida y el espacio para mantenimiento tienen un responsable.
- [ ] Se registran las versiones de GPU, controlador, CUDA, kernel, tiempo de ejecución de contenedores y orquestación.
- [ ] El planificador expone y respeta las etiquetas de ubicación o dominio de fallo donde la carga de trabajo las necesita.
- [ ] Las salidas de inventario y topología de
nvidia-smise almacenan para cada clase de host. - [ ] Las pruebas de comunicación cubren las ubicaciones de un solo nodo, mismo rack y entre racks que el planificador de producción puede crear.
- [ ] La prueba de la aplicación utiliza una fuente de datos y un perfil de carga de trabajo representativos.
- [ ] Se prueban las rutas de punto de control, drenaje de host, reemplazo y reversión.
- [ ] Los informes de costes separan el tiempo productivo de GPU de los costes de inactividad, reintentos, datos y soporte, sin contar el mismo tiempo dos veces. Para el modelo de costes más amplio, comience con esta guía de alquiler de GPU.
Preguntas frecuentes
¿Es un rack de servidores GPU lo mismo que un clúster de GPU?
No. Un rack de servidores GPU describe un límite de despliegue físico o administrado por el proveedor a escala de rack. Un clúster de GPU es un grupo lógico de nodos que puede abarcar parte de un rack, un rack completo o varios racks. La diferencia es importante cuando la red, el almacenamiento, los dominios de fallo y la programación atraviesan límites físicos.
¿Cuántos servidores GPU caben en un rack de servidores GPU?
No existe un número universal útil. La profundidad del servidor y las unidades de rack son solo la primera restricción. La respuesta práctica depende del consumo de energía del servidor, el diseño de refrigeración, la capacidad y redundancia de la PDU, el tendido de cables, el acceso para mantenimiento y la densidad aprobada de la instalación. Valide la respuesta con el diseño exacto de host, rack y centro de datos que utilizará.
¿Todos los racks de servidores GPU necesitan InfiniBand?
No. La estructura adecuada depende de la carga de trabajo y la topología. Las cargas de trabajo de un solo host pueden no necesitar en absoluto una estructura de alto rendimiento entre nodos. Las cargas de trabajo distribuidas deben probarse en la ruta de red que utilizarán realmente, incluida la ubicación en el mismo rack y entre racks. Evite seleccionar una estructura basándose únicamente en una especificación de marketing.
¿Qué debo probar antes de aceptar capacidad de rack GPU en la nube?
Pruebe la asignación que recibió: inventario de hardware, topología, afinidad GPU-NIC, comportamiento del almacenamiento local y compartido, comunicación de un solo nodo, comunicación dentro del mismo rack, comunicación entre racks si es posible en producción, comportamiento representativo de la aplicación y recuperación ante un fallo planificado.
¿Cuándo debo evitar operar un rack de servidores GPU?
Evite las operaciones a escala de rack cuando su carga de trabajo no necesite el control que proporcionan. Si una API de modelo administrada puede cumplir los requisitos de modelo, latencia, disponibilidad, privacidad y coste, puede eliminar el trabajo relacionado con hardware, tejido de red, controladores, planificador y gestión de capacidad. Haga esta comparación deliberadamente antes de comprometerse con un rack de servidores GPU.
Construya el rack en torno a la carga de trabajo
Un rack de servidores GPU tiene éxito cuando su diseño físico y su asignación en la nube se ajustan a las rutas de comunicación, datos y recuperación de la carga de trabajo. Haga explícita la topología, separe las clases de tráfico que pueden interferir entre sí, valide el rendimiento en los ámbitos de un solo nodo, mismo rack y entre racks, y acepte la capacidad solo después de haber probado la aplicación real y una ruta de fallo.
Si no se requiere control a nivel de rack, compare una opción de API de modelo antes de asumir la carga operativa. Si se requiere, utilice esta guía junto con la guía de servidores GPU, la guía de arquitectura de clústeres GPU y la lista de comprobación de costes de la nube GPU para convertir la capacidad en un despliegue verificable.
