Ollama czy vLLM: co wybrać do serwowania modeli LLM?

Ollama a vLLM w jednym akapicie

Ollama to menedżer modeli z wbudowanym serwerem: pobiera skwantyzowane wagi, ładuje je i odpowiada na 127.0.0.1:11434, korzystając z CPU, jeśli serwer nie posiada innego zasobu. vLLM to silnik wysokiej przepustowości: utrzymuje GPU w stanie pełnego obciążenia przy wielu jednoczesnych żądaniach i jest niewłaściwym narzędziem na maszynie bez akceleratora graficznego. Na tym polega główna różnica. Ollama jest przeznaczona dla pojedynczego użytkownika korzystającego z lokalnego asystenta. vLLM jest przeznaczony dla aplikacji obsługującej cały zespół.

Oba rozwiązania udostępniają API HTTP zgodne z OpenAI, więc kod klienta można łatwo przełączać między nimi poprzez zmianę base URL. API nie stanowi różnicy. Różnica polega na sposobie obsługi sytuacji, w której drugie żądanie dociera w momencie, gdy pierwsze wciąż generuje tokeny.

Czym w rzeczywistości jest Ollama

Ollama stanowi warstwę ułatwiającą obsługę modeli. Jedno polecenie instalacji dostarcza rejestr modeli (ollama pull llama3.1:8b), lokalny magazyn wag, interfejs czatu, usługę systemd oraz API HTTP. Większość obsługiwanych modeli to pliki GGUF, zazwyczaj kwantyzowane do 4 bitów. Dzięki temu model 7B lub 8B zajmuje na dysku około 5 GB zamiast 16 GB. Kwantyzacja redukuje ilość pamięci wymaganej do wnioskowania na procesorze (CPU). Na komputerach Apple Silicon Mac narzędzie może również uruchamiać modele oparte na formacie safetensors za pośrednictwem silnika MLX, a od wersji v0.40.0 (wrzesień 2026) wspierane architektury są tam uruchamiane na MLX automatycznie.

Silnik uruchomieniowy GGUF bazuje na llama.cpp, bibliotece wnioskowania w języku C++, która umożliwiła praktyczne wykorzystanie kwantyzacji GGUF na standardowym sprzęcie. Według stanu na październik 2026 Ollama wspiera dwa silniki: llama.cpp oraz MLX, a kompilacje na system Linux obsługują również wnioskowanie MLX z wykorzystaniem CUDA. Przewodnik programisty umożliwia włączenie tego backendu za pomocą cmake -B build . -DOLLAMA_MLX_BACKENDS=cuda_v13, przy założeniu spełnienia wymagań wstępnych w postaci CUDA 13+ oraz cuDNN 9+. Zatem porównywanie Ollama z llama.cpp w rzeczywistości sprowadza się do zestawienia warstwy ergonomicznej z narzędziem, które ona opakowuje.

Projekt zakłada obsługę jednego użytkownika. Według stanu na październik 2026 domyślna wartość dla OLLAMA_NUM_PARALLEL wynosi 1. Oznacza to, że jeden model przetwarza jedno żądanie w danym czasie, a pozostałe oczekują w kolejce, która domyślnie mieści 512 wpisów (OLLAMA_MAX_QUEUE). Ustawienie równoległości można zwiększyć, a poniższa sekcja wyjaśnia związane z tym koszty. Jeśli Ollama nie była wcześniej uruchamiana, należy zacząć od hostowania Ollama na VPS z zamkniętym portem 11434, ponieważ lokalne API nie wymaga uwierzytelniania.

Czym w rzeczywistości jest vLLM

vLLM to wyłącznie serwer wnioskowania. Nie zarządza biblioteką modeli, udostępnia jedynie vllm chat klienta dla uruchomionego serwera i nie pobiera modelu na żądanie. W momencie uruchomienia wskazuje się repozytorium Hugging Face, z którego ładowany jest jeden konkretny model, obsługiwany aż do zatrzymania procesu.

