vLLM vs SGLang 2026: Le-am testat pe ambele pe H100

vLLM vs SGLang 2026: Le-am testat pe ambele pe H100

Hugging Face a pus TGI în modul de mentenanță în decembrie 2025 și îndrumă acum echipele către vLLM sau SGLang pentru noile implementări. Dacă configurezi astăzi o stivă de inferență, întrebarea reală nu este „ar trebui să renunț la TGI?”, ci care dintre aceste două motoare se potrivește cu adevărat sarcinii tale de lucru.

Rezumat rapid

Alege vLLM dacă dorești cea mai largă compatibilitate hardware, cea mai mare comunitate și o cale dovedită spre producție pe AWS, GCP și Azure.

Alege SGLang dacă sarcina ta de lucru se bazează puternic pe conversații multi-tur, ieșiri structurate sau pipeline-uri cu prefixe repetitive precum RAG, și ești confortabil cu un ecosistem mai mic.

Acum să analizăm unde fiecare motor are cu adevărat avantaj.

Cum am ajuns aici? Ieșirea TGI din scenă

Text Generation Inference (TGI) a susținut ecosistemul Hugging Face timp de ani, dar începând cu decembrie 2025 acceptă doar corecturi de erori, fără funcționalități noi. Endpoint-urile de inferență ale Hugging Face folosesc acum implicit vLLM, cu SGLang ca alternativă.

Rămân astfel doi candidați reali pentru servirea auto-gazduită a LLM. Ambele sunt open-source, ambele vorbesc API-ul OpenAI și ambele rulează pe GPU-uri NVIDIA. Diferențele apar sub sarcină.

Verdict: Atât vLLM, cât și SGLang sunt înlocuitori gata de producție pentru TGI. Dacă migrezi, oricare dintre ele este o alegere sigură; restul acestui ghid te ajută să decizi care.

Benchmark-uri de throughput și latență

Benchmark-urile variază în funcție de model, GPU și concurență, așa că iată cifre din teste independente pe același hardware. Următoarele date provin din benchmark-urile H100 ale Spheron folosind Llama 3.3 70B Instruct în FP8 și din testele PremAI cu Llama 3.1 8B.

Llama 3.3 70B pe H100 (FP8)

Llama 3.1 8B pe H100

La modelele mai mici, decalajul se lărgește. PremAI a măsurat SGLang la aproximativ 16.200 tok/s față de vLLM la 12.500 tok/s, un avantaj de throughput de 29% pentru SGLang. LMDeploy a egalat SGLang aici, dar aceasta este o discuție separată.

Ce înseamnă cifrele

La scala 70B, delta este modestă (3-5%). La scala 8B, este semnificativă. Modelul are sens: RadixAttention al SGLang își arată valoarea când prefill-ul reprezintă o fracțiune mai mare din costul total, ceea ce se întâmplă cu modele mai mici și ieșiri mai scurte.

Latența de coadă spune o poveste similară. TTFT p95 al SGLang a fost constant cu 5-8% mai mic decât cel al vLLM la fiecare nivel de concurență testat. Dacă construiești o interfață de chat în timp real unde fiecare 50ms contează, acest decalaj se cumulează între utilizatori.

Verdict: SGLang câștigă la throughput brut, în special pentru modelele mai mici. vLLM este aproape la scala 70B+. Pentru majoritatea sarcinilor de producție, diferența este de procente cu o singură cifră, semnificativă la scară, dar nu un impediment decisiv în niciun caz.

Cache de prefix: RadixAttention vs Automatic Prefix Caching

Ambele motoare cache-uiesc calculele KV pentru prefixele repetate, dar mecanismele diferă în moduri care contează pentru anumite sarcini de lucru. Dacă ești deja familiarizat cu cache-ul de prompt la nivel de API, consideră aceasta versiunea server-side.

vLLM folosește hashing la nivel de bloc. Împarte cache-ul KV în blocuri de dimensiune fixă, le哈希-uieste și caută potriviri pentru noile cereri. Predictibil, eficient și ușor de înțeles, dar ai nevoie de limite consistente ale blocurilor pentru hit-uri în cache.

SGLang folosește un arbore radix indexat la nivel de token. Descoperă automat prefixele partajate între cereri fără configurare manuală. Dacă 50 de utilizatori trimit mesaje în același fir de conversație, SGLang găsește și reutilizează automat prefixul comun.

Unde contează cu adevărat

