vLLM vs SGLang 2026: Vi har benchmarket begge på H100'er

vLLM vs SGLang 2026: Vi har benchmarket begge på H100'er

Hugging Face satte TGI i vedligeholdelsestilstand i december 2025 og peger nu teams i retning af vLLM eller SGLang til nye deployment. Hvis du opsætter en inferens-stack i dag, er det rigtige spørgsmål ikke "skal jeg væk fra TGI?", men hvilken af disse to engines der faktisk passer til din workload.

Hurtigt overblik

Vælg vLLM, hvis du ønsker den bredeste hardware-understøttelse, det største community og en velafprøvet vej til produktion på tværs af AWS, GCP og Azure.

Vælg SGLang, hvis din workload er tung på flerrunders samtaler, strukturerede outputs eller præfiks-tunge pipelines som RAG, og du er komfortabel med et mindre økosystem.

Lad os nu dykke ned i, hvor hver engine faktisk trækker fra.

Hvordan endte vi her? TGI's exit

Text Generation Inference (TGI) bar Hugging Face-økosystemet i årevis, men fra december 2025 accepterer det kun fejlrettelser, ingen nye funktioner. Hugging Faces egne Inference Endpoints bruger nu vLLM som standard, med SGLang som et alternativ.

Det efterlader to reelle kandidater til selv-hostet LLM-serving. Begge er open source, begge taler OpenAI API'en, og begge kører på NVIDIA GPU'er. Forskellene viser sig under belastning.

Konklusion: Både vLLM og SGLang er produktionsklare TGI-erstatninger. Hvis du migrerer, er begge et sikkert valg; resten af denne guide hjælper dig med at vælge hvilken.

Throughput- og latency-benchmarks

Benchmarks varierer afhængigt af model, GPU og samtidighed, så her er tal fra uafhængige tests på samme hardware. Følgende data stammer fra Spherons H100-benchmarks ved brug af Llama 3.3 70B Instruct i FP8 og PremAIs tests med Llama 3.1 8B.

Llama 3.3 70B på H100 (FP8)

Llama 3.1 8B på H100

På mindre modeller udvides kløften. PremAI målte SGLang til cirka 16.200 tok/s mod vLLM på 12.500 tok/s, hvilket giver SGLang en 29 % throughput-fordel. LMDeploy matchede SGLang her, men det er en anden snak.

Hvad tallene betyder

Ved 70B-skalaen er deltaet beskedent (3-5 %). Ved 8B-skalaen er det betydeligt. Mønsteret giver mening: SGLangs RadixAttention giver større gevinst, når prefill udgør en større del af de samlede omkostninger, hvilket sker med mindre modeller og kortere outputs.

Tail-latency fortæller en lignende historie. SGLangs TTFT p95 var konsekvent 5-8 % lavere end vLLMs ved alle testede samtidighedsniveauer. Hvis du bygger en realtids-chatgrænseflade, hvor hvert 50. millisekund betyder noget, ophobes denne forskel på tværs af brugere.

Konklusion: SGLang vinder på rå throughput, især for mindre modeller. vLLM ligger tæt på ved 70B+ skala. For de fleste produktions-workloads er forskellen i enkeltcifrede procenter, hvilket er meningsfuldt ved stor skala, men ikke afgørende i nogen retning.

Præfikscaching: RadixAttention vs automatisk præfikscaching

Begge engines cacher KV-beregninger for gentagne præfikser, men mekanismerne adskiller sig på måder, der betyder noget for visse workloads. Hvis du allerede er bekendt med prompt-caching på API-niveau, så tænk på dette som server-side-versionen.

vLLM bruger hashing på blok-niveau. Det opdeler KV-cachen i blokke af fast størrelse, hasher dem og slår matches op ved nye forespørgsler. Forudsigeligt, effektivt og let at forstå, men du har brug for konsistente blokgrænser for cache-hits.

SGLang bruger et radix-træ indekseret på token-niveau. Det opdager automatisk delte præfikser på tværs af forespørgsler uden manuel konfiguration. Hvis 50 brugere sender beskeder i den samme samtaletråd, finder og genbruger SGLang det fælles præfiks automatisk.

