Az Apple, a Google és a NYU új technikái felezik az LLM-ek memóriaigényét

A hosszú kontextusú nagy nyelvi modellek (LLM) memóriaproblémákkal küzdenek, ami nem a modell súlyaihoz kapcsolódik. Dekódolás közben a transzformerek gyorsítótárazzák a kulcs- és értékvektorokat (KV) minden tokenhez és minden réteghez, hogy ne kelljen újra számolniuk a figyelmet. Ez a gyorsítótár lineárisan növekszik a szekvenciahossz és a kötegméret függvényében. Hosszú kontextus és nagy egyidejűség esetén ez a gyorsítótár meghaladhatja magának a modellnek a méretét. A Llama-3.1-70B modellnél 128 ezer token esetén ez már 40 GB-ot jelent, 1 millió tokennél pedig több mint 300 GB-ot — ami meghaladja maguknak a súlyoknak a 140 GB-os méretét. Ráadásul minden új dekódolt tokennek a teljes gyorsítótárat ki kell olvasnia a nagy sávszélességű memóriából (HBM), ami a dekódolást memóriabefoglalás-sávszélesség-függővé teszi a számítási kapacitás helyett. A KV gyorsítótár zsugorítása így a legközvetlenebb módja a költségek és a dekódolási késleltetés csökkentésének. A jelenlegi megközelítések öt fő családba sorolhatók: token-kizárás (H2O, SnapKV), kvantálás (KIVI, GEAR), alacsony-rangú projekció (Palu), összevonás (KVMerger) és architekturális megosztás (MLA). A legújabb, 2026-os kutatások erősen tolódnak az ultralacsony bites kvantálás irányába. (MarkTechPost)

A Google és a NYU TurboQuant módszere (ICLR 2026) és a Together AI OSCAR-ja ellentétes irányból támadja ugyanazt a problémát, míg az Apple EpiCache-e olyan problémát kezel, amelyet egyik sem old meg. A legtöbb KV kvantáló ugyanazt az alapvető ellenséget küzdi: a kiugró csatornákat — néhány csatorna, amelyek aránytalanul nagy nagyságrendűek, és dominálják a kvantálási tartományt, a jel többi részét csak néhány ábrázolható szintre szorítva. Ezért a naiv INT2 kvantálás (csak négy szint) közel nulla pontosságra esik össze. A KIVI állította fel az alapértelmezett referenciát. Megmutatta, hogy a kulcsvektorok tokenek között fix kiugró csatornákkal rendelkeznek, míg az értékvektorok nem, így a kulcsokat csatornánként, az értékeket tokenenként kvantálja. Ez a hangolásmentes, 2-bites recept körülbelül 2,6-szorosára csökkenti a teljes csúcsmemóriát (beleértve a súlyokat is), és ez a referenciapont, amelyre az újabb módszerek épülnek.

Kapcsolódó: KV cache RAM-ba mentése

TurboQuant: adatfüggetlen és elméletileg optimális

A TurboQuant a kiugró értékeket anélkül kezeli, hogy valaha is ránézne az adatokra, két szakaszban: Első szakasz: minden vektort véletlenszerűen elforgat, így a koordinátái közel függetlenné és közel Gauss-eloszlásúvá válnak, ami lehetővé teszi egy optimális, előre kiszámított skalár (Lloyd–Max) kvantáló alkalmazását koordinátánként. Második szakasz: egy 1-bites Quantized Johnson–Lindenstrauss (QJL) transzformációt alkalmaznak a maradékra, ami provably torzításmentes becslést ad a figyelmi logitokról, normálási állandó többletköltség nélkül. Az értékesítés fő pontja elméleti: a TurboQuant torzítása provably egy kis állandó tényezőn (≈ 2,7×) belül van az információelméleti alsó határhoz képest. Gyakorlatban lényegében teljes pontosságú visszanyerést ér el a Tű a Szénakazalban teszten 4× tömörítés mellett, és a cikk abszolút minőségi semlegességet jelent 3,5 bites, és csak marginális degradációt 2,5 bites csatornánként. Mivel nincs szükség kalibrációra, bármilyen modellen érintetlenül működik, és gyors vektoradatbázis-kvantálóként is funkcionál. Egy megjegyzendő: a széles körben ismételt „8× gyorsabb figyelem H100-on” adat a Google blogjából származik, nem a cikkből, és egy szűk figyelmi-logit mikrobeméretezésre utal. A TurboQuant dokumentált édes pontja a 3–4 bites, közel veszteségmentes tartomány.

Kapcsolódó: TurboQuant méretösszehasonlítás

OSCAR: figyelem-tudatos és bevetésre kész

