Knative y scale-to-zero para inferencia LLM: cuándo apagar la GPU ahorra y cuándo te cuesta el SLO

Mon, 31 Aug 2026 10:00:00 +0200

Cierre de la tanda de plataforma y autoservicio, tras Backstage y Kubeflow. Aquí la pregunta es puramente económica con una trampa técnica dentro: apagar la GPU cuando nadie la usa parece dinero gratis, hasta que el primer usuario del día espera dos minutos.

TL;DR

Una GPU cuesta lo mismo sirviendo que ociosa. Una H100 en cloud dedicado ronda los 2 a 4 euros la hora se use o no, así que apagar el servicio cuando no hay tráfico parece dinero regalado. Knative es la pieza que lo hace: su autoescalador escala a cero réplicas y las vuelve a levantar cuando llega una petición, midiendo concurrencia en vez de CPU, que es lo que el autoescalador de Kubernetes no sabe hacer.

La trampa está en el arranque en frío. Knative levanta un pod en segundos, pero eso solo es el principio: un LLM tiene que cargar los pesos del disco a la HBM y compilar sus grafos, y ahí se van de decenas de segundos a minutos según el tamaño del modelo y el almacenamiento. Un trabajo de referencia mide el arranque de vLLM en unos 20 segundos incluso para un modelo de 3.000 millones de parámetros, y la carga de pesos crece de forma lineal con el tamaño. El primer usuario de cada valle de tráfico paga esa espera entera.

De ahí la regla. Apagar la GPU compensa con tráfico esporádico, muchos modelos poco usados o entornos de desarrollo, y es una trampa con SLO de latencia estricto, tráfico sostenido o modelos enormes cuyo arranque viola cualquier presupuesto interactivo. Entre el todo y la nada hay tres términos medios que casi siempre ganan: mantener una réplica caliente, compartir la GPU con model-swap, o acelerar la carga de pesos para que el arranque quepa en el ciclo del autoescalador.

La analogía: el restaurante que apaga la cocina

Un restaurante con la cocina encendida a las cuatro de la tarde, sin un solo cliente, quema gas para nada. La tentación es apagarla y encenderla cuando entre alguien. El problema es el tiempo de encendido. Si la cocina es una placa de inducción, se enciende en segundos y apagarla entre servicios es evidente. Si es un horno de leña que tarda dos horas en coger temperatura, apagarlo significa que el primer cliente de la noche cena frío o se va.

Servir un modelo pequeño es una placa de inducción. Servir un modelo de 70.000 millones de parámetros es el horno de leña: los pesos que hay que subir a la HBM son la leña que hay que quemar hasta alcanzar temperatura, y no se acelera con desearlo. La decisión de apagar la cocina, es decir, de escalar a cero, no depende de si quieres ahorrar gas, sino de cuánto tarda en encenderse tu cocina y de cuánto está dispuesto a esperar tu primer cliente. Todo este artículo es esa cuenta.

Cómo escala Knative

Knative graduó en la CNCF en octubre de 2025 y tiene tres componentes; el que nos ocupa es Serving, el de aplicaciones sin servidor con autoescalado. Su modelo de objetos tiene cuatro piezas: el Service de alto nivel, la Configuration que describe el estado deseado, la Revision inmutable que es lo que se escala en realidad, y la Route que reparte tráfico entre revisiones.

Lo que hace posible el escalado a cero son dos componentes del plano de datos. El queue-proxy es un sidecar en cada pod que mide la concurrencia y aplica el límite de peticiones simultáneas. El activator es la pieza clave: cuando el servicio está a cero réplicas, las peticiones se dirigen a él, que las aparca en una cola, avisa al autoescalador de que hace falta capacidad, y reenvía la petición aparcada cuando un pod queda listo. Es el camarero que toma nota y te dice que la cocina está calentando, en vez de cerrarte la puerta.

KPA frente a HPA

El autoescalador propio de Knative, el KPA, mide concurrencia y peticiones por segundo, no CPU ni memoria. Esa es la diferencia que importa: el autoescalador de Kubernetes, el HPA, escala por CPU y no sabe bajar a cero, su mínimo operativo es uno. Para apagar del todo hace falta el KPA.