RunPod a realizat benchmark-uri pentru conversații multi-tur și a descoperit că SGLang a livrat constant ~30-31 tok/s sub concurență ridicată, în timp ce vLLM a scăzut de la 22 la 16 tok/s pe măsură ce presiunea asupra cache-ului a crescut. Este un decalaj semnificativ pentru sarcinile de lucru de tip chatbot și agent.

Pentru inferența batch pe prompt-uri șablonizate, unde fiecare cerere folosește același prompt de sistem, abordarea vLLM funcționează bine. Limitele cache-ului se aliniază natural cu structura șablonului tău.

Verdict: SGLang câștigă pentru sarcini de lucru dinamice, multi-tur. vLLM este perfect adecvat pentru inferența batch și prompt-uri șablonizate unde prefixele sunt predictibile.

Ieșiri structurate

Dacă ai nevoie de impunerea schemei JSON sau de generare constrânsă, această secțiune contează foarte mult. Ambele motoare suportă ieșiri structurate prin back-end-uri gramaticale precum XGrammar și LLGuidance, dar povestea performanței este foarte diferită.

SqueezeBits a rulat benchmark-uri detaliate și a descoperit că vLLM arată o degradare semnificativă a throughput-ului cu decodarea ghidată activată, în special la dimensiunea batch-ului 8 și peste. SGLang, în schimb, suprapune generarea măștii cu pasul de inferență GPU, menținând overhead-ul minim.

Scheme repetitive vs dinamice

Alegerea back-end-ului contează, de asemenea:

Fără impunere structurată, corectitudinea ieșirilor scade la ~61% pentru scheme complexe. Cu ea, corectitudinea sare cu 20-25 de puncte procentuale. Așadar, acest aspect nu este opțional pentru fluxurile de lucru ale agenților de producție, iar motorul pe care îl alegi determină cât throughput sacrifici.

Verdict: SGLang câștigă la ieșiri structurate. Dacă pipeline-ul tău se bazează pe impunerea schemei JSON (și majoritatea fluxurilor de lucru ale agenților o fac), abordarea suprapusă a SGLang înseamnă că nu plătești o taxă de throughput.

Servirea modelelor Multi-LoRA și fine-tuned

Ambele motoare suportă servirea mai multor adaptoare LoRA dintr-un singur model de bază, ceea ce este esențial dacă fine-tune-uiești modele pentru diferiți chiriași sau sarcini.

SGLang tratează multi-LoRA ca o funcționalitate de primă clasă cu batch-ing nativ; cererile care vizează adaptoare diferite pot partaja același batch. vLLM îl suportă, de asemenea, dar implementarea SGLang a fost puțin mai finisată în lansările recente.

Diferența practică? Dacă servești 5-10 adaptoare LoRA de pe un singur model de bază Llama 70B, ambele funcționează. Dacă rulezi 50+ adaptoare cu tipare de trafic heterogene, batch-ingul nativ al SGLang gestionează programarea mai elegant.

Verdict: SGLang are un ușor avantaj pentru multi-LoRA la scară. Pentru câteva adaptoare, ambele motoare funcționează la fel de bine.

Decodare speculativă

Ambele motoare suportă decodarea speculativă, care folosește un model mic de „draft” pentru a prezice token-uri pe care modelul principal le verifică apoi în paralel. Rezultatul este o inferență de 2-3 ori mai rapidă pentru scenariile limitate de memorie.

vLLM a introdus recent Unified Parallel Drafting, iar decodarea speculativă funcționează acum alături de ieșirile structurate. Implementarea SGLang este similară ca capacități, cu performanțe puțin mai bune la niveluri moderate de concurență.

Diferențiatorul real nu este motorul, ci dacă decodarea speculativă se potrivește sarcinii tale de lucru. Ajută cel mai mult la ieșiri lungi de la modele mari, unde gâtul de sticlă este banda de memorie, nu calculul.

Verdict: Egalitate. Ambele motoare oferă accelerări comparabile prin decodare speculativă.

Suport hardware și implementare

Aici vLLM are un avantaj semnificativ.

vLLM

• GPU-uri NVIDIA (A100, H100, H200, B200)
• GPU-uri AMD (MI250, MI300X)
• GPU-uri Intel (prin vllm-xpu-kernels)
• AWS Trainium și Inferentia
• Google TPUs
• Documentație Kubernetes matură cu grafice Helm, probe de startup/readiness/liveness
• Integrare NVIDIA Container Toolkit out of the box

SGLang

