No pierdas tus GPUs durante el mantenimiento en Google Cloud

La demanda global de GPUs es astronómica. Conseguir recursos NVIDIA L4, A100 o H100 en Google Cloud Platform (GCP) suele sentirse como un gran logro para tu equipo de Engineering. Sin embargo, puedes perder esa capacidad cuando se realiza mantenimiento del hardware subyacente o cuando detienes manualmente tu instancia para ejecutar tareas de rutina.

Detener tu VM libera tus recursos, ya sea por un evento de mantenimiento programado de Google Cloud o por una detención iniciada por el usuario para parchear un driver, rotar una imagen o modificar los scopes de la instancia. Esto devuelve tu GPU al pool público y deja varados tus entrenamientos críticos de ML o tus workloads de inferencia. Aquí te mostramos cómo asegurar tus GPUs y garantizar que sobrevivan a las actualizaciones de infraestructura.

Restricciones importantes y casos especiales

Aunque las reservas son la defensa estándar contra la pérdida de capacidad, debes tener en cuenta ciertas reglas de arquitectura de GCP:

• Configuraciones de GPU restringidas: Debido a las restricciones extremas de suministro, algunas configuraciones de GPU más nuevas o muy demandadas no se pueden reservar con reservas de capacidad bajo demanda estándar. Por ejemplo, las configuraciones A4X Max, A3 Ultra y A3 High con menos de ocho GPUs actualmente tienen restricciones. Verifica siempre la elegibilidad de la reserva en la documentación de GCP.
• Spot VMs vs. CUD: Las reservas protegen los workloads de VMs estándar. No protegen las Spot VMs, que no pueden consumir reservas y son interrumpibles por diseño.
• CUD: Los descuentos por uso comprometido (CUD) afectan los precios; por sí mismos no reservan capacidad. Ten en cuenta que los CUD se cobran por las VMs, pero también por las reservas inactivas.
• Integración con GKE: Las reservas de Compute Engine pueden proteger la capacidad de GPU que usa Google Kubernetes Engine (GKE). En GKE Standard, configura el node pool con afinidad de reserva. En GKE Autopilot, debes seleccionar explícitamente una reserva o configurar una ComputeClass personalizada compatible.

Cómo implementar reservas de GPU para el mantenimiento del usuario

El enfoque más seguro para evitar que la configuración se desvíe es definir la VM una sola vez en una plantilla de instancias y crear la reserva a partir de esa plantilla. De forma predeterminada, las reservas se configuran como "Consumir automáticamente". Cualquier VM creada en tu proyecto que coincida exactamente con las especificaciones de la reserva la consumirá de forma automática.

1. Crea la reserva

Si estás realizando mantenimiento escalonado en un clúster (como aplicar parches de SO nodo por nodo), no necesitas reservar capacidad para toda la flota. Dimensiona tu reserva según el número exacto de instancias que planeas detener de forma simultánea. Por ejemplo, si drenas y actualizas dos nodos a la vez, configura tu --vm-count en 2 para capturar esas instancias específicas mientras se reinician.

Puedes aprovisionar la reserva usando una plantilla de instancias para garantizar la coincidencia exacta, desde la línea de comandos:

gcloud compute reservations create gpu-maintenance-reservation \
    --project=my-project-id \
    --source-instance-template=projects/my-project-id/global/instanceTemplates/my-gpu-template \
    --vm-count=1 \
    --zone=us-central1-c

Como alternativa, puedes definir la reserva directamente:

gcloud compute reservations create reservation-v100 \
    --project=joshua-playground \
    --zone=us-east1-c \
    --machine-type=n1-standard-1 \
    --accelerator=count=1,type=nvidia-tesla-v100 \
    --vm-count=1 \
    --require-specific-reservation=false

Y, por supuesto, también puedes hacerlo desde la Google Cloud Console.

2. Despliega tu VM y verifica el consumo

Como --require-specific-reservation está en false, no necesitas cambiar tus scripts de despliegue de VMs. Siempre que lances una VM con una coincidencia exacta en la misma zona, GCP la asignará automáticamente a tu capacidad reservada.

Para confirmar que la cantidad esperada de instancias está consumiendo los slots reservados, revisa las métricas de la reserva en la Google Cloud Console. Puedes ver las reservas actuales en Compute Engine > Reservations, o consultar el uso histórico en Google Cloud Monitoring, con las métricas compute.googleapis.com/reservation/used y compute.googleapis.com/reservation/reserved.

3. Elimina tu reserva

A diferencia de las VMs estándar, las reservas de capacidad deben eliminarse de forma explícita cuando ya no las necesitas. Si retiras tu workload de forma permanente y eliminas la VM, pero olvidas eliminar la reserva, seguirás pagando por la capacidad de GPU vacía al precio completo bajo demanda; y los CUD también se facturarán.

Cuando termines con la reserva, elimínala desde la línea de comandos:

gcloud compute reservations delete gpu-maintenance-reservation \
    --project=my-project-id \
    --zone=us-central1-c \
    --quiet

Los números

Las reservas en GCP no tienen costo adicional, aunque pagas por los recursos reservados tanto si están conectados a una VM en ejecución como si están inactivos. Como ya estás pagando por la VM con GPU activa, protegerla con una reserva no altera tus costos. Solo incurres en costos por inactividad durante los breves minutos en que la VM se reinicia durante el mantenimiento, lo que la convierte en un seguro muy barato contra la pérdida de tu hardware.

Para verificar exactamente cuánto pagaste por la capacidad reservada mientras tus instancias estaban detenidas, puedes usar DoiT Cloud Analytics. Filtra tus reportes por el SKU compute.googleapis.com/reservation para auditar el costo exacto de la capacidad garantizada durante tu tiempo de inactividad.

Al usar las reservas de GCP, conviertes la disponibilidad de hardware de un juego de azar en una garantía predecible. Como las reservas no cuestan nada adicional sobre tu cómputo subyacente, no proteger tus instancias críticas de GPU con una reserva es un riesgo innecesario. Aprovisiona la capacidad exacta que necesitas en tu zona de destino, despliega desde una plantilla de instancias coincidente y asegúrate de que los reinicios de rutina o los mantenimientos inevitables de Google nunca dejen tus workloads varados.