vLLM vs SGLang 2026: Testasimme molemmat H100-laitteistoilla

vLLM vs SGLang 2026: Testasimme molemmat H100-laitteistoilla

Hugging Face siirsi TGI:n ylläpitotilaan joulukuussa 2025 ja ohjaa nyt tiimit käyttämään vLLM:ää tai SGLangia uusissa käyttöönotoissa. Jos pystytät päättelypinon tänään, todellinen kysymys ei ole ”pitäisikö minun siirtyä pois TGI:stä?”, vaan se, kumpi näistä kahdesta moottorista todella sopii työkuormaasi.

Pika yhteenveto

Valitse vLLM, jos haluat laajimman laitetuen, suurimman yhteisön ja taistellun tien tuotantoon AWS:ssä, GCP:ssä ja Azuressa.

Valitse SGLang, jos työkuormasi painottuu monivaiheisiin keskusteluihin, jäsenneltyihin tulosteisiin tai etuliitepainotteisiin putkiin kuten RAG, ja olet tyytyväinen pienempään ekosysteemiin.

Puretaan nyt auki, missä kukin moottori todella vetää pidemmän korren.

Miten tähän päädyttiin? TGI:n poistuminen

Text Generation Inference (TGI) kantoi Hugging Face -ekosysteemiä vuosien ajan, mutta joulukuusta 2025 alkaen se hyväksyy vain virhekorjauksia, ei uusia ominaisuuksia. Hugging Facen omat Inference Endpoints -palvelut käyttävät nyt oletuksena vLLM:ää, ja SGLang on vaihtoehto.

Tämä jättää kaksi todellista kilpailijaa itse isännöityyn LLM-palveluun. Molemmat ovat avoimen lähdekoodin projekteja, molemmat puhuvat OpenAI API:a ja molemmat toimivat NVIDIA GPU:illa. Erot tulevat esiin kuormituksen alla.

Tuomio: Sekä vLLM että SGLang ovat tuotantovalmiita TGI-korvaajia. Jos migratoit, kumpikin on varma valinta; tämän oppaan loppuosa auttaa sinua valitsemaan kumman.

Läpimeno- ja viivetestit

Testitulokset vaihtelevat mallin, GPU:n ja samanaikaisuuden mukaan, joten tässä on lukuja riippumattomista testeistä samalla laitteistolla. Seuraavat tiedot perustuvat Spheronin H100-testeihin, joissa käytettiin Llama 3.3 70B Instruct -mallia FP8-muodossa, sekä PremAI:n testeihin Llama 3.1 8B -mallilla.

Llama 3.3 70B H100:lla (FP8)

Llama 3.1 8B H100:lla

Pienemmillä malleilla ero kasvaa. PremAI mittasi SGLangin suorituskyvyksi noin 16 200 tok/s verrattuna vLLM:n 12 500 tok/s:iin, mikä tarkoittaa 29 % läpimentoetua SGLangille. LMDeploy saavutti tässä SGLangin tasoa, mutta se on eri keskustelun aihe.

Mitä luvut tarkoittavat

70B-mittakaavassa ero on vaatimaton (3–5 %). 8B-mittakaavassa se on merkittävä. Kuviosta tulee järkevä: SGLangin RadixAttention tuottaa enemmän hyötyä silloin, kun esikäsittely (prefill) muodostaa suuremman osan kokonaiskustannuksista, mikä tapahtuu pienemmillä malleilla ja lyhyemmillä tulosteilla.

Häntäviive kertoo saman tarinan. SGLangin TTFT p95 oli johdonmukaisesti 5–8 % alempi kuin vLLM:n kaikilla testatuilla samanaikaisuustasoilla. Jos rakennat reaaliaikaista chat-käyttöliittymää, jossa jokainen 50 ms merkitsee, tuo ero kasautuu käyttäjämäärän myötä.

Tuomio: SGLang voittaa raakaläpimenossa, erityisesti pienemmillä malleilla. vLLM on lähellä 70B+ mittakaavassa. Useimmissa tuotantotyökuormissa ero on yksinumeroisia prosentteja, mikä on merkittävää skaalautuessa, mutta ei kummassakaan tapauksessa showstopper.

Etuliitteen välimuisti: RadixAttention vs automaattinen etuliitteen välimuisti