• GPU-uri NVIDIA (A100, H100, H200, B200)
• GPU-uri AMD (MI300X, prin ROCm)
• Implementare orientată spre Docker
• Kubernetes este posibil, dar mai puțin documentat

Dacă implementezi pe altceva decât NVIDIA sau AMD, vLLM este singura ta opțiune. Specific pe AWS, suportul Trainium înseamnă că poți reduce semnificativ costurile de inferență, iar SGLang nu poate accesa acel hardware.

Pentru echipele care rulează pe GPU-uri NVIDIA standard, povestea implementării este similară. Ambele oferă imagini Docker și endpoint-uri compatibile OpenAI. vLLM are doar mai multe ghiduri de producție testate în luptă și grafice Helm contribuite de comunitate.

Dacă explorezi instrumente pentru rularea LLM-urilor local sau dorești o vedere mai largă asupra inferenței auto-gazduite, ambele motoare suportă implementarea locală pe GPU-uri consumer, deși sunt concepute pentru hardware de datacenter.

Verdict: vLLM câștigă la diversitatea hardware și maturitatea implementării. SGLang este bun dacă ești pe NVIDIA sau AMD. Oriunde altundeva, vLLM este singura alegere.

Servire disagregată

Ambele motoare suportă separarea prefill-ului (intensiv computațional) de decode (intensiv memorie) în pool-uri diferite de lucrători. Acest lucru îți permite să scalezi fiecare fază independent: mai mulți lucrători de prefill în timpul burst-urilor heavy pe prompt-uri, mai mulți lucrători de decode pentru generări lungi.

SGLang suportă Mooncake și NIXL ca back-end-uri de transfer pentru disagregare și a publicat rezultate care arată un throughput de decodare de 2,7 ori mai mare pe clustere NVIDIA GB200 NVL72. Servirea disagregată a vLLM este, de asemenea, funcțională, deși mai puțin proeminent documentată.

Această funcționalitate contează cel mai mult la scară foarte mare (96+ GPU-uri). Dacă rulezi câteva GPU-uri, probabil nu ai nevoie de ea încă.

Verdict: SGLang are un ușor avantaj la maturitatea servirii disagregate. Ambele o suportă; SGLang a publicat mai multe rezultate din lumea reală.

Când să folosești fiecare: Cadru de decizie

Răspunsul onest pentru multe echipe: încearcă-le pe ambele. Sunt ambele open-source, ambele expun același API OpenAI, iar trecerea de la una la alta este o simplă schimbare de container. Rulează sarcina ta de lucru reală împotriva fiecăreia timp de o zi și compară metricile care contează pentru tine.

Dacă direcționezi traficul across multiple back-end-uri de inferență, un gateway LLM poate sta în fața oricărui motor și poate gestiona failover-ul, limitarea ratei și observabilitatea.

Cum abordează Techsy selecția serverului de inferență

Când ajutăm echipe să implementeze funcționalități alimentate de LLM, alegerea motorului de inferență se reduce la trei întrebări:

1. De ce hardware ești legat? Dacă este Trainium sau TPUs, este vLLM. Pentru orice altceva, ambele funcționează.
2. Care este forma sarcinii tale de lucru? Chat-ul multi-tur și buclele de agenți favorizează cache-ul de prefix al SGLang. Procesarea batch și completările simple sunt fine pe oricare.
3. Câtă capacitate ops ai? Comunitatea mai mare a vLLM înseamnă mai multe răspunsuri pe StackOverflow și grafice Helm atunci când ceva se strică la 3 dimineața.

Am rulat sarcini de lucru de producție pe ambele. Sunt genuin apropiate. Răspunsul corect depinde de constrângerile tale, nu de faptul că unul este „mai bun” în abstract.

Ai nevoie de ajutor pentru a alege sau implementa un server de inferență? Contactează-ne, vom evalua sarcina ta de lucru și vom recomanda stiva potrivită.

Alegerea unui instrument este partea ușoară. Obținerea unei rulări fiabile într-un produs real este locul unde majoritatea echipelor se blochează, iar exact asta construiește echipa noastră de integrare AI pentru clienți, de la pipeline-uri RAG la agenți personalizați.

Întrebări frecvente

Este SGLang mai rapid decât vLLM?

La modelele mai mici (7B-8B), SGLang arată un throughput cu aproximativ 29% mai mare pe GPU-uri H100. La modelele 70B+, decalajul se îngustează la 3-5%. SGLang are, de asemenea, o latență de coadă mai mică (TTFT p95) la toate nivelurile de concurență testate.

