Googles TurboQuant skrumpede lige et 31GB AI-indeks til 4GB — her er, hvad det faktisk betyder

Googles TurboQuant skrumpede lige et 31GB AI-indeks til 4GB — her er, hvad det faktisk betyder

31GB ned til 4GB. Det er tallet, der barberede et par procent af Microns aktie i juni 2026, og det er, hvad der sendte halvdelen af dev-Twitter ud i en panik over, om deres RAG-regninger lige var kollapset. Matematikken bagved er reel: Googles TurboQuant (arXiv 2504.19874, accepteret til ICLR 2026) komprimerer en LLM's hukommelse cirka 6x ned til omkring 3 bits pr. værdi med næsten intet tab af nøjagtighed. Men de fleste artikler fik én ting galt, og det ændrer, hvordan du bør læse hele historien.

Historien om Googles TurboQuant AI-hukommelseskomprimering er faktisk to historier iført den samme hættetrøje. Lad os rede dem ud.

Nøglepointer

• TurboQuant er Googles træningsfri komprimeringsalgoritme: ca. 6x reduktion af KV-cachen til ca. 3 bits, næsten intet nøjagtighedstab (ICLR 2026).
• TurboVec er et separat tredjeparts Rust-bibliotek, der implementerer TurboQuant. Google udgav det ikke.
• Den virale "31GB → 4GB, slår FAISS"-demo er TurboVecs, ikke rå TurboQuant.
• Den reelle gevinst for udviklere er billigere inferens med lang kontekst og mindre RAG-indekser, men den officielle Google-udgivelse er en artikel, ikke et produkt.

Hvad er Googles TurboQuant, på almindeligt dansk?

TurboQuant er Google Researchs træningsfri, data-uvidende vektorkvantiseringsalgoritme. Den komprimerer en LLM's KV-cache cirka 6x ned til omkring 3 bits pr. værdi med næsten intet tab af nøjagtighed. Den er udgivet i arXiv 2504.19874 og accepteret til ICLR 2026. "Træningsfri" betyder, at den virker på eksisterende modeller direkte fra hylden, uden finetuning.

Så hvad er det egentlig, der bliver komprimeret? Primært to ting.

For det første KV-cachen. Når en model læser din samtale, gemmer den en løbende opsummering af alt hidtil, kaldet key-value-cachen. Tænk på den som modellens korttidshukommelse. Jo længere dit kontekstvindue er, desto mere af denne hukommelse gemmer den, og desto mere GPU-RAM sluger den. En chat på 128k tokens kan få KV-cachen til at vokse til mange gigabytes. Det er grunden til, at serving med lang kontekst hurtigt bliver dyr, og hvorfor prompt-caching for at skære API-omkostninger overhovedet blev en ting.

For det andet vektorindekser. De embeddings, der driver semantisk søgning og RAG, er store arrays af flydende-komma-tal. Gem millioner af dem i fuld præcision, og du kigger på titalls gigabytes RAM.

TurboQuant skrumper begge dele. Her er den seje del: den behøver ingen af dine data for at gøre det. De fleste kvantiseringsmetoder undersøger først en stikprøve af dine vektorer og bygger derefter en kodebog, der er afstemt efter dem. Det springer TurboQuant over. Den er data-uvidende, hvilket betyder, at den rammer sit komprimeringsforhold uden nogensinde at kigge på din fordeling.

TurboQuants reelle trick er ikke komprimeringsforholdet. Det er, at den behøver nul træningsdata for at ramme det.

Det er den ægte gevinst. Du kan rette den mod en model, du allerede kører, og få besparelserne med det samme.

TurboQuant mod TurboVec: Forvirringen, som alle får galt

TurboQuant er Googles komprimeringsalgoritme (arXiv 2504.19874, ICLR 2026). TurboVec er et separat tredjeparts Rust- og Python-bibliotek (RyanCodrai/turbovec), der implementerer TurboQuant til vektorsøgning. Google udgav ikke TurboVec. Det virale "31GB → 4GB, slår FAISS"-resultat tilhører TurboVec, ikke rå TurboQuant. Hvis du husker én ting fra dette indlæg, så husk det.

Det var her, det blev rodet. Da 31GB→4GB-benchmarken gik viralt i begyndelsen af juni 2026, kørte et par medier (herunder Tech Startups) overskrifter om, at Google havde "udgivet TurboVec." Det er ikke, hvad der skete. Tjek kilden: TurboVec ligger på RyanCodrai/turbovec på GitHub og PyPI. Det er et open source-bibliotek bygget af en udvikler ved navn Ryan Codrai. MarkTechPost fik indramningen rigtig og beskrev det som "et Rust-vektorindeks med Python-bindings, bygget på Googles TurboQuant-algoritme."

Så forholdet er enkelt: Google udgav matematikken, og fællesskabet byggede værktøjer med den. TurboVec er det mest synlige af disse værktøjer.

Google byggede algoritmen. En udvikler ved navn Ryan Codrai byggede biblioteket, som alle tager skærmbilleder af. De er ikke det samme.

Hvis du overvejer, hvor et TurboQuant-baseret indeks passer i forhold til dit nuværende setup, sætter vores oversigt over de bedste vektordatabaser i 2026 FAISS, Qdrant og de nyere komprimerede indekser side om side.

Hvordan komprimerer TurboQuant hukommelse uden at ødelægge nøjagtigheden?

TurboQuant bruger en tilfældig rotation plus et polærkoordinat-kvantiseringsskema (PolarQuant) og en Johnson-Lindenstrauss-lignende projektion (QJL, Quantized Johnson-Lindenstrauss) til at sprede værdier jævnt før kvantisering. Det er denne næsten optimale forvrængning, der gør, at den kan komme ned på omkring 3 bits pr. værdi, mens nøjagtigheden forbliver næsten intakt, uden at der kræves genoptræning af modellen.

Lad mig folde det ud, for fagsproget skjuler en ret intuitiv idé.

Når du kvantiserer, afrunder du tal til færre bits. Faren er, at nogle dimensioner af en vektor bærer langt mere vægt end andre, så en klodset afrunding af dem ødelægger resultatet. TurboQuants løsning er først at rotere vektoren tilfældigt. Forestil dig at blande et kortspil jævnt, før du giver, så ingen enkelt hånd ender skæv. Efter rotationen er værdierne spredt ud, så ingen enkelt dimension dominerer, og afrunding gør langt mindre ondt.

Det er QJL-delen: en tilfældig projektion, der blander alting sammen, mens afstande bevares. PolarQuant (præsenteret på AISTATS 2026) kvantiserer derefter de roterede værdier i polære koordinater, hvilket passer bedre til deres fordeling end almindelig gitterafrunding.

Gevinsten er det, artiklen kalder næsten optimal forvrængning, hvilket betyder, at den kommer tæt på den teoretiske Shannon-grænse for, hvor lidt kvalitet du kan tabe ved et givet bit-budget. I almindelige vendinger: med 3 bits pr. værdi kan du stort set ikke gøre det meget bedre, og TurboQuant når dertil uden at studere dine data.

For den fulde mekanisme er Google Research-bloggen og arXiv-artiklen de primære kilder. InfoQ har også en ren udviklerorienteret gennemgang af KV-cache-vinklen, hvis du vil have praktikerens perspektiv.

Hvad betyder 31GB → 4GB egentlig for din RAM-regning?

Et 10M-vektor RAG-indeks, der kræver ca. 31GB RAM i fuld præcision, kommer ned på cirka 4GB med TurboVecs TurboQuant-baserede komprimering, lille nok til at passe på en standard-instans i stedet for et hukommelsestungt niveau. For KV-cachen betyder den ca. 6x reduktion cirka 6x flere samtidige lang-kontekst-sessioner på den samme GPU. Det er den del, der faktisk viser sig på en faktura.

Vi har regnet på tallene, som konkurrenterne ikke vil. Først en hurtig ærlighedsnote: alt nedenfor er estimeret og modelleret (juni 2026) ud fra offentlige cloud-priser og artiklens oplyste forhold. Vi har ikke kørt TurboVec i produktion, så behandl disse som regnestykket, ikke en benchmark, vi fysisk har målt. Prisniveauerne følger samme grundlag, som vi bruger i vores guide til at reducere LLM API-omkostninger.

Her er et 10M-dokument embedding-indeks, fuld præcision mod TurboVec-komprimeret, kortlagt til det cloud-RAM-niveau, du faktisk ville have brug for:

Springet fra en hukommelsesoptimeret boks til en lille generel én er hele historien. For et selvhostet indeks er det ofte forskellen mellem en regning, der får dig til at krympe dig, og en, du knap nok bemærker. Hvis du bygger den pipeline, der ligger ovenpå, dækker vores gennemgang af at bygge en RAG-applikation, hvor dette indeks hører hjemme.

Nu KV-cache-siden, modelleret på en fast 24GB GPU, der servicerer 128k-kontekst-sessioner:

En 6x KV-cache-reduktion sparer ikke bare RAM. Den kan gøre én GPU til seks for lang-kontekst-serving.

Derfor betyder det mere for lang-kontekst-arbejdsbyrder end noget andet. Hvis du servicerer mange korte chats, var din KV-cache aldrig flaskehalsen. Hvis du kører 128k-token-agenter eller dokumentanalyse, ændrer en 6x reduktion din økonomi pr. GPU natten over. VentureBeats rapportering sætter den øvre grænse for gennemstigningsgevinsten til op til 8x på en H100 med 50%+ besparelser, hvilket stemmer overens med vores modellerede samtidighedsregnestykke.

Hvorfor faldt hukommelseschip-aktierne, og overreagerede Wall Street?

Efter afsløringen af TurboQuant faldt aktierne i Micron, Western Digital og Seagate på frygt for, at radikalt billigere AI-hukommelse skrumper den fremtidige DRAM- og HBM-efterspørgsel, den såkaldte "DeepSeek-øjeblik"-indramning. Analytikere, herunder Wells Fargo, argumenterede for det modsatte: billigere hukommelse driver mere samlet forbrug, ikke mindre, via Jevons' paradoks.

Fortællingen skrev sig selv. AI er den største køber af high-bandwidth-hukommelse lige nu, så hvis en Google-algoritme skærer hukommelsesbehovet 6x, lyder logikken, falder efterspørgslen efter chips, og det gør chipproducenterne også. TechCrunch greb endda til "Pied Piper"-sammenligningen, den fiktive komprimerings-startup fra HBO's Silicon Valley, der lovede at skrumpe verdens data. Aktierne faldt på den frygt.

Her er den roligere udlægning, og det er en, nyhedscyklussen for det meste sprang over. Wells Fargo pegede på Jevons' paradoks: når noget bliver billigere og mere effektivt, forbruger vi som regel mere af det samlet set, ikke mindre. Billigere AI-hukommelse betyder, at flere apps sender lang-kontekst-funktioner på markedet, flere teams selvhoster større RAG-indekser, og mere inferens sker, punktum. Effektivitetsgevinster har en lang historie med at øge den samlede efterspørgsel frem for at dræbe den.

Markedet prissatte TurboQuant som en efterspørgselsdræber. Historien siger, at billigere beregning som regel betyder, at vi bare bruger mere af den.

Så var faldet en overfortolkning? Sandsynligvis, i det mindste på kort sigt. En forskningsartikel er ikke en øjeblikkelig omstilling af hele branchen. Markedet reagerede på en overskrift; den faktiske udrulning vil tage kvartaler, og den efterspørgselsinducerende effekt kan meget vel oversvømme besparelserne.

Kan du faktisk bruge TurboQuant i dag?

Ja, delvist. TurboQuants officielle Google-udgivelse er artiklen og algoritmen, ikke et drop-in-produkt. Men fællesskabsimplementeringer findes allerede: TurboVec (RyanCodrai/turbovec, på PyPI) til vektorindekser, og AmesianX/TurboQuant til llama.cpp (cirka 5,2x, med understøttelse af DeepSeek-V2/V3 og GLM-4.7-Flash via MLA). Økosystemet er ungt, men brugbart.

Hvis du vil prøve vektorindeks-siden, er TurboVec kun en pip væk:

pip install turbovec
# Rust + Python bindings, implements Google's TurboQuant for vector search
# llama.cpp KV-cache impl (DeepSeek/MLA): github.com/AmesianX/TurboQuant
# Python reference impl: github.com/yashkc2025/turboquant

Til KV-cache-siden på lokale modeller er AmesianX/TurboQuant llama.cpp-implementeringen den, man skal holde øje med, især hvis du kører DeepSeek- eller GLM-modeller med multi-head latent attention. Den passer godt sammen med en lokal LLM-opsætning, da en mindre KV-cache betyder, at du kan presse en større kontekst på det samme kort. Og hvis du vælger, hvilken åben model du vil køre den mod, dækker vores bedste open source-LLM-benchmarks DeepSeek- og GLM-familierne direkte.

Det ærlige forbehold: det her er artikel-nu, økosystem-modning. Den officielle Google-leverance er forskning, ikke et understøttet produkt med en SLA.

Det ærlige svar: TurboQuant er leverbar matematik, ikke en download-knap. Endnu.

Er TurboQuant hype eller den ægte vare? En ærlig dom

TurboQuant er reel og ægte smart. Dens træningsfri design er den sande gevinst, og KV-cache-gevinsten betyder mest for lang-kontekst-arbejdsbyrder. Men det er ikke magi: det er ét kvantiseringsfremskridt blandt mange, overskriftens 31GB→4GB tilhører TurboVec snarere end Google, og aktiepanikken overfortolkede et forskningsresultat.

I vores erfaring med at finjustere inferens- og RAM-omkostninger for kunder, er det, der afgør, om en teknik som denne er værd at adoptere, friktion. Træningsfri vinder stort her, fordi der ikke er nogen finetuning-cyklus, ingen kodebog at vedligeholde, ingen modelkirurgi. Du kan montere den på noget, du allerede kører.

Hvad det ændrer:

• Billigere lang-kontekst-inferens, hvilket er der, hukommelsesomkostninger faktisk gør ondt.
• Mindre selvhostede RAG-indekser, der passer på billigere hardware.
• En komprimeringsmulighed, du kan adoptere uden at genoptræne noget.

Hvad det ikke ændrer:

• Det vil ikke gøre meget for kort-kontekst, små-model-arbejdsbyrder, hvor KV-cachen aldrig var flaskehalsen.
• Det gør ikke din eksisterende kvantisering forældet natten over; det er en tilføjelse, ikke en erstatning.
• Den officielle Google-udgivelse er stadig en artikel, så produktionsklar værktøjskasse er op til fællesskabet indtil videre.

Hvis du prøver at finde ud af, hvad det betyder for din egen inferens- eller RAM-regning, er det præcis den slags omkostningsmodellering, vi laver for kunder hos Techsy. Få en gratis konsultation, hvis du vil have et ekstra par øjne på det.

Ofte stillede spørgsmål

Hvad er Google TurboQuant?

TurboQuant er Google Researchs træningsfri vektorkvantiseringsalgoritme, udgivet i arXiv 2504.19874 og accepteret til ICLR 2026. Den komprimerer en LLM's KV-cache cirka 6x ned til omkring 3 bits pr. værdi med næsten intet tab af nøjagtighed. Fordi den er data-uvidende, virker den på eksisterende modeller uden finetuning eller genoptræning.

Udgav Google faktisk TurboVec?

