vLLM czy TensorRT-LLM: który silnik do on-prem LLM

Dlaczego wybór silnika to osobna decyzja od wyboru GPU

Kiedy firma policzy już ile GPU potrzebuje pod Llamę 70B, zwykle uznaje, że najtrudniejsza decyzja techniczna jest za nią. Nie jest. Ten sam serwer 2x H100 potrafi obsłużyć dwukrotnie różną liczbę użytkowników zależnie od tego, jaki silnik serwujący na nim postawimy i jak go skonfigurujemy. Sprzęt wyznacza sufit. Silnik decyduje, jak blisko tego sufitu realnie zajedziesz.

W praktyce dla on-prem LLM w średniej produkcji wybór sprowadza się do dwóch nazw: vLLM i TensorRT-LLM. Trzecia, SGLang, dochodzi tam, gdzie liczy się współdzielony kontekst (RAG, długie system prompty). Ten post porównuje je liczbami i kończy tabelą decyzyjną: który silnik do jakiego scenariusza. Bez tezy, że jeden jest zawsze lepszy, bo nie jest.

Co właściwie robią te silniki

Silnik serwujący (inference server) siedzi między modelem a użytkownikiem i odpowiada za trzy rzeczy: ładowanie wag do VRAM, zarządzanie kolejką requestów (batching) i zwracanie tokenów. Różnice między silnikami leżą głównie w tym, jak sprytnie robią batching i jak agresywnie optymalizują pod konkretny sprzęt.

vLLM to projekt open source o najszerszym wsparciu modeli i najprostszym wdrożeniu. Jego znakiem firmowym jest PagedAttention, czyli zarządzanie KV cache jak stronami pamięci w systemie operacyjnym. Model uruchamiasz jedną komendą, bez kroku kompilacji. Aktualizacja modelu to podmiana wag.

TensorRT-LLM to biblioteka NVIDIA, która kompiluje model do zoptymalizowanego silnika pod konkretną architekturę GPU (Hopper, Blackwell), konkretną precyzję i konkretny zakres batch size. Ta kompilacja to osobny krok, który trwa, ale w zamian daje najwyższy throughput, jaki karta jest w stanie wyprodukować.

SGLang to silnik z agresywnym prefix caching. Kiedy wiele requestów dzieli ten sam początek (ten sam długi system prompt, ten sam dokument w kontekście RAG), SGLang liczy tę wspólną część raz i reużywa. W czystym on-prem RAG to bywa decydujące.

Liczby: throughput i TTFT na H100

Poniższe wartości pochodzą z niezależnego benchmarku SqueezeBits na jednej karcie H100 SXM5 80GB, model Llama 3.3 70B Instruct w FP8, wersje vLLM 0.18, TensorRT-LLM 1.2 i SGLang 0.5.9. Metodyka: prompty ~512 tokenów wejścia, 256 tokenów wyjścia, pomiar przy rosnącej współbieżności.

Zagregowany throughput (tokeny wyjścia na sekundę), im więcej tym lepiej:

Współbieżność	vLLM	TensorRT-LLM	SGLang
1 request	120 tok/s	130 tok/s	125 tok/s
10 requestów	650 tok/s	710 tok/s	680 tok/s
50 requestów	1 850 tok/s	2 100 tok/s	1 920 tok/s
100 requestów	2 400 tok/s	2 780 tok/s	2 460 tok/s

Time to first token, mediana (p50) i p95, im mniej tym lepiej:

Współbieżność	vLLM p50	vLLM p95	TRT-LLM p50	TRT-LLM p95	SGLang p50	SGLang p95
1 request	45 ms	68 ms	38 ms	55 ms	42 ms	61 ms
10 requestów	120 ms	195 ms	105 ms	170 ms	112 ms	178 ms
50 requestów	380 ms	720 ms	340 ms	620 ms	360 ms	680 ms
100 requestów	740 ms	1 450 ms	680 ms	1 280 ms	710 ms	1 380 ms

