Разборы · Статья: · Видео: · 14:48
TurboQuant: как ужать память агентного поиска в 5 раз без потери качества
Разбор доклада Шаши Джагтапа из Super Agentic AI про TurboQuant — алгоритм Google, который хранит эмбеддинги в 3–4 битах вместо 32 и режет память retrieval впятеро, сохраняя качество поиска.
Смотреть на YouTube Turbocharge Your Agent's Retrieval with TurboQuant - Shashi Jagtap, Superagentic AI
AI Engineer · 14:48
Главы видео — нажми, чтобы перейти к моменту 9
- 0:00 Проблема: длинный контекст ломает агента С ростом контекста растёт KV-кэш (история диалога) и производительность деградирует — заметнее всего на своём железе.
- 1:30 Память как узкое горлышко локального агента На Mac модель, KV-кэш и векторный индекс дерутся за один общий пул RAM; KV-кэш может стать больше самой модели.
- 1:45 Эмбеддинги тратят впятеро больше нужного По умолчанию хранение в 32 битах, а поиску хватает 3–4 бит — отсюда пятикратный перерасход памяти на retrieval.
- 2:05 Что пробовали раньше Квантизация модели, компакция контекста, меньшие эмбеддинги, offload на CPU/диск — у каждого метода компромисс по качеству, скорости или железу.
- 2:57 Что такое TurboQuant Алгоритм Google с ICLR 2026: хранит эмбеддинги в 3–4 битах через PolarQuant (сжатие вектора) и QJL (исправление ошибки).
- 4:49 Ключевой сдвиг: поиску важна только близость Поиску всё равно, как выглядит вектор, — важно лишь, какой ближе к запросу. Значит, вектор можно жать агрессивно.
- 5:08 Три стадии и один параметр Перемешать данные, округлить по бакетам скалярной квантизацией, поправить остаток QJL одним битом. Вам достаётся только выбор битового бюджета.
- 6:37 Где встроено и как подключить Вкатывается в llama.cpp, MLX, Ollama, LM Studio; для агентов есть open-source Turbo Agent — меняете только слой ретривера.
- 8:28 Демо и альтернативы Baseline fp32 занял 8 КБ, TurboQuant — 1.6 КБ при том же ответе. Плюс сравнение с RabitQ и FP8.
Коротко
Эмбеддинги в поиске хранятся в полной 32-битной точности, хотя ранжированию хватает 3–4 бит, — отсюда пятикратный перерасход памяти. TurboQuant сжимает векторы до этих 3–4 бит без падения качества, и подключается он заменой одного слоя ретривера, не трогая ни агента, ни векторную базу.
Выжимка голосом
Самое ценное из разбора — за пару минут
Показать текст выжимки Скрыть текст выжимки
Озвучено синтезом речи · голос alena
Объясни проще
Суть без жаргона
Простыми словами
Когда агент долго общается или роется в большой базе знаний, он держит в памяти много векторов-эмбеддингов, и каждый записан «с запасом» — в 32 битах. Но поиску не нужна такая точность: ему важно лишь, какой вектор ближе всего к запросу. TurboQuant пользуется этим и хранит те же векторы в 3–4 битах — памяти уходит примерно впятеро меньше, а ответы остаются те же. Подключается он подменой одного компонента поиска, всё остальное библиотека делает сама.
Как ребёнку
Представь, что ты ищешь в шкафу самую похожую на образец футболку. Тебе не нужно знать точный оттенок нитки — достаточно понять, какая ближе всего. TurboQuant «огрубляет» описание каждой футболки, чтобы оно занимало меньше места на полке, но по-прежнему позволяет быстро найти самую похожую.
Аналогия — «это как…»
Это как JPEG для картинок: файл ужимается в разы, потому что глазу не нужна каждая математически точная точка. TurboQuant делает то же с векторами — выкидывает точность, которая поиску всё равно не пригодилась бы.
Зачем это мне
Память стала главным потолком локальных и агентных систем: на своём железе KV-кэш и векторный индекс дерутся за один пул RAM, и с ростом контекста агент тупеет. Умение отдать поиску в 5 раз меньше памяти без потери качества напрямую расширяет размер контекста, базы знаний и число агентов, которые влезают в одну машину.
Для тех, кто в теме
TurboQuant (Google, ICLR 2026) кладёт эмбеддинги в KV-кэш и векторный индекс в 3–4 бита вместо fp32 через связку PolarQuant (выравнивание распределения shuffle + скалярная квантизация по бакетам) и QJL (коррекция остаточной ошибки одним битом). Практический sweet spot ~3.5 бита; управляется единственным параметром — битовым бюджетом, остальное на библиотеке. Покрывает и inference-слой, и RAG; уже вкатывается в llama.cpp, MLX, Ollama, LM Studio. В отличие от RabitQ (Milvus, 1–4 бита, только vector search) работает и для KV-кэша.
Оценка видео
Чем выше — тем больше пользы на минуту
средняя из 5
Память как потолок локальных агентов и свежий paper Google с ICLR 2026 — одна из горячих тем года.
Идея и механика поданы ясно, но это короткий обзорный talk: математика PolarQuant/QJL остаётся за кадром, цифр по recall почти нет.
Сам разворот «квантуй ради ранжирования, а не ради вектора» свежий, хотя опирается на чужой алгоритм.
Есть open-source Turbo Agent и понятный путь: свапнуть ретривер, задать битовый бюджет, прогнать бенчмарк.
Автор честно переводит ML-paper на язык software-инженеров, но местами доклад перегружен повторами.
Кому будет полезно
Чем выше оценка — тем больше пользы для профессии. Разверни — почему.
Для разработчиков RAG и поисковых систем 4.8 /5
Прямое попадание: как ужать векторный индекс впятеро без падения recall, оставив ту же векторную БД и агентный фреймворк.
Для ML-инженеров и AI-инженеров 4.6 /5
Даёт рабочую интуицию про PolarQuant, QJL, битовый бюджет и разницу между сжатием KV-кэша и сжатием индекса.
Для инженеров локального инференса 4.5 /5
Объясняет, почему на Mac KV-кэш дерётся за RAM с индексом и как квантизация возвращает память под контекст.
Для бэкенд-разработчиков агентов 4.1 /5
Показывает, где именно в пайплайне подменить слой ретривера, чтобы получить экономию без переписывания агента.
Для дата-инженеров 3.7 /5
Полезно для больших статических индексов, но выбор между TurboQuant, RabitQ и FP8 придётся уточнять под свою нагрузку.
Для технических архитекторов 3.6 /5
Помогает заложить память как явный бюджет системы, хотя продовых бенчмарков в докладе мало.
Инсайты
Нажми, чтобы раскрыть — то, что меняет взгляд на тему
01 Полная точность эмбеддингов — привычка, а не требование 4:49
Мы храним векторы в 32 битах по инерции. Но поиску не нужна точность вектора — нужна лишь его близость к запросу, а её сохраняют и 3–4 бита. Полная точность в retrieval оказывается тратой памяти почти ни за что.
02 Память, а не вычисления, стала потолком агента 1:12
Классически думают про FLOPS и скорость модели. Но на своём железе с ростом контекста KV-кэш раздувается — иногда больше самой модели — и всё упирается в общий пул RAM. Узкое место сместилось в память.
03 Качество сжатия судят по ранжированию, а не по вектору 5:08
Обычная метрика сжатия — насколько искажён вектор. TurboQuant предлагает смотреть иначе: важно лишь, не поехал ли порядок ближайших результатов. Это смещает саму рамку оценки «хорошего» сжатия.
04 Оптимизация ушла в библиотеки — вам остался один тумблер 6:00
Раньше квантизация означала ручной тюнинг. Здесь всё сложное (перемешивание, бакеты, коррекция ошибки) спрятано, а инженеру остаётся единственное решение — сколько бит он готов потратить.
05 KV-кэш и векторный индекс — одна проблема с одним решением 6:55
Их обычно чинят раздельно: одно на inference-слое, другое в vector search. TurboQuant показывает, что это одна и та же задача сжатия и её можно закрыть одним подходом сразу в обоих местах.
Ключевые цитаты
Сильные фразы из видео — нажми тайм-код, чтобы услышать в оригинале
«Поиску не важно, как выглядит вектор. Ему важно только, что ближе всего к вашему запросу.»
«Не храните векторы в 32 битах. Просто храните их в трёх-четырёх битах. Вот и всё.»
«Это значит, что на retrieval вы тратите в пять раз больше памяти.»
«Хорошая новость в том, что всё остальное библиотека делает сама. Вручную настраивать ничего не нужно.»
«Идеальная точка по индустрии — 3.5 бита. Но можно и меньше, если это работает для вашей задачи.»
«Единственное, что мы изменили, — это ретривер. И это дало огромную разницу.»
«Память индекса всего 1.6 КБ — почти впятеро меньше, чем у float32.»
«Смените мышление и сжимайте только ради ранжирования.»
Полезные советы
Что можно применить уже сегодня. Разверни совет — сколько займёт, что даст и что конкретно делать
1 Замерь, сколько памяти реально ест твой retrieval
15 минут поймёшь, есть ли у тебя тот самый пятикратный перерасход
Замерь, сколько памяти реально ест твой retrieval
Прежде чем что-то менять, посмотри на память индекса и KV-кэша при рабочем размере контекста. Часто окажется, что эмбеддинги съедают несопоставимо много относительно пользы.
Что делать
- 1 Запусти пайплайн на реальном объёме документов и контекста.
- 2 Отдельно замерь память векторного индекса и KV-кэша.
- 3 Прикинь, во сколько бит на самом деле хранятся твои эмбеддинги (обычно fp32).
2 Свапни один ретривер на TurboQuant и сравни
полдня увидишь разницу в памяти без риска ломать весь пайплайн
Свапни один ретривер на TurboQuant и сравни
Не переписывай агента целиком. Возьми один поисковый путь, подмени слой индексации на квантованный и прогони тот же запрос на baseline и на TurboQuant.
Что делать
- 1 Оставь тот же агентный фреймворк и ту же векторную БД.
- 2 Заведи два ретривера: fp32-baseline и TurboQuant.
- 3 Сравни память индекса и корректность ответа на одинаковых запросах.
3 Прогони recall и latency на своих данных
1 день убедишься, что качество не просело именно на твоей нагрузке
Прогони recall и latency на своих данных
Демо на игрушечном индексе ничего не доказывает про прод. Единственная честная проверка — бенчмарк recall и задержки на реальных документах и запросах.
Что делать
- 1 Собери набор запросов с известными правильными результатами.
- 2 Замерь recall@k и latency на baseline и на квантованном индексе.
- 3 Смотри не на средний ответ, а на просадку в хвосте.
4 Начни с бюджета 4 бита и опускайся аккуратно
20 минут найдёшь свою точку баланса памяти и качества
Начни с бюджета 4 бита и опускайся аккуратно
Индустриальный ориентир — около 3.5 бита, но безопаснее стартовать с 4 и снижать, следя за recall. Как только качество поехало — остановись на предыдущем значении.
5 Оставь шаг переранжирования включённым
10 минут сохранишь точность выдачи при агрессивном сжатии
Оставь шаг переранжирования включённым
В демо именно re-rank удерживает корректность после компрессии: сначала грубый быстрый поиск по сжатому индексу, потом переранжирование топа. Не выкидывай его ради экономии.
6 Обнови инференс-движок
30 минут получишь квантизацию бесплатно, без своего кода
Обнови инференс-движок
TurboQuant вкатывается внутрь llama.cpp, MLX, Ollama и LM Studio. Если гоняешь локальные модели через них, часть выгоды приедет с обновлением движка сама.
7 Определись, что именно ты жмёшь
15 минут не перепутаешь два разных сценария экономии
Определись, что именно ты жмёшь
TurboQuant работает и для KV-кэша инференс-слоя, и для эмбеддингов векторного индекса. Это разные места и разный эффект — реши, где у тебя болит, прежде чем внедрять.
Сценарии применения
Как разные люди применяют это на практике
Я как Разработчик RAG-поиска
Проблема: векторный индекс раздувает RAM и тянет за собой счёт за инфраструктуру
Хочу: ужать индекс, не меняя векторную БД и не теряя релевантность
Поможет: статья показывает, как свапнуть слой ретривера на TurboQuant и проверить recall
Я как Инженер локального инференса
Проблема: на Mac KV-кэш при длинном контексте дерётся за память с моделью и индексом
Хочу: вернуть память под контекст без покупки железа
Поможет: видно, что квантизация KV-кэша до 3–4 бит снимает основной перерасход
Я как Основатель AI-стартапа
Проблема: облачный inference и большие индексы дорогие, а маржа тонкая
Хочу: понять, реально ли впятеро урезать память retrieval
Поможет: разбор даёт путь через open-source Turbo Agent и честные оговорки про бенчмарк
Я как Бэкенд-разработчик агента
Проблема: с ростом контекста агент отвечает медленнее и хуже
Хочу: разобраться, почему деградация идёт от KV-кэша
Поможет: статья объясняет механику и где в пайплайне вмешаться
Я как Дата-инженер
Проблема: огромный статический индекс не влезает в память и медленно грузится
Хочу: выбрать метод сжатия под большой неизменный индекс
Поможет: есть сравнение TurboQuant с RabitQ, который силён именно на больших статических индексах
Я как Инди-хакер
Проблема: гоняет модель и поиск на своём ноуте, всё упирается в 16–32 ГБ RAM
Хочу: выжать больше контекста из того же железа
Поможет: понимает, что обновление Ollama/LM Studio уже может принести часть экономии
Логика повествования
Как устроена аргументация видео — пройди по шагам
-
Предпосылка Длинный контекст деградирует из-за KV-кэша 0:37
С ростом истории диалога KV-кэш пухнет, и качество агента падает — особенно на своём железе.
-
Аргумент На локальной машине память — общий пул 1:30
Модель, KV-кэш и векторный индекс дерутся за одну RAM; KV-кэш может перерасти саму модель.
-
Аргумент Эмбеддинги хранятся в 32 битах без нужды 1:45
Поиску хватает 3–4 бит, значит fp32 — пятикратный перерасход памяти на retrieval.
-
Пример Прежние методы все с компромиссом 2:05
Квантизация модели, компакция, меньшие эмбеддинги, offload — каждый жертвует качеством, скоростью или требует железа.
-
Аргумент Поиску важна только близость, не сам вектор 4:49
Раз важен лишь порядок ближайших, вектор можно жать агрессивно, пока не поехало ранжирование.
-
Пример TurboQuant: перемешать, округлить, поправить 5:08
PolarQuant выравнивает и квантует по бакетам, QJL правит остаточную ошибку одним битом.
-
Пример Демо: тот же ответ, впятеро меньше памяти 10:55
8 КБ у fp32 против 1.6 КБ у TurboQuant при том же grounded-ответе; сменили только ретривер.
-
Вывод Вывод: сжимай ради ранжирования 13:13
Смени мышление, начни с малого, прогони recall и latency на своих данных.
Подробный разбор
Полный разбор — разверни, если нужно глубже
Развернуть подробный разбор Свернуть подробный разбор
Подробный разбор
Доклад держится на одном непривычном тезисе: поиску не нужна полная точность вектора. Мы по инерции храним эмбеддинги в 32 битах, будто это данные для точных вычислений, — а на деле в retrieval важен лишь порядок ближайших к запросу. Всё, что точнее этого порядка, память тратит впустую. Отсюда и оценка автора: fp32 на поиске — примерно пятикратный перерасход.
Механика TurboQuant описана без математики, но честно: сначала данные «выравниваются» перемешиванием и округляются по бакетам (это PolarQuant), затем остаточная ошибка добивается одним битом (QJL). Инженеру из всего этого достаётся ровно один рычаг — битовый бюджет; ориентир около 3.5 бита, на практике удобно стартовать с 4. Важно, что это одно решение сразу для двух мест: KV-кэша на inference-слое и эмбеддингов в векторном индексе.
Стоит ли смотреть целиком
Да, если вы строите RAG или агентов и упираетесь в память — 15 минут окупятся понятной интуицией и конкретным путём внедрения через open-source Turbo Agent. Живое демо наглядно: агента и документы не трогали, сменили только ретривер, и память индекса упала с 8 КБ до 1.6 КБ при том же ответе.
Но относитесь к докладу как к сильному приглашению попробовать, а не как к доказательству. Сохранность качества показана на единичном ответе и крошечном индексе, а «3.5 бита» и «всё уже встроено» поданы оптимистичнее, чем есть на сегодня. Настоящий ответ даст только ваш бенчмарк recall и latency на ваших данных — с чего автор и советует начать.
План внедрения
С чего начать — отмечай шаги, прогресс сохранится
Выполнено 0 из 5
Проверь себя
Ответь на вопросы, чтобы материал закрепился
-
1. Почему с ростом контекста локальный агент начинает тупить?
-
2. Сколько бит на самом деле нужно поиску по эмбеддингам, по мысли доклада?
-
3. Что делает стадия QJL в TurboQuant?
-
4. В чём ключевой сдвиг мышления, который предлагает автор?
-
5. Что именно поменяли в живом демо, чтобы получить пятикратную экономию памяти?
-
6. Чем RabitQ отличается от TurboQuant, по словам автора?
Словарь терминов
Понять незнакомое простым языком
Показать 8 терминов Свернуть словарь
- KV-кэш
- Память, где модель хранит «историю» текущего диалога/контекста, чтобы не пересчитывать её каждый раз. Растёт вместе с длиной контекста.
- Эмбеддинг
- Числовой вектор, кодирующий смысл текста. Похожие по смыслу тексты дают близкие векторы, и по этой близости работает поиск.
- Квантизация
- Хранение чисел в меньшем числе бит (например, 4 вместо 32). Экономит память ценой части точности.
- TurboQuant
- Алгоритм Google (ICLR 2026), сжимающий эмбеддинги до 3–4 бит без заметной потери качества поиска.
- PolarQuant
- Часть TurboQuant: выравнивает распределение вектора (перемешивание) и округляет значения по бакетам скалярной квантизацией.
- QJL
- Финальная стадия TurboQuant: правит остаточную ошибку сжатия всего одним битом.
- Re-ranking
- Переранжирование: быстрый грубый поиск даёт кандидатов, а второй проход уточняет их порядок, удерживая точность после сжатия.
- RAG
- Retrieval-Augmented Generation: подход, где модель перед ответом ищет релевантные документы в векторной базе и опирается на них.
Критический взгляд
Объективно: с какими тезисами можно поспорить и что преувеличено
Это по сути презентация своего open-source и чужого paper
Доклад продвигает Turbo Agent от Super Agentic AI поверх алгоритма Google. Это нормально, но независимой оценки со стороны в самом выступлении нет — стоит держать в голове конфликт интересов.
«Качество сохраняется» показано без цифр recall
Главное доказательство в демо — что оба ретривера дали grounded-ответ «true» на одном вопросе. Это не бенчмарк recall@k, а единичный кейс; реальную сохранность качества автор сам предлагает проверять уже вам.
Пятикратная экономия показана на игрушечном индексе
Демо: 8 КБ против 1.6 КБ, эмбеддинги 0.6B и 256 измерений. Абсолютные величины крошечные, и поведение на многогигабайтном проде из такого демо не следует напрямую.
«Всё уже встроено, делать ничего не надо» — оптимистично
Автор сам оговаривается, что tooling ещё emerging. «Everything will eventually get baked in» — это про будущее, а не про гарантированное состояние ваших движков сегодня.
3.5 бита как «индустриальный sweet spot» — без источника
Конкретная цифра подана как консенсус индустрии, но ссылки на замеры в докладе нет. Для своей задачи её надо подтверждать бенчмарком, а не принимать на веру.
Взгляни иначе
Новый угол, смежные области и потенциал на стыке — пища для размышлений
Сжатие — это про приватность, а не только про счёт за память
Чем меньше памяти нужно retrieval, тем больше контекста и знаний влезает на личное устройство. Экономия бит — это тихий способ вернуть вычисления и данные из облака на edge, ближе к пользователю.
Тот же принцип — за пределами ИИ
«Храни только ту точность, что нужна решению» — это идея не про эмбеддинги, а про любые системы: аналитические витрины, индексы БД, телеметрию. Часто мы платим за точность, которой никто дальше по пайплайну не пользуется.
Урок JPEG повторяется
Картинки давно хранят с потерями, потому что глазу не нужна полная точность. TurboQuant — это «lossy-сжатие для смысла»: поиску, как и глазу, достаточно достаточно хорошего приближения.
А зачем тогда вообще 32 бита?
Если качество держится на 4 битах, возникает встречный вопрос: не избыточны ли сами эмбеддинги by design? Возможно, будущие модели будут учиться сразу в компактном представлении, а не сжиматься постфактум.
Похожие разборы
RAG не умер, а вырос в итеративный agentic-поиск: эмбеддинги как кэш вычислений
Простой «RAG = один вызов вектора в контекст» устарел, но сам retrieval жив и превратился в итеративный поиск агента с набором инструментов (вектор, BM25, grep). Эмбеддинги стоит понимать как кэш вычислений: разовая индексация экономит токены и поднимает точность ответов, что подтверждают метрики Cursor.
Читать → РазборHeadroom: как перестать переплачивать за токены ИИ-агентов — слой сжатия контекста простыми словами
Большая часть токенов в Claude Code и Codex уходит не на ваши промпты, а на «мусор» — целиком вычитанные логи, JSON и страницы, из которых нужно 10–20%. Headroom — это локальный прокси, который умно сжимает этот мусор разными компрессорами и при этом обратим: если модель захочет оригинал, она вернёт его одним tool-call.
Читать → РазборDocling: как превратить PDF, таблицы и картинки в контекст для LLM — локально и дёшево
Большая часть корпоративных данных заперта в PDF, таблицах и сканах, а качество любого RAG или агента решается не в промпте, а на этапе извлечения этих данных. Docling делает это локально, дёшево и детерминированнее, чем прогон документов через дорогие frontier-модели.
Читать → РазборМодель предлагает — платформа решает: инфраструктура надёжности для автономных ИИ-агентов
При переходе от чатботов к автономным агентам узкое место смещается с интеллекта модели на надёжность инфраструктуры вокруг неё. Модель должна лишь предлагать действия, а проверять, одобрять и исполнять их обязана детерминированная платформа — и именно она, а не лучший промпт, становится конкурентным преимуществом.
Читать →