Справочник

Qdrant: что это, как поднять и сколько займёт на диске

17 сентября 2026 · 17 минут чтения

Проверка фактов

Юлия Найпак

Методист по автоматизации. Сверяет паспорт инструмента с документацией вендора.

Автор Р

Редакция

Коллектив авторов, редакторов и иллюстраторов статей на сайте блога онлайн-университета «Зерокодер». Пишем…

Черновик готовит редакция с помощью ИИ. За стандарт издания отвечает главный редактор — Валерий Курземнек.

Материал редакции Зерокодера. Числа замеров ниже сняты собственным прогоном 17 сентября 2026 года на Qdrant 1.19.1; цитаты документации приведены дословно. Обновлено: сентябрь 2026.

Qdrant — это открытая векторная база данных на Rust: хранилище числовых векторов с поиском по смысловой близости и фильтрами по метаданным. Что это даёт на практике: 100 000 эмбеддингов по 384 измерения ложатся в одну коллекцию, ближайшая десятка находится за 15 миллисекунд, а сервер поднимается одним файлом даже без Docker. Числа ниже — из прогона редакции на версии 1.19.1.

Главное:

• Официальный репозиторий описывает продукт дословно: «Qdrant (read: quadrant) is a vector similarity search engine and vector database». Лицензия Apache-2.0, язык Rust, 34 617 звёзд на GitHub.
• Прогон редакции 17.09.2026: 100 000 векторов по 384 измерения заняли на диске 540 366 409 байт при 153 600 000 байт самих чисел. Векторы — это 28,6% папки коллекции.
• Тысяча векторов в той же установке номинально заняла 621 042 308 байт, то есть больше, чем сто тысяч: место съедают преаллоцированные файлы сегментов, и на NTFS они занимают диск целиком.
• Фильтр по метаданным без индекса дал p50 31,03 мс, с индексом — 14,70 мс на той же коллекции и с тем же фильтром.
• Бесплатный тариф Qdrant Cloud — «0.5 vCPU / 1GB RAM/ 4 GB Disk»; по нашему замеру памяти в него влезает около 550 000 векторов по 384 измерения.

Что такое Qdrant и чем эта база отличается от обычной

Qdrant — это поисковый движок по векторам и векторная база данных одновременно. README проекта формулирует так: «Qdrant (read: quadrant) is a vector similarity search engine and vector database», и отдельно отмечает язык: «Qdrant is written in Rust 🦀, which makes it fast and reliable even under high load». Репозиторий qdrant/qdrant открыт 30 мая 2020 года, лицензия Apache-2.0, на 17 сентября 2026 года у него 34 617 звёзд и 2 680 форков по данным GitHub API.

Обычная база ищет по точному совпадению значений: WHERE city = 'Москва'. Qdrant ищет по близости чисел. Текст, картинку или товар прогоняют через модель, и она выдаёт вектор — набор чисел фиксированной длины, кодирующий смысл объекта. Как получаются такие числа, разобрано в материале про эмбеддинги; типовой сценарий, ради которого векторную базу и ставят, описан в статье про RAG.

Хранимая единица здесь — точка (point): собственный идентификатор, привязанный к ней вектор или несколько именованных векторов и payload — свободный JSON, по которому потом фильтруют. Коллекция — это именованный набор точек с общей размерностью вектора и общей метрикой расстояния (Cosine, Dot, Euclid, Manhattan).

Мини-вывод: Qdrant хранит числовые представления объектов и отвечает на вопрос «что похоже»; реляционная база отвечает на «что точно равно».

Зачем отдельная база под векторы, если есть pgvector и Chroma

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

Практическое правило простое. Если векторы живут рядом с бизнес-данными и их сотни тысяч, pgvector избавляет от второго сервера и даёт, как перечисляет его README, «ACID compliance, point-in-time recovery, JOINs». Если нужен быстрый прототип на ноутбуке, Chroma стартует в одну строку. Qdrant забирает случаи, где важны фильтры поверх векторного поиска, квантизация, шардирование и раздельное масштабирование поиска.

