vLLM vai TGI? Suuri rinnakkaisuus käänsi läpimenon 24-kertaiseksi

vLLM on perusteltu valinta, jos oma kielimalli palvelee paljon samanaikaisia pyyntöjä: julkaistussa LLaMA-2-7B-vertailussa sen läpimeno oli enimmillään 24-kertainen TGI:hin verrattuna 200 yhtäaikaisen pyynnön kuormassa. Ero syntyi, kun TGI:n läpimeno heikkeni kuorman kasvaessa ja vLLM pysyi lähellä huippuaan. Luku kuvaa juuri tätä kuormaa ja testattua kokoonpanoa, ei yksittäisen käyttäjän vastauksen nopeutumista.

Jos palvelussa on vain vähän samanaikaisia keskusteluja, TGI:n nopeampi vastauksen aloitus voi painaa läpimenoa enemmän. Uuden palvelun valinnassa on silti huomioitava elinkaari: Hugging Facen TGI-ohje ilmoittaa TGI:n olleen ylläpitotilassa 11. joulukuuta 2025 lähtien ja suosittelee Inference Endpoints -palvelussa vaihtoehdoiksi vLLM:ää tai SGLangia. Toimivaa TGI-asennusta ei tarvitse vaihtaa pelkän vertailuluvun vuoksi, mutta uutta käyttöönottoa ja tulevia muutoksia on syytä arvioida ylläpitotilan ehdoilla.

Miksi läpimenoero kasvoi kuorman mukana?

Tutkimuksen läpimeno tarkoittaa kaikkien pyyntöjen yhteensä tuottamia tokeneita sekunnissa. LLaMA-2-7B-mallilla vLLM tuotti sadan samanaikaisen pyynnön kuormassa 15 243 ja TGI 4 156 tokenia sekunnissa; ero oli 3,67-kertainen. Vasta kahdensadan pyynnön äärikuormassa suhteellinen ero nousi 24-kertaiseksi. Siksi jälkimmäinen luku kertoo ennen kaikkea siitä, miten palvelimet käyttäytyivät kapasiteettirajalla.

Mallikoko muutti tulosta. LLaMA-2-13B-mallilla vLLM:n etu oli optimaalisella rinnakkaisuudella 2,8-kertainen. LLaMA-2-70B-mallilla se oli 2,1-kertainen, kun malli oli jaettu neljälle grafiikkasuorittimelle. Jälkimmäisessä kokoonpanossa suorittimien välinen synkronointi kuuluu mitattuun kokonaisuuteen; pienemmän mallin tulosta ei voi yleistää suoraan suurimpaan malliin.

Kokeissa käytettiin NVIDIA A100 -grafiikkasuorittimia, vLLM:n versiota 0.6.1 ja TGI:n versiota 2.3.0. Molemmat ajettiin FP16-tarkkuudella, ja keskustelusyötteet poimittiin ShareGPT-aineistosta. Syötteiden keskipituudeksi asetettiin 512 ja tuotosten 256 tokenia; kukin kokoonpano lämmitettiin ennen mittausta, mitattiin 1 000 pyynnöllä ja toistettiin kolme kertaa. Nämä rajaukset ovat olennaisia, koska pitkä syöte kuormittaa muistia eri tavoin kuin lyhyt keskusteluvuoro ja koska versio sekä laitteisto vaikuttavat ajoitukseen.

vLLM:n tehokas KV-välimuistin käsittely ja pyyntöjen eräajo auttavat pitämään useita generointeja käynnissä. Niitä ei kuitenkaan voi nimetä yksin 24-kertaisen eron syyksi: myös TGI käyttää eräajoa ja muistia säästäviä tarkkaavaisuustekniikoita. Tutkimuksen välitön havainto on tarkempi: TGI:n läpimeno alkoi kyllästyä pienemmällä rinnakkaisuudella, kun taas vLLM:n läpimeno kasvoi pidempään. Jos oma liikenne ei yllä vastaavaan ruuhkaan, sen suhteellinen hyöty voi jäädä paljon pienemmäksi.

