Váš KV Cache nemá problém s bity. Má problém s geometrií.

Při stejné 2bitové přesnosti jedna rozhodnutí o tom, po které ose se kvantizuje, mění benchmark skóre z 2,88 na 63,53. Klíče a hodnoty potřebují opačnou léčbu — a důvod je v attention rovnici, ne v hardwaru.

Vezměme si Llama-2-13B. Skupíme jeho key-value cache do kvantizační skupiny o velikosti 32 na dvě bity, zatímco zbytek zůstane na místě — stejný model, stejný bitový rozpočet, stejné velikosti skupin, stejné benchmarky.

V závislosti na jednom jediném prvku implementačního rozhodnutí dosahuje CoQA přesnost buď 2,88 nebo 63,53. Skóre při plné přesnosti je 66,37.

Rozhodnutí není o tom, kolik bitů celkem se používá. Otázka je prostě, jakou osu zvolíte pro seskupení při výpočtu každého měřítka? Když se rozhodnete použít kanál jako rozměr seskupení (klíče) a token jako rozměr seskupení (hodnoty), dostanete se někam v rámci čtyř bodů od plné přesnosti. Pokud otočíte některou z těchto voleb, dojde ke ztrátě kvality. Pokud otočíte obě tyto volby, model již nefunguje.

Čtyři způsoby, jak utratit stejné 2 bity na stejném cache. Výsledky z KIVI ablace na Llama-2-13B při velikosti skupiny 32.

Kvantizace je obvykle považována za jeden ovladač: 8 bitů, 4 bity, 2 bity, s plynulou nákladovostí přesnosti. Uvnitř KV cache tomu tak není. Jde o výběr souřadnicových systémů a různých systémů pro klíče a hodnoty. Tento článek vysvětluje proč. Stručně: kvantizační chyba závisí na rozsahu hodnot uvnitř skupin; klíče a hodnoty mají velmi odlišnou strukturu; a lidé často chybně určí osu, protože ji nelze odvodit z distribuce hodnot. Musíte se podívat, jak se chyba změní po attention spotřebě. To dává obecný princip pro kompresi mezilehlých akcí a dobrý důvod pochybovat o rekonstrukční chybě jako proxy pro kvalitu.

Proč KV Cache je tam, kde to kousne

Během generovací fáze transformer ukládá všechny key-value projekce (KV) dat tokenů, které již zpracoval, do cache, aby nemusel znovu počítat tato data. Tato cache roste lineárně s kontextovou délkou a velikostí dávky. Nakonec to vyústí v to, že cache bude větší než samotný model.

Tento nárůst růstu lze snadno identifikovat, když se podíváme na spotřebu paměti různých částí modelu. V KVQuant analýze LLaMA-7B, váhy představují přibližně 98 procent paměti při délce sekvence 512, s aktivacemi na 2 procenta. Při kontextu 128K se poměr otočí na přibližně 16 procent váhy a 84 procent KV cache. Když se podíváme na analýzu OPT-175B citovanou KIVI autory, našli podobné výsledky. Konkrétně při velikosti dávky 512 s 512tokenovým promptem KV cache dosáhne 1,2 TB — několikrát větší než velikost modelových váhy.

Kapacita je však pouze polovinou problému. GPU musí přečíst celou KV cache z paměti zařízení pro každý generovaný token. To znamená, že zatímco GPU čte KV cache, výpočetní jádra zůstávají nečinná. Snížení celkové velikosti cache tak zvyšuje dostupný procesní prostor a snižuje čas strávený čekáním na přenos dat.

Co je kvantizační chyba

Uniformní integer kvantizace je matematicky přímočará. Pro skupinu čísel se zaznamenává nejmenší číslo jako nulový bod a poté se rozsah skupiny dělí počtem úrovní, které lze reprezentovat, aby se získal krok. Každý prvek se poté zaokrouhlí na nejbližší krok. Dvě okamžité výsledky následují. První, chyba na prvek je omezena polovinou kroku. Druhá, krok je rozsah skupiny dělený 2ᴮ − 1. Při 2 bitech máte pouze 4 úrovně, které pokrývají jakýkoli rozsah, který existuje uvnitř skupiny. Takže prvek, který je o sto větší ve srovnání se svými sousedy, se nezdaří pouze. Nafukuje krok pro všechny ostatní prvky, které sdílejí stejnou skupinu, a všichni se stanou hrubšími společně. Skupina je jednotka poškození. Výběr osy znamená rozhodnutí, které prvky trpí společně. Jinak řečeno, otázka již není „kolik bitů si mohu dovolit?“ ale „kde jsou extrémní hodnoty a mohu je izolovat?“

