# Qdrant quantization: как сжать векторы и проверить качество поиска

Источник: https://modelium.tech/zhurnal/qdrant-kvantovanie-vektorov/

Квантизация Qdrant создаёт сжатое представление векторов для поиска; исходные векторы при этом сохраняются. Начните со scalar int8 на отдельной тестовой коллекции, затем сравните выдачу и память с контрольной коллекцией при той же нагрузке. Экономию памяти всей базы и точность нельзя вывести из степени сжатия одного вектора: нужен замер на ваших документах.

**Срез официальной документации — 7 октября 2026 года.** Ниже протокол для изолированного self-hosted Qdrant, а не результат запуска Modelium. В документации описан интерфейс с `memory` для v1.19 и новее; для более ранней версии сверяйте `on_disk`/`always_ram` и свой API, не копируйте настройку вслепую. [s3](#src-s3) [s6](#src-s6)

## Что именно сжимает Qdrant quantization?

Для локального поиска по документам схема такова: embedding-модель создаёт dense-векторы, Qdrant индексирует их и возвращает близкие точки, а локальная LLM формирует ответ по найденным фрагментам. Квантизация касается **представления векторов внутри поиска Qdrant**, не весов LLM в GGUF и не исходного текста документов. В self-hosted сценарии заранее определите одну модель эмбеддингов, её версию, размерность и одинаковый способ получения вектора документа и запроса. [s1](#src-s1) [s2](#src-s2)

Qdrant предлагает scalar, binary, product и TurboQuant; простой первый кандидат — scalar int8. Он преобразует компонент исходного float32-вектора в 8-битное представление: размер **сжатого представления компонента** меньше вчетверо, но оригиналы продолжают существовать. Это не обещает сокращения диска или RAM всей коллекции вчетверо: у неё есть HNSW, payload, индексы, служебные данные и кеш. Вендор описывает снижение погрешности на своих наборах, но это не измерение Modelium и не гарантия для русскоязычного корпуса. [s1](#src-s1) [s3](#src-s3) [s4](#src-s4)

Binary и product могут сжать сильнее, но выбор зависит от размерности и распределения ваших векторов; документация отдельно рекомендует для binary rescoring оригиналами. Не ставьте их вместо scalar только потому, что у метода больше заявленный коэффициент: сравнивать нужно качество **своей** поисковой задачи и цену дополнительного чтения исходников. [s1](#src-s1)

## Как подготовить честный контрольный набор?

Используйте [локальный тестовый Qdrant](/zhurnal/qdrant-lokalno/) с изолированным портом и обезличенными документами, не меняйте рабочую коллекцию. Сохраните версию сервера, конфигурацию dense-векторов (размерность, `distance`), модель и ревизию embeddings, одинаковые point ID и payload. Подготовьте набор реальных для задачи запросов и для каждого ожидаемые ID релевантных фрагментов; добавьте короткий запрос, длинный запрос и выборку с типовым `filter`, если фильтрация действительно используется. Отдельно фиксируйте состояние и нагрузку сервера. [s2](#src-s2) [s6](#src-s6) [s8](#src-s8)

Создайте две тестовые коллекции с одними данными, структурой и режимом индексации: `docs_control` без quantization и `docs_int8` с scalar. В конфигурации **новой** коллекции по документации Qdrant задайте те же `vectors.size` и `vectors.distance`, а для второй дополнительно `"quantization_config":{"scalar":{"type":"int8","quantile":0.99,"memory":"pinned"}}`. Здесь `size` должен совпасть с реальной размерностью вашей embedding-модели; пример Qdrant `768` не является требованием для всех моделей. `quantile:0.99` — документированный параметр примера, не универсально лучший результат. Для `memory:pinned` заранее проверьте доступную RAM под сжатую копию. [s1](#src-s1) [s2](#src-s2) [s3](#src-s3)

Если оцениваете **уже существующую** отдельную тестовую коллекцию, официальная документация описывает `PATCH /collections/{collection_name}` с `quantization_config`, но без повторного объявления векторов. Изменение конфигурации не применяйте к рабочему адресу и не принимайте один ответ API за завершение перестройки: дождитесь готовности коллекции, сверяйте число точек и выполните контрольный запрос. Лучше держать отдельную нетронутую контрольную коллекцию, чтобы сравнить также расходы хранения, а не только режим запроса. [s1](#src-s1) [s7](#src-s7)

## Как сравнить качество выдачи при одинаковых запросах?

Отправляйте запросы через `POST /collections/{collection_name}/points/query` с одинаковыми вектором запроса, `limit`, фильтром, HNSW-параметрами и окружением. Для контроля на `docs_int8` документация позволяет установить `"params":{"quantization":{"ignore":true}}`, чтобы искать без сжатой копии; результаты сохраняйте отдельно от результатов `docs_control`. Для сценария со сжатием явно установите `"params":{"quantization":{"ignore":false,"rescore":true,"oversampling":2.0}}`: `rescore` пересчитывает кандидатов по исходным векторам, а `oversampling` увеличивает их пул перед пересортировкой. Для scalar значение `rescore` по умолчанию может быть выключено, поэтому явно фиксируйте режим, а не сравнивайте неуказанные defaults. [s1](#src-s1) [s8](#src-s8)

Для каждого запроса запишите ID топ-k, оценку релевантности и задержку: доля релевантных ID в топ-k — отдельная оценка по вашей ручной разметке; `overlap@k` с точным контрольным списком — только проверка совпадения с контролем, не доказательство полезности документа для пользователя. Не смешивайте эти две величины. Сравните минимум режим без квантизации, scalar без пересортировки и scalar с rescoring при тех же запросах; если сравниваете latency, задайте сопоставимую конкуренцию, повторения и температуру кеша. Числовой прирост не заявлен: Modelium такой эксперимент не проводил. [s1](#src-s1) [s8](#src-s8)

При фильтрации повторите тот же `filter` для обеих коллекций. Если извлечение нужного источника ухудшилось, попробуйте `oversampling` и `rescore`, проверьте размерность и одинаковость записанных векторов, а затем оцените конечный ответ RAG с цитатой; сам ответ LLM может ошибаться даже при одинаковом топ-k. Разграничение доступа проверяйте отдельно: метка в payload и клиентский фильтр сами по себе не заменяют авторизацию. [Гайд по фильтрам](/zhurnal/qdrant-filtry-metadannyh/) описывает отдельный отрицательный тест. [s1](#src-s1) [s8](#src-s8)

## Как измерить память и задержку без ложной «экономии ×4»?

На Qdrant v1.18+ используйте `GET /collections/docs_control/memory` и тот же путь для `docs_int8`. Разделяйте `Disk`, `RAM` (закреплённые данные) и `Cached` (вытесняемые страницы ОС), смотрите компоненты Vectors, индексы и payload, а не только общее число процесса. Это **оценки**: в документации прямо отмечены неучтённые аллокации; `Cached` может меняться при давлении на память и после прогрева. Запишите версию, размер двух коллекций, состояние индекса и объём page cache вместе с нагрузкой. [s4](#src-s4)

С Qdrant v1.19 настройка `memory` позволяет независимо размещать оригиналы, HNSW и квантизованные векторы: `pinned` закрепляет поддерживаемую структуру в RAM, `cached` использует прогретый page cache, `cold` не прогревает данные заранее. Оригинальные dense-векторы нельзя просто поставить в `pinned` по этому интерфейсу; если оригиналы `cold`, а сжатая копия `pinned`, рескоринг читает оригиналы и может увеличить задержку. Старые флаги `on_disk` и `always_ram` не исчезли из исторических установок, но не следует приписывать им семантику v1.19 без проверки версии. [s3](#src-s3) [s5](#src-s5)

Сравнивайте несколько одинаковых прогонов, медиану и хвост задержки при зафиксированных данных и ресурсе узла. Если выигрыш памяти ценой худшей выдачи или неприемлемого хвоста задержки, вернитесь к контрольному варианту; не отключайте `rescore` до проверки релевантности. Для продакшена планируйте отдельное окно, резервную копию и обратимый перенос трафика между коллекциями — не экспериментируйте с единственной рабочей копией. [s1](#src-s1) [s4](#src-s4) [s5](#src-s5)

**Следующий шаг:** составьте размеченный набор запросов по [методике оценки RAG](/zhurnal/ocenka-kachestva-rag/), проведите на отдельных коллекциях сравнение ID и релевантности топ-k, RAM/кеша/диска и задержки, затем принимайте решение по собственным порогам задачи. Modelium не проводил этого теста и не публикует выдуманных измерений. [s1](#src-s1) [s4](#src-s4) [s8](#src-s8)

## Источники

1. [Qdrant: Quantization, методы, scalar и параметры поиска](https://qdrant.tech/documentation/manage-data/quantization/) — получено 2026-10-07
2. [Qdrant: Vectors and vector configuration](https://qdrant.tech/documentation/manage-data/vectors/) — получено 2026-10-07
3. [Qdrant: Memory Tiers and legacy settings](https://qdrant.tech/documentation/ops-configuration/memory-tiers/) — получено 2026-10-07
4. [Qdrant: Monitor Collection Memory Usage](https://qdrant.tech/documentation/ops-monitoring/memory-usage/) — получено 2026-10-07
5. [Qdrant: Optimize Performance](https://qdrant.tech/documentation/ops-optimization/optimize/) — получено 2026-10-07
6. [Qdrant: Local Quickstart](https://qdrant.tech/documentation/quickstart/) — получено 2026-10-07
7. [Qdrant REST API: Update collection parameters](https://api.qdrant.tech/api-reference/collections/update-collection/) — получено 2026-10-07
8. [Qdrant REST API: Query points](https://api.qdrant.tech/api-reference/search/query-points/) — получено 2026-10-07