El KPA trabaja con dos ventanas. La estable, de 60 segundos por defecto, promedia el tráfico normal. La de pánico, mucho más corta, reacciona a picos bruscos: cuando la demanda supera el doble de la capacidad de las réplicas actuales, entra en modo pánico y escala de golpe. El objetivo de concurrencia por réplica por defecto es 100, pero para inferencia LLM el valor útil suele ser de 1 a 4, porque cada petición ocupa mucho la GPU; el ejemplo oficial de KServe usa un objetivo de 1.

Dos temporizadores gobiernan el apagado. El scale-to-zero-grace-period, de 30 segundos por defecto, es lo que el sistema espera a tener lista la maquinaria de rearranque antes de retirar la última réplica. El scale-to-zero-pod-retention-period, cero por defecto, es el tiempo mínimo que el último pod sobrevive tras la decisión de apagar. Subir este segundo valor es una de las palancas para no apagar en cuanto hay un microvalle de tráfico.

Por qué el arranque en frío de un LLM no es arrancar un pod

Aquí está el núcleo del artículo, y hay un matiz que la mayoría de las discusiones se salta. Que Knative levante un pod en segundos no significa que el modelo esté listo en segundos. El arranque de un servicio de inferencia tiene varias fases, y las dos caras que dominan no son las que uno espera.

Un trabajo reciente que mide el arranque en frío de vLLM lo desglosa paso a paso. Para un modelo de 3.000 millones de parámetros, el arranque total ronda los 20 segundos, y el hallazgo contraintuitivo es que la mayor parte está limitada por CPU, no por GPU: inicialización del proceso, importación de librerías, construcción del motor. Dentro de eso hay dos costes que crecen y que son los que atacan las técnicas de aceleración.

El primero es la carga de pesos, que escala de forma lineal con el tamaño del modelo. En el mismo trabajo va de medio segundo para un modelo pequeño a casi cinco para uno de 16.000 millones. Proyectado a los tamaños reales, el peso en disco manda: un modelo de 8.000 millones ocupa unos 16 GB en FP16 y 8 en FP8; uno de 70.000 millones, 140 y 70; uno de 405.000 millones, 810 y 405. Cargar 140 GB del disco a la HBM no se hace en un parpadeo, y si el almacenamiento es lento o está en red, el minuto llega solo.

El segundo es la compilación de grafos. La transformación y captura de grafos con torch.compile cuesta de 11 a 21 segundos si no hay caché de compilación, y baja a 3 a 6 con ella. Es media batalla que no tiene nada que ver con los pesos, y que se gana conservando la caché de compilación entre arranques.

La conclusión operativa es que el enemigo no es solo la HBM: es la carga de pesos más la compilación. Para modelos pequeños los pesos son solo una fracción del arranque, y apagar la GPU es casi indoloro. Para modelos grandes los pesos dominan, y el arranque en frío se convierte en el problema. Cargar un modelo de 70.000 millones con el cargador ingenuo de la librería habitual puede irse a varios minutos, y ese es el tiempo exacto que espera tu primer usuario.

Las técnicas que acortan la espera

La buena noticia es que el arranque en frío se ataca por sus dos frentes. Por el lado de los pesos, los cargadores por streaming como el de NVIDIA transfieren los pesos a la GPU de forma concurrente en vez de secuencial: los datos publicados llevan un modelo de 8.000 millones de unos 48 segundos con el cargador estándar a unos 14 con streaming desde SSD, y a menos de 8 con almacenamiento rápido. El caso más gráfico es un modelo de 122.000 millones, 233 GB en disco, que pasa de 3 minutos y medio a unos 37 segundos. Ese número tiene una consecuencia directa: 37 segundos caben en un ciclo de sondeo del autoescalador de 30 a 60 segundos; tres minutos y medio, no. Es la diferencia entre que el escalado a cero sea viable con modelos grandes o no lo sea.

Por el lado de la compilación, la técnica es más barata todavía: conservar la caché de torch.compile entre arranques, y con ella los 11 a 21 segundos se convierten en 3 a 6. Herramientas como Tensorizer y las imágenes OCI con los pesos empaquetados atacan el mismo problema desde otro ángulo, como vimos en el artículo sobre acelerar el cold start.

Knative y KServe: los dos modos

KServe se apoya en Knative para su modo sin servidor, y esto es lo que conecta todo lo anterior con una plataforma real. KServe tiene dos modos de despliegue.

El modo Serverless usa Knative Serving y el KPA, soporta escalado a cero y mide concurrencia y peticiones por segundo. Se activa poniendo minReplicas: 0 en el InferenceService. Es el camino natural para servir muchos modelos intermitentes.

