TurboQuant od Google właśnie zmniejszył indeks AI z 31 GB do 4 GB — co to naprawdę oznacza

TurboQuant od Google właśnie zmniejszył indeks AI z 31 GB do 4 GB — co to naprawdę oznacza

Z 31 GB do 4 GB. To właśnie ta liczba zabrała w czerwcu 2026 roku kilka procent z kursu Microna i sprawiła, że połowa deweloperskiego Twittera wpadła w panikę, czy ich rachunki za RAG właśnie się nie zawaliły. Matematyka pod spodem jest prawdziwa: TurboQuant od Google (arXiv 2504.19874, przyjęty na ICLR 2026) kompresuje pamięć LLM-a mniej więcej 6x, do około 3 bitów na wartość, przy niemal zerowej utracie dokładności. Ale większość artykułów pomyliła się w jednej kwestii — a to zmienia sposób, w jaki powinno się czytać całą tę historię.

Opowieść o kompresji pamięci AI Google TurboQuant to tak naprawdę dwie historie w tej samej bluzie z kapturem. Rozplączmy je.

Najważniejsze wnioski

• TurboQuant to niewymagający trenowania algorytm kompresji od Google: redukcja KV-cache o ~6x do ~3 bitów, niemal zerowa utrata dokładności (ICLR 2026).
• TurboVec to osobna, zewnętrzna biblioteka w Ruście implementująca TurboQuant. Google jej nie wydało.
• Wiralowe demo „31GB → 4GB, lepsze niż FAISS" należy do TurboVec, a nie do surowego TurboQuant.
• Prawdziwa korzyść dla dewelopera to tańsza inferencja długiego kontekstu i mniejsze indeksy RAG, ale oficjalne wydanie Google to artykuł naukowy, nie produkt.

Czym jest TurboQuant od Google, mówiąc po ludzku?

TurboQuant to niewymagający trenowania, niezależny od danych algorytm kwantyzacji wektorowej od Google Research. Kompresuje KV cache LLM-a około 6x, do mniej więcej 3 bitów na wartość, przy niemal zerowej utracie dokładności. Został opublikowany w arXiv 2504.19874 i przyjęty na ICLR 2026. „Niewymagający trenowania" oznacza, że działa na istniejących modelach prosto z pudełka, bez konieczności dostrajania.

Co więc właściwie jest kompresowane? Głównie dwie rzeczy.

Po pierwsze, KV cache. Gdy model czyta Twoją rozmowę, przechowuje bieżące podsumowanie wszystkiego do tej pory, zwane pamięcią podręczną kluczy i wartości (key-value cache). Pomyśl o tym jak o krótkotrwałej pamięci modelu. Im dłuższe okno kontekstu, tym więcej tej pamięci musi utrzymywać — i tym więcej RAM-u GPU pożera. Czat na 128 tys. tokenów może rozdymać KV cache do wielu gigabajtów. Dlatego serwowanie długiego kontekstu szybko staje się drogie i dlatego cache'owanie promptów w celu obniżenia kosztów API w ogóle stało się tematem.

Po drugie, indeksy wektorowe. Embeddingi zasilające wyszukiwanie semantyczne i RAG to duże tablice liczb zmiennoprzecinkowych. Przechowuj miliony z nich w pełnej precyzji, a patrzysz na dziesiątki gigabajtów RAM-u.

TurboQuant zmniejsza oba. I tu jest fajna część: nie potrzebuje do tego żadnych Twoich danych. Większość schematów kwantyzacji najpierw bada próbkę Twoich wektorów, a potem buduje dopasowany do nich słownik kodowy. TurboQuant to pomija. Jest niezależny od danych, co znaczy, że osiąga swój współczynnik kompresji, nigdy nie zaglądając do Twojego rozkładu.

Prawdziwa sztuczka TurboQuant to nie współczynnik kompresji. To fakt, że do jego osiągnięcia potrzebuje zera danych treningowych.

To jest właśnie prawdziwy przełom. Możesz wycelować go w model, który już uruchamiasz, i natychmiast uzyskać oszczędności.

TurboQuant kontra TurboVec: zamieszanie, które wszyscy źle rozumieją

TurboQuant to algorytm kompresji od Google (arXiv 2504.19874, ICLR 2026). TurboVec to osobna, zewnętrzna biblioteka w Ruście i Pythonie (RyanCodrai/turbovec), która implementuje TurboQuant na potrzeby wyszukiwania wektorowego. Google nie wydało TurboVec. Wiralowy wynik „31GB → 4GB, lepsze niż FAISS" należy do TurboVec, a nie do surowego TurboQuant. Jeśli masz zapamiętać z tego wpisu jedną rzecz, niech to będzie właśnie to.

