Compresia KV Cache este o decizie de infrastructură, nu o dezbatere despre modele
Compresia KV cache nu mai este o dezbatere despre calitatea modelului. Este o decizie de achiziție de infrastructură care vine la pachet cu o problemă matematică.
Spun acest lucru direct deoarece prea multe echipe tratează încă memoria LLM-urilor cu context lung ca pe un concurs de benchmark-uri: TurboQuant vs OSCAR vs EpiCache, alegem un câștigător și mergem mai departe. În practică, nu așa eșuează implementările. Ele eșuează pentru că o echipă optimizează pentru lățimea de biți, alta pentru portabilitate, iar a treia descoperă prea târziu că istoricul conversațiilor multi-turn este o problemă diferită față de un singur prompt de 128K. Conform rezumatului MarkTechPost din 18 iunie, cele trei abordări rezolvă blocaje adiacente, nu pe același.
Compresia KV cache devine dureroasă când HBM, nu FLOP-urile, este limita ta
Matematica memoriei este partea pe care operatorii nu o pot ignora. Exemplul sursă folosește Llama-3.1-70B în BF16: aproximativ 0,31 MB de KV cache per token, cam 40 GB la 128K tokeni și peste 300 GB la 1M tokeni. Acesta este punctul în care cache-ul poate depăși greutatea modelelor în sine. Dacă servești cereri cu context lung și concurență, fiecare token decodat trage acel cache înapoi prin memoria cu lățime de bandă mare (HBM).
Această schimbare contează mai mult decât un alt punct într-un clasament. Odată ce decodarea devine limitată de lățimea de bandă, curba ta de cost se modifică. Nu te mai întrebi: „Poate acest model să răspundă bine?”, ci „Câte sesiuni pot menține active înainte ca traficul de memorie să distrugă latența?”
Într-un test de sarcină pe care l-am rulat luna trecută pentru un client, alegerea modelului nu a fost principala constrângere. Reutilizarea prefixului arăta excelent în izolare, dar odată ce numărul de sesiuni concurente a crescut, latența de coadă a sărit deoarece mișcarea memoriei, nu calculul, era limitatorul. De aceea lucrarea de bază pe 2 biți a KIVI rămâne relevantă în 2026: a încadrat cuantizarea KV cache ca o problemă de sisteme de inferență, nu doar ca un truc de compresie.
TurboQuant este soluția pentru portabilitate, nu câștigătorul universal
TurboQuant este impresionant dintr-un motiv întemeiat. Google Research și NYU au construit o abordare agnostică la date care atacă canalele aberante fără calibrare. Mai întâi, rotește aleatoriu vectorii astfel încât coordonatele să se comporte mai mult ca variabile gaussiene independente. Apoi, aplică un cuantizator scalar precalculat și o transformare QJL pe 1 bit asupra reziduului. Revendicarea teoretică este puternică: distorsiunea rămâne în cadrul unui factor constant mic față de limita inferioară.
Acesta este instrumentul potrivit atunci când te interesează portabilitatea modelului și nu îți permiți o rulare de calibrare personalizată pentru fiecare țintă de servire. Punctul optim raportat este intervalul de 3 până la 4 biți, unde calitatea rămâne aproape fără pierderi pe sarcinile de lucru pe care le subliniază lucrarea. Acest lucru face ca TurboQuant să fie atractiv pentru echipele care rulează flote mixte sau experimentează cu mai multe arhitecturi.
Dar iată partea controversată: oamenii continuă să repete promisiunea greșită. Cea mai sonoră afirmație despre TurboQuant este linia „atenție de 8 ori mai rapidă pe H100” din postarea de pe blogul Google Research despre TurboQuant, totuși articolul sursă notează corect că aceasta se referă la un micro-benchmark îngust, nu la servirea end-to-end. Am mai văzut acest tipar cu nucleele de inferență: un câștig într-o etapă devine un argument de achiziție pentru întregul stack. Așa își cumpără echipele dezamăgirea.
OSCAR contează pentru că cineva a livrat efectiv părțile dificile
Dacă ținta ta este compresia KV cache INT2 implementabilă, OSCAR este povestea practică în acest moment. Sistemul celor de la Together AI nu propune doar o rotație conștientă de atenție; acesta integrează paging cu precizie mixtă, nuclee Triton și integrare SGLang. Aceasta este o mare realizare, deoarece câștigurile în producție vin de obicei din pachet, nu din lucrarea academică.
Detaliile contează. OSCAR păstrează tokenii de tip "sink" și cei recenți în BF16 în timp ce comprimă tokenii istorici la INT2, lăsând doar aproximativ 0,24% din tokeni necomprimați la un context de 128K, conform rezumatului. De asemenea, livrează rotații precalculate pentru modelele suportate, ceea ce elimină un pas neplăcut de implementare. Avantajul raportat este substanțial: până la 7,83x throughput la nivel de job, aproximativ 8x reducere a memoriei KV-cache la un context de 100K și o decodare de până la 3x mai rapidă pe configurațiile testate.
De aceea cred că OSCAR câștigă în prezent argumentul privind implementabilitatea la extrema de biți mici. Nu pentru că ideea este mai frumoasă, ci pentru că cineva a redus distanța dintre teoria cuantizării și realitatea servirii.
Cazul ideal pentru un câștigător direct tot nu stă în picioare
Un contraargument corect este că întreprinderile au nevoie de un răspuns simplu. Dacă o metodă o bate pe alta la calitatea benchmark-ului și la throughput, alegerea liderului reduce complexitatea. Există logică în asta. Fiecare cale suplimentară de inferență adaugă overhead de testare, logică de rollback, efort de observabilitate și povară de suport. Standardizarea pe o singură metodă este adesea alegerea operațională sănătoasă.
Sunt de acord cu acest instinct. Doar că nu cred că dovezile actuale susțin un câștigător universal.
Comparația raportată de OSCAR sugerează că TurboQuant scade drastic la bugete similare, dar acea interpretare vine cu avertismente pe care articolul sursă a făcut bine să le semnaleze: comparația rulează în cadrul framework-ului OSCAR, cuantifică toate straturile, folosește o singură sămânță aleatorie și evaluează TurboQuant sub regimul său intenționat de 3 până la 4 biți. Aceasta nu este suficient pentru un verdict general. Invers, povestea portabilității TurboQuant nu răspunde la întrebarea dacă poți obține un comportament de producție INT2 stabil pe stack-ul tău exact săptămâna viitoare.
Deci, decizia reală este mai îngustă și mai plictisitoare:
- Alege TurboQuant atunci când implementarea agnostică la model și comportamentul aproape fără pierderi la 3-4 biți contează mai mult decât compresia absolută.
- Alege OSCAR atunci când ai nevoie de INT2 pentru modele suportate, integrare în producție și economii imediate de memorie la context lung.
- Nu forța niciuna dintre ele să rezolve gestionarea memoriei multi-turn, pentru că nu acesta este rolul lor.
EpiCache este reamintirea faptului că prompturile lungi și conversațiile lungi sunt probleme de sistem diferite
Aceasta este partea pe care multe echipe o omit. Un singur prompt de 128K și o conversație de două ore nu reprezintă aceeași sarcină de lucru, chiar dacă ambele arată ca „context lung” pe un slide.
EpiCache de la Apple abordează direct cazul conversațional. În loc să întrebe doar cât de precis să stocheze tokenii, întreabă ce istoric să păstreze activ, cum să îl segmenteze în episoade coerente și cum să recupereze episodul corect în timpul inferenței. Framework-ul adaugă prefill pe blocuri, clustering episodic, recuperare pe episoade și bugetare a memoriei pe straturi.
Operațional, aceasta este o axă diferită față de cuantizarea KV cache. Este gestionarea cache-ului, nu doar micșorarea lui. Câștigurile raportate în materialul sursă sunt exact motivul pentru care acea distincție contează: până la 40% precizie mai mare decât liniile de bază de evacuare, precizie aproape de cache complet la o compresie de 4-6x, memorie de vârf de până la 3,5x mai mică și o latență cu aproximativ 2,4x mai mică pe benchmark-urile de conversație evaluate.
Replică mea la mentalitatea „doar alege un câștigător” este simplă: EpiCache se compune cu TurboQuant sau OSCAR. Deci, dacă sarcina ta de lucru este un copilot de suport, un asistent de cercetare sau un agent intern cu istoric bogat de chat, cel mai bun stack poate fi o metodă pentru retenție plus alta pentru precizia stocării. Aceasta nu este indecizie. Acesta este design de sistem.
Întrebarea corectă este ce constrângere te costă bani mai întâi
Când intru într-o analiză de inferență, nu încep cu numele lucrărilor. Încep cu trei întrebări.
În primul rând, flota de servire este limitată de memorie în timpul decodării sau suntem încă limitați de calcul? În al doilea rând, avem nevoie de portabilitate între modele sau putem optimiza intens pentru un stack suportat? În al treilea rând, sarcina de lucru este dominată de un singur prompt lung sau de multe schimburi conversaționale?
Aceste întrebări restrâng de obicei domeniul rapid. Dacă portabilitatea domină, TurboQuant are argumentul mai curat. Dacă echipa ta este deja pe un stack suportat de OSCAR și ai nevoie de economii agresive INT2 acum, OSCAR pare mai puternic. Dacă sesiunile de suport sau memoria agentului sunt punctul nevralgic, EpiCache aparține designului chiar dacă folosești și cuantizarea.
De aceea revin mereu la aceeași teză contrariană: compresia KV cache nu este cu adevărat o cursă. Este o problemă de design de stack care a fost comercializată ca o luptă în cușcă.
Lecturi conexe
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation