GPU Autoscaling on Kubernetes — Karpenter, KAI Scheduler, Gang Scheduling

Three layers, not one. Karpenter provisions nodes dynamically (under one minute, 40% faster than Cluster Autoscaler). KAI Scheduler handles gang scheduling, topology awareness, and hierarchical queues — it prevents the 7-of-8 partial allocation trap where seven nodes wait and burn on one missing GPU. Application-level autoscalers (NVIDIA Dynamo Planner, llm-d Workload Variant Autoscaler) scale on inference-specific signals — queue depth, KV cache utilization — not CPU/DCGM duty cycle. The classic HPA trap is that `DCGM_FI_DEV_GPU_UTIL` is a duty-cycle measurement: 100% could be 10 requests or 100. vLLM pre-allocates KV cache memory, so memory never triggers scale-down. This lesson teaches you to compose the three layers and avoid the default Karpenter `WhenEmptyOrUnderutilized` policy that terminates running GPU jobs mid-inference.

Learn 1.3 hr Python (stdlib, toy queue-depth autoscaler simulator)

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

#Learning Objectives

  • Diagram the three autoscaling layers (node provisioning, gang scheduling, application-level) and name the tool used at each layer.
  • Explain why DCGM_FI_DEV_GPU_UTIL is the wrong HPA signal for vLLM and name two replacements (queue depth, KV cache utilization).
  • Describe gang scheduling and the partial-allocation failure mode KAI Scheduler prevents (7 of 8 GPUs idle).
  • Name the Karpenter consolidation policy (WhenEmptyOrUnderutilized) that terminates running GPU jobs and state the 2026 safe alternative.
Full Access lesson

Keep going. The rest of this lesson is one step away.

Unlock all 503 lessons, video, code, quizzes and every future update. Pay in your own currency with Paystack.

The text and code of this lesson are based on AI Engineering from Scratch by Rohit Ghumare, MIT licensed.