Poradnik konfiguracji vLLM: serwowanie lokalnych LLM-ów z produkcyjną prędkością

Autor: Jakub Rusinowski · Ostatnia aktualizacja: 12 lipca 2026

W tym przewodniku

Ollama vs vLLM: który problem faktycznie masz?
Dwa pomysły, dzięki którym vLLM jest szybki
Krok 1 — Instalacja
Krok 2 — Uruchom serwowanie modelu
Krok 3 — Skieruj klientów OpenAI na swój endpoint
Którą kwantyzację wybrać: AWQ, GPTQ czy FP8
Lista kontrolna na produkcję
Najczęściej zadawane pytania

vLLM serwuje lokalne LLM-y z produkcyjną przepustowością — zwykle 5–20× więcej żądań na sekundę niż Ollama przy równoczesnym obciążeniu — dzięki PagedAttention i ciągłemu batchowaniu. Ten poradnik instaluje vLLM, wyjaśnia te dwa pomysły prostym językiem, pomaga wybrać właściwą kwantyzację (AWQ/GPTQ/FP8) i stawia endpoint zgodny z OpenAI, na który możesz skierować prawdziwy ruch.

Ostatnia aktualizacja: lipiec 2026

Ollama vs vLLM: który problem faktycznie masz?

Zanim cokolwiek zainstalujesz, spójrz na to trzeźwo — dla pojedynczego użytkownika vLLM *nie* jest szybszy:

	Ollama / llama.cpp	vLLM
Jeden użytkownik na czacie	Znakomicie	Porównywalnie, bez zysku
10–100 równoczesnych żądań	Kolejkuje, przepustowość się załamuje	Do tego został zbudowany
Format modelu	GGUF (skwantyzowany, odciążanie na CPU)	HF safetensors, AWQ/GPTQ/FP8
Sprzęt	Cokolwiek, w tym Maki	NVIDIA (CUDA) w pierwszej kolejności; AMD ROCm wspierane
Model utrzymania	Prostota aplikacji desktopowej	Prawdziwy serwer, którym administrujesz

Jeśli serwujesz sam sobie, zostań przy lokalnym API Ollama. Jeśli serwujesz zespołowi, aplikacji albo potokom wsadowym — wszędzie tam, gdzie żądania się *nakładają* — vLLM jest standardową odpowiedzią, a różnica jest dramatyczna: na jednym RTX 4090 serwującym model 8B Ollama utrzymuje mniej więcej 100–150 tok/s łącznie dla wszystkich użytkowników, podczas gdy vLLM utrzymuje 1000–2500+ tok/s zagregowanej przepustowości przy 30–100 równoległych żądaniach.

Dwa pomysły, dzięki którym vLLM jest szybki

PagedAttention. Każda rozmowa potrzebuje cache'u KV (pamięci roboczej modelu), który naiwne serwery alokują jako jeden ciągły blok o rozmiarze *maksymalnego możliwego* kontekstu — marnując 60–80% VRAM na wypełnienie. vLLM zarządza cache'em KV tak, jak system operacyjny zarządza RAM-em: w małych stronach, alokowanych na żądanie. Ten sam GPU, kilkakrotnie więcej równoczesnych rozmów utrzymywanych w pamięci.

Ciągłe batchowanie. Naiwne batchowanie czeka, aż wszystkie żądania w partii się zakończą, zanim rozpocznie kolejną — jedna długa odpowiedź blokuje wszystkich. vLLM planuje na poziomie *tokenów*: w chwili, gdy dowolna sekwencja się kończy, oczekujące żądanie zajmuje jej miejsce już w następnym przebiegu w przód. GPU nigdy nie stoi bezczynnie, dopóki w kolejce jest praca.

Żadna z tych sztuczek nie pomaga pojedynczemu żądaniu; obie zwielokrotniają przepustowość zagregowaną. Dlatego odpowiedź na pytanie „czy vLLM jest szybszy?” brzmi: „przy jakiej równoczesności?”.

Krok 1 — Instalacja

Wymagania: Linux (albo WSL2), Python 3.10–3.12, GPU NVIDIA z aktualnym sterownikiem (Compute Capability 7.0+; do modeli 7–8B w pełnej jakości zalecane 16 GB VRAM lub więcej).

python -m venv .venv && source .venv/bin/activate
pip install vllm

Ten jeden pakiet zawiera silnik wnioskowania oraz serwer zgodny z OpenAI. Dokumentacja: docs.vllm.ai.

Krok 2 — Uruchom serwowanie modelu

vLLM pobiera modele prosto z Hugging Face. Na karcie 24 GB dobrym pierwszym testem jest model 7–8B skwantyzowany metodą AWQ:

vllm serve Qwen/Qwen2.5-7B-Instruct-AWQ \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90 \
  --api-key localtoken

Flagi, których faktycznie będziesz dotykać:

--max-model-len — maksymalny kontekst na żądanie. Krótszy = więcej równoczesnych sekwencji zmieści się w stronicowanym cache'u KV. Nie ustawiaj domyślnie 128K „na wszelki wypadek”.
--gpu-memory-utilization — ułamek VRAM, który vLLM rezerwuje z góry (domyślnie 0,9). Zmniejsz go, jeśli ten sam GPU obsługuje też Twój monitor.
--api-key — w przeciwieństwie do Ollama vLLM ma wbudowane uwierzytelnianie. Korzystaj z niego.
--tensor-parallel-size 2 — podział na 2 GPU, gdy model nie mieści się na jednym (poradnik o wielu GPU).

Krok 3 — Skieruj klientów OpenAI na swój endpoint

Endpoint jest w pełni zgodny z OpenAI — istniejący kod SDK wymaga jedynie zmiany adresu bazowego:

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="localtoken")

resp = client.chat.completions.create(
    model="Qwen/Qwen2.5-7B-Instruct-AWQ",
    messages=[{"role": "user", "content": "Summarize PagedAttention in one sentence."}],
)
print(resp.choices[0].message.content)

Ustrukturyzowane wyjście (response_format ze schematem JSON) i wywoływanie narzędzi też tu działają — schematy z naszego poradnika o ustrukturyzowanym wyjściu przenoszą się bez zmian.

Którą kwantyzację wybrać: AWQ, GPTQ czy FP8

vLLM słabo radzi sobie z GGUF — jego świat kwantyzacji wygląda inaczej:

Format	Jakość	Prędkość w vLLM	Kiedy stosować
Brak (BF16)	Odniesienie	Szybko, najwięcej VRAM	Gdy VRAM masz pod dostatkiem
FP8	~99% BF16	Najszybciej na Ada/Hopper (RTX 40xx+)	Nowoczesny GPU, najlepszy domyślny wybór
AWQ (4-bitowa)	~97–98%	Szybko	Gdy chcesz zmieścić w VRAM dwa razy większy model
GPTQ (4-bitowa)	~96–98%	Szybko	Najszerszy wybór gotowych, skwantyzowanych repozytoriów

Zasada praktyczna: poszukaj na Hugging Face swojego modelu z dopiskiem „AWQ” albo „FP8” i serwuj gotowe, skwantyzowane repozytorium; kwantyzuj samodzielnie tylko wtedy, gdy nikt tego nie zrobił. Model 7B w AWQ potrzebuje ~6 GB na wagi, zostawiając resztę karty 24 GB na strony cache'u KV — czyli na równoczesność.

Lista kontrolna na produkcję

Uruchom to jako usługę — jednostka systemd albo oficjalny obraz Dockera (vllm/vllm-openai), z restartem po awarii.
Obserwuj właściwą metrykę: vLLM wystawia metryki Prometheusa pod /metrics — śledź głębokość kolejki (num_requests_waiting) i wykorzystanie cache'u KV; to one, a nie tokeny na sekundę, mówią Ci, kiedy skalować.
Jeden model na proces. vLLM serwuje pojedynczy model; do dwóch modeli uruchom dwie instancje (różne porty/GPU), w razie potrzeby z routerem z przodu.
Testuj obciążenie realnymi długościami promptów — przepustowość przy promptach 100-tokenowych nic nie mówi o Twoim ruchu RAG z promptami 4K.
Dostęp zdalny: ta sama zasada, co przy każdym lokalnym endpoincie — nigdy nie wystawiaj go bez zabezpieczeń; umieść go w sieci typu tailnet (poradnik o domowym serwerze) albo za reverse proxy z TLS.

Najczęściej zadawane pytania

Czy vLLM jest szybszy od Ollama?

Dla jednego użytkownika: nie — opóźnienie pojedynczego strumienia jest podobne, a Ollama jest dużo prostsza. Przy równoczesnym obciążeniu: dramatycznie tak, 5–20× wyższa przepustowość zagregowana, bo ciągłe batchowanie utrzymuje GPU w nasyceniu, podczas gdy Ollama przetwarza płytką kolejkę.

Czy vLLM potrafi uruchamiać modele GGUF?

Obsługa GGUF istnieje, ale jest eksperymentalna i wolna — omija zoptymalizowane ścieżki vLLM. Serwuj oryginalne wagi HF albo ich kwantyzację AWQ/GPTQ/FP8. GGUF zostaw dla świata llama.cpp i Ollama.

Czy vLLM działa na Macu?

Nie w sensowny sposób — vLLM celuje w serwowanie w stylu centrum danych na CUDA (i ROCm). Na Apple Silicon właściwym narzędziem są serwery oparte na llama.cpp; Mac obsługujący jedno gospodarstwo domowe i tak nie potrzebuje ciągłego batchowania.

Ile VRAM potrzebuję, żeby obsłużyć N użytkowników?

Wagi raz plus cache KV na każdą aktywną sekwencję. Model 8B w AWQ (~6 GB) na karcie 24 GB zostawia ~15 GB puli stron — czyli mniej więcej 40–80 aktywnych sekwencji z kontekstem 2K. Dłuższe konteksty szybko to zmniejszają i dlatego ograniczenie --max-model-len jest pierwszą dźwignią strojenia.

Powiązane poradniki

← Wszystkie przewodniki | Sprawdź zgodność GPU