vLLM vs SGLang 2026: Otestovali jsme oba na H100

vLLM vs SGLang 2026: Otestovali jsme oba na H100

Hugging Face převedlo TGI do režimu údržby v prosinci 2025 a nyní nasměrovává týmy k vLLM nebo SGLang pro nová nasazení. Pokud dnes stavíte stack pro inferenci, skutečná otázka není „měl bych přejít z TGI?“, ale který z těchto dvou engineů skutečně vyhovuje vaší zátěži.

Rychlé shrnutí

Zvolte vLLM, pokud chcete nejširší podporu hardwaru, největší komunitu a ověřenou cestu k produkčnímu nasazení napříč AWS, GCP a Azure.

Zvolte SGLang, pokud je vaše zátěž náročná na vícekolové konverzace, strukturované výstupy nebo pipeline s těžkými prefixy, jako je RAG, a nevadí vám menší ekosystém.

Nyní si rozeberme, kde každý engine skutečně vyniká.

Jak jsme se sem dostali? Odchod TGI

Text Generation Inference (TGI) neslo ekosystém Hugging Face roky, ale od prosince 2025 přijímá pouze opravy chyb, žádné nové funkce. Vlastní Inference Endpoints od Hugging Face nyní defaultně používají vLLM, přičemž SGLang je alternativou.

To ponechává dva skutečné uchazeče pro self-hosted serving LLM. Obě jsou open-source, obě komunikují přes OpenAI API a obě běží na GPU NVIDIA. Rozdíly se projeví pod zátěží.

Verdikt: vLLM i SGLang jsou produkčně zralé náhrady za TGI. Pokud migrujete, obě jsou bezpečnou volbou; zbytek tohoto průvodce vám pomůže vybrat tu pravou.

Benchmarky propustnosti a latence

Benchmarky se liší podle modelu, GPU a concurrency, takže zde uvádíme čísla z nezávislých testů na stejném hardwaru. Následující data pocházejí z benchmarků H100 od Spheronu pomocí Llama 3.3 70B Instruct ve FP8 a testů PremAI s Llama 3.1 8B.

Llama 3.3 70B na H100 (FP8)

Llama 3.1 8B na H100

U menších modelů se rozdíl zvětšuje. PremAI naměřilo u SGLang přibližně 16 200 tok/s oproti 12 500 tok/s u vLLM, což znamená výhodu v propustnosti o 29 % pro SGLang. LMDeploy se zde vyrovnal SGLang, ale to je jiné téma.

Co nám čísla říkají

V měřítku 70B je delta modestní (3–5 %). V měřítku 8B je významná. Tento vzorec dává smysl: RadixAttention od SGLang se více vyplácí, když je prefill větší částí celkových nákladů, což se děje u menších modelů a kratších výstupů.

Tail latency vypráví podobný příběh. TTFT p95 u SGLang bylo konzistentně o 5–8 % nižší než u vLLM na všech testovaných úrovních concurrency. Pokud budujete rozhraní pro chat v reálném čase, kde záleží na každých 50 ms, tento rozdíl se u uživatelů sčítá.

Verdikt: SGLang vítězí v hrubé propustnosti, zejména u menších modelů. vLLM je blízko v měřítku 70B+. Pro většinu produkčních zátěží je rozdíl v jednotkách procent, což je ve velkém měřítku významné, ale ani jedna strana není dealbreakerem.

Ukládání prefixů do cache: RadixAttention vs Automatic Prefix Caching

Oba enginy cachují KV výpočty pro opakující se prefixy, ale mechanismy se liší způsobem, který matters pro určité zátěže. Pokud již znáte ukládání promptů do cache na úrovni API, berte toto jako serverovou verzi.

vLLM používá hashování na úrovni bloků. Rozděluje KV cache do bloků pevné velikosti, hashuje je a hledá shody u nových požadavků. Je to předvídatelné, efektivní a snadno pochopitelné, ale pro zásahy do cache potřebujete konzistentní hranice bloků.

SGLang používá radixový strom indexovaný na úrovni tokenů. Automaticky objevuje sdílené prefixy napříč požadavky bez manuální konfigurace. Pokud 50 uživatelů pošle zprávy ve stejném konverzačním vláknu, SGLang najde a znovu použije společný prefix automaticky.

Kde to skutečně matters

RunPod otestoval vícekolové konverzace a zjistil, že SGLang dodávalo konzistentně ~30–31 tok/s při vysoké concurrency, zatímco vLLM kleslo z 22 na 16 tok/s, jak rostl tlak na cache. To je významný rozdíl pro workloady chatbotů a agentů.

Pro batch inferenci na šablonových promptech, kde každý požadavek používá stejný systémový prompt, přístup vLLM funguje dobře. Hranice cache se přirozeně zarovnávají se strukturou vaší šablony.

Verdikt: SGLang vítězí u dynamických, vícekolových zátěží. vLLM je zcela dostačující pro batch inferenci a šablonové prompty, kde jsou prefixy předvídatelné.

Strukturované výstupy

Pokud potřebujete vynucení JSON schématu nebo omezenou generaci, tato sekce je velmi důležitá. Obě enginy podporují strukturované výstupy prostřednictvím gramatických backendů, jako jsou XGrammar a LLGuidance, ale příběh výkonu je velmi odlišný.

SqueezeBits provedl podrobné benchmarky a zjistil, že vLLM vykazuje významný pokles propustnosti s povoleným guided decoding, zejména při velikosti dávky 8 a vyšší. SGLang naproti tomu překrývá generování masky s krokem inference na GPU, čímž udržuje režii minimální.

Opakující se vs. dynamická schémata

Volba backendu také matters:

Bez strukturovaného vynucení klesá správnost výstupů na ~61 % u složitých schémat. S ním správnost skočí o 20–25 procentních bodů. Takže to není volitelné pro produkční workflow agentů a engine, který zvolíte, určuje, kolik propustnosti obětujete.

Verdikt: SGLang vítězí u strukturovaných výstupů. Pokud vaše pipeline spoléhá na vynucení JSON schématu (což většina workflow agentů dělá), překrývající se přístup SGLang znamená, že neplatíte daň za propustnost.

Multi-LoRA a serving fine-tuned modelů

Obě enginy podporují serving více LoRA adapterů z jednoho základního modelu, což je nezbytné, pokud fine-tunujete modely pro různé tenanty nebo úkoly.

SGLang považuje multi-LoRA za first-class feature s nativním dávkováním; požadavky cílící na různé adaptéry mohou sdílet stejnou dávku. vLLM to také podporuje, ale implementace SGLang byla v nedávných releasích mírně více vytříbená.

Praktický rozdíl? Pokud servírujete 5–10 LoRA adapterů z jednoho základního modelu Llama 70B, oba fungují. Pokud provozujete 50+ adapterů s heterogenními vzorci provozu, nativní dávkování SGLang zvládá plánování gracefulněji.

Verdikt: SGLang má mírnou výhodu pro multi-LoRA ve velkém měřítku. Pro handful adapterů fungují obě enginy stejně dobře.

Spekulativní dekódování

Obě enginy podporují spekulativní dekódování, které využívá malý „draft“ model k předpovědi tokenů, které hlavní model následně paralelně ověří. Výsledkem je 2–3x rychlejší inference pro scénáře omezené pamětí.

vLLM nedávno představilo Unified Parallel Drafting a spekulativní dekódování nyní funguje spolu se strukturovanými výstupy. Implementace SGLang je podobná co do schopností, s mírně lepším výkonem na středních úrovních concurrency.

Skutečným diferenciátorem není engine, ale zda spekulativní dekódování sedí vaší zátěži. Pomáhá nejvíce u dlouhých výstupů z velkých modelů, kde je úzkým hrdlem šířka pásma paměti, nikoliv výpočetní výkon.

Verdikt: Remíza. Obě enginy poskytují srovnatelná zrychlení díky spekulativnímu dekódování.

Podpora hardwaru a nasazení

Zde vLLM výrazně vede.

vLLM

• GPU NVIDIA (A100, H100, H200, B200)
• GPU AMD (MI250, MI300X)
• GPU Intel (přes vllm-xpu-kernels)
• AWS Trainium a Inferentia
• Google TPU
• Zralá dokumentace pro Kubernetes s Helm chartkami, startup/readiness/liveness sondami
• Integrace NVIDIA Container Toolkit out of the box

SGLang

• GPU NVIDIA (A100, H100, H200, B200)
• GPU AMD (MI300X, přes ROCm)
• Nasazení primárně přes Docker
• Kubernetes je možné, ale méně zdokumentované

Pokud nasazujete na cokoli jiného než NVIDIA nebo AMD, vLLM je vaší jedinou volbou. Konkrétně na AWS podpora Trainium znamená, že můžete významně snížit náklady na inferenci, a SGLang se k tomuto hardwaru nedostane.

Pro týmy běží na standardních GPU NVIDIA je příběh nasazení podobný. Obě poskytují Docker obrazy a endpointy kompatibilní s OpenAI. vLLM má jen více battle-tested produkčních průvodců a komunitou přispívaných Helm chartek.

Pokud zkoumáte nástroje pro spuštění LLM lokálně nebo chcete širší pohled na self-hosted inferenci, obě enginy podporují lokální nasazení na consumer GPU také, ačkoli jsou navrženy pro datacentrový hardware.

Verdikt: vLLM vítězí v šíři hardwarové podpory a zralosti nasazení. SGLang je v pořádku, pokud jste na NVIDIA nebo AMD. Kdekoli jinde je vLLM jedinou volbou.

Oddělený serving (Disaggregated Serving)

Obě enginy podporují oddělení prefill (náročné na výpočet) od dekódování (náročné na paměť) do různých poolů workerů. To vám umožňuje škálovat každou fázi nezávisle: více workerů pro prefill během burstů s těžkými prompty, více workerů pro dekódování pro dlouhou generaci.

SGLang podporuje Mooncake a NIXL jako transfer backends pro disagregaci a publikovalo výsledky ukazující 2,7x vyšší propustnost dekódování na clusterech NVIDIA GB200 NVL72. Oddělený serving vLLM je také funkční, ačkoli méně prominentně dokumentovaný.

Tato feature matters nejvíce ve velmi velkém měřítku (96+ GPU). Pokud provozujete handful GPU, pravděpodobně ji ještě nepotřebujete.

Verdikt: SGLang má mírnou výhodu ve zralosti odděleného servingu. Obě to podporují; SGLang publikovalo více reálných výsledků.

Kdy použít který: Rozhodovací framework

Upřímná odpověď pro mnoho týmů: vyzkoušejte obě. Jsou open-source, obě exponují stejné OpenAI API a přepínání mezi nimi je swap kontejneru. Spusťte svou skutečnou zátěž proti každému na jeden den a porovnejte metriky, které jsou pro vás důležité.

Pokud směrujete provoz napříč více inference backends, LLM gateway může stát před kterýmkoli enginem a zpracovat failover, rate limiting a observabilitu.

Jak Techsy přistupuje k výběru inference serveru

Když pomáháme týmům nasazovat funkce poháněné LLM, volba inference engine se redukuje na tři otázky:

1. Do jakého hardwaru jste uzamčeni? Pokud je to Trainium nebo TPU, je to vLLM. U všeho ostatního fungují obě.
2. Jaký je tvar vaší zátěže? Vícekolový chat a smyčky agentů favorizují caching prefixů v SGLang. Batch processing a jednoduché completions jsou v pořádku na obou.
3. Kolik ops kapacity máte? Větší komunita vLLM znamená více odpovědí na StackOverflow a Helm chartek, když se něco pokazí ve 3 ráno.

Provozovali jsme produkční zátěže na obou. Jsou skutečně blízko. Správná odpověď závisí na vašich omezeních, ne na tom, že by jeden byl abstraktně „lepší“.

Potřebujete pomoct s výběrem nebo nasazením inference serveru? Kontaktujte nás, posoudíme vaši zátěž a doporučíme správný stack.

Výběr nástroje je ta snazší polovina. Zprovoznit ho spolehlivě uvnitř skutečného produktu je místo, kde většina týmů uvízne, a přesně to je to, co náš tým pro AI integrace buduje pro klienty, od RAG pipeline po custom agenty.

Často kladené otázky

Je SGLang rychlejší než vLLM?

U menších modelů (7B–8B) vykazuje SGLang přibližně o 29 % vyšší propustnost na GPU H100. U modelů 70B+ se rozdíl zužuje na 3–5 %. SGLang má také nižší tail latenci (TTFT p95) na všech testovaných úrovních concurrency.

Mohu používat vLLM a SGLang s formátem OpenAI API?

Ano. Obě exponují endpointy kompatibilní s OpenAI out of the box. Můžete jeden zaměnit za druhý bez změny klientského kódu. Vaše volání /v1/chat/completions fungují identicky na obou.

Proč Hugging Face deprekovalo TGI?

TGI přešlo do režimu údržby v prosinci 2025. Hugging Face se rozhodlo přispívat do vLLM a SGLang místo udržování samostatného inference engine. TGI stále funguje pro existující nasazení, ale žádné nové funkce nepřijdou.

Podporuje SGLang GPU NVIDIA a AMD?

SGLang podporuje GPU NVIDIA (A100, H100, H200, B200) a GPU AMD (MI300X přes ROCm). Nepodporuje GPU Intel, AWS Trainium, Inferentia ani Google TPU. vLLM má širší pokrytí hardwaru.

Co je RadixAttention a proč to matters?

RadixAttention je mechanismus ukládání prefixů do cache v SGLang. Ukládá položky KV cache v radixovém stromu indexovaném na úrovni tokenů, automaticky objevuje sdílené prefixy napříč požadavky. To činí vícekolové konverzace a RAG pipeline výrazně rychlejšími, protože opakující se kontext nemusí být přepočítáván.

Který engine je lepší pro strukturované JSON výstupy?

SGLang. Překrývá generování gramatické masky s inferencí na GPU, takže vynucení strukturovaného výstupu sotva ovlivní propustnost. vLLM vykazuje znatelnou degradaci při velikostech dávky 8 a vyšších, když je povoleno guided decoding.

Mohu servírovat více LoRA adapterů z jednoho základního modelu?

Obě enginy podporují serving multi-LoRA. SGLang to považuje za nativní feature s dávkováním napříč různými adaptéry ve stejné dávce požadavků. vLLM to také podporuje, ale plánování SGLang je efektivnější při vysokém počtu adapterů.

Co je oddělený serving prefill/dekódování?

Znamená to spuštění fáze prefill (zpracování promptu) na oddělených GPU workerech od fáze dekódování (generování tokenů). Prefill je omezeno výpočtem; dekódování je omezeno pamětí. Jejich oddělení vám umožňuje škálovat každé nezávisle. Obě enginy to podporují, přičemž SGLang má více publikovaných produkčních výsledků.

Jak migrovat z TGI na vLLM nebo SGLang?

Protože všechny tři exponují API kompatibilní s OpenAI, migrace je většinou swap kontejneru. Nasměrujte své nasazení Docker Compose nebo Kubernetes na nový obraz, upravte flagy pro načítání modelu a aktualizujte endpointy health check. Klientský kód zůstává stejný.

Měl bych použít vLLM nebo SGLang pro RAG pipeline?

SGLang je silnější volbou pro RAG. Jeho RadixAttention automaticky cachuje a znovu používá dlouhé systémové prompty a kontexty dokumentů, které RAG pipeline opakovaně posílají. Caching na úrovni bloků vLLM funguje také, ale uvidíte lepší míru zásahů do cache s přístupem SGLang na úrovni tokenů, když se chunky dokumentů mezi požadavky mírně liší.

Finální verdikt

SGLang vítězí ve více kategoriích, ale výhody vLLM, šíře hardwaru a zralost ekosystému, jsou věci, které matters ve 3 ráno, když spadne node.

Pokud jste na hardwaru NVIDIA a vaše zátěž zahrnuje vícekolové konverzace, agenty se strukturovanými výstupy nebo RAG pipeline se sdílenými prefixy, začněte se SGLang. Získáte lepší propustnost a nižší latenci tam, kde to counts.

Pokud potřebujete flexibilitu mezi cloudy, podporu hardwaru jiného než NVIDIA nebo komfort největší open-source komunity pro serving LLM, začněte s vLLM. Je to bezpečnější default, který bude většině týmů dobře sloužit.

V každém případě jsou obě enginy vynikající a rychle se zlepšují. Vyberte jednu, nasaďte ji, změřte svou skutečnou zátěž a přepněte, pokud vám čísla řeknou, abyste tak učinili. API kompatibilní s OpenAI činí tento přepínání bezbolestným.

Zdroje

• 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