Klíče: Outliery žijí ve fixních kanálech

Velké jazykové modely obsahují aktivace, které jsou neobvykle velké ve srovnání s většinou akcí. Sun a kolegové katalogizovali tyto velmi velké aktivace napříč různými rodinami modelů: v Mixtral 8x7B je největší velikost blízká 7000, zatímco medián velikosti rysu je kolem 0,3 — zhruba čtyři řády velikosti. Tyto jsou velmi vzácné; zůstávají fixní v rozměrech, které se zřídka mění s vstupem, a nejsou náhodné. Jednají jako implicitní předpojatosti a jsou to, co zaměřuje pozornost na několik tokenů: pozornost chování. V key cache je tato struktura velmi jasná: konkrétní kanály nesou velmi velké velikosti konzistentně napříč každým tokenem v sekvenci. Skupina tokenů a každá skupina obsahuje tyto outliery kanálů, takže každá skupina kroků je nastavena outliery, a všechny běžné kanály za to platí. Skupina kanálů a outliery kanálů tvoří své vlastní skupiny. Jejich vnitřní rozsah je velký, ale soběstačný; běžné kanály jsou ponechány samotné. Výsledky souhlasí. Průměrně napříč vrstvami a hlavami na Llama-2-13B KIVI hlásí klíč rekonstrukční chybu 13,67 při seskupení tokenů proti 4,55 při seskupení kanálů, a — co je důležitější — chybu skóre pozornosti 47,00 proti 9,60. Kvantizace klíčů tokenů produkuje přibližně pětkrát větší chybu skóre. Skóre souhlasí s významnými metrikami pro klíče; kanálová kvantizace vyniká na obou frontách.

Hodnoty: Kde se intuice láme

Value cache neukazuje kanál-outlier vzorec. Zdá se, že je poměrně plochý. Samozřejmě, podle argumentu rozsahu, bychom mohli očekávat, že obě tyto osy budou produkovat podobnou kvalitu komprese.

Nedělají. Bez ohledu na to, jak je implementována správa klíčů (výsledky 2,80 a 2,88), komprese per-kanálových hodnot zhroucení modelu.

A tady je háček: pokud jste měřili tuto ztrátu pomocí surové rekonstrukční chyby na původním tensoru, pro který každá hodnota byla komprimována, per-kanálová hodnota kvantizace vypadá vlastně trochu lépe, při 3,73 proti 4,57. Pokud byste ověřili kompresi zjevným způsobem, zvolili byste konfiguraci, která zničí model.

Value cache kvantizační chyba na Llama-2-13B, měřená dvěma způsoby. Uložená-tensor metrika a spotřebovaná-výstup metrika nesouhlasí o více než řád.

Řešení spočívá v tom, že value cache je nikdy čten přímo. Je spotřebován matricovým produktem: výstup pozornosti je vážený součet hodnot vektorů napříč tokeny, s softmax pozornostními skóre jako váhy. Protože toho, relevantní chyba je ta, která je zavedena během tohoto procesu a ne uvnitř tensorů samotných. Měřeno podle výstupu pozornosti, objednávka byla úplně obrácena. Relativní chyba hlášená KIVI pro výstup pozornosti v důsledku per-token hodnot vektoru kvantizace byla 3,55 ve srovnání s 49,89 pro per-kanálovou kvantizaci — více než čtrnáctkrát vyšší pro to, co se zdálo být lepší volbou na základě toho, jak dobře bylo komprimováno.

