Servidor GPU: guía de arquitectura, rendimiento y despliegue en la nube

Un servidor GPU es más que un acelerador conectado a una CPU. Para las cargas de trabajo de IA, la unidad útil es todo el sistema: memoria de la GPU, memoria del host, canales de la CPU, ruta de almacenamiento, ruta de red, tiempo de ejecución, política de programación y la forma de medir el trabajo completado.

Esta guía ayuda a desarrolladores de IA e ingenieros de infraestructura de ML a elegir, desplegar y validar un servidor GPU en la nube sin reducir la decisión a un nombre de modelo o una tarifa por hora. Úsela para redactar una especificación de la carga de trabajo, probar la topología que realmente está obteniendo, desplegar de forma segura y mantener los costes vinculados a resultados útiles.

La respuesta rápida: ¿qué es un servidor GPU?

Un servidor GPU es un servidor físico o virtual configurado con una o más unidades de procesamiento gráfico para cómputo paralelo. Normalmente incluye:

• Una o más GPU y su memoria de alto ancho de banda (HBM o VRAM)
• CPU, RAM del sistema, canales PCIe y una topología de placa base
• NVMe local para cachés o preparación, además de almacenamiento persistente para datos y puntos de control
• Interfaces de red para usuarios, almacenamiento de objetos y, en sistemas multinodo, comunicación colectiva
• Controladores, un tiempo de ejecución de contenedores, monitorización y, en ocasiones, una capa de orquestación

Para inferencia, el servidor GPU debe sostener al mismo tiempo el modelo, la caché KV, el comportamiento de procesamiento por lotes y el objetivo de latencia. Para entrenamiento o ajuste fino distribuido, la ruta de comunicación entre GPU y nodos puede importar tanto como el rendimiento bruto del acelerador. Para pipelines de medios y por lotes, el almacenamiento y el comportamiento de inicio a menudo determinan si la máquina dedica su tiempo facturado a realizar trabajo útil.

La implicación práctica es sencilla: elija un servidor GPU a partir de una especificación de la carga de trabajo y, después, valídelo con su propia carga de trabajo. No suponga que dos hosts con la misma etiqueta de acelerador se comportarán de la misma manera.

Arquitectura de un servidor GPU: las seis capas que determinan los resultados

Piense en un servidor GPU como seis capas conectadas. Una capa débil puede limitar todo el sistema.

El acelerador y la memoria son la restricción inicial, no la respuesta completa

Comience por la huella de memoria del modelo, el plan de precisión o cuantización, la longitud de contexto prevista, la concurrencia y el margen de seguridad. La GPU necesita espacio para algo más que los pesos estáticos: el servicio también requiere asignaciones en tiempo de ejecución, espacios de trabajo y, a menudo, una caché KV en crecimiento. El entrenamiento añade activaciones, gradientes y estado del optimizador.

Por eso, una guía de selección de GPU para IA debe comenzar con la carga de trabajo, no con una clasificación genérica de la «mejor GPU». Si la carga de trabajo cabe cómodamente en un dispositivo, la interconexión adicional puede ser irrelevante. Si necesita paralelismo de tensores o entrenamiento sincronizado, la topología pasa a formar parte del requisito de capacidad.

La topología intranodo determina si varias GPU actúan como un equipo

El trabajo con varias GPU no es rápido automáticamente. Las GPU pueden comunicarse mediante PCIe, enlaces directos de alto ancho de banda o un tejido de conmutación, y la ruta puede variar según el par. NVIDIA documenta que nvidia-smi topo -m ayuda a revelar la topología intranodo y que las herramientas de ancho de banda pueden validar las rutas previstas de GPU a GPU.

Antes de comprometerse con un servidor de varias GPU, recopile:

1. El mapa de topología para el tipo exacto de host.
2. La disponibilidad de comunicación entre pares para los pares de GPU que utilizará su framework.
3. Una referencia simple de ancho de banda o de comunicación colectiva.
4. La afinidad de CPU y NIC con respecto a las GPU.

