Jak Ollama obsługuje równoległe żądania

Ten przewodnik wyjaśnia sposób, w jaki Ollama obsługuje równoległe żądania (koncelewność, kolejkowanie i ograniczenia zasobów) oraz jak dostosować jego działanie za pomocą zmiennej środowiskowej OLLAMA_NUM_PARALLEL (oraz powiązanych parametrów).

Więcej informacji na temat przepustowości, opóźnień, VRAM oraz benchmarków dla różnych środowisk uruchomieniowych i sprzętu można znaleźć tutaj: Wydajność LLM: Benchmarki, wąskie gardła i optymalizacja.

Agenci wieloetapowi wielokrotnie zwiększają liczbę ponowień przy niestabilnym próbkowaniu; domyślne wartości temperatury, top_p oraz kar dla modeli z klasy Qwen i Gemma zostały opisane tutaj: Parametry inferencji agentycznej dla Qwen i Gemma.

Obsługa równoległych żądań

• Przetwarzanie równoległe: Ollama obsługuje równoległe przetwarzanie żądań. Jeśli system ma wystarczająco dużo dostępnej pamięci (RAM dla inferencji na CPU, VRAM dla inferencji na GPU), można jednocześnie załadować wiele modeli, a każdy załadowany model może obsługiwać kilka żądań równolegle. Jest to kontrolowane przez zmienną środowiskową OLLAMA_NUM_PARALLEL, która ustawia maksymalną liczbę równoległych żądań, które dany model może przetwarzać jednocześnie. Domyślnie wartość ta wynosi 4 (lub 1, w zależności od dostępności pamięci), ale można ją dostosować.

• Bathczing (grupowanie): Gdy na ten sam model jednocześnie przyjdzie kilka żądań, Ollama grupuje je w jedną partię (batch) i przetwarza je razem. Oznacza to, że oba żądania są obsługiwane równolegle, a użytkownicy zobaczą odpowiedzi strumieniowane jednocześnie. Serwer celowo nie czeka na zapełnienie partii; przetwarzanie rozpoczyna się tak szybko, jak tylko żądania są dostępne.

Kolejkowanie i ograniczenia

• Kolejkowanie: Jeśli liczba równoległych żądań przekroczy skonfigurowaną koncelewność (np. więcej niż OLLAMA_NUM_PARALLEL żądań dla danego modelu), dodatkowe żądania trafiają do kolejki. Kolejka działa w sposób FIFO (pierwszy wchodzi, pierwszy wychodzi).

• Ograniczenia kolejki: Maksymalna liczba żądań w kolejce jest kontrolowana przez OLLAMA_MAX_QUEUE (domyślnie: 512). Jeśli kolejka jest pełna, nowe żądania otrzymują błąd 503, wskazujący na przeciążenie serwera.

• Ładowanie modeli: Liczba różnych modeli, które mogą być jednocześnie załadowane, jest kontrolowana przez OLLAMA_MAX_LOADED_MODELS. Jeśli żądanie wymaga załadowania nowego modelu, a pamięci jest za mało, Ollama wyładuje bezczynne modele, aby zrobić miejsce, a żądanie trafi do kolejki, aż model zostanie załadowany.

Przykładowa scenariusz

Jeśli dwa żądania dla tego samego modelu nadejdą w tym samym czasie, a koncelewność serwera jest ustawiona na co najmniej 2, oba żądania zostaną przetworzone razem w jednej partii, a obaj użytkownicy otrzymają odpowiedzi równolegle. Jeśli koncelewność jest ustawiona na 1, jedno żądanie zostanie przetworzone natychmiast, a drugie czeka w kolejce, aż pierwsze się zakończy.

Jeśli żądania dotyczą różnych modeli, a pamięci jest wystarczająco dużo, oba modele mogą zostać załadowane, a żądania obsłużone równolegle. Jeśli nie, może być konieczne wyładowanie jednego z modeli, a żądanie trafi do kolejki.

Tabela podsumowująca