Ограничение pgvector названо в его README прямо: тип vector держит «up to 2,000 dimensions», и эмбеддинги на 3 072 измерения туда уже не положить без halfvec.

Мини-вывод: отдельная векторная база оправдана нагрузкой и фильтрами; при сотнях тысяч векторов рядом с Postgres расширение pgvector закрывает задачу дешевле.

Как поднять Qdrant локально: Docker и запуск без Docker

Qdrant поднимается двумя путями. Штатный — контейнер: документация приводит команду docker run -p 6333:6333 qdrant/qdrant и адрес localhost:6333, по которому отвечают REST API и веб-интерфейс. Docker на машине редакции не установлен, поэтому эта команда идёт здесь цитатой документации, а все числа статьи сняты вторым путём. Порты документация перечисляет буквально: «6333 — For the HTTP API, for the Monitoring health and metrics endpoints», «6334 — For the gRPC API», «6335 — For Distributed deployment».

Второй путь обходится без Docker вовсе. Релиз v1.19.1 от 4 сентября 2026 года выложен на GitHub восемью готовыми сборками: Windows, macOS (Intel и Apple Silicon), Linux (glibc, musl, AppImage) плюс пакет .deb. Архив qdrant-x86_64-pc-windows-msvc.zip весит 29 671 153 байта и разворачивается в один исполняемый файл qdrant.exe на 85 063 168 байт — ни конфигов, ни зависимостей.

$ qdrant.exe
Version: 1.19.1, build: 6ab21cac
Access web UI at http://localhost:6333/dashboard

WARN qdrant::settings: Config file not found: config/config
INFO qdrant::actix: Qdrant HTTP listening on 6333
INFO qdrant::tonic: Qdrant gRPC listening on 6334

Версию сервера надёжнее спрашивать у самого сервера: тег образа переезжает при каждой пересборке, а корневой эндпоинт возвращает версию вместе с хешем коммита.

$ curl http://127.0.0.1:6333/
{"title":"qdrant - vector search engine","version":"1.19.1","commit":"6ab21cac18ebb6f4ae29102c7f8f5cc11affd5de"}

Рядом с бинарником появляются каталоги storage и snapshots; данные переживают перезапуск. Тот же коммит 6ab21cac дала и линуксовая сборка qdrant-x86_64-unknown-linux-gnu.tar.gz в WSL — дальше это пригодится.

Мини-вывод: Qdrant запускается либо одной командой Docker, либо одним файлом из релиза GitHub; порт 6333 отдаёт HTTP API, 6334 — gRPC, 6335 нужен только кластеру.

Как работать с Qdrant из Python: клиент и локальный режим

Работа с Qdrant из Python идёт через пакет qdrant-client (pip install qdrant-client); в прогоне редакции пакет и сервер оказались одной версии — 1.19.1. Минимальный цикл — создать коллекцию, залить точки, спросить ближайших:

from qdrant_client import QdrantClient, models

client = QdrantClient(url="http://127.0.0.1:6333")
client.create_collection(
    "serp_ru",
    vectors_config=models.VectorParams(size=312, distance=models.Distance.COSINE),
)
client.upsert("serp_ru", points=models.Batch(ids=ids, vectors=vectors, payloads=payloads))
hits = client.query_points("serp_ru", query=query_vector, limit=3, with_payload=True)

У того же клиента есть локальный режим: QdrantClient(path="./local_db") не обращается ни к какому серверу и держит данные в файле. Редакция залила в него те же 747 текстовых кусков, что и в сервер: сборка заняла 2,49 секунды, поиск — 1,14 мс, папка на диске — 3 101 228 байт. Топ-3 по контрольному запросу совпал с серверным до четвёртого знака: 0.6644, 0.6633, 0.6572. Математика одна и та же; локальный режим не умеет только сеть, параллельных клиентов и снапшоты.

