vLLM - serwowanie modeli LLM z własnego serwera (co to, vs Ollama, jak uruchomić)

Co to jest vLLM w skrócie

W skrócie: vLLM to otwartoźródłowy silnik do serwowania modeli LLM o wysokiej przepustowości. Uruchamia model raz i obsługuje wiele zapytań równolegle przez API zgodne z OpenAI. W odróżnieniu od Ollamy (wygoda, jeden użytkownik lokalnie) vLLM celuje w produkcję i obciążenie zespołowe na serwerze z GPU.

Konkret: jeśli chcesz pogadać z modelem na własnym laptopie, zostań przy Ollamie. Jeśli budujesz aplikację, która ma odpytywać model setki razy na minutę dla wielu użytkowników naraz - to jest robota dla vLLM. To nie jest „klik i czat", to komponent infrastruktury, który stawiasz na serwerze i podpinasz pod aplikację.

Jeśli dopiero wchodzisz w temat lokalnych modeli, zacznij od przewodnika Ollama i powstał w Sky Computing Lab na UC Berkeley. Dziś rozwija go społeczność - ponad 2000 kontrybutorów, a wspieranych jest ponad 200 architektur modeli (dane projektu).

Sedno vLLM to trzy pojęcia, które warto znać, zanim postawisz serwer:

• PagedAttention - sposób zarządzania pamięcią podręczną modelu (KV cache) na wzór stron pamięci w systemie operacyjnym. To on odpowiada za wydajność: mniej marnowanego VRAM, więcej równoległych sekwencji.
• Continuous batching - vLLM dokłada nowe zapytania do trwającej obróbki wsadowej w locie, zamiast czekać, aż zbierze się pełna paczka. Dzięki temu GPU nie stoi bezczynnie.
• API zgodne z OpenAI - serwer wystawia endpoint /v1/chat/completions, taki sam jak OpenAI. To znaczy, że aplikacja napisana pod ChatGPT działa z vLLM po zmianie jednego adresu.

vLLM ładnie współpracuje z modelami z Hugging Face - obsłuży rodziny Llama, Qwen, Gemma, Mixtral czy DeepSeek-V3. Pod spodem korzysta z CUDA (NVIDIA) i HIP (AMD), a przez wtyczki sprzętowe wspiera też Google TPU, Intel Gaudi czy Apple Silicon. To zależy od budżetu, ale zdecydowana większość wdrożeń stoi na kartach NVIDIA - i tego się trzymajmy w dalszej części.

Jak działa vLLM - dlaczego jest szybki

Pytanie, które słyszę najczęściej: skoro model jest ten sam, czemu vLLM jest szybszy od naiwnego uruchomienia w bibliotece Transformers? Odpowiedź leży w pamięci i kolejkowaniu.

Krok po kroku, co się dzieje pod maską:

• PagedAttention tnie marnotrawstwo VRAM. Klasyczne serwowanie rezerwuje pamięć na maksymalną długość odpowiedzi z góry, przez co połowa VRAM leży odłogiem. vLLM przydziela pamięć stronami, dokładnie tyle, ile trzeba - i upycha więcej równoległych rozmów na tej samej karcie.
• Continuous batching trzyma GPU zajęte. Gdy jedno zapytanie kończy generować tekst, jego miejsce w batchu natychmiast zajmuje następne z kolejki. Karta nie czeka na najwolniejszego w paczce.
• Zoptymalizowane jądra obliczeniowe. vLLM korzysta z rozwiązań pokroju FlashAttention i skompilowanych jąder przez torch.compile, co skraca czas pojedynczej operacji.

Efekt jest jakościowy: przy wielu równoczesnych użytkownikach vLLM obsługuje znacznie więcej zapytań na sekundę niż podejście naiwne, przy lepszym wykorzystaniu tej samej karty. Trade-off: dla pojedynczego zapytania na raz ta przewaga topnieje - cały zysk bierze się z równoległości. Dlatego vLLM świeci przy ruchu, a nie przy jednym „cześć, jak się masz". Konkretne mnożniki przepustowości zależą od modelu, karty i długości promptu - w dokumentacji projektu znajdziesz liczby dla typowych konfiguracji.

vLLM vs Ollama - kiedy który

To jest sedno decyzji, więc rozłóżmy ją na tabelę. Oba narzędzia serwują lokalne modele, ale celują w inny scenariusz.

Werdykt - kiedy który:

• Wybierz Ollamę, gdy uczysz się tematu, budujesz prototyp, pracujesz sam na laptopie albo chcesz szybko sprawdzić model. Zero konfiguracji, działa też bez mocnej karty. Porównanie z desktopowym konkurentem znajdziesz w tekście LM Studio vs Ollama.

Wymagania sprzętowe - czy odpalisz vLLM

Tu robi się poważnie, bo to najczęstszy punkt, w którym ludzie się przewracają. vLLM to silnik GPU - realnie potrzebujesz karty NVIDIA z obsługą CUDA i sporej ilości pamięci VRAM.

Konkret o VRAM: model w precyzji FP16 zajmuje z grubsza dwa razy tyle gigabajtów, ile ma miliardów parametrów. Model 7B to około 14-16 GB VRAM, więc mieści się na jednej karcie 24 GB z zapasem na kontekst. Większe modele, jak 70B, wymagają albo kilku kart (tensor parallelism), albo mocnej kwantyzacji.

Krok po kroku, jak zmieścić model w karcie:

• Kwantyzacja. Formaty AWQ i GPTQ zmniejszają model, obniżając precyzję wag - dzięki temu 7B zmieści się w mniejszej karcie, a większy model w tym, co masz. Kosztem odrobiny jakości.
• Parametr --max-model-len. Skrócenie maksymalnej długości kontekstu zwalnia sporo VRAM. Jeśli nie potrzebujesz gigantycznego okna kontekstu, przytnij je.
• Multi-GPU. Przy naprawdę dużych modelach rozkładasz je na kilka kart. To już konfiguracja serwerowa, nie laptopowa.

Trade-off jest jasny: CPU albo Apple Silicon do vLLM to zła para - silnik jest pisany pod GPU serwerowe. Jeśli masz tylko MacBooka albo słabe GPU, zostań przy Ollamie lub LM Studio i nie walcz z wiatrakami. Dobór modelu pod ilość VRAM rozkładamy na czynniki pierwsze w tekście dobór modelu pod VRAM; dotrenowany model potem serwujesz właśnie przez vLLM.

Jakie karty GPU pod vLLM - konkretne modele

Konkret: nie każda karta z napisem NVIDIA nadaje się pod produkcyjne serwowanie. Liczy się przede wszystkim ilość VRAM, bo to ona decyduje, jak duży model wejdzie i ilu użytkowników obsłużysz naraz. Oto realny przekrój kart, które spotkasz w tym zadaniu - od budżetowej używki po sprzęt datacenter:

• NVIDIA RTX 3090 (24 GB VRAM) - używana karta z poprzedniej generacji, najtańsze wejście w 24 GB. Uciągnie model 7B-13B na jednej sztuce. Rząd cenowy 3000-4500 zł za sztukę na rynku wtórnym, wg aktualnej oferty.
• NVIDIA RTX 4090 (24 GB VRAM) - topowa karta konsumencka, sporo mocy obliczeniowej przy tych samych 24 GB. Rząd 8000-11000 zł, wg aktualnej oferty.
• NVIDIA RTX A6000 (48 GB VRAM) - karta profesjonalna, 48 GB mieści model 30B lub dwa mniejsze naraz. Rząd kilkunastu tysięcy złotych za sztukę.
• NVIDIA L40S (48 GB VRAM) - datacenterowa karta inferencyjna, projektowana pod całodobową pracę serwerową. Wydatek rzędu kilkudziesięciu tysięcy złotych.
• NVIDIA A100 (40 lub 80 GB VRAM) - koń roboczy poważnych wdrożeń, wersja 80 GB obsłuży duże modele bez dzielenia. Cena rzędu kilkudziesięciu tysięcy złotych za sztukę.
• NVIDIA H100 (80 GB VRAM) - obecny szczyt do trenowania i serwowania największych modeli. To wydatek liczony w setkach tysięcy złotych - dla większości firm nieopłacalny na własność.

Trade-off jest tu brutalnie prosty: im większy model chcesz serwować, tym więcej VRAM, a każdy kolejny próg VRAM to skokowy wzrost ceny. Dlatego przy modelach 7B-13B często wystarcza pojedyncza karta 24 GB, a po sprzęt datacenter sięgasz dopiero, gdy serwujesz naprawdę duże modele dla wielu użytkowników. I właśnie dlatego dla obciążenia 24/7 częściej opłaca się wynająć serwer z taką kartą, niż kupować ją na własność - o czym za chwilę.

Jak uruchomić vLLM - krok po kroku

Dobra wiadomość: start jest prostszy, niż się wydaje. Zakładam, że masz serwer z kartą NVIDIA i zainstalowanymi sterownikami CUDA.

Instalacja. Najprościej przez menedżer pakietów Pythona:

pip install vllm

Zalecanym instalatorem jest szybki uv, ale klasyczny pip też jest wspierany i wystarczy do startu.

Uruchomienie serwera. Jedna komenda stawia serwer z wybranym modelem z Hugging Face:

vllm serve <nazwa-modelu>

Serwer domyślnie nasłuchuje na porcie 8000 i od razu wystawia API zgodne z OpenAI. Podstawiasz nazwę modelu (np. z rodziny Llama czy Qwen) i po chwili masz działający endpoint.

Wariant z Dockerem. Jeśli wolisz kontener - a przy serwerze produkcyjnym polecam - jest oficjalny obraz vllm/vllm-openai z Docker Hub (ponad 10 milionów pobrań, dane projektu):

docker run --gpus all \
  -p 8000:8000 \
  --shm-size=8g \
  vllm/vllm-openai \
  --model <nazwa-modelu>

Pro tip admina: flaga --gpus all jest obowiązkowa - bez niej kontener nie zobaczy karty i vLLM padnie na starcie. Parametr --shm-size warto podnieść, bo domyślne 64 MB pamięci współdzielonej to za mało przy pracy na wielu kartach.

Test API. Sprawdź, czy serwer odpowiada, zwykłym curl-em na endpoint zgodny z OpenAI:

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "<nazwa-modelu>", "messages": [{"role": "user", "content": "Czesc"}]}'

Jeśli w odpowiedzi dostaniesz JSON z treścią - serwer działa. To ten sam format, którego używa OpenAI, więc możesz go od razu podpiąć pod istniejący kod.

vLLM jako API zgodne z OpenAI

Tu leży największa siła vLLM z punktu widzenia dewelopera. Endpoint jest zgodny z OpenAI, więc to drop-in replacement - podmieniasz backend, a kod aplikacji zostaje.

Konkret: jeśli Twoja aplikacja korzysta z biblioteki openai w Pythonie, wystarczy zmienić base_url na adres własnego serwera vLLM i podać dowolny klucz. Reszta kodu, wszystkie wywołania czatu i parametry, działa bez zmian. Zamiast płacić OpenAI za każdy token, obsługujesz zapytania na własnej karcie.

Do czego to się przydaje w praktyce:

• Własny backend czatowy dla aplikacji lub wewnętrznego narzędzia firmy, bez wysyłania danych na zewnątrz.
• Prywatność danych - prompty i odpowiedzi nie opuszczają Twojego serwera, co bywa wymogiem przy wrażliwych danych.
• Przewidywalny koszt - płacisz za serwer, nie za tokeny; przy stałym, dużym ruchu to zwykle się opłaca.

To zależy od ruchu: przy sporadycznych zapytaniach API OpenAI bywa tańsze i wygodniejsze. Przy stałym obciążeniu 24/7 własny serwer z GPU odwraca ten rachunek. Jeśli budujesz na tym automatyzacje, model spięty przez API z narzędziem workflow to naturalny kolejny krok - jak to hostować, opisujemy w tekście hosting pod n8n i automatyzacje

Ścieżka B - chmura GPU na godziny. Do eksperymentów, testów i krótkich zadań sprawdzają się dostawcy chmury GPU rozliczani za godzinę pracy, tacy jak RunPod czy vast.ai (wspominam ich plain-text, jako opcję on-demand). Płacisz tylko za czas, w którym karta pracuje, ale przy pracy ciągłej rachunek szybko przewyższa stały serwer.