Un sistema basado en NVLink o NVSwitch puede proporcionar un diseño de comunicación diferente al de una disposición solo PCIe. La documentación de Fabric Manager de NVIDIA describe el papel de NVLink y NVSwitch en la conexión de GPU y la gestión del tejido. Trate esto como una cuestión de adecuación a la carga de trabajo, no como una insignia: un endpoint de inferencia independiente de una sola GPU no necesita el mismo tejido que un trabajo sincronizado con varias GPU.

El plano del host y la ruta de datos son cuellos de botella frecuentes

Una GPU puede permanecer inactiva mientras el host tokeniza, descodifica medios, carga fragmentos, restaura un punto de control o copia datos a través de una ruta PCIe inesperada. Solicite detalles sobre CPU, RAM, NUMA, disco local y red junto con la especificación del acelerador.

Use el NVMe local de forma deliberada para cachés y preparación desechables. Coloque los artefactos de modelos, conjuntos de datos, puntos de control, flujos de trabajo y resultados aceptados en almacenamiento que sobreviva a una instancia reemplazable cuando deban persistir. Esta separación facilita la recreación de un servidor GPU en la nube y reduce el riesgo de que una detención, un cambio de tamaño o un host fallido elimine el trabajo que necesita reanudar.

El software convierte una GPU en capacidad programable

Para un solo servidor, la ruta mínima de software suele ser un controlador compatible, un entorno de ejecución compatible con CUDA, herramientas de contenedores, una imagen de carga de trabajo, observabilidad y una ruta de acceso controlada. En Kubernetes, un servidor GPU también necesita detección de dispositivos, el complemento de dispositivos del proveedor y una política de programación.

Kubernetes expone las GPU mediante complementos de dispositivos y recursos personalizados programables; su documentación sobre programación de GPU explica que los recursos de GPU se solicitan mediante límites de contenedor. El GPU Operator de NVIDIA agrupa componentes comunes como controladores, el kit de herramientas de contenedores, el complemento de dispositivos, el etiquetado de nodos y la monitorización basada en DCGM. Estos componentes reducen el trabajo de configuración repetitivo, pero usted sigue siendo responsable de la compatibilidad de versiones, la política de acceso y las pruebas de aceptación.

Elija el servidor GPU a partir del resumen de la carga de trabajo

Redacte este resumen de una página antes de evaluar una oferta de servidor GPU para IA o de alojamiento de servidor GPU dedicado:

Este resumen evita un desajuste costoso. Una carga de trabajo de servicio de baja latencia puede necesitar capacidad predecible y artefactos precargados. Un trabajo por lotes puede tolerar interrupciones si guarda puntos de control correctamente. Una ejecución de entrenamiento puede necesitar comunicación colectiva validada y puntos de control duraderos. Que un anuncio incluya «servidor GPU NVIDIA» o «GPU de servidor» no basta para responder a ninguna de esas preguntas.

Para evaluar las compensaciones entre modelos de capacidad, compare la capacidad de GPU sin servidor frente a la dedicada después de conocer la tolerancia a la inactividad y las necesidades operativas de la carga de trabajo.

Cómo evaluar el rendimiento de un servidor GPU

La especificación que parece más rápida no es necesariamente la que completa la carga de trabajo más rápido. Establezca una línea base en este orden.

1. Mida el resultado orientado al usuario o al trabajo

Elija un conjunto reducido de métricas que el propietario de la carga de trabajo reconozca:

• Servicio interactivo de LLM: tiempo hasta el primer token, latencia entre tokens, solicitudes correctas por minuto y latencia de cola con la concurrencia prevista.
• Inferencia por lotes o generación de medios: elementos completados por hora, tasa de fallos/reintentos, retraso de cola y coste por resultado aceptado.
• Entrenamiento o ajuste fino: muestras/tokens por segundo, tiempo por paso, tiempo de comunicación, duración del punto de control y tiempo de recuperación.
• Embeddings o recuperación: documentos/vectores por segundo, tiempo de ingesta de extremo a extremo y tiempo de persistencia del índice.

Registre la distribución de entrada, la versión del modelo, la versión del entorno de ejecución, la concurrencia, el estado de la caché y el intervalo de tiempo. Un benchmark sin esas condiciones es difícil de reproducir o comparar.

2. Verifique la topología antes de ajustar el framework

Para una carga de trabajo con varias GPU, inspeccione primero la topología real. La guía de NCCL de NVIDIA recomienda comprobar el mapa dentro del nodo y medir el ancho de banda esperado de GPU a GPU antes de modificar parámetros de ajuste. También advierte que una mejora en un benchmark puede ser perjudicial en otros casos.

Esta es una medida de protección útil: no empiece copiando variables de entorno de otro host. Primero confirme que las GPU, las NIC, los controladores y la ruta de comunicación coinciden con los supuestos del resultado que desea obtener.

3. Separe el tiempo de cómputo, comunicación y ruta de datos

Si la utilización del acelerador es baja, la GPU no es automáticamente el problema. Divida una ejecución en:

1. Tiempo de cola y arranque en frío
2. Tiempo de descarga de artefactos o carga del modelo
3. Preprocesamiento o tokenización de CPU
4. Cómputo en GPU
5. Comunicación de GPU a GPU o de nodo a nodo
6. Tiempo de escritura de salida, punto de control o posprocesamiento

Esta descomposición hace evidente la siguiente prueba. Mida el almacenamiento si domina la carga del modelo. Mida la topología y las operaciones colectivas si los trabajos sincronizados se bloquean. Mida el comportamiento de la CPU y de la canalización de entrada si la GPU espera. Después, vuelva a probar la misma carga de trabajo, en lugar de comparar una nueva configuración con una ejecución no relacionada.

4. Use comprobaciones de estado y diagnósticos activos para preguntas diferentes

La telemetría de producción indica si un nodo ha presentado una condición mientras está en ejecución. Los diagnósticos activos prueban si un recurso drenado puede ejecutar una carga de trabajo conocida. La documentación de DCGM Diagnostics de NVIDIA distingue ambos enfoques y señala que las pruebas activas pueden consumir capacidad de cómputo, memoria, PCIe, interconexión, energía y refrigeración.

Ejecute diagnósticos invasivos únicamente en capacidad que haya retirado del servicio normal. Use la evidencia resultante para decidir si devuelve al servicio, aísla o investiga un servidor GPU, no como sustituto de las pruebas de aceptación a nivel de aplicación.

Despliegue un servidor GPU en la nube: una secuencia orientada a producción

La secuencia de despliegue siguiente funciona primero para una única máquina virtual o servidor bare metal, y luego se escala a un planificador cuando el modelo operativo lo requiere.

Paso 1: Separe el estado persistente del cómputo reemplazable

Defina tres clases de datos:

• Efímeros: capas de contenedor, artefactos compilados y cachés que pueden reconstruirse.
• Estado de ejecución duradero: modelos, conjuntos de datos, puntos de control, flujos de trabajo y resultados aceptados.
• Secretos y configuración: credenciales, acceso al registro, configuración del servicio y ajustes relevantes para auditoría.

Conecte el estado duradero mediante el método de almacenamiento adecuado para su plataforma. Mantenga una ruta de restauración explícita. Un despliegue reproducible de servidor GPU debería poder reemplazar el cómputo sin tener que adivinar dónde se encuentra el modelo o el último punto de control.

Paso 2: Fije y registre la pila de software

Registre la imagen del sistema operativo, la rama del controlador GPU, la compatibilidad de CUDA/runtime, el digest de la imagen de contenedor, la versión del framework, la revisión del modelo y la configuración de inicio. Evite usar «latest» como única referencia de versión para una carga de trabajo de producción.

Este registro ayuda a distinguir un problema de hardware o topología de un cambio accidental de software. También le proporciona un punto de reversión después de una actualización del controlador, el runtime o el modelo.

Paso 3: Haga que el acceso sea privado de forma predeterminada

Otorgue a usuarios y servicios únicamente el acceso que necesitan. Los controles habituales incluyen reglas de red de entrada restringidas, acceso administrativo basado en claves o identidad, credenciales de corta duración, rutas privadas para modelos y datos, cuentas de servicio con privilegios mínimos y un gestor de secretos en lugar de valores incorporados en las imágenes.

