Googles TurboQuant krympet en 31 GB AI-indeks til 4 GB: hva betyr det egentlig?

31 GB ned til 4 GB. Det er tallet som kostet Micron noen prosent på børsen i juni 2026, og som sendte halve dev-Twitter ut i panikk over om RAG-regningene deres nettopp hadde kollapset. Matematikken bak er reell: Googles TurboQuant (arXiv 2504.19874, akseptert til ICLR 2026) komprimerer en LLMs minne omtrent 6x ned til ca. 3 bits per verdi med nesten null nøyakhetstap. Men de fleste dekkingsartiklene fikk én ting feil, og det endrer hvordan du bør lese hele historien.

TurboQuant-historien er egentlig to historier som deler samme hettegenser. La oss nøste dem fra hverandre.

Viktige punkter

• TurboQuant er Googles treningsfrie kompresjonsalgoritme: ~6x KV-cache-reduksjon til ~3 bits, nesten null nøyakhetstap (ICLR 2026).
• TurboVec er et separat tredjepartsbibliotek i Rust som implementerer TurboQuant. Google ga ikke ut TurboVec.
• Den virale «31 GB → 4 GB, slår FAISS»-demoen tilhører TurboVec, ikke TurboQuant alene.
• Den reelle gevinsten for utviklere er billigere lang-kontekst-inferens og mindre RAG-indekser, men Googles offisielle leveranse er et paper, ikke et produkt.

Hva er Googles TurboQuant, på vanlig norsk?

TurboQuant er Google Researchs treningsfrie, datauavhengige vektorkvanteringsalgoritme. Den komprimerer en LLMs KV-cache omtrent 6x, ned til ca. 3 bits per verdi, med nesten null nøyakhetstap. Den er publisert i arXiv 2504.19874 og akseptert til ICLR 2026. «Treningsfri» betyr at den fungerer på eksisterende modeller uten finjustering.

Hva er det egentlig som komprimeres? To ting, i hovedsak.

Først: KV-cachen. Når en modell leser samtalen din, lagrer den et løpende sammendrag av alt så langt, kalt nøkkel-verdi-cache. Tenk på det som modellens korttidsminne. Jo lenger kontekstvindu, jo mer minne holder den, og jo mer GPU-RAM spiser den. En 128 000-token-samtale kan blåse opp KV-cachen til mange gigabyte. Det er derfor langkontekst-serving blir dyrt raskt, og grunnen til at prompt-bufring for å kutte API-kostnader i det hele tatt ble en greie.

Deretter: vektorindekser. Embeddingene som driver semantisk søk og RAG er store arrays med flyttallsverdier. Lagrer du millioner av dem i full presisjon, snakker vi titalls gigabyte RAM.

TurboQuant krymper begge deler. Den kule biten: den trenger ingen av dataene dine for å gjøre det. De fleste kvanterings-skjemaer studerer et utvalg av vektorene dine først og bygger en kodebook tilpasset dem. TurboQuant hopper over det. Den er datauavhengig, noe som betyr at den treffer kompresjonsforholdet uten å se på distribusjonen din én eneste gang.

TurboQuants egentlige triks er ikke kompresjonsforholdet. Det er at den trenger null treningsdata for å treffe det.

Det er den genuine opplåsingen. Du kan peke den mot en modell du allerede kjører og få besparelsene umiddelbart.

TurboQuant vs TurboVec: Forvirringen alle gjør seg skyldig i

TurboQuant er Googles kompresjonsalgoritme (arXiv 2504.19874, ICLR 2026). TurboVec er et separat tredjepartsbibliotek i Rust og Python (RyanCodrai/turbovec) som implementerer TurboQuant for vektorsøk. Google ga ikke ut TurboVec. Det virale «31 GB → 4 GB, slår FAISS»-resultatet tilhører TurboVec, ikke TurboQuant direkte. Hvis du husker én ting fra dette innlegget, husk det.

Her er hvor det gikk galt. Da 31 GB→4 GB-benchmarken gikk viralt i tidlig juni 2026, kjørte noen utgivelser (inkludert Tech Startups) overskrifter om at Google hadde «lansert TurboVec». Det er ikke hva som skjedde. Sjekk kilden: TurboVec bor på RyanCodrai/turbovec på GitHub og PyPI. Det er et åpen kildekode-bibliotek laget av en utvikler som heter Ryan Codrai. MarkTechPost fikk framing-en riktig og beskrev det som «en Rust-vektorindeks med Python-bindinger, bygget på Googles TurboQuant-algoritme».

Forholdet er altså enkelt: Google publiserte matematikken, og fellesskapet bygde verktøy med den. TurboVec er det mest synlige av disse verktøyene.

Google bygde algoritmen. En utvikler ved navn Ryan Codrai bygde biblioteket alle tar skjermbilder av. De er ikke det samme.

Vil du vite hvor en TurboQuant-basert indeks passer inn ved siden av oppsettet ditt, gir oversikten vår over beste vektordatabaser i 2026 FAISS, Qdrant og de nyere komprimerte indeksene side om side.

Hvordan komprimerer TurboQuant minne uten å ødelegge nøyaktigheten?

TurboQuant bruker en tilfeldig rotasjon pluss et polar-koordinat-kvanterings-skjema (PolarQuant) og en Johnson-Lindenstrauss-liknende projeksjon (QJL, Quantized Johnson-Lindenstrauss) for å spre verdier jevnt før kvantering. Denne nær-optimale forvrengingen er det som gjør at den kan gå ned til ca. 3 bits per verdi med nesten intakt nøyaktighet, uten noen modellfinjustering.

La meg pakke det ut, for sjargongen skjuler en ganske intuitiv idé.

Når du kvanterer, runder du tall til færre bits. Faren er at noen dimensjoner av en vektor bærer mye mer vekt enn andre, så klossete avrunding ødelegger resultatet. TurboQuants løsning er å rotere vektoren tilfeldig først. Tenk deg at du stokker en kortstokk jevnt før du deler ut, slik at ingen enkelt hånd ender opp skjevt. Etter rotasjonen er verdiene spredt ut slik at ingen én dimensjon dominerer, og avrunding gjør mye mindre skade.

Det er QJL-biten: en tilfeldig projeksjon som blander alt sammen mens den bevarer avstander. PolarQuant (presentert på AISTATS 2026) kvanterer deretter de roterte verdiene i polar-koordinater, noe som passer distribusjonen deres bedre enn vanlig rutenettavrunding.

Utbetalingen er det papiret kaller nær-optimal forvrengning, noe som betyr at det kommer nær det teoretiske Shannon-grensen for hvor lite kvalitet man kan tape ved et gitt bit-budsjett. Kort sagt: for 3 bits per verdi kan du knapt gjøre det bedre, og TurboQuant treffer det uten å studere dataene dine.

For hele mekanismen er Google Research-bloggen og arXiv-papiret primærkildene. InfoQ har også en pen utviklerorientert gjennomgang av KV-cache-vinkelen hvis du vil ha praktikerperspektivet.

Hva betyr 31 GB → 4 GB egentlig for RAM-regningen din?

En 10M-vektors RAG-indeks som trenger ~31 GB RAM i full presisjon, faller til ca. ~4 GB med TurboVecs TurboQuant-baserte kompresjon, liten nok til å passe på en rimelig instans i stedet for et minnetungt tier. For KV-cache betyr ~6x-reduksjonen omtrent 6x flere samtidige langkontekst-sesjoner på samme GPU. Det er biten som faktisk dukker opp på en faktura.

Vi kjørte tallene konkurrentene ikke vil. En rask ærlighetsnotat først: alt nedenfor er estimert og modellert (juni 2026) fra offentlig skypris og papirens oppgitte forholdstall. Vi har ikke kjørt TurboVec i produksjon, så behandle dette som matematikken, ikke en benchmark vi fysisk har målt. Pristierene følger samme grunnlag vi bruker i veiledningen vår om å redusere LLM API-kostnader.

Her er en 10M-dokuments embeddings-indeks, full presisjon vs TurboVec-komprimert, kartlagt til sky-RAM-tieret du faktisk ville trenge:

Hoppet fra en minneoptimalisert boks til en liten generell formål-boks er hele historien. For en selvhostet indeks er det ofte forskjellen mellom en regning du grimaser av og en du knapt merker. Bygger du pipelinen som sitter på toppen av det, dekker gjennomgangen vår om å bygge en RAG-applikasjon hvor denne indeksen bor.

Nå KV-cache-siden, modellert med en fast 24 GB GPU som betjener 128 000-kontekst-sesjoner:

Et 6x KV-cache-kutt sparer ikke bare RAM. Det kan gjøre én GPU til seks for langkontekst-serving.

Det er grunnen til at dette betyr mer for langkontekst-arbeidsbelastninger enn noe annet. Betjener du mange korte chatter, var KV-cachen din aldri flaskehalsen. Kjører du 128 000-token-agenter eller dokumentanalyse, endrer et 6x-kutt GPU-økonomien din over natten. VentureBeat-rapporteringen setter den øvre grensen for gjennomstrømmingsgevinsten til opp til 8x på en H100 med 50 %+ kostnadsbesparelser, noe som stemmer overens med vår modellerte samtidighetsmatematikk.

Hvorfor falt minnekortaksjer, og overeagerte børsen?

Etter TurboQuants avsløring falt Micron, Western Digital og Seagate på frykten for at radikalt billigere AI-minne krymper fremtidig DRAM- og HBM-etterspørsel, den såkalte «DeepSeek-moment»-framing-en. Analytikere inkludert Wells Fargo argumenterte for det motsatte: billigere minne driver mer total bruk, ikke mindre, via Jevons' paradoks.

Narrativet skrev seg selv. AI er den største kjøperen av høybåndsminne akkurat nå, så hvis en Google-algoritme kutter minnebehov 6x, går logikken, faller etterspørselen etter brikker og dermed brikkeprodusenter. TechCrunch nådde til og med for «Pied Piper»-sammenligningen, den fiktive kompresjonsstartup-en fra HBOs Silicon Valley som lovet å krympe verdens data. Aksjene falt på den frykten.

Her er den roligere tolkningen, og det er en nyhetssyklusen stort sett hoppet over. Wells Fargo pekte på Jevons' paradoks: når noe blir billigere og mer effektivt, forbruker vi vanligvis mer av det totalt, ikke mindre. Billigere AI-minne betyr at flere apper leverer langkontekst-funksjoner, flere team selvhoster større RAG-indekser, og mer inferens skjer, periode. Effektivitetsgevinster har en lang historie med å øke total etterspørsel snarere enn å drepe den.

Markedet prissatte TurboQuant som en etterspørselsdrepe. Historien sier billigere beregning betyr at vi bare bruker mer av det.

Var kursfallet en overreaksjon? Sannsynligvis, i det minste på kort sikt. Et forskningspaper er ikke en øyeblikkelig bransjeomfattende oppgradering. Markedet reagerte på en overskrift; den faktiske utrullingen vil ta kvartaler, og etterspørsels-induksjonseffekten kan godt overstige besparelsene.

Kan du faktisk bruke TurboQuant i dag?

Ja, delvis. TurboQuants offisielle Google-leveranse er papiret og algoritmen, ikke et plug-and-play-produkt. Men fellesskapsimplementasjoner finnes allerede: TurboVec (RyanCodrai/turbovec, på PyPI) for vektorindekser, og AmesianX/TurboQuant for llama.cpp (ca. 5,2x, med støtte for DeepSeek-V2/V3 og GLM-4.7-Flash via MLA). Økosystemet er ungt men brukbart.

Vil du prøve vektorindeks-siden, er TurboVec en pip unna:

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

For KV-cache-siden på lokale modeller er AmesianX/TurboQuant llama.cpp-implementasjonen den å følge med på, spesielt hvis du kjører DeepSeek- eller GLM-modeller med multi-head latent attention. Den passer bra med et lokalt LLM-oppsett, siden en mindre KV-cache betyr at du kan kjøre større kontekst på samme GPU. Og velger du hvilken åpen modell du skal kjøre den mot, dekker oversikten vår over beste åpen kildekode LLM-benchmarks DeepSeek- og GLM-familiene direkte.

Den ærlige forbeholdet: dette er paper-nå, og et modningsøkosystem. Googles offisielle leveranse er forskning, ikke et støttet produkt med en SLA.

Det ærlige svaret: TurboQuant er shippable matematikk, ikke en nedlastingsknapp. Ennå.

Er TurboQuant hype eller det virkelige? En ærlig dom

TurboQuant er ekte og genuint smart. Det treningsfrie designet er den sanne opplåsingen, og KV-cache-gevinsten betyr mest for langkontekst-arbeidsbelastninger. Men det er ikke magi: det er ett kvanterings-fremskritt blant mange, overskrift-31 GB→4 GB tilhører TurboVec snarere enn Google, og aksjepanikkken overlesete et forskningsresultat.

Basert på erfaringen vår med å finjustere inferens og RAM-kostnader for klienter, er det som avgjør om en teknikk som denne er verdt å ta i bruk friksjonen. Treningsfri vinner stort her, fordi det ikke finnes noen finjusteringssyklus, ingen kodebook å vedlikeholde, ingen modellkirurgi. Du kan feste den til noe du allerede kjører.

Hva det endrer:

• Billigere langkontekst-inferens, som er der minnekostnadene faktisk gjør vondt.
• Mindre selvhostede RAG-indekser som passer på rimeligere maskinvare.
• Et kompresjonsalternativ du kan ta i bruk uten å omskolere noe som helst.

Hva det ikke endrer:

• Det vil ikke gjøre mye for kortkontekst-, liten-modell-arbeidsbelastninger, der KV-cachen aldri var flaskehalsen.
• Det gjør ikke eksisterende kvantering din overflødig over natten; det er et tillegg, ikke en erstatning.
• Googles offisielle utgivelse er fremdeles et paper, så produksjonsklar verktøy er opp til fellesskapet for nå.

