
Googlen TurboQuant kutisti 31 Gt:n tekoälyindeksin 4 Gt:hen — mitä se oikeasti tarkoittaa
31 gigatavua kutistui neljään. Se on luku, joka vei Micronin osakkeesta muutaman prosentin kesäkuussa 2026, ja se sai puolet devaaja-Twitteristä panikoimaan, olivatko heidän RAG-laskunsa juuri romahtaneet. Alla oleva matematiikka on todellista: Googlen TurboQuant (arXiv 2504.19874, hyväksytty ICLR 2026 -konferenssiin) pakkaa LLM:n muistin suunnilleen 6-kertaisesti noin 3 bittiin arvoa kohden lähes ilman tarkkuushäviötä. Mutta useimmat jutut käsittivät yhden asian väärin, ja se muuttaa koko tarinan lukutapaa.
Google TurboQuant -tekoälymuistin pakkaustarina on oikeasti kaksi tarinaa samassa hupparissa. Selvitetään ne erilleen.
Keskeiset pointit
- TurboQuant on Googlen koulutusvapaa pakkausalgoritmi: noin 6-kertainen KV-välimuistin pienennys noin 3 bittiin, lähes nolla tarkkuushäviötä (ICLR 2026).
- TurboVec on erillinen kolmannen osapuolen Rust-kirjasto, joka toteuttaa TurboQuantin. Google ei julkaissut sitä.
- Viraali "31 Gt → 4 Gt, voittaa FAISSin" -demo on TurboVecin, ei raaka TurboQuant.
- Todellinen kehittäjähyöty on halvempi pitkän kontekstin inferenssi ja pienemmät RAG-indeksit, mutta Googlen virallinen julkaisu on tutkimuspaperi, ei tuote.
Mikä on Googlen TurboQuant selkokielellä?
TurboQuant on Google Researchin koulutusvapaa, datasta riippumaton vektorikvantointialgoritmi. Se pakkaa LLM:n KV-välimuistin noin 6-kertaisesti, suunnilleen 3 bittiin arvoa kohden, lähes ilman tarkkuushäviötä. Se on julkaistu arXivissa numerolla 2504.19874 ja hyväksytty ICLR 2026 -konferenssiin. "Koulutusvapaa" tarkoittaa, että se toimii suoraan olemassa olevilla malleilla ilman hienosäätöä.
Mitä siis oikeasti pakataan? Pääasiassa kahta asiaa.
Ensinnäkin KV-välimuisti. Kun malli lukee keskusteluasi, se tallentaa jatkuvaa yhteenvetoa kaikesta siihenastisesta — tätä kutsutaan avain-arvo-välimuistiksi. Ajattele sitä mallin lyhytkestoisena muistina. Mitä pidempi konteksti-ikkuna, sitä enemmän tätä muistia kertyy, ja sitä enemmän GPU:n RAM-muistia se syö. 128k-tokenin keskustelu voi paisuttaa KV-välimuistin useisiin gigatavuihin. Siksi pitkän kontekstin tarjoilu muuttuu nopeasti kalliiksi, ja siksi prompt caching API-kustannusten leikkaamiseen ylipäätään keksittiin.
Toiseksi, vettori-indeksit. Semanttista hakua ja RAGia pyörittävät upotukset ovat suuria liukulukutaulukoita. Tallenna miljoonia täydellä tarkkuudella, niin katsot kymmenien gigatavujen RAM-tarpeeseen.
TurboQuant kutistaa molemmat. Ja tässä tulee hieno osa: se ei tarvitse yhtään sinun dataasi tehdäkseen sen. Useimmat kvantointimenetelmät tutkivat ensin otoksen vektoreistasi ja rakentavat sitten niihin sovitetun koodikirjan. TurboQuant ohittaa sen. Se on datasta riippumaton, eli se saavuttaa pakkaussuhteensa katsomatta koskaan sinun jakaumaasi.
TurboQuantin todellinen temppu ei ole pakkaussuhde. Se on se, että se tarvitsee nolla koulutusdataa saavuttaakseen sen.
Se on aito läpimurto. Voit osoittaa sen jo käyttämääsi malliin ja saada säästöt heti.
TurboQuant vs TurboVec: Sekaannus, jonka kaikki käsittävät väärin
TurboQuant on Googlen pakkausalgoritmi (arXiv 2504.19874, ICLR 2026). TurboVec on erillinen kolmannen osapuolen Rust- ja Python-kirjasto (RyanCodrai/turbovec), joka toteuttaa TurboQuantin vektorihakua varten. Google ei julkaissut TurboVecia. Viraali "31 Gt → 4 Gt, voittaa FAISSin" -tulos kuuluu TurboVecille, ei raa'alle TurboQuantille. Jos muistat yhden asian tästä jutusta, muista se.
Tässä kohtaa asiat menivät sekaisin. Kun 31 Gt → 4 Gt -benchmark levisi viraaliksi kesäkuun alussa 2026, muutamat mediat (mukaan lukien Tech Startups) julkaisivat otsikoita, joiden mukaan Google olisi "julkaissut TurboVecin". Näin ei käynyt. Tarkista lähde: TurboVec löytyy osoitteesta RyanCodrai/turbovec GitHubissa ja PyPI:ssä. Se on avoimen lähdekoodin kirjasto, jonka on rakentanut Ryan Codrai -niminen kehittäjä. MarkTechPost osasi kehystää oikein ja kuvaili sitä "Rust-vektori-indeksiksi Python-sidonnaisuuksilla, rakennettu Googlen TurboQuant-algoritmin päälle."
Suhde on siis yksinkertainen: Google julkaisi matematiikan, ja yhteisö rakensi sen päälle työkaluja. TurboVec on näistä työkaluista näkyvin.

