Alquilar un servidor GPU: guía de arquitectura, rendimiento y despliegue en la nube

Si necesita alquilar un servidor GPU para una carga de trabajo de entrenamiento, inferencia, ajuste fino o medios, comience con un plan de carga de trabajo y aceptación por escrito, no con un listado de GPU. La solicitud adecuada permite comprobar la memoria de acelerador necesaria, el tiempo de ejecución, la topología, la ruta de datos, el comportamiento de recuperación y la métrica de éxito antes de que una reserva se convierta en una dependencia de producción.

El alquiler de GPU es el modelo operativo adecuado cuando su equipo necesita controlar el entorno del acelerador, como el tiempo de ejecución, los pesos del modelo, la disposición del almacenamiento, las redes o el calendario de despliegue, sin comprar ni operar el hardware en sí. La decisión no es realmente «¿qué GPU tiene la tarifa por hora más baja?». Se trata de determinar si una GPU alquilada puede lograr un resultado definido de la carga de trabajo de forma segura, predecible y a un coste que su equipo pueda explicar.

Esta guía ofrece a desarrolladores de IA e ingenieros de infraestructura de ML una forma práctica de planificar un alquiler de GPU, desplegarlo y aceptarlo en producción. Deliberadamente no clasifica proveedores ni cita precios transitorios. Estos cambian con demasiada rapidez como para fundamentar una decisión de ingeniería duradera. En su lugar, se centra en la arquitectura, las comprobaciones de validación y las señales de la carga de trabajo que le acompañan en distintos modelos de nube y alquiler.

Respuesta rápida: elija el alquiler de GPU menos persistente y menos exclusivo que pueda satisfacer sus requisitos de memoria, latencia, rendimiento, residencia de datos y control operativo. Valídelo con su modelo real, indicaciones representativas y una prueba de aceptación por escrito antes de comprometerse con una reserva más prolongada.

Comience por la carga de trabajo, no por el listado de GPU

Una solicitud de alquiler de GPU debe comenzar como un resumen de la carga de trabajo. Una solicitud imprecisa como «necesitamos una H100» dificulta comparar capacidad, probar un despliegue o explicar el coste. Un resumen útil describe el trabajo que debe completarse y los límites que no pueden modificarse.

Utilice una tarjeta de modelo, un conjunto de indicaciones representativas y una porción de conjunto de datos similar a producción cuando esté permitido. Los benchmarks sintéticos son útiles para solucionar problemas, pero son un sustituto débil de la combinación de longitudes de indicaciones, concurrencia, preprocesamiento y calidad de salida que el producto realmente necesita.

Cómo alquilar un servidor GPU: utilice una tarjeta de aceptación por escrito

La forma más segura de alquilar un servidor GPU es tratar la primera asignación como una prueba de aceptación. Documente la carga de trabajo, solicite la asignación más pequeña que pueda ejecutarla de forma segura y recopile evidencias antes de ampliar la reserva o mover tráfico de producción. No alquile un servidor GPU basándose únicamente en el nombre de una GPU o en una sola cifra por hora.

Tarjeta de aceptación para alquilar un servidor GPU

Para Kubernetes, verifique la ruta del complemento de dispositivo del proveedor, así como el manifiesto de la carga de trabajo. Kubernetes expone recursos de GPU mediante complementos de dispositivo y tiene reglas específicas de límites/solicitudes para recursos extendidos. Consulte la guía de programación de GPU de Kubernetes antes de considerar un manifiesto como prueba de despliegue.

Para un nodo de centro de datos NVIDIA que esté inactivo y sea seguro de probar, registre la entidad objetivo y el resultado del diagnóstico pertinente. NVIDIA documenta los diagnósticos DCGM como comprobaciones activas que pueden evaluar software, memoria, PCIe, NVLink, alimentación y otras rutas; coordine estas comprobaciones con el planificador porque pueden consumir capacidad real. Un registro mínimo de evidencia puede incluir:

nvidia-smi -L
nvidia-smi topo -m
dcgmi discovery --list
dcgmi diag --run 1 --entity-id gpu:0

