Asymetrie kvantizace KV cache

Výchozí zjištění na GPT-2

Sweep přes bity, granularitu a poměr K/V na GPT-2 small ukázal dvě věci. Za prvé, granularita rozhoduje výrazně víc než cokoli jiného: škálování kvantizace po hlavách (skupiny po 64 kanálech) při 3 bitech dá ppl 46,8, zatímco škálování na celý vektor téhož rozměru dá 243,7. Za druhé, v tomto režimu potřebují klíče víc bitů než hodnoty — při stejném rozpočtu 5,5 efektivního bitu dá konfigurace K=6b/V=4b jen +0,23 ppl (2,9× menší cache), zatímco K=4b/V=6b dá celých +1,40. Vysvětlení je mechanické: chyba v klíčích prochází softmaxem pozornosti a exponenciálně se zesiluje, chyba v hodnotách se jen váženě sečte. Koleno křivky leží kolem 5,5–6,5 efektivního bitu, tedy 2,5–2,9× menší cache prakticky zadarmo.

Přenesení na Qwen3.5 a metodická past

Na Qwen3.5 (baseline bf16 cache na WikiText-2, 8192 tokenů, bloky po 512: perplexita 12,0121) se ukázalo, že tvrzení „klíče potřebují víc bitů“ nepřežilo beze změny přenos na jinou architekturu, a to ze dvou důvodů.

Metodická past. V Qwen3.5 se klíče kvantují na výstupu k_proj, ale mezi tímto bodem a KV cache ještě leží k_norm — RMSNorm přes hlavovou dimenzi, kterou GPT-2 nemá. Kvantizace před k_norm je neprůkazná: norma část chyby měřítka vydělí pryč, takže klíče dostanou opravu zdarma, kterou hodnoty (kvantované na výstupu v_proj bez jakékoli normalizace) nemají. První běh takto vyrobil zdánlivé obrácení dřívějšího zjištění; po přesunu měření na výstup k_norm škoda z kvantizace klíčů vzrostla při všech bitových šířkách, při třech bitech o 44 %. Měřit se tedy musí až na výstupu k_norm — jde o opravu dřívějšího závěru, ne o novou hypotézu.

Asymetrie se obrací podle rozpočtu. I po opravě měření platí původní tvrzení jen v části rozsahu. Pod zhruba 4 efektivními bity je asymetrie výrazná ve prospěch klíčů — rozdíl je v jednotkách perplexity, protože sráz klíčů je ostrý a nízko položený. Od přibližně 5 efektivních bitů výš je volba mezi K a V doménově závislá a rozdíl je jen v setinách ppl: nad kolenem jsou klíče už dost přesné a další bit se lépe zúročí u hodnot. Konfigurace K=4/V=8 dává na Qwen3.5 2,6× menší KV cache (úspora 5,3 GB při plném kontextu) při perplexitě 0,0195 pod baseline. Symetrická 6bitová kvantizace při kontextu 262 tisíc tokenů ušetří 5,4 GB za +0,0182 ppl.

Doménová závislost je konkrétní, ne abstraktní. Na zdrojovém kódu (Python) vyhrávají klíče ve všech měřených rozpočtech, zatímco na WikiTextu nad kolenem vyhrávají hodnoty — sráz klíčů leží u kódu výš, protože přesné dohledání konkrétních identifikátorů jde přes klíče, kdežto próza si vystačí s přibližným adresováním. Konfigurace K=4/V=8, na WikiTextu jediná pod baseline, je na kódu o 0,061 ppl horší než baseline. Poctivé znění doporučení proto zní: nad ~5 efektivními bity je volba doménově závislá, pod ~4 bity dát víc klíčům vždy, protože tam rozdíl narůstá na jednotky. Kód je navíc při 4 bitech v natech zhruba 2,9× citlivější na kvantizaci než WikiText — plné attention vrstvy tam nesou víc práce, což je konzistentní s obecným pozorováním, že úloha přesného vyhledávání zatěžuje pozornost víc než plynulá próza.

Granularita jako jediné univerzální doporučení

Napříč oběma modely i doménami platí jedna věc bez výjimky: kvantizace „po hlavách“ nestačí, pokud je hlava velká. GPT-2 má hlavovou dimenzi 64, Qwen3.5 256 — a při 4 bitech na WikiTextu jde škoda z celého vektoru (+0,334) přes granularitu po hlavách (+0,077) až po podskupiny 64 (+0,052) a 32 kanálů (+0,029), s téměř identickým trendem i na kódu. Jemnější granularita tedy sníží škodu o dvě třetiny za cenu necelého půl bitu režie navíc a je to jediné doporučení z celého bloku měření, které přežilo obě testované domény beze změny.

Proč na tom vůbec záleží

KV cache je při dlouhém kontextu dominantní paměťová položka, a to i ve srovnání s jinými kandidáty na kompresi u hybridních architektur. U Qwen3.5 má stav zbylých lineárních vrstev (Gated DeltaNet) pevnou velikost nezávislou na délce kontextu, zatímco KV cache osmi plných attention vrstev roste s kontextem lineárně; obě položky se vyrovnají kolem 768 tokenů. Při kontextu 8 tisíc tokenů představuje stav ještě 8,6 % celkové paměti, při 131 tisících už jen 0,6 % a při plných 262 tisících pouhých 0,3 % — v tomto režimu zabírá cache 8,6 GB, řádově víc než cokoli, co lze ušetřit další kompresí stavu. Kvantizace cache po hlavách, s přesně nastaveným poměrem K/V podle efektivního bitového rozpočtu, je proto jedinou úsporou v tomto rozsahu, jejíž dopad odpovídá velikosti problému, a jedna z mála metod v projektu, která je prakticky bezztrátová.