Millainen VPS tekoälyn ajamiseen: rajapinta vai malli palvelimella

Kaksi tarvetta, kaksi palvelinkokoa

Useimmat ”tekoälyä käyttävät” sovellukset (avustajat, agentit, tiivistelmät, tietojen poiminta, haku dokumenteista) kutsuvat mallin tarjoajan isännöimää mallia rajapinnan kautta. Laskenta tapahtuu tarjoajan palvelimilla; palvelimenne valmistelee pyynnön, odottaa vastausta ja käsittelee sen. Palvelin mitoitetaan silloin kuten mikä tahansa verkkosovellus: ohjelmointikielen, tietokannan ja samanaikaisten käyttäjien määrän mukaan.

Toinen tapaus on itse palvelimella ajettava malli, Ollaman, llama.cpp:n tai Python-kirjaston avulla. Syyt ovat tuttuja: data, joka pysyy omalla infrastruktuurillanne, kiinteä kustannus pyyntöjen määrästä riippumatta, suurten tietomäärien taustakäsittely, erikoistunut malli. Silloin koko mallin on mahduttava muistiin, ja malli ratkaisee palvelimen koon.

Rajapinnan kautta: mitoittakaa sovellus, ei mallia

Rajapinnan kautta tehty mallipyyntö kestää sekunnista useisiin kymmeniin sekunteihin, varsinkin kun vastaus lähetetään sitä mukaa kuin se syntyy (streaming). Sillä välin palvelimenne ei juuri laske mitään: se odottaa. Ratkaisevaa on sen kyky pitää monta pyyntöä odottamassa estämättä muita:

• Asynkroninen palvelin: Node.js, FastAPI ja Uvicorn tai asynkroniset Gunicorn-workerit. Synkroninen worker, joka odottaa 20 sekunnin vastausta, on varattuna kaikilta muilta kävijöiltä.
• Tehtäväjono pitkille käsittelyille (dokumentin tiivistelmä, erän analyysi): kävijän pyyntö palaa heti, ja worker käsittelee työn taustalla.
• Säädetyt aikakatkaisut välityspalvelimessa: Nginx katkaisee oletuksena vastauksen, joka pysyy hiljaa yli 60 sekuntia (proxy_read_timeout).

Varattava muisti on sovelluksen ja sen tietokannan muisti: 4 GB kattaa Python- tai Node.js-sovelluksen PostgreSQL:llä julkaisuvaiheessa. Yleinen kokoonpano, jossa Next.js-käyttöliittymä, FastAPI-rajapinta ja PostgreSQL-tietokanta kutsuvat mallia rajapinnan kautta, mahtuu 6 tai 8 gigatavuun käyttöliittymän käännös mukaan lukien.

Upotukset ja vektorihaku: vektorien muisti

Sovellus, joka hakee tietoa dokumenteistanne (RAG, retrieval-augmented generation), muuntaa jokaisen tekstikatkelman vektoriksi ja etsii sitten kysymystä lähimmät. Mitoitettavia kohtia on kaksi:

• Upotusmalli, jos se toimii omalla palvelimellanne: yleiset mallit ovat kooltaan 100 MB:n ja 1,5 GB:n välillä ja laskevat suorittimella vaivatta. Esimerkiksi all-MiniLM-L6-v2 vie alle 100 MB.
• Vektorit: pgvectorissa vektori vie 4 tavua ulottuvuutta kohden ja lisäksi 8 tavua. Miljoona katkelmaa 1 536 ulottuvuudessa on noin 6 GB dataa, ja siihen tulee lisäksi hakua nopeuttava HNSW-indeksi. Jotta haut olisivat nopeita, indeksin ja haettujen vektorien on mahduttava muistiin.

pgvectorin tyyppi halfvec tallentaa jokaisen ulottuvuuden 2 tavuun 4 tavun sijaan: puolet muistista, ja hakutulosten laatu pysyy hyvin lähellä alkuperäistä.

Malli palvelimella: ensin muisti

Kielimalli on painotiedosto, joka ladataan kokonaan muistiin vastaamista varten. Sen koko riippuu parametrien määrästä ja kvantisoinnista, eli tarkkuudesta, jolla kukin paino tallennetaan. llama.cpp:n ja Ollaman käyttämä GGUF-muoto tarjoaa kvantisointeja 2 bitistä 16 bittiin; noin 4-bittinen Q4_K_M on yleinen kompromissi koon ja laadun välillä.