| TurboQuant | TurboVec | |
|---|---|---|
| Mikä se on | Pakkausalgoritmi | Vektori-indeksikirjasto (Rust + Python) |
| Kuka rakensi | Google Research + DeepMind | Ryan Codrai (kolmas osapuoli) |
| Missä | arXiv 2504.19874, ICLR 2026 | GitHub RyanCodrai/turbovec, PyPI |
| Otsikkoluku | ~6x KV-välimuistin pienennys ~3 bittiin | 31 Gt → ~4 Gt 10M dokumentin indeksissä |
| Tila | Tutkimuspaperi + algoritmi | Toimiva avoimen lähdekoodin kirjasto |
Google rakensi algoritmin. Ryan Codrai -niminen kehittäjä rakensi kirjaston, josta kaikki ottavat kuvakaappauksia. Ne eivät ole sama asia.
Jos punnitset, mihin TurboQuant-pohjainen indeksi sopii nykyisen setupisi rinnalle, meidän kokoelmamme vuoden 2026 parhaista vektoritietokannoista asettaa FAISSin, Qdrantin ja uudemmat pakatut indeksit vierekkäin.
Miten TurboQuant pakkaa muistia tuhoamatta tarkkuutta?
TurboQuant käyttää satunnaista rotaatiota ja napakoordinaattipohjaista kvantointijärjestelmää (PolarQuant) sekä Johnson-Lindenstrauss-tyylistä projektiota (QJL, Quantized Johnson-Lindenstrauss) jakaakseen arvot tasaisesti ennen kvantointia. Tämä lähes optimaalinen vääristymä mahdollistaa noin 3 bittiin arvoa kohden pudottamisen tarkkuuden pysyessä lähes ennallaan, ilman mallin uudelleenkoulutusta.
Avataan tätä, koska jargonin takana on varsin intuitiivinen idea.
Kun kvantoidaan, lukuja pyöristetään harvempiin bitteihin. Vaarana on, että jotkin vektorin ulottuvuudet painavat paljon enemmän kuin toiset, joten niiden kömpelö pyöristäminen pilaa tuloksen. TurboQuantin korjaus on pyörittää vektori ensin satunnaisesti. Kuvittele korttipakan sekoittaminen tasaisesti ennen jakoa, jotta yksikään käsi ei jää vinoksi. Rotaation jälkeen arvot ovat levittäytyneet niin, ettei mikään yksittäinen ulottuvuus dominoi, ja pyöristäminen haittaa paljon vähemmän.
Se on QJL-osa: satunnaisprojektio, joka sekoittaa kaiken säilyttäen samalla etäisyydet. PolarQuant (esitelty AISTATS 2026 -konferenssissa) kvantoi sitten pyöritetyt arvot napakoordinaateissa, mikä sopii niiden jakaumaan paremmin kuin tavallinen ruudukkopyöristys.
Palkinto on se, mitä paperi kutsuu lähes optimaaliseksi vääristymäksi — eli se pääsee lähelle teoreettista Shannonin rajaa sille, kuinka vähän laatua voi menettää annetulla bittibudjetilla. Selkokielellä: 3 bitillä arvoa kohden ei juuri parempaan pysty, ja TurboQuant pääsee siihen tutkimatta dataasi.
Koko mekanismin osalta Google Researchin blogi ja arXiv-paperi ovat ensisijaiset lähteet. InfoQ:lla on myös selkeä kehittäjäsuuntautunut erittely KV-välimuistin näkökulmasta, jos haluat käytännön kehystyksen.
Mitä 31 Gt → 4 Gt oikeasti tarkoittaa RAM-laskullesi?
10 miljoonan vektorin RAG-indeksi, joka tarvitsee ~31 Gt RAM-muistia täydellä tarkkuudella, putoaa noin ~4 Gt:hen TurboVecin TurboQuant-pohjaisella pakkauksella — tarpeeksi pieni mahtuakseen tavalliselle instanssille muistipainotteisen tason sijaan. KV-välimuistin osalta ~6-kertainen pienennys tarkoittaa suunnilleen 6-kertaisesti enemmän samanaikaisia pitkän kontekstin istuntoja samalla GPU:lla. Se on se osa, joka oikeasti näkyy laskulla.
Me laskimme numerot, joita kilpailijat eivät laske. Nopea rehellisyysnoteeraus ensin: kaikki alla oleva on arvioitua ja mallinnettua (kesäkuu 2026) julkisista pilvihinnastoista ja paperin ilmoittamista suhteista. Emme ole ajaneet TurboVecia tuotannossa, joten käsittele näitä matematiikkana, ei fyysisesti mittaamanamme benchmarkina. Hinnoittelutasot noudattavat samaa perustaa kuin oppaamme LLM API -kustannusten vähentämisestä.