Hvor det faktisk betyder noget

RunPod benchmarkede flerrunders samtaler og fandt, at SGLang leverede ~30-31 tok/s konsekvent under høj samtidighed, mens vLLM faldt fra 22 til 16 tok/s, efterhånden som cachetrykket steg. Det er en meningsfuld forskel for chatbot- og agent-workloads.

Til batch-inferens på skabelonbaserede prompts, hvor hver forespørgsel bruger den samme system-prompt, fungerer vLLMs tilgang fint. Cache-grænserne justerer sig naturligt efter din skabelonstruktur.

Konklusion: SGLang vinder til dynamiske, flerrunders workloads. vLLM er fuldt ud tilstrækkelig til batch-inferens og skabelonbaserede prompts, hvor præfikser er forudsigelige.

Strukturerede outputs

Hvis du har brug for JSON-skema-håndhævelse eller begrænset generering, betyder dette afsnit meget. Begge engines understøtter strukturerede outputs gennem grammar-backends som XGrammar og LLGuidance, men performance-historien er meget anderledes.

SqueezeBits kørte detaljerede benchmarks og fandt, at vLLM viser betydelig throughput-forringelse med guided decoding aktiveret, især ved batch-størrelse 8 og derover. SGLang overlapper derimod maskegenerering med GPU-inferenstrinnet, hvilket holder overhead minimalt.

Repetitive vs dynamiske skemaer

Valget af backend betyder også noget:

Uden struktureret håndhævelse falder korrektheden til ~61 % på komplekse skemaer. Med den stiger korrektheden med 20-25 procentpoint. Så dette er ikke valgfrit for produktions-agent-workflows, og den engine, du vælger, bestemmer, hvor meget throughput du ofrer.

Konklusion: SGLang vinder til strukturerede outputs. Hvis din pipeline er afhængig af JSON-skema-håndhævelse (og det er de fleste agent-workflows), betyder SGLangs overlappede tilgang, at du ikke betaler en throughput-skatt.

Multi-LoRA og serving af finetunede modeller

Begge engines understøtter serving af flere LoRA-adapters fra en enkelt basismodel, hvilket er essentielt, hvis du finetuner modeller til forskellige lejere eller opgaver.

SGLang behandler multi-LoRA som en førsteklasses funktion med native batching; forespørgsler, der målretter forskellige adapters, kan dele den samme batch. vLLM understøtter det også, men SGLangs implementering har været lidt mere poleret i de seneste releases.

Den praktiske forskel? Hvis du serverer 5-10 LoRA-adapters fra én Llama 70B-basismodel, virker begge. Hvis du kører 50+ adapters med heterogene trafikmønstre, håndterer SGLangs native batching planlægningen mere elegant.

Konklusion: SGLang har en lille fordel ved multi-LoRA i stor skala. For en håndfuld adapters virker begge engines lige godt.

Spekulativ decoding

Begge engines understøtter spekulativ decoding, som bruger en lille "draft"-model til at forudsige tokens, som hovedmodellen derefter verificerer parallelt. Resultatet er 2-3 gange hurtigere inferens i memory-bound scenarier.

vLLM introducerede for nylig Unified Parallel Drafting, og spekulativ decoding fungerer nu sammen med strukturerede outputs. SGLangs implementering er lignende i kapacitet, med lidt bedre performance ved moderate samtidighedsniveauer.

Den rigtige differentiator er ikke enginen, men om spekulativ decoding passer til din workload. Det hjælper mest med lange outputs fra store modeller, hvor bottlenecken er memory-båndbredde, ikke beregning.

Konklusion: Uafgjort. Begge engines leverer sammenlignelige hastighedsforbedringer via spekulativ decoding.

Hardware-understøttelse og deployment

Her trækker vLLM markant fra.

vLLM

• NVIDIA GPU'er (A100, H100, H200, B200)
• AMD GPU'er (MI250, MI300X)
• Intel GPU'er (via vllm-xpu-kernels)
• AWS Trainium og Inferentia
• Google TPUs
• Moden Kubernetes-dokumentation med Helm-charts, startup/readiness/liveness-probes
• NVIDIA Container Toolkit-integration out of the box