Zaletą tego wąskiego zakresu działania jest przepustowość. Za wydajność odpowiadają dwa mechanizmy. PagedAttention przechowuje pamięć podręczną KV (pamięć podręczną klucz-wartość, czyli stan uwagi dla każdego tokena utrzymywany przez model dla każdego aktywnego żądania) w blokach o stałym rozmiarze, podobnie jak system operacyjny stronicuje pamięć. Żądanie nie wymaga już rezerwacji dużego, ciągłego obszaru pamięci obliczonego dla najgorszego scenariusza, dzięki czemu pamięć, która wcześniej pozostawała zarezerwowana i niewykorzystana, staje się dostępna dla większej liczby jednoczesnych żądań. Continuous batching pozwala nowemu żądaniu dołączyć do przetwarzanej partii w kolejnym kroku dekodowania, zamiast czekać na zakończenie całej bieżącej partii. Zakończona sekwencja natychmiast opuszcza partię, a zwolnione miejsce jest uzupełniane.

Praktyczny rezultat: na pojedynczym GPU przejście od jednego do trzydziestu jednoczesnych użytkowników znacząco zwiększa całkowitą liczbę tokenów na sekundę, podczas gdy prędkość dla pojedynczego użytkownika spada znacznie mniej, niż można by oczekiwać. W domyślnej konfiguracji Ollama, przejście od jednego do trzydziestu użytkowników powoduje jedynie, że dwudziestu dziewięciu z nich musi czekać.

Continuous batching stanowi kluczową różnicę

Wyobraźmy sobie pięć żądań trafiających do serwera w tym samym momencie na identycznym sprzęcie.

Ollama przy ustawieniach domyślnych przetwarza pierwsze żądanie do końca, następnie drugie i tak dalej. Piąty użytkownik czeka na cztery pełne cykle generowania. Całkowita przepustowość jest w przybliżeniu równa prędkości pojedynczej generacji, ponieważ procesor pracuje w danej chwili tylko nad jedną sekwencją.

vLLM dekoduje wszystkie pięć żądań w tym samym przebiegu (forward pass). Wygenerowanie jednego tokena dla pięciu sekwencji kosztuje niewiele więcej niż dla jednej, ponieważ najbardziej kosztownym elementem jest odczyt wag modelu z pamięci, a ten odczyt jest współdzielony przez całą partię (batch). Jest to ten sam mechanizm ograniczenia przepustowości pamięci, który spowalnia wnioskowanie na CPU: płaci się za przenoszenie wag, a nie za operacje arytmetyczne.

Można ustawić OLLAMA_NUM_PARALLEL=4, aby uzyskać część tych korzyści. Kosztem jest pamięć. Każdy równoległy slot wymaga własnej pamięci podręcznej KV, a Ollama mnoży alokację kontekstu zamiast ją dzielić: FAQ podaje, że wymagana pamięć RAM skaluje się przez OLLAMA_NUM_PARALLEL razy OLLAMA_CONTEXT_LENGTH. Zatem cztery równoległe żądania do modelu skonfigurowanego na 8192 tokeny utrzymują po 8192 tokeny każde, ale serwer musi pomieścić w sumie pamięć podręczną dla 32768 tokenów. Wartość 8192 jest wyborem, a nie narzuconą stałą, więc zwiększenie num_ctx i oszacowanie kosztu RAM jest krokiem decydującym o tym, czy cztery sloty w ogóle się zmieszczą. Stronicowana pamięć podręczna (paged cache) w vLLM pozwala uniknąć rezerwowania pełnego okna dla każdego slotu z góry, ponieważ bloki są przydzielane żądaniu w miarę jego rzeczywistego wzrostu. Tak czy inaczej, górny limit liczby osób, które serwer może obsłużyć jednocześnie, zależy od rozmiaru pamięci podręcznej KV, kosztu fazy prefill oraz głębokości kolejki, co wyjaśnia, dlaczego serwer działający poprawnie dla jednej osoby zwalnia przy pięciu.

Instalacja i udostępnianie za pomocą Ollama

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

Skrypt instalacyjny tworzy użytkownika systemowego ollama, instaluje plik binarny i rejestruje ollama.service powiązany z 127.0.0.1:11434. Wartość eval rate wyświetlana przez --verbose to rzeczywista liczba tokenów na sekundę dla danej maszyny. Należy ufać tej wartości bardziej niż jakimkolwiek publikowanym danym. Pojedynczy odczyt z jednego zapytania jest punktem wyjścia, a nie miarą wydajności, dlatego pomiar tokenów na sekundę przy zmiennym obciążeniu pozwala ocenić, czy serwer utrzyma zakładane obciążenie i czy wynajęcie GPU jest bardziej opłacalne niż płacenie za każdy token.

