Phase 17: Infrastructure & Production

GPU Autoscaling en Kubernetes Karpenter, programador KAI, programación de pandillas

Type: Learn

Languages: Python (stdlib, toy queue-depth autoscaler simulator)

Prerequisites: Phase 17 · 02 (Inference Platform Economics), Phase 17 · 04 (Serving Engine Internals)

Time: ~75 minutes

Objetivos de aprendizaje

• Diagrafía de las tres capas de autoescalado (provisión de nodos, programación de grupos, nivel de aplicación) y nombra la herramienta utilizada en cada capa.
• ¿ Por qué ?DCGM_FI_DEV_GPU_UTILes la señal HPA incorrecta para vLLM y nombrar dos reemplazos (profundidad de cola, utilización de caché KV).
• Describa la programación de banda y el modo de falla de asignación parcial que KAI Scheduler impide (7 de las 8 GPUs inactivas).
• Nombre de la política de consolidación de Karpenter (WhenEmptyOrUnderutilized) que cese la ejecución de trabajos de GPU y establece la alternativa segura para 2026.

El problema

Tu equipo envía un servicio de LLM en Kubernetes.DCGM_FI_DEV_GPU_UTILEl HPA nunca aumenta ya piensa que estás lleno. añade una réplica manualmente; TTFT cae. HPA todavía no escala. La señal te está mintiendo.

Separadamente, se utiliza Cluster Autoscaler para nodos. Una solicitud de 1M-token llega a las 2 a.m.; el cluster pasa 3 minutos proporcionando un nodo, y los tiempos de solicitud fuera.

Separadamente, se implementa un modelo 70B que requiere 8 GPU en 2 nodos. El grupo tiene 7 GPUs libres y 1 distribuido en 3 nodos. Cluster Autoscaler proporciona un nodo para la GPU 1 faltante. Siete nodos esperan 4 minutos quemando dinero mientras Kubernetes consigue la última GPU.

Tres capas, tres modos de falla diferentes. La autoescalación consciente de la GPU en 2026 no es "inclivar HPA". Es componer el provisioning de nodos, la programación de banda y la autoescalación de señales de aplicación.

El concepto

Capas 1 Provisión de nodos (Carpenter)

Karpenter observa los módulos pendientes y los nodos de provisión en ~ 45-60 segundos (Cluster Autoscaler normalmente toma 90-120 segundos para los nodos de GPU).NodePoolrestricción si su cápsula necesita 8 H100 y el grupo no tiene un nodo correspondiente, Karpenter proporciona uno directamente en lugar de escalar un grupo existente.

The consolidation trap: El defecto de Karpenter consolidationPolicy: WhenEmptyOrUnderutilizedEs peligroso para los grupos de GPU. Terminará un nodo de GPU en ejecución para migrar las capsules a una instancia de tamaño correcto más barata. Para las cargas de trabajo de inferencia que significa desalojar las solicitudes en ejecución y recargar un modelo 70B en el nuevo nodo. La pérdida es minutos de capacidad más fallos de solicitud.

Configuración segura para las redes de GPU:

yamlCopydisruption:
  consolidationPolicy: WhenEmpty
  consolidateAfter: 1h

Permite a Karpenter consolidar nodos verdaderamente vacíos después de una hora pero nunca desalojar un trabajo en marcha.

Capas 2 Programación de pandillas (KAI Scheduler)

KAI Scheduler (proyecto "Karp" entonces renombrado) maneja lo que el kube-scheduler predeterminado no hace:

Gang schedulingUna capsula de inferencia distribuida que requiere 8 GPU o todos los 8 comienzan juntos o ninguno lo hace. sin esto, obtienes la trampa de asignación parcial: 7 de 8 capsules comienzan, esperan indefinidamente, queman dinero.

Topology awareness saber qué GPU comparten NVLink, que se sientan en el mismo estante, que tienen InfiniBand entre ellos. Colocar las pods en consecuencia. Una carga de trabajo tensor-paralelo DeepSeek-V3 67B debe permanecer en un dominio NVLink; KAI Scheduler respeta eso.

Hierarchical queues varios equipos compiten por la misma GPU con prioridad y cuota.

KAI se implementa junto con kube-scheduler como un cronómetro secundario; se anota las cargas de trabajo para usarlo.

Capas 3 señales de nivel de aplicación