El modo Standard o raw usa el HPA de Kubernetes, no escala a cero, y mide CPU y memoria. Se elige cuando se necesita algo que Knative restringe, como montar varios volúmenes, y no hace falta apagar del todo.

Hay un tercer camino que interesa especialmente a quien ya tiene KEDA desplegado: en modo Standard, KServe recomienda KEDA para inferencia generativa, y KEDA sí puede escalar a cero por métricas de Prometheus, como la longitud de la cola o los tokens por segundo. Es una vía de escalado a cero por métricas propias, fuera de Knative, que encaja mejor con un autoescalado guiado por la señal real de saturación del modelo en vez de por concurrencia genérica.

Para quien sirve muchos modelos predictivos y ligeros, existe además ModelMesh, el patrón de alta densidad que mete muchos modelos en los mismos pods y los rota en memoria, sin apoyarse en Knative. Es el equivalente al model-swap: en vez de apagar y encender por modelo, comparte una GPU entre muchos. Está orientado a inferencia clásica de respuesta corta, no a LLM generativos.

La cuenta económica

La decisión se reduce a comparar lo que ahorras apagando con lo que arriesgas en el arranque. El ahorro es fácil de estimar. Si una GPU cuesta $ C $ euros por hora y tu servicio está ocioso $ H $ horas al día, apagarlo ahorra del orden de

$$\text{ahorro diario} \approx C \cdot H$$

Con una H100 a 3 euros la hora y 16 horas ociosas al día, son 48 euros diarios por GPU, del orden de 1.400 al mes. En una flota de varios modelos poco usados, la cifra se multiplica y deja de ser despreciable.

El coste está en el otro lado, y no se mide en euros: se mide en SLO. El escalado a cero solo sale a cuenta si el arranque en frío cabe dentro de lo que tu peor caso de latencia tolera. Con un modelo pequeño y almacenamiento rápido, decenas de segundos como mucho, y para un asistente interno que se usa a ráfagas puede ser aceptable. Con un modelo de 70.000 millones y el cargador ingenuo, minutos, y ningún SLO interactivo lo aguanta.

Entre apagar del todo y no apagar nunca hay tres términos medios, y casi siempre uno de ellos es la respuesta correcta:

Réplica caliente, con minReplicas: 1. Se elimina el arranque en frío del primer usuario a cambio de pagar una GPU-hora continua. El punto de equilibrio es directo: compensa mantenerla caliente cuando el coste de esa GPU en caliente es menor que el coste reputacional o de SLO de que el primer usuario espere. Para un servicio de cara al cliente, casi siempre.

Model-swap o sleep en una GPU compartida, como vimos en servir varios modelos en una GPU. El proceso se mantiene vivo y el modelo se descarga y recarga en segundos en vez de arrancar de cero. Es el intermedio para varios modelos que no justifican una GPU cada uno pero tampoco toleran el arranque completo.

Acelerar la carga para que el arranque en frío quepa en el ciclo del autoescalador, con streaming de pesos y caché de compilación. Es lo que hace viable el escalado a cero real con modelos grandes, y el que convierte “tres minutos y medio” en “37 segundos”.

Trampas operativas y escepticismo honesto

El pod arranca en segundos, el modelo no. No confundas el tiempo de arranque de Knative con el tiempo hasta que el modelo responde. La diferencia es todo el artículo.

El objetivo de concurrencia por defecto es 100, y para un LLM eso es un desastre. Cada petición ocupa la GPU; un objetivo de 1 a 4 es lo razonable. Dejar el 100 por defecto significa aceptar cien peticiones simultáneas en una réplica que aguanta cuatro.

El arranque en frío no es solo carga de pesos. La compilación de grafos cuesta lo suyo, y se ataca por separado, con caché. Optimizar solo el almacenamiento deja la mitad del problema sin tocar.

Cilium y Gateway API todavía no son un camino soportado. Knative soporta Gateway API en beta y prueba con Istio, Contour y Envoy Gateway; la integración con Cilium no figura como probada y tiene fricción documentada. Si tu ingress es Cilium, verifícalo antes de contar con ello.

KEDA puede ser mejor señal que el KPA. Escalar por concurrencia genérica es peor que escalar por la métrica real de saturación del modelo. Si ya tienes KEDA, el modo Standard con escalado a cero por métricas propias merece una prueba frente al Serverless por defecto.