Aby zwiększyć współbieżność, należy użyć pliku typu drop-in dla systemd, co zapobiegnie nadpisaniu zmian podczas aktualizacji:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

ollama ps pokazuje, co zostało załadowane, a kolumna PROCESSOR przedstawia stan faktyczny. 100% CPU oznacza, że GPU nie jest wykorzystywane, co stanowi rzeczywistą przyczynę większości zgłoszeń o niskiej wydajności Ollama. Linia OLLAMA_KEEP_ALIVE=30m w pliku drop-in jest równie istotna przy małym obciążeniu, ponieważ domyślna konfiguracja usuwa model z pamięci po pięciu minutach bezczynności, a utrzymywanie modelu w pamięci między zapytaniami zapobiega ponownemu ładowaniu modelu przy pierwszym zapytaniu po przerwie trwającej do pół godziny. Jeśli okresy bezczynności są dłuższe, należy ustawić wyższą wartość.

Instalacja i uruchomienie vLLM

Wersje vLLM z obsługą GPU wymagają systemu Linux (macOS na układach Apple Silicon posiada wsparcie wyłącznie dla CPU poprzez gotowy pakiet wheel w wydaniu 0.32.0, natomiast akceleracja GPU na tych komputerach realizowana jest przez vLLM-Metal, oddzielną wtyczkę utrzymywaną przez społeczność, opartą na MLX). W przypadku języka Python, bieżące wydanie (0.32.0, październik 2026) obsługuje wersje od 3.11 do 3.14, co jest zgodne z oficjalnym przewodnikiem instalacji. Wersja Python 3.10 została wycofana w wydaniu 0.32.0, dlatego użycie wersji 3.12, przedstawione poniżej, jest bezpiecznym wyborem. Instalację należy przeprowadzić w odizolowanym środowisku wirtualnym, ponieważ proces ten pobiera specyficzną kompilację PyTorch:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto
vllm download-kernels

Ostatnia linia pochodzi z oficjalnego przewodnika instalacji vLLM dla NVIDIA, aktualnego na październik 2026 roku. Instaluje ona wstępnie skompilowane kernele FlashInfer. Bez nich vLLM pobiera i kompiluje kernele przy każdym uruchomieniu, co według dokumentacji może wydłużyć proces o kilka minut w przypadku układów Hopper i nowszych. Polecenie należy uruchamiać ponownie po każdej aktualizacji vLLM, ponieważ FlashInfer nie zaimportuje się, jeśli wersje kerneli nie będą zgodne.

Następnie należy uruchomić model. Nazwa musi być identyfikatorem repozytorium Hugging Face, a nie krótkim tagiem:

vllm serve Qwen/Qwen2.5-1.5B-Instruct

Pierwsze uruchomienie trwa długo, ponieważ system pobiera wagi, a następnie profiluje GPU w celu ustalenia liczby bloków pamięci podręcznej KV, które zmieszczą się w pamięci. Usługa nasłuchuje na porcie 8000. Należy zweryfikować jej działanie przed napisaniem jakiegokolwiek kodu klienckiego:

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

Jeśli na serwerze zainstalowany jest Docker, oficjalny obraz pozwala uniknąć problemów z zależnościami CUDA:

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

Flaga --ipc=host zapewnia kontenerowi dostęp do współdzielonej pamięci hosta; zwiększenie --shm-size stanowi alternatywne rozwiązanie. PyTorch przesyła tensory między procesami za pomocą współdzielonej pamięci, co jest szczególnie istotne przy wnioskowaniu z wykorzystaniem paralelizmu tensorowego.

Najważniejsze flagi w środowisku produkcyjnym to --max-model-len (okno kontekstowe, które zamierzasz wykorzystać), --gpu-memory-utilization (ułamek pamięci karty, który vLLM może zarezerwować, domyślnie 0.92 według stanu na październik 2026), --tensor-parallel-size do podziału jednego modelu na kilka jednostek GPU oraz --api-key.