Los controles exactos dependen de su nube y de su límite de cumplimiento, pero el principio no cambia: un notebook expuesto, un puerto de inferencia o un escritorio remoto no constituyen una estrategia de despliegue.

Paso 4: Verifique el host antes de aceptar tráfico de carga de trabajo

Use una breve verificación previa:

• Confirme que el sistema operativo detecta el inventario de GPU y el controlador esperados.
• Confirme que un contenedor puede acceder a la GPU prevista.
• Ejecute una carga de trabajo representativa pequeña.
• Capture evidencia de topología y comunicación cuando haya más de una GPU involucrada.
• Lea y escriba en la ubicación de almacenamiento usada para modelos/puntos de control.
• Confirme que los registros, las métricas y las alertas llegan a un lugar donde un operador pueda actuar sobre ellos.

En un clúster de Kubernetes, instale la ruta de controlador y complemento de dispositivo compatible con el proveedor antes de programar cargas de trabajo. El siguiente patrón mínimo ilustra la declaración de recursos; ajuste la imagen, el espacio de nombres, los controles de seguridad y las reglas de programación para su propio entorno.

apiVersion: batch/v1
kind: Job
metadata:
  name: gpu-acceptance-check
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: workload
          image: registry.example.com/your-workload@sha256:replace-with-image-digest
          resources:
            limits:
              nvidia.com/gpu: 1

Use etiquetas de nodo, afinidad, taints y cuotas para evitar que cargas de trabajo incompatibles compitan por la misma capacidad de GPU. La guía de clústeres GPU de Kubernetes profundiza en la programación multinodo, las colas y los controles operativos.

Paso 5: Cree una puerta de aceptación antes de producción

Use la misma puerta para cada nuevo tipo de host, actualización de imagen o cambio sustancial de topología.

Control de costes: paga por el trabajo completado, no por una impresionante máquina inactiva

El precio de las GPU en la nube es solo una partida del coste total de un servidor GPU. Haz un seguimiento del período pagado frente a la salida útil:

completed-work cost = compute + storage + data movement + platform/operations overhead + failed/retried work

Luego pregunta:

• ¿El servidor permanece activo porque está atendiendo tráfico útil o simplemente porque apagarlo es inconveniente?
• ¿La carga de trabajo crea puntos de control y limpia los datos temporales de forma predecible?
• ¿Los artefactos del modelo se copian repetidamente en lugar de montarse desde una caché intencional o un almacenamiento persistente?
• ¿Los trabajos fallidos se reintentan sin presupuesto ni clasificación de errores?
• ¿Una topología con varias GPU realmente mejora el trabajo que importa?

Usa la guía de precios de alquiler de GPU para un enfoque de modelado de capacidad y la guía de costes ocultos de las GPU en la nube para cuestiones sobre almacenamiento, salida de datos, tiempo inactivo y soporte. Para un despliegue más grande, la guía de arquitectura de clústeres GPU cubre las capas de computación, red, almacenamiento y plano de control que aparecen cuando un servidor ya no es suficiente.

Cuándo un servidor GPU es la herramienta adecuada y cuándo no lo es

Usa un servidor GPU dedicado o un servidor GPU en la nube cuando necesites controlar el entorno de ejecución, los artefactos del modelo, la programación, las bibliotecas del sistema, la localidad de los datos o la topología de aceleradores. También es una opción sensata cuando la carga de trabajo tiene una demanda lo bastante estable como para justificar el límite operativo.

Elige una ruta de modelo/API gestionada cuando el control directo del sistema no forme parte del requisito y la prioridad sea ofrecer capacidad de modelo sin asumir la responsabilidad de los controladores, la asignación de capacidad, el mantenimiento del entorno de ejecución y el diagnóstico de hardware. La decisión debe comparar el coste del trabajo completado y la carga operativa, no simplemente «GPU en la nube» frente a «API» en una tabla de precios. Consulta GPU en la nube frente a API de modelo para conocer ese límite.