SGLang

• NVIDIA GPU'er (A100, H100, H200, B200)
• AMD GPU'er (MI300X, via ROCm)
• Docker-først deployment
• Kubernetes er muligt, men mindre dokumenteret

Hvis du deployer på andet end NVIDIA eller AMD, er vLLM dit eneste valg. Specifikt på AWS betyder Trainium-understøttelsen, at du kan skære inferensomkostningerne betydeligt ned, og SGLang kan ikke røre den hardware.

For teams, der kører på standard NVIDIA GPU'er, er deployment-historien lignende. Begge leverer Docker-images og OpenAI-kompatible endpoints. vLLM har bare flere battle-tested produktionsguider og community-bidragne Helm-charts.

Hvis du udforsker værktøjer til at køre LLM'er lokalt eller ønsker et bredere overblik over selv-hostet inferens, understøtter begge engines også lokal deployment på forbruger-GPU'er, selvom de er designet til datacenter-hardware.

Konklusion: vLLM vinder på hardware-bredde og deployment-modenhed. SGLang er fint, hvis du er på NVIDIA eller AMD. Alle andre steder er vLLM det eneste valg.

Adskilt serving

Begge engines understøtter adskillelse af prefill (beregningstungt) fra decode (memorytungt) i forskellige worker-pools. Dette lader dig skalere hver fase uafhængigt; flere prefill-workers under prompt-tunge bursts, flere decode-workers til lang generering.

SGLang understøtter Mooncake og NIXL som transfer-backends til adskillelse og har publiceret resultater, der viser 2,7 gange højere decoding-throughput på NVIDIA GB200 NVL72-clustre. vLLMs adskilte serving er også funktionel, men mindre fremtrædende dokumenteret.

