Google TurboQuant щойно стиснув 31 ГБ AI-індексу до 4 ГБ — що це насправді означає

Google TurboQuant щойно стиснув 31 ГБ AI-індексу до 4 ГБ — що це насправді означає

31 ГБ до 4 ГБ. Саме ця цифра у червні 2026 року зняла кілька відсотків з акцій Micron і змусила половину розробницького Twitter панікувати, чи не обвалилися їхні рахунки за RAG. Математика під цим реальна: Google TurboQuant (arXiv 2504.19874, прийнято на ICLR 2026) стискає пам'ять LLM приблизно у 6 разів до близько 3 біт на значення з майже нульовою втратою точності. Але більшість статей помилилися в одному, і це змінює те, як варто читати всю історію.

Історія про стиснення AI-пам'яті Google TurboQuant — це насправді дві історії в одній худі. Розплутаємо їх.

Ключові висновки

• TurboQuant — це алгоритм стиснення від Google, що не потребує навчання: ~6x зменшення KV-кешу до ~3 біт, майже нульова втрата точності (ICLR 2026).
• TurboVec — це окрема стороння бібліотека на Rust, яка реалізує TurboQuant. Google її не випускав.
• Вірусне демо «31 ГБ → 4 ГБ, швидше за FAISS» — це TurboVec, а не сирий TurboQuant.
• Реальний виграш для розробника — дешевший інференс довгого контексту й менші RAG-індекси, але офіційний реліз Google — це стаття, а не продукт.

Що таке Google TurboQuant простою мовою?

TurboQuant — це алгоритм векторного квантування від Google Research, який не потребує навчання й не залежить від даних. Він стискає KV-кеш LLM приблизно у 6 разів, до близько 3 біт на значення, з майже нульовою втратою точності. Опубліковано в arXiv 2504.19874 і прийнято на ICLR 2026. «Без навчання» означає, що він працює з наявними моделями з коробки, без донавчання.

То що саме стискається? Переважно дві речі.

По-перше, KV-кеш. Коли модель читає вашу розмову, вона зберігає поточне резюме всього сказаного — так званий кеш ключів і значень. Уявіть його як короткострокову пам'ять моделі. Чим довше ваше контекстне вікно, тим більше цієї пам'яті вона тримає і тим більше GPU RAM з'їдає. Чат на 128k токенів може роздути KV-кеш до багатьох гігабайт. Тому обслуговування довгого контексту швидко дорожчає, і тому кешування промптів для зменшення витрат на API взагалі з'явилося.

По-друге, векторні індекси. Ембедінги, що живлять семантичний пошук і RAG, — це великі масиви чисел з рухомою комою. Зберігайте мільйони з них у повній точності — і ви дивитесь на десятки гігабайт RAM.

TurboQuant стискає обидва. Ось що круто: для цього йому не потрібні ваші дані. Більшість схем квантування спочатку вивчають вибірку ваших векторів, а потім будують кодову книгу, налаштовану під них. TurboQuant це пропускає. Він не залежить від даних, тобто досягає свого ступеня стиснення, жодного разу не глянувши на ваш розподіл.

Справжній трюк TurboQuant — не ступінь стиснення. А те, що для нього потрібно нуль навчальних даних.

Ось де справжній прорив. Ви можете націлити його на модель, яку вже використовуєте, і отримати економію одразу.

TurboQuant проти TurboVec: плутанина, в якій усі помиляються

TurboQuant — це алгоритм стиснення від Google (arXiv 2504.19874, ICLR 2026). TurboVec — це окрема стороння бібліотека на Rust і Python (RyanCodrai/turbovec), яка реалізує TurboQuant для векторного пошуку. Google не випускав TurboVec. Вірусний результат «31 ГБ → 4 ГБ, швидше за FAISS» належить TurboVec, а не сирий TurboQuant. Якщо запам'ятаєте одну річ з цього посту — нехай це буде вона.

Ось де стало брудно. Коли бенчмарк 31 ГБ→4 ГБ став вірусним на початку червня 2026 року, кілька видань (зокрема Tech Startups) опублікували заголовки, що Google «випустив TurboVec». Це не те, що сталося. Перевірте джерело: TurboVec живе на RyanCodrai/turbovec у GitHub і PyPI. Це бібліотека з відкритим кодом, створена розробником на ім'я Ryan Codrai. MarkTechPost правильно сформулював, описавши це як «векторний індекс на Rust із Python-прив'язками, побудований на алгоритмі Google TurboQuant».

Тож зв'язок простий: Google опублікував математику, а спільнота побудувала інструменти на ній. TurboVec — найпомітніший із цих інструментів.

Google створив алгоритм. Розробник на ім'я Ryan Codrai створив бібліотеку, скріншоти якої всі публікують. Це не одне й те саме.

