Какъв VPS за изкуствен интелект: API или модел на сървъра

Две нужди, два размера сървър

Повечето приложения, които „използват AI“ (асистенти, агенти, резюмета, извличане на данни, търсене в документи), извикват модел, хостван от неговия създател, през API. Изчислението се извършва при него; вашият сървър подготвя заявката, чака отговора и го обработва. Тогава той се оразмерява като всяко уеб приложение: според езика, базата данни и броя на едновременните потребители.

Другият случай е модел, изпълняван на самия сървър, с Ollama, llama.cpp или Python библиотека. Причините са известни: данни, които остават във вашата инфраструктура, фиксиран разход независимо от броя на заявките, фонова обработка на големи обеми, специализиран модел. Тук целият модел трябва да се побере в паметта и именно той определя размера.

През API: оразмерете приложението, а не модела

Заявка към модел през API трае от една до няколко десетки секунди, особено когато отговорът се изпраща поточно (streaming). През това време вашият сървър почти не изчислява: той чака. Важна е способността му да държи много заявки в изчакване, без да блокира останалите:

• Асинхронен сървър: Node.js, FastAPI с Uvicorn или асинхронни worker процеси на Gunicorn. Синхронен worker, който чака отговор 20 секунди, е worker, блокиран за всички останали посетители.
• Опашка от задачи за дългите обработки (резюме на документ, анализ на партида): заявката на посетителя получава отговор веднага, а worker обработва задачата във фонов режим.
• Настроени времена за изчакване на проксито: по подразбиране Nginx прекъсва отговор, който мълчи повече от 60 секунди (proxy_read_timeout).

Паметта, която да предвидите, е тази на приложението и на базата му: 4 GB покриват приложение на Python или Node.js с PostgreSQL при старта. Една често срещана конфигурация, интерфейс на Next.js, API на FastAPI и база PostgreSQL, които извикват модел през API, се побира в 6 до 8 GB, включително компилирането на интерфейса.

Embeddings и векторно търсене: паметта за векторите

Приложение, което търси във вашите документи (RAG, retrieval-augmented generation), превръща всеки откъс във вектор, след това намира най-близките до даден въпрос. Две неща за оразмеряване:

• Моделът за embeddings, ако работи при вас: популярните модели заемат от 100 MB до 1,5 GB и изчисляват на процесор без затруднение. all-MiniLM-L6-v2 например заема по-малко от 100 MB.
• Векторите: с pgvector един вектор заема 4 байта на измерение, плюс 8. Един милион откъса с 1 536 измерения представляват около 6 GB данни, към които се добавя HNSW индексът, който ускорява търсенето. За бързо търсене индексът и векторите, които се търсят, трябва да се побират в паметта.

Типът halfvec на pgvector съхранява всяко измерение в 2 байта вместо в 4: половината памет, при качество на търсенето, което остава много близко.

Модел на сървъра: първо паметта

Езиковият модел е файл с тегла, който се зарежда изцяло в паметта, за да отговаря. Размерът му зависи от броя на параметрите и от квантизацията, точността, с която се съхранява всяко тегло. Форматът GGUF, този на llama.cpp и Ollama, предлага квантизации от 2 до 16 бита; вариантът Q4_K_M, около 4 бита, е обичайният компромис между размер и качество.

Към теглата се добавят още две неща:

• Контекстът (KV кешът): всеки токен от текущия разговор заема памет. За Llama 3.1 8B пресметнете около 128 KB на токен при 16-битова точност, тоест 1 GB за контекст от 8 000 токена, и още толкова за всеки разговор, обработван паралелно.
• Останалата част от сървъра: система, приложение, база данни, както при всяко уеб приложение.

Пример. Llama 3.1 8B на 4 бита, два едновременни разговора от 8 000 токена и малко приложение: 5 GB за модела, 2 GB за контекста, 2 GB за приложението и системата, общо 9 GB, и около 12 GB с 25 % резерв.

На процесор: какво определя скоростта

За да генерира всеки токен, моделът прочита отново всичките си тегла в паметта. На процесор скоростта на генериране е ограничена повече от пропускателната способност на паметта, отколкото от броя на ядрата: модел от 5 GB на машина, която чете 25 GB в секунда, достига таван от около 5 токена в секунда, още преди да се отчете изчислението.

Различават се две фази:

• Прочитането на въпроса (prompt processing) е интензивно изчисление: повече vCPU го правят по-бързо, което има значение при дългите документи.
• Генерирането на отговора зависи главно от пропускателната способност на паметта и от размера на модела: два пъти по-малък модел отговаря около два пъти по-бързо.

На практика, с няколко vCPU, модел със 7 до 8 милиарда параметъра, квантизиран на 4 бита, генерира няколко токена в секунда. Това е удобно за фонова обработка (класифициране на съобщения, извличане на полета от документ, нощно резюме на постъпилото през деня) и за вътрешен асистент. Интерактивната употреба в голям мащаб и моделите с няколко десетки милиарда параметъра се изпълняват на видеокарта (GPU).

Измерването решава: llama-bench, включен в llama.cpp, дава скоростта на двете фази на вашия сървър, за вашия модел.

llama-bench -m model-Q4_K_M.gguf -p 512 -n 128

Дискът: моделите, техните версии, векторите

Моделът заема на диска приблизително толкова, колкото и в паметта: 5 GB за модел с 8 милиарда параметъра на 4 бита. Предвидете място за два или три модела или версии, векторните индекси, изходните документи и базата данни. NVMe SSD зарежда модел за няколко секунди при стартиране на услугата, което има значение при всяко рестартиране.

Порядък на величините: 50 GB за приложение, което извиква модел през API, 80 до 120 GB, щом модел и неговите документи се намират на сървъра.

Сигурна настройка

С Ollama пускането в действие се свежда до две команди:

curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8b

По подразбиране Ollama слуша на 127.0.0.1:11434, тоест само от самия сървър. Запазете тази настройка: неговото API не изисква удостоверяване, а инстанция, отворена към интернет, обслужва всеки, с вашите ресурси. Вашето приложение, на същия сървър, разговаря с него локално; ако друг сървър трябва да изпраща заявки към него, минете през прокси, което удостоверява заявките, или през частна мрежа.

След това настройте размера на контекста (num_ctx) според това, от което наистина се нуждаят вашите заявки: именно той увеличава заетата памет, разговор по разговор.