pgvector hay Qdrant — tôi nên tự host cái nào?

Nếu bạn đã chạy Postgres (hoặc muốn một cơ sở dữ liệu cho cả dữ liệu ứng dụng và embedding), pgvector là lựa chọn ít công sức nhất — nó chỉ là một extension. Nếu bạn có hàng triệu vector hoặc muốn một engine chuyên dụng với lọc nhanh, Qdrant đáng có dịch vụ riêng. Cho hầu hết các agent mới bắt đầu, pgvector trên Postgres là dư dả.

Một cơ sở dữ liệu vector cần bao nhiêu RAM?

Nhiều hơn bạn đoán, vì tìm kiếm tốt muốn chỉ mục trong bộ nhớ. Một quy tắc đại khái: vài trăm nghìn embedding nằm thoải mái trong 2 GB; một khi bạn đạt vài triệu, lên kế hoạch cho 4 GB+ và tinh chỉnh chỉ mục. Bắt đầu ở 2 GB, xem bộ nhớ, đổi kích cỡ khi tìm kiếm chậm.

Vì sao tự host một vector store thay vì một cái có quản lý?

Hai lý do người ta thực sự làm: các embedding của bạn thường chứa dữ liệu riêng tư của bạn (ghi chú, tài liệu, nội dung khách hàng), và một store tự host giữ điều đó trên một máy chủ bạn kiểm soát. Và nó chi phí cố định — một dịch vụ vector có quản lý tính tiền theo vector và truy vấn, trong khi một VPS là một con số hàng tháng không đo theo truy vấn.

Một vector DB và agent của tôi có thể chạy trên cùng một VPS không?

Có, cho các khối lượng công việc nhỏ đến vừa — đặt chung agent và một instance pgvector/Qdrant trên một cỗ máy đơn giản và cắt độ trễ xuống gần bằng không. Tách chúng ra các máy chủ riêng chỉ khi một cái bắt đầu bỏ đói cái kia về RAM, vốn là một vấn đề đáng có sau này, không phải một lo lắng ngày đầu.

Các embedding có ngốn nhiều đĩa không?

Một embedding đơn là vài kilobyte, nên một triệu cái là vài gigabyte cộng chi phí phụ chỉ mục — đáng kể nhưng không khổng lồ. 25–45 GB đĩa bao phủ một store bộ nhớ đáng kể cho hầu hết các agent. RAM, không phải đĩa, thường là giới hạn đầu tiên bạn chạm.

Host một cơ sở dữ liệu vector cho bộ nhớ AI agent trên một VPS

Một AI agent không có bộ nhớ bị kẹt tự giới thiệu lại mỗi cuộc hội thoại. Cách sửa là một cơ sở dữ liệu vector — nó lưu các embedding của tài liệu, ghi chú hay các chat trước của bạn để agent có thể nhớ lại các phần liên quan theo yêu cầu (đó là chữ "R" trong RAG). Bạn có thể thuê nó như một dịch vụ có quản lý, hoặc bạn có thể tự chạy nó trên một VPS và giữ dữ liệu của bạn — vốn thường là dữ liệu riêng tư của bạn — trên một cỗ máy bạn kiểm soát. Đây là cách, và nó thực sự tốn bao nhiêu RAM.

Hai lựa chọn tốt

Bạn không cần gì kỳ lạ. Hai con đường bao phủ gần như mọi người:

pgvector — một extension Postgres. Nếu bạn đã chạy Postgres (hoặc vui vẻ làm vậy), cái này thêm tìm kiếm vector vào cơ sở dữ liệu bạn đã có. Một dịch vụ, một sao lưu, SQL bạn biết. Khởi đầu ít công sức nhất với khoảng cách lớn.

Qdrant — một engine vector chuyên dụng. Với tới nó khi bạn có nhiều vector (vài triệu+) hoặc muốn lọc metadata nhanh và một API chuyên dụng. Nó là một dịch vụ riêng để chạy, nhưng nó được xây cho chính công việc này.

Cho hầu hết các agent đang tìm chỗ đứng, pgvector là câu trả lời đầu tiên đúng. Chuyển sang Qdrant khi bạn đã vượt quá nó, không phải trước đó.

Thực tế RAM (đây là phần người ta đánh giá thấp)

Tìm kiếm vector nhanh vì chỉ mục sống trong bộ nhớ — nên RAM, không phải đĩa, là ràng buộc thật của bạn. Một hướng dẫn đại khái:

Vài trăm nghìn embedding — thoải mái trong 2 GB.
Vài triệu — lên kế hoạch cho 4 GB+ và tinh chỉnh chỉ mục.
Đĩa là phần dễ: một triệu embedding chỉ là vài GB, nên 25–45 GB bao phủ một store nghiêm túc.

Nên chọn kích cỡ cho chỉ mục, không phải tập tin. (Cùng logic như hướng dẫn chọn kích cỡ chung — thứ nặng không rõ ràng cho tới khi bạn đo.)

Bắt đầu nhanh: pgvector

Trên một cỗ máy với Postgres (Docker dễ nhất — cùng mẫu như tự host n8n):

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE memory (
  id bigserial PRIMARY KEY,
  content text,
  embedding vector(1536)        -- khớp số chiều của mô hình embedding của bạn
);

-- sau khi bạn có dữ liệu, xây một chỉ mục cho tìm kiếm nhanh:
CREATE INDEX ON memory USING hnsw (embedding vector_cosine_ops);

Agent của bạn chèn content + embedding của nó, rồi truy vấn với ORDER BY embedding <=> $query_embedding LIMIT 5 để kéo các bộ nhớ gần nhất. Đó là toàn bộ vòng lặp.

Thích Qdrant? Nó là một container Docker đơn phơi bày một API HTTP/gRPC; bạn tạo một collection với kích cỡ vector của bạn và upsert các điểm. Cùng ý tưởng, engine chuyên dụng.

Nó có thể chia sẻ một cỗ máy với agent không?

Có — cho các store bộ nhớ nhỏ-đến-vừa, chạy vector DB trên cùng VPS với agent. Nó đơn giản hơn và độ trễ về cơ bản bằng không. Tách chúng ra các máy chủ riêng chỉ khi một cái bắt đầu chen cái kia ra khỏi RAM. Đó là một quyết định sau, vấn-đề-đáng-có, không phải một cái ngày đầu.

Các lưu ý trung thực

RAM là bức tường, và nó im lặng. Tìm kiếm giữ nhanh cho tới khi chỉ mục không còn vừa trong bộ nhớ, rồi nó xuống cấp. Xem bộ nhớ và đổi kích cỡ trước khi nó cắn — đừng chờ các truy vấn chậm nói cho bạn.
Các embedding tốn token để tạo. Mỗi tài liệu bạn embed là một lệnh gọi API tới một mô hình embedding. Store rẻ để host; tạo các vector là chi phí định kỳ — liên quan tới chạy một agent thực sự tốn gì.
Sao lưu nó. Bộ nhớ của agent bạn là dữ liệu như bất kỳ cái nào khác. Nếu nó quan trọng, snapshot nó.

Trong đó, một vector store tự host là một cách sạch để cho một agent bộ nhớ bền bỉ mà không giao dữ liệu riêng tư của bạn cho một bên thứ ba. Bắt đầu với pgvector trên một cỗ máy 2 GB, để mắt tới RAM, và lớn lên thành Qdrant hoặc một gói lớn hơn chỉ khi các con số bảo bạn.