LLM Serving on Kubernetes in 2... Note

LLM Serving on Kubernetes in 2026: What's Solved and What's Still Open

The landscape of running large language models on Kubernetes has significantly evolved, with many previously open problems now having well-funded solutions and established players. Areas like KV-cache-aware routing, prefill/decode disaggregation, fractional GPU sharing, and GPU scheduling primitives are considered crowded. These segments are addressed by a variety of projects and commercial offerings, making new ventures in these spaces competitive rather than pioneering.However, three distinct areas remain genuinely underserved, presenting opportunities for new development. The first is establishing model-weight distribution as a first-class Kubernetes primitive, analogous to how container images are handled. Current ad-hoc download methods for large model weights are a major cause of long cold starts, hindering efficient scale-to-zero deployments. A proposed solution involves CRDs for model artifacts and caching, with node-level machinery for content validation and peer-to-peer prewarming.A second underserved area is SLO-driven inference autoscaling that accounts for request heterogeneity. While SLO-aware autoscaling exists, a more nuanced approach is needed to differentiate requests based on their urgency and latency tolerance. This could involve per-request-class latency budgeting and admission control mechanisms.The third gap lies in managing the lifecycle of multiple tenancy-specific LoRA adapters. While loading adapters at runtime is supported, crucial aspects like lifecycle management, cache eviction, and VRAM budgeting are still largely handled manually. A CRD-based solution for managing LoRA adapters, their placement, and routing is needed.Idea one, focusing on model-weight distribution, is recommended for OSS operator projects due to its infrastructure focus and demonstrability without massive GPU resources. Idea two, concerning nuanced SLO autoscaling, is better suited for research-oriented contributions with rigorous benchmarking. Idea three, for LoRA adapter lifecycle management, offers a middle ground between the two. It is important to note that none of these areas are entirely unoccupied, and new efforts will build upon existing prior art.