Якщо ви зважуєте, де індекс на основі TurboQuant впишеться поруч із вашим поточним сетапом, наш огляд найкращих векторних баз даних 2026 року порівнює FAISS, Qdrant і новіші стиснені індекси пліч-о-пліч.

Як TurboQuant стискає пам'ять, не руйнуючи точність?

TurboQuant використовує випадкове обертання плюс схему квантування в полярних координатах (PolarQuant) і проєкцію в стилі Джонсона-Лінденштрауса (QJL, Quantized Johnson-Lindenstrauss), щоб рівномірно розподілити значення перед квантуванням. Саме це майже оптимальне спотворення дозволяє опуститися до приблизно 3 біт на значення, зберігаючи точність майже недоторканою, без перенавчання моделі.

Розберу це, бо жаргон приховує досить інтуїтивну ідею.

Коли ви квантуєте, ви округлюєте числа до меншої кількості біт. Небезпека в тому, що деякі виміри вектора несуть набагато більшу вагу, ніж інші, тому незграбне округлення руйнує результат. Виправлення TurboQuant — спочатку випадково обернути вектор. Уявіть, що ви тасуєте колоду перед роздачею, щоб жодна рука не виявилася перекошеною. Після обертання значення розподілені так, що жоден вимір не домінує, і округлення шкодить набагато менше.

Це і є частина QJL: випадкова проєкція, яка змішує все, зберігаючи відстані. PolarQuant (представлено на AISTATS 2026) потім квантує обернені значення в полярних координатах, що краще відповідає їхньому розподілу, ніж звичайне округлення по сітці.

Виграш — це те, що стаття називає майже оптимальним спотворенням, тобто воно наближається до теоретичної межі Шеннона щодо того, як мало якості можна втратити при заданому бітовому бюджеті. Простою мовою: для 3 біт на значення краще майже не зробити, і TurboQuant досягає цього, не вивчаючи ваші дані.

Для повного механізму блог Google Research і стаття на arXiv — першоджерела. InfoQ також має чистий розбір для розробників під кутом KV-кешу, якщо хочете практичну рамку.

Що 31 ГБ → 4 ГБ насправді означає для вашого рахунку за RAM?

RAG-індекс на 10 млн векторів, який потребує ~31 ГБ RAM у повній точності, падає до приблизно ~4 ГБ зі стисненням TurboVec на основі TurboQuant — достатньо мало, щоб вміститися на звичайному інстансі замість тарифу з великою пам'яттю. Для KV-кешу зменшення у ~6 разів означає приблизно у 6 разів більше одночасних сесій довгого контексту на тому самому GPU. Саме ця частина реально з'являється у рахунку.

Ми порахували цифри, які конкуренти не порахували. Спершу коротка нотатка про чесність: усе нижче — оцінки та моделювання (червень 2026) на основі публічних хмарних цін і заявлених у статті коефіцієнтів. Ми не запускали TurboVec у продакшені, тож сприймайте це як математику, а не бенчмарк, який ми фізично виміряли. Тарифні рівні використовують ту саму базу, що й наш гайд зі зменшення витрат на LLM API.

Ось індекс ембедінгів на 10 млн документів, повна точність проти стиснення TurboVec, прив'язаний до хмарного тарифу RAM, який вам реально знадобиться:

Перехід з машини з оптимізацією під пам'ять на невелику машину загального призначення — це вся історія. Для самостійно розміщеного індексу це часто різниця між рахунком, від якого морщишся, і тим, якого майже не помічаєш. Якщо ви будуєте пайплайн, який працює поверх нього, наш покроковий гайд зі створення RAG-застосунку пояснює, де живе цей індекс.

Тепер бік KV-кешу, змодельований на фіксованому 24 ГБ GPU, що обслуговує сесії зі 128k контекстом:

Зменшення KV-кешу у 6 разів не просто економить RAM. Воно може перетворити один GPU на шість для обслуговування довгого контексту.

Тому це важливіше для навантажень із довгим контекстом, ніж для будь-чого іншого. Якщо ви обслуговуєте багато коротких чатів, ваш KV-кеш ніколи не був вузьким місцем. Якщо ви запускаєте агенти на 128k токенів або аналіз документів, зменшення у 6 разів змінює економіку на GPU за ніч. Репортаж VentureBeat оцінює верхню межу приросту пропускної здатності до 8x на H100 із економією витрат 50%+, що узгоджується з нашою моделлю конкурентності.

Чому акції виробників пам'яті впали, чи Волл-стріт перереагувала?

