Kāds VPS vajadzīgs mākslīgajam intelektam: API vai modelis serverī

Divas vajadzības, divi servera izmēri

Lielākā daļa lietojumprogrammu, kas «izmanto MI» (asistenti, aģenti, kopsavilkumi, datu izgūšana, meklēšana dokumentos), izsauc modeli, ko mitina tā izstrādātājs, caur API. Skaitļošana notiek pie viņa; jūsu serveris sagatavo pieprasījumu, gaida atbildi un to apstrādā. Tad to dimensionē kā jebkuru tīmekļa lietojumprogrammu: pēc tās valodas, datubāzes un vienlaicīgo lietotāju skaita.

Otrs gadījums ir modelis, kas darbojas pašā serverī ar Ollama, llama.cpp vai kādu Python bibliotēku. Iemesli ir zināmi: dati, kas paliek jūsu infrastruktūrā, fiksētas izmaksas neatkarīgi no pieprasījumu skaita, lielu apjomu fona apstrāde, specializēts modelis. Šeit visam modelim jāietilpst atmiņā, un izmēru nosaka tieši tas.

Caur API: dimensionēt lietojumprogrammu, nevis modeli

Pieprasījums modelim caur API ilgst no vienas līdz vairākiem desmitiem sekunžu, it īpaši, ja atbilde tiek straumēta pa daļām (streaming). Šajā laikā jūsu serveris gandrīz neko neskaitļo: tas gaida. Svarīga ir tā spēja turēt gaidīšanā daudz pieprasījumu, nebloķējot pārējos:

• Asinhrons serveris: Node.js, FastAPI ar Uvicorn vai asinhroni Gunicorn darba procesi. Sinhrons darba process, kas 20 sekundes gaida atbildi, ir darba process, kas bloķēts visiem pārējiem apmeklētājiem.
• Uzdevumu rinda ilgām apstrādēm (dokumenta kopsavilkums, datu partijas analīze): apmeklētāja pieprasījums atgriežas uzreiz, un darba process to apstrādā fonā.
• Iestatīti noilgumi starpniekserverī: Nginx pēc noklusējuma pārtrauc atbildi, kas klusē ilgāk par 60 sekundēm (proxy_read_timeout).

Paredzamā atmiņa ir lietojumprogrammas un tās datubāzes atmiņa: 4 GB sedz Python vai Node.js lietojumprogrammu ar PostgreSQL palaišanas brīdī. Izplatīta konfigurācija, Next.js saskarne, FastAPI API un PostgreSQL datubāze, kas izsauc modeli caur API, ietilpst 6 līdz 8 GB, ieskaitot saskarnes kompilēšanu.

Iegultnes un vektoru meklēšana: vektoru atmiņa

Lietojumprogramma, kas meklē jūsu dokumentos (RAG, retrieval-augmented generation), katru fragmentu pārvērš vektorā un pēc tam atrod jautājumam tuvākos. Jādimensionē divas pozīcijas:

• Iegultņu modelis, ja tas darbojas pie jums: izplatītie modeļi sver no 100 MB līdz 1,5 GB un bez grūtībām skaitļo uz procesora. Piemēram, all-MiniLM-L6-v2 aizņem mazāk par 100 MB.
• Vektori: ar pgvector viens vektors aizņem 4 baitus uz dimensiju, plus 8. Miljons fragmentu ar 1536 dimensijām ir aptuveni 6 GB datu, kam pievienojas HNSW indekss, kas paātrina meklēšanu. Ātrai meklēšanai indeksam un vaicātajiem vektoriem jāietilpst atmiņā.

pgvector tips halfvec glabā katru dimensiju 2 baitos, nevis 4: uz pusi mazāk atmiņas, un meklēšanas kvalitāte paliek ļoti tuva.

Modelis serverī: vispirms atmiņa

Valodas modelis ir svaru fails, ko atbildēšanai pilnībā ielādē atmiņā. Tā izmērs atkarīgs no parametru skaita un kvantizācijas, tas ir, precizitātes, ar kādu glabāts katrs svars. GGUF formāts, ko izmanto llama.cpp un Ollama, piedāvā kvantizāciju no 2 līdz 16 bitiem; Q4_K_M variants, ap 4 bitiem, ir ierastais kompromiss starp izmēru un kvalitāti.

