Zkrácení paměti jazykového modelu: úspory jsou menší, než naznačují články

Když jazykový model čte dlouhý prompt, ukládá pro každý token klíč a hodnotu. Toto úložiště je KV cache. Při 32 000 tokenech zabírá 2,4 GB pro jeden dotaz na modelu, který jsme testovali. Mnohé články navrhují většinu z ní zahodit a ponechat jen důležité tokeny. Otestovali jsme to na bezplatné GPU a položili dvě otázky, které články zřídka kladou společně. Najde model stále fakta, která potřebuje? A vrátí se paměť opravdu zpět?

Krátká odpověď: při 25 % a 12,5 % cache ztratila každá metoda, kterou jsme zkusili, potřebná fakta téměř vždy.

Model byl Qwen3-4B-Instruct na bezplatné Kaggle T4. Úloha byla syntetická: několik záznamů o projektech („Project X has status S and codeword C“) skrytých mezi nesouvisejícími dokumenty, poté otázka na jeden, dva nebo všechny tři. Odpovědi se hodnotily přesnou shodou kódového slova. Prompty měly 8k, 16k a 32k tokenů, po 6 případech. Běh byl zastaven v dohodnutém časovém limitu, takže úroveň 32k má 3 z 6 případů. Zbývá 255 zaznamenaných výsledků z 306 plánovaných. Každá politika a rozpočet níže má 15 otázek.

Porovnali jsme šest způsobů výběru, co ponechat: žádné vytlačování, posuvné okno, náhodné tokeny, skóre key-norm a naše vlastní reimplementace myšlenek SnapKV a H2O. Každou jsme spustili na úrovni tokenů i na úrovni stránek (bloky po 16 tokenech).

Zdroj: zaznamenané výsledky běhu, 255 záznamů. Rozpočet 12,5 % je horší: 0 nebo 1 správná z 15 pro každou metodu.

S plnou cache model odpověděl 15 z 15. S její čtvrtinou nejlepší metody dosáhly 2 z 15. Typická špatná odpověď si ponechala název projektu, ale vymyslela číslice, například „cobalt-381“ místo „cobalt-2609“. Náš výklad: skórování zachová význam tokenu a zahodí vzácné číslo, které nese odpověď. To je hypotéza z těchto běhů, ne testovaný mechanismus.

Inferenční servery ukládají cache ve stránkách po 16 tokenech. Stránku lze znovu použít, jen když jsou všech jejích 16 tokenů pryč. Pokud smažete roztroušené tokeny, uvolníte mnohem méně, než si myslíte. Toto účetnictví jsme simulovali na stejných bězích. Metody zarovnané na stránky uvolní téměř vše, ale ztratily odpověď. Metody, které si ponechaly trochu přesnosti, uvolnily podstatně méně.

Zdroj: simulované účetnictví stránek po 16 blocích na zaznamenaných bězích (průměr 30 případů na metodu). Není to měření na skutečném stránkovaném serveru. Každá skórovaná metoda logicky odstranila přibližně 1962 MB na otázku, takže 320 MB uvolněných znamená 16 % z toho. Metoda window logicky odstranila 2376 MB na otázku a 2373 MB z toho se stalo celými stránkami (vykreslená hodnota). Proč odstraňuje více než ostatní metody, jsme nezjišťovali, takže ji porovnávejte opatrně.

Ještě jeden výsledek. Ve statickém cache Hugging Face, který jsme použili, se dekódování po vytlačení nezrychlilo (asi 1510 až 1640 ms na token). To říká, že knihovna stále počítá pozornost (attention) přes plnou šířku. Neříká to, že stránkovaný server by se choval stejně.

• 4B otevřený model na bezplatné T4. Toto nic neříká o špičkových modelech.
• SnapKV a H2O jsou zde naše reimplementace, bez ověření vůči publikovaným číslům.
• Uvolněné stránky jsou simulované. Na GPU se měřila jen alokace cache.
• Úroveň 32k je hotová napůl. Všechny dokončené 32k případy také selhaly.
• Jedna syntetická zátěž. Skutečné úlohy mohou být shovívavější.

Co to podporuje: otázku, kterou se vyplatí pořádně otestovat. Metoda by musela vybírat celé stránky a ponechat čísla a názvy. Takovou jsme nepostavili.