Molemmat moottorit tallentavat KV-laskentoja toistuville etuliitteille, mutta mekanismit eroavat tavalla, joka on tärkeä tietyille työkuormille. Jos tunnet jo kehotevälimuistin API-tasolla, ajattele tätä palvelinpohjaisena versiona.

vLLM käyttää lohkotason hash-funktiota. Se jakaa KV-välimuistin kiinteänkokoisiin lohkoihin, hashaa ne ja etsii osumia uusista pyynnöistä. Ennustettava, tehokas ja helppo hahmottaa, mutta tarvitset johdonmukaiset lohkorajat välimuistiosumille.

SGLang käyttää token-tasolla indeksoitua radix-puuta. Se havaitsee automaattisesti jaettuja etuliitteitä pyyntöjen välillä ilman manuaalista konfigurointia. Jos 50 käyttäjää lähettää viestejä samassa keskusteluketjussa, SGLang löytää ja käyttää uudelleen yhteisen etuliitteen automaattisesti.

Missä sillä todella on väliä

RunPod testasi monivaiheisia keskusteluja ja havaitsi, että SGLang tuotti johdonmukaisesti ~30–31 tok/s korkealla samanaikaisuudella, kun taas vLLM:n suorituskyky laski 22:sta 16:een tok/s välimuistipaineen kasvaessa. Tämä on merkittävä ero chatbot- ja agenttityökuormille.

Eräpäättelyssä mallipohjaisilla kehotteilla, joissa jokainen pyyntö käyttää samaa järjestelmäkehotea, vLLM:n lähestymistapa toimii hyvin. Välimuistirajat asettuvat luonnollisesti mallipohjasi rakenteen mukaan.

Tuomio: SGLang voittaa dynaamisissa, monivaiheisissa työkuormissa. vLLM on täysin riittävä eräpäättelyyn ja mallipohjaisiin kehotteisiin, joissa etuliitteet ovat ennustettavia.

Jäsennellyt tulosteet

Jos tarvitset JSON-skeeman valvontaa tai rajoitettua generointia, tämä osio on erittäin tärkeä. Molemmat moottorit tukevat jäsenneltyjä tulosteita kielioppitaustaosien, kuten XGrammarin ja LLGuidancen, kautta, mutta suorituskykytarina on hyvin erilainen.

SqueezeBits ajoi yksityiskohtaisia testejä ja havaitsi, että vLLM:n läpimeno heikkenee huomattavasti, kun ohjattu dekoodaus on käytössä, erityisesti eräko'oilla 8 ja suuremmilla. SGLang sen sijaan limittää maskin generoinnin GPU-päättelyvaiheen kanssa, pitäen ylikuormituksen minimaalisena.

Toistuvat vs dynaamiset skeemat

Taustaosan valinta on myös tärkeä:

Ilman jäsenneltyä valvontaa tulosteiden oikeellisuus laskee ~61 %:iin monimutkaisissa skeemoissa. Sen kanssa oikeellisuus nousee 20–25 prosenttiyksikköä. Joten tämä ei ole valinnainen osa tuotantoagenttien työnkulkuja, ja valitsemasi moottori määrää, kuinka paljon läpimenoa uhraat.

Tuomio: SGLang voittaa jäsennellyissä tulosteissa. Jos putkesi luottaa JSON-skeeman valvontaan (kuten useimmat agenttityönkulut tekevät), SGLangin päällekkäinen lähestymistapa tarkoittaa, että et maksa läpimentoveroa.

Multi-LoRA ja hienosäädettyjen mallien palvelu

Molemmat moottorit tukevat useiden LoRA-sovitinten palvelua yhdestä perusmallista, mikä on välttämätöntä, jos hienosäädät malleja eri vuokralaisille tai tehtäville.

SGLang käsittelee multi-LoRA:n ensiluokkaisena ominaisuutena natiivilla erästyksellä; eri sovittimiin kohdistuvat pyynnöt voivat jakaa saman erän. vLLM tukee sitä myös, mutta SGLangin toteutus on ollut hieman hiotumpi viimeaikaisissa julkaisuissa.

Käytännön ero? Jos palvelet 5–10 LoRA-sovitinta yhdestä Llama 70B -perusmallista, molemmat toimivat. Jos ajat 50+ sovitinta heterogeenisillä liikennemalleilla, SGLangin natiivi erästys käsittelee aikataulutuksen sulavammin.