Para una factoría de inferencia

La decisión de apagar la GPU no es ideológica, es aritmética, y depende de dos números: cuánto tarda tu modelo en arrancar y cuánto espera tu peor usuario. Tres reglas cierran el asunto.

Primera, apaga lo que es intermitente y barato de arrancar: entornos de desarrollo, modelos pequeños de uso esporádico, la larga cola de modelos que casi nadie toca. Ahí el escalado a cero es dinero directo sin coste apreciable de SLO.

Segunda, no apagues lo que es crítico y caro de arrancar: el modelo de cara al cliente con SLO estricto, y los modelos enormes cuyo arranque en frío se mide en minutos. Ahí una réplica caliente cuesta menos que un usuario esperando.

Tercera, antes de decidir, mide tu arranque real y arréglalo. Muchos servicios se descartan del escalado a cero por un arranque de tres minutos que, con streaming de pesos y caché de compilación, baja a treinta segundos y cambia la respuesta. La palanca más rentable no es elegir bien entre apagar o no: es hacer que apagar sea barato.

Con esto cerramos la tanda de plataforma y autoservicio. El portal enseña lo que hay, la caja de herramientas de ML da lo que falta sin duplicar lo que tienes, y el escalado a cero decide cuánto de todo eso está encendido cuando nadie mira. Las tres responden a la misma pregunta desde ángulos distintos: cómo poner una plataforma cara a disposición de sus usuarios sin arruinarse manteniéndola encendida.

Ver también

Autoscaling de inferencia LLM con HPA y KEDA — la alternativa por métricas propias al KPA de Knative.
Servir varios modelos en una GPU: co-residencia, model-swap y sleep — el intermedio entre apagar y mantener caliente.
Acelerar el cold start de modelos — cómo hacer que el arranque quepa en el ciclo del autoescalador.
TCO completo de un cluster GPU on-premise — la cuenta de la GPU-hora que decide si apagar compensa.

Fuentes

CNCF, Cloud Native Computing Foundation announces Knative’s graduation — https://www.cncf.io/announcements/2025/10/08/cloud-native-computing-foundation-announces-knatives-graduation/
Knative Docs, Serving architecture — https://knative.dev/docs/serving/architecture/
Knative Docs, Request flow — https://knative.dev/docs/serving/request-flow/
Knative Docs, Configuring KPA-specific autoscaling — https://knative.dev/docs/serving/autoscaling/kpa-specific/
Knative Docs, Configuring concurrency — https://knative.dev/docs/serving/autoscaling/concurrency/
Knative Docs, Configuring scale-to-zero — https://knative.dev/docs/serving/autoscaling/scale-to-zero/
Knative Blog, Managing Gateway API ingress with the Knative Operator — https://knative.dev/blog/articles/gateway-api-ingress-with-knative-operator/
CNCF, KServe becomes a CNCF incubating project — https://www.cncf.io/blog/2025/11/11/kserve-becomes-a-cncf-incubating-project/
KServe Docs, Autoscaling with Kubernetes HPA (Serverless vs Standard) — https://kserve.github.io/website/docs/model-serving/predictive-inference/autoscaling/hpa-autoscaler
KServe Docs, Autoscaler for generative inference (KEDA) — https://kserve.github.io/website/docs/model-serving/generative-inference/autoscaling
KServe GitHub, docs/samples/autoscaling (InferenceService minReplicas 0) — https://github.com/kserve/kserve/blob/master/docs/samples/autoscaling/README.md
Wang et al. (MLSys 2026), Breaking the ice: analyzing cold start latency in vLLM — https://arxiv.org/abs/2606.07362
NVIDIA Developer Blog, Reducing cold start latency for LLM inference with NVIDIA Run:ai Model Streamer — https://developer.nvidia.com/blog/reducing-cold-start-latency-for-llm-inference-with-nvidia-runai-model-streamer
Microsoft Azure SDK Blog, Eliminate LLM cold starts: load models up to 6x faster — https://devblogs.microsoft.com/azure-sdk/eliminate-llm-cold-starts-load-models-up-to-6x-faster-with-azure-blob-storage-and-runai-model-streamer/
Hugging Face Blog, Llama 3.1 (VRAM and precision tables) — https://huggingface.co/blog/llama31
CloudZero, H100 GPU cost 2026 — https://www.cloudzero.com/blog/h100-gpu-cost/

Knative on lo0 — Blog Técnico