Rutare cache KV: Reduceți munca redundantă de preumplere LLM

Rutarea cache-ului KV contează atunci când prefixele de prompt repetate continuă să apară în traficul LLM. Dacă cererea corectă ajunge pe replica corectă, motorul de servire poate reutiliza starea de atenție cache-ată în loc să recalculeze aceleași tokenuri de preumplere din nou și din nou.

Acest lucru pare a fi un detaliu de infrastructură, dar devine rapid o problemă de produs. Promptele lungi ale sistemului, contextul RAG, exemplele few-shot și istoricul de chat multi-turn pot face ca munca de preumplere să fie costisitoare. Când fiecare replică recalculează același prefix, echipele plătesc în latență, timp GPU și planificare a capacității.

ShareAI oferă dezvoltatorilor un API pentru peste 150 de modele, vizibilitate pe piață, rutare și failover. Rutarea cache-ului KV se află cu un strat mai jos, în infrastructura de servire a modelului. Concluzia utilă pentru cititorii ShareAI este simplă: deciziile de rutare contează la fiecare strat al stivei AI, de la alegerea modelului până la care replică GPU gestionează un prompt repetat.

De ce contează rutarea cache-ului KV

În timpul inferenței LLM, un model procesează mai întâi promptul de intrare în faza de preumplere. Acesta construiește un cache cheie-valoare, de obicei numit cache KV, astfel încât tokenurile generate ulterior să poată face referire la contextul deja procesat.

Cache-ul pentru prefixe permite motoarelor de servire să reutilizeze acel cache atunci când o cerere ulterioară împărtășește același început al promptului. Documentația automată de cache pentru prefixe vLLM descrie acest lucru ca reutilizarea cache-ului KV pentru prefixe comune, astfel încât cererea nouă să poată sări peste calculul pentru partea comună. Cache-ul pentru prefixe SGLang folosește o idee similară pentru a partaja cache-ul KV pentru secvențe comune de tokenuri.

Acest lucru este deosebit de important pentru sarcinile de lucru în care multe cereri încep în același mod: agenți de suport cu un prompt mare al sistemului, aplicații RAG care folosesc fragmente de documentație repetate, agenți de codare cu instrucțiuni de depozit sau produse de chat care transportă istoricul conversației între ture.

Unde se defectează Round-Robin

Cache-ul pentru prefixe este cel mai simplu pe o singură replică. Același proces vede prefixul repetat și poate reutiliza cache-ul său dacă memoria este disponibilă. Problema apare atunci când serviciul se scalează pe orizontală.

Cu un echilibrator de încărcare round-robin standard, prima cerere poate încălzi cache-ul pe replica A, în timp ce a doua cerere cu același prefix ajunge pe replica B. Replica B nu are acea stare cache-ată, așa că recalculează aceeași muncă de preumplere. A treia cerere poate merge la replica C și pierde din nou.

Pe măsură ce numărul de replici crește, echilibrarea naivă a încărcării poate răspândi cererile corelate pe mai multe mașini. Flota de servire a modelului poate părea echilibrată, dar rata de acces la cache-ul pentru prefixe scade. Aceasta este lacuna pe care rutarea cache-ului KV încearcă să o închidă.

Trei niveluri practice de rutare

1. Afiliarea sesiunii

Afiliarea sesiunii direcționează traficul de la același utilizator, spațiu de lucru, chiriaș sau conversație către aceeași replică. Este cel mai simplu punct de plecare pentru chat-ul multi-turn, deoarece solicitările ulterioare împărtășesc adesea contextul anterior.

Compromisul este că identitatea utilizatorului nu este întotdeauna aceeași cu similaritatea solicitării. Doi utilizatori pot împărtăși aceeași solicitare lungă de sistem și totuși să fie direcționați către replici diferite. Afiliarea sesiunii poate fi, de asemenea, perturbată atunci când replicile sunt adăugate sau eliminate.

2. Rutare pe baza hash-ului prefixului