Tuomio: SGLangilla on pieni etu multi-LoRA:ssa skaalautuessa. Muutamalla sovittimella molemmat moottorit toimivat yhtä hyvin.

Spekulatiivinen dekoodaus

Molemmat moottorit tukevat spekulatiivista dekoodausta, joka käyttää pientä ”luonnos”-mallia ennustamaan tokeneja, jotka päämalli sitten varmentaa rinnakkain. Tuloksena on 2–3 kertaa nopeampi päättely muistiriippuvaisissa skenaarioissa.

vLLM esitteli recently Unified Parallel Draftingin, ja spekulatiivinen dekoodaus toimii nyt yhdessä jäsenneltyjen tulosteiden kanssa. SGLangin toteutus on kyvyiltään samanlainen, hieman paremmalla suorituskyvyllä kohtalaisilla samanaikaisuustasoilla.

Todellinen erottaja ei ole moottori, vaan se, sopiiko spekulatiivinen dekoodaus työkuormaasi. Se auttaa eniten pitkissä tulosteissa suurista malleista, joissa pullonkaula on muistikaistanleveys, ei laskentateho.

Tuomio: Tasapeli. Molemmat moottorit tarjoavat vertailukelpoiset spekulatiivisen dekoodauksen nopeutuspotentiaalit.

Laitetuki ja käyttöönotto

Tässä vLLM vetää selvästi pidemmän korren.

vLLM

• NVIDIA GPU:t (A100, H100, H200, B200)
• AMD GPU:t (MI250, MI300X)
• Intel GPU:t (vllm-xpu-kernelsin kautta)
• AWS Trainium ja Inferentia
• Google TPUs
• Kypsät Kubernetes-dokumentit Helm-kaavioilla, käynnistys-/valmius-/elossaolo-antureilla
• NVIDIA Container Toolkit -integraatio out-of-the-box

SGLang

• NVIDIA GPU:t (A100, H100, H200, B200)
• AMD GPU:t (MI300X, ROCm:n kautta)
• Docker-keskeinen käyttöönotto
• Kubernetes on mahdollinen, mutta vähemmän dokumentoitu

Jos otat käyttöön jotain muuta kuin NVIDIA- tai AMD-laitteistoa, vLLM on ainoa vaihtoehtosi. Erityisesti AWS:ssä Trainium-tuki tarkoittaa, että voit leikata päättelykustannuksia merkittävästi, eikä SGLang pysty hyödyntämään sitä laitteistoa.

Tiimeille, jotka käyttävät standardi NVIDIA GPU:ita, käyttöönoton tarina on samanlainen. Molemmat tarjoavat Docker-kuvia ja OpenAI-yhteensopivia päätepisteitä. vLLM:ssä on vain enemmän taisteltuja tuotanto-oppaita ja yhteisöncontribuoimia Helm-kaavioita.

Jos tutkimme työkaluja LLM:ien ajamiseen paikallisesti tai haluat laajemman näkymän itse isännöityyn päättelyyn, molemmat moottorit tukevat paikallista käyttöönottoa kuluttaja-GPU:illa, vaikka ne on suunniteltu datakeskuslaitteistolle.

Tuomio: vLLM voittaa laitteiston laajuudessa ja käyttöönoton kypsyydessä. SGLang on kunnossa, jos käytät NVIDIA- tai AMD-laitteistoa. Muualla vLLM on ainoa valinta.

Erotettu palvelu

Molemmat moottorit tukevat esikäsittelyn (laskentaintensiivinen) ja dekoodauksen (muisti-intensiivinen) erottamista eri työntekijäpoolseihin. Tämä mahdollistaa kunkin vaiheen itsenäisen skaalaamisen: enemmän esikäsittelytyöntekijöitä kehotepainotteisten piikkien aikana, enemmän dekoodaustyöntekijöitä pitkän generoinnin aikana.

SGLang tukee Mooncakea ja NIXL:ää siirtotaustaosina erottelulle ja on julkaissut tuloksia, jotka osoittavat 2,7 kertaa suuremman dekoodausläpimenon NVIDIA GB200 NVL72 -klustereissa. vLLM:n erotettu palvelu on myös toiminnallinen, vaikka sitä on dokumentoitu vähemmän näkyvästi.

