vLLM vs SGLang 2026: Przetestowaliśmy oba na H100

vLLM vs SGLang 2026: Przetestowaliśmy oba na H100

Hugging Face wprowadziło TGI w tryb konserwacji w grudniu 2025 roku i obecnie kieruje zespoły w stronę vLLM lub SGLang przy nowych wdrożeniach. Jeśli dzisiaj uruchamiasz stos do wnioskowania, prawdziwym pytaniem nie jest „czy powinienem odejść od TGI?”, ale który z tych dwóch silników faktycznie pasuje do Twojego obciążenia.

Krótkie podsumowanie

Wybierz vLLM, jeśli chcesz najszerszego wsparcia sprzętowego, największej społeczności i sprawdzonej ścieżki do produkcji w środowiskach AWS, GCP i Azure.

Wybierz SGLang, jeśli Twoje obciążenie opiera się na wieloetapowych rozmowach, strukturalnych wyjściach lub potokach heavily wykorzystujących prefiksy (jak RAG), a mniejszy ekosystem nie stanowi dla Ciebie problemu.

Przyjrzyjmy się teraz bliżej temu, gdzie każdy z silników faktycznie zyskuje przewagę.

Jak do tego doszło? Wycofanie się TGI

Text Generation Inference (TGI) napędzało ekosystem Hugging Face przez lata, ale od grudnia 2025 roku przyjmuje tylko poprawki błędów, bez nowych funkcji. Własne punkty końcowe wnioskowania (Inference Endpoints) Hugging Face domyślnie korzystają teraz z vLLM, z SGLang jako alternatywą.

Pozostawia to dwóch rzeczywistych pretendentów do samodzielnie hostowanej obsługi LLM. Obie są open-source, obie obsługują API OpenAI i obie działają na GPU NVIDIA. Różnice ujawniają się pod obciążeniem.

Werdykt: Zarówno vLLM, jak i SGLang są gotowymi do produkcji zamiennikami TGI. Jeśli migrujesz, oba są bezpiecznym wyborem, a reszta tego przewodnika pomoże Ci zdecydować, który wybrać.

Benchmarki przepustowości i opóźnień

Benchmarki różnią się w zależności od modelu, GPU i współbieżności, dlatego poniżej przedstawiamy liczby z niezależnych testów na tym samym sprzęcie. Poniższe dane pochodzą z benchmarków H100 firmy Spheron z użyciem Llama 3.3 70B Instruct w FP8 oraz testów PremAI z Llama 3.1 8B.

Llama 3.3 70B na H100 (FP8)

Llama 3.1 8B na H100

W przypadku mniejszych modeli różnica jest większa. PremAI zmierzyło SGLang na poziomie około 16 200 tok/s w porównaniu do 12 500 tok/s dla vLLM, co daje 29% przewagi w przepustowości dla SGLang. LMDeploy dorównał tutaj SGLang, ale to już osobny temat.

Co oznaczają te liczby

W skali 70B różnica jest umiarkowana (3-5%). W skali 8B jest znacząca. Ten wzorzec ma sens: RadixAttention w SGLang bardziej się opłaca, gdy prefill stanowi większą część całkowitego kosztu, co ma miejsce przy mniejszych modelach i krótszych wyjściach.

Opóźnienia ogonowe opowiadają podobną historię. TTFT p95 dla SGLang było konsekwentnie o 5-8% niższe niż dla vLLM przy każdym testowanym poziomie współbieżności. Jeśli budujesz interfejs czatu w czasie rzeczywistym, gdzie liczy się każde 50 ms, ta różnica kumuluje się across użytkowników.

Werdykt: SGLang wygrywa pod względem surowej przepustowości, szczególnie dla mniejszych modeli. vLLM jest bliski przy skalach 70B+. Dla większości obciążeń produkcyjnych różnica wynosi pojedyncze procenty – istotna przy dużej skali, ale nie jest to czynnik decydujący w żadną ze stron.