Rutarea pe baza hash-ului prefixului folosește solicitarea însăși ca cheie de rutare. Routerul face hash-ul începutului stabil al solicitării și trimite prefixele potrivite către aceeași replică.

Acest lucru funcționează mai bine atunci când solicitările de sistem repetate, exemplele few-shot sau contextul recuperat împărtășit contează mai mult decât identitatea utilizatorului. Partea dificilă este alegerea limitei prefixului. Dacă hash-ul include un marcaj temporal, un ID de cerere sau un câmp specific utilizatorului, cheia de rutare se fragmentează și reutilizarea cache-ului se destramă.

3. Rutare conștientă de evenimentele cache-ului

Abordarea cea mai avansată urmărește care blocuri de cache sunt rezidente pe care replică, apoi direcționează fiecare cerere către replica cu cea mai bună suprapunere de cache, luând totodată în considerare încărcarea. Proiectul llm-d router descrie un selector de endpoint care ia în considerare localitatea KV-cache, încărcarea curentă și prioritatea atunci când alege unde ar trebui să meargă o cerere.

Este mai complex, dar este direcția corectă pentru flote cu debit mare, unde ratele de cache ratate sunt măsurate, costisitoare și frecvente.

Când să o evitați

Rutarea KV cache nu merită automat complexitatea. Este o potrivire slabă atunci când solicitările sunt scurte, în mare parte unice sau procesate în loturi cu puțină structură repetată.

Rezumarea documentelor, generarea creativă, extragerea unică și multe sarcini asincrone în loturi pot să nu aibă suficientă suprapunere de prefix împărtășit pentru a justifica rutarea conștientă de cache. În aceste cazuri, echilibrarea simplă a încărcării poate fi mai curată.

Testul practic este măsurarea: rata de accesare a cache-ului, timpul până la primul token, debitul, adâncimea cozii, presiunea memoriei GPU și costul per sarcină finalizată. Dacă rutarea conștientă de cache nu modifică aceste valori, corectați mai întâi structura promptului.

Cum se potrivește acest lucru cu ShareAI

ShareAI este o piață AI și API, nu echilibratorul de sarcină pentru servirea modelelor din clusterul GPU. Dezvoltatorii folosesc ShareAI pentru a accesa multe modele printr-un singur API, a compara semnalele pieței, a direcționa cererile, a gestiona utilizarea și a trece la altă rută atunci când o rută se degradează.

Acest lucru face ca rutarea cache-ului KV să fie în continuare relevantă. Dacă operați propriul stack de inferență, vă ajută să puneți întrebări mai bune despre infrastructură. Dacă consumați modele găzduite, vă ajută să evaluați de ce două rute cu nume de modele similare pot avea comportamente diferite sub sarcini reale.

Pentru constructori, acest lucru se conectează și la prețuri. O aplicație cu prompturi lungi, context RAG repetat sau bucle de agenți poate crea o utilizare AI foarte inegală. ShareAI Builder permite proprietarilor de aplicații să direcționeze traficul de inferență AI prin ShareAI, să stabilească o marjă sau o suprataxă, să facă clienții să plătească ShareAI pentru utilizarea direcționată și să primească plăți lunare bazate pe utilizarea generată. Aplicația în sine rămâne construită în afara ShareAI.

Pentru selecția modelului și evaluarea rutelor, începeți cu Piața de modele ShareAI. Pentru elementele de bază ale implementării, utilizați Referința API ShareAI.

Lista de verificare pentru rutarea cache-ului KV

• Puneți mai întâi conținutul stabil al promptului: promptul sistemului, regulile instrumentului, exemplele și contextul repetat.
• Mutați câmpurile dinamice mai târziu: marcaje temporale, ID-uri de cerere, fapte specifice utilizatorului și instrucțiuni unice.
• Măsurați rata de accesare a cache-ului înainte și după modificările de rutare.
• Urmăriți timpul până la primul token, debitul, adâncimea cozii și presiunea VRAM împreună.
• Începeți cu rutarea pe bază de prefix-hash înainte de a construi rutarea conștientă de evenimentele cache-ului.
• Împărțiți regulile de rutare pe sarcină de lucru în loc să forțați o politică globală.
• Mențineți costul și latența vizibile la nivelul aplicației, nu doar în interiorul clusterului de inferență.