Tämä ominaisuus on tärkein hyvin suurissa mittakaavoissa (96+ GPU:ta). Jos käytät kourallisen GPU:ita, et todennäköisesti tarvitse sitä vielä.

Tuomio: SGLangilla on pieni etu erotetun palvelun kypsyydessä. Molemmat tukevat sitä; SGLang on julkaissut enemmän todellisia tuotantotuloksia.

Milloin käyttää mitä: päätöskehys

Rehellinen vastaus monille tiimeille: kokeile molempia. Ne ovat molemmat avoimen lähdekoodin projekteja, molemmat paljastavat saman OpenAI API:n, ja vaihtaminen niiden välillä on kontinvaihto. Ajakaa todellinen työkuormanne kummankin läpi päivän ajan ja vertailkaa teille tärkeitä mittareita.

Jos reitität liikennettä useiden päättelytaustaosien välillä, LLM-gateway voi istua kumman tahansa moottorin edessä ja hoitaa vikasietoisuuden, nopeudenrajoituksen ja havainnollistamisen.

Miten Techsy lähestyy päättelypalvelimen valintaa

Kun autamme tiimejä ottamaan käyttöön LLM-pohjaisia ominaisuuksia, päättelymoottorin valinta tiivistyy kolmeen kysymykseen:

1. Mihin laitteistoon olet lukittunut? Jos se on Trainium tai TPU, kyseessä on vLLM. Kaikessa muussa molemmat toimivat.
2. Millainen on työkuormasi muoto? Monivaiheinen chat ja agenttisilmukat suosivat SGLangin etuliitteen välimuistia. Eräkäsittely ja yksinkertaiset täydennykset toimivat hyvin kummassakin.
3. Kuinka paljon ops-kapasiteettia sinulla on? vLLM:n suurempi yhteisö tarkoittaa enemmän StackOverflow-vastauksia ja Helm-kaavioita, kun jokin hajoaa kello 3 aamulla.

Olemme ajaneet tuotantotyökuormia molemmilla. Ne ovat aidosti lähellä toisiaan. Oikea vastaus riippuu rajoituksistasi, ei siitä, että toinen olisi abstraktisti ”parempi”.

Tarvitsetko apua valinnassa tai päättelypalvelimen käyttöönotossa? Ota meihin yhteyttä, arvioimme työkuormasi ja suosittelemme oikeaa stackia.

Työkalun valitseminen on helpompi puolisko. Sen luotettava toiminta todellisessa tuotteessa on kohta, jossa useimmat tiimit jumittuvat, ja juuri sitä meidän AI-integraatiotiimimme rakentaa asiakkaille, RAG-putkista räätälöityihin agentteihin.

Usein kysytyt kysymykset

Onko SGLang nopeampi kuin vLLM?

Pienemmillä malleilla (7B–8B) SGLang näyttää noin 29 % korkeampaa läpimenoa H100 GPU:illa. 70B+ malleissa ero kapenee 3–5 %:iin. SGLangilla on myös alhaisempi häntäviive (TTFT p95) kaikilla testatuilla samanaikaisuustasoilla.

Voinko käyttää vLLM:ää ja SGLangia OpenAI API -muodossa?

Kyllä. Molemmat paljastavat OpenAI-yhteensopivat päätepisteet out-of-the-box. Voit vaihtaa toisen toiseen muuttamatta asiakaskoodiasi. /v1/chat/completions-kutsusi toimivat identtisesti kummassakin.

Miksi Hugging Face deprekoisi TGI:n?

TGI siirtyi ylläpitotilaan joulukuussa 2025. Hugging Face päätti contribute vLLM:ään ja SGLangiin erillisen päättelymoottorin ylläpidon sijaan. TGI toimii edelleen olemassa olevissa käyttöönotoissa, mutta uusia ominaisuuksia ei ole tulossa.

Tukeeko SGLang NVIDIA- ja AMD GPU:ita?

SGLang tukee NVIDIA GPU:ita (A100, H100, H200, B200) ja AMD GPU:ita (MI300X ROCm:n kautta). Se ei tue Intel GPU:ita, AWS Trainiumia, Inferentiaa eikä Google TPU:ita. vLLM:llä on laajempi laitekatavuus.

Mikä on RadixAttention ja miksi se on tärkeä?