Oto, gdzie zrobiło się niechlujnie. Gdy benchmark 31GB→4GB stał się wiralowy na początku czerwca 2026 roku, kilka serwisów (w tym Tech Startups) puściło nagłówki twierdzące, że Google „wydało TurboVec". To nie to, co się wydarzyło. Sprawdź źródło: TurboVec znajduje się pod adresem RyanCodrai/turbovec na GitHubie i w PyPI. To biblioteka open source zbudowana przez dewelopera o imieniu Ryan Codrai. MarkTechPost ujął to trafnie, opisując ją jako „indeks wektorowy w Ruście z bindingami Pythona, zbudowany na algorytmie TurboQuant od Google".

Relacja jest więc prosta: Google opublikowało matematykę, a społeczność zbudowała na niej narzędzia. TurboVec jest najbardziej widocznym z tych narzędzi.

Google zbudowało algorytm. Deweloper o imieniu Ryan Codrai zbudował bibliotekę, której zrzuty ekranu krążą wszędzie. To nie jest to samo.

Jeśli zastanawiasz się, gdzie indeks oparty na TurboQuant pasuje obok Twojej obecnej konfiguracji, nasze zestawienie najlepszych baz wektorowych w 2026 roku stawia FAISS, Qdrant i nowsze skompresowane indeksy obok siebie.

Jak TurboQuant kompresuje pamięć, nie niszcząc dokładności?

TurboQuant wykorzystuje losową rotację oraz schemat kwantyzacji we współrzędnych biegunowych (PolarQuant) i projekcję w stylu Johnsona-Lindenstraussa (QJL, Quantized Johnson-Lindenstrauss), aby równomiernie rozłożyć wartości przed kwantyzacją. To niemal optymalne zniekształcenie pozwala mu zejść do około 3 bitów na wartość przy niemal nienaruszonej dokładności, bez konieczności ponownego trenowania modelu.

Rozpakujmy to, bo żargon ukrywa całkiem intuicyjną ideę.

Kiedy kwantyzujesz, zaokrąglasz liczby do mniejszej liczby bitów. Niebezpieczeństwo polega na tym, że niektóre wymiary wektora niosą znacznie większy ciężar niż inne, więc nieudolne ich zaokrąglenie niszczy wynik. Rozwiązaniem TurboQuant jest najpierw losowo obrócić wektor. Wyobraź sobie równomierne przetasowanie talii przed rozdaniem, żeby żadna ręka nie wyszła krzywa. Po rotacji wartości są rozłożone tak, że żaden pojedynczy wymiar nie dominuje, a zaokrąglanie boli znacznie mniej.

To jest właśnie część QJL: losowa projekcja, która wszystko ze sobą miesza, zachowując jednocześnie odległości. PolarQuant (zaprezentowany na AISTATS 2026) następnie kwantyzuje obrócone wartości we współrzędnych biegunowych, co lepiej pasuje do ich rozkładu niż zwykłe zaokrąglanie siatkowe.

Wypłatą jest to, co artykuł nazywa niemal optymalnym zniekształceniem, co oznacza, że zbliża się do teoretycznej granicy Shannona określającej, jak mało jakości można stracić przy danym budżecie bitów. Mówiąc po ludzku: dla 3 bitów na wartość zasadniczo nie da się zrobić dużo lepiej, a TurboQuant dochodzi tam bez badania Twoich danych.

Po pełny mechanizm blog Google Research i artykuł w arXiv to źródła pierwotne. InfoQ ma też czyste zorientowane na deweloperów omówienie wątku KV-cache, jeśli chcesz perspektywy praktyka.

Co właściwie oznacza 31GB → 4GB dla Twojego rachunku za RAM?

Indeks RAG na 10 mln wektorów, który w pełnej precyzji potrzebuje ~31 GB RAM-u, spada do mniej więcej ~4 GB dzięki kompresji TurboVec opartej na TurboQuant — na tyle mało, by zmieścić się na zwykłej instancji zamiast na warstwie o dużej pamięci. Dla KV cache redukcja o ~6x oznacza mniej więcej 6x więcej równoczesnych sesji długiego kontekstu na tym samym GPU. To jest ta część, która faktycznie pojawia się na fakturze.

