3 bits in plaats van 16: TurboQuant ontleed en wanneer je het echt moet inschakelen

In maart 2026 publiceerde Google een bericht over TurboQuant, een algoritme voor geheugencompressie voor taalmmodellen, dat een marktpaniek veroorzaakte omdat aandelen van geheugenfabrikanten in een week tijd bijna 90 miljard dollar aan gecombineerde marktwaarde verloren. Het algoritme pakt het KV-cache-probleem aan: terwijl LLM's tekst genereren, slaan ze tussentijdse berekeningen op voor alle voorgaande tokens, wat lineair groeit met de contextlengte en tientallen gigabytes kan verbruiken. Zo neemt de KV-cache voor Llama 3.1 70B bij een context van 128K ongeveer 40 GB in beslag in BF16, waardoor het onmogelijk is om op een enkele H100 GPU te passen. TurboQuant comprimeert de KV-cache 5-6x door een willekeurige rotatie op vectoren toe te passen vóór kwantisatie, gevolgd door een optimale Lloyd-Max-kwantiseerder, dit alles zonder kalibratie of fine-tuning. Deze data-oblivious aanpak werkt op elk transformermodel. Google beweert 'tot 8x versnelling op H100 GPU's', maar analyse van de community laat zien dat dit gemeten is tegen FP32; de echte versnelling is ongeveer 4x voor alleen aandacht, en de geheugenbesparing is het echte voordeel. Benchmarks op kleine modellen (tot 8B) tonen nul nauwkeurigheidsverlies op LongBench en Needle-in-a-Haystack, maar er zijn geen gegevens voor modellen van 70B+, en communitytests op een 104B-model tonen slechts een perplexiteitstoename van 3,6%. Vergelijkingen met alternatieven zoals KVTC (tot 20x compressie maar vereist kalibratie), RotorQuant (snellere rotatie maar lagere kwaliteit) en KIVI (16x compressie, geïntegreerd in Hugging Face) geven een compleet beeld. Het ontbreken van officiële code wordt gecompenseerd door meer dan 15 community-implementaties.