Pro tip admina: zanim wykupisz najmocniejszą kartę na rynku, policz realny koszt na dłuższą metę - z odnowieniem, nie z ceną promocyjną pierwszego miesiąca. Dla stałego ruchu dedykowany serwer z GPU u dostawcy bywa tańszy i mniej kłopotliwy niż utrzymywanie własnego sprzętu w domu. A jeśli obok modelu chcesz postawić automatyzacje, ten sam serwer obsłuży też hosting pod n8n i automatyzacje.

Częste błędy i pułapki

Zebrałem listę potknięć, na które admini wpadają najczęściej przy pierwszym uruchomieniu vLLM. Sprawdź je, zanim zaczniesz debugować na ślepo.

• Za mało VRAM - błąd OOM przy ładowaniu. Model nie mieści się w karcie. Rozwiązanie: mniejszy model, kwantyzacja AWQ lub GPTQ, albo obniżenie --max-model-len.
• Zapomniana flaga --gpus all w Dockerze. Kontener nie widzi karty i vLLM startuje na CPU albo pada. Zawsze dokładaj tę flagę.
• Mylenie vLLM z Ollamą. vLLM to nie jest „klik i działa" na laptopie - to serwer inferencji. Jeśli szukasz prostoty, wróć do Ollamy.
• Brak --shm-size przy wielu kartach. Domyślna pamięć współdzielona jest za mała i przy multi-GPU wyskakują błędy komunikacji między kartami.
• Model za bramką na Hugging Face. Część modeli wymaga akceptacji licencji i tokenu dostępu. Bez ustawionego tokenu vLLM nie pobierze wag.

FAQ - najczęstsze pytania

Co to jest vLLM?

vLLM to otwartoźródłowy silnik do serwowania dużych modeli językowych o wysokiej przepustowości. Uruchamia model raz i obsługuje wiele zapytań równolegle dzięki mechanizmowi PagedAttention. Wystawia API zgodne z OpenAI, więc łatwo podpiąć go pod istniejącą aplikację. Powstał na UC Berkeley i jest rozwijany jako projekt open-source.

vLLM czy Ollama - co wybrać?

To zależy od zastosowania. Ollamę wybierz do nauki, prototypu i pracy w pojedynkę na laptopie - jest prosta i działa od ręki. vLLM wybierz, gdy stawiasz produkcyjne API dla aplikacji, obsługujesz wielu użytkowników naraz i potrzebujesz maksymalnej przepustowości na serwerze z mocnym GPU.

Jakie GPU potrzebuje vLLM?

vLLM wymaga karty NVIDIA z obsługą CUDA i sporej ilości pamięci VRAM. Zasada kciuka: model w precyzji FP16 zajmuje około dwa razy tyle gigabajtów, ile ma miliardów parametrów, więc model 7B potrzebuje około 14-16 GB. Karta 24 GB, jak RTX 3090 czy RTX 4090, uciągnie mniejsze modele; większe wymagają A100 albo kilku kart.

Czy vLLM działa na CPU lub Apple Silicon?

Słabo. vLLM to silnik pisany pod serwerowe GPU i na CPU albo Apple Silicon nie pokaże swoich atutów. Jeśli masz tylko MacBooka lub komputer bez mocnej karty NVIDIA, do lokalnej pracy z modelem lepszym wyborem będzie Ollama albo LM Studio, które radzą sobie na skromniejszym sprzęcie.

Jak uruchomić w vLLM API zgodne z OpenAI?

Wystarczy komenda vllm serve z nazwą modelu - serwer od razu wystawia endpoint /v1/chat/completions na porcie 8000. W swojej aplikacji zmieniasz tylko adres base_url biblioteki OpenAI na adres serwera vLLM. Cała reszta kodu działa bez zmian, bo format API jest identyczny.

Ile kosztuje uruchomienie vLLM?

Sam vLLM jest darmowy - to projekt open-source na licencji Apache 2.0. Realny koszt to serwer lub VPS z GPU, na którym postawisz silnik. Współdzielony hosting odpada, bo potrzebujesz dedykowanej karty non stop. Ceny sprzętu z GPU sprawdź w aktualnej ofercie dostawcy, bo zależą od modelu karty.