Ensimmäinen token ja valmis vastaus mittaavat eri kokemusta

Vuorovaikutteisessa keskustelussa ensimmäisen tokenin viive kertoo, milloin käyttäjä näkee vastauksen alkavan. Kokonaisviive mittaa ajan pyynnöstä viimeiseen tokeniin. Läpäisykyky taas summaa kaikkien pyyntöjen tuotoksen, joten hyvä kokonaistulos voi esiintyä yhtä aikaa joidenkin yksittäisten pyyntöjen pitkän odotuksen kanssa. Hitaimpia kokemuksia kuvaavat esimerkiksi viivejakauman p95- ja p99-arvot, eivät pelkät keskiarvot.

Tutkimuksen 25 samanaikaisen käyttäjän LLaMA-2-7B-taulukossa TGI:n ensimmäisen tokenin mediaaniviive oli 0,18 sekuntia ja vLLM:n 0,24 sekuntia. Saman taulukon koko vastauksen p99-viive oli kuitenkin vLLM:llä 14,18 ja TGI:llä 23,47 sekuntia. TGI aloitti siis tässä kuormassa tyypillisen vastauksen nopeammin, kun taas vLLM sai hitaimman prosentin kokonaiset vastaukset valmiiksi nopeammin. Mittarit eivät anna yhtä yleispätevää voittajaa vuorovaikutteiselle liikenteelle.

Jos sovellus näyttää tekstiä suoratoistona, aloitusviive on käyttäjälle näkyvä palvelutason osa. Taustalla tehtävässä luokittelussa tai pitkän tekstin tuotannossa valmiin vastauksen viive voi olla ratkaisevampi. Sekaliikenteessä kumpaakaan ei kannata peittää yhteen läpimenolukuun: pyyntöjen pituus, samanaikaisuus ja vastausten suoratoisto määrittävät sen, mikä palvelimen ominaisuus näkyy käyttäjälle.

Rajapinta voi pysyä samana, mutta vastauksen sisältö muuttua

vLLM:n palvelindokumentaatio kuvaa OpenAI-yhteensopivat completions- ja chat completions -päätepisteet. OpenAI-tyyppistä asiakasta käyttävä sovellus voi siksi säilyttää suuren osan pyyntöjen rakenteesta, kun palvelimen osoite vaihtuu. TGI:lläkin on yhteensopiva chat-rajapinta, joten protokollan vaihto ei aina edellytä uuden asiakkaan kirjoittamista.

Yhteensopivuus koskee silti toteutettuja ominaisuuksia. vLLM:n chat-päätepiste edellyttää mallille sopivaa chat-templatea, ja esimerkiksi completions-pyynnön suffix-parametria ei tueta. Mallin Hugging Face -varastossa oleva generation_config.json voi myös muuttaa vLLM:n näytteenoton oletusarvoja. Sama HTTP-pyyntö voi tällöin onnistua molemmissa palvelimissa mutta tuottaa erilaisen tekstin tai poiketa sovelluksen odottamasta oletuskäytöksestä.

Siirtymän toiminnallinen testi kannattaa tehdä sovelluksen oikeilla pyynnöillä: mukana ovat järjestelmäviestit, mahdolliset työkalukutsut, suoratoisto, virhetilanteet ja ne parametrit, joita asiakas todella lähettää. Vertailun kohteena ovat vastausten rakenne ja käytettävyys, eivät sanasta sanaan samat tuotokset stokastisesta mallista. Jos nykyinen asiakas käyttää TGI:n omaa rajapintaa OpenAI-yhteensopivan reitin sijasta, pyyntöjen muunnos on erillinen työvaihe.

Erärajat ja muisti ratkaisevat oman kapasiteetin