Prøver du å finne ut hva dette betyr for din egen inferens eller RAM-regning, er det nettopp den typen kostnadsmodellering vi gjør for klienter hos Techsy. Få en gratis konsultasjon hvis du vil ha et ekstra sett øyne på det.

Ofte stilte spørsmål

Hva er Google TurboQuant?

TurboQuant er Google Researchs treningsfrie vektorkvanteringsalgoritme, publisert i arXiv 2504.19874 og akseptert til ICLR 2026. Den komprimerer en LLMs KV-cache ca. 6x, ned til ca. 3 bits per verdi, med nesten null nøyakhetstap. Fordi den er datauavhengig, fungerer den på eksisterende modeller uten finjustering eller ny opplæring.

Ga Google faktisk ut TurboVec?

Nei. TurboQuant er Googles algoritme. TurboVec er et separat tredjepartsbibliotek i Rust og Python (RyanCodrai/turbovec) bygget oppå TurboQuant av en uavhengig utvikler. Noen utgivelser krediterte feilaktig Google med å ha utgitt TurboVec da den virale 31 GB→4 GB-benchmarken gikk viralt, men GitHub viser at det er et fellesskapsprosjekt.

Er TurboQuant det samme som TurboVec?

Nei. TurboQuant er kompresjonsalgoritmen Google publiserte. TurboVec er ett bibliotek som implementerer den algoritmen for vektorsøk. Den ene er matematikken; den andre er et verktøy bygget med matematikken. Det berømte «31 GB → 4 GB, slår FAISS»-resultatet tilhører TurboVec, ikke noe Google leverte direkte.

Mister TurboQuant nøyaktighet?

Nesten null nøyakhetstap er papirpåstanden, selv ved ca. 3 bits per verdi. Algoritmen oppnår nær-optimal forvrengning (nær Shannon-grensen) ved å rotere vektorer tilfeldig før kvantering, slik at ingen enkelt dimensjon dominerer. I praksis betyr det at kvalitetsfallet er lite nok til å være ubetydelig for de fleste arbeidsbelastninger.

Hvor mye RAM sparer TurboQuant?

Ca. 6x på KV-cachen, ned til ca. 3 bits per verdi. På vektorindeks-siden demonstrerte TurboVec en 10M-dokuments-indeks som krympet fra 31 GB til ca. 4 GB, opptil 92 % minnekutt. De faktiske besparelsene dine avhenger av presisjonsgrunnlinjen din og om du komprimerer KV-cache, embeddings eller begge deler.

Er dette bare hype, hvorfor falt minneaksjer?

Det er et reelt fremskritt, men panikkens tolket et forskningsresultat for bokstavelig. Micron, Western Digital og Seagate falt på frykten for at billigere AI-minne kutter brikkeetterspørselen. Wells Fargo svarte med Jevons' paradoks: billigere, mer effektivt minne øker vanligvis total bruk. Et paper er heller ikke en øyeblikkelig bransjeoppgradering, så kortsiktsreaksjonen ser overdrevet ut.

Kan jeg bruke TurboQuant i dag?

Delvis. Googles offisielle utgivelse er papiret og algoritmen, ikke et produkt. Fellesskapsimplementasjoner finnes nå: TurboVec på PyPI for vektorindekser, AmesianX/TurboQuant for llama.cpp (DeepSeek-V2/V3 og GLM-4.7-Flash via MLA), og yashkc2025/turboquant som en Python-referanse. Økosystemet er ungt men allerede brukbart.

Hvordan skiller TurboQuant seg fra kvanterings-teknikker jeg allerede bruker?

De fleste kvanterings-metoder studerer et utvalg av dataene dine for å bygge en tunet kodebook. TurboQuant er treningsfri og datauavhengig, så den treffer forholdet sitt uten å se på distribusjonen din. Den retter seg også spesifikt mot KV-cache og vektorindekser med nær-optimal forvrengning, snarere enn bare å komprimere modellvekter.

Fungerer TurboQuant med DeepSeek eller llama.cpp?

Ja, gjennom AmesianX/TurboQuant llama.cpp-implementasjonen, som rapporterer ca. 5,2x kompresjon og støtter DeepSeek-V2/V3 og GLM-4.7-Flash via multi-head latent attention (MLA). Det gjør det til et praktisk alternativ hvis du selvhoster disse modellene og vil ha en mindre KV-cache for lengre kontekster på samme maskinvare.

Når hjelper TurboQuant mest?

Det hjelper mest med langkontekst-inferens og store selvhostede RAG-indekser, der minne er den reelle flaskehalsen. Et 6x KV-cache-kutt betyr flere samtidige 128 000-kontekst-sesjoner per GPU, og en komprimert embeddings-indeks passer på rimeligere instanser. Det hjelper minst for kortkontekst-chatter og små modeller, der KV-cachen aldri var kostnadsdriveren din.