TL;DR
llm-d 1.0 releases with distributed inference features targeting the economics of serving large language models at scale across heterogeneous hardware.
The llm-d project released version 1.0 this week, marking the first stable milestone for the CNCF-governed inference stack backed by Red Hat, IBM, Google Cloud, CoreWeave, and NVIDIA. The release targets a problem that has quietly become the bottleneck for enterprise AI: serving models at production scale costs as much as training them. Organizations running agentic workloads now spend more compute on context management than on token generation, a dynamic that existing model servers were not built to handle.
llm-d 1.0 introduces prefill/decode disaggregation, KV cache offloading to CPU or remote memory, and load-aware routing that directs requests across multiple model servers including vLLM and SGLang. Prefix caching reuses common prompt prefixes across requests, while wide expert parallelism spreads mixture-of-experts layers across nodes. Batch and async inference pipelines let operators tune throughput versus latency per workload. The stack runs on heterogeneous hardware — GPUs from different vendors, mixed with CPUs — without requiring a single vendor's orchestration layer.
The market reaction
Agentic systems changed the inference profile overnight. A single user request can spawn dozens of parallel sub-agents, each re-reading megabytes of context while generating unpredictable burst traffic. Traditional autoscaling reacts too slowly; KV caches balloon until they OOM the GPU. llm-d's design treats context as a first-class resource that can be evicted, migrated, or shared across replicas. Early adopters report 2-3x throughput gains on long-context workloads by offloading cold KV blocks to host memory while keeping hot blocks on device.
What this means for practitioners
The project fills a gap between model servers and cluster schedulers. vLLM and SGLang optimize single-node throughput; Kubernetes handles pod lifecycle. llm-d sits between them, making routing decisions based on cache locality, queue depth, and hardware topology. For teams already running vLLM, integration means adding a sidecar and a ConfigMap — no model recompilation. The CNCF governance model also means the API surface is stabilized; breaking changes now require a deprecation cycle.
Open questions remain around multi-tenancy isolation and whether the control plane becomes a single point of contention at thousand-node scale. The project's benchmark suite publishes latency distributions, not just peak throughput, which suggests the maintainers expect operators to care about tail latency. If the ecosystem converges on llm-d as the de facto inference data plane, the next battleground shifts to cache coherence protocols and disaggregated memory fabrics.
FAQ
What is llm-d 1.0? A CNCF-hosted open-source inference platform that adds distributed caching, routing, and disaggregation on top of vLLM and SGLang.
Who governs the project? The Cloud Native Computing Foundation, with founding contributors from Red Hat, IBM, Google Cloud, CoreWeave, and NVIDIA.
Which model servers does it support? vLLM and SGLang at launch, with a plugin interface for others.
Does it require specific hardware? No — it targets heterogeneous clusters mixing GPU vendors and CPU offload targets.
About the Author
Guilherme A.
Former dentist (MD) from Brazil, 41 years old, husband, and AI enthusiast. In 2020, he transitioned from a decade-long career in dentistry to pursue his passion for technology, entrepreneurship, and helping others grow.
Connect on LinkedIn