Utilice la sintaxis de comandos, el alcance de las pruebas y los permisos documentados para la versión de DCGM instalada. Un diagnóstico aprobado es evidencia de esa ejecución de prueba, no una promesa general de que todas las cargas de trabajo futuras funcionarán de la misma manera.

Para entrenamiento con varias GPU o inferencia distribuida, añada una operación colectiva representativa a la carga de trabajo de aceptación y conserve la evidencia de la topología y de la interfaz de red. La documentación distribuida de PyTorch explica el contexto de CUDA/NCCL y los ajustes de interfaz de diagnóstico que pueden ayudar a investigar un problema en la ruta de comunicación. Para la inferencia basada en vLLM, capture las métricas que se ajusten al contrato de la aplicación —como la latencia de las solicitudes, el comportamiento de los tokens de salida, las preempciones y las señales relacionadas con la caché—, en lugar de aceptar una respuesta única de terminal como resultado de rendimiento.

Las seis capas de un alquiler de GPU para producción

La expresión alquiler de GPU puede describir varios productos diferentes. Trate el acelerador alquilado como una capa de un sistema operativo, no como la solución completa.

1. Capa de capacidad: el modelo de GPU, la memoria, la partición, la tenencia, la cuota y la duración de la asignación.
2. Capa de tiempo de ejecución: controlador, bibliotecas CUDA, tiempo de ejecución de contenedores, framework, servidor de modelos y archivo lockfile de dependencias.
3. Capa de datos: almacenamiento de objetos, volúmenes, puntos de control, artefactos de modelos, cifrado, reglas de ciclo de vida y prueba de restauración.
4. Capa de red: entrada, tráfico entre servicios, conectividad privada, reglas de firewall, descargas de imágenes y cualquier necesidad de tejido multi-GPU o multinodo.
5. Capa de programación: cola de trabajos, política de escalado automático, reglas de colocación, reintentos, comportamiento de drenaje y alternativa de capacidad.
6. Capa de operaciones: identidad, secretos, registros, métricas, comprobaciones de estado, diagnósticos, presupuestos y un responsable de incidentes.

Un alquiler que parece económico en la capa de capacidad puede seguir siendo una mala opción si no puede satisfacer una capa inferior. Por ejemplo, un trabajo por lotes con grandes puntos de control puede verse limitado por la recuperación del almacenamiento; un endpoint de baja latencia puede verse limitado por el arranque en frío o el tiempo de cola; y un trabajo distribuido puede verse limitado por la topología en lugar del número bruto de aceleradores.

Elija el límite de asignación que se ajuste al trabajo

No existe un alquiler de GPU «mejor» de forma universal. La elección útil es el límite de asignación que proporcione a su carga de trabajo suficiente control sin pagar por capacidad inactiva ni trabajo operativo innecesario.

Si ya opera Kubernetes, las GPU se consumen mediante plugins de dispositivos del proveedor. Kubernetes documenta los recursos de GPU como recursos personalizados proporcionados por plugins de dispositivos e indica que las cantidades de GPU pertenecen a los límites de un contenedor; si también se configura requests, debe coincidir con el límite. La documentación de Kubernetes sobre la programación de GPU es la fuente de referencia para el comportamiento actual de los recursos.

apiVersion: v1
kind: Pod
metadata:
  name: inference-smoke-test
spec:
  restartPolicy: Never
  containers:
    - name: server
      image: registry.example.com/inference:immutable-tag
      resources:
        limits:
          nvidia.com/gpu: 1
      envFrom:
        - secretRef:
            name: model-service-secrets

El manifiesto es solo una solicitud de programación, no una prueba de preparación. Confirme el controlador, el entorno de ejecución, el artefacto del modelo, los permisos de almacenamiento, la política de red y el estado del servicio antes de considerar el alquiler de GPU como capacidad utilizable. Cuando la pila de NVIDIA sea adecuada, el NVIDIA GPU Operator puede automatizar el despliegue de los componentes de software de NVIDIA necesarios para aprovisionar recursos de GPU en Kubernetes; fije y pruebe la combinación de componentes compatible con su entorno.