Nej. TurboQuant er Googles algoritme. TurboVec er et separat tredjeparts Rust- og Python-bibliotek (RyanCodrai/turbovec) bygget ovenpå TurboQuant af en uafhængig udvikler. Nogle medier krediterede fejlagtigt Google for at udgive TurboVec, da den virale 31GB→4GB-benchmark gik viralt, men GitHub viser, at det er et fællesskabsprojekt.

Er TurboQuant det samme som TurboVec?

Nej. TurboQuant er den komprimeringsalgoritme, Google udgav. TurboVec er ét bibliotek, der implementerer den algoritme til vektorsøgning. Det ene er matematikken; det andet er et værktøj bygget med matematikken. Det berømte "31GB → 4GB, slår FAISS"-resultat er TurboVecs, ikke noget, Google sendte direkte på markedet.

Mister TurboQuant nøjagtighed?

Næsten intet tab af nøjagtighed er overskriftspåstanden fra artiklen, selv ved omkring 3 bits pr. værdi. Algoritmen opnår næsten optimal forvrængning (tæt på Shannon-grænsen) ved at rotere vektorer tilfældigt før kvantisering, så ingen enkelt dimension dominerer. I praksis betyder det, at kvalitetstabet er lille nok til at være ubetydeligt for de fleste arbejdsbyrder.

Hvor meget RAM sparer TurboQuant?

Cirka 6x på KV-cachen, hvilket bringer den ned på omkring 3 bits pr. værdi. På vektorindeks-siden demonstrerede TurboVec et 10M-dokument-indeks, der skrumpede fra 31GB til omkring 4GB, op til en 92% hukommelsesreduktion. Dine faktiske besparelser afhænger af dit præcisionsudgangspunkt, og om du komprimerer KV-cache, embeddings eller begge dele.

Er det bare hype, hvorfor faldt hukommelsesaktierne?

Det er et reelt fremskridt, men panikken overfortolkede et forskningsresultat. Micron, Western Digital og Seagate faldt på frygt for, at billigere AI-hukommelse skærer i chipefterspørgslen. Wells Fargo kontrade med Jevons' paradoks: billigere, mere effektiv hukommelse øger som regel det samlede forbrug. En artikel er heller ikke en øjeblikkelig omstilling af branchen, så den kortsigtede reaktion ser overdreven ud.

Kan jeg bruge TurboQuant i dag?

Delvist. Den officielle Google-udgivelse er artiklen og algoritmen, ikke et produkt. Fællesskabsimplementeringer findes nu: TurboVec på PyPI til vektorindekser, AmesianX/TurboQuant til llama.cpp (DeepSeek-V2/V3 og GLM-4.7-Flash via MLA), og yashkc2025/turboquant som en Python-reference. Økosystemet er ungt, men allerede brugbart.

Hvordan adskiller TurboQuant sig fra den kvantisering, jeg allerede laver?

Det meste kvantisering studerer en stikprøve af dine data for at bygge en afstemt kodebog. TurboQuant er træningsfri og data-uvidende, så den rammer sit forhold uden nogensinde at kigge på din fordeling. Den sigter også specifikt mod KV-cachen og vektorindekser med næsten optimal forvrængning frem for blot at komprimere modelvægte.

Virker TurboQuant med DeepSeek eller llama.cpp?

Ja, via AmesianX/TurboQuant llama.cpp-implementeringen, som rapporterer cirka 5,2x komprimering og understøtter DeepSeek-V2/V3 og GLM-4.7-Flash via multi-head latent attention (MLA). Det gør den til en praktisk mulighed, hvis du selvhoster disse modeller og vil have en mindre KV-cache til længere kontekster på den samme hardware.

Hvornår hjælper TurboQuant faktisk mest?

Den hjælper mest med lang-kontekst-inferens og store selvhostede RAG-indekser, hvor hukommelse er den reelle flaskehals. En 6x KV-cache-reduktion betyder flere samtidige 128k-kontekst-sessioner pr. GPU, og et komprimeret embedding-indeks passer på billigere instanser. Den hjælper mindst for kort-kontekst-chats og små modeller, hvor KV-cachen aldrig var din omkostningsdriver.