Uwierzytelnianie jest dostępne jako flaga w vLLM i nieobecne w lokalnym API Ollama

vLLM wymusza użycie tokena typu bearer, jeśli zostanie on zdefiniowany:

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

Tę samą wartość można przekazać za pomocą zmiennej środowiskowej VLLM_API_KEY. Żądanie skierowane do tras /v1 bez podania tokena kończy się błędem HTTP 401. Klucz nie zabezpiecza jednak całego serwera. Przewodnik bezpieczeństwa vLLM oraz kod źródłowy uwierzytelniania w wersji 0.32.0 wskazują, że zabezpieczenie dotyczy wyłącznie punktów końcowych z prefiksami ścieżek /v1, /v2, /inference oraz /cohere. Tekst pomocy --api-key na stronie vllm serve wymienia tylko trzy pierwsze, jednak kod weryfikuje wszystkie cztery. Zarówno przewodnik, jak i tekst pomocy informują, że pozostałe punkty końcowe, w szczególności /invocations, który udostępnia tę samą inferencję co /v1, nie wymagają uwierzytelnienia. Jest to wystarczający powód, aby nie wystawiać portu 8000 na publicznym interfejsie sieciowym. Przewodnik bezpieczeństwa vLLM zaleca również przeniesienie limitowania zapytań (rate limiting) na zewnętrzny reverse proxy. Token przesyłany przez zwykły protokół HTTP jest czytelny podczas transmisji, jednak sama flaga oznacza, że serwer rozpoznaje tożsamość wywołującego.

Lokalne API Ollama nie wymaga uwierzytelniania. Modele chmurowe, publikowanie modeli oraz pobieranie prywatnych modeli wymagają zalogowania; bezpośredni dostęp do API ollama.com wymaga klucza API. Każdy proces, który ma dostęp do portu 11434, może uruchamiać, pobierać lub usuwać modele. Należy ograniczyć dostęp do interfejsu loopback i łączyć się z nim przez własny serwer VPN WireGuard lub za pośrednictwem uwierzytelniającego reverse proxy z terminacją TLS (transport layer security).

Wymagania sprzętowe: co jest potrzebne dla każdego rozwiązania

Ollama działa na CPU. Skwantyzowany model 4-bitowy zajmuje około pół gigabajta pamięci RAM na miliard parametrów, plus około gigabajta narzutu środowiska uruchomieniowego oraz dodatkową pamięć na kontekst. Model 3B wymaga więc około 4 GB wolnej pamięci, a model 8B około 8 GB. Szybkość na współdzielonym vCPU wynosi od kilku do kilkunastu tokenów na sekundę. Wynika to z przepustowości pamięci, a nie z błędnej konfiguracji, więc żadna flaga tego nie naprawi. Aby sprawdzić te obliczenia w praktyce dla konkretnego wydania, zamiast polegać na szacunkach, uruchomienie Nemotron 3.5 Lightning na VPS pozwala precyzyjnie określić tag do pobrania, ilość zajmowanej pamięci RAM po załadowaniu oraz ocenić, czy wydajność samego CPU jest akceptowalna.

vLLM wymaga GPU. Domyślna ścieżka obsługuje nieskwantyzowane wagi w precyzji 16-bitowej, co oznacza około 2 GB na miliard parametrów: model 8B potrzebuje około 16 GB pamięci wideo tylko na same wagi, jeszcze przed alokacją pamięci podręcznej KV, która zapewnia współbieżność, dla której zainstalowano vLLM. Na karcie 24 GB pozostawia to miejsce na użyteczną pamięć podręczną. Na karcie 16 GB miejsca brakuje, więc należy wybrać mniejszy model, przekazać flagę --quantization (z kwantyzowanym punktem kontrolnym lub w celu kwantyzacji wag o pełnej precyzji podczas ładowania) albo przenieść część wag do systemowej pamięci RAM za pomocą --cpu-offload-gb. To rozwiązanie zachowuje precyzję, ale jest wolniejsze, ponieważ wagi muszą być przesyłane do GPU przy każdym przebiegu w przód. Istnieje backend CPU z własnymi oddzielnymi paczkami, ale jego użycie niweluje sens stosowania vLLM.

Kwestia sprzętowa zazwyczaj determinuje wybór oprogramowania. Brak GPU oznacza Ollama. Wynajęte GPU, które pracuje na 5 procent wykorzystania z powodu szeregowania żądań, oznacza vLLM.

Wybór rozwiązania dla danego obciążenia

• Jedna osoba, VPS z procesorem CPU, tworzenie szkiców i podsumowań: Ollama. Tempo pracy jest akceptowalne, a prostszego rozwiązania nie ma.
• Asystent programistyczny lub serwer MCP łączący narzędzia z lokalnym modelem, z którego korzystasz tylko Ty: Ollama. Obsługa jednego połączenia jednocześnie to rzeczywiste obciążenie.
• Porównywanie pięciu modeli w tym tygodniu: Ollama. Pobieranie i usuwanie otagowanych modeli to zadanie, w którym to narzędzie sprawdza się najlepiej, podczas gdy vLLM wymaga restartu procesu dla każdego modelu.
• Aplikacja wewnętrzna, produkt typu chat lub potok wyszukiwania z rzeczywistymi użytkownikami: vLLM. To przypadek, w którym przetwarzanie wsadowe uzasadnia koszty GPU.
• Zadanie wsadowe polegające na ocenie stu tysięcy dokumentów w ciągu nocy: vLLM z wysokim parametrem --max-num-seqs. Przepustowość jest jedyną istotną metryką, a opóźnienie dla pojedynczego dokumentu nie ma znaczenia.
• Platforma agentowa, w której kilka samodzielnie hostowanych agentów AI odpytuje model jednocześnie: vLLM, ponieważ ruch generowany przez agentów ma charakter skokowy i z natury jest równoległy.

Tryby awaryjne i odpowiadające im komunikaty

vLLM odmawia uruchomienia z błędem pamięci podręcznej KV. Komunikat zawiera obie wartości liczbowe:

ValueError: To serve at least one request with the model's max seq len (32768), (4.00 GiB KV cache is needed, which is larger than the available KV cache memory (1.00 GiB). Based on the available memory, the estimated maximum model length is 8192. Try increasing `gpu_memory_utilization` (which also controls CPU memory on the CPU backend) or decreasing `max_model_len` when initializing the engine. See https://docs.vllm.ai/en/latest/configuration/conserving_memory/ for more details.

Model deklaruje okno kontekstowe większe niż ilość pamięci pozostała po załadowaniu wag. Należy je zmniejszyć za pomocą --max-model-len 8192 lub zwiększyć --gpu-memory-utilization, jeśli karta nie jest obciążona innymi zadaniami.

Ollama wyświetla Killed w trakcie generowania. Mechanizm Linux out-of-memory killer przerwał proces, ponieważ model wymagał więcej pamięci RAM, niż jest dostępne w systemie. Należy to potwierdzić za pomocą sudo dmesg | grep -i oom. Rozwiązaniem jest wybór mniejszego lub mocniej skwantyzowanego modelu, a nie zmiana ustawień.

Ollama działa poprawnie przy pojedynczym zapytaniu, ale zwalnia pod obciążeniem. W logach nie pojawiają się żadne błędy. Czas odpowiedzi wydłuża się wraz ze wzrostem liczby użytkowników, ponieważ OLLAMA_NUM_PARALLEL=1 szereguje zapytania. Długie odpowiedzi pogarszają sytuację, gdyż jeden użytkownik zajmujący jedyny dostępny slot blokuje pozostałych do momentu zakończenia generowania. Zastosowanie ograniczenia odpowiedzi za pomocą num_predict pozwala narzucić limit czasu, przez jaki pojedyncze zapytanie może blokować serwer. Należy zwiększyć ustawienie równoległości, akceptując wyższe zużycie pamięci RAM przez kontekst każdego slotu, lub przenieść obciążenie do vLLM.

vLLM zwraca błąd 401 przy każdym wywołaniu /v1. Usługa została uruchomiona z flagą --api-key, a klient nie przesyła nagłówka Authorization. Większość bibliotek klienckich OpenAI przesyła dowolną wartość przekazaną jako klucz, dlatego należy skonfigurować go po stronie klienta zamiast usuwać flagę.

vLLM zgłasza, że model nie został znaleziony. Ollama pobiera modele na żądanie, vLLM tego nie robi. Pole model w treści żądania musi być zgodne z identyfikatorem repozytorium, z którym uruchomiono usługę, lub z wartością --served-model-name, jeśli została zdefiniowana. Dokładny ciąg znaków można zweryfikować za pomocą curl http://localhost:8000/v1/models.

Uruchomienie obu rozwiązań jest uzasadnionym podejściem

Nie wykluczają się one wzajemnie. Typowa konfiguracja obejmuje vLLM na instancji z GPU obsługującej aplikację oraz Ollama na standardowym VPS obok, wykorzystywanym do lokalnych skryptów, zadań cron oraz testowania nowych wydań modeli. Oba punkty końcowe są zgodne z API OpenAI, więc jedna biblioteka kliencka i zmiana base-URL pozwalają na obsługę obu. Kontrola kosztów jest tutaj ważniejsza niż wybór silnika, ponieważ bezczynne GPU generuje takie same opłaty jak obciążone, a utrzymanie przewidywalnych kosztów agentów i wnioskowania to odrębne zagadnienie od wyboru serwera.

FAQ

Czy vLLM jest szybszy niż Ollama?

W przypadku pojedynczego żądania na tym samym GPU różnica jest niewielka, ponieważ oba rozwiązania wykonują te same operacje arytmetyczne. Przy wielu jednoczesnych żądaniach vLLM znacznie wyprzedza konkurencję, ponieważ mechanizm continuous batching dekoduje każdą aktywną sekwencję w jednym przebiegu forward pass, podczas gdy domyślna konfiguracja Ollama przetwarza je jedna po drugiej. Na maszynach wyposażonych wyłącznie w CPU oba rozwiązania posiadają wspierane ścieżki inferencji, przy czym vLLM korzysta z oddzielnych pakietów (wheels) dla CPU.

Czy vLLM może działać bez GPU?

Tak, poprzez backend CPU. Standardowe pakiety są przeznaczone dla GPU NVIDIA lub AMD, a główny powód istnienia vLLM – utrzymywanie akceleratora w stanie pełnego obciążenia dzięki batchowaniu żądań – traci znaczenie w przypadku CPU. Backend CPU istnieje i posiada oddzielne pakiety dla architektur x86 oraz Arm. Do rzeczywistej inferencji na CPU należy używać bezpośrednio Ollama lub llama.cpp.

Jaka jest różnica między Ollama a llama.cpp?

llama.cpp to biblioteka inferencyjna, a GGUF to jej format kwantyzowanych wag. Ollama wykorzystuje ją do inferencji GGUF i dodaje rejestr modeli, pobieranie z tagami, zarządzanie modelami oraz jednostkę systemd. Ollama dostarcza również silnik MLX, który uruchamia modele oparte na safetensors na układach Apple Silicon, oraz wspiera kompilacje CUDA na systemach Linux, więc oba rozwiązania nie zawsze są identyczne pod spodem.

Ile pamięci GPU potrzebuje vLLM dla modelu 8B?

Przy precyzji 16-bit same wagi zajmują około 16 GB, co daje w przybliżeniu 2 GB na miliard parametrów, a pamięć podręczna KV wymaga dodatkowej przestrzeni. Karta 24 GB zapewnia komfort pracy. Karta 16 GB wymaga modelu kwantyzowanego, mniejszego modelu lub użycia --cpu-offload-gb, aby przenieść część wag do pamięci RAM systemu, co wiąże się ze spadkiem prędkości. vLLM rezerwuje część pamięci karty określoną przez --gpu-memory-utilization, która na październik 2026 roku domyślnie wynosi 0.92.

Czy muszę zmieniać kod aplikacji, aby przełączać się między nimi?

Zazwyczaj wystarczy zmiana adresu bazowego URL, klucza API oraz nazwy modelu. Ollama udostępnia interfejs zgodny z OpenAI pod adresem http://127.0.0.1:11434/v1 i ignoruje klucz, podczas gdy vLLM udostępnia http://localhost:8000/v1 i wymusza użycie klucza na trasach /v1, jeśli został on ustawiony. Nazwy modeli różnią się formatem: llama3.1:8b dla Ollama, pełny identyfikator repozytorium, taki jak Qwen/Qwen2.5-1.5B-Instruct, dla vLLM.