KV Cache Routing: Waarom standaard loadbalancers prefix caching verstoren (en hoe u dit oplost)

Dankzij prefix caching kunnen vLLM en SGLang het opnieuw berekenen van tokens die het model al heeft gezien overslaan — maar alleen als de volgende request op dezelfde GPU-replica terechtkomt. Standaard round-robin routing kan de cache-localiteit in deployments met meerdere replica's aanzienlijk verminderen, waardoor de voordelen van prefix caching beperkt blijven, tenzij de routing cache-aware wordt gemaakt. Prefix-aware sticky routing lost dit op. Dit artikel legt het mechanisme uit, de kosten van het negeren ervan, en hoe u het kunt implementeren in drie niveaus van toenemende geavanceerdheid.

Inference maakt een steeds groter deel uit van de vraag naar AI-rekenkracht. Volgens sommige schattingen in de sector zou inference de meerderheid van het AI-rekenverbruik kunnen vertegenwoordigen naarmate generatieve AI-workloads volwassener worden, en een aanzienlijk deel daarvan is dubbel werk — uw model dat opnieuw attention states berekent voor tokens die het enkele seconden geleden al heeft verwerkt. De boosdoener is niet de GPU of het model. Het is de loadbalancer voor uw inference-cluster, die elke request routeert zonder enig besef van wat er al waar is gecached.

Voor een breder overzicht van LLM-inference-engines en optimalisatieknoppen, zie LLM Inferencing: Optimize Speed, Cost & Scale AI.

Waarom Prefix Caching belangrijk is

Elke LLM-inference request wordt uitgevoerd in twee afzonderlijke fasen. Tijdens de prefill verwerkt het model de gehele invoerreeks en bouwt het een key-value (KV) cache op — een matrix van attention states, één entry per token, opgeslagen in het VRAM van de GPU. Tijdens het decoden genereert het model de output-tokens één voor één, waarbij het teruggrijpt op die gecachte status zonder de invoer opnieuw te lezen.

Prefill is kostbaar. De rekenkosten hiervan schalen kwadratisch met de invoerlengte: het verdubbelen van de prompt verviervoudigt de attention-berekening. Voor een systeem-prompt van 2.000 tokens die eenmaal per request wordt verwerkt bij 1.000 requests per uur, is dat 2 miljoen tokens aan prefill-werk per uur — elk uur, elke dag.

Prefix caching elimineert het overtollige deel van dat werk. Als Request B een prefix deelt met een eerder verwerkte Request A, hergebruikt de engine de gecachte KV-blokken voor die gedeelde tokens en berekent alleen het nieuwe suffix. De besparingen stapelen zich op in drie veelvoorkomende workload-patronen:

• RAG-pipelines: opgehaalde document-chunks kunnen vaak overlappen tussen queries, vooral wanneer veel gebruikers dezelfde kennisbank of frequent geraadpleegde documenten gebruiken.
• Multi-turn chat: elk vervolgbericht wordt toegevoegd aan de gespreksgeschiedenis die het model al heeft gecodeerd.
• Few-shot prompting: een vaste reeks voorbeelden die voorafgaand aan elke request wordt geplaatst, kost één keer prefill-rekenkracht, niet N keer.

vLLM implementeert prefix caching via op hashing gebaseerde blok-matching — elk KV-blok wordt geïdentificeerd door een hash van de tokens die het hebben geproduceerd. SGLang maakt gebruik van RadixAttention, een radix tree die de langste overeenkomende prefix over alle actieve requests vindt en die blokken direct hergebruikt. Bij workloads met veel prefixes is gerapporteerd dat RadixAttention van SGLang meervoudige doorvoerverbeteringen levert ten opzichte van cache-blinde serving, waarbij LMSYS winsten tot ongeveer 5× meldt in representatieve benchmarks. vLLM met automatische prefix caching ingeschakeld elimineert het merendeel van overtollige prefill bij multi-turn workloads.