Policzyliśmy liczby, których konkurencja nie policzyła. Najpierw krótka uwaga o uczciwości: wszystko poniżej jest szacowane i modelowane (czerwiec 2026) na podstawie publicznych cen chmury i współczynników podanych w artykule. Nie uruchamialiśmy TurboVec w produkcji, więc traktuj to jako matematykę, a nie benchmark, który fizycznie zmierzyliśmy. Warstwy cenowe opierają się na tej samej podstawie, której używamy w naszym przewodniku po obniżaniu kosztów API LLM.

Oto indeks embeddingów na 10 mln dokumentów, pełna precyzja kontra kompresja TurboVec, zmapowany na warstwę RAM w chmurze, której faktycznie byś potrzebował:

Przeskok z maszyny zoptymalizowanej pod pamięć na małą maszynę ogólnego przeznaczenia to cała historia. Dla samodzielnie hostowanego indeksu to często różnica między rachunkiem, przy którym się krzywisz, a takim, którego ledwie zauważasz. Jeśli budujesz potok, który na tym stoi, nasz przewodnik po budowaniu aplikacji RAG obejmuje miejsce, w którym żyje ten indeks.

Teraz strona KV-cache, modelowana przy stałym GPU 24GB serwującym sesje o kontekście 128 tys.:

Redukcja KV-cache o 6x nie tylko oszczędza RAM. Potrafi zamienić jedno GPU w sześć dla serwowania długiego kontekstu.

Dlatego ma to większe znaczenie dla obciążeń długiego kontekstu niż dla czegokolwiek innego. Jeśli serwujesz dużo krótkich czatów, Twój KV cache nigdy nie był wąskim gardłem. Jeśli uruchamiasz agentów na 128 tys. tokenów lub analizę dokumentów, redukcja o 6x zmienia ekonomię na GPU z dnia na dzień. Relacja VentureBeat umieszcza górny pułap zysku przepustowości na poziomie do 8x na H100 przy oszczędności kosztów ponad 50%, co zgadza się z naszą modelowaną matematyką współbieżności.

Dlaczego akcje producentów pamięci spadły i czy Wall Street przesadziło?

Po ujawnieniu TurboQuant akcje Microna, Western Digital i Seagate spadły w obawie, że radykalnie tańsza pamięć AI skurczy przyszły popyt na DRAM i HBM — w ramach tak zwanego ujęcia „momentu DeepSeek". Analitycy, w tym Wells Fargo, argumentowali coś przeciwnego: tańsza pamięć napędza większe całkowite użycie, a nie mniejsze, poprzez paradoks Jevonsa.

Narracja napisała się sama. AI jest obecnie największym nabywcą pamięci o wysokiej przepustowości, więc jeśli algorytm Google tnie zapotrzebowanie na pamięć 6x, to — jak głosi logika — popyt na chipy spada, a wraz z nim producenci chipów. TechCrunch sięgnął nawet po porównanie do „Pied Pipera", fikcyjnego startupu kompresyjnego z serialu HBO Dolina Krzemowa, który obiecywał skompresować dane całego świata. Akcje spadły właśnie na tej obawie.

Oto spokojniejsze spojrzenie — takie, które cykl newsowy w większości pominął. Wells Fargo wskazało na paradoks Jevonsa: gdy coś staje się tańsze i bardziej wydajne, zwykle konsumujemy tego ogółem więcej, a nie mniej. Tańsza pamięć AI oznacza, że więcej aplikacji wdraża funkcje długiego kontekstu, więcej zespołów samodzielnie hostuje większe indeksy RAG i generalnie dzieje się więcej inferencji. Zyski wydajności mają długą historię zwiększania całkowitego popytu zamiast jego zabijania.

Rynek wycenił TurboQuant jako zabójcę popytu. Historia mówi, że tańsze obliczenia zwykle oznaczają po prostu, że używamy ich więcej.

Czy więc spadek był nadinterpretacją? Prawdopodobnie, przynajmniej w krótkim terminie. Artykuł naukowy to nie natychmiastowa modernizacja całej branży. Rynek zareagował na nagłówek; faktyczne wdrożenie zajmie kwartały, a efekt indukowania popytu może z nawiązką przykryć oszczędności.

Czy faktycznie można dziś używać TurboQuant?