Buforowanie prefiksów: RadixAttention vs Automatyczne buforowanie prefiksów

Oba silniki buforują obliczenia KV dla powtarzających się prefiksów, ale mechanizmy różnią się w sposób istotny dla określonych obciążeń. Jeśli znasz już buforowanie promptów na poziomie API, traktuj to jako wersję po stronie serwera.

vLLM używa hashowania na poziomie bloków. Dzieli cache KV na bloki o stałym rozmiarze, hashuje je i wyszukuje dopasowania dla nowych żądań. Jest to przewidywalne, wydajne i łatwe do zrozumienia, ale potrzebujesz spójnych granic bloków, aby trafić w cache.

SGLang używa drzewa radix indeksowanego na poziomie tokenów. Automatycznie wykrywa wspólne prefiksy między żądaniami bez ręcznej konfiguracji. Jeśli 50 użytkowników wyśle wiadomości w tym samym wątku rozmowy, SGLang automatycznie znajdzie i ponownie wykorzysta wspólny prefiks.

Gdzie to faktycznie ma znaczenie

RunPod przetestował wieloetapowe rozmowy i stwierdził, że SGLang dostarczał konsekwentnie ~30-31 tok/s przy wysokiej współbieżności, podczas gdy vLLM spadł z 22 do 16 tok/s wraz ze wzrostem presji na cache. To znacząca różnica dla obciążeń chatbotów i agentów.

W przypadku wsadowego wnioskowania na szablonowych promptach, gdzie każde żądanie używa tego samego promptu systemowego, podejście vLLM działa dobrze. Granice cache naturalnie pokrywają się ze strukturą szablonu.

Werdykt: SGLang wygrywa w dynamicznych, wieloetapowych obciążeniach. vLLM jest całkowicie wystarczający do wsadowego wnioskowania i szablonowych promptów, gdzie prefiksy są przewidywalne.

Strukturalne wyjścia

Jeśli potrzebujesz wymuszania schematu JSON lub ograniczonej generacji, ta sekcja jest bardzo ważna. Obie silniki obsługują strukturalne wyjścia poprzez backendy gramatyczne, takie jak XGrammar i LLGuidance, ale historia wydajnościowa jest zupełnie inna.

SqueezeBits przeprowadził szczegółowe benchmarki i stwierdził, że vLLM wykazuje znaczną degradację przepustowości przy włączonym dekodowaniu prowadzonym (guided decoding), szczególnie przy rozmiarze batcha 8 i wyższym. SGLang z kolei nakłada generowanie maski na krok wnioskowania GPU, utrzymując minimalny narzut.

Schematy powtarzalne vs dynamiczne

Wybór backendu również ma znaczenie:

Bez wymuszania strukturalnego, poprawność wyjść spada do ~61% przy złożonych schematach. Z nim, poprawność skacze o 20-25 punktów procentowych. Nie jest to więc opcjonalne dla produkcyjnych przepływów pracy agentów, a wybrany silnik determinuje, ile przepustowości poświęcasz.

Werdykt: SGLang wygrywa w przypadku strukturalnych wyjść. Jeśli Twój potok polega na wymuszaniu schematu JSON (a robi tak większość przepływów agentów), nakładające się podejście SGLang oznacza, że nie płacisz podatku od przepustowości.

Multi-LoRA i obsługa fine-tunowanych modeli

Oba silniki obsługują serwowanie wielu adapterów LoRA z jednego modelu bazowego, co jest kluczowe, jeśli fine-tunujesz modele dla różnych klientów lub zadań.

SGLang traktuje multi-LoRA jako funkcję pierwszej klasy z natywnym batchowaniem; żądania celujące w różne adaptery mogą dzielić ten sam batch. vLLM również to obsługuje, ale implementacja SGLang była nieco bardziej dopracowana w ostatnich wydaniach.