The HPA trap¿ Qué es esto ?DCGM_FI_DEV_GPU_UTILes una métrica de ciclo de trabajo mide si la GPU estaba haciendo el trabajo en cada intervalo de muestreo. El 100% de utilización podría significar 10 solicitudes simultáneas o 100; la GPU estaba ocupada de cualquier manera.

Peor aún, los motores vLLM y similares asignan previamente la memoria caché KV (hasta --gpu-memory-utilizationEl uso de memoria se mantiene cerca del 90% incluso en una sola solicitud.

2026 replacement signals¿Qué es esto ?

• Profundidad de la cola (número de solicitudes que esperan preempleo).
• Utilización de la caché KV (cuál es la fracción de bloques asignados a las secuencias activas).
• Por réplica P99 TTFT (su señal de SLA).
• Producción de producto (solicitudes de satisfacción de todos los SLOs por segundo).

NVIDIA Dynamo Planner y llm-d Workload Variant Autoscaler consumen estas señales y réplicas de escala.

¿Cuándo utilizar qué

El preempleo/decodificación desglosado lo complica todo

Si ejecuta una preemplaza/decodificación desagregada (fase 17 · 17), tiene dos clases de capsules con diferentes desencadenantes de escala: escala de capsules de preemplaza en profundidad de cola, escala de capsules de decodificación en presión de caché KV. llm-d expone estos como separados ServicesNo trate de poner un solo HPA frente a ambos.

El inicio frío también importa aquí

La mitigación de arranque en frío (fase 17 · 10) es cuando el tiempo de provisión de nodos se vuelve visible para el usuario.min_workers=1) para las rutas críticas de SLO, o utilizar puntos de control de estilo Modal en la capa de aplicación.

Números que debes recordar

• Provisión de nodos de carpenter: ~ 45-60s vs Cluster Autoscaler ~ 90-120s (nodos GPU).
• El programa KAI evita la trampa de 7 de 8 residuos de asignación parcial.
• DCGM_FI_DEV_GPU_UTILcomo señal HPA: rotada; utilizar profundidad de cola o utilización de KV.
• Carpenter WhenEmptyOrUnderutilized: termina ejecutando trabajos de GPU.WhenEmpty + consolidateAfter: 1hpara inferir.

Usalo

code/main.pySimula una autoescalada de tres capas en una carga de trabajo de GPU quebrada. Compara HPA ingenuo (ciclo de trabajo), HPA de profundidad de cola y escalada programada por la banda KAI. Reporta solicitudes no satisfechas, minutos de GPU inactivos y una puntuación compuesta.

Envío

Esta lección produceoutputs/skill-gpu-autoscaler-plan.md. Dada la topología del grupo, la forma de la carga de trabajo y el SLO, diseña un plan de autoescalado de tres capas.

Los ejercicios

1. - ¿ Qué ?code/main.py¿Cuántas solicitudes de HPA en el ciclo de trabajo naívo caen que capturan HPA en la cola? ¿De dónde viene la diferencia?
2. Diseñar un NodePool de Karpenter para un grupo que sirve Llama 3.3 70B FP8 en H100 SXM5. Especificar capacity-type¿ Qué ?disruption.consolidationPolicy¿ Qué ?consolidateAfter, y una mancha que mantiene las cargas de trabajo no GPU fuera de estos nodos.
3. Su equipo informa que las implementaciones están atascadas en espera porque "GPUs disponibles pero la cápsula no programará". Diagnóstico ¿es este Karpenter, kube-scheduler, o KAI Scheduler? ¿Qué métricas confirman?
4. Elige una señal para las cápsulas de preempleo desglosadas a escala automática y otra señal para las cápsulas de decodificación.
5. Calcule el coste de la WhenEmptyOrUnderutilizedtrampa de consolidación en un servicio de producción 24x7 que promedia 60 eventos de caída de solicitudes por día en P99 TTFT > 10s.

Términos clave

Leer más

• KAI Scheduler GitHub documentos de diseño y ejemplos de configuración.
• Karpenter Disruption Controls semántica de la política de consolidación y las deficiencias de seguridad de la GPU.
• NVIDIA — Disaggregated LLM Inference on Kubernetes Dinamo Planner escala señales.
• Ray docs — KAI Scheduler for RayClusters Patrón de integración de rayos.
• AWS EKS Compute and Autoscaling Best Practices Guía específica de Kubernetes gestionada.
• llm-d GitHub Diseño de la variante de autoescalador de carga de trabajo.

This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.

Browse the complete course catalog or open this lesson on GitHub.