Painojen lisäksi muistia kuluu kahteen asiaan:

• Konteksti (KV-välimuisti): jokainen käynnissä olevan keskustelun token vie muistia. Llama 3.1 8B:llä varatkaa noin 128 KB tokenia kohden 16 bitin tarkkuudella, eli 1 GB 8 000 tokenin kontekstille, ja saman verran jokaista rinnakkain käsiteltävää keskustelua kohden.
• Muu palvelin: järjestelmä, sovellus ja tietokanta, kuten missä tahansa verkkosovelluksessa.

Esimerkki. Llama 3.1 8B 4-bittisenä, kaksi samanaikaista 8 000 tokenin keskustelua ja pieni sovellus: 5 GB mallille, 2 GB kontekstille ja 2 GB sovellukselle ja järjestelmälle, eli yhteensä 9 GB, ja noin 12 GB 25 %:n marginaalin kanssa.

Suorittimella: mikä ratkaisee nopeuden

Jokaisen tokenin tuottamiseksi malli lukee kaikki painonsa uudelleen muistista. Suorittimella tekstin tuottamisen nopeutta rajoittaa siis muistikaista enemmän kuin ytimien määrä: 5 GB:n malli koneella, joka lukee 25 GB sekunnissa, yltää enintään noin 5 tokeniin sekunnissa jo ennen kuin itse laskentaa otetaan huomioon.

Kaksi vaihetta erotetaan toisistaan:

• Kysymyksen lukeminen (prompt processing) on raskasta laskentaa: useampi vCPU nopeuttaa sitä, mikä on tärkeää pitkissä dokumenteissa.
• Vastauksen tuottaminen riippuu ennen kaikkea muistikaistasta ja mallin koosta: puolet pienempi malli vastaa noin kaksi kertaa nopeammin.

Käytännössä muutamalla vCPU:lla 4-bittiseksi kvantisoitu 7 tai 8 miljardin parametrin malli tuottaa muutaman tokenin sekunnissa. Se riittää hyvin taustakäsittelyyn (viestien luokittelu, kenttien poiminta dokumentista, päivän tapahtumien tiivistäminen yön aikana) ja sisäiseen avustajaan. Laajamittainen interaktiivinen käyttö ja useiden kymmenien miljardien parametrien mallit ajetaan näytönohjaimella (GPU).

Mittaus ratkaisee: llama.cpp:n mukana tuleva llama-bench kertoo molempien vaiheiden nopeuden omalla palvelimellanne ja omalla mallillanne.

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

Levy: mallit, niiden versiot, vektorit

Malli vie levyllä suunnilleen saman verran tilaa kuin muistissa: 5 GB 4-bittiselle 8 miljardin parametrin mallille. Varatkaa tilaa kahdelle tai kolmelle mallille tai versiolle, vektori-indekseille, lähdedokumenteille ja tietokannalle. NVMe-SSD lataa mallin muutamassa sekunnissa palvelun käynnistyessä, mikä on tärkeää jokaisella uudelleenkäynnistyksellä.

Suuruusluokka: 50 GB sovellukselle, joka kutsuu mallia rajapinnan kautta, ja 80 ja 120 GB:n välillä heti, kun malli ja sen dokumentit ovat palvelimella.

Turvallinen käyttöönotto

Ollamalla käyttöönotto hoituu kahdella komennolla:

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

Ollama kuuntelee oletuksena osoitteessa 127.0.0.1:11434, eli vain palvelimelta itseltään. Pitäkää tämä asetus: sen rajapinta ei vaadi tunnistautumista, ja internetiin avoin instanssi palvelee ketä tahansa teidän resursseillanne. Samalla palvelimella toimiva sovelluksenne keskustelee sen kanssa paikallisesti; jos toisen palvelimen on kutsuttava sitä, käyttäkää pyynnöt tunnistavaa välityspalvelinta tai yksityistä verkkoa.

Säätäkää sitten kontekstin koko (num_ctx) sen mukaan, mitä pyyntönne tarvitsevat: juuri se kasvattaa varattua muistia keskustelu keskustelulta.