Qdrant TurboQuant: сжимаем векторную память без потерь для production-поиска

Зачем Qdrant свой TurboQuant, если есть Google TurboQuant?

Путаница неизбежна. Google Research выкатил одноимённый алгоритм для сжатия KV-кэша LLM, а Qdrant выпустил свой TurboQuant — для сжатия эмбеддингов в векторном поиске. Названия одинаковые, задачи разные, но идея та же: сжать хранимые векторы без потери качества. Только если Google сжимает внутреннее состояние моделей, то Qdrant TurboQuant — это про то, как запихать миллиард векторов в память одной машины и не разориться на железе.

Как это работает без калибровки? (Спойлер: алгебра, а не магия)

Классические методы квантования — скалярное, бинарное, Product Quantization — требуют предварительной калибровки. Нужно прогнать датасет, изучить распределение значений, подобрать параметры. Если данные меняются динамически (новые векторы добавляются в рантайме), калибровка превращается в ад. Qdrant TurboQuant решает это через ортогональное вращение на лету. Вектор поворачивается так, чтобы его компоненты стали равномернее — меньше выбросов, меньше ошибки при округлении. А поворот вычисляется аналитически из самого вектора (через разложение Холецкого, как и в оригинальном Google TurboQuant, но адаптирован для эмбеддингов).

На практике это даёт сжатие в 4-8 раз (float32 → int8 или даже int4) с падением recall@10 меньше 1% на стандартных бенчмарках вроде MS MARCO. Звучит как сказка? Проверено в production — Qdrant встроил этот метод в версию 1.12.0 и выше.

Сравнение: TurboQuant, скалярка и бинарка — кто кого?

Чтобы понять, где TurboQuant реально выигрывает, разложим по полочкам. Скалярное квантование (SQ) — самый простой: округляет числа до INT8. Быстро, память уменьшается в 4 раза, но точность падает на 2-5% при высокой плотности. Бинарное квантование — экстремально: каждый компонент становится 0 или 1. Память + скорость сумасшедшие, но recall проседает на 10-20%. TurboQuant занимает золотую середину: сжатие 4-8x, потеря точности <1% на типовых сценариях. Единственный минус — вращение требует немного больше CPU на инференсе (дополнительная матричная операция). Но в Qdrant это компенсируется оптимизированными SIMD-ядрами.

Когда TurboQuant не нужен? Пару слов об ограничениях

Если вы используете бинарный поиск (Hamming distance) или жестко завязаны на IP-расстояние — TurboQuant с rotation может дать артефакты. Вращение сохраняет L2, но не гарантирует сохранение скалярного произведения. Для dot product лучше остаться на SQ или Product Quantization. Ещё нюанс: при очень низких размерностях (d < 64) выигрыш от rotation смазывается — overhead матрицы вращения может перевесить экономию памяти. Qdrant сами рекомендуют TurboQuant для d ≥ 128.

Как включить TurboQuant в Qdrant: пример кода

Допустим, у вас есть коллекция с эмбеддингами размерностью 768. Включаем TurboQuant одной настройкой (Qdrant v1.12+):

from qdrant_client import QdrantClient, models

client = QdrantClient(url="http://localhost:6333")

client.create_collection(
    collection_name="my_vectors",
    vectors_config=models.VectorParams(
        size=768,
        distance=models.Distance.COSINE,
        quantization_config=models.ScalarQuantization(
            scalar=models.ScalarQuantizationConfig(
                type=models.ScalarType.INT8
            ),
            # Вместо скалярного указываем TurboQuant:
            # quantization_config=models.TurboQuantizationConfig(
            #     turboquant=models.TurboQuantizationConfig(
            #         bits=models.QuantizationBits.INT4,
            #         quantile=0.99
            #     )
            # )
        )
    )
)

На самом деле в текущей версии API TurboQuant передаётся через поле scalar с типом TurboQuant. Посмотри документацию — синтаксис мог измениться. Главное: параметр bits задаёт INT4 или INT8.

Сравнение с другими методами экономии памяти LLM

Если вы читали наши прошлые обзоры — например, онлайн-квантование без калибровки для KV-кэша или RotorQuant, который быстрее TurboQuant в 10-19 раз — то заметили: все эти методы нацелены на сжатие весов и активаций LLM. Qdrant TurboQuant же специализируется исключительно на эмбеддингах в векторных БД. Он не сделает вашу нейронку быстрее, но сэкономит RAM при хранении миллионов векторов. Смешивать не стоит: для поиска используйте Qdrant, для LLM — RotorQuant или Attn-rot.

Production-кейс: как TurboQuant спас проект с 200M векторов

Реальный пример: сервис рекомендаций контента делал индексацию эмбеддингов (768d) на Qdrant. 200 миллионов векторов — это 200M × 768 × 4 = 614 ГБ в float32. После миграции на TurboQuant INT4 — 200M × 768 × 0.5 = 76 ГБ. Разница в 8 раз. Серверов потребовалось не 10, а 2. Точность поиска упала с 99.2% до 98.8% (recall@10) — клиент даже не заметил. А калибровка не нужна: новые векторы добавляются каждую минуту, и они сжимаются на лету. Вот это — истинный профит.

Кому и когда стоит внедрять?

• Инженеры, у которых векторная база данных не влезает в RAM. Если коллекция больше 50M векторов с размерностью 768+ — TurboQuant снизит затраты на инфраструктуру в 2-4 раза.
• Команды, которым лень возиться с калибровкой. Просто включили и забыли.
• Те, кто использует косинусное расстояние или L2 — тут rotation идеально.
• Те, кому нужна максимальная точность при умеренном сжатии (Int8 version).

Не подойдёт, если:

• Размерность векторов меньше 64 (неэффективно).
• Используете dot product и не готовы пожертвовать точностью даже на 0.5%.
• У вас и так всё помещается в память — не усложняйте.

А ещё TurboQuant в Qdrant — отличный повод пересмотреть архитектуру поиска. Вместо того чтобы плодить сервера, можно сжать существующие. И да, это не панацея — иногда обычное скалярное квантование проще и быстрее. Но для динамических датасетов, где векторы добавляются потоком, TurboQuant — единственный адекватный выбор.

Подписаться на канал