Self-hosted RAG на скала: колко RAM реално изяжда векторен индекс

Всеки RAG туториал работи на лаптоп с няколкостотин документа и се усеща без усилие. После го насочваш към реален корпус — документите на компания, години тикети, knowledge base — и изведнъж паметта е целият разговор.

RAG не мащабира по CPU. Той мащабира по RAM.

Защо индексът иска памет

Извличането работи, като превръща всеки chunk текст в embedding — вектор, дълъг от няколкостотин до няколко хиляди числа. Търсенето значи сравняване на вектора на заявката ти с всички тях, бързо. „Бързо“ е ключовата дума: за ниска латентност индексът трябва да живее в RAM. На диск работи, но всяка заявка плаща наказание, а извличането с ниска латентност беше смисълът на self-hosting-а на първо място.

Така че сметката за памет мащабира с две неща: колко chunks имаш и колко широк е всеки вектор.

Реални числа, грубо

Измери своя — размерността и типът индекс движат това много — но като начална сенсация:

• Няколкостотин хиляди embeddings — комфортно в 2–4 GB. Лична knowledge base, документите на един продукт.
• Ниски милиони — с приложението, клиента на модела и OS-а около него, планирай 16–32 GB. Това е сериозна корпоративна knowledge base или multi-source RAG.
• Десетки милиони, или вектори с висока размерност — сега си на 48–80 GB, и отвъд това през няколко машини. Големи документални имоти, multi-tenant извличане, или държиш няколко индекса топли наведнъж.

Multi-agent система, която държи и голям индекс, натрупва и двата разхода на същата машина — така план от 32 GB се превръща тихо в 64 GB.

Изборът на двигател, накратко

Ако вече пускаш Postgres, pgvector е опцията с най-малко усилие — то е разширение, не нова услуга за бавачене. Когато имаш милиони вектори и искаш бързо филтрирано търсене, специализиран двигател като Qdrant или Weaviate заслужава отделния процес. Не прави over-engineering от първия ден; пусни това, което вече оперираш, и го отдели, когато търсенето реално забави.

Защо да си правиш труда да хостваш сам

Две причини, поради които хората реално правят това, и нито една не е „за да спестя няколко долара“:

Поверителност. Embeddings-ите не са абстрактни — те кодират текста, от който идват. Твоите документи, съдържанието на клиентите ти, вътрешните ти бележки, превърнати във вектори и изпратени на сървъри на трета страна. Self-hosting-ът държи това на машина, която контролираш. Ако данните са достатъчно чувствителни, че също плащаш в crypto без KYC, управляван векторен облак разваля целия смисъл.

Фиксиран разход. Управляваните векторни услуги мерят по съхранени вектори и пуснати заявки. VPS е едно месечно число и можеш да го удряш колкото искаш. На скала, предвидимото бие измереното.

Какво значи това за оразмеряването

Започни, като измериш корпуса си, не като гадаеш. Вземи броя embeddings и размерността, зареди извадка, гледай резидентната памет, екстраполирай. После избери план със запас за индекса плюс всичко около него — приложението, клиента на модела, място за растеж.

За всичко отвъд няколко милиона вектори, държани частно, Pro линията работи от 32 до 80 GB с dedicated IP и нощни архиви, което има значение, когато индексът е продуктът и загубата му боли.