Мини-вывод: qdrant-client работает и с сервером, и с файлом на диске, выдавая одинаковый результат.

Какие индексы есть в Qdrant и что даёт индекс по payload

Индексов в Qdrant два, и отвечают они за разное. Документация разделяет их одной фразой: «a vector index speeds up vector search, and payload indexes speed up filtering». Векторный индекс здесь ровно один: «Qdrant currently only uses HNSW as a dense vector index» — многослойный граф ближайших соседей, который заменяет перебор миллионов векторов обходом нескольких сотен.

Индекс по payload — это обычный индекс по полю метаданных, и без него условие фильтра проверяется у точек по ходу поиска. Редакция замерила разницу на своей коллекции из 100 000 точек: один и тот же фильтр cat = "faq" AND year >= 2023, по 200 случайных запросов на режим, limit 10.

Читается таблица так: индекс по payload вернул фильтрованный запрос к скорости обычного поиска, а его отсутствие удвоило задержку. Документация добавляет условие про порядок: «Payload indexes should be created before ingesting data». Создание двух индексов на уже залитой коллекции добавило к её объёму 55 083 851 байт.

Мини-вывод: поля, по которым планируется фильтровать, нужно индексировать до заливки данных; на 100 000 точек это разница между 31,03 и 14,70 мс в медиане.

Сколько Qdrant занимает на диске: замер редакции

Вопрос «сколько места займёт база» в выдаче не закрывает никто: по нашей переписи 18 прочитанных страниц топа слова «payload_storage» и «vector_storage» не встречаются ни разу, сочетание «занимает на диске» — тоже. Поэтому редакция замерила сама.

Условия прогона: Qdrant 1.19.1 (коммит 6ab21cac), Windows 11, NTFS, 16 логических ядер, 100 000 случайных нормированных векторов по 384 измерения плюс payload из трёх полей. Сырьё — 153 600 000 байт чисел. Папка коллекции после того, как оптимизатор закончил работу:

Папка оказалась в 3,5 раза тяжелее самих чисел, и больше половины её занял payload из трёх коротких полей. Контрольный опыт объяснил почему: та же сотня тысяч векторов, залитая вообще без payload, дала 540 374 179 байт и те же самые 277 088 656 байт в payload_storage. Это не данные, а преаллокация: каждый из восьми сегментов сразу резервирует страницу на 33 554 432 байта, и журнал WAL резервирует по 32 мегабайта на файл (wal_capacity_mb: 32 в штатном конфиге).

Отсюда следствие против интуиции. Тысяча векторов в Qdrant занимает 621 042 308 байт, десять тысяч — 621 231 308, а сто тысяч — 540 366 409. Маленькая коллекция тяжелее большой, потому что её сегменты остаются дописываемыми — документация делит их надвое: «A segment can be appendable or non-appendable depending on the type of storage and index used». Дописываемый сегмент держит полный преаллоцированный чанк, а большую коллекцию оптимизатор уже перепаковал в файлы по размеру данных.

Мини-вывод: считать объём Qdrant по формуле «размерность × 4 байта × число векторов» нельзя; на реальной установке к этому добавляется фиксированный хвост в сотни мегабайт, и хвост тем толще, чем больше ядер: число сегментов Qdrant подбирает по их количеству (default_segment_number: 0).

Почему du показывает разный размер Qdrant на NTFS и ext4

Замер объёма Qdrant зависит от файловой системы, и разница измеряется не процентами. Редакция запустила ту же сборку 1.19.1 с тем же коммитом 6ab21cac дважды: qdrant.exe на Windows и NTFS, qdrant на ext4 в WSL — и залила по 1 000 векторов.

Номинальный размер совпал до байта. Занятое место разошлось в 144 раза, потому что на ext4 преаллоцированные чанки остаются разреженными файлами — дырки в них места не занимают. На NTFS разреженность включают явно, и Qdrant этого не делает; штатная утилита Windows отвечает однозначно:

$ fsutil sparse queryflag ...\vector_storage\vectors\chunk_0.mmap
У этого файла НЕ установлен атрибут "Разреженный"

На сотне тысяч векторов на ext4 картина та же: номинально 572 318 547 байт, реально занято 210 132 992. Полезная часть при этом честная — vector_storage занял 153 673 728 байт при теоретических 153 600 000.

Вывод для планирования: на Linux считайте по занятому месту (около 2 101 байта на вектор в 384 измерения вместе со служебными данными), на Windows и NTFS закладывайте номинальный размер целиком.

Мини-вывод: цифра «сколько весит Qdrant» без указания файловой системы и способа замера бессмысленна — разброс на одних и тех же данных доходит до 144 раз.

Что делает квантизация в Qdrant и что она не уменьшает

Квантизация в Qdrant сжимает представление векторов ради памяти. Документация формулирует цель точно: «Quantization is primarily used to reduce the memory footprint and accelerate the search process in high-dimensional vector spaces», а про скалярный вариант уточняет: «Scalar Quantization compresses each vector component from a 32-bit float to an 8-bit integer, achieving 4x compression with minimal accuracy loss».

Слово «memory» здесь стоит читать буквально. Редакция собрала ту же коллекцию из 100 000 векторов со скалярной квантизацией int8 и квантилем 0.99 и сравнила с обычной:

На диске стало больше на 60 417 883 байта: сжатые копии складываются рядом с оригиналами, потому что оригиналы нужны для уточнения результата. Экономия приходит в оперативной памяти, где в горячем слое лежит только сжатая версия.

Отдельная ловушка этого замера заставила редакцию переснять его. Статус коллекции показал green, а optimizer_status — ok, и в этот момент папка весила 1 795 825 294 байта: оптимизатор ещё не убрал temp_segments. Правильное число приходит позже, и надёжный признак даёт стабилизация размера папки; статус успокаивает раньше времени.

Мини-вывод: скалярная квантизация в Qdrant экономит RAM и немного ускоряет поиск, увеличивая при этом объём на диске на 11%.

Сколько стоит Qdrant Cloud и что влезает в бесплатный тариф

Сам Qdrant бесплатен: Apache-2.0, ставится на свой сервер без ограничений по числу векторов. Платить приходится за управляемое облако Qdrant Cloud, и его бесплатный уровень описан на странице тарифов буквально: «Free Tier», «Free forever», «For testing, and prototypes», «Single Node Cluster», «0.5 vCPU / 1GB RAM/ 4 GB Disk». Раздел вопросов на той же странице повторяет границы: «The free tier includes 1GB RAM and 4GB disk storage».

Дальше — платный уровень с оплатой по факту: «Billing is calculated based on actual resource usage during the billing period. You’re charged for compute (vCPU), memory (GB), storage (GB) consumed by your clusters, storage (GB) consumed by backups, and used inference tokens of paid models». Готового прайса в долларах на странице нет, вместо него калькулятор.

Что реально влезает в бесплатный тариф, показывает замер памяти. Редакция подняла чистый сервер Qdrant 1.19.1 и сняла рабочий набор процесса до и после заливки:

пустой сервер                     73 372 КБ
после 100 000 векторов × 384     248 884 КБ

Сто тысяч векторов стоили 175 512 КБ, то есть около 1,76 КБ на вектор вместе с графом HNSW. При лимите в 1 ГБ оперативной памяти это даёт потолок примерно в 550 000 векторов по 384 измерения. Диск в 4 ГБ вместил бы около 2 000 000 таких векторов, так что упирается бесплатный тариф именно в память. Расход памяти между 100 000 и 550 000 векторов редакция не проверяла: рост графа HNSW не обязан быть линейным, поэтому оценка оптимистичная.

Мини-вывод: бесплатного тарифа Qdrant Cloud хватает на прототип с полумиллионом эмбеддингов; ограничителем выступает 1 ГБ оперативной памяти, тогда как 4 ГБ диска остаются незанятыми.