Podsumowując, Ollama jest zaprojektowany tak, aby wydajnie obsługiwać wiele jednoczesnych żądań, pod warunkiem że serwer jest skonfigurowany pod kątem koncelewności i dysponuje wystarczającymi zasobami. W przeciwnym razie żądania są kolejkowane i przetwarzane kolejno.

Jeśli zwiększenie wartości OLLAMA_NUM_PARALLEL przestaje utrzymywać stabilne opóźnienia, a kolejka nieustannie rośnie pod wpływem rzeczywistego ruchu, jest to jeden z wyraźniejszych sygnałów, który warto rozważyć w kontekście przejścia na silnik serwowania zaprojektowany do tego celu. Ollama do vLLM: Kiedy migrować lokalny serwer LLM omawia tę decyzję, w tym ciągłe grupowanie (continuous batching) i PagedAttention jako mechanizmy stosowane przez vLLM, aby równoległe żądania nie obniżają wzajemnie swojej wydajności.

Obsługa niedoboru pamięci

Gdy Ollama natrafi na niewystarczającą ilość pamięci do obsługi nadchodzących żądań, stosuje kombinację mechanizmów kolejkowania i strategii zarządzania zasobami, aby utrzymać stabilność:

Kolejkowanie żądań

• Nowe żądania trafiają do kolejki FIFO (First-In, First-Out), gdy pamięć nie może zostać natychmiast przydzielona.
• Rozmiar kolejki jest kontrolowany przez OLLAMA_MAX_QUEUE (domyślnie: 512 żądań).
• Jeśli kolejka osiągnie maksymalną pojemność, nowe żądania otrzymują błąd 503 “Server Overloaded” (Serwer przeciążony).

Zarządzanie modelami

• Aktywne modele mogą zostać wyładowane z pamięci, gdy staną się bezczynne, aby zwolnić zasoby dla żądań w kolejce.
• Liczba równolegle załadowanych modeli jest ograniczona przez OLLAMA_MAX_LOADED_MODELS (domyślnie: 3× liczba GPU lub 3 dla CPU).

Optymalizacja pamięci

• Próby grupowania żądań (batching) dla tego samego modelu, aby zmaksymalizować efektywność pamięci.
• W przypadku inferencji na GPU wymagana jest pełna alokacja VRAM na model – częściowe ładowanie nie jest wspierane.

Scenariusze awaryjne

Krytyczne wyczerpanie pamięci: Gdy nawet żądania z kolejki przekraczają dostępne zasoby, Ollama może:

• Wykorzystywać pamięć wirtualną na dysku (co drastycznie obniża wydajność)
• Zwracać błędy “out of memory” (brak pamięci)
• W skrajnych przypadkach crashować instancję modelu

Administratorzy powinni monitorować zużycie pamięci i dostosowywać te parametry w oparciu o możliwości sprzętowe. Obsługa niedoboru pamięci staje się kluczowa przy uruchamianiu większych modeli (7B+ parametrów) lub przetwarzaniu wielu równoległych żądań.

Strategie optymalizacji Ollama

Włącz przyspieszenie GPU za pomocą export OLLAMA_CUDA=1 i ustaw liczbę wątków CPU przez export OLLAMA_NUM_THREADS=84. Ulepszenia sprzętowe

• RAM: 32GB+ dla modeli 13B, 64GB+ dla modeli 70B
• Pamięć masowa: Dyski NVMe SSD dla szybszego ładowania/swapowania modeli
• GPU: NVIDIA RTX 3080/4090 z 16GB+ VRAM dla większych modeli

Strategie operacyjne

• Grupowanie żądań (Batching): Przetwarzanie wielu zapytań jednocześnie, aby zmniejszyć narastające koszty pamięci
• Automatyczne wyładowywanie modeli: Pozwala Ollamie usuwać bezczynne modele z pamięci
• Cache’owanie często używanych modeli: Utrzymywanie popularnych modeli w pamięci

Monitorowanie i rozwiązywanie problemów