Diseñe la arquitectura del alquiler de GPU antes del despliegue

Para la experimentación puntual, puede bastar un entorno sencillo. Para un camino hacia producción, dibuje el flujo de solicitudes y el flujo de fallos antes de reservar capacidad:

Client / job submitter
        ↓
Auth + queue / scheduler
        ↓
GPU workload service ─── logs, traces, model metrics
        ↓                         ↓
Persistent model + data storage   health / alerting
        ↓
Backup, checkpoint, and restore path

Formule pronto cuatro preguntas de arquitectura:

• ¿Qué debe persistir? Decida si los pesos del modelo, los artefactos compilados, las cachés, los prompts, los puntos de control y las salidas pueden desaparecer junto con la asignación. La simple suposición de que hay un «volumen conectado» no es un plan de restauración.
• ¿Qué debe ser privado? Identifique el límite de red e identidad para los datos, los registros de paquetes, la telemetría y la administración. Limite las credenciales a las necesidades reales de la carga de trabajo y rótelas fuera de la imagen.
• ¿Qué debe escalar? Diferencie entre un servicio de una GPU, una cola de trabajos independientes y una carga de trabajo que requiere comunicación coordinada entre múltiples GPU o nodos. Fallan de forma distinta y necesitan pruebas de carga diferentes.
• ¿Qué sucede cuando desaparece la capacidad? Defina la frecuencia de los puntos de control, las reglas de reintento de trabajos, la visibilidad de la cola, una clase de asignación alternativa y una vía de degradación orientada al usuario antes de que ocurra una interrupción.

La respuesta puede ser un diseño deliberadamente pequeño: una única VM con GPU, una imagen inmutable, un volumen conectado, una cola de trabajos y una regla de apagado. El objetivo no es crear un clúster para cada alquiler de GPU; es hacer explícito el límite de control.

Despliegue por etapas, no en una única reserva prolongada

Un lanzamiento por etapas reduce la probabilidad de que su primer alquiler prolongado se convierta en una sesión de depuración. Mantenga un breve registro de evidencias en cada etapa.

1. Prueba rápida del entorno. Inicie la imagen exacta del contenedor. Verifique que la GPU sea visible, que el framework pueda crear un contexto, que se carguen los artefactos de modelo requeridos y que el servicio pueda acceder únicamente a las dependencias que necesita.
2. Prueba funcional. Ejecute entradas conocidas y compruebe el formato de salida, la lógica de seguridad y la fijación de la versión del modelo. Para entrenamiento o ajuste fino, demuestre que se puede escribir y restaurar un punto de control.
3. Prueba de carga representativa. Utilice una distribución realista de prompts o trabajos. Mida el tiempo en cola, el tiempo de inicio, el tiempo hasta el primer token o primer resultado, el rendimiento, la latencia de cola, el margen de memoria, los errores y los reintentos.
4. Prueba de fallos. Drene o detenga un trabajador, reinicie el servicio, invalide una caché y simule un fallo de dependencia. Verifique que los puntos de control, los reintentos, las alertas y el estado visible para el usuario se comporten según lo diseñado.
5. Revisión de aceptación. Compare el resultado registrado con el resumen de la carga de trabajo. Solo entonces decida si ampliar, reservar, dedicar o escalar el alquiler de GPU.

Para un servidor de modelos como vLLM, evite tratar una única cifra agregada de «tokens por segundo» como una respuesta completa. Su actual documentación de métricas de producción distingue entre la latencia de solicitud de extremo a extremo, el tiempo en cola, el tiempo de inferencia, el tiempo de prefill, el tiempo de decodificación, el tiempo hasta el primer token, la latencia entre tokens y las señales de residencia en caché. El mismo principio se aplica a otros entornos de ejecución: mida las etapas que importan para la experiencia del usuario y para el asignador.

Utilice una prueba de aceptación de rendimiento que pueda fallar

Una prueba de aceptación es un contrato entre el equipo de ingeniería y la decisión de alquiler de GPU. Debe ser lo suficientemente breve como para ejecutarse repetidamente y lo bastante específica como para rechazar un entorno deficiente.

