EQVPS

Свой векторный БД для памяти AI-агента на VPS

Jun 15, 2026 · 3 min read · EQVPS Team

AI-агент без памяти обречён заново представляться каждый разговор. Решение — векторная БД: хранит эмбеддинги ваших документов, заметок или прошлых чатов, чтобы агент по запросу вспоминал нужные куски (это «R» в RAG). Можно взять managed-сервис, а можно поднять самому на VPS и держать данные — часто ваши приватные — на машине, которую контролируете вы. Вот как, и что это реально стоит по RAM.

Два хороших варианта

Ничего экзотического не нужно. Два пути покрывают почти всех:

pgvector — расширение Postgres. Если уже крутите Postgres (или не против) — оно добавляет векторный поиск в БД, что у вас уже есть. Один сервис, один бэкап, знакомый SQL. Самый ненапряжный старт с большим отрывом.

Qdrant — профильный векторный движок. Берите, когда много векторов (низкие миллионы+) или нужна быстрая фильтрация по метаданным и отдельный API. Это отдельный сервис, но он сделан ровно под эту задачу.

Для большинства агентов, что встают на ноги, pgvector — правильный первый ответ. К Qdrant переходите, когда переросли, не раньше.

Реальность по RAM (это и недооценивают)

Векторный поиск быстр, потому что индекс живёт в памяти — так что RAM, не диск, ваше реальное ограничение. Грубый ориентир:

Так что берите под индекс, не под файл. (Та же логика, что в общем гайде по sizing — тяжёлое неочевидно, пока не измеришь.)

Быстрый старт: pgvector

На машине с Postgres (Docker проще всего — тот же паттерн, что self-host n8n):

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE memory (
  id bigserial PRIMARY KEY,
  content text,
  embedding vector(1536)        -- под размерность вашей модели эмбеддингов
);

-- когда появятся данные, постройте индекс для быстрого поиска:
CREATE INDEX ON memory USING hnsw (embedding vector_cosine_ops);

Агент вставляет content + его эмбеддинг, затем запрашивает ORDER BY embedding <=> $query_embedding LIMIT 5, чтобы достать ближайшие воспоминания. Это весь цикл.

Хотите Qdrant? Это один Docker-контейнер с HTTP/gRPC API; создаёте коллекцию с размером вектора и upsert'ите точки. Та же идея, профильный движок.

Может ли он делить машину с агентом?

Да — для малых-средних хранилищ запускайте векторную БД на том же VPS, что и агент. Проще, и задержка почти ноль. Разносите по разным серверам, только когда один начинает теснить другой по RAM. Это поздняя приятная проблема, не задача первого дня.

Честные оговорки

В этих рамках self-hosted векторное хранилище — чистый способ дать агенту прочную память, не отдавая приватные данные третьим. Старт с pgvector на 2 ГБ, следите за RAM, и растите в Qdrant или больший тариф, только когда цифры скажут.

FAQ

pgvector или Qdrant — что self-host?

Если уже крутите Postgres (или хотите одну БД и под данные приложения, и под эмбеддинги) — pgvector наименее затратен, это просто расширение. Если у вас миллионы векторов или нужен профильный движок с быстрой фильтрацией — Qdrant стоит отдельного сервиса. Для большинства агентов на старте pgvector на Postgres более чем достаточно.

Сколько RAM нужно векторной БД?

Больше, чем кажется, потому что хороший поиск хочет индекс в памяти. Грубо: пара сотен тысяч эмбеддингов комфортно в 2 ГБ; на низких миллионах закладывайте 4 ГБ+ и тюньте индекс. Старт с 2 ГБ, следите за памятью, увеличивайте, когда поиск замедлится.

Зачем self-host векторное хранилище, а не managed?

Две причины, по которым это реально делают: эмбеддинги часто содержат ваши приватные данные (заметки, документы, клиентский контент), и self-hosted хранилище держит это на сервере, который вы контролируете. И это фикс-цена — managed-сервис берёт за векторы и запросы, а VPS — одно число в месяц без счётчика за запрос.

Могут ли векторная БД и агент жить на одном VPS?

Да, для малых-средних нагрузок — разместить агента и pgvector/Qdrant на одной машине просто и режет задержку почти в ноль. Разносите по разным серверам, только когда один начинает отнимать RAM у другого — это приятная проблема на потом, не забота первого дня.

Эмбеддинги едят много диска?

Один эмбеддинг — пара килобайт, так что миллион — это несколько гигабайт плюс накладные индекса: ощутимо, но не огромно. 25–45 ГБ диска покрывают солидное хранилище памяти для большинства агентов. RAM, не диск, обычно первый лимит, в который упираешься.

← Back to blogSee plans & pricing →