llm-d — CNCF Sandbox Project

The Inference Routing
Landscape

Every LLM deployment makes a routing decision — whether you realize it or not. This is the story of four approaches, from simple round-robin to cache-aware intelligence, and where each one shines.

0
Routing Approaches
0
TTFT Speedup (Illustrative)
CNCF
Sandbox Project
The Four Approaches

The Routing Approaches

The runtime (vLLM, SGLang) is an orthogonal choice. The difference is how requests find their way to pods.

Round-Robin
Requests distributed evenly, no awareness of cache state or load. Every request is a cold prefill.
Cache-Blind
Load-Aware
Routes to least-busy replica. Prevents hotspots, but still ignores KV cache state entirely.
Cache-Blind
Hash-Based
Hashes prefix for deterministic affinity. Rigid — breaks with scaling, eviction, variable lengths.
Partial Affinity
Cache-Aware (llm-d)
Scores pods on real KV-cache / prefix overlap, balanced against load and request priority. Routes to the warmest cache.
Full Cache Intelligence
Routing, Visualized

How Requests Flow

Watch three request flows side by side. Round-robin scatters requests randomly. Cache-aware routing sends them to the pod with the warmest KV cache.

Architecture

Three Deployment Stacks

Each stack builds on the one before it. The Cache-Aware stack plugs llm-d's Endpoint Picker (EPP) into the Inference Gateway via the Gateway API.

Basic Stack
Client Request
Round-Robin LB
Pod 1
Pod 2
Pod 3
Cache hit: ~1/N pods
Platform Stack
Client Request
Gateway API
KServe Router
Pod 1
Pod 2
Pod 3
Better ops, same cache miss
Cache-Aware Stack
Client Request
Inference Gateway (IGW)
llm-d EPP
Pod 1 ████
Pod 2 ██
Pod 3 █
Prefix cache hit: high (illustrative)

llm-d's inference scheduler also supports prefill/decode disaggregation, priority- and load-aware scoring, and wide expert parallelism — all behind the same gateway.

Performance

The Performance Gap

Illustrative TTFT curves as context length grows — same runtime (vLLM), only the routing changes. Patterned on llm-d community benchmark results.

Basic / Platform
Cache-Aware (llm-d)
~48x
faster TTFT at 32K tokens (illustrative)
Workload Fit

Which Workload Wins Where?

Different workloads favor different routing. Cache-aware routing dominates when prefix overlap is high. Scores are illustrative fit ratings, not benchmarks.

Multi-Turn Chat
Basic
20
Platform
30
Cache-Aware
95
Best: Cache-Aware
Agentic / Tool Use
Basic
15
Platform
25
Cache-Aware
95
Best: Cache-Aware
RAG / Retrieval
Basic
20
Platform
30
Cache-Aware
90
Best: Cache-Aware
Code Generation
Basic
25
Platform
35
Cache-Aware
85
Best: Cache-Aware
Batch Processing
Basic
75
Platform
65
Cache-Aware
50
Best: Basic Stack
Structured Output
Basic
40
Platform
45
Cache-Aware
80
Best: Cache-Aware
The Honest Verdict

When Cache-Aware Routing Is Worth It

An honest assessment. Cache-aware routing is not always the answer — here is when it matters and when it does not.

Worth the investment when...
  • Your workload has high prefix overlap — multi-turn chat, agentic workflows, RAG with shared templates
  • You are already running Kubernetes with KServe or planning to
  • Context lengths regularly exceed 4K tokens, where cache savings compound
  • You need consistent low-latency TTFT, not just good average throughput
  • You are scaling to multiple GPU pods and cache misses waste expensive compute
Probably not worth it when...
  • Your prompts are mostly unique with little prefix reuse — batch processing, one-shot classification
  • You are running a single GPU pod — local caching already handles everything
  • You do not use Kubernetes and do not plan to — the Platform stack adds complexity
  • Context lengths are short (under 1K tokens) — the prefill savings are minimal
  • Simplicity matters more than performance — the Basic stack is genuinely simpler
Get Started

Start Building with llm-d

llm-d is an open-source CNCF Sandbox project. It runs on any Kubernetes cluster, any GPU vendor (NVIDIA, AMD, Intel), and any vLLM-supported model. The routing logic is decoupled from the infrastructure.