Skrátenie pamäte jazykového modelu: úspory sú menšie, než naznačujú články

Keď jazykový model číta dlhý prompt, ukladá pre každý token kľúč a hodnotu. Toto úložisko je KV cache. Pri 32 000 tokenoch zaberá 2,4 GB pre jeden dopyt na modeli, ktorý sme testovali. Mnohé články navrhujú väčšinu z nej zahodiť a ponechať len dôležité tokeny. Otestovali sme to na bezplatnej GPU a položili dve otázky, ktoré články zriedka kladú spolu. Nájde model stále fakty, ktoré potrebuje? A vráti sa pamäť naozaj späť?

Krátka odpoveď: pri 25 % a 12,5 % cache stratila každá metóda, ktorú sme skúsili, potrebné fakty takmer vždy.

Model bol Qwen3-4B-Instruct na bezplatnej Kaggle T4. Úloha bola syntetická: niekoľko záznamov o projektoch („Project X has status S and codeword C“) skrytých medzi nesúvisiacimi dokumentmi, potom otázka na jeden, dva alebo všetky tri. Odpovede sa hodnotili presnou zhodou kódového slova. Prompty mali 8k, 16k a 32k tokenov, po 6 prípadoch. Beh bol zastavený v dohodnutom časovom limite, takže úroveň 32k má 3 z 6 prípadov. Zostáva 255 zaznamenaných výsledkov z 306 plánovaných. Každá politika a rozpočet nižšie má 15 otázok.

Porovnali sme šesť spôsobov výberu, čo ponechať: žiadne vytláčanie, posuvné okno, náhodné tokeny, skóre key-norm a naše vlastné reimplementácie myšlienok SnapKV a H2O. Každú sme spustili na úrovni tokenov aj na úrovni stránok (bloky po 16 tokenoch).

Zdroj: zaznamenané výsledky behu, 255 záznamov. Rozpočet 12,5 % je horší: 0 alebo 1 správna z 15 pre každú metódu.

S plnou cache model odpovedal 15 z 15. S jej štvrtinou najlepšie metódy dosiahli 2 z 15. Typická zlá odpoveď si ponechala názov projektu, ale vymyslela číslice, napríklad „cobalt-381“ namiesto „cobalt-2609“. Náš výklad: skórovanie zachová význam tokenu a zahodí vzácne číslo, ktoré nesie odpoveď. To je hypotéza z týchto behov, nie testovaný mechanizmus.

Inferenčné servery ukladajú cache v stránkach po 16 tokenoch. Stránku možno znovu použiť, len keď sú všetkých jej 16 tokenov preč. Ak vymažete roztrúsené tokeny, uvoľníte oveľa menej, než si myslíte. Toto účtovníctvo sme simulovali na rovnakých behoch. Metódy zarovnané na stránky uvoľnia takmer všetko, ale stratili odpoveď. Metódy, ktoré si ponechali trochu presnosti, uvoľnili podstatne menej.

Zdroj: simulované účtovníctvo stránok po 16 blokoch na zaznamenaných behoch (priemer 30 prípadov na metódu). Nie je to meranie na skutočnom stránkovanom serveri. Každá skórovaná metóda logicky odstránila približne 1962 MB na otázku, takže 320 MB uvoľnených znamená 16 % z toho. Metóda window logicky odstránila 2376 MB na otázku a 2373 MB z toho sa stalo celými stránkami (vykreslená hodnota). Prečo odstraňuje viac než ostatné metódy, sme nezisťovali, takže ju porovnávajte opatrne.

Ešte jeden výsledok. V statickom cache Hugging Face, ktorý sme použili, sa dekódovanie po vytlačení nezrýchlilo (asi 1510 až 1640 ms na token). To hovorí, že knižnica stále počíta pozornosť (attention) nad plnou šírkou. Nehovorí to, že stránkovaný server by sa správal rovnako.

• 4B otvorený model na bezplatnej T4. Toto nič nehovorí o špičkových modeloch.
• SnapKV a H2O sú tu naše reimplementácie, bez overenia voči publikovaným číslam.
• Uvoľnené stránky sú simulované. Na GPU sa merala len alokácia cache.
• Úroveň 32k je hotová napoly. Všetky dokončené 32k prípady tiež zlyhali.
• Jedna syntetická záťaž. Skutočné úlohy môžu byť zhovievavejšie.

Čo to podporuje: otázku, ktorú sa oplatí poriadne otestovať. Metóda by musela vyberať celé stránky a ponechať čísla a názvy. Takú sme nepostavili.