Šim svaram pievienojas vēl divas pozīcijas:

• Konteksts (KV kešatmiņa): katrs pašreizējās sarunas tokens aizņem atmiņu. Modelim Llama 3.1 8B rēķinieties ar aptuveni 128 KB uz tokenu 16 bitu precizitātē, tas ir, 1 GB kontekstam ar 8000 tokeniem, un tikpat daudz katrai paralēli apstrādātai sarunai.
• Pārējais serveris: sistēma, lietojumprogramma, datubāze, tāpat kā jebkurai tīmekļa lietojumprogrammai.

Piemērs. Llama 3.1 8B 4 bitos, divas vienlaicīgas sarunas ar 8000 tokeniem un neliela lietojumprogramma: 5 GB modelim, 2 GB kontekstam, 2 GB lietojumprogrammai un sistēmai, kopā 9 GB, un ar 25 % rezervi aptuveni 12 GB.

Uz procesora: kas nosaka ātrumu

Lai izveidotu katru tokenu, modelis no jauna nolasa visus savus svarus atmiņā. Tāpēc uz procesora ģenerēšanas ātrumu ierobežo atmiņas joslas platums, vairāk nekā kodolu skaits: 5 GB modelis mašīnā, kas nolasa 25 GB sekundē, sasniedz griestus ap 5 tokeniem sekundē, vēl pirms tiek ieskaitīta skaitļošana.

Izšķir divas fāzes:

• Jautājuma nolasīšana (prompt processing) ir intensīva skaitļošana: vairāk vCPU to paātrina, un tas ir svarīgi gariem dokumentiem.
• Atbildes ģenerēšana galvenokārt atkarīga no atmiņas joslas platuma un modeļa izmēra: divreiz mazāks modelis atbild apmēram divreiz ātrāk.

Praksē uz dažiem vCPU modelis ar 7 līdz 8 miljardiem parametru, kvantizēts 4 bitos, rada dažus tokenus sekundē. Tas ir ērti fona apstrādei (ziņojumu šķirošana, lauku izgūšana no dokumenta, naktī sagatavots dienas notikumu kopsavilkums) un iekšējam asistentam. Plaša mēroga interaktīvie lietojumi un modeļi ar vairākiem desmitiem miljardu parametru darbojas uz grafiskās kartes (GPU).

Izšķir mērījums: llama-bench, kas nāk kopā ar llama.cpp, parāda abu fāžu ātrumu jūsu serverī, jūsu modelim.

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

Disks: modeļi, to versijas, vektori

Diskā modelis aizņem aptuveni tikpat, cik atmiņā: 5 GB modelim ar 8 miljardiem parametru 4 bitos. Paredziet vietu diviem vai trim modeļiem vai versijām, vektoru indeksiem, avota dokumentiem un datubāzei. NVMe SSD ielādē modeli dažās sekundēs pakalpojuma startēšanas brīdī, un tas ir svarīgi katrā restartēšanā.

Orientējoši: 50 GB lietojumprogrammai, kas izsauc modeli caur API, 80 līdz 120 GB, tiklīdz serverī dzīvo modelis un tā dokumenti.

Uzstādīšana, droši

Ar Ollama palaišanai pietiek ar divām komandām:

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

Pēc noklusējuma Ollama klausās adresē 127.0.0.1:11434, tas ir, pieņem savienojumus tikai no paša servera. Saglabājiet šo iestatījumu: tā API neprasa nekādu autentifikāciju, un internetā atvērta instance apkalpo jebkuru, uz jūsu resursu rēķina. Jūsu lietojumprogramma tajā pašā serverī ar to sazinās lokāli; ja tai jāpiekļūst no cita servera, izmantojiet starpniekserveri, kas autentificē pieprasījumus, vai privātu tīklu.

Pēc tam iestatiet konteksta izmēru (num_ctx) atbilstoši tam, kas vajadzīgs jūsu pieprasījumiem: tieši tas palielina aizņemto atmiņu, sarunu pēc sarunas.