Tak, częściowo. Oficjalne wydanie TurboQuant od Google to artykuł i algorytm, a nie gotowy produkt do wdrożenia. Ale implementacje społeczności już istnieją: TurboVec (RyanCodrai/turbovec, w PyPI) dla indeksów wektorowych oraz AmesianX/TurboQuant dla llama.cpp (około 5,2x, ze wsparciem dla DeepSeek-V2/V3 i GLM-4.7-Flash poprzez MLA). Ekosystem jest młody, ale używalny.

Jeśli chcesz wypróbować stronę indeksów wektorowych, TurboVec jest o jedno pip od Ciebie:

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

Dla strony KV-cache w modelach lokalnych, implementacja llama.cpp od AmesianX/TurboQuant to ta, którą warto śledzić, szczególnie jeśli uruchamiasz modele DeepSeek lub GLM z uwagą utajoną wielu głowic. Dobrze komponuje się z lokalną konfiguracją LLM, ponieważ mniejszy KV cache oznacza, że możesz wycisnąć większy kontekst na tej samej karcie. A jeśli wybierasz, który otwarty model przeciwko temu uruchomić, nasze benchmarki najlepszych LLM-ów open source obejmują bezpośrednio rodziny DeepSeek i GLM.

Uczciwe zastrzeżenie: to stan „artykuł teraz, ekosystem dojrzewa". Oficjalny produkt Google to badania, a nie wspierany produkt z SLA.

Uczciwa odpowiedź: TurboQuant to matematyka gotowa do wdrożenia, a nie przycisk do pobrania. Jeszcze.

TurboQuant to hype czy prawdziwa sprawa? Uczciwy werdykt

TurboQuant jest prawdziwy i naprawdę sprytny. Jego niewymagający trenowania design to prawdziwy przełom, a wygrana na KV-cache ma największe znaczenie dla obciążeń długiego kontekstu. Ale to nie magia: to jeden z wielu postępów w kwantyzacji, nagłówek 31GB→4GB należy do TurboVec, a nie do Google, a giełdowa panika nadinterpretowała wynik badań.

Z naszego doświadczenia w dostrajaniu kosztów inferencji i RAM-u dla klientów wynika, że o tym, czy warto adoptować taką technikę, decyduje tarcie. Niewymagający trenowania design wygrywa tu wyraźnie, bo nie ma cyklu dostrajania, nie ma słownika kodowego do utrzymania, nie ma operacji na modelu. Możesz to doczepić do czegoś, co już uruchamiasz.

Co to zmienia:

• Tańsza inferencja długiego kontekstu, czyli tam, gdzie koszt pamięci faktycznie boli.
• Mniejsze samodzielnie hostowane indeksy RAG, które mieszczą się na tańszym sprzęcie.
• Opcja kompresji, którą można zaadoptować bez trenowania czegokolwiek.

Czego to nie zmienia:

• Niewiele pomoże obciążeniom krótkiego kontekstu i małych modeli, gdzie KV cache nigdy nie był wąskim gardłem.
• Nie dezaktualizuje z dnia na dzień Twojej obecnej kwantyzacji; to dodatek, nie zamiennik.
• Oficjalne wydanie Google to wciąż artykuł naukowy, więc narzędzia klasy produkcyjnej na razie leżą po stronie społeczności.

Jeśli próbujesz ustalić, co to oznacza dla Twojego własnego rachunku za inferencję lub RAM, to dokładnie ten rodzaj modelowania kosztów, które robimy dla klientów w Techsy. Umów się na bezpłatną konsultację, jeśli chcesz, żeby ktoś drugi rzucił na to okiem.

O autorze

Mert Batur Gurbuz jest współzałożycielem Techsy.io, gdzie zespół dostarcza agentów AI, systemy automatyzacji i potoki głosowe/SDR dla klientów B2B. Studiuje na University of Birmingham i pisze o stosie narzędzi LLM, którego zespół Techsy faktycznie używa w produkcji. Połącz się na LinkedIn.

Często zadawane pytania

Czym jest Google TurboQuant?

TurboQuant to niewymagający trenowania algorytm kwantyzacji wektorowej od Google Research, opublikowany w arXiv 2504.19874 i przyjęty na ICLR 2026. Kompresuje KV cache LLM-a około 6x, do mniej więcej 3 bitów na wartość, przy niemal zerowej utracie dokładności. Ponieważ jest niezależny od danych, działa na istniejących modelach bez żadnego dostrajania czy ponownego trenowania.

Czy Google faktycznie wydało TurboVec?