Lista de verificación para el despliegue de un servidor GPU

Antes de aprobar un servidor para producción, verifica que puedes responder sí a cada pregunta:

• ¿El resumen de la carga de trabajo especifica el modelo, la memoria, la concurrencia y la métrica de éxito?
• ¿Has probado la topología exacta del servidor GPU, no solo el modelo de acelerador?
• ¿Puedes reproducir la pila de software a partir de versiones fijadas y resúmenes de imagen?
• ¿El estado duradero está separado de la computación reemplazable?
• ¿La carga de trabajo tiene una ruta de acceso restringida y secretos gestionados?
• ¿Dispones de una línea base de la aplicación, además de evidencia de topología y ruta de datos?
• ¿Puede un operador ver el estado de salud, los errores, la utilización y la actividad relevante para los costes?
• ¿Has probado el reinicio o el reemplazo utilizando el mismo plan de estado persistente?
• ¿El servidor se detiene, escala o reutiliza cuando no está proporcionando trabajo útil?

Preguntas frecuentes

¿Para qué se utiliza un servidor GPU?

Un servidor GPU se utiliza para cargas de trabajo que se benefician de la aceleración paralela, incluida la inferencia de IA, el entrenamiento y ajuste fino de modelos, los embeddings, la simulación, el renderizado y los flujos de generación de medios. El despliegue adecuado depende de los requisitos de memoria, latencia, rendimiento, datos y operación de la carga de trabajo.

¿Un servidor GPU dedicado siempre es más rápido que la capacidad GPU sin servidor?

No. Un servidor GPU dedicado puede ofrecer más control y una capacidad activa más estable, pero su utilidad depende de la utilización, el comportamiento de inicio, el ajuste del entorno de ejecución y la ruta de datos circundante. La capacidad sin servidor puede ser más adecuada para trabajos con picos de demanda y reiniciables. Mide la carga de trabajo completada en las condiciones en las que realmente operarás.

¿Cómo elijo el servidor GPU adecuado para un LLM?

Empieza por los pesos del modelo, la precisión, la longitud del contexto, la concurrencia y el margen de capacidad de la caché KV. Después, determina si el modelo cabe en una GPU o requiere varios dispositivos, y evalúa el tiempo hasta el primer token, la latencia entre tokens, el rendimiento y el comportamiento de cola usando tráfico representativo. No elijas basándote solo en el número de parámetros.

¿Necesito Kubernetes para un servidor GPU?

No. Un único host bien controlado puede ser el despliegue fiable más sencillo. Kubernetes se vuelve más útil cuando necesita programación repetible, aislamiento, políticas, coordinación entre varios nodos o capacidad compartida entre equipos. Añádalo porque resuelve un problema operativo, no porque haya GPU involucradas.

¿Cómo puedo probar un servidor GPU antes de producción?

Pruebe el contenedor similar al de producción, una carga de trabajo pequeña y representativa, las lecturas/escrituras de almacenamiento, la observabilidad y la recuperación. Para cargas de trabajo con varias GPU, capture también evidencias de topología y comunicación. Use la supervisión de estado para obtener señales continuas y diagnósticos activos en capacidad retirada del servicio cuando necesite validación a nivel de infraestructura.

Construya el sistema en torno al trabajo

El servidor GPU adecuado es aquel que convierte repetidamente la entrada prevista en una salida aceptada, con rendimiento medible, estado recuperable y coste operativo controlado. Comience con la especificación de la carga de trabajo, valide el sistema que recibe y mantenga las decisiones de arquitectura vinculadas a evidencias en lugar de a una etiqueta de hardware.

Si el control directo del hardware es esencial, utilice esas evidencias para elegir y operar capacidad GPU con confianza. Si no lo es, compare el coste operativo del servidor con una vía de modelo/API gestionado antes de asumir una infraestructura que no necesita.

Fuentes

• Kubernetes: Programación de GPU
• NVIDIA GPU Operator
• Diagnósticos NVIDIA DCGM
• NVIDIA NCCL: Rendimiento y ajuste
• NVIDIA Fabric Manager