Wzór jest czytelny: TensorRT-LLM prowadzi na każdym poziomie współbieżności, gdy silnik jest już skompilowany. Przewaga jest najmniejsza przy pojedynczym requeście (~8% nad vLLM) i największa przy 50 równoległych (~13%). Na TTFT ten sam kierunek: TRT-LLM ma niższe opóźnienie, a różnica rośnie w ogonie p95, czyli tam, gdzie użytkownik najbardziej odczuwa zacinanie.

Warto jednak znać drugą stronę. Starszy benchmark SqueezeBits na A100 (Llama 3 8B) pokazał, że przy bardzo ostrym limicie latencji i wymuszonym małym batchu (batch 4) to vLLM wychodził szybciej, 230 tok/s wobec 197 tok/s dla TRT-LLM. Innymi słowy: przewaga TensorRT-LLM materializuje się pod obciążeniem i batchingiem, a nie przy pojedynczych, latency-krytycznych requestach na małym modelu.

Co te liczby znaczą operacyjnie

Kilkanaście procent throughputu brzmi jak detal, dopóki nie przeliczysz go na użytkowników. Jeśli serwer w vLLM obsługuje 30 jednoczesnych sesji przy Twoim SLO, te same ~13% przewagi to realnie 3 do 4 dodatkowych sesji z tego samego sprzętu. Przy dwóch serwerach to jeden użytkownik więcej niż zerowy ROI z całej trzeciej karty, której nie musisz kupować.

Ale jest warunek: ta przewaga jest darmowa tylko wtedy, gdy model jest stabilny. Każda zmiana modelu, precyzji albo docelowego zakresu batch size w TensorRT-LLM oznacza ponowną kompilację silnika. vLLM tego kroku nie ma. Dlatego liczby z tabeli to nie cała historia. Druga połowa to koszt utrzymania.

Cold start i koszt utrzymania

To jest miejsce, w którym większość porównań się urywa, a decyzja on-prem naprawdę się rozstrzyga.

Silnik	Zimny start (pierwszy raz)	Kolejne przeładowania	Krok kompilacji
vLLM	~62 s	~62 s	brak
TensorRT-LLM	~28 min (kompilacja)	~90 s	tak, per wersja modelu
SGLang	~58 s	~58 s	brak

28 minut kompilacji TensorRT-LLM to nie błąd, to świadomy kompromis: budujesz silnik raz na wersję modelu, a potem serwujesz go miesiącami. Problem pojawia się, gdy Twój zespół często zmienia modele, testuje warianty kwantyzacji albo aktualizuje wersje co dwa tygodnie. Wtedy 28 minut per iteracja plus konieczność wersjonowania artefaktów silnika zamienia się w realny narzut DevOps, którego vLLM po prostu nie ma.

Zużycie VRAM jest praktycznie takie samo we wszystkich trzech silnikach (71 do 79 GB na H100 80GB przy tym modelu w FP8), więc pamięć nie jest tu kryterium wyboru. Kryterium jest to, ile masz rąk do utrzymania i jak stabilny jest Twój model.

H200 i długi kontekst: kiedy pamięć zmienia rachunek

Powyższe liczby to jedna karta H100. Przy wyborze między H100 a H200 dochodzi zmienna, która nie widać w tabeli throughputu z krótkimi promptami: pojemność i przepustowość pamięci. H200 ma 141 GB VRAM wobec 80 GB w H100, co przy długim kontekście RAG (15k do 30k tokenów wejścia, typowe dla dokumentacji technicznej) pozwala utrzymać większy KV cache i wyższy batch, zanim pamięć stanie się wąskim gardłem.

Tu wybór silnika zaczyna się przenikać z wyborem sprzętu. Na długim, współdzielonym kontekście SGLang z prefix cachingiem potrafi zniwelować przewagę throughputu TensorRT-LLM, bo nie liczy tego samego prefiksu raz na request. Reguła praktyczna: im bardziej Twoje prompty są unikalne, tym bardziej liczy się surowy throughput (TRT-LLM); im więcej dzielą wspólnego kontekstu, tym bardziej opłaca się prefix caching (SGLang).

Tabela decyzyjna: który silnik do jakiego on-prem

Scenariusz on-prem	Rekomendacja	Dlaczego
Jeden stabilny model, maksymalny throughput pod obciążeniem	TensorRT-LLM	Najwyższe tok/s i najniższy TTFT, kompilację robisz raz
Częsta zmiana modeli, mały zespół IT, szybka iteracja	vLLM	Zero kompilacji, najszersze wsparcie modeli, najprostszy deploy
RAG ze wspólnym system promptem lub długim kontekstem	SGLang	Prefix caching reużywa wspólną część, niższa latencja
Pierwsze wdrożenie, jeszcze nie wiesz co serwujesz	vLLM	Bezpieczny default, zejdziesz z niego gdy model się ustabilizuje
Latencja pojedynczego requestu krytyczna, mały model	vLLM lub TRT-LLM	Przy wymuszonym małym batchu różnice się zacierają, testuj oba

Rekomendacja domyślna

Dla większości średnich firm wchodzących w on-prem AI rozsądny start to vLLM: zero kompilacji, najszersze wsparcie modeli i najmniejszy narzut na zespół, który dopiero uczy się operować własnym LLM. Kiedy model się ustabilizuje, a ruch urośnie na tyle, że kilkanaście procent throughputu zaczyna przekładać się na oszczędność jednej karty, migracja na TensorRT-LLM staje się policzalna. Jeśli od początku wiesz, że Twój główny workload to RAG na wspólnej bazie dokumentów, SGLang wart jest testu równolegle do vLLM już na starcie.

Najgorsza decyzja to wybór silnika pod benchmark z bloga producenta zamiast pod własny profil ruchu. Zmierz swój realny rozkład długości promptów, współbieżności i częstotliwości zmian modelu, a dopiero potem czytaj tabele. Liczby wyżej są punktem startu do rozmowy, nie werdyktem.

// co tu nie pokrywamCzego tu nie pokrywam

• Multi-node i tensor parallelism ponad jeden serwer. Wszystkie liczby wyżej to pojedyncza karta lub jeden node. Skalowanie na 8+ GPU ma własne wąskie gardła (interconnect, pipeline parallelism) i zasługuje na osobny post.
• Dokładny tuning kernel flag i wersji CUDA. Wahania ±10 do 15% między wersjami silnika i driverów są normalne. Traktuj tabele jako rząd wielkości, nie jako gwarancję.
• Alternatywy non-NVIDIA (AMD MI300X, Intel Gaudi). Wsparcie w tych silnikach dojrzewa, ale dla mieszanego inference w produkcji średniej firmy wciąż jest niedojrzałe.
• Jakość modelu. Silnik nie zmienia tego, co model potrafi, tylko jak szybko to podaje. Wybór modelu i kwantyzacji to osobna rozmowa.

// disclosure i biasesDisclosure i biases

Pracuję nad on-prem AI platformą (CortexMine) dla europejskich producentów. Liczby w tym poście pochodzą z publicznego benchmarku SqueezeBits i publicznych wytycznych doboru silników, nie z naszych wewnętrznych testów. Tam, gdzie źródła się różniły (A100 kontra H100, mały kontra duży model), zaznaczyłem to w tekście, bo wnioski nie są uniwersalne.

Stronniczość, której jestem świadom: piszę z perspektywy „on-prem jest realnym wyborem", więc naturalnie skupiam się na kryteriach utrzymania i kontroli, a nie tylko na surowym throughpucie. Firma, która serwuje jeden model przez rok bez zmian, ma inny rachunek niż zespół iterujący co dwa tygodnie, i staram się to rozdzielać.

Powiązane notatki

• Sizing: GPU sizing dla Llama 3.1 70B inference: liczby z benchmarków — ile kart kupić, zanim zdecydujesz jaki silnik na nich postawić.
• Koszt: Ile kosztuje milion tokenów on-prem: H100 vs H200 vs API — jak throughput przekłada się na koszt per 1M tokenów.
• Kwantyzacja: Dobór GPU i kwantyzacja LLM, gdy H200 jest niedostępny — FP8 i INT4, które te silniki obsługują różnie.
• Observability: Monitoring i observability dla on-prem LLM: co logować — co mierzyć na produkcji, żeby wiedzieć, czy silnik dowozi.
• Pillar: AI on-prem w europejskiej produkcji 2026: przewodnik architektoniczny — szerszy kontekst całej architektury.