Qdrant / Vector DB на VPS: как запустить AI-поиск и не упереться в RAM, диск и индексы

Vector DB нужна не “для модного AI”, а для конкретной задачи: искать по смыслу, находить похожие документы, строить RAG, делать AI-поиск по базе знаний, товарам, тикетам, логам, статьям, PDF, описаниям услуг или пользовательскому контенту. Qdrant хорошо подходит для таких задач, но на VPS он требует нормального расчёта. Ошибка — поставить vector DB на маленький сервер, залить embeddings и ждать, что всё будет работать как обычная SQL-база.

Главная боль владельца проекта обычно не в установке Qdrant. Установить контейнер легко. Боль начинается позже: RAM быстро растёт, импорт векторов падает по OOM, поиск с фильтрами тормозит, payload indexes занимают память, Docker volume не был смонтирован и данные потерялись, snapshots лежат на том же диске, embedding model поменяли и всё нужно переиндексировать, а API Qdrant случайно открыт в интернет без ключа.

Эта статья — практический checklist для Qdrant / vector DB на VPS: когда VPS подходит, сколько ресурсов закладывать, какие ошибки чаще всего встречаются, что проверить до заказа и когда лучше сразу смотреть не на VPS, а на dedicated server.

Когда Qdrant на VPS — нормальное решение

Qdrant на VPS подходит, если вам нужен AI-поиск для сайта, базы знаний, FAQ, каталога товаров, внутренней документации, CRM, тикетов поддержки, личного кабинета, RAG-проекта, прототипа AI assistant, semantic search API или небольшого production-сервиса.

Нормальная схема обычно выглядит так:

• Application/API получает запрос пользователя.
• Embedding model превращает запрос и документы в векторы.
• Qdrant хранит vectors + payload и ищет похожие объекты.
• Payload filters ограничивают поиск по project_id, language, user_id, category, status, date или другим полям.
• Backend получает top-k результатов и отдаёт их пользователю или LLM.
• Backup/snapshots защищают коллекции от потери данных.
• Monitoring показывает RAM, disk, latency, количество points, ошибки API и состояние snapshots.

Для небольшого AI-поиска можно начать с VPS Hostyrex: https://hostyrex.net/ru/vps.html. Если проект уже production, коллекции большие, векторов много или важна стабильная задержка, лучше заранее обсудить конфигурацию: https://hostyrex.net/ru/contacts.html.

Что люди реально ищут, когда vector DB начинает тормозить

Обычно человек не ищет “купить VPS для Qdrant”. Он ищет конкретную проблему:

• Qdrant на VPS
• Vector DB на VPS
• Qdrant memory usage
• Qdrant on_disk не снижает RAM
• Qdrant HNSW index memory
• Qdrant payload index slow filter
• Qdrant Docker volume data lost
• Qdrant snapshot backup restore
• Qdrant OOM during bulk upload
• Qdrant slow search with filters
• Qdrant сколько RAM нужно
• Vector database for RAG self-hosted

Это значит, что статья должна отвечать не “как установить Qdrant”, а “как не выбрать слабый VPS и не потерять данные после первого нормального импорта”.

Главная ошибка: считать только размер embeddings

Многие считают так: “у меня 1 миллион документов, embedding 768 dimensions, значит 1 000 000 × 768 × 4 bytes — примерно 3 GB, значит VPS 4 GB RAM хватит”. Это опасно упрощённый расчёт.

Почему так считать нельзя:

• сами vectors — это только часть данных;
• HNSW index тоже занимает ресурсы;
• payload хранит метаданные;
• payload indexes занимают дополнительную память и диск;
• Qdrant хранит служебную информацию по points;
• операционная система использует page cache;
• bulk ingestion временно требует больше ресурсов;
• snapshots и optimizer тоже создают нагрузку;
• если рядом API, Redis, Postgres или embedding worker — они тоже едят RAM.

Vector DB — это не просто “таблица float”. Если вы используете фильтры, payload, named vectors, hybrid search, sparse vectors, quantization или несколько коллекций, расчёт усложняется.

Сколько ресурсов нужно для Qdrant VPS

Универсального ответа нет. Ресурсы зависят от количества vectors, размерности embedding, типа хранения, HNSW-настроек, payload indexes, фильтров, количества запросов, записи, batch import и требований к latency.

Практический ориентир:

• 2 vCPU / 4 GB RAM — dev, тест, маленький semantic search, небольшая база знаний, прототип RAG без тяжёлого ingestion.
• 4 vCPU / 8 GB RAM — небольшой production AI-поиск, десятки/сотни тысяч vectors, аккуратные payload indexes, NVMe, backup и monitoring.
• 4–8 vCPU / 16 GB RAM — более серьёзный Qdrant под RAG, несколько коллекций, фильтры, активный ingest, больше headroom под optimizer и page cache.
• 8+ vCPU / 32+ GB RAM — большой production, миллионы vectors, активные фильтры, высокая конкуренция запросов, несколько приложений или длинный retention данных.

Если у вас уже миллионы vectors, высокие требования к latency, много одновременных запросов, тяжёлые фильтры, hybrid search или постоянный ingestion, VPS может быть временным решением. Для стабильного production лучше смотреть dedicated server: https://hostyrex.net/ru/servers.html.

RAM: почему Qdrant может “есть больше, чем ожидали”

Реальная частая жалоба: “Я включил on_disk, но RAM всё равно растёт”. Это не всегда баг. Нужно понимать, что vector data, HNSW index, payload, payload indexes, mmap/page cache и служебные структуры — разные части системы. Перенос vectors на диск не означает, что вообще всё перестанет использовать память.

Что важно:

• on_disk: true для vectors снижает давление от raw vectors на RAM, но не отменяет остальные структуры.
• HNSW index может иметь отдельную настройку хранения.
• Payload indexes нужны для быстрых фильтров, но они не бесплатные.
• ОС может показывать высокое использование памяти из-за page cache — это не всегда проблема.
• Bulk import может требовать больше памяти, чем обычный search.
• Optimizer и rebuild индексов могут временно увеличить нагрузку.

Плохой подход — паниковать из-за любого роста RAM. Хороший подход — смотреть, есть ли OOM, swap, major page faults, рост latency, ошибки API, падения контейнера и постоянное давление на память.

Disk / NVMe: для vector DB это критично

Если vectors или indexes частично живут на диске, диск становится частью performance. Для Qdrant под AI-поиск нужен быстрый локальный SSD/NVMe. Медленный диск может дать плохую задержку даже при нормальном CPU.

Что проверить перед заказом VPS:

• NVMe или обычный SSD;
• достаточно ли места под коллекции, snapshots и временные операции;
• что будет при росте базы в 2–3 раза;
• есть ли мониторинг свободного места;
• куда будут сохраняться snapshots;
• не лежит ли backup только на том же диске;
• какой профиль нагрузки: много чтения, много записи или смешанный.

Для vector DB опасно выбирать VPS только по CPU/RAM. Если диск медленный или место быстро заканчивается, AI-поиск начнёт тормозить, snapshots перестанут создаваться, а восстановление станет проблемой.

Docker: самая частая ошибка — забыть volume

Qdrant часто запускают в Docker. Это нормально. Ошибка — запустить контейнер без постоянного volume. Тогда данные могут исчезнуть при удалении контейнера, пересоздании или неудачном обновлении.

Для теста команда может выглядеть просто, но для production обязательно нужно монтировать storage:

docker run -d \
  --name qdrant \
  -p 127.0.0.1:6333:6333 \
  -p 127.0.0.1:6334:6334 \
  -v /opt/qdrant/storage:/qdrant/storage \
  qdrant/qdrant

Важные моменты:

• не публикуйте Qdrant на 0.0.0.0, если доступ должен быть только локальным;
• используйте volume для /qdrant/storage;
• не храните production-data внутри ephemeral container layer;
• проверяйте права на storage-директорию;
• перед обновлением делайте snapshot/backup;
• не обновляйте контейнер вслепую без rollback-плана.

Порты и безопасность: Qdrant нельзя просто открыть в интернет

Qdrant API — это прямой доступ к вашей vector database. Если открыть его публично без API key, любой, кто достучится до порта, может читать, писать или удалять данные в зависимости от конфигурации и доступных endpoints.

Для одного VPS обычно безопаснее так:

• Qdrant слушает 127.0.0.1 или приватный интерфейс.
• Приложение обращается к Qdrant локально.
• Наружу открыт только backend API, а не сам Qdrant.
• Если Qdrant нужен снаружи — включить API key, TLS и ограничить IP.
• Порты 6333, 6334, 6335 не должны быть публичными без необходимости.

Для обычного AI-поиска наружу чаще нужен не Qdrant, а ваше приложение: например, backend endpoint /search. Сам Qdrant должен быть внутренним сервисом.

Если проект связан с пользовательским контентом, scraping, proxy, массовым AI-парсингом, большим трафиком или спорной нагрузкой, заранее проверьте условия использования и abuse policy: https://hostyrex.net/ru/terms.html.

Payload indexes: почему поиск с фильтрами тормозит

AI-поиск почти всегда использует фильтры. Например:

• искать только по конкретному пользователю;
• искать только по project_id;
• искать только по языку;
• искать только по категории;
• искать только по опубликованным документам;
• искать только по дате или статусу.

Ошибка — загрузить payload и думать, что фильтры автоматически будут быстрыми. Для полей, по которым вы реально фильтруете, нужны payload indexes. Но индексировать всё подряд тоже плохо: каждый индекс занимает ресурсы.

Практическое правило:

• индексируйте поля, которые часто используются в фильтрах;
• не индексируйте большие текстовые поля “на всякий случай”;
• сначала подумайте о cardinality: project_id, user_id, tenant_id, language, status, category;
• если фильтр резко сужает выборку, payload index особенно полезен;
• если фильтр почти ничего не отсекает, пользы может быть меньше;
• следите за RAM/disk после добавления индексов.

Частая проблема RAG-проектов: данные лежат в одной коллекции для всех клиентов, но нет нормального индекса по tenant_id или project_id. В итоге фильтрация становится дорогой, а поиск тормозит.

Embedding size: размерность влияет на стоимость VPS

Чем больше dimension у embedding, тем больше памяти и диска нужно. 384, 768, 1024, 1536, 3072 dimensions — это разные бюджеты хранения и поиска. Иногда команда берёт “самую мощную” embedding model, хотя качество на задаче почти не растёт, а стоимость инфраструктуры увеличивается.

Перед запуском спросите себя:

• какая embedding model используется;
• какая размерность vectors;
• сколько документов будет через 3 месяца;
• сколько chunks создаётся из одного документа;
• нужно ли хранить несколько embeddings на один объект;
• будет ли hybrid search: dense + sparse;
• нужен ли reranking после vector search;
• можно ли использовать меньшую модель без потери качества.

Одна из скрытых ошибок AI-поиска — считать документы, а не chunks. Если у вас 50 000 PDF, после chunking это может стать 500 000 или 2 000 000 vectors. VPS нужно считать по vectors, а не по исходным файлам.

Bulk ingestion: почему импорт падает, хотя поиск потом лёгкий

Импорт vectors может быть тяжелее, чем обычный поиск. Во время массовой загрузки Qdrant создаёт segments, строит индексы, пишет данные, оптимизирует структуру хранения. Если сразу заливать миллионы points на маленький VPS, можно получить OOM, высокий disk I/O, долгий optimizer backlog и нестабильный API.

Что помогает:

• загружать batches контролируемого размера;
• не строить тяжёлый index в самый пик ingestion, если можно отложить;
• использовать on-disk storage, если RAM ограничена;
• создать важные payload indexes до массовой загрузки, если понятно, какие фильтры будут нужны;
• не запускать embedding generation и Qdrant ingestion на одном маленьком VPS без расчёта;
• следить за RAM, disk, CPU, optimizer status и latency во время импорта;
• делать snapshots после успешного крупного импорта.

Отдельная ошибка — генерировать embeddings на том же VPS, где работает Qdrant и backend. Если embedding generation тяжёлая, она может забрать CPU/RAM и сделать поиск медленным. Для production лучше разделять ingestion pipeline и query serving хотя бы логически, а при росте — физически.

Snapshots и backup: snapshot на том же VPS — не защита

Qdrant snapshots удобны для архивирования, переноса и восстановления коллекций. Но snapshot, который лежит на том же диске, что и основная база, не является полноценным backup. Если диск заполнен, сервер удалён, VPS скомпрометирован или файловая система повреждена, snapshot может пропасть вместе с данными.

Минимальный backup-план:

• регулярно создавать snapshots для важных коллекций;
• выгружать snapshots вне основного VPS;
• хранить несколько копий, а не один перезаписываемый файл;
• делать snapshot перед крупным reindex, изменением embedding model или обновлением Qdrant;
• проверять восстановление на тестовом сервере;
• учитывать, что snapshots занимают место и могут нагружать диск.

Если коллекции большие, snapshots тоже будут большими. Это нужно учитывать при выборе диска. Нельзя брать VPS “ровно под данные” без места на backup, временные файлы и рост.

Обновление embedding model: скрытая миграция всей базы

В обычной базе можно добавить колонку и жить дальше. В vector DB смена embedding model часто означает, что старые vectors больше нельзя корректно сравнивать с новыми. Если вы перешли с одной модели на другую, может потребоваться переиндексация всей коллекции.

Что нужно продумать заранее:

• будет ли новая модель иметь другую размерность;
• можно ли хранить старые и новые vectors параллельно;
• нужны ли named vectors;
• как переключить поиск без простоя;
• сколько времени займёт пересчёт embeddings;
• хватит ли диска на временное хранение двух наборов vectors;
• что делать с cache и результатами старого поиска.

Если AI-поиск важен для бизнеса, embedding model нельзя менять “вечером на production” без плана. Это полноценная миграция данных.

Hybrid search: качество выше, но инфраструктура сложнее

Для многих задач чистый semantic search даёт хорошие результаты, но не всегда. Иногда нужен hybrid search: dense vectors + keyword/sparse search + filters + reranking. Это может повысить качество поиска, но усложняет инфраструктуру.

Что меняется:

• хранится больше типов vectors;
• появляются sparse vectors или дополнительные indexes;
• нужен reranker, который потребляет CPU/GPU/API-бюджет;
• latency запроса становится выше;
• нужно мониторить не только Qdrant, но и весь retrieval pipeline;
• больше данных — больше backup и больше диск.

Если вам нужен простой поиск по базе знаний, не начинайте сразу с самой сложной архитектуры. Сначала проверьте качество на небольшом наборе данных, измерьте latency, recall и стоимость ресурсов.

Monitoring: что отслеживать у Qdrant на VPS

Без monitoring владелец узнаёт о проблеме, когда AI-поиск уже не отвечает или пользователи получают плохие результаты.

Минимум, который нужно отслеживать:

• доступность Qdrant API;
• latency search-запросов;
• HTTP/gRPC errors;
• RAM и swap;
• CPU load;
• disk usage;
• disk I/O и iowait;
• количество collections;
• количество points/vectors;
• рост storage;
• успешность snapshots;
• время bulk ingestion;
• optimizer status;
• количество открытых file descriptors и mmap;
• наличие OOM events в kernel logs.

Qdrant отдаёт metrics, которые можно подключить к Prometheus/Grafana. Но даже без сложного стека нужно хотя бы следить за сервером: диск, RAM, swap, CPU, контейнер, API health и snapshots.

Когда VPS не подходит

VPS подходит для старта, теста, MVP и небольшого production. Но он не всегда правильный выбор.

Лучше смотреть на dedicated server или отдельную архитектуру, если:

• коллекции уже измеряются миллионами vectors;
• нужна стабильная низкая latency;
• много одновременных search-запросов;
• идёт постоянный ingestion новых документов;
• есть hybrid search, reranking, sparse vectors;
• нужны большие payload indexes;
• данные активно растут;
• нужен кластер или репликация;
• один VPS уже держит backend, Postgres, Redis, workers и Qdrant;
• простой AI-поиска влияет на продажи или поддержку;
• нужно больше контроля над NVMe, CPU и RAM.

В таких случаях смотрите dedicated servers: https://hostyrex.net/ru/servers.html. Если нужна отдельная сеть, IPv4, приватный routing или доступ между несколькими узлами, смотрите IPv4 и сетевые услуги: https://hostyrex.net/ru/ip.html.

Что проверить перед заказом VPS под Qdrant

• Сколько vectors будет на старте?
• Сколько vectors будет через 3–6 месяцев?
• Какая размерность embeddings?
• Сколько chunks получается из одного документа?
• Нужен dense search, sparse search или hybrid search?
• Какие payload fields будут использоваться в фильтрах?
• Какие поля нужно индексировать?
• Нужен on-disk storage или всё должно быть в RAM?
• Какой latency считается нормальным?
• Сколько search-запросов в секунду ожидается?
• Будет ли массовый ingestion?
• Где будет работать embedding generation?
• Будет ли Qdrant доступен только локально или из внешних сервисов?
• Нужны ли API key, TLS, IP allowlist?
• Где будут храниться snapshots?
• Кто будет обновлять Qdrant?
• Что делать при смене embedding model?
• Нужен ли managed support?

Если вы не уверены, какой VPS нужен, не выбирайте минимальный тариф вслепую. Опишите задачу: количество документов, chunks, embedding dimension, ожидаемые QPS, фильтры, retention, snapshots и где будет работать backend. Связаться с Hostyrex можно здесь: https://hostyrex.net/ru/contacts.html.

Короткий production checklist Qdrant на VPS

• Qdrant storage смонтирован в persistent volume.
• Данные не лежат только внутри Docker container layer.
• VPS имеет NVMe/SSD и запас по диску.
• RAM рассчитана не только под vectors, но и под indexes, payload, page cache и ingestion.
• Qdrant не открыт публично без API key.
• Если доступ внешний — включены TLS, API key и firewall/IP allowlist.
• Порты 6333/6334/6335 не торчат наружу без необходимости.
• Payload indexes созданы только для реально используемых фильтров.
• Bulk ingestion делается batches, а не бесконтрольным потоком.
• Snapshots создаются регулярно.
• Snapshots выгружаются вне основного VPS.
• Перед reindex, update и сменой embedding model есть backup.
• Monitoring проверяет RAM, swap, disk, latency, errors, collections, points и snapshots.
• Есть план роста: upgrade VPS, перенос на dedicated или разделение backend/Qdrant.

Как Hostyrex может помочь с Qdrant / Vector DB

Hostyrex предоставляет VPS для Qdrant, vector database, AI-поиска, RAG, semantic search API, embedding storage, backend-сервисов и тестовых AI-инфраструктур. Для небольшого проекта можно начать с VPS: https://hostyrex.net/ru/vps.html. Если коллекции большие, важна стабильная latency, нужен отдельный NVMe и больше контроля над ресурсами, лучше рассмотреть dedicated server: https://hostyrex.net/ru/servers.html.

Если задача нестандартная, лучше сначала описать её до оплаты: сколько vectors, какая размерность embeddings, какие фильтры, сколько запросов, нужен ли hybrid search, где будет backend и как планируется backup. Контакты: https://hostyrex.net/ru/contacts.html. Если нужно администрирование, перенос или сопровождение, смотрите managed services: https://client.hostyrex.net/store/managed-services.

FAQ

Можно ли запустить Qdrant на VPS?

Да. Qdrant можно запускать на VPS, если правильно рассчитать RAM, диск, storage mode, indexes, backup и доступ. Для тестов и небольшого AI-поиска VPS подходит хорошо. Для больших коллекций и стабильной production latency лучше рассматривать dedicated server.

Сколько RAM нужно для Qdrant?

Зависит от количества vectors, размерности embeddings, HNSW, payload indexes, storage mode и нагрузки. Для теста может хватить 4 GB RAM. Для небольшого production лучше смотреть 8–16 GB RAM. Для миллионов vectors и активного поиска часто нужно 32 GB RAM и выше или dedicated server.

Почему Qdrant использует много памяти?

Память используют не только raw vectors. Есть HNSW index, payload, payload indexes, служебные структуры, mmap/page cache, ingestion и optimizer. Поэтому включение on_disk не означает, что RAM перестанет расти.

Что значит on_disk в Qdrant?

on_disk позволяет хранить vectors на диске через disk-backed/memmap storage, чтобы снизить давление на RAM. Но indexes и payload могут иметь отдельные настройки. Если нужно реально снижать память, нужно смотреть всю конфигурацию коллекции, а не один параметр.

Почему поиск с фильтрами в Qdrant тормозит?

Часто нет payload index по полю, которое используется в фильтре. Например, поиск по project_id, tenant_id, language или status без индекса может быть медленнее. Но индексировать все поля подряд тоже не нужно: indexes занимают ресурсы.

Нужен ли NVMe для vector DB?

Для production — желательно. Если vectors или indexes частично работают с диском, NVMe/SSD сильно важнее, чем кажется. Медленный диск ухудшает latency, ingestion, snapshots и восстановление.

Можно ли держать Qdrant, backend и Postgres на одном VPS?

Для маленького проекта — можно. Но нужно считать ресурсы всех сервисов вместе. Если backend, Postgres, Redis, embedding worker и Qdrant живут на одном маленьком VPS, нехватка RAM или disk I/O появится быстро.

Нужно ли открывать порт Qdrant в интернет?

Обычно нет. Лучше держать Qdrant на localhost или приватном интерфейсе, а наружу отдавать только backend API. Если Qdrant должен быть доступен извне, нужны API key, TLS, firewall и желательно IP allowlist.

Как делать backup Qdrant?

Для коллекций можно использовать snapshots. Но snapshot нужно выгружать вне основного VPS. Snapshot на том же диске — это удобная локальная копия, но не полноценная защита от потери сервера или диска.

Что будет, если поменять embedding model?

Часто нужно пересчитать vectors и переиндексировать коллекцию. Если новая модель имеет другую размерность, старую коллекцию нельзя просто продолжать использовать как раньше. Нужно планировать миграцию, временное хранение двух наборов vectors и переключение поиска.

Когда VPS уже не подходит для Qdrant?

Когда коллекции большие, запросов много, latency критична, идёт постоянный ingestion, используются hybrid search/reranking, payload indexes растут, а Qdrant делит ресурсы с backend и базой. Тогда лучше перейти на dedicated server или отдельную архитектуру.

Что спросить у провайдера перед заказом VPS под Qdrant?

Уточните CPU, RAM, NVMe, объём диска, возможность upgrade, backup, firewall, локацию, условия по трафику, managed support и подходит ли конфигурация под ваше количество vectors, размерность embeddings, фильтры и ожидаемые QPS.