EQVPS

VPS за self-hosted RAG на мащаб

Retrieval-augmented generation спира да е демо на лаптоп, щом корпусът стане реален. Vector индекс иска RAM, а embeddings-ите ти са твоите частни данни. Ето математиката за оразмеряване и защо high-memory, no-KYC хостинг приляга. От $55/месец.

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

Ето частта, която повечето хостинг страници пропускат: бързият retrieval иска индекса в RAM. Всеки chunk текст става embedding — вектор с ширина от няколко стотин до няколко хиляди числа — и търсенето значи сравняване на заявката ти срещу всички тях, бързо. На диск работи, но всяка заявка плаща такса за латентност, а нископатентният retrieval беше причината да хостваш сам на първо място.

Математиката за оразмеряване, честно

Измери собствения си корпус — размерността и типът индекс люлеят това доста — но като отправен усет:

Написахме пълната RAM крива тук, ако искаш детайлите.

Защо high-memory и no-KYC заедно

Наемането на 48 GB RAM е лесно. Наемането му с crypto и без проверка за самоличност не е — повечето хостове, които продават сериозна памет евтино, го правят зад карта и KYC формуляр. Embeddings-ите ти не са абстрактни числа; те кодират текста, от който са дошли. Твоите документи, съдържанието на клиентите ти, превърнати във вектори. Ако тези данни са достатъчно чувствителни, че плащаш частно, managed vector облак разваля целия смисъл — и същото прави хост, който връзва сървъра със самоличността ти.

Тази комбинация — висока памет, dedicated IP, crypto, без KYC, нощни backup-и — е това, за което Pro линията е. Тя не е най-евтината на гигабайт, и ако не се нуждаеш от поверителност, можеш да намериш RAM по-евтино другаде. Но ако индексът е продуктът ти и не може да напусне, това е формата, която приляга.

Откъде да започнеш

Избери план със запас за индекса плюс всичко около него — приложението, model клиента, място за растеж. За повечето реални корпуси това е Pro-48 (48 GB); голям отива на Pro-64 или Pro-80. Зареди проба първо, гледай паметта, оразмери от числото, което си измерил — не от това, от което си се страхувал.

Ако retrieval-ът ти е част от по-голяма агентска система, същата машина често държи и агентския флот — така план от 48 GB тихо става такъв от 64 GB.

Готов за deploy? Плати в crypto, без KYC — онлайн за около минута.

Deploy-ни сега →

Въпроси

Колко RAM реално се нуждае RAG настройката ми?

Тя мащабира с броя embeddings и ширината на векторите. Няколко стотин хиляди chunks се събират в 2–4 GB; ниски милиони, с приложението и OS-а около тях, кацат на 16–32 GB; десетки милиони бутат 48 GB и отвъд. Измери проба, гледай resident паметта, екстраполирай — не гадай високо, просто ще надплатиш.

Защо да не използвам managed vector услуга?

Две причини, поради които хората реално хостват сами: embeddings-ите ти кодират частни данни (документи, бележки, клиентско съдържание), така че държането им на машина, която контролираш, има значение; и цената е плоска — managed услуга измерва по вектори и заявки, VPS е едно месечно число, което можеш да удряш колкото искаш.

pgvector или dedicated engine?

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

Нужен ли ми е GPU за RAG?

Не. Retrieval-ът е CPU + RAM работа — сравняване на вектори, не генериране на текст. Генериращата стъпка извиква LLM-а ти (API, или отделен model хост). High-memory CPU машина е точно правилната форма за retrieval половината.

Коментари

Още няма коментари. Бъди първият.

Остави коментар

Коментарите се модерират преди да се появят.