Після презентації TurboQuant акції Micron, Western Digital і Seagate впали на страхах, що радикально дешевша AI-пам'ять скоротить майбутній попит на DRAM і HBM — так звана рамка «момент DeepSeek». Аналітики, зокрема Wells Fargo, аргументували протилежне: дешевша пам'ять стимулює більше загальне використання, а не менше, через парадокс Джевонса.

Наратив написався сам. AI зараз найбільший покупець високопропускної пам'яті, тож якщо алгоритм Google скорочує потребу в пам'яті у 6 разів, логіка така: попит на чіпи падає, а з ним і виробники чіпів. TechCrunch навіть потягнувся до порівняння з «Pied Piper» — вигаданим стартапом стиснення з серіалу Silicon Valley на HBO, який обіцяв стиснути дані світу. Акції впали на цьому страху.

Ось спокійніший погляд, і новинний цикл його переважно пропустив. Wells Fargo вказав на парадокс Джевонса: коли щось стає дешевшим і ефективнішим, ми зазвичай споживаємо більше цього загалом, а не менше. Дешевша AI-пам'ять означає, що більше застосунків випускають функції довгого контексту, більше команд самостійно розміщують більші RAG-індекси, і більше інференсу відбувається, крапка. Покращення ефективності мають довгу історію зростання загального попиту, а не його вбивства.

Ринок оцінив TurboQuant як вбивцю попиту. Історія каже, що дешевші обчислення зазвичай означають, що ми просто використовуємо їх більше.

Тож чи було падіння надмірною реакцією? Ймовірно, принаймні короткостроково. Дослідницька стаття — не миттєва перебудова всієї галузі. Ринок відреагував на заголовок; реальне впровадження займе квартали, і ефект індукування попиту може цілком перекрити економію.

Чи можна реально використовувати TurboQuant сьогодні?

Так, частково. Офіційний реліз Google TurboQuant — це стаття й алгоритм, а не готовий продукт. Але реалізації спільноти вже існують: TurboVec (RyanCodrai/turbovec, у PyPI) для векторних індексів і AmesianX/TurboQuant для llama.cpp (приблизно 5.2x, з підтримкою DeepSeek-V2/V3 і GLM-4.7-Flash через MLA). Екосистема молода, але придатна до використання.

Якщо хочете спробувати бік векторного індексу, TurboVec — на відстані pip:

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

Для боку KV-кешу на локальних моделях реалізація llama.cpp AmesianX/TurboQuant — та, за якою варто стежити, особливо якщо ви запускаєте моделі DeepSeek або GLM з multi-head latent attention. Вона добре поєднується з налаштуванням локального LLM, бо менший KV-кеш означає, що ви можете розширити контекст на тій самій картці. А якщо обираєте, яку відкриту модель запустити, наші бенчмарки найкращих відкритих LLM покривають родини DeepSeek і GLM безпосередньо.

Чесне застереження: це «стаття зараз, екосистема дозріває». Офіційний результат Google — дослідження, а не підтримуваний продукт із SLA.

Чесна відповідь: TurboQuant — це математика, готова до відправки, а не кнопка завантаження. Поки що.

TurboQuant — хайп чи реальна річ? Чесний вердикт

TurboQuant реальний і справді розумний. Його дизайн без навчання — справжній прорив, а виграш у KV-кеші найважливіший для навантажень із довгим контекстом. Але це не магія: це один із багатьох кроків у квантуванні, заголовок 31 ГБ→4 ГБ належить TurboVec, а не Google, а біржова паніка перереагувала на дослідницький результат.

З нашого досвіду налаштування інференсу та витрат на RAM для клієнтів, річ, яка вирішує, чи варто впроваджувати таку техніку, — це тертя. Дизайн без навчання тут виграє по-великому, бо немає циклу донавчання, немає кодової книги для підтримки, немає хірургії моделі. Ви можете прикрутити це до того, що вже працює.

Що це змінює:

• Дешевший інференс довгого контексту, де вартість пам'яті реально болить.
• Менші самостійно розміщені RAG-індекси, які вміщуються на дешевшому заліззі.
• Варіант стиснення, який можна впровадити без перенавчання будь-чого.

Що це не змінює:

• Це мало що дасть для навантажень із коротким контекстом і малими моделями, де KV-кеш ніколи не був вузьким місцем.
• Це не робить ваше наявне квантування застарілим за ніч; це доповнення, а не заміна.
• Офіційний реліз Google — досі стаття, тож інструменти продакшн-рівня поки що на спільноті.

Якщо ви намагаєтеся зрозуміти, що це означає для вашого інференсу чи рахунку за RAM, це саме той тип моделювання витрат, який ми робимо для клієнтів у Techsy. Отримайте безкоштовну консультацію, якщо хочете другу пару очей на це.

Про автора