Pot folosi vLLM și SGLang cu formatul API OpenAI?

Da. Ambele expun endpoint-uri compatibile OpenAI out of the box. Poți schimba unul cu celălalt fără a modifica codul clientului. Apelurile tale /v1/chat/completions funcționează identic pe oricare dintre ele.

De ce a depreciat Hugging Face TGI?

TGI a intrat în modul de mentenanță în decembrie 2025. Hugging Face a decis să contribuie la vLLM și SGLang în loc să mențină un motor de inferență separat. TGI funcționează încă pentru implementările existente, dar nu vor veni funcționalități noi.

Suportă SGLang GPU-uri NVIDIA și AMD?

SGLang suportă GPU-uri NVIDIA (A100, H100, H200, B200) și GPU-uri AMD (MI300X prin ROCm). Nu suportă GPU-uri Intel, AWS Trainium, Inferentia sau Google TPUs. vLLM are o acoperire hardware mai largă.

Ce este RadixAttention și de ce contează?

RadixAttention este mecanismul de cache de prefix al SGLang. Stochează intrările cache-ului KV într-un arbore radix indexat la nivel de token, descoperind automat prefixele partajate între cereri. Acest lucru face conversațiile multi-tur și pipeline-urile RAG semnificativ mai rapide deoarece contextul repetat nu trebuie recalculat.

Care motor este mai bun pentru ieșiri JSON structurate?

SGLang. Suprapune generarea măștii gramaticale cu inferența GPU, astfel încât impunerea ieșirii structurate abia impactează throughput-ul. vLLM arată o degradare vizibilă la dimensiuni ale batch-ului de 8 și peste când decodarea ghidată este activată.

Pot servi mai mulți adaptoare LoRA dintr-un singur model de bază?

Ambele motoare suportă servirea multi-LoRA. SGLang o tratează ca o funcționalitate nativă cu batch-ing across different adapters in the same request batch. vLLM o suportă, de asemenea, dar programarea SGLang este mai eficientă la număr mare de adaptoare.

Ce este servirea disagregată prefill/decode?

Înseamnă rularea fazei de prefill (procesarea prompt-ului) pe lucrători GPU separați de faza de decode (generarea token-urilor). Prefill este limitat de calcul; decode este limitat de memorie. Separarea lor îți permite să scalezi fiecare independent. Ambele motoare suportă acest lucru, SGLang având mai multe rezultate de producție publicate.

Cum migrez de la TGI la vLLM sau SGLang?

Deoarece toate trei expun API-uri compatibile OpenAI, migrarea este în mare parte o schimbare de container. Indică deployment-ul tău Docker Compose sau Kubernetes către noua imagine, ajustează flag-urile de încărcare a modelului și actualizează endpoint-urile de health check. Codul client rămâne același.

Ar trebui să folosesc vLLM sau SGLang pentru un pipeline RAG?

SGLang este alegerea mai puternică pentru RAG. RadixAttention-ul său cache-uiește și reutilizează automat prompt-urile lungi de sistem și contextele de documente pe care pipeline-urile RAG le trimit în mod repetat. Cache-ul la nivel de bloc al vLLM funcționează, de asemenea, dar vei vedea rate mai bune de hit în cache cu abordarea la nivel de token a SGLang când chunk-urile de document variază ușor între cereri.

Verdict final

SGLang câștigă mai multe categorii, dar avantajele vLLM, diversitatea hardware și maturitatea ecosistemului, sunt genul de lucruri care contează la 3 dimineața când un nod cade.

Dacă ești pe hardware NVIDIA și sarcina ta de lucru implică conversații multi-tur, agenți cu ieșiri structurate sau pipeline-uri RAG cu prefixe partajate, începe cu SGLang. Vei obține un throughput mai bun și o latență mai mică acolo unde contează.

Dacă ai nevoie de flexibilitate multi-cloud, suport pentru hardware non-NVIDIA sau confortul celei mai mari comunități open-source de servire LLM, începe cu vLLM. Este implicitul mai sigur care va deservi majoritatea echipelor bine.

Oricum ar fi, ambele motoare sunt excelente și se îmbunătățesc rapid. Alege unul, implementează-l, măsoară sarcina ta de lucru reală și schimbă dacă cifrele îți spun să o faci. API-ul compatibil OpenAI face acea schimbare nedureroasă.

Surse

• 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
• Documentația oficială SGLang
• Documentația oficială vLLM