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.
En una máquina virtual TPU con cuatro chips, cada minuto cuesta dinero. Cuando Google logró que un modelo de 449 gigabytes estuviera listo para responder en un benchmark documentado solo después de más de diez minutos, el nodo estaba pagando por una capacidad de cómputo que aún no estaba computando. Precisamente este momento de arranque es el que determina la factura real de la nube en la inferencia de IA en Google Kubernetes Engine.
Lo más importante en resumen
- El proceso de carga es el principal factor de coste. Para un modelo de 480 mil millones de parámetros, el tiempo de carga en una TPU pasó de más de 630 a menos de 280 segundos en cuanto los pesos se transmitieron en streaming directamente desde el almacenamiento de objetos en lugar de usar la ruta local indirecta.
- La memoria del host se reduce a la mitad. La ruta de carga clásica ocupó un pico de 881 gigabytes de RAM del host, mientras que el streaming se conformó con 436. La diferencia es presupuesto reservado que un grupo de nodos tendría que mantener disponible de forma permanente.
- La causa reside en la arquitectura. Los nodos TPU no tienen SSD locales. La ruta de carga clásica ocupa brevemente el doble del tamaño del modelo en la memoria RAM. Quien ignore esto, lo pagará mediante el sobreaprovisionamiento y un escalado lento.
Relacionado:FinOps de Kubernetes: las palancas contra el 70 por ciento del desperdicio de clústeres / 4 por ciento en el centro de datos, 54 en la central eléctrica
Por qué la costosa TPU espera antes de computar
Un acelerador cuesta por hora, independientemente de si genera tokens o si carga un modelo en la memoria. En modelos pequeños, esto apenas se nota. Pero en un modelo con cientos de gigabytes de pesos, el proceso de carga se convierte en la fase más larga del ciclo de vida de un pod.
Esto afecta directamente al autoescalado. Si un clúster escala ante picos de carga, cada nuevo pod debe cargar primero su modelo antes de responder a la primera solicitud. Si esto tarda varios minutos, surge un dilema. O bien el escalado reacciona demasiado tarde y los usuarios esperan, o bien el equipo mantiene permanentemente activa una costosa capacidad de reserva. Ambas opciones queman horas de TPU.
La cuenta es incómoda. Un nodo que tarda diez minutos en cargar y luego trabaja durante una hora pierde alrededor de una séptima parte de su tiempo de ejecución pagado en un proceso que no produce ni un solo token.
El recargo oculto de memoria en el arranque
La ruta de carga clásica en una TPU pasa por la memoria RAM del host. El modelo se lee primero por completo en la memoria de la CPU, allí se descompone para los chips y solo entonces se transfiere. Para los modelos de PyTorch sin una lógica de carga especializada, esto implica un pico de memoria de aproximadamente el doble del tamaño del modelo, ya que el punto de control y la copia preparada coexisten brevemente.
Esta doble ocupación es el verdadero coste. Un grupo de nodos debe dimensionarse para que sobreviva al pico, no para la operación normal. Por lo tanto, se reserva capacidad para un momento que solo ocurre durante el arranque.
Los nodos TPU sin SSD local obligan a tomar decisiones
A diferencia de muchas instancias GPU, los nodos TPU carecen de un disco local rápido desde el cual cargar un modelo. Los pesos provienen del almacenamiento de objetos o de volúmenes adjuntos. Esto agudiza el conflicto entre el tiempo de carga, los costes de almacenamiento y el riesgo de que un nodo se quede sin memoria al arrancar.
La solución que Google documenta para este caso es el Run:ai Model Streamer de código abierto. Eludiría el paso intermedio local e inyectaría los pesos en paralelo desde el almacenamiento de objetos directamente a la memoria del chip. Para el caso general, la documentación indica tiempos de carga hasta seis veces más rápidos frente a métodos convencionales. En el caso TPU medido anteriormente fue de poco más de un factor dos. La ruta TPU está soportada por vLLM desde la versión 0.18.0.
Importante para contextualizar: el salto medido al factor dos se aplica al caso descrito de grandes modelos PyTorch. Para modelos con una lógica de carga ya optimizada, la ganancia es menor. Quien planee usar el streamer debería verificar su propio tipo de modelo, no asumir ciegamente el número de benchmark.
Qué palancas tienen realmente los equipos de plataforma
La primera decisión es la propia ruta de carga. Transmitir desde el almacenamiento de objetos reduce el pico de memoria y hace posible pools de nodos más pequeños y económicos. Esto tiene un doble efecto: mayor preparación de pods para el escalado y menos memoria reservada por nodo.
La segunda palanca es la caché. Una caché de compilación persistente en el almacenamiento de objetos acorta notablemente los siguientes arranques, porque la preparación costosa no se repite en cada pod. Para aceleración zonal se puede colocar una caché de lectura delante del almacenamiento de objetos.
La tercera palanca es la planificación. El verdadero scale-to-zero sigue siendo caro en TPUs, porque cada arranque en frío paga el proceso completo de carga. Para cargas variables, la elasticidad selectiva con pods de reserva precalentados suele ser más barata que escalar puramente hacia arriba y abajo. Quien tome en serio los costes operativos de infraestructura de IA, por ejemplo en el entorno del Google Cloud Summit DACH 2026, no puede evitar esta ecuación.
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 del modelo en paralelo desde un almacenamiento de objetos como Cloud Storage directamente a la memoria de un acelerador. Eludiría el disco local y el paso por la memoria del host, permitiendo que los modelos grandes estén listos más rápido y con un pico de memoria menor.
¿Por qué es un problema de coste el cold-start en inferencia TPU?
Un acelerador cuesta por hora, incluso mientras carga un modelo. Si el proceso de carga de modelos grandes tarda varios minutos, retrasa el escalado y obliga a los equipos a reaccionar lentamente o a mantener capacidad de reserva cara. Ambas opciones aumentan el coste por solicitud respondida realmente.
¿A partir de qué versión de vLLM funciona el streamer en TPU?
Para la ruta TPU se necesita vLLM en versión 0.18.0 o superior. Para GPUs, el streamer soporta la conexión a Cloud Storage ya desde la versión 0.11.1. Se activa mediante una bandera adicional en el comando de inicio.
¿Se aplica la ganancia de factor dos a cualquier modelo?
No. La reducción medida a la mitad del tiempo de carga y del pico de memoria se refiere a grandes modelos PyTorch que siguen la ruta clásica de carga a través de la memoria del host. Los modelos con lógica de carga incremental ya existente se benefician menos. Antes de cambiar, merece la pena probar con tu propio modelo.
¿Cómo se relaciona el tiempo de carga del modelo con el autoscaling?
Cada pod reiniciado debe cargar su modelo antes de responder solicitudes. Si esta fase es larga, la escalación automática responde con lentitud ante picos de carga. Tiempos de carga más cortos preparan los pods más rápido, reducen la necesidad de reservas mantenidas y mejoran la utilización de los aceleradores pagados.
Consejos de lectura de la redacción
- Límites PUE más altos y plazos más largos: cómo la enésima modificación del EnEfG relaja las obligaciones de los centros de datos
- La conexión a IA alcanza la madurez empresarial: el Protocolo de Contexto de Modelo bajo la Linux Foundation
- Casi al nivel líder, más barato y entrenado en tres continentes
Más desde la red MBF Media
Más de la red MBF Media
MyBusinessFutureIA en la empresa mediana: del piloto a la escalabilidadDigital ChiefsTres presupuestos de IA, sin factura comúnSecurityToday¿Qué es ISO 27001? Definición, certificado y diferenciaciónFuente de la imagen: generada por IA (julio de 2026)