Mert Batur Gurbuz — співзасновник Techsy.io, де команда створює AI-агентів, системи автоматизації та голосові/SDR-пайплайни для B2B-клієнтів. Він навчається в Університеті Бірмінгема й пише про стек інструментів LLM, який команда Techsy реально використовує в продакшені. Підключайтеся в LinkedIn.

Часті запитання

Що таке Google TurboQuant?

TurboQuant — це алгоритм векторного квантування від Google Research, який не потребує навчання, опублікований в arXiv 2504.19874 і прийнятий на ICLR 2026. Він стискає KV-кеш LLM приблизно у 6 разів, до близько 3 біт на значення, з майже нульовою втратою точності. Оскільки він не залежить від даних, він працює з наявними моделями без будь-якого донавчання чи перенавчання.

Чи Google справді випустив TurboVec?

Ні. TurboQuant — це алгоритм Google. TurboVec — це окрема стороння бібліотека на Rust і Python (RyanCodrai/turbovec), побудована на основі TurboQuant незалежним розробником. Деякі видання помилково приписали Google випуск TurboVec, коли вірусний бенчмарк 31 ГБ→4 ГБ став вірусним, але GitHub показує, що це проєкт спільноти.

Чи TurboQuant те саме, що TurboVec?

Ні. TurboQuant — це алгоритм стиснення, який опублікував Google. TurboVec — одна з бібліотек, яка реалізує цей алгоритм для векторного пошуку. Одне — математика; інше — інструмент, побудований на цій математиці. Знаменитий результат «31 ГБ → 4 ГБ, швидше за FAISS» — це TurboVec, а не те, що Google випустив безпосередньо.

Чи TurboQuant втрачає точність?

Майже нульова втрата точності — головна заява зі статті, навіть при приблизно 3 бітах на значення. Алгоритм досягає майже оптимального спотворення (близького до межі Шеннона), випадково обертаючи вектори перед квантуванням, щоб жоден окремий вимір не домінував. На практиці це означає, що падіння якості достатньо мале, щоб бути нехтуваним для більшості навантажень.

Скільки RAM економить TurboQuant?

Приблизно у 6 разів на KV-кеші, зменшуючи його до приблизно 3 біт на значення. На боці векторного індексу TurboVec продемонстрував стиснення індексу на 10 млн документів з 31 ГБ до приблизно 4 ГБ, до 92% економії пам'яті. Ваша реальна економія залежить від базової точності та від того, чи стискаєте ви KV-кеш, ембедінги, чи обидва.

Це просто хайп, чому акції пам'яті впали?

Це реальний прогрес, але паніка перереагувала на дослідницький результат. Micron, Western Digital і Seagate впали на страхах, що дешевша AI-пам'ять скорочує попит на чіпи. Wells Fargo заперечив парадоксом Джевонса: дешевша, ефективніша пам'ять зазвичай збільшує загальне використання. Стаття також не є миттєвою перебудовою галузі, тож короткострокова реакція виглядає надмірною.

Чи можна використовувати TurboQuant сьогодні?

Частково. Офіційний реліз Google — це стаття й алгоритм, а не продукт. Реалізації спільноти вже існують: TurboVec у PyPI для векторних індексів, AmesianX/TurboQuant для llama.cpp (DeepSeek-V2/V3 і GLM-4.7-Flash через MLA) і yashkc2025/turboquant як Python-референс. Екосистема молода, але вже придатна до використання.

Чим TurboQuant відрізняється від квантування, яке я вже роблю?

Більшість квантувань вивчають вибірку ваших даних, щоб побудувати налаштовану кодову книгу. TurboQuant не потребує навчання й не залежить від даних, тож він досягає свого коефіцієнта, жодного разу не глянувши на ваш розподіл. Він також націлений конкретно на KV-кеш і векторні індекси, з майже оптимальним спотворенням, а не просто стискає ваги моделі.

Чи працює TurboQuant із DeepSeek або llama.cpp?

Так, через реалізацію llama.cpp AmesianX/TurboQuant, яка повідомляє про приблизно 5.2x стиснення й підтримує DeepSeek-V2/V3 і GLM-4.7-Flash через multi-head latent attention (MLA). Це робить її практичним варіантом, якщо ви самостійно розміщуєте ці моделі й хочете менший KV-кеш для довшого контексту на тому самому заліззі.

Коли TurboQuant реально допомагає найбільше?

Він допомагає найбільше з інференсом довгого контексту та великими самостійно розміщеними RAG-індексами, де пам'ять — справжнє вузьке місце. Зменшення KV-кешу у 6 разів означає більше одночасних сесій зі 128k контекстом на GPU, а стиснений індекс ембедінгів вміщується на дешевших інстансах. Він найменше допомагає для коротких чатів і малих моделей, де KV-кеш ніколи не був вашим драйвером витрат.