Tre öppna motorer slåss just nu om samma jobb: att svara snabbast och billigast när en stor språkmodell körs i produktion. vLLM, SGLang och Nvidias TensorRT-LLM fick alla stora versionssläpp i september 2026, och skillnaderna mellan dem har blivit tydligare snarare än mindre. vLLM 0.29.0 kom den 9 september och gjorde en ny körmotor, Model Runner V2, till standard. SGLang 0.5.19 och 0.5.20 följde tätt, den 5 och 18 september, med snabbare prefix-cachning. Nvidias TensorRT-LLM 1.3.0 låg som release candidate i slutet av samma månad. Den här artikeln går igenom specifikationer, benchmarks från tre oberoende källor, pris, hårdvarukrav och vilken motor du bör välja beroende på din arbetsbelastning. Om du redan kör modeller lokalt med Ollama eller vLLM på egen hårdvara känner du igen en del av terminologin, men produktionsserving i skala ställer andra krav än en enskild utvecklarmaskin.
Vad vLLM, SGLang och TensorRT-LLM egentligen gör
Alla tre projekten löser samma grundproblem. En språkmodell som Llama 3.3 70B eller DeepSeek R1 kan inte bara “köras”, den måste schemaläggas, batchas och hållas i GPU-minnet på ett sätt som utnyttjar hårdvaran fullt ut. Skillnaden mellan en naiv implementation och en välbyggd inferensmotor kan vara en faktor tio i genomströmning. Det är den motorn som avgör om din chattbot svarar på 300 millisekunder eller tre sekunder, och om notan för en miljon token blir 15 öre eller sju kronor.
Det som gör valet svårt 2026 är att alla tre har blivit “bra nog” för de enklaste fallen. Skillnaderna syns först när trafiken växer, när samtidigheten stiger över några tiotal förfrågningar, eller när du behöver pressa ut sista millisekunden för en kundvänd tjänst. Ett team som bara kör interna verktyg för tio kollegor märker sällan skillnaden mellan motorerna. Ett team som serverar hundratusen förfrågningar om dagen gör det nästan alltid.
vLLM startade som ett forskningsprojekt på UC Berkeley och är i dag den mest spridda öppna inferensmotorn, med stöd för nästan alla populära modellarkitekturer. SGLang kom ur samma forskningsmiljö (Berkeleys Sky Computing Lab) men tog en annan väg: det optimerar hårt för fall där många förfrågningar delar samma textprefix, till exempel system-prompts eller flerturskonversationer. TensorRT-LLM är Nvidias egen motor, byggd ovanpå kompilatorn TensorRT, och den vinner oftast på ren latens när man kör Nvidia-hårdvara och är beredd att kompilera en separat motor per modell och GPU.
Valet mellan dem handlar sällan om vilken som är “bäst” i absolut mening. Det handlar om vilken arbetsbelastning du har: långa delade prompts, korta engångsfrågor, batchkörning över natten, eller en realtidstjänst med strikta svarstidskrav. Vi går igenom alla tre varianterna nedan, med siffror från verkliga tester.
Det finns också en fjärde variabel som sällan syns i rubrikerna: hur mycket ingenjörstid du är beredd att lägga på drift. vLLM och SGLang går att starta med ett enda kommando. TensorRT-LLM kräver ett kompileringssteg och en pipeline runt det, vilket gör att den operativa kostnaden inte alltid syns i ett rent prestandatest. Den kostnaden är precis lika verklig som GPU-notan, bara svårare att sätta en siffra på.
vLLM: öppen standard med bredast modellstöd
vLLM 0.29.0, släppt den 9 september 2026, innehöll enligt projektets egna releaseanteckningar 594 commits från 277 utvecklare, varav 91 helt nya bidragsgivare till projektet. Det säger något om farten i utvecklingen: det här är inte ett moget, stillastående bibliotek utan ett projekt som fortfarande förändras varje vecka. Den stora nyheten i 0.29.0 är att Model Runner V2 blir standardläge och att det gamla Model Runner V1 nu är markerat som föråldrat.
Projektets egna mätningar pekar på en hastighetsökning på 6,6 till 7,6 gånger för en specifik kärna som hanterar Mamba-metadata, och en förbättring på 12,9 till 25,2 procent för en GEMM-beräkningsväg. Det är viktigt att läsa de siffrorna rätt: de gäller enskilda beräkningskärnor, inte den totala genomströmningen i en riktig produktionsmiljö. En GEMM-kärna som blir 20 procent snabbare ger inte automatiskt 20 procent fler svar per sekund i en chattjänst.
Styrkan med vLLM ligger på ett annat plan: bredd. Det stöder fler modellarkitekturer än någon av konkurrenterna, kör OpenAI-kompatibelt API ur lådan, och fungerar på både Nvidia-GPU:er och, i vissa konfigurationer, AMD-kort via ROCm. Licensen är Apache 2.0, helt fri att använda i kommersiell drift utan licensavgift. Enligt ett uttalande från investmentbolaget Andreessen Horowitz används vLLM i produktion av bland andra Meta, Google och Character.ai, tillsammans med “många andra” företag som inte namnges specifikt. Fullständig versionshistorik och källkod finns i projektets releaseanteckningar på GitHub.
Den breda community-basen gör också att nya modeller landar i vLLM snabbt efter att de släpps. Om din organisation redan testat att köra DeepSeek eller Llama lokalt för utveckling, är steget till att sätta samma modellfamilj i produktion med vLLM litet, eftersom konfigurationsformatet och modellladdningen i stort sett är samma.
SGLang: specialisten på delade prompts och RadixAttention
SGLang 0.5.19 kom den 5 september 2026 och innehöll enligt releaseloggen 786 pull requests, vilket visar samma höga utvecklingstakt som vLLM men också samma risk: många snabba ändringar kan skapa kompatibilitetsproblem mellan versioner. Två veckor senare, den 18 september, följde 0.5.20 med en omarbetad prefix-cache, snabbare körningar för reinforcement learning och stöd för nio ytterligare modeller.
Det som gör SGLang unikt är tekniken RadixAttention. Den bygger ett träd av tidigare sedda textprefix och återanvänder beräkningen för allt som matchar, ner till token-nivå. I praktiken betyder det att om tusen användare skickar samma system-prompt, så beräknas den bara en gång. I ett test som molntjänsten RunPod publicerat uppmättes SGLang till omkring 16 200 token per sekund mot 12 500 för vLLM på Llama 3.1 8B, i en arbetsbelastning med många flerturskonversationer och delade prefix, en skillnad på runt 29 procent till SGLang:s fördel. Samma fördel försvinner nästan helt om varje prompt är unik.
SGLang är också, enligt projektets egen lista med användare på GitHub, i drift hos ett brett spektrum av kända namn: xAI, Nvidia, AMD, LinkedIn, kodredigeraren Cursor, samt molnleverantörerna Oracle Cloud, Google Cloud och AWS. Projektet gör själv anspråket att det körs på över 400 000 GPU:er globalt. Siffran kommer från projektet själv, inte från en oberoende granskad räkning, men den ger en fingervisning om skalan. Ett mer konkret, externt bekräftat exempel kommer från molnleverantören Spherons publicerade benchmarkrapport, som pekar ut xAI som den som kör SGLang för att serva sin Grok 3-modell, och Microsoft Azure som kör SGLang för DeepSeek R1 på AMD-hårdvara. Fullständiga releaseanteckningar för 0.5.19 och 0.5.20 finns i SGLang-projektets changelog på GitHub.
TensorRT-LLM: Nvidias motor för maximal hastighet på egen hårdvara
TensorRT-LLM skiljer sig från de andra två på ett grundläggande sätt. Istället för att tolka modellen vid körning kompilerar TensorRT-LLM en skräddarsydd motor för exakt din modell, din GPU och dina inställningar för parallellisering. Det tar tid (kompileringssteget kan ta allt från några minuter till närmare en halvtimme beroende på modellstorlek), men resultatet brukar vinna på ren latens. Version 1.3.0 fanns som release candidate i slutet av september 2026, en fortsättning på en serie release candidates som startade redan i juni med nya kandidater ungefär varannan vecka.
I ett test från granskningssajten RunInfra uppmätte man en första-token-latens på cirka 235 millisekunder för TensorRT-LLM mot 514 millisekunder för vLLM, vid en samtidighet på 32 förfrågningar. Kinesiska teknikmediet Creeta rapporterar liknande mönster på en H100-GPU med Llama 3.3 70B i FP8: TensorRT-LLM nådde cirka 2 100 token per sekund, SGLang cirka 1 920, och vLLM cirka 1 850, vid 50 samtidiga förfrågningar. Mönstret återkommer även hos Spheron, som mätte 2 100 token per sekund för TensorRT-LLM mot 1 850 för vLLM på samma modell och GPU.
Priset för den hastigheten är flexibilitet. TensorRT-LLM är i praktiken byggt för Nvidias ekosystem, kräver en matchande kombination av CUDA, drivrutin och TensorRT-version, och en motor byggd för en GPU-generation går vanligtvis inte att återanvända på nästa. Licensen är Apache 2.0 precis som konkurrenterna, men hela stacken runt omkring (CUDA, drivrutiner, eventuellt NGC-prenumerationer) hör till Nvidias kommersiella villkor, som måste granskas separat. Nvidias egen dokumentation beskriver TensorRT-LLM som motorn bakom företagets NIM-mikrotjänster, som marknadsförs som produktionsklara inferenstjänster. Källkoden och de fullständiga release candidate-anteckningarna för 1.3.0-serien ligger öppet i TensorRT-LLMs GitHub-repository.
Specifikationstabell: alla tre motorer sida vid sida
Nedan är en direkt jämförelse av de tekniska egenskaperna, byggd på de senaste versionerna i september 2026.
| Egenskap | vLLM | SGLang | TensorRT-LLM |
|---|---|---|---|
| Senaste version (sep 2026) | 0.29.0 | 0.5.20 | 1.3.0 (release candidate) |
| Releasedatum | 9 september 2026 | 18 september 2026 | Slutet av september 2026 |
| Licens | Apache 2.0 | Apache 2.0 | Apache 2.0 (stack kräver Nvidia CUDA/drivrutin) |
| Ursprung | UC Berkeley | Berkeley Sky Computing Lab | Nvidia |
| Körningsmodell | Tolkad (PagedAttention) | Tolkad (RadixAttention) | Kompilerad motor per modell/GPU |
| Primär styrka | Brett modellstöd, enkel drift | Delade prefix, flerturskonversationer | Lägsta latens på Nvidia-hårdvara |
| GPU-stöd | Nvidia CUDA, AMD ROCm (begränsat) | Nvidia CUDA, visst AMD-stöd | Nvidia CUDA (primärt mål) |
| OpenAI-kompatibelt API | Ja, inbyggt | Ja, inbyggt | Via Triton eller separat serverlager |
| Kvantisering FP8 | Stöds, kräver CUDA 11.8+ | Stöds på kompatibel hårdvara | Starkt stöd på Hopper och nyare |
| Kvantisering FP4/NVFP4 | Begränsat, versionsberoende | Begränsat, versionsberoende | Starkast stöd, byggt för Blackwell |
| Kompileringssteg krävs | Nej | Nej | Ja, per modell och GPU |
| Typisk tid till första svar efter start | Sekunder | Sekunder | Minuter (efter kompilering) |
Tabellen visar mönstret tydligt: vLLM och SGLang är snabbare att komma igång med, medan TensorRT-LLM kräver ett extra steg i utbyte mot bättre latens på rätt hårdvara. Ingen av de tre är “bäst” på allt, och det är precis den poängen som gör jämförelsen svår att sammanfatta i en enda siffra. Lägg särskilt märke till raden om kompileringssteg: det är den rad i tabellen som oftast glöms bort när team jämför motorer enbart på pappersprestanda, men det är också den rad som i praktiken avgör hur snabbt ni kan rulla ut en modelluppdatering en vanlig tisdag.
Prestandabenchmarks från tre oberoende källor
För att undvika att luta sig på en enda leverantörs siffror har vi samlat resultat från tre separata tester, alla körda på Llama-modeller på Nvidia H100-GPU:er under 2026: Creetas motorjämförelse, RunInfras latensanalys och RunPod:s publicerade flerturstest. De är inte perfekt jämförbara (olika promptlängder, olika samtidighetsnivåer), men mönstret upprepas tydligt över alla tre.
| Källa | Modell & GPU | vLLM | SGLang | TensorRT-LLM |
|---|---|---|---|---|
| Spheron (benchmarkrapport) | Llama 3.3 70B, H100 80GB, FP8 | 1 850 tok/s | Ej uppmätt i detta test | 2 100 tok/s |
| Creeta (teknikmedia) | Llama 3.3 70B, H100 80GB, FP8, 50 samtidiga | 1 850 tok/s | 1 920 tok/s | 2 100 tok/s |
| RunPod (prefixtungt flerturstest) | Llama 3.1 8B, prefixtung belastning | 12 500 tok/s | 16 200 tok/s | Ej inkluderat i detta test |
| RunInfra (latenstest, samtidighet 32) | Första-token-latens | 514 ms | Ej uppmätt i detta test | 235 ms |
Två slutsatser håller över alla källor. För det första: när arbetsbelastningen domineras av unika, korta förfrågningar på stora modeller vinner TensorRT-LLM nästan alltid på både latens och total genomströmning, med 10 till 20 procents fördel framför vLLM i de flesta testen. För det andra: så fort arbetsbelastningen innehåller mycket återanvänt textprefix, som i chattbotar med fast system-prompt eller agentloopar som skickar samma kontext om och om igen, tar SGLang täten med god marginal, i RunPod:s test med nästan 30 procent högre genomströmning än vLLM.
Det finns inget test i vårt underlag som jämför alla tre motorerna på Nvidias nyare B200-kort eller på AMD:s MI300X under identiska förhållanden. Analysfirman AIMultiple har publicerat GPU-till-GPU-jämförelser (runt 2,40 ms latens för åtta B200-kort mot 4,20 ms för åtta MI300X-kort), men det är ren hårdvarulatens, inte ett motortest. Behandla alla B200- och MI300X-specifika påståenden om dessa tre motorer med skepsis tills ett kontrollerat test publiceras.
Så testar du motorerna på egen hand
Ingen extern benchmark ersätter ett eget test på din egen trafik. Alla tre motorerna exponerar ett OpenAI-kompatibelt HTTP-API, vilket gör det möjligt att köra samma lastgenererande skript mot alla tre och jämföra äpplen med äpplen, så länge du håller modell, promptmängd och samtidighet konstant mellan körningarna.
# Enkel genomströmningsmätning mot valfri OpenAI-kompatibel server
# (byt bara ut porten: 8000 för vLLM, 30000 för SGLang)
time curl -s http://localhost:8000/v1/completions \
-H "Content-Type: application/json" \
-d '{
"model": "meta-llama/Llama-3.3-70B-Instruct",
"prompt": "Sammanfatta följande text på svenska: ...",
"max_tokens": 256,
"n": 1
}' | python3 -c "import json,sys; d=json.load(sys.stdin); print(len(d['choices'][0]['text'].split()))"Kör samma anrop i en loop med stigande samtidighet (1, 8, 32, 100 parallella förfrågningar) och logga svarstid och antal genererade token per sekund för varje nivå. Det är först när du ser var kurvan böjer av, punkten där mer samtidighet inte längre ger mer total genomströmning, att du vet var din verkliga kapacitetsgräns ligger för just din modell och GPU. Det är den kurvan, inte ett enskilt snitt-tal, som avgör vilken motor som faktiskt passar din trafik.
Kostnad per miljon token: vad räkningen faktiskt blir
Kostnadssiffrorna i de olika testerna sprider sig kraftigt, mest beroende på vilket GPU-pris man räknar mot. Spheron utgick från 2,65 dollar i timmen för en H100, medan analysfirman AIMultiple räknade med 2,69 dollar och RunPod:s eget benchmarkarkiv använde 3,49 dollar. Det gör att “kostnad per miljon token” aldrig bör citeras utan att man också anger vilket timpris som ligger bakom.
| Källa | GPU och timpris | vLLM, kostnad/miljon utgående token | TensorRT-LLM, kostnad/miljon utgående token |
|---|---|---|---|
| Spheron | H100 80GB, 2,65 USD/h | 0,40 USD | 0,35 USD |
| RunInfra | H100 (leverantörens eget pris) | 0,158 USD (FP8) / 0,206 USD (BF16) | Ej separat angivet |
| AIMultiple (GPU-prisreferens) | H100, 2,69 USD/h | Ej motortest, GPU-pris endast | Ej motortest, GPU-pris endast |
Skillnaden mellan 0,16 dollar och 0,40 dollar per miljon token för samma motor, vLLM, visar hur känslig kostnadsberäkningen är för mätmetod. Vill du räkna din egen kostnad, ta inte en enda siffra från en artikel. Mät din egen genomströmning på din egen modell och multiplicera med ditt eget GPU-pris. Ingen av motorerna har en egen licensavgift per token, kostnaden kommer alltid från GPU-timmen, inte mjukvaran.
Licens och företagsstöd
Alla tre projekten delar samma grundlicens: Apache 2.0, fri att använda, modifiera och köra i kommersiell drift utan royalty till projektet. Det är en viktig skillnad mot en del AI-infrastruktur som kräver betald enterprise-licens för produktionsbruk.
Där det skiljer sig är runt stacken. vLLM och SGLang är i praktiken fristående: du kan köra dem på nästan vilken Linux-server med rätt GPU-drivrutin som helst, utan att teckna avtal med någon. TensorRT-LLM, däremot, lever inuti Nvidias mjukvarustack. Du behöver matchande versioner av CUDA, drivrutin och TensorRT, och om du vill ha officiellt företagsstöd (snabbare svarstid på buggar, hjälp med driftsättning) rör du dig in i Nvidias kommersiella erbjudanden som NGC och AI Enterprise, med separata avtal och priser som inte är offentligt listade på samma sätt som GPU-timpriser.
För de två öppna motorerna finns inget enskilt “officiellt” supportavtal från upphovsprojekten. I stället växer en marknad av tredjepartsleverantörer (molnplattformar, konsultbolag) som säljer hanterad drift ovanpå vLLM och SGLang. Det betyder att din faktiska supportkostnad beror mer på vem du köper molntjänsten eller konsulttimmarna från än på själva mjukvaran.
Räkna därför den totala ägandekostnaden i tre delar, inte bara GPU-timpriset: mjukvarulicens (noll kronor för alla tre), GPU-drift (den dominerande posten), och ingenjörstid för drift och uppgraderingar (ofta underskattad, särskilt för TensorRT-LLM:s kompileringspipeline). Ett team som bara jämför GPU-timpris mellan leverantörer missar ofta den tredje posten helt, trots att den över ett år kan bli lika stor som själva molnnotan.
Hårdvarustöd: GPU, VRAM och kvantisering
Ingen av motorerna anger ett enda “minimikrav” för VRAM, för det beror helt på modellstorlek, kontextlängd, batchstorlek och vilken precision du kör i. Som grov tumregel: en modell i 7 till 8 miljarder parametrar i FP16 eller BF16 brukar få plats på ett GPU-kort med 24 GB minne, med begränsad kontextlängd och batchning. En modell på 70 miljarder parametrar kräver i praktiken flera kort med 80 GB vardera i samma precision. Kvantisering till FP8 eller 4-bit halverar eller mer det rena viktminnet, men det eliminerar inte minnesbehovet för KV-cache under pågående generering.
På precisionssidan ligger FP8 brett stöttat hos alla tre i dag. vLLM:s egen dokumentation anger att CUDA 11.8 eller senare stöder FP8 i formaten E4M3 och E5M2. SGLang stöder FP8 på kompatibel hårdvara, men exakt vilka modeller och GPU-generationer som stöds varierar mellan versioner. TensorRT-LLM har det starkaste stödet för FP8 på Nvidias Hopper-generation (H100, H200) och ännu starkare för det nyare NVFP4-formatet på Blackwell-kort (B200), där Nvidias egen mjukvara är byggd specifikt för den typen av lågprecisionsberäkning.
För AMD:s MI300X-kort är läget mer osäkert för alla tre. TensorRT-LLM är i praktiken inte ett alternativ, eftersom hela motorn bygger på Nvidias CUDA-kompilator. vLLM och SGLang har båda viss ROCm-kompatibilitet, men stödet måste verifieras per modellarkitektur och version snarare än antas fungera rakt av. Om din organisation redan satsat på AMD-hårdvara, testa alltid den exakta modell- och kvantiseringskombination du planerar att köra innan du binder dig.
Kontextlängd är en annan dimension som ofta glöms bort i hårdvaruplaneringen. En modell som stöder 128 000 token i kontext kräver ett proportionellt större KV-cache-utrymme per aktiv förfrågan, vilket i sin tur minskar hur många samtidiga användare samma GPU-minne kan hantera. Alla tre motorerna erbjuder tekniker för att mildra detta, som chunked prefill, paged attention och radix-baserad cache-delning, men de löser problemet på olika sätt. Den motor som hanterar lång kontext mest minneseffektivt kan därför variera beroende på exakt modellarkitektur och hur dina prompts ser ut.
Kvantiseringsvalet hänger ofta ihop med hur modellen togs fram i första hand. Om du redan finjusterat en egen modell med QLoRA eller någon annan 4-bitarsmetod, är det extra viktigt att testa att den finjusterade vikten faktiskt laddar korrekt i den serveringsmotor du väljer, eftersom alla tre har egna format för hur LoRA-adaptrar och kvantiserade vikter kombineras vid körning. Detsamma gäller om modellen finjusterats via Hugging Face: exportformatet som fungerar perfekt för träning är inte alltid det format som laddar snabbast i produktion.
Ekosystem och utvecklingstakt: vad siffrorna säger om projekthälsa
Utvecklingstakten i alla tre projekten är ovanligt hög för infrastrukturmjukvara. vLLM:s 594 commits och 277 bidragsgivare i en enda release, med 91 helt nya namn i listan, pekar på ett projekt som fortfarande växer sin bidragsgivarbas snarare än att konsolideras kring en liten kärngrupp. SGLang:s 786 pull requests i en release är ännu högre i absoluta tal, men det säger också något om risknivån: ju fler samtidiga ändringar, desto större chans att en uppgradering introducerar ett beteende du inte förväntat dig.
För ett team som ska välja motor för flera års drift är det värt att fråga sig vilken utvecklingstakt man faktiskt vill ha. Ett projekt som ändrar standardinställningar varje månad (vilket vLLM gjorde när Model Runner V2 blev standard) kräver mer regressionstestning vid varje uppgradering, men ger också snabbare tillgång till nya modellarkitekturer och optimeringar. TensorRT-LLMs release candidate-cykel, med nya kandidater varannan vecka sedan juni, visar en liknande hög takt men med en mer formell process innan något når stabil status.
Fem verkliga exempel på produktionsanvändning
Siffror i ett labb är en sak. Här är fem konkreta, offentligt dokumenterade exempel på var motorerna faktiskt körs i skarp drift. Lägg märke till att källornas tillförlitlighet skiljer sig: ett direkt företagsuttalande väger tyngre än en lista ett projekt skrivit om sig själv, men båda ger värdefulla signaler om var varje motor faktiskt vunnit mark.
- Meta, Google och Character.ai (vLLM): Enligt ett uttalande från investmentbolaget Andreessen Horowitz används vLLM i produktion hos dessa företag, tillsammans med flera andra som inte namngivits.
- xAI och Grok 3 (SGLang): Molnleverantören Spheron pekar specifikt ut xAI som den organisation som kör SGLang för att serva Grok 3 i produktion.
- Microsoft Azure och DeepSeek R1 på AMD (SGLang): Samma källa dokumenterar att Azure kör SGLang för att serva DeepSeek R1-modellen på AMD-hårdvara, ett av de tydligaste publika exemplen på AMD-driven LLM-serving i produktion.
- Nvidia NIM-mikrotjänster (TensorRT-LLM): Nvidias egen dokumentation beskriver TensorRT-LLM som motorn bakom företagets NIM-containerpaket, som säljs som produktionsklara mikrotjänster för inferens.
- LinkedIn, Cursor och tre stora molnplattformar (SGLang): SGLang-projektets egen användarlista på GitHub namnger LinkedIn och AI-kodredigeraren Cursor som användare, samt att Oracle Cloud, Google Cloud och AWS erbjuder SGLang i sina respektive kataloger. Det är projektets egen uppgift, inte en oberoende granskning, men den matchar bilden av SGLang som starkt förankrat hos stora molnaktörer.
Så väljer du rätt motor för ditt användningsfall
Den enskilt viktigaste frågan att ställa innan du väljer motor är: hur ser dina riktiga förfrågningar ut? Är de korta och unika, eller långa och återanvänder samma kontext? Svaret styr valet mer än något enskilt benchmarktal.
Ett praktiskt sätt att svara på frågan är att logga en vecka av riktig trafik och räkna hur stor andel av varje prompt som är identisk mellan förfrågningar, till exempel system-instruktioner, verktygsscheman eller tidigare konversationsturer som skickas om igen. Ligger den andelen över 30 till 40 procent av den totala prompt-längden, är SGLang:s prefix-cachning sannolikt värd investeringen. Ligger den nära noll, vinner du inget på att byta motor av den anledningen, och bör istället optimera för ren latens eller enkelhet.
| Användningsfall | Rekommenderad motor | Varför |
|---|---|---|
| Chattbot med fast system-prompt, hög samtidighet | SGLang | RadixAttention återanvänder den delade prompten och ger upp till ~29% högre genomströmning i prefixtunga tester |
| Agentloopar som upprepar samma verktygsbeskrivningar | SGLang | Samma prefixfördel gäller när kontexten byggs upp iterativt över flera anrop |
| Realtidstjänst med strikt svarstidskrav (t.ex. röstassistent) | TensorRT-LLM | Lägst uppmätt första-token-latens (235 ms mot 514 ms för vLLM i RunInfra:s test) |
| Snabb prototyp eller intern verktygslåda med många olika modeller | vLLM | Bredast modellstöd, inget kompileringssteg, igång på minuter |
| Batchbearbetning av stora dokumentmängder över natten | vLLM eller TensorRT-LLM | Total genomströmning väger mer än latens vid batchkörning, TensorRT-LLM leder ofta med 10-20% |
| Blandad GPU-flotta med både Nvidia och AMD-kort | vLLM | Bäst dokumenterat ROCm-spår av de tre, även om stödet måste testas per modell |
| Team utan tidigare Nvidia-kompileringserfarenhet | vLLM eller SGLang | Inget krav på att bygga och underhålla kompilerade motorer per GPU-generation |
Ett vanligt misstag är att välja motor baserat på ett enda benchmarktal från en artikel, utan att testa mot sin egen trafik. Siffrorna i den här artikeln varierar redan mellan tre källor som alla mätte på liknande hårdvara. Din egen trafik, med dina egna promptmönster, är den enda siffra som verkligen räknas.
Migrationsguide: byta inferensmotor utan att allt går sönder
Att byta inferensmotor är sällan ett enkelt drop-in-byte, trots att alla tre marknadsför OpenAI-kompatibla API:er. Här är stegen som gäller oavsett riktning, följt av specifika fallgropar för varje byte.
- Frys din nuvarande arbetsbelastning: modellversion, tokenizer, promptformat, typiska in- och utdatalängder, samtidighetsnivå och streamingbeteende.
- Mät en baslinje: första-token-latens, latens mellan token, total genomströmning, kötid och GPU-minnesanvändning, på din egen trafik.
- Validera numeriskt beteende på en fast uppsättning promptar innan du byter, inklusive chattmallar, stopptoken och eventuell verktygsanropsformatering.
- Porta serverlagret. Kontrollera att batchning, streaming, felkoder och tokenräkning beter sig likadant även om API:et kallas “OpenAI-kompatibelt”.
- Bygg om kvantiserade artefakter. En GPTQ-, AWQ- eller FP8-fil är i regel inte utbytbar rakt av mellan motorer.
- Justera om batchnings- och minnesinställningar. Värden som fungerat bra i en motor överförs sällan direkt till en annan.
Från vLLM till SGLang
Den stora vinsten med SGLang kommer från prefixåteranvändning. Om din trafik inte faktiskt delar textprefix mellan förfrågningar märker du kanske ingen skillnad alls, eller en försämring. RadixAttention är dessutom känslig för exakt prefix-identitet: en liten ändring i whitespace, systemprompt eller serialisering av verktygsscheman kan tysta ner cacheträffarna helt utan att du märker det förrän genomströmningen plötsligt sjunker.
Från SGLang till vLLM
Gå åt andra hållet och du riskerar att tappa prefixprestanda om vLLM:s egen prefix-cachning inte är aktiverad och trimmad. Eventuella SGLang-specifika program för strukturerad generering eller reguljära uttryck måste porteras till vLLM:s motsvarande gränssnitt, de är inte kompatibla rakt av.
Från vLLM eller SGLang till TensorRT-LLM
Det här är det tyngsta bytet. Modellen måste exporteras till ett TensorRT-LLM-kompatibelt format, och en motor måste kompileras specifikt för målets GPU, precision, parallelliseringsgrad och maximala sekvenslängd. Den kompilerade motorn följer sedan inte automatiskt med om du byter GPU-generation, en ny B200-maskin kräver i regel en ny kompilering. Räkna med att kompileringstid och motorartefakter blir en del av din CI/CD-pipeline, inte bara ett engångssteg. Kör alltid noggranna kvalitetstester efter kompilering: FP8- och FP4-kvantisering beror på kalibrering och skalfaktorer, och kvaliteten ska aldrig antas vara identisk med BF16 utan att testas.
Ett exempel på kommandot som startar en SGLang-server för jämförelse mot en vLLM-drift ser ut ungefär så här:
python -m sglang.launch_server \
--model-path meta-llama/Llama-3.3-70B-Instruct \
--tp 4 \
--mem-fraction-static 0.85 \
--port 30000
# Motsvarande start i vLLM:
vllm serve meta-llama/Llama-3.3-70B-Instruct \
--tensor-parallel-size 4 \
--gpu-memory-utilization 0.85 \
--port 8000Lägg märke till att parametrarna har olika namn (--mem-fraction-static mot --gpu-memory-utilization) trots att de styr ungefär samma sak. Det är precis den typen av små, lätt missade skillnader som gör att ett “enkelt” motorbyte tar en vecka längre än planerat.
Fördelar och nackdelar med varje motor
| Motor | Fördelar | Nackdelar |
|---|---|---|
| vLLM | Bredast modellstöd, inget kompileringssteg, stor community, OpenAI-kompatibelt API ur lådan | Förlorar mot TensorRT-LLM på ren latens, förlorar mot SGLang på prefixtunga laster |
| SGLang | Stark fördel vid delade prompts och flerturskonversationer, snabb utveckling, stöd hos stora molnplattformar | Fördelen krymper kraftigt vid unika engångsprompts, cachekänslig för minsta promptändring |
| TensorRT-LLM | Lägst latens och ofta högst genomströmning på Nvidia-hårdvara, starkast FP8/FP4-stöd | Kräver kompilering per modell/GPU, låst till Nvidias stack, längst startuppsättning |
Vanliga misstag vid val av inferensmotor
De flesta driftproblem vi hört talas om dyker inte upp vid lansering, de dyker upp två eller tre uppgraderingar senare, när ett team glömt varför en konfigurationsflagga sattes till ett visst värde från början. Dokumentera därför alltid varför en inställning valdes, inte bara vilket värde den fick.
Det vanligaste felet är att kopiera ett benchmarktal rakt av från en artikel och anta att det gäller den egna trafiken. Som tabellerna ovan visar skiljer sig kostnadssiffrorna för samma motor med en faktor fyra mellan olika källor, bara beroende på vilket GPU-timpris som använts. Mät alltid på egen trafik innan du binder dig.
Ett annat vanligt fel är att välja TensorRT-LLM för latensvinsten utan att räkna in kompileringstiden i driftprocessen. Om modellen uppdateras varje vecka, eller om GPU-flottan byter generation ofta, kan den extra operativa bördan äta upp hela latensfördelen. På samma sätt väljer många SGLang för prefix-cachningen utan att faktiskt kontrollera om deras egen trafik har några delade prefix att utnyttja, vilket gör hela investeringen meningslös.
Slutligen: många organisationer glömmer att testa kvantiseringens effekt på svarskvalitet, inte bara på hastighet. Ett FP8- eller FP4-kvantiserat svar kan se bra ut i en snabb granskning men innehålla subtila kvalitetsförsämringar som bara syns i ett strukturerat utvärderingstest mot den okvantiserade modellen.
Ett fjärde, mer organisatoriskt misstag är att låta en enskild utvecklares preferens styra valet utan att dokumentera avvägningen för resten av teamet. En motor vald för att den var snabbast att komma igång med en fredag eftermiddag blir lätt den motor hela produktionsmiljön byggs kring i flera år, oavsett om den fortfarande är rätt val när trafikmönstret förändras.
Domen: vilken motor vinner 2026?
Det finns ingen universell vinnare, och varje källa i vårt underlag drar samma slutsats. TensorRT-LLM tar hem de flesta direkta hastighetstesten på Nvidia-hårdvara, med 10 till 20 procents fördel i genomströmning och mer än dubbelt så låg första-token-latens jämfört med vLLM i RunInfra:s mätning. Men den fördelen kommer med ett kompileringssteg och ett hårdare beroende av Nvidias stack som inte passar alla driftmiljöer. Räknat i rena siffror från våra tre benchmarkkällor: TensorRT-LLM vann latenstestet hos RunInfra med mer än dubbla hastigheten, matchade eller slog vLLM och SGLang i både Creetas och Spherons genomströmningstest, och det enda scenariot där den inte deltog i jämförelsen var RunPod:s renodlade prefix-test, ett område där SGLang är specifikt byggt för att dominera.
SGLang vinner tydligt (upp till 29 procent i RunPod:s test) så fort arbetsbelastningen domineras av delade prompts eller flerturskonversationer, och har redan dragit till sig tunga användare som xAI och Microsoft Azure för just den typen av trafik. vLLM förblir det säkraste förstahandsvalet för team som vill ha bredast modellstöd och minst operativ komplexitet, utan att offra prestanda mer än marginellt i de flesta verkliga scenarier.
Den praktiska rekommendationen: börja med vLLM om du inte redan vet att du har ett prefixtungt eller extremt latenskänsligt problem. Byt till SGLang om profileringen visar att dina förfrågningar faktiskt delar textprefix. Investera i TensorRT-LLM först när du har en stabil modell, en fast Nvidia-hårdvaruflotta, och ett verkligt behov av varje millisekund. Letar du efter fler jämförelser och guider inom AI-infrastruktur, samlar vi dem under AI och maskininlärning, inklusive hur du kommer igång med lokal modellkörning i LM Studio innan du skalar upp till en produktionsmotor.
Vanliga frågor
Kan jag köra vLLM, SGLang och TensorRT-LLM på samma GPU-kluster samtidigt?
Ja, tekniskt går det bra, de delar inte globalt tillstånd på GPU:n. I praktiken väljer de flesta ett huvudspår för produktion och håller de andra för specifika modeller eller experiment, för att minska antalet driftsmiljöer att underhålla.
Är TensorRT-LLM alltid snabbast?
Nej. Det leder ofta på ren latens och genomströmning för unika, korta förfrågningar på Nvidia-hårdvara, men förlorar mot SGLang så fort trafiken domineras av delade textprefix, och fördelen minskar om modellen uppdateras ofta eftersom varje uppdatering kräver ny kompilering.
Fungerar någon av motorerna bra på AMD:s MI300X?
TensorRT-LLM är i praktiken uteslutet, det bygger på Nvidias CUDA-kompilator. vLLM och SGLang har båda viss ROCm-kompatibilitet, men stödet varierar per modellarkitektur och version och måste testas, inte antas.
Kostar det extra licenspengar att köra någon av motorerna i produktion?
Nej, alla tre är licensierade under Apache 2.0 utan royalty för kommersiellt bruk. Den faktiska kostnaden kommer nästan uteslutande från GPU-timpriset, inte från mjukvarulicensen.
Vilken motor är enklast att komma igång med för ett litet team?
vLLM brukar vara enklast, eftersom den inte kräver ett separat kompileringssteg och har det bredaste modellstödet. En server kan vara igång och svara på förfrågningar inom några minuter efter installation.
Hur stor skillnad gör RadixAttention i praktiken?
I RunPod:s prefixtunga flerturstest gav SGLang omkring 16 200 token per sekund mot 12 500 för vLLM, en skillnad på ungefär 29 procent. Men i arbetsbelastningar utan delade prefix kan fördelen krympa till nästan noll, så resultatet beror helt på din egen trafik.
Behöver jag bygga om min TensorRT-LLM-motor när jag byter GPU-generation?
I regel ja. En motor kompilerad för H100 är inte garanterat portabel till B200 eller en annan GPU-generation, och ny maskinvara kräver normalt en ny kompileringsomgång med rätt optimeringsprofil.
Var kommer resultaten i den här artikeln ifrån?
Från publicerade benchmarkrapporter hos Spheron, Creeta, RunInfra och RunPod, samt projektens egna releaseanteckningar för vLLM och SGLang och Nvidias dokumentation för TensorRT-LLM. Siffrorna är inte perfekt jämförbara mellan källor eftersom testförhållandena skiljer sig, vilket är själva poängen med att visa flera källor sida vid sida i stället för en enda.
