Imagina un estudio de video de veinte personas en Ciudad de Guatemala con dos VMs en Google Cloud con GPUs NVIDIA T4 conectadas. Una hace la transcodificación de cada noche. La otra es una estación de trabajo virtual con Windows a la que un editor entra desde su casa tres días por semana. Las dos las armó en 2021 un contratista que hace mucho dejó de trabajar con ellos. Ya nadie abre la consola de Cloud, porque nada está fallando.
Ese es justo el perfil al que más le duele un aviso de fin de soporte de GPU. Las máquinas siguen trabajando hasta el día en que dejan de hacerlo, y ese día ya está en el calendario.
Qué cambió y cuál es la fecha que importa
En las notas de versión de Google Cloud del 22 de septiembre de 2026, Compute Engine marcó como obsoletas las GPUs NVIDIA T4 (nvidia-tesla-t4 y nvidia-tesla-t4-vws) y las NVIDIA P4 (nvidia-tesla-p4 y nvidia-tesla-p4-vws), con fecha de fin de soporte.
La fecha de fin de soporte de las dos es el 1 de agosto de 2027. La propia página de fin de soporte de Google lo dice sin rodeos: hasta esa fecha, los recursos con GPUs T4 siguen funcionando con normalidad, y a partir del 1 de agosto de 2027 ya no vas a poder crear, iniciar ni acceder a ningún recurso de Google Cloud que use esas GPUs. La P4 lleva la misma fecha y la misma redacción.
Esto no es una vista previa ni un rumor. Está en las páginas publicadas de obsolescencia, y tiene un antecedente que ya ocurrió: la NVIDIA P100 llegó a fin de soporte el 15 de septiembre de 2026, diez días antes de que escribiéramos esto. Si todavía estabas en una P100, esa decisión ya la tomaron por ti.
La palabra que hay que tomar en serio es acceder. No se trata solo de prohibir máquinas nuevas. Una VM que existe pero que no se puede iniciar después de esa fecha es una máquina apagada con un disco conectado, y el disco se sigue facturando.
A quién le pega esto en una empresa pequeña o mediana
La T4 fue durante años el caballito de batalla del cómputo con GPU barato. Es tan accesible que los equipos chicos la pusieron en cosas que una empresa grande jamás aceleraría. En proyectos de clientes la encontramos en cinco lugares.
- Inferencia sobre una VM N1. Una sola T4 conectada a una máquina de propósito general, corriendo un modelo de transcripción, un pipeline de OCR, un clasificador de imágenes o un servicio de recomendaciones.
- Estaciones de trabajo virtuales. Las variantes
-vwsexisten para CAD, edición de video y 3D entregados a un escritorio remoto. Compute Engine agrega sola la licencia de NVIDIA RTX Virtual Workstation cuando creas ese tipo de instancia, y por eso ese costo queda escondido dentro de la línea de la VM en la factura. - Node pools de GKE. Un pool fijado a aceleradores T4 dentro de un clúster que alguien configuró una sola vez.
- Pipelines de Dataflow y trabajos de Managed Service for Apache Spark cuya configuración de workers nombra la T4 de forma explícita.
- Configuraciones de Cloud Workstations y cargas de Gemini Enterprise Agent Platform que apuntan a la T4 como su acelerador.
El hilo común es que en todos esos lugares el modelo de GPU está escrito en un archivo de configuración, una plantilla o un recurso de Terraform, no lo elige una persona cada mañana. Nadie se va a dar cuenta de la obsolescencia mirando una pantalla. Alguien tiene que ir a leer la configuración.
Qué revisamos primero en un proyecto de cliente
Antes de proponer cualquier migración queremos la lista completa. La primera pasada es un comando por proyecto, del conjunto documentado de comandos comunes de Compute Engine:
gcloud compute instances list \
--filter="guestAccelerators.acceleratorCount>0" \
--format="table(name,zone,guestAccelerators.acceleratorType,guestAccelerators.acceleratorCount,disks.type)"Córrelo en todos los proyectos de la organización, no solo en el que se llama producción. Las VMs con GPU tienen la costumbre de vivir en un proyecto bautizado como una prueba de concepto de hace tres años.
Después revisamos los lugares a los que ese comando no llega:
- Plantillas de instancia y grupos de instancias administrados. Las VMs que están corriendo pueden estar bien mientras la plantilla que las recrea sigue nombrando una T4. Esa es la falla que te despierta a las 3 de la mañana después de un evento de autoescalado en agosto de 2027.
- Node pools de GKE. Lista los pools y lee el acelerador de cada uno, incluidos los que están escalados a cero.
- Plantillas de Dataflow y definiciones de trabajos de Spark que fijan un acelerador de worker.
- Configuraciones de Cloud Workstations.
- Código de infraestructura. Terraform, Deployment Manager, scripts de shell en un repo. Busca
tesla-t4ytesla-p4en todos los repositorios, incluidos aquellos donde nadie ha hecho un commit en un año. - Descuentos por uso comprometido. Los compromisos vigentes de uno y de tres años sobre T4 siguen válidos hasta su fecha de vencimiento, pero ya no se pueden comprar ni renovar compromisos de tres años sobre T4. Cualquier compromiso que venza cerca de agosto de 2027 necesita una decisión ahora, no una renovación automática hacia un callejón sin salida.
- Si la carga todavía necesita GPU. Varios de los pipelines que heredamos se aceleraron porque una T4 salía barata, no porque las matemáticas lo pidieran. Dos de cada tantas migraciones terminan siendo un borrado.
La mudanza, en el orden en que la hacemos
Los destinos que Google recomienda son la serie de máquinas G2 con GPUs NVIDIA L4 y la serie G4 con NVIDIA RTX PRO 6000. El detalle estructural importante, el que suele sorprender: no puedes cambiar una instancia existente en el lugar de un tipo de máquina N1 de propósito general a un tipo optimizado para aceleradores. No hay una edición que convierta una VM con T4 en una VM con L4. Se crea una instancia nueva y se mueven los datos.
- Elige el destino y la zona. G2 y G4 no están en todas las zonas donde había T4. Revisa la página de ubicaciones de GPU para tu región antes de prometerle a alguien que la máquina se queda donde está. A veces la respuesta honesta es que la carga cambia de región, y eso trae consecuencias de latencia y de residencia de datos que conviene poner sobre la mesa temprano.
- Rescata los datos de Local SSD. Si la instancia vieja usa discos Local SSD con algo que quieras conservar, copia su contenido a un volumen de Persistent Disk primero. Los datos de Local SSD no sobreviven la mudanza, y tampoco sobreviven a un apagado.
- Crea la instancia nueva G2 o G4. Instala los controladores desde cero. Para una estación de trabajo virtual esto significa los controladores de NVIDIA RTX Virtual Workstation, no los estándar.
- Mueve los volúmenes de Persistent Disk. Desconéctalos de la instancia vieja y conéctalos a la nueva.
- Vuelve a probar la carga real antes de borrar nada. La T4 es Turing y la L4 es Ada Lovelace. Una imagen de contenedor con una versión de CUDA o de controlador fijada, un kernel compilado o un artefacto de modelo construido para una capacidad de cómputo específica pueden negarse a cargar. Ahí está el trabajo de verdad, y por eso no agendamos la migración para julio de 2027.
- Actualiza todo lo que crea máquinas. Plantillas de instancia, node pools de GKE, configuración de workers de Dataflow, configuraciones de workstations, Terraform. Una VM migrada con una plantilla sin migrar no está migrada.
- Borra las instancias viejas solo después de que un ciclo completo del negocio haya corrido limpio en las nuevas. Un cierre de mes es buena marca para la mayoría de nuestros clientes.
Notas de costo y de riesgo
No vamos a poner precios de GPU aquí, porque se mueven y una cifra vieja en un artículo es peor que ninguna cifra. Cotiza tu configuración específica en la calculadora de precios de Google Cloud el día que planifiques, y vuelve a revisarla antes de comprometerte.
Lo que sí te podemos decir es que cambia la forma de la factura. La T4 era un acelerador que conectabas a una máquina N1 que tú dimensionabas, así que CPU y GPU iban por separado. G2 y G4 son series optimizadas para aceleradores, con proporciones fijas de GPU a vCPU y memoria. Si tu caja con T4 era un CPU pequeño con una GPU, la máquina soportada más cercana puede darte más CPU del que pediste. Eso no es automáticamente más caro, porque la guía de Google dice que los clientes que pasan de T4 a L4 pueden ver de dos a cuatro veces mejor rendimiento, y un trabajo que termina en un tercio del tiempo en una máquina facturada por segundo puede salir más barato aun con una tarifa por hora más alta. Mide tu propia carga. No aceptes ni la versión optimista ni la pesimista sin una prueba.
Tres riesgos que señalamos en todos estos proyectos:
- La máquina olvidada. Agosto de 2027 se siente lejos, y por eso mismo la estación de trabajo del editor va a seguir en una T4 en julio de 2027. Pon el inventario en un ticket con fecha, no en la cabeza de alguien.
- La trampa del compromiso. Renovar un descuento sobre hardware con fecha publicada de fin de soporte amarra dinero a una máquina que vas a tener que dejar.
- La plantilla silenciosa. El autoescalado y la reparación de nodos recrean máquinas desde plantillas. Una plantilla que nombra un acelerador retirado convierte un martes tranquilo en una caída.
Cómo ayuda Guanacos Tech
Esto lo hacemos como un trabajo acotado: inventariar cada GPU en cada proyecto, ligar cada una a una carga y a un responsable, probar el reemplazo con L4 o RTX PRO 6000 contra el trabajo real, y entregarte un plan de migración con fechas que caen bastante antes del límite y no encima de él. Si la respuesta honesta para una carga es que ya no necesita GPU, también lo decimos, y el ahorro es tuyo.
Si quieres un segundo par de ojos sobre un proyecto de Google Cloud que heredaste, así arranca nuestro trabajo de consultoría de Google Cloud. Agenda una llamada de 30 minutos y trae los IDs de tus proyectos.