Dit werkt het beste op een enkele instantie wanneer requests stabiele gedeelde prefixes hebben en voldoende KV-cachecapaciteit om hergebruikbare blokken te bewaren. Het moment dat u schaalt naar een vloot van meerdere replica's, begint het probleem.

Hoe Round-Robin Routing de Cache Hit Rate verstoort

Neem een deployment met acht vLLM-replica's achter een standaard Kubernetes-service. Replica 1 verwerkt een request met een systeem-prompt van 2.000 tokens, berekent de KV-cache en slaat deze op in zijn VRAM. De volgende request met de identieke prompt arriveert. Round-robin stuurt deze naar Replica 2 — die geen cache heeft voor die prefix, dus berekent deze de volledige prefill vanaf nul. De derde request gaat naar Replica 3. Zelfde misser.

Bij workloads waarbij een nuttige prefix-cache slechts op één replica bestaat — bijvoorbeeld bij groeiende gespreksgeschiedenissen of tenant-specifieke contexten — vermindert round-robin routing de waarschijnlijkheid dat een request op de replica terechtkomt die de cache bezit naarmate de vlootgrootte toeneemt. Dit effect kan de cache-localiteit aanzienlijk verminderen en overtollige prefill-berekeningen verhogen.

Bij workloads met veel prefixes kan naïef uitschalen de cache-localiteit verminderen en overtollige prefill verhogen, tenzij routing cache-aware is.

De productiecijfers zijn helder. Het llm-d project, het Kubernetes-native gedistribueerde inference-framework van Red Hat, vergeleek prefix-cache-aware routing met round-robin op 8 pods / 16 H100 GPU's en mat een 57× snellere time-to-first-token en 2× hogere doorvoer op dezelfde hardware. Een afzonderlijke benchmark op Llama 3.1 70B over 4× AMD MI300X GPU's liet een 3× hogere output tokens/sec en 2× TTFT-reductie zien na het overstappen van routingstrategie. DigitalOcean's inference-gateway, gebouwd op dezelfde primitives, mat tot 108% doorvoerverbetering voor cache-aware versus willekeurige routing bij identieke hardwareconfiguraties.

De economische impact hangt af van het request-volume, de modelgrootte, het GPU-type en workload-kenmerken, maar hogere cache hit rates vertalen zich over het algemeen in lagere infrastructuurkosten en een betere benutting van bestaande hardware.

De uitdaging is dat zuivere cache-localiteit en zuivere loadbalancing in tegengestelde richting trekken. De vraag wordt dan: hoe behoudt u cache-localiteit zonder loadbalancing op te offeren?

Drie niveaus van Prefix-Aware Routing

Deze benaderingen zijn geordend van eenvoudigst naar meest precies.

Niveau 1 — Session Affinity

De snelste oplossing: configureer uw loadbalancer zo dat deze hasht op een sessie- of gebruikers-ID en stuurt requests van dezelfde sessie altijd naar dezelfde replica. Dit is standaard beschikbaar in de meeste loadbalancers als een sticky-session of consistent-hash policy — geen aangepaste routinglogica vereist.

Session affinity werkt goed voor multi-turn chat waar dezelfde gebruiker opeenvolgende requests genereert met een groeiende gespreksgeschiedenis. Het heeft twee structurele beperkingen. Het toevoegen van een replica schudt de hash-ring door elkaar, wat bestaande affinity verbreekt en cache misses veroorzaakt totdat de vloot opnieuw is opgewarmd.

Gebruik dit als een snelle initiële verbetering voor single-tenant of lage-concurrency deployments, of overal waar u een snelle winst wilt behalen voordat u investeert in een preciezere oplossing.

Niveau 2 — Prefix-Hash Routing

In plaats van te hashen op wie de request heeft gestuurd, hasht u op wat de request bevat. Concreet hasht u de eerste N tokens van de prompt — de stabiele prefix die identiek is voor verschillende gebruikers — en routeert u alle requests met dezelfde prefix-hash naar dezelfde replica.