Vysvětlení spočívá v pozornostní hustotě, kterou měřili jako 84,3 procenta. Většina informací obsažených ve výstupu může být připsána malé skupině velmi důležitých tokenů. Per-token kvantizace omezuje chybu každého tokenu na ten token, takže chyby na neimportantních tokenech se množí téměř nulovými váhami pozornosti a efektivě mizí. Per-kanálová kvantizace roztírá chybu každého tokenu napříč sdílenou kanálovou škálou, takže špatně reprezentované tokeny kontaminují reprezentaci těch, které jsou důležité. Hustota, která dělá pozornost efektivní, je stejnou vlastností, která dělá per-token kvantizaci bezpečnou.

Přenosný урок je širší než KV cache: měřit kompresní chybu tam, kde je tensor spotřebován, ne tam, kde je uložen. Implicitní předpoklad rekonstrukční chyby je, že každá součást tensoru má stejnou váhu při přispívání k finálnímu výstupu. Pozornost explicitně ne. Jakákoli následná operace, která váží, brání nebo rozptyluje svůj vstup, porušuje tento předpoklad. Čtenáři, kteří jsou obeznámeni s mým předchozím článkem o slabých místech v hodnocení metrikách v systémech načtení, uznají, že tyto výsledky jsou podobné dříve popsaným selháním: snadno vypočítané metriky, které hlásí na něco jiného, než bylo zamýšleno.

Rotary Embeddings Complicate the Keys

Existují některé problémy s používáním Rotary Position Embeddings (RoPE). RoPE otáčí páry kanálů na základě relativní pozice každého tokenu. To míchání částečně rozpouští fixní kanálovou strukturu, která dělala per-kanálovou kvantizaci klíčů funkční — outlirový kanál se otočí do svých sousedů, a sousedé dědí rozsah. Odpověď KVQuant je pořadí: kvantizovat klíče před aplikací rotace, a aplikovat RoPE po dekvantizaci. Společně s per-kanálovou kvantizací klíčů, neuniformními datovými typy a izolací malé frakce outliérů, toto dostává pod 0,1 perplexity degradaci při 3 bitech, a umožňuje službu LLaMA-7B až do 1 milionu tokenů kontextu na jednom A100-80GB.

Je také důležité pochopit úroveň dopadu z RoPE. Autoři článku “RotateKV” hlásili nárůst kvantizačních chyb o 145 procent, když byla přidána RoPE, a poznamenali, že outlirové kanály se liší napříč pozornostními hlavami — což je důvod, proč aplikace jedné sdílené rotace matice všude je nedostatečná, a hlavami adaptivní rotace dělají lépe.

Systémová daň a proč to není detail

Per-token kvantizace se hodí pro dekódování. Každý token přijde; kvantizujete ho, přidáte ho do sekvence (podél tokenu), nic jiného se nehýbe.

Per-kanálová kvantizace se nehodí. Když statistika kanálu sahá tokeny, které ještě nebyly vygenerovány, nemůžete vypočítat měřítko, když token přijde. Práce KIVI je uchovat nejnovější tokeny — až 128 — v plné přesnosti v reziduálním bufferu, a kvantizovat ve skupinách, až když se dostatečně nahromadí.

Jak se ukázalo, reziduální buffer se stává nosným, spíše než jen náhodným. Na GSM8K s Llama-2-7B, plná přesnost skóre 13,50. Úplně kvantizováno na 2 bity s正确nými osami, skóre 5,76. Stejné osy a stejné bity, plus reziduální buffer nedávno vygenerovaných tokenů v plné přesnosti, skóre 12,74. Posuvný okno nedávno vygenerovaných tokenů v plné přesnosti získá zpět většinu toho, co bylo ztraceno v důsledku agresivní kvantizace na obtížných vícestupňových problémech — což by mělo smysl, kdybychom uvážili, které tokeny byly pozornostně sledovány řetězcem aritmetických operací.

Existuje významná výhoda z toho, že vše děláte správně — jak KIVI hlásí, 2,6krát menší špičková spotřeba paměti pro Llama-2-7B, umožňující velikosti dávek až čtyřikrát větší, a také 2,35 až 3,47krát lepší propustnost na reálném úkolu služby.

Co s tím dělat