Inference Endpoints -palvelun vLLM-asetuksissa suurin erään mahtuvien sekvenssien määrä ja erän tokenraja ovat erillisiä rajoja. Pitkä syöte voi täyttää tokenrajan, vaikka pyyntöjä olisi vain vähän. Tämän vuoksi rinnakkaisten käyttäjien määrä ei yksin kuvaa sitä, kuinka paljon työtä grafiikkasuoritin pystyy ottamaan vastaan samalla hetkellä.

Mallin jakaminen usealle grafiikkasuorittimelle voi olla välttämätöntä, jotta painot ja KV-välimuisti mahtuvat muistiin. Jakaminen tuo samalla tiedonsiirtoa ja synkronointia; suurempi suoritinmäärä ei automaattisesti lyhennä yksittäisen pyynnön viivettä. Jos toinen palvelin sallii pidemmän kontekstin tai suuremman erän kuin toinen, vertailu mittaa myös erilaista kapasiteettirajaa. Samat enimmäispituudet ja sama laitteistobudjetti tekevät tuloksista käyttökelpoisia valintaa varten.

Oman liikenteen vertailussa hyödyllisiä ovat erikseen lyhyet keskusteluvuorot, pitkät syötteet ja todellinen ruuhkahuippu. Samat syötteet, tuotospituudet ja rinnakkaisuustasot on ajettava molemmille palvelimille. Mittaa samalla tuotetut tokenit sekunnissa, ensimmäisen tokenin viive ja koko vastauksen hitaimmat viiveet. Näin selviää, johtuuko mahdollinen etu suuremmasta kapasiteetista vai siitä, että osa käyttäjistä joutuu odottamaan kauemmin.

TGI:stä siirtyminen vaatii uuden päätepisteen

Hugging Facen Inference Endpoints -ympäristössä olemassa olevan päätepisteen inference engineä ei voi vaihtaa suoraan TGI:stä vLLM:ään. Hallittu siirtymä alkaa uudesta päätepisteestä samalle mallille; lähtökohtana voi käyttää samaa laitteistoa ja kokoonpanoa. Tämä koskee nimenomaan Inference Endpoints -palvelua. Itse ylläpidetyssä asennuksessa siirto riippuu omasta reitityksestä, mallin latauksesta ja käyttöönottoympäristöstä.

1. Kirjaa vanhan palvelun malli, token- ja syöterajat, generointiasetukset sekä käytetyt API-reitit. Luo niiden pohjalta vLLM-päätepiste ennen nykyisen palvelun sulkemista.
2. Tee molempiin toiminnalliset pyynnöt ja tarkista chat-template, suoratoiston tapahtumat, vastausmuoto sekä sovellukselle merkitykselliset virheet.
3. Kuormita uutta päätepistettä todellista liikennettä muistuttavilla pyynnöillä. Vertaa läpimenoa ja kumpaakin viivemittaria sekä tavallisessa kuormassa että ruuhkassa.
4. Ohjaa liikennettä uuteen osoitteeseen hallitusti. Pidä vanha päätepiste palautusvaihtoehtona, kunnes sovelluksen toiminta ja viiveet täyttävät sovitut rajat; vasta sitten sen voi pysäyttää tai poistaa.

TGI:n ylläpitotila merkitsee pienten korjausten ja ylläpitotehtävien jatkumista, mutta uusien ominaisuuksien odottaminen sen varaan on huono suunnitteluoletus. Jos nykyinen asennus täyttää vaatimukset vähäisellä rinnakkaisuudella, siirtymän kiire määräytyy omista ylläpito- ja integraatiotarpeista. Suureen rinnakkaisuuteen tähtäävässä uudessa palvelussa vLLM:n kuormankesto tekee siitä vahvan lähtökohdan, jonka arvo varmistuu oman mallin ja liikenteen mittauksissa.

Lue myös:

• Claude Code vai Codex? Valinta ratkeaa työnkulkuun, ei yhteen testiin
• REST vai GraphQL? Pienempi vastaus voi vaatia raskaamman palvelimen
• NotebookLM vai ChatGPT PDF-tutkimukseen? Rajattu aineisto vähentää arvailua