Success Stories

El modelo de tienda se come la costosa hora TPU

Al realizar inferencia de inteligencia artificial en GKE con TPUs, la carga del modelo es el momento más costoso.

Por Alec Chizhik 11 julio 2026 6 min de lectura

El modelo de tienda se come la costosa hora TPU

En una VM con TPU de cuatro chips, cada minuto cuesta dinero. Cuando Google tuvo un modelo de 449 GB listo para responder en un benchmark documentado tras más de diez minutos, el nodo pagó por capacidad de cómputo que aún no estaba procesando. Precisamente este momento inicial decide la factura real en la nube al realizar inferencias de IA en Google Kubernetes Engine.

Por qué la costosa TPU espera antes de procesar

Un acelerador cuesta por hora, independientemente de si genera tokens o carga un modelo en la memoria. En modelos pequeños este aspecto pasa desapercibido, pero en un modelo con cientos de gigabytes de pesos, la carga inicial se convierte en la fase más larga en el ciclo de vida de un pod.

Esto afecta directamente al escalado automático. Cuando un clúster escala hacia arriba en momentos de alta demanda, cada pod nuevo debe cargar primero su modelo antes de poder responder a la primera solicitud. Si este proceso dura varios minutos, surge un dilema: o la escalabilidad reacciona demasiado tarde y los usuarios esperan, o el equipo mantiene capacidad de reserva costosa permanentemente activa. Ambas opciones queman horas de TPU.

La factura es incómoda. Un nodo que carga durante diez minutos y luego trabaja durante una hora pierde aproximadamente un séptimo de su tiempo pagado en un proceso que no produce ni un solo token.

El sobrecoste oculto en memoria al iniciar

La ruta de carga clásica en una TPU pasa por la memoria del host. El modelo se lee primero completamente en la memoria de la CPU, se descompone allí para los chips y solo entonces se transfiere. En modelos de PyTorch sin lógica de carga especializada, esto implica un pico de memoria de aproximadamente el doble del tamaño del modelo, ya que el checkpoint y la copia procesada se superponen temporalmente.

Esta doble ocupación es el auténtico punto de coste. Un grupo de nodos debe dimensionarse para soportar el pico, no para la operación normal. Por lo tanto, se reserva capacidad para un momento que solo ocurre al inicio.

// Pico de memoria al cargar

881 GB → 436 GB

Necesidad de RAM del host para un modelo de 449 GB: ruta de carga clásica frente a transmisión directa desde la memoria de objetos.

Nodos TPU sin SSD local obligan a tomar una decisión

Al contrario que muchas instancias de GPU, los nodos TPU no disponen de un disco local rápido desde el que cargar un modelo. Los pesos se obtienen desde el almacenamiento de objetos o de volúmenes adjuntos. Esto agrava el conflicto de objetivos entre tiempo de carga, costes de almacenamiento y el riesgo de que un nodo, al arrancar, desborde la memoria de trabajo.

La solución que Google documenta para este caso es el Run:ai Model Streamer de código abierto. Este evita el rodeo local y transfiere los pesos en paralelo directamente desde el almacenamiento de objetos a la memoria del chip. Para el caso general, la documentación menciona hasta seis veces más velocidad de carga en comparación con los métodos convencionales. En el caso de TPU medido anteriormente, el factor fue de algo más de dos. El soporte para el camino TPU está disponible en vLLM a partir de la versión 0.18.0.

Importante para contextualizar: el salto medido hasta un factor dos se refiere al caso descrito de grandes modelos de PyTorch. Para modelos con lógica de carga ya optimizada, el beneficio es menor. Quien planee usar el streamer debería verificar el tipo de modelo propio, sin adoptar ciegamente el dato de referencia.

Qué herramientas reales tienen los equipos de plataforma

La primera decisión es el propio camino de carga. El streaming desde el almacenamiento de objetos reduce el pico de memoria y permite nodos más pequeños y económicos. Esto tiene un doble efecto: mayor rapidez en la preparación de pods para la escalabilidad y menos memoria reservada por nodo.

La segunda herramienta es la caché. Una caché de compilación persistente en el almacenamiento de objetos acorta notablemente los arranques posteriores, ya que no es necesario repetir la preparación costosa en cada pod. Para acelerar por zonas, se puede colocar una caché de lectura antes del almacenamiento de objetos.

La tercera herramienta es la planificación. El auténtico escalado a cero sigue siendo caro en TPUs, pues cada arranque en frío implica pagar el proceso completo de carga. Para cargas fluctuantes, la elasticidad selectiva con pods de reserva precalentados suele ser más económica que el escalado puro hacia arriba y abajo. Quien tome en serio los costes operativos de la infraestructura de IA, por ejemplo en el entorno del Google Cloud Summit DACH 2026, no puede ignorar este cálculo.

Preguntas frecuentes

¿Qué es el Run:ai Model Streamer?

El Run:ai Model Streamer es un componente de código abierto que carga los pesos de los modelos en paralelo desde un almacenamiento de objetos como Cloud Storage directamente a la memoria de un acelerador. Evita el disco local y el rodeo por la memoria de trabajo del host, lo que permite arrancar modelos grandes con mayor rapidez y menor pico de memoria.

¿Por qué el arranque en frío en inferencia con TPU es un problema de costes?

Un acelerador cuesta por hora, incluso mientras carga un modelo. Si el proceso de carga de modelos grandes dura varios minutos, esto retrasa la escalabilidad y obliga a los equipos a optar entre una reacción lenta o mantener una capacidad de reserva costosa. Ambas opciones incrementan el coste por solicitud respondida.

¿A partir de qué versión de vLLM funciona el streamer en TPU?

Para el camino TPU se requiere vLLM en versión 0.18.0 o superior. Para GPUs, el streamer ya soporta la conexión a Cloud Storage desde la versión 0.11.1. Se activa mediante un parámetro adicional en el comando de inicio.

¿El beneficio de un factor dos aplica a cualquier modelo?

No. La reducción a la mitad del tiempo de carga y del pico de memoria se refiere a grandes modelos de PyTorch que siguen el camino clásico de carga a través de la memoria del host. Los modelos con lógica de carga ya incremental obtienen menos beneficio. Antes de cambiar, conviene probar con el propio modelo.

¿Cómo se relaciona el tiempo de carga del modelo con el escalado automático?

Cada pod recién arrancado debe cargar su modelo antes de responder a peticiones. Si esta fase es larga, la escalabilidad automática reacciona con lentitud ante picos de carga. Tiempos de carga más breves permiten que los pods estén listos con mayor rapidez, reducen la necesidad de reserva mantenida y mejoran la utilización de los aceleradores pagados.