Het belangrijkste verschil met session affinity: dit verwerkt gedeelde systeem-prompts correct. Als de routing-key wordt berekend op basis van de stabiele gedeelde prefix, kunnen gebruikers met dezelfde systeem-prompt naar dezelfde replica worden gerouteerd. De replica berekent de prefix KV-cache één keer en bedient elke daaropvolgende overeenkomende request vanuit de cache.

Het kiezen van de juiste prefix-grens is belangrijker dan het hashing-mechanisme zelf. Voor een RAG-pipeline moet de grens het langste stabiele deel van de prompt beslaan, wat mogelijk alleen de systeem-prompt is of ook veelgebruikte opgehaalde context bevat. Voor few-shot prompting is het het einde van het voorbeeldblok. Voor multi-turn chat is het het einde van de vorige turn. Als u de grens te kort instelt, blijft er variabele inhoud binnen het gehashte gebied, wat schijnmissers genereert; als u deze te lang instelt, bevat deze inhoud die verschilt per request en wordt de routing over te veel replica's gefragmenteerd.

Niveau 3 — KV-Event-Aware Routing

De meest precieze benadering: de router abonneert zich op KV-blokallocatie- en eviction-events die door elke inference-engine worden uitgezonden en onderhoudt een real-time kaart van welke blokken — geïdentificeerd door hun inhoudshashes — op welke replica aanwezig zijn. Bij elke binnenkomende request scoort hij elke in aanmerking komende replica op basis van hoeveel van de prefix van de request daar al is gecacht, gewogen tegen de huidige belasting van elke replica, en routeert vervolgens naar de optie met de hoogste score.

De scoring-functie balanceert twee signalen. De cache-overlapscore meet welk fractie van de prefix-blokken van de binnenkomende request al aanwezig is op een bepaalde replica. De loadscore meet hoe verzadigd die replica op dat moment is. De router balanceert cache-localiteit met de huidige replica-belasting bij het nemen van routingbeslissingen.

Dit is in grote lijnen de architectuur die wordt gebruikt door de Endpoint Picker-component van llm-d, die cache-status en belastinginformatie gebruikt om een doelreplica te selecteren voordat de request wordt doorgestuurd. De routing-overhead zelf is verwaarloosbaar vergeleken met de prefill-besparingen die het oplevert.

Wanneer u Prefix-Aware Routing kunt overslaan

Prefix-aware routing verdient zijn complexiteit alleen wanneer workloads daadwerkelijke prefix-overlap hebben. Het voegt bij elke request een routingbeslissing en het opzoeken van de blokstatus toe zonder rendement in drie scenario's: wanneer alle prompts uniek zijn (document-samenvatting, creatieve generatie met gevarieerde invoer), wanneer prompts kort zijn (onder ongeveer 200 tokens, waar de prefill-kosten triviaal zijn), of wanneer batch-workloads volledig verschillende invoer verwerken zonder structurele herhaling.

De praktische diagnose: meet uw cache hit rate rechtstreeks vanuit vLLM's cache-event-metrics of SGLang's RadixAttention-statistieken. Als de hit rate zelfs na cache-aware routing laag blijft, controleer dan eerst de prompt-structuur.

Hoe TrueFoundry KV Cache Sticky Routing implementeert

TrueFoundry's AI Gateway en model-deploymentlaag implementeren sticky routing voor KV-cache-optimalisatie op native wijze. Wanneer een model via TrueFoundry wordt geïmplementeerd, kunnen requests met overeenkomende prefixes naar dezelfde vLLM- of SGLang-replica worden gerouteerd, waardoor die requests de bestaande KV-cache-status kunnen hergebruiken in plaats van herhaaldelijk dezelfde prefill-tokens opnieuw te berekenen.

De routing-laag is ontworpen om twee concurrerende doelen te balanceren: het behouden van cache-localiteit en het handhaven van een gezonde belastingverdeling over replica's. Wanneer een replica de relevante prefix-cache al bevat, kan de routing de voorkeur geven aan die replica om hergebruik te maximaliseren. Wanneer een replica verzadigd raakt, kan de gateway terugvallen op alternatieve replica's om te voorkomen dat cache-localiteit een knelpunt wordt.