Întrebări frecvente

Ce este rutarea cache-ului KV?

Rutarea cache-ului KV este o strategie de rutare care trimite cereri cu prefixuri de prompt repetate către replici care probabil dețin deja cache-ul KV corespunzător. Scopul este de a reduce calculul redundant de preumplere.

Cum este diferită rutarea cache-ului KV de cache-ul de prefix?

Cache-ul de prefix este abilitatea motorului de servire a modelului de a reutiliza starea cache pentru prefixuri de prompt partajate. Rutarea cache-ului KV este strategia de plasare a traficului care ajută cererile potrivite să ajungă acolo unde acea stare cache există deja.

De ce rutarea round-robin afectează cache-ul de prefix?

Rutarea round-robin distribuie cererile între replici fără a ști care replică are care prefix cache. Un prompt repetat poate rata cache-ul pur și simplu pentru că ajunge pe o replică diferită.

Ce tipuri de sarcini beneficiază cel mai mult de rutarea cache-ului KV?

Chat-ul multi-turn, RAG, agenții de codare, agenții de suport, prompting-ul few-shot și aplicațiile cu prompturi lungi de sistem partajate sunt cele mai bune candidate deoarece reutilizează prefixuri de prompt substanțiale.

Când ar trebui o echipă să evite rutarea cache-ului KV?

Evitați-o atunci când prompturile sunt scurte, în mare parte unice sau orientate pe loturi cu puțină structură repetată. În aceste cazuri, complexitatea rutării poate adăuga puțin valoare.

vLLM și SGLang suportă cache-ul de prefix?

Da. Documentația vLLM menționează cache-ul automat de prefix, iar documentația SGLang menționează cache-ul de prefix pentru cache-ul KV partajat pe secvențe comune de tokeni. Motorul de servire încă are nevoie de ajutor pentru rutare atunci când sunt implicate mai multe replici.

Rutarea cache-ului KV este aceeași cu cache-ul semantic?

Nu. Rutarea cache-ului KV funcționează cu reutilizarea exactă sau aproape structurală a prefixurilor în cadrul servire inferenței. Cache-ul semantic stochează și reutilizează răspunsuri sau rezultate intermediare pe baza semnificației, de obicei cu embeddings sau praguri de similaritate.

ShareAI înlocuiește un load balancer conștient de cache-ul KV?

Nu. ShareAI este piața AI și stratul API pentru accesul la modele, rutare, failover, utilizare și facturare. Rutarea conștientă de KV-cache este infrastructura de servire a modelelor la nivel inferior pentru echipele care operează replici de inferență.

Cum ar trebui Constructorii să gândească despre rutarea cache-ului KV?

Constructorii ar trebui să trateze comportamentul cache-ului ca un factor de cost în aplicațiile intens utilizate de AI. Dacă aplicația lor are utilizare inegală, ShareAI poate ajuta la rutarea și monetizarea traficului AI în timp ce aplicația rămâne construită și deținută în afara ShareAI.

Ce ar trebui să măsoare echipele înainte de a schimba rutarea?

Măsurați rata de acces la cache, timpul până la primul token, debitul, adâncimea cozii, presiunea VRAM, costul pe sarcină și calitatea rezultatului. Schimbările de rutare ar trebui să îmbunătățească volumul de muncă, nu doar tabloul de bord.

Poate rutarea cache-ului KV reduce costurile API AI?

Poate reduce costurile de infrastructură pentru echipele care servesc modele singure, deoarece munca redundantă de preumplere mai redusă poate îmbunătăți eficiența GPU. Pentru API-urile găzduite, efectul depinde de faptul dacă furnizorul expune aceste economii în preț sau performanță.