Что ломается у новичка в Qdrant: открытый порт и слабые эмбеддинги

Первая грабля — безопасность. Документация Qdrant предупреждает без обиняков: «Self-hosted open source deployments are not secure by default and are not production-ready». Раздел про аутентификацию уточняет, что стоит за этой фразой: «By default, all self-deployed Qdrant instances are not secure. They are open to all network interfaces and do not have any kind of authentication configured». Свежий сервер слушает 0.0.0.0 и выполнит любой запрос до него дотянувшегося, включая удаление коллекций. Лечится одной переменной окружения:

$ set QDRANT__SERVICE__API_KEY=zc-demo-key-17092026
$ curl -i http://127.0.0.1:6353/collections
HTTP/1.1 401 Unauthorized
Must provide an API key or an Authorization bearer token

$ curl -i -H "api-key: zc-demo-key-17092026" http://127.0.0.1:6353/collections
HTTP/1.1 200 OK
{"result":{"collections":[]},"status":"ok","time":2.9e-6}

Вторая грабля дороже. Редакция залила в Qdrant 747 текстовых кусков из 18 прочитанных страниц выдачи, посчитав эмбеддинги моделью cointegrated/rubert-tiny2 на 312 измерений (2,5 секунды на CPU, 302,1 куска в секунду). База отработала безупречно и вернула ближайшие векторы за 27,9 мс. Ближайшими они оказались не те: на запрос «сколько стоит облако qdrant» первым пришёл кусок про создание индекса по payload со score 0.6079. Замена свёртки с CLS на усреднение токенов ответ не выправила — первым встал абзац про запуск в Docker. Два других контрольных запроса промахнулись так же.

Вывод относится к любому проекту на векторном поиске: качество ответа задаёт модель эмбеддингов, а база честно отдаёт ближайшие числа. Слабая модель на 312 измерений даёт слабый поиск при любой базе — и это же объясняет, почему сборки вроде Dify и AnythingLLM начинают настройку с выбора модели.

Третья грабля техническая: при штатном пороге indexing_threshold_kb: 10000 мелкие сегменты остаются без HNSW и ищутся перебором. В нашем прогоне на 100 000 точек поле indexed_vectors_count показало 94 000 при points_count 100 000, то есть 6 000 векторов лежали в сегменте ниже порога.

Мини-вывод: перед продом закройте Qdrant ключом, проверьте indexed_vectors_count и убедитесь, что модель эмбеддингов сильнее ruBERT-tiny.

Чек-лист запуска Qdrant

FAQ

Qdrant — это что? Открытая векторная база данных и поисковый движок по векторам, написанный на Rust и распространяемый под лицензией Apache-2.0.

Можно ли запустить Qdrant без Docker? Да. В релизах GitHub лежат готовые бинарники под Windows, Linux и macOS; Windows-сборка v1.19.1 — это один файл qdrant.exe на 85 063 168 байт, который стартует без конфига.

Сколько места занимает Qdrant? По замеру редакции 17.09.2026 на версии 1.19.1: 100 000 векторов по 384 измерения — 540 366 409 байт номинально на NTFS и 210 132 992 байта реально занятых на ext4.

Qdrant бесплатный? Сам сервер — да, Apache-2.0 без ограничений. Облако Qdrant Cloud даёт бесплатный уровень «0.5 vCPU / 1GB RAM/ 4 GB Disk», дальше оплата по фактическому потреблению.

Какие порты использует Qdrant? 6333 — HTTP API и веб-интерфейс, 6334 — gRPC, 6335 — обмен между узлами кластера.

Что лучше: Qdrant или pgvector? pgvector дешевле, пока векторы живут рядом с бизнес-данными в PostgreSQL и их размерность не превышает 2 000. Qdrant выигрывает на фильтрах поверх векторного поиска, квантизации и раздельном масштабировании.