Tässä 10 miljoonan dokumentin upotusindeksi, täysi tarkkuus vs TurboVec-pakattu,映射 siihen pilvi-RAM-tasoon, jonka oikeasti tarvitsisit:
| 10M vektorin RAG-indeksi | Tarvittava RAM | Tyypillinen instanssitaso | Karkea kuukausittainen RAM-kustannushaarukka |
|---|---|---|---|
| Täysi tarkkuus (float32) | ~31 Gt | 32 Gt+ muistioptimoitu | korkeampi (muistioptimoitu taso) |
| TurboVec-pakattu | ~4 Gt | 8 Gt yleiskäyttö | huomattavasti matalampi (yleiskäyttötaso) |
Hyppy muistipainotteisesta boksista pieneen yleiskäyttöiseen on koko tarina. Itse ylläpidetylle indeksille se on usein ero laskun välillä, joka saa irvistämään, ja sellaisen, jota tuskin huomaat. Jos rakennat sen päällä toimivaa putkea, meidän läpikäyntimme RAG-sovelluksen rakentamisesta kattaa, missä tämä indeksi elää.
Nyt KV-välimuistin puoli, mallinnettuna kiinteällä 24 Gt GPU:lla, joka palvelee 128k-kontekstin istuntoja:
| KV-välimuisti, 24 Gt GPU @ 128k konteksti | Samanaikaiset istunnot (mallinnettu) |
|---|---|
| Täysi tarkkuus | perustaso (kutsutaan ~N:ksi) |
| ~3-bittinen TurboQuant (~6x) | suunnilleen 6x N |
6-kertainen KV-välimuistin pienennys ei vain säästä RAMia. Se voi muuttaa yhden GPU:n kuudeksi pitkän kontekstin tarjoilussa.
Siksi tällä on eniten merkitystä juuri pitkän kontekstin työkuormille. Jos tarjoilet paljon lyhyitä keskusteluja, KV-välimuisti ei koskaan ollut pullonkaula. Jos ajat 128k-tokenin agentteja tai dokumenttianalyysiä, 6-kertainen pienennys muuttaa GPU-kohtaisen taloutesi yhdessä yössä. VentureBeatin raportointi asettaa ylärajan läpimennon kasvulle jopa 8-kertaiseksi H100:lla yli 50 % kustannussäästöillä, mikä sopii yhteen meidän mallinnetun samanaikaisuuslaskelmamme kanssa.
Miksi muistisiruosakkeet laskivat, ja yli-reagoiko Wall Street?
TurboQuantin paljastuksen jälkeen Micronin, Western Digitalin ja Seagaten osakkeet laskivat pelossa, että radikaalisti halvempi tekoälymuisti kutistaa tulevaa DRAM- ja HBM-kysyntää — ns. "DeepSeek-hetki"-kehystys. Analyytikot, mukaan lukien Wells Fargo, väittivät päinvastaista: halvempi muisti ajaa enemmän kokonaiskäyttöä, ei vähemmän, Jevonsin paradoksin kautta.
Narratiivi kirjoitti itsensä. Tekoäly on tällä hetkellä suurin kaistanleveysmuistin ostaja, joten jos Googlen algoritmi leikkaa muistitarvetta 6-kertaisesti, logiikka menee niin, että sirujen kysyntä laskee ja samoin siruvalmistajat. TechCrunch jopa turvautui "Pied Piper"-vertaukseen — HBO:n Silicon Valley -sarjan kuvitteellinen pakkaus-startup, joka lupasi kutistaa maailman datan. Osakkeet laskivat sen pelon varassa.
Tässä rauhallisempi näkemys, ja sellainen, jonka uutissykli enimmäkseen ohitti. Wells Fargo viittasi Jevonsin paradoksiin: kun jokin muuttuu halvemmaksi ja tehokkaammaksi, me yleensä kulutamme sitä kokonaisuudessaan enemmän, emme vähemmän. Halvempi tekoälymuisti tarkoittaa, että useammat sovellukset julkaisevat pitkän kontekstin ominaisuuksia, useammat tiimit ylläpitävät itse isompia RAG-indeksejä, ja enemmän inferenssiä tapahtuu, piste. Tehokkuushyödyillä on pitkä historia kokonaiskysynnän kasvattajana sen tappamisen sijaan.
Markkina hinnoitteli TurboQuantin kysynnän tappajaksi. Historia sanoo, että halvempi laskentateho tarkoittaa yleensä, että käytämme sitä vain enemmän.
Oliko lasku siis yli-tulkintaa? Todennäköisesti, ainakin lyhyellä aikavälillä. Tutkimuspaperi ei ole hetkellinen koko toimialan remontti. Markkina reagoi otsikkoon; todellinen käyttöönotto vie kvartaaleja, ja kysyntää indusoiva efekti voi hyvinkin peittää säästöt alleen.
Voiko TurboQuantia oikeasti käyttää jo tänään?
Kyllä, osittain. TurboQuantin virallinen Google-julkaisu on paperi ja algoritmi, ei valmis tuote. Mutta yhteisötoteutuksia on jo olemassa: TurboVec (RyanCodrai/turbovec, PyPI:ssä) vektorindekseille, ja AmesianX/TurboQuant llama.cpp:lle (noin 5,2-kertainen, tuella DeepSeek-V2/V3:lle ja GLM-4.7-Flashille MLA:n kautta). Ekosysteemi on nuori mutta käyttökelpoinen.
Jos haluat kokeilla vektorindeksipuolta, TurboVec on pip-komennon päässä:
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/turboquantKV-välimuistin puolelle paikallisissa malleissa AmesianX/TurboQuant-llama.cpp-toteutus on se, jota kannattaa seurata, erityisesti jos ajat DeepSeek- tai GLM-malleja, joissa on multi-head latent attention. Se sopii hyvin yhteen paikallisen LLM-setupin kanssa, koska pienempi KV-välimuisti tarkoittaa, että voit ajaa isompaa kontekstia samalla kortilla. Ja jos valitset, mitä avointa mallia sen kanssa ajat, meidän parhaiden avoimen lähdekoodin LLM-benchmarkit kattavat DeepSeek- ja GLM-perheet suoraan.
Rehellinen varaus: tämä on paperi nyt, ekosysteemi kypsymässä. Googlen virallinen toimitus on tutkimusta, ei tuettu tuote, jolla on SLA.
Rehellinen vastaus: TurboQuant on toimituskelpoista matematiikkaa, ei latauspainiketta. Vielä.
Onko TurboQuant hypeä vai todellinen juttu? Rehellinen arvio
TurboQuant on todellinen ja aidosti nerokas. Sen koulutusvapaa suunnittelu on todellinen läpimurto, ja KV-välimuistin voitto merkitsee eniten pitkän kontekstin työkuormille. Mutta se ei ole taikaa: se on yksi kvantointiedistysaskel monien joukossa, otsikon 31 Gt → 4 Gt kuuluu TurboVecille eikä Googlelle, ja osakepaniikki yli-tulkitsi tutkimustuloksen.
Meidän kokemuksemme mukaan inferenssin ja RAM-kustannusten säätämisessä asiakkaille ratkaiseva tekijä on kitka. Koulutusvapaus voittaa tässä isosti, koska hienosäätösykliä ei ole, koodikirjaa ei tarvitse ylläpitää, eikä mallia tarvitse leikellä. Sen voi pultata jo käytössä olevaan järjestelmään.
Mitä se muuttaa:
- Halvempi pitkän kontekstin inferenssi, missä muistikustannukset oikeasti kirpaisevat.
- Pienemmät itse ylläpidetyt RAG-indeksit, jotka mahtuvat halvemmalle laitteistolle.
- Pakkausvaihtoehto, jonka voi ottaa käyttöön kouluttamatta mitään uudelleen.
Mitä se ei muuta:
- Se ei tee paljon lyhyen kontekstin, pienten mallien työkuormille, joissa KV-välimuisti ei koskaan ollut pullonkaula.
- Se ei vanhenna olemassa olevaa kvantointiasi yhdessä yössä; se on lisä, ei korvaaja.
- Googlen virallinen julkaisu on yhä paperi, joten tuotantokelpoiset työkalut ovat toistaiseksi yhteisön vastuulla.
Jos yrität selvittää, mitä tämä tarkoittaa omalle inferenssi- tai RAM-laskullesi, juuri tuollaista kustannusmallinnusta me teemme asiakkaille Techsyllä. Ota ilmainen konsultaatio, jos haluat toisen silmäparin katsomaan sitä.
Tietoa kirjoittajasta
Mert Batur Gurbuz on Techsy.io:n perustajaosakas, missä tiimi toimittaa tekoälyagentteja, automaatiojärjestelmiä ja ääni-/SDR-putkia B2B-asiakkaille. Hän opiskelee University of Birminghamissa ja kirjoittaa LLM-työkalupinosta, jota Techsyn tiimi oikeasti käyttää tuotannossa. Yhdistä LinkedInissä.
Usein kysytyt kysymykset
Mikä on Google TurboQuant?
TurboQuant on Google Researchin koulutusvapaa vektorikvantointialgoritmi, julkaistu arXivissa numerolla 2504.19874 ja hyväksytty ICLR 2026 -konferenssiin. Se pakkaa LLM:n KV-välimuistin noin 6-kertaisesti, suunnilleen 3 bittiin arvoa kohden, lähes ilman tarkkuushäviötä. Koska se on datasta riippumaton, se toimii olemassa olevilla malleilla ilman hienosäätöä tai uudelleenkoulutusta.
Julkaisiko Google oikeasti TurboVecin?
Ei. TurboQuant on Googlen algoritmi. TurboVec on erillinen kolmannen osapuolen Rust- ja Python-kirjasto (RyanCodrai/turbovec), joka on rakennettu TurboQuantin päälle riippumattoman kehittäjän toimesta. Jotkut mediat virheellisesti kreditoivat Googlea TurboVecin julkaisusta, kun viraali 31 Gt → 4 Gt -benchmark levisi, mutta GitHub näyttää, että kyseessä on yhteisöprojekti.
Onko TurboQuant sama asia kuin TurboVec?
Ei. TurboQuant on pakkausalgoritmi, jonka Google julkaisi. TurboVec on yksi kirjasto, joka toteuttaa sen algoritmin vektorihakua varten. Toinen on matematiikkaa; toinen on työkalu, joka on rakennettu sen matematiikan avulla. Kuuluisa "31 Gt → 4 Gt, voittaa FAISSin" -tulos on TurboVecin, ei jotain mitä Google toimitti suoraan.
Menettääkö TurboQuant tarkkuutta?
Lähes nolla tarkkuushäviö on paperin otsikkoväite, jopa noin 3 bitillä arvoa kohden. Algoritmi saavuttaa lähes optimaalisen vääristymän (lähellä Shannonin rajaa) pyörittämällä vektorit satunnaisesti ennen kvantointia, jotta mikään yksittäinen ulottuvuus ei dominoi. Käytännössä se tarkoittaa, että laadun pudotus on tarpeeksi pieni ollakseen merkityksetön useimmille työkuormille.
Kuinka paljon RAM-muistia TurboQuant säästää?
Noin 6-kertaisesti KV-välimuistissa, pudottaen sen suunnilleen 3 bittiin arvoa kohden. Vektori-indeksin puolella TurboVec demosi 10 miljoonan dokumentin indeksin kutistumista 31 gigatavusta noin 4:ään, jopa 92 % muistileikkaus. Todelliset säästösi riippuvat tarkkuuden lähtötasostasi ja siitä, pakkaatko KV-välimuistia, upotuksia vai molempia.
Onko tämä vain hypeä, miksi muistiosakkeet laskivat?
Kyseessä on todellinen edistysaskel, mutta paniikki yli-tulkitsi tutkimustuloksen. Micron, Western Digital ja Seagate laskivat pelossa, että halvempi tekoälymuisti leikkaa sirujen kysyntää. Wells Fargo vastasi Jevonsin paradoksilla: halvempi, tehokkaampi muisti lisää yleensä kokonaiskäyttöä. Paperi ei myöskään ole hetkellinen toimialan remontti, joten lyhyen aikavälin reaktio näyttää liioitellulta.
Voiko TurboQuantia käyttää jo tänään?
Osittain. Googlen virallinen julkaisu on paperi ja algoritmi, ei tuote. Yhteisötoteutuksia on jo olemassa: TurboVec PyPI:ssä vektorindekseille, AmesianX/TurboQuant llama.cpp:lle (DeepSeek-V2/V3 ja GLM-4.7-Flash MLA:n kautta), ja yashkc2025/turboquant Python-viitetoteutuksena. Ekosysteemi on nuori mutta jo käyttökelpoinen.
Miten TurboQuant eroaa kvantoinnista, jota jo teen?
Useimmat kvantointimenetelmät tutkivat otoksen datastasi rakentaakseen sovitettua koodikirjaa. TurboQuant on koulutusvapaa ja datasta riippumaton, joten se saavuttaa suhteensa katsomatta koskaan jakaumaasi. Se kohdistuu myös nimenomaan KV-välimuistiin ja vektori-indekseihin lähes optimaalisella vääristymällä, eikä vain pakkaa mallin painoja.
Toimiiko TurboQuant DeepSeekin tai llama.cpp:n kanssa?
Kyllä, AmesianX/TurboQuant-llama.cpp-toteutuksen kautta, joka raportoi noin 5,2-kertaisesta pakkauksesta ja tukee DeepSeek-V2/V3:a ja GLM-4.7-Flashia multi-head latent attentionin (MLA) kautta. Se tekee siitä käytännöllisen vaihtoehdon, jos ylläpidät itse noita malleja ja haluat pienemmän KV-välimuistin pidempiä konteksteja varten samalla laitteistolla.
Milloin TurboQuant oikeasti auttaa eniten?
Se auttaa eniten pitkän kontekstin inferenssissä ja suurissa itse ylläpidetyissä RAG-indekseissä, joissa muisti on todellinen pullonkaula. 6-kertainen KV-välimuistin pienennys tarkoittaa enemmän samanaikaisia 128k-kontekstin istuntoja per GPU, ja pakattu upotusindeksi mahtuu halvemmille instansseille. Se auttaa vähiten lyhyen kontekstin keskusteluissa ja pienissä malleissa, joissa KV-välimuisti ei koskaan ollut kustannustekijäsi.