Denne funktion betyder mest ved meget stor skala (96+ GPU'er). Hvis du kører en håndfuld GPU'er, har du sandsynligvis ikke brug for det endnu.

Konklusion: SGLang har en lille fordel i modenhed for adskilt serving. Begge understøtter det; SGLang har publiceret flere resultater fra den virkelige verden.

Hvornår skal du bruge hvad: Beslutningsramme

Det ærlige svar for mange teams: prøv begge. De er begge open source, begge eksponerer den samme OpenAI API, og skift mellem dem er en container-swap. Kør din faktiske workload mod hver af dem i en dag og sammenlign de metrics, der betyder noget for dig.

Hvis du router trafik på tværs af flere inferens-backends, kan en LLM-gateway sidde foran enten engine og håndtere failover, rate limiting og observability.

Hvordan Techsy tilgår valg af inferens-server

Når vi hjælper teams med at deploye LLM-drevne funktioner, reduceres valget af inferens-engine til tre spørgsmål:

1. Hvilken hardware er du låst til? Hvis det er Trainium eller TPUs, er det vLLM. Alt andet, begge virker.
2. Hvad er formen på din workload? Flerrunders chat og agent-loops favoriserer SGLangs præfikscaching. Batch-behandling og simple completions er fine på enten.
3. Hvor meget ops-kapacitet har du? vLLMs større community betyder flere StackOverflow-svar og Helm-charts, når noget går galt kl. 3 om natten.

Vi har kørt produktions-workloads på begge. De er genuint tæt på. Det rigtige svar afhænger af dine begrænsninger, ikke af at den ene er "bedre" i abstrakt forstand.

Brug for hjælp til at vælge eller deploye en inferens-server? Kontakt os, vi vil vurdere din workload og anbefale den rigtige stack.

At vælge et værktøj er den nemme halvdel. At få det til at køre stabilt inde i et rigtigt produkt er, hvor de fleste teams går i stå, og det er præcis, hvad vores AI-integrationsteam bygger for klienter, fra RAG-pipelines til custom agents.

Ofte stillede spørgsmål

Er SGLang hurtigere end vLLM?

På mindre modeller (7B-8B) viser SGLang cirka 29 % højere throughput på H100 GPU'er. På 70B+ modeller indsnævres kløften til 3-5 %. SGLang har også lavere tail-latency (TTFT p95) ved alle testede samtidighedsniveauer.

Kan jeg bruge vLLM og SGLang med OpenAI API-formatet?

Ja. Begge eksponerer OpenAI-kompatible endpoints out of the box. Du kan bytte den ene ud med den anden uden at ændre din klientkode. Dine /v1/chat/completions-kald fungerer identisk på enten.

Hvorfor udfasede Hugging Face TGI?

TGI gik i vedligeholdelsestilstand i december 2025. Hugging Face besluttede at bidrage til vLLM og SGLang i stedet for at vedligeholde en separat inferens-engine. TGI virker stadig til eksisterende deployment, men der kommer ingen nye funktioner.

Understøtter SGLang NVIDIA- og AMD-GPU'er?

SGLang understøtter NVIDIA GPU'er (A100, H100, H200, B200) og AMD GPU'er (MI300X via ROCm). Det understøtter ikke Intel GPU'er, AWS Trainium, Inferentia eller Google TPUs. vLLM har bredere hardware-dækning.

Hvad er RadixAttention, og hvorfor betyder det noget?

RadixAttention er SGLangs mekanisme til præfikscaching. Det gemmer KV-cache-entrys i et radix-træ indekseret på token-niveau, hvilket automatisk opdager delte præfikser på tværs af forespørgsler. Dette gør flerrunders samtaler og RAG-pipelines betydeligt hurtigere, fordi gentaget kontekst ikke behöver genberegnes.

Hvilken engine er bedre til strukturerede JSON-outputs?

SGLang. Det overlapper grammar-maskegenerering med GPU-inferens, så håndhævelse af struktureret output næsten ikke påvirker throughput. vLLM viser mærkbar forringelse ved batch-størrelser på 8 og derover, når guided decoding er aktiveret.

Kan jeg serve flere LoRA-adapters fra én basismodel?

Begge engines understøtter multi-LoRA-serving. SGLang behandler det som en native funktion med batching på tværs af forskellige adapters i den samme request-batch. vLLM understøtter det også, men SGLangs planlægning er mere effektiv ved høje adapter-antal.

Hvad er adskilt prefill/decode-serving?

Det betyder at køre prefill-fasen (behandling af prompten) på separate GPU-workers fra decode-fasen (generering af tokens). Prefill er compute-bound; decode er memory-bound. Adskillelse af dem lader dig skalere hver uafhængigt. Begge engines understøtter dette, hvor SGLang har flere publicerede produktionsresultater.

Hvordan migrerer jeg fra TGI til vLLM eller SGLang?

Da alle tre eksponerer OpenAI-kompatible API'er, er migration stort set en container-swap. Peg din Docker Compose- eller Kubernetes-deployment mod det nye image, juster model loading-flags, og opdater health check-endpoints. Klientkoden forbliver den samme.

Skal jeg bruge vLLM eller SGLang til en RAG-pipeline?

SGLang er det stærkere valg til RAG. Dets RadixAttention cacher og genbruger automatisk de lange system-prompts og dokumentkontekster, som RAG-pipelines gentagne gange sender. vLLMs blok-niveau caching virker også, men du vil se bedre cache-hit-rates med SGLangs token-niveau tilgang, når dokumentchunks varierer lidt på tværs af forespørgsler.

Endelig konklusion

SGLang vinder flere kategorier, men vLLMs fordele – hardware-bredde og økosystem-modenhed – er den slags ting, der betyder noget kl. 3 om natten, når en node går ned.

Hvis du er på NVIDIA-hardware, og din workload involverer flerrunders samtaler, agenter med strukturerede outputs eller RAG-pipelines med delte præfikser, start med SGLang. Du får bedre throughput og lavere latency, hvor det tæller.

Hvis du har brug for multi-cloud-flexibilitet, understøttelse af ikke-NVIDIA-hardware eller trygheden ved det største open source LLM-serving-community, start med vLLM. Det er den sikrere standard, der vil tjene de fleste teams godt.

Uanset hvad er begge engines fremragende og bliver hurtigt bedre. Vælg én, deploy den, mål din faktiske workload, og skift, hvis tallene fortæller dig det. Den OpenAI-kompatible API gør det skift smertefrit.

Kilder

• 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