Az OSCAR az ellenkező irányba fogad. Az az alapelve, hogy az INT2 négy szintjénél egy adatfüggetlen forgatás rossz eszköz — a tartományok vak smoothingja nem elegendő, amikor szinte nincs tartalék pontosság. Ezért az OSCAR egy figyelmi-tudatos forgatást számít ki egy egyszeri offline kalibrációs menetből: a kulcsokat a lekérdezési kovariancia sajátvektor-bázisába forgatják, az értékeket a pontszám-súlyozott érték kovariancia sajátvektor-bázisába. Egy Hadamard transzformáció és egy bit-megfordító permutáció ezután elosztja a csatorna fontosságát egyenletesen a kvantálási csoportok között. Amitől az OSCAR megkülönbözteti magát, hogy teljes rendszerként érkezik, nem csak algoritmusként: Vegyes-precíziós lapozott gyorsítótár: a sink és a legutóbbi tokenek BF16-ban maradnak, míg a történelem INT2-re tömörödik — 128K kontextusban csak a tokenek ~0,24%-a marad BF16-ban. Fuzionált Triton kernel a teljes SGLang integrációval (lapozott-figyelem és előtag-gyorsítótár kompatibilis). Előre kiszámított forgatások (egy „RotationZoo”) a Qwen3-4B/8B/32B, GLM-4.7-FP8 és MiniMax-M2.7 modellekhez — nincs szükség újrakalibrálásra. Effektív 2,28 bites értéken az OSCAR 1,42 ponton belül marad a BF16-hoz képest a Qwen3-8B-n, és lényegében megegyezik a Qwen3-32B-n (0,02 pontos rés). A GLM-4.7-FP8 esetében — ahol a naiv INT2 nulla pontosságra esik, és az adatfüggetlen alapvonalak csak alacsony egyjegyű számokat érnek el — az OSCAR megegyezik a BF16-tal, sőt, kissé meg is haladja a jelentett benchmarkokon (zajon belül). A Together AI akár 7,83×-os feladat-szintű átvitelt és körülbelül 8×-os KV-gyorsítótár memória-csökkentést jelent 100K kontextusban, akár ~3× gyorsabb dekódolással.

Kapcsolódó: ART-rendszer gyorsítása

Tehát melyik a nyerő? Egyik sem — és ez az őszinte válasz. A bevethető INT2 esetében 128K tokenenként a támogatott modelleken, az OSCAR jelenleg az egyetlen demonstrált lehetőség, amely nem esik össze, és gyártásra kész SGLang támogatással rendelkezik. A betanítás-mentes, modell-agnosztikus kvantálás 3–4 bites tartományban a TurboQuant sokkal szélesebb általánosságot kínál. Az OSCAR cikkében azt jelentik, hogy a TurboQuant több mint 40 pontot esik egy hasonló költségvetés mellett — de ez az értékelés az OSCAR saját keretrendszerén belül fut, minden réteget kvantál, egyetlen véletlen magot használ, és a TurboQuant szándékolt bit-szélessége alatt működik, így gyenge alap a fej-fej melletti ítélethez. Az érdekesebb lehetőség az, hogy a kettő kiegészíti egymást: egy kalibráció-tudatos forgatás párosítása egy optimális skalár kvantálóval egy ígéretes kombináció, amelyet még senki sem szállított le. (Mindkét csapat nyilvánosan megjegyezte ugyanezt az ötletet.)

Kapcsolódó: KV cache llama.cpp-ben

A harmadik tengely: EpiCache

A TurboQuant és az OSCAR is egyetlen hosszú kontextusra épül. Egyik sem kezeli a kiterjedt többfordulós beszélgetéseket, ahol a történelem sok csere során halmozódik. Az Apple EpiCache egy betanítás-mentes KV-gyorsítótár-kezelő keretrendszer, amely pontosan erre a résre irányul: A blokkonkénti előzetes feldolgozás blokkokban dolgozza fel a történetet, hogy a csúcsmemóriát korlátozottan tartsa. Az epizodikus klaszterezés a beszélgetést koherens szemantikai „epizódokra” osztja, amelyek mindegyike saját tömörített gyorsítótárral rendelkezik. Az epizód-egyeztetett lekérés minden lekérdezést a legrelevánsabb epizódhoz irányít a következtetés idején. Az adaptív rétegenkénti költségvetés-allokáció méri az egyes rétegek kilakoltatással szembeni érzékenységét, és ennek megfelelően osztja el a memória költségvetését. A LongMemEval, a RealTalk és a LoCoMo teszteken az EpiCache 40%-kal magasabb pontosságot jelent, mint a kizárási alapvonalak, közel teljes gyorsítótár pontosságot 4–6× tömörítés mellett, és akár 3,5× alacsonyabb csúcsmemóriát (és ~2,4× alacsonyabb késleltetést). Mivel azt dönti el, hogy mely tokeneket tartsa meg, ahelyett, hogy pontosan tárolná őket, közvetlenül az OSCAR-ral vagy a TurboQuant-tal kombinálható a növekvő megtakarítások érdekében. Az EpiCache a beszélgetések kezelésére összpontosít, szemben a TurboQuant és az OSCAR által kínált tömörítési technikákkal.

Kapcsolódó: Perplexity tokenizálási gyorsítás

Főbb tanulságok: A TurboQuant tolja az elméleti, modell-agnosztikus határt — a 3–4 bites közel veszteségmentes tömörítéshez bármilyen modellen. Az OSCAR vezet a bevethető INT2-ben, akár 7,83× átvitellel és ~8× memória-csökkentéssel 100K kontextusban a támogatott modelleken. Az Apple EpiCache a hosszú beszélgetések kezelésére összpontosít, ami kiegészíti a tömörítési módszereket. A 128 ezer tokenes Llama-3.1-70B modellnél a KV gyorsítótár ~40 GB-ot tesz ki, ami meghaladja a modell súlyainak 140 GB-os méretét.