RadixAttention on SGLangin etuliitteen välimuistimekanismi. Se tallentaa KV-välimuistimerkinnät token-tasolla indeksoituun radix-puuhun, havaiten automaattisesti jaettuja etuliitteitä pyyntöjen välillä. Tämä tekee monivaiheisista keskusteluista ja RAG-putkista huomattavasti nopeampia, koska toistuvaa kontekstia ei tarvitse laskea uudelleen.

Kumpi moottori on parempi jäsennellyille JSON-tulosteille?

SGLang. Se limittää kielioppimaskin generoinnin GPU-päättelyyn, joten jäsennellyn tulosteen valvonta vaikuttaa tuskin lainkaan läpimentoon. vLLM näyttää huomattavaa heikkenemistä eräko'oilla 8 ja suuremmilla, kun ohjattu dekoodaus on käytössä.

Voinko palvella useita LoRA-sovittimia yhdestä perusmallista?

Molemmat moottorit tukevat multi-LoRA-palvelua. SGLang käsittelee sitä natiivina ominaisuutena erästyksellä eri sovittimien välillä samassa pyyntöerässä. vLLM tukee sitä myös, mutta SGLangin aikataulutus on tehokkaampaa suurilla sovittimien määrillä.

Mikä on erotettu esikäsittely/dekoodaus-palvelu?

Se tarkoittaa esikäsittelyvaiheen (kehotteen käsittely) ajamista erillisillä GPU-työntekijöillä kuin dekoodausvaiheen (tokenien generointi). Esikäsittely on laskentariippuvaista; dekoodaus on muistiriippuvaista. Niiden erottaminen mahdollistaa kunkin itsenäisen skaalaamisen. Molemmat moottorit tukevat tätä, ja SGLangilla on enemmän julkaistuja tuotantotuloksia.

Miten migratoit TGI:stä vLLM:ään tai SGLangiin?

Koska kaikki kolme paljastavat OpenAI-yhteensopivat API:t, migraatio on lähinnä kontinvaihto. Ohjaa Docker Compose- tai Kubernetes-käyttöönotto uusiin imageihin, säädä mallin latauslippuja ja päivitä health check -päätepisteet. Asiakaskoodi pysyy samana.

Pitäisikö minun käyttää vLLM:ää vai SGLangia RAG-putkessa?

SGLang on vahvempi valinta RAG:iin. Sen RadixAttention tallentaa automaattisesti välimuistiin ja käyttää uudelleen pitkät järjestelmäkehotteet ja dokumenttikontekstit, joita RAG-putket lähettävät toistuvasti. vLLM:n lohkotason välimuisti toimii myös, mutta saat parempia välimuistiosumia SGLangin token-tason lähestymistavalla, kun dokumenttilohkot vaihtelevat hieman pyyntöjen välillä.

Lopullinen tuomio

SGLang voittaa useammissa kategorioissa, mutta vLLM:n edut, laitteiston laajuus ja ekosysteemin kypsyys, ovat sellaisia asioita, jotka merkitsevät kello 3 aamulla, kun node menee alas.

Jos käytät NVIDIA-laitteistoa ja työkuormasi sisältää monivaiheisia keskusteluja, agentteja jäsennellyillä tulosteilla tai RAG-putkia jaetuilla etuliitteillä, aloita SGLangilla. Saat paremman läpimenon ja alhaisemman viiveen siellä, missä sillä on väliä.

Jos tarvitset monipilvijoustavuutta, ei-NVIDIA-laitetukea tai mukavuutta suurimman avoimen lähdekoodin LLM-palveluyhteisön takana, aloita vLLM:llä. Se on turvallisempi oletusarvo, joka palvelee useimpia tiimejä hyvin.

Joka tapauksessa molemmat moottorit ovat erinomaisia ja paranevat nopeasti. Valitse yksi, ota se käyttöön, mittaa todellinen työkuormasi ja vaihda, jos luvut niin sanovat. OpenAI-yhteensopiva API tekee vaihdosta kivuttoman.

Lähteet

• Spheron H100 Benchmarks: vLLM vs TensorRT-LLM vs SGLang
• PremAI: vLLM vs SGLang vs LMDeploy Benchmarks
• SqueezeBits: Guided Decoding Performance on vLLM and SGLang
• RunPod: SGLang vs vLLM KV Cache Reuse
• SGLang Official Documentation
• vLLM Official Documentation