Para hardware dedicado o propiedad de un clúster, valide el nodo antes de que acepte cargas de trabajo de alto valor. NVIDIA documenta que DCGM Diagnostics puede probar rutas de despliegue, hardware e integración, incluidas verificaciones relacionadas con cómputo, memoria, PCIe, NVLink, alimentación, temperatura y comunicación. Estos diagnósticos pueden consumir recursos y entrar en conflicto con el trabajo activo, así que coordínelos con el planificador y ejecute pruebas invasivas solo en capacidad que esté autorizado a vaciar. Una aprobación es evidencia operativa, no un sustituto de las pruebas de carga a nivel de aplicación.

Realice el seguimiento del coste por trabajo completado, no solo de una cifra por hora

El precio por hora es una entrada para una decisión de alquiler de GPU, pero no describe la unidad real de valor. Alquile un servidor GPU basándose en una métrica de trabajo completado, pero cuente cada componente facturado solo una vez:

Coste por trabajo completado =
  (acelerador facturado sin solapamientos + recursos del host + almacenamiento/snapshots
   + red/egress + soporte o licencias)
  ÷ salidas aceptadas o trabajos completados

El denominador debe coincidir con el producto: imágenes aceptadas, vídeos completados, trabajos exitosos, solicitudes dentro de un SLO o lotes que cumplan los criterios de calidad. Registre el tiempo inactivo y los trabajos fallidos como campos de diagnóstico que expliquen el resultado; no los añada de nuevo si ya están incluidos en el tiempo facturado del acelerador. Realice un seguimiento por separado de las salidas rechazadas y los reintentos; de lo contrario, un alquiler de GPU aparentemente rápido puede ocultar un problema de fiabilidad o calidad.

Utilice la guía de precios de alquiler de GPU para conocer el vocabulario de los modelos de precios, los costes ocultos de la nube GPU para identificar los campos que suelen desaparecer de una cotización por hora, y la guía sobre GPU sin servidor frente a GPU dedicada para decidir cuánta capacidad mantener activa. Para una decisión de infraestructura más amplia, la guía sobre nube GPU frente a API de modelos explica cuándo operar su propio entorno de ejecución puede ser menos atractivo que consumir una API de modelos gestionada.

Cuándo el alquiler de GPU es la abstracción equivocada

No alquile un servidor GPU simplemente porque una carga de trabajo use IA. Una API de modelos gestionada suele ser más sencilla cuando no necesita controlar el entorno de ejecución subyacente, los pesos del modelo, la topología del acelerador ni la arquitectura del plano de datos. Puede reducir el trabajo de despliegue para funcionalidades de producto que principalmente necesitan un resultado de inferencia.

El alquiler de GPU resulta más atractivo cuando necesita un modelo personalizado, un entorno de ejecución controlado, un límite de datos fijo, preprocesamiento o posprocesamiento especializado, capacidad predecible de larga duración o una plataforma de ingeniería que atienda muchas cargas de trabajo. La respuesta adecuada también puede ser híbrida: mantenga la carga de trabajo que necesita control de sistemas en GPU alquiladas y dirija las llamadas a modelos de uso común a través de una capa de API. Flatkey puede evaluarse como esa capa de API para cargas de trabajo que no requieren control directo del acelerador; no debe presentarse como sustituto de un clúster de GPU cuando el control a nivel de host es un requisito.

Lista de verificación de preparación para el alquiler de GPU

Antes de ampliar una reserva o mover un alquiler de GPU a producción, confirme todo lo siguiente:

• El resumen de la carga de trabajo indica la revisión del modelo, la precisión, la configuración de memoria, el objetivo de rendimiento, el límite de datos y el responsable.
• El límite de asignación elegido se ajusta al trabajo: sin servidor, VM, nodo dedicado o clúster.
• El entorno de ejecución se inicia desde una imagen inmutable y puede restaurar los artefactos requeridos de modelo, datos y punto de control.
• Una prueba de carga representativa registra el comportamiento de inicio, cola, latencia, rendimiento, memoria, errores y reintentos.
• Las comprobaciones de estado y las alertas tienen un responsable; los diagnósticos se programan sin interrumpir a los inquilinos ni las cargas de trabajo activas.
• La regla de apagado, reducción de escala o revisión de la reserva se documenta antes de que la capacidad quede inactiva.
• La vista de costes utiliza el trabajo completado e incluye almacenamiento, transferencia, operaciones, tiempo inactivo y trabajo fallido.
• Existe una ruta alternativa para la pérdida de asignación, la escasez de capacidad o un despliegue fallido.

Preguntas frecuentes

¿Qué debo comprobar antes de alquilar un servidor GPU?

Antes de alquilar un servidor GPU, defina la carga de trabajo, el límite de asignación, la memoria de acelerador necesaria, el controlador y entorno de ejecución compatibles, el requisito de topología, la ruta del planificador, la carga de trabajo de aceptación, la prueba de restauración del punto de control y el registro de costes del trabajo completado. Valide un nodo inactivo con el flujo de trabajo de comprobación de estado aprobado y, después, ejecute un trabajo representativo antes de comprometer más capacidad.

¿Qué incluye el alquiler de una GPU?

Varía según el modelo de asignación. Puede recibir solo una superficie de ejecución de trabajos, una VM, un host dedicado o una asignación de clúster. Confirme la capacidad de GPU, el acceso al entorno de ejecución, la persistencia del almacenamiento, las redes, el límite de soporte y el comportamiento ante interrupciones, en lugar de asumir que «alquiler de GPU» implica un nivel concreto de control.

¿Cómo elijo entre una GPU y varias GPU?

Comience con el requisito de memoria del modelo y su objetivo de rendimiento. Añada GPU solo cuando un dispositivo no pueda satisfacer la configuración de memoria o cuando un cuello de botella medido justifique el paralelismo. El trabajo con varias GPU también añade consideraciones de topología, comunicación, programación y fallos, por lo que debe probarse como una arquitectura diferente y no como un simple multiplicador.

¿Puedo ejecutar GPU alquiladas en Kubernetes?

Sí, si el clúster cuenta con los controladores del proveedor y el complemento de dispositivos adecuados. Kubernetes expone las GPU como recursos personalizados; utilice etiquetas de programación y reglas de ubicación cuando el hardware difiera entre nodos. Valide todo el entorno de ejecución y la carga de trabajo, no solo la asignación del planificador.

¿Cuánto debería durar el primer alquiler de GPU?

Haga que la asignación inicial sea lo bastante larga para completar una prueba de humo, una prueba de carga representativa y una comprobación de fallos/recuperación. No contrate una reserva más larga hasta que la prueba de aceptación documentada se supere con la carga de trabajo que importa.

Documente la decisión

El mejor alquiler de GPU es el que cumple un resultado de carga de trabajo verificado con el menor límite de control seguro. Redacte el resumen de la carga de trabajo, despliegue por etapas, mida toda la ruta de la solicitud y conserve las pruebas que permitan al siguiente ingeniero reproducir la decisión. Si no puede explicar qué debe persistir, qué debe escalar, cómo es un fallo y qué se considera trabajo completado, no está listo para optimizar el precio del alquiler.

Cuando alquile un servidor GPU, utilice esas pruebas para decidir si ampliar, reservar, dedicar, escalar o elegir una abstracción diferente. Si el producto solo necesita la salida del modelo y no necesita control de la infraestructura, compare las ventajas y desventajas operativas en la guía de nube GPU frente a API de modelo.

Para el siguiente punto de decisión, compare la arquitectura de este artículo con la guía de arquitectura de servidores GPU, la guía de racks de servidores GPU y la guía de clústeres GPU de Kubernetes.

Fuentes

• Kubernetes: programar GPU
• Documentación de NVIDIA GPU Operator
• Diagnósticos de NVIDIA DCGM
• Referencia de NVIDIA dcgmi diag
• Documentación distribuida de PyTorch
• Métricas de producción de vLLM