Nie. TurboQuant to algorytm Google. TurboVec to osobna, zewnętrzna biblioteka w Ruście i Pythonie (RyanCodrai/turbovec), zbudowana na bazie TurboQuant przez niezależnego dewelopera. Niektóre serwisy błędnie przypisały Google wydanie TurboVec, gdy wiralowy benchmark 31GB→4GB stał się popularny, ale GitHub pokazuje, że to projekt społeczności.

Czy TurboQuant to to samo co TurboVec?

Nie. TurboQuant to algorytm kompresji opublikowany przez Google. TurboVec to jedna z bibliotek implementujących ten algorytm dla wyszukiwania wektorowego. Jedno to matematyka; drugie to narzędzie zbudowane na tej matematyce. Słynny wynik „31GB → 4GB, lepsze niż FAISS" należy do TurboVec, a nie do czegoś, co Google dostarczyło bezpośrednio.

Czy TurboQuant traci dokładność?

Niemal zerowa utrata dokładności to główna teza artykułu, nawet przy około 3 bitach na wartość. Algorytm osiąga niemal optymalne zniekształcenie (bliskie granicy Shannona) poprzez losową rotację wektorów przed kwantyzacją, dzięki czemu żaden pojedynczy wymiar nie dominuje. W praktyce oznacza to, że spadek jakości jest na tyle mały, by był pomijalny dla większości obciążeń.

Ile RAM-u oszczędza TurboQuant?

Około 6x na KV cache, sprowadzając go do mniej więcej 3 bitów na wartość. Po stronie indeksów wektorowych TurboVec zademonstrował indeks 10 mln dokumentów kurczący się z 31 GB do około 4 GB, czyli do 92% redukcji pamięci. Twoje faktyczne oszczędności zależą od bazowej precyzji i od tego, czy kompresujesz KV cache, embeddingi, czy oba.

Czy to tylko hype, dlaczego akcje producentów pamięci spadły?

To realny postęp, ale panika nadinterpretowała wynik badań. Micron, Western Digital i Seagate spadły w obawie, że tańsza pamięć AI obetnie popyt na chipy. Wells Fargo skontrowało paradoksem Jevonsa: tańsza, bardziej wydajna pamięć zwykle zwiększa całkowite użycie. Artykuł naukowy to też nie natychmiastowa modernizacja branży, więc krótkoterminowa reakcja wygląda na przesadzoną.

Czy mogę dziś używać TurboQuant?

Częściowo. Oficjalne wydanie Google to artykuł i algorytm, nie produkt. Implementacje społeczności istnieją już teraz: TurboVec w PyPI dla indeksów wektorowych, AmesianX/TurboQuant dla llama.cpp (DeepSeek-V2/V3 i GLM-4.7-Flash poprzez MLA) oraz yashkc2025/turboquant jako referencja w Pythonie. Ekosystem jest młody, ale już używalny.

Czym TurboQuant różni się od kwantyzacji, którą już robię?

Większość kwantyzacji bada próbkę Twoich danych, by zbudować dostrojony słownik kodowy. TurboQuant jest niewymagający trenowania i niezależny od danych, więc osiąga swój współczynnik, nigdy nie zaglądając do Twojego rozkładu. Celuje też konkretnie w KV cache i indeksy wektorowe, z niemal optymalnym zniekształceniem, zamiast tylko kompresować wagi modelu.

Czy TurboQuant działa z DeepSeek lub llama.cpp?

Tak, poprzez implementację llama.cpp od AmesianX/TurboQuant, która raportuje około 5,2x kompresji i wspiera DeepSeek-V2/V3 oraz GLM-4.7-Flash poprzez uwagę utajoną wielu głowic (MLA). Czyni to ją praktyczną opcją, jeśli samodzielnie hostujesz te modele i chcesz mniejszego KV cache dla dłuższych kontekstów na tym samym sprzęcie.

Kiedy TurboQuant faktycznie pomaga najbardziej?

Pomaga najbardziej przy inferencji długiego kontekstu i dużych samodzielnie hostowanych indeksach RAG, gdzie pamięć jest prawdziwym wąskim gardłem. Redukcja KV-cache o 6x oznacza więcej równoczesnych sesji o kontekście 128 tys. na GPU, a skompresowany indeks embeddingów mieści się na tańszych instancjach. Pomaga najmniej przy czatach krótkiego kontekstu i małych modelach, gdzie KV cache nigdy nie był Twoim czynnikiem kosztowym.