• Używaj nvidia-smi (dla GPU) i htop (dla CPU/RAM), aby zidentyfikować wąskie gardła
• W przypadku błędów pamięci:
• Przejdź na modele z kwantyzacją
• Zmniejsz liczbę równoległych żądań
• Zwiększ przestrzeń zamiany (swap)

Przykładowy przepływ optymalizacji:

### Użyj modelu z kwantyzacją z przyspieszeniem GPU
export OLLAMA_CUDA=1
ollama run llama2:7b-q4_0 --context-size 2048

### Ogranicz liczbę załadowanych modeli i równoległych żądań
export OLLAMA_MAX_LOADED_MODELS=2
export OLLAMA_NUM_PARALLEL=4

Te zmiany mogą zmniejszyć zużycie pamięci o 30-60%, zachowując jakość odpowiedzi, co jest szczególnie korzystne przy uruchamianiu wielu modeli lub przy dużej liczbie żądań.

Zmienna środowiskowa OLLAMA_NUM_PARALLEL

OLLAMA_NUM_PARALLEL kontroluje, ile żądań Ollama wykona równolegle. Jeśli wyślesz kilka żądań do tego samego serwera Ollama, to ustawienie w dużej mierze decyduje, czy będą one wykonywane równolegle, czy trafią do kolejki.

• Wyższe wartości mogą zwiększyć przepustowość pod warunkiem, że masz wystarczająco dużo zasobów CPU/GPU/VRAM, ale mogą zwiększyć opóźnienia i obciążenie pamięci.
• Niższe wartości zmniejszają konflikty o zasoby i mogą poprawić stabilność, ale żądania częściej będą trafiać do kolejki.

Pamięć, a konkretnie jej zużycie, skaluje się z wyrażeniem OLLAMA_NUM_PARALLEL * OLLAMA_CONTEXT_LENGTH: cztery równoległe sloty przy ustawieniu kontekstu 32K rezerwują pamięć cache KV tak, jakby został załadowany pojedynczy ciąg o długości 128K, nawet zanim jakiekolwiek żądanie z niego skorzysta. Na karcie z 16 GB VRAM te obliczenia budżetu często mają większe znaczenie niż samo kolejkowanie – zobacz Cache KV na GPU 16 GB po pełny budżet VRAM i dlaczego OLLAMA_NUM_PARALLEL=1 to zazwyczaj właściwy punkt wyjścia dla pojedynczej sesji z długim kontekstem.

Jak ustawić OLLAMA_NUM_PARALLEL

Linux / macOS (usługa systemd lub powłoka):

export OLLAMA_NUM_PARALLEL=2
ollama serve

Jednorazowe uruchomienie (prefiks tylko dla tego polecenia):

OLLAMA_NUM_PARALLEL=2 ollama serve

Docker (przykład):

docker run --rm -e OLLAMA_NUM_PARALLEL=2 -p 11434:11434 ollama/ollama

Jak dobrać wartość

Zacznij od 1–2 dla pojedynczego GPU / ograniczonego VRAM, a następnie stopniowo zwiększaj wartość, obserwując:

• Zużycie VRAM GPU (błędy OOM / wymuszanie wyrzucenia modelu)
• Zużycie CPU i średnie obciążenie (load average)
• p95 opóźnień dla typowych żądań
• Stopień błędów / przekroczeń limitów czasu (timeouts)

Jeśli optymalizujesz konkretną stronę pod kątem używania CLI, zobacz sekcję Ollama CLI w ściągawce oraz przykłady poleceń dla ollama serve, ollama ps i ollama run.

Szybkie receptury tuningowe

Priorytet stabilności

• OLLAMA_NUM_PARALLEL=1
• Używaj mniejszych / modeli z kwantyzacją
• Wolnij krótsze rozmiary kontekstu

Priorytet przepustowości

• OLLAMA_NUM_PARALLEL=2 (lub więcej, jeśli masz zapas mocy)
• Rozważ grupowanie żądań na warstwie klienta
• Upewnij się, że masz wystarczająco dużo VRAM i wątków CPU

„Wyrzucam z VRAM, gdy nadejdą dwa żądania"

• Zmniejsz OLLAMA_NUM_PARALLEL
• Użyj modelu o agresywniejszej kwantyzacji
• Zmniejsz długość kontekstu / maksymalną liczbę tokenów

Rozwiązywanie problemów

Objawy, że OLLAMA_NUM_PARALLEL jest zbyt wysokie

• Żądania zawieszają się nieregularnie pod obciążeniem
• Częste występowanie błędów OOM na GPU / wymuszane wyładowywanie modeli
• Nagłe skoki opóźnień przy nadejściu drugiego żądania

Objawy, że OLLAMA_NUM_PARALLEL jest zbyt niskie

• CPU/GPU jest niewykorzystany
• Opóźnienia z kolejkowania dominują nad całkowitym czasem odpowiedzi

Wskazówka: Jeśli również kontrolujesz swojego klienta, dodaj ponowienia z jitterem (losowym opóźnieniem) i utrzymuj połączenia keep-alive. Wiele problemów typu „Ollama jest wolne" to tak naprawdę kolejkowanie + narastające koszty utrzymania połączeń.

Ollama: Grupowanie żądań (Batching) kontra Równoległe Wykonywanie

Grupowanie (Batching) w Ollama odnosi się do praktyki grupowania wielu nadchodzących żądań i przetwarzania ich jako jednej jednostki. Pozwala to na bardziej efektywne wykorzystanie zasobów obliczeniowych, szczególnie na sprzęcie, który korzysta z operacji równoległych (takim jak GPU).

Gdy wiele żądań dla tego samego modelu nadejdzie jednocześnie, Ollama może przetwarzać je razem w jednej partii, o ile pamięci wystarcza. Zwiększa to przepustowość i może zmniejszyć opóźnienie dla każdego żądania, ponieważ model może wykorzystać zoptymalizowane operacje macierzowe dla całej partii.

Grupowanie jest szczególnie skuteczne, gdy żądania są podobne rozmiarem i złożonością, ponieważ pozwala to na lepsze wykorzystanie sprzętu.

Równoległe wykonywanie w Ollama oznacza obsługę wielu żądań jednocześnie, czy to dla tego samego modelu, czy dla różnych modeli, w zależności od dostępnej pamięci i konfiguracji.

Ollama obsługuje dwa poziomy koncelewności:

• Wielo-modelowe ładowanie: Jeśli jest wystarczająco dużo pamięci, można załadować kilka modeli i obsługiwać żądania jednocześnie.
• Równoległe żądania na model: Każdy załadowany model może przetwarzać kilka żądań równolegle, co jest kontrolowane ustawieniem OLLAMA_NUM_PARALLEL (domyślnie 1 lub 4, w zależności od pamięci).

Gdy liczba żądań przekracza limit koncelewności, trafiają one do kolejki (FIFO) do limitu OLLAMA_MAX_QUEUE.

Podsumowanie

Ollama wykorzystuje zarówno grupowanie (batching), jak i równoległe wykonywanie, aby wydajnie przetwarzać wiele żądań. Grupowanie łączy żądania do jednoczesnego przetwarzania, podczas gdy równoległe wykonywanie pozwala na równoczesne działanie wielu żądań (lub modeli). Obydwa metody zależą od pamięci systemowej i są konfigurowalne dla uzyskania optymalnej wydajności.

Po więcej benchmarków, regulacji koncelewności i wskazówek wydajnościowych sprawdź nasz Wydajność LLM: Benchmarki, wąskie gardła i optymalizacja.

Przydatne linki

• Ściągawka poleceń Ollama
• Porównanie wydajności LLM - Ollama na GPU 16GB VRAM
• Przenoszenie modeli Ollama na inny dysk lub folder
• Jak Ollama wykorzystuje rdzenie wydajnościowe i efektywne Intel CPU
• Ollama do vLLM: Kiedy migrować lokalny serwer LLM