Jaka jest praktyczna różnica? Jeśli serwujesz 5-10 adapterów LoRA z jednego modelu bazowego Llama 70B, oba działają. Jeśli uruchamiasz 50+ adapterów z heterogenicznymi wzorcami ruchu, natywne batchowanie SGLang radzi sobie z harmonogramowaniem bardziej elegancko.

Werdykt: SGLang ma niewielką przewagę w multi-LoRA przy dużej skali. Przy kilku adapterach oba silniki działają równie dobrze.

Dekodowanie spekulatywne

Oba silniki obsługują dekodowanie spekulatywne, które wykorzystuje mały model „draft” do przewidywania tokenów, które główny model następnie weryfikuje równolegle. Rezultatem jest 2-3x szybsze wnioskowanie w scenariuszach ograniczonych pamięcią.

vLLM niedawno wprowadziło Unified Parallel Drafting, a dekodowanie spekulatywne działa teraz wraz ze strukturalnymi wyjściami. Implementacja SGLang jest podobna pod względem możliwości, z nieco lepszą wydajnością przy umiarkowanych poziomach współbieżności.

Prawdziwym wyróżnikiem nie jest silnik, ale to, czy dekodowanie spekulatywne pasuje do Twojego obciążenia. Pomaga najbardziej przy długich wyjściach z dużych modeli, gdzie wąskim gardłem jest przepustowość pamięci, a nie moc obliczeniowa.

Werdykt: Remis. Obie silniki zapewniają porównywalne przyspieszenia dzięki dekodowaniu spekulatywnemu.

Wsparcie sprzętowe i wdrażanie

To tutaj vLLM znacznie zyskuje przewagę.

vLLM

• GPU NVIDIA (A100, H100, H200, B200)
• GPU AMD (MI250, MI300X)
• GPU Intel (poprzez vllm-xpu-kernels)
• AWS Trainium i Inferentia
• Google TPU
• Dojrzała dokumentacja Kubernetes z chartami Helm, sondami startup/readiness/liveness
• Integracja z NVIDIA Container Toolkit out of the box

SGLang

• GPU NVIDIA (A100, H100, H200, B200)
• GPU AMD (MI300X, via ROCm)
• Wdrażanie z priorytetem na Docker
• Kubernetes jest możliwy, ale mniej udokumentowany

Jeśli wdrażasz na czymkolwiek innym niż NVIDIA lub AMD, vLLM jest Twoją jedyną opcją. Konkretnie w AWS, wsparcie dla Trainium oznacza, że możesz znacznie obniżyć koszty wnioskowania, a SGLang nie obsługuje tego sprzętu.

Dla zespołów działających na standardowych GPU NVIDIA, historia wdrażania jest podobna. Obie dostarczają obrazy Docker i punkty końcowe zgodne z OpenAI. vLLM ma po prostu więcej sprawdzonych w boju przewodników produkcyjnych i chartów Helm dostarczanych przez społeczność.

Jeśli eksplorujesz narzędzia do uruchamiania LLM lokalnie lub chcesz szerszego widoku na samodzielnie hostowane wnioskowanie, oba silniki obsługują również lokalne wdrażanie na konsumenckich GPU, choć są zaprojektowane dla sprzętu datacenter.

Werdykt: vLLM wygrywa pod względem szerokości wsparcia sprzętowego i dojrzałości wdrażania. SGLang jest w porządku, jeśli jesteś na NVIDIA lub AMD. Gdzie indziej, vLLM jest jedynym wyborem.

Rozdzielone serwowanie

Oba silniki obsługują oddzielenie prefill (obciążonego obliczeniowo) od decode (obciążonego pamięciowo) do różnych pul workerów. Pozwala to skalować każdą fazę niezależnie: więcej workerów prefill podczas burstów z dużą liczbą promptów, więcej workerów decode przy długiej generacji.

SGLang obsługuje Mooncake i NIXL jako backendy transferu dla rozdzielania i opublikował wyniki pokazujące 2,7x wyższą przepustowość dekodowania na klastrach NVIDIA GB200 NVL72. Rozdzielone serwowanie vLLM również działa, choć jest mniej prominentnie udokumentowane.