Omdat routing geïntegreerd is met model-deployment, hoeven teams geen afzonderlijke infrastructuur te bouwen voor sticky sessions, prefix-hashing of aangepast loadbalancing-beleid. Dezelfde deployment-workflow die wordt gebruikt om modellen horizontaal te schalen, behoudt ook het cache-aware routinggedrag wanneer replica's worden toegevoegd of verwijderd.

Voor teams die lange systeem-prompts, multi-turn chattoepassingen, RAG-workloads of few-shot prompting-pipelines uitvoeren, vergroot dit de waarschijnlijkheid dat herhaalde prefixes warm blijven op de replica's die de grootste kans hebben om daaropvolgende requests te bedienen. Het resultaat is een hogere cachebenutting, lagere overtollige prefill-berekeningen en een betere GPU-efficiëntie zonder dat er routinglogica op applicatieniveau nodig is.

Best Practices

• Corrigeer de prompt-structuur voordat u aan routing komt. Plaats alle statische inhoud — systeem-prompt, few-shot-voorbeelden, opgehaalde chunks — aan het begin van elke prompt. Variabele inhoud (gebruikersbericht, request-ID, tijdstempel) moet volgen op de stabiele prefix. Eén verkeerd geplaatst dynamisch veld vóór de systeem-prompt laat de cache-mogelijkheid volledig instorten, ongeacht de routingstrategie.
• Stel uw prefix-grens in op basis van werkelijke aantallen tokens, niet op gissingen. Tokeniseer uw typische systeem-prompt en voorbeeldblok, tel de tokens en gebruik die grens voor prefix-hashing. Een willekeurige vaste lengte snijdt vaak halverwege een zin in variabele inhoud of mist het volledige stabiele gebied.
• Begin op Niveau 2, meet, en beslis dan of Niveau 3 de moeite waard is. De overstap van round-robin naar prefix-hash routing legt het merendeel van de beschikbare winst vast zonder aangepaste routinginfrastructuur. Niveau 3 is het evalueren waard wanneer u meerdere replica's uitvoert bij aanhoudende concurrency en prefix-cache-misses een gemeten knelpunt zijn.
• Monitor de cache hit rate als een productie-alert, niet alleen als een dashboard-metric. Een ontwikkelaar die stilzwijgend een dynamisch veld toevoegt aan de systeem-prompt zal de hit rate onmiddellijk laten kelderen. De latentie-regressie verschijnt voordat iemand de logs controleert. Stel alerts in voor het dalen van de hit rate onder uw vastgestelde baseline.
• Stem het localiteitsgewicht af per workload-type, niet globaal. Multi-turn chat en RAG-pipelines profiteren van een sterke voorkeur voor cache-localiteit. Batch inference over diverse invoer profiteert van zuivere loadbalancing. Als uw gateway gemengd verkeer bedient, voer dan afzonderlijke routingconfiguraties uit per workload-klasse in plaats van een compromis te sluiten over beide.
• Houd VRAM-benutting in de gaten naast de hit rate. Prefix caching ruilt GPU-geheugen in voor prefill-besparingen. Bij hoge concurrency concurreren gecachte blokken met actieve requests om VRAM, wat LRU-eviction triggert en hit rates laat instorten. Als de hit rate onder belasting verslechtert ondanks correcte routing, is geheugendruk waarschijnlijk de oorzaak — pas het plafond voor geheugenbenutting op de inference-engine aan voordat u uitgaat van een routingprobleem.

Conclusie

Voor de meeste teams is de overstap van round-robin naar prefix-hash routing de optimalisatie met de hoogste impact. Geavanceerdere cache-aware routing wordt steeds waardevoller naarmate de vlootgrootte, concurrency en het hergebruik van de cache toenemen.

Ontdek hoe TrueFoundry's AI Gateway prefix-aware routing afhandelt samen met model-deployment in één enkel control plane → truefoundry.com/ai-gateway