1. Nikdy nepoužívejte jeden kvantizér pro oba. Používejte různé kvantizéry pro klíče (per-kanálové) a pro hodnoty (per-token). Roura, která aplikuje jeden kvantizér na „KV cache“, pravděpodobně již obětovala většinu možné kvality při použití malého počtu bitů pro reprezentaci každé hodnoty.
2. Kvantizujte klíče před RoPE. To je otázka správnosti, nikoli preference.
3. Uchovávejte plnou přesnost okna nedávno vygenerovaných tokenů. Ačkoli uchovávání takového okna zabere velmi málo paměti ve srovnání s tím, jak velkou může být cache, je přesně tato oblast, která generuje většinu přesnosti pro obtížné úkoly.
4. Neověřujte na rekonstrukční chybu. Vždy ověřujte na základě výstupu pozornosti nebo na základě konečného výkonu úkolu. Ukládací metrika není pouze hluk — pro hodnoty ukazuje špatným směrem.
5. Neověřujte na krátkém kontextu vícečetné výběry. Autoři KIVI záměrně se vyhnuli uzavřeným úkolem, jako je MMLU, pro tuto evaluaci, protože jeden dekódovací krok čtení výstupních logitů téměř nevyčerpává cache. Jakékoli hodnocení, které nevytváří cache přes čas a poté neprovádí generování z ní, nebude moci pozorovat selhání, která jsou inherentní ve vašem návrhu systému.

Kam se práce ubírá

Ačkoli je stále co dělat ohledně geometrické povahy problému, mnoho výzkumníků pokračuje ve studiu způsobů, jak jsou outlirové kanály rozloženy mezi různými transformer hlavami, a jak hardwarové omezení ovlivňují, které seskupení jsou nejlevnější: InnerQ zahrnuje kanálovou normalizaci klíčů do klíčových a dotazových váh během předplněného. Proto se při runtime nevzniká žádné další náklady. Kromě toho InnerQ ukládá vysoké přesnosti okna pro nedávno vygenerované tokeny a pozornostní sink tokeny. Tímto způsobem InnerQ eliminuje příležitost pro outliery v kanálu, aby kontaminovaly sousední kanály.

Jiní navrhují, že místo ukládání celé cache by se mělo ukládat pouze dostatek informací, aby bylo možné znovu vytvořit klíč a / nebo hodnoty na vyžádání z menší cached reprezentace.

Nakonec je důležité si uvědomit, že přesnost není jediným parametrem, který kvantizace ovlivňuje. Nedávný výzkum ukázal degradaci zarovnání v důsledku kvantizace KV cache. Kromě toho tento výzkum dokumentoval degradaci zarovnání i v produkčních vLLM službách, které využívají FP8 cache spolu s beztréninkovým zotavením protokolem, který obnovil až 97 procent toho, co bylo ztraceno v zarovnání. Jako taková, zatímco konfigurace může udržet své benchmarkové výsledky, nemusí nutně znamenat, že si uchovává všechny ostatní relevantní parametry, o které se staráte.

Obecný princip

Idea kvantizace byla rámována jako „přesnostní rozpočet“: kolik bitů můžete obětovat? KV cache ukazuje, že užitečnější otázka je strukturální. Přesnost je přidělena ve skupinách; skupina je jednotka poškození, a osa, po které seskupujete, určuje, které prvky sdílejí svůj osud. Správná osa je ta, po které je váš tensor spotřebován, tj. způsob, jakým používáte váš tensor, a ne to, jak váš tensor vypadá, když je uložen v paměti. Klíče jsou používány prostřednictvím dot-produktu výpočtu proti dotazu. Jedna poškozená kanál otráví všechny skóre. Hodnoty jsou spotřebovány prostřednictvím sparse-váženého průměru napříč tokeny. Protože toho, jedna poškozená hodnota je prostě váženým.

Dva tenzory stejné velikosti a vygenerované dvěma po sobě jdoucími vrstvami jsou léčeny odlišně. Je dobré se zeptat na jakoukoli aktivaci, kterou chcete komprimovat: co operace kontrahuje to pryč, a respektuje moje seskupení to?