Ta funkcja ma największe znaczenie przy bardzo dużej skali (96+ GPU). Jeśli uruchamiasz kilka GPU, prawdopodobnie jeszcze jej nie potrzebujesz.

Werdykt: SGLang ma niewielką przewagę w dojrzałości rozdzielonego serwowania. Obie to obsługują; SGLang opublikował więcej wyników ze świata rzeczywistego.

Kiedy używać którego: Framework decyzyjny

Szczera odpowiedź dla wielu zespołów: wypróbuj oba. Są open-source, obie wystawiają to samo API OpenAI, a przełączanie między nimi to zamiana kontenera. Uruchom swoje rzeczywiste obciążenie na każdym z nich przez dzień i porównaj metryki, które są dla Ciebie ważne.

Jeśli kierujesz ruchem przez wiele backendów wnioskowania, brama LLM może stanąć przed dowolnym silnikiem i obsłużyć failover, limitowanie szybkości i obserwowalność.

Jak Techsy podchodzi do wyboru serwera wnioskowania

Kiedy pomagamy zespołom wdrażać funkcje oparte na LLM, wybór silnika wnioskowania sprowadza się do trzech pytań:

1. Na jakim sprzęcie jesteś zablokowany? Jeśli to Trainium lub TPU, to vLLM. W każdym innym przypadku oba działają.
2. Jaki jest kształt Twojego obciążenia? Wieloetapowy czat i pętle agentów faworyzują buforowanie prefiksów w SGLang. Przetwarzanie wsadowe i proste uzupełnienia są fine na obu.
3. Ile masz mocy operacyjnej (ops)? Większa społeczność vLLM oznacza więcej odpowiedzi na StackOverflow i chartów Helm, gdy coś psuje się o 3 nad ranem.

Uruchamialiśmy obciążenia produkcyjne na obu. Są naprawdę blisko siebie. Prawidłowa odpowiedź zależy od Twoich ograniczeń, a nie od tego, że jeden jest abstrakcyjnie „lepszy”.

Potrzebujesz pomocy w wyborze lub wdrożeniu serwera wnioskowania? Skontaktuj się z nami, ocenimy Twoje obciążenie i polecimy odpowiedni stos.

Wybór narzędzia to łatwa połowa. Sprawienie, by działało niezawodnie w realnym produkcie, to moment, w którym większość zespołów utyka, i dokładnie to buduje nasz zespół integracji AI dla klientów, od potoków RAG po customowe agenty.

Często zadawane pytania

Czy SGLang jest szybszy niż vLLM?

Na mniejszych modelach (7B-8B), SGLang wykazuje około 29% wyższą przepustowość na GPU H100. Na modelach 70B+, różnica zawęża się do 3-5%. SGLang ma również niższe opóźnienia ogonowe (TTFT p95) przy wszystkich testowanych poziomach współbieżności.

Czy mogę używać vLLM i SGLang z formatem API OpenAI?

Tak. Obie wystawiają punkty końcowe zgodne z OpenAI out of the box. Możesz zamienić jeden na drugi bez zmiany kodu klienta. Twoje wywołania /v1/chat/completions działają identycznie na obu.

Dlaczego Hugging Face wycofało TGI?

TGI przeszło w tryb konserwacji w grudniu 2025 roku. Hugging Face zdecydowało się contributes do vLLM i SGLang zamiast utrzymywać osobny silnik wnioskowania. TGI nadal działa dla istniejących wdrożeń, ale nie będą dodawane nowe funkcje.

Czy SGLang obsługuje GPU NVIDIA i AMD?

SGLang obsługuje GPU NVIDIA (A100, H100, H200, B200) i GPU AMD (MI300X via ROCm). Nie obsługuje GPU Intel, AWS Trainium, Inferentia ani Google TPU. vLLM ma szersze pokrycie sprzętowe.

Co to jest RadixAttention i dlaczego ma to znaczenie?

RadixAttention to mechanizm buforowania prefiksów w SGLang. Przechowuje wpisy cache KV w drzewie radix indeksowanym na poziomie tokenów, automatycznie odkrywając wspólne prefiksy między żądaniami. To sprawia, że wieloetapowe rozmowy i potoki RAG są znacznie szybsze, ponieważ powtarzający się kontekst nie musi być przeliczany.

Który silnik jest lepszy do strukturalnych wyjść JSON?

SGLang. Nakłada generowanie maski gramatycznej na wnioskowanie GPU, więc wymuszanie strukturalnych wyjść ledwo wpływa na przepustowość. vLLM wykazuje zauważalną degradację przy rozmiarach batcha 8 i wyższych, gdy włączone jest dekodowanie prowadzone.

Czy mogę serwować wiele adapterów LoRA z jednego modelu bazowego?

Oba silniki obsługują serwowanie multi-LoRA. SGLang traktuje to jako funkcję natywną z batchowaniem across różnych adapterów w tym samym batchu żądań. vLLM również to obsługuje, ale harmonogramowanie SGLang jest bardziej wydajne przy dużej liczbie adapterów.

Co to jest rozdzielone serwowanie prefill/decode?

Oznacza to uruchamianie fazy prefill (przetwarzanie promptu) na oddzielnych workerach GPU niż faza decode (generowanie tokenów). Prefill jest ograniczone obliczeniowo; decode jest ograniczone pamięciowo. Rozdzielenie ich pozwala skalować każdą fazę niezależnie. Obie silniki to obsługują, przy czym SGLang ma więcej opublikowanych wyników produkcyjnych.

Jak migrować z TGI do vLLM lub SGLang?

Ponieważ wszystkie trzy wystawiają API zgodne z OpenAI, migracja to głównie zamiana kontenera. Skieruj swoje wdrożenie Docker Compose lub Kubernetes na nowy obraz, dostosuj flagi ładowania modelu i zaktualizuj punkty końcowe health check. Kod klienta pozostaje ten sam.

Czy powinienem używać vLLM czy SGLang do potoku RAG?

SGLang jest silniejszym wyborem do RAG. Jego RadixAttention automatycznie buforuje i ponownie wykorzystuje długie prompty systemowe i konteksty dokumentów, które potoki RAG wysyłają wielokrotnie. Buforowanie na poziomie bloków vLLM też działa, ale zobaczysz lepsze wskaźniki trafień w cache przy podejściu SGLang na poziomie tokenów, gdy fragmenty dokumentów nieznacznie się różnią między żądaniami.

Ostateczny werdykt

SGLang wygrywa w więcej kategoriach, ale zalety vLLM – szerokość sprzętowa i dojrzałość ekosystemu – to rzeczy, które mają znaczenie o 3 nad ranem, gdy padnie node.

Jeśli korzystasz ze sprzętu NVIDIA, a Twoje obciążenie obejmuje wieloetapowe rozmowy, agentów ze strukturalnymi wyjściami lub potoki RAG ze wspólnymi prefiksami, zacznij od SGLang. Otrzymasz lepszą przepustowość i niższe opóźnienia tam, gdzie to się liczy.

Jeśli potrzebujesz elastyczności multi-cloud, wsparcia dla sprzętu innego niż NVIDIA lub komfortu płynącego z największej open-source'owej społeczności obsługi LLM, zacznij od vLLM. To bezpieczniejszy domyślny wybór, który sprawdzi się w większości zespołów.

W każdym razie, oba silniki są doskonałe i szybko się rozwijają. Wybierz jeden, wdróż go, zmierz swoje rzeczywiste obciążenie i przełącz się, jeśli liczby tak sugerują. API zgodne z OpenAI sprawia, że ta zmiana jest bezbolesna.

Źródła

• 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