Jak naprawić błąd Ollama 500 „unable to load model”

Co naprawdę oznacza błąd 500 „unable to load model” w Ollamie

Błąd Ollama Error: 500 Internal Server Error: unable to load model mówi tylko tyle, że serwer Ollamy nie zdołał załadować modelu. Nie mówi, dlaczego. Prawdziwa przyczyna jest zapisana w logu serwera, w linii nad tym komunikatem. Na VPS z systemd czytasz ją poleceniem journalctl -e -u ollama.

Ten poradnik jest dla osoby, która wynajmuje VPS, wpisała ollama run albo zaimportowała plik GGUF z Hugging Face i zobaczyła właśnie ten komunikat. Najpierw pokazujemy, gdzie szukać przyczyny. Potem przechodzimy przez cztery typowe przyczyny. Przy każdej opisujemy, jak wygląda na serwerze bez GPU, ze stałą ilością RAM.

Dlaczego terminal pokazuje tylko „500”

Ollama składa się z dwóch części. Polecenie ollama run jest klientem. Model ładuje serwer, który na Linuksie działa jako usługa systemd o nazwie ollama. Klient wysyła żądanie HTTP. Gdy ładowanie się nie uda, serwer odpowiada kodem 500 (Internal Server Error, czyli błąd po stronie serwera). Kod 500 jest więc tylko opakowaniem. Szczegóły zostają w logu usługi.

Czasem część przyczyny przechodzi do klienta. W zgłoszeniu ollama#16547 (Ollama 0.30.5, macOS) terminal pokazał cały łańcuch:

Error: 500 Internal Server Error: llama-server process has terminated: exit status 1: error loading model: unknown model architecture: 'mllama'

Czytaj taki komunikat od końca. O przyczynie decyduje tekst po ostatnim dwukropku, a nie początek linii. W zgłoszeniu ollama#14419 z lutego 2026 roku terminal pokazał jednak tylko Error: 500 Internal Server Error: unable to load model. Wtedy jedynym źródłem informacji jest log.

Krok 1: sprawdź wersję Ollamy i przeczytaj log serwera

Zacznij od wersji. Prawie każda diagnoza zależy od tego, który build masz zainstalowany.

ollama -v

Zapisz wynik. Przyda się przy porównaniu z wymaganiami modelu i przy ewentualnym powrocie do starszej wersji.

Teraz log. Dokumentacja Ollamy dla Linuksa podaje to polecenie:

journalctl -e -u ollama

Opcja -e przewija od razu na koniec, więc widzisz najnowsze wpisy. Jeśli chcesz obserwować log na żywo, otwórz drugą sesję SSH i uruchom wariant ze strony o rozwiązywaniu problemów:

journalctl -u ollama --no-pager --follow --pager-end

W pierwszej sesji powtórz ollama run <model>. W drugiej zobaczysz linie, które serwer zapisał w chwili błędu. Gdy log jest długi, przefiltruj go:

journalctl -u ollama --no-pager | grep -iE 'error|terminated|memory|architecture'

Krok 2: włącz OLLAMA_DEBUG, gdy log mówi za mało

Domyślny poziom logowania czasem nie pokazuje przyczyny. Wtedy włącz tryb debugowania przez nadpisanie (override) usługi systemd:

sudo systemctl edit ollama

W edytorze dopisz:

[Service]
Environment="OLLAMA_DEBUG=1"

Zapisz plik i uruchom usługę ponownie:

sudo systemctl restart ollama

Zamiast edytora możesz ręcznie utworzyć plik /etc/systemd/system/ollama.service.d/override.conf z tą samą treścią. Wtedy przed restartem uruchom jeszcze sudo systemctl daemon-reload, żeby systemd wczytał zmieniony plik. Według dokumentacji OLLAMA_DEBUG=1 dodaje między innymi szczegóły z wykrywania GPU. Po diagnozie usuń tę linię tym samym poleceniem sudo systemctl edit ollama i znowu zrestartuj usługę. Log w trybie debugowania rośnie szybko, a na małym VPS miejsce na dysku jest ograniczone.

Przyczyna 1: unknown model architecture, czyli Ollama jest starsza niż model

W zgłoszeniu ollama#14419 użytkownik Ollamy 0.17.0 próbował uruchomić qwen3.5:35b. W logu serwera była taka linia:

llama_model_load: error loading model: error loading model architecture: unknown model architecture: 'qwen35'

Wariant MoE (mixture of experts) tego modelu zgłaszał qwen35moe. Znaczenie jest proste. Plik modelu deklaruje architekturę, której zainstalowany build nie zna, więc ładowanie kończy się błędem. W tamtym wątku problem z qwen35 rozwiązało przejście na wersję 0.17.1 lub nowszą.

Ten przypadek najczęściej trafia w pliki GGUF z Hugging Face. W tym samym wątku wyjaśniono, że modele Qwen3.5 pobrane z Hugging Face działają na silniku llama.cpp. Musiały więc poczekać, aż Ollama zsynchronizuje swoją kopię tego kodu. Kilku użytkowników nowszych wersji, 0.18.3 i 0.19.0, wciąż widziało ten błąd przy innych modelach. Aktualizacja pomaga więc wtedy, gdy nowa wersja faktycznie obsługuje daną architekturę. Nie pomaga zawsze.

Co zrobić:

1. Porównaj wynik ollama -v z informacjami o wydaniu modelu albo z notkami wydań Ollamy na stronie releases. Szukaj nazwy architektury z logu.
2. Jeśli Twoja wersja jest starsza, zaktualizuj Ollamę, uruchamiając ponownie skrypt instalacyjny (polecenie znajdziesz niżej).
3. Jeśli najnowsza wersja nadal nie zna tej architektury, wybierz inny model albo poczekaj na wydanie z obsługą.

Model z Hugging Face uruchamiasz w formie ollama run hf.co/{username}/{repository}, opcjonalnie z tagiem kwantyzacji po dwukropku. Jeśli plik masz już na dysku, import pliku GGUF do Ollamy przez Modelfile wygląda inaczej, ale sprawdzanie wersji działa tak samo. Ollama nie kwantyzuje plików GGUF podczas importu. Plik zostaje taki, jaki pobrałeś, razem ze swoją architekturą.

W kodzie wersji 0.17.0 jest też komunikat this model is not supported by your version of Ollama. You may need to upgrade. Jeśli go zobaczysz, przyczyna jest ta sama: build jest za stary dla tego modelu.

Przyczyna 2: model nie mieści się w pamięci VPS

Na VPS bez GPU cały model musi zmieścić się w RAM. Pamięć jest stała, kupiona razem z planem. Nie ma karty graficznej, na którą można przenieść część warstw. Gdy model jest za duży, a żaden inny model nie jest załadowany, harmonogram (scheduler) Ollamy zapisuje w logu linię:

model is too large for system memory

To linia z logu serwera na poziomie Info, a nie tekst błędu 500 w terminalu. Dlatego szukaj jej w journalctl. Ten sam komunikat cytuje nasz poradnik o uruchamianiu Ollamy na własnym VPS.

Starsze wydania opisywały to inaczej. W kodzie wersji 0.17.0 jest komunikat model requires more system memory (…) than is available (…). Na Linuksie dostępna pamięć to tam wolny RAM plus wolny swap. W kodzie wersji 0.40.7 jest z kolei llama-server reported out-of-memory during startup. Każdy z tych komunikatów oznacza to samo: za mało pamięci.

Sprawdź, ile masz wolnego RAM i co jest już załadowane:

free -h
ollama ps

ollama ps pokazuje modele działające w tej chwili. Domyślnie model zostaje w pamięci przez 5 minut, więc wolny RAM w free -h może być mniejszy, niż się spodziewasz. Model zatrzymasz poleceniem ollama stop <model>.

Masz cztery wyjścia. Zatrzymaj inne załadowane modele. Weź mniejszy model. Weź mocniej skwantyzowaną wersję tego samego modelu, bo kwantyzacja Q4, Q8 i FP16 zmienia rozmiar pliku. Albo przejdź na plan z większą pamięcią. Zanim wybierzesz, policz to na spokojnie: jak duży model LLM zmieści się w Twoim RAM.

Przyczyna 3: proces runnera zakończył działanie

Ollama ładuje model w osobnym procesie, tak zwanym runnerze. Gdy ten proces padnie, w logu pojawia się linia o jego zakończeniu. Jej brzmienie zależy od wersji. W kodzie 0.40.7 jest to llama-server process has terminated: …, a w 0.17.0 llama runner process has terminated: …. Dlatego szukaj w logu słowa terminated, a nie jednego dokładnego zdania:

journalctl -u ollama --no-pager | grep -i terminated

Sama ta linia nie wskazuje przyczyny. W zgłoszeniu #16547 ten sam początek prowadził do unknown model architecture: 'mllama', ale był to przypadek odwrotny do przyczyny nr 1. Model llama3.2-vision jest starszy, a użytkownicy zobaczyli błąd po aktualizacji Ollamy, choć wcześniej ten model u nich działał. Nikt w wątku nie napisał, że pomogła kolejna aktualizacja. Taki przypadek pasuje do sekcji o tymczasowym powrocie do starszej wersji. Przeczytaj tekst po dwukropku i dopasuj go do odpowiedniej sekcji tego poradnika.

Jeśli wynajmujesz serwer z kartą NVIDIA, a tekst po dwukropku dotyczy GPU, dokumentacja Ollamy podaje takie kroki:

sudo nvidia-modprobe -u
sudo rmmod nvidia_uvm
sudo modprobe nvidia_uvm
sudo dmesg | grep -i nvrm
sudo dmesg | grep -i nvidia

Pierwsze polecenie upewnia się, że moduł nvidia_uvm jest załadowany. Drugie i trzecie przeładowują ten moduł. Ostatnie dwa pokazują komunikaty sterownika z jądra. Dokumentacja zaleca też ustawienie zmiennej CUDA_ERROR_LEVEL=50, żeby dostać więcej informacji o błędach CUDA. Jeśli Ollama działa w Dockerze, sprawdź najpierw docker run --gpus all ubuntu nvidia-smi. Gdy to polecenie nie działa, Ollama nie zobaczy karty.

Na zwykłym VPS bez GPU te kroki nie mają zastosowania, bo nie ma tam sterowników NVIDIA. Skrypt instalacyjny na takiej maszynie informuje, że nie wykrył karty NVIDIA ani AMD i że Ollama będzie pracować tylko na CPU. Na serwerze bez GPU przyczyny szukaj w tekście po dwukropku, najczęściej w sekcji o architekturze albo o pamięci.

Przyczyna 4: niepełny lub uszkodzony plik modelu

Dokumentacja Ollamy nie opisuje, jak rozpoznać uszkodzony albo niepełny plik modelu. Nie znamy też żadnej konkretnej linii w logu, która by to potwierdzała. Jeśli log nie pasuje do żadnej z poprzednich przyczyn, częstym pierwszym krokiem jest usunięcie modelu i pobranie go od nowa. Traktuj to jako próbę, a nie udokumentowaną naprawę.

df -h /usr/share/ollama
ollama rm <model>
ollama pull <model>

Na Linuksie modele leżą domyślnie w /usr/share/ollama/.ollama/models. Jeśli ustawiłeś OLLAMA_MODELS, sprawdź df -h dla tamtego katalogu, bo ponowne pobranie potrzebuje wolnego miejsca. Jak działa ten katalog i czym różni się pull od run, opisujemy w poradniku ollama pull a ollama run i gdzie Ollama trzyma modele.

Jak zaktualizować Ollamę na VPS

Na Linuksie Ollamę aktualizujesz, uruchamiając ponownie skrypt instalacyjny:

ollama -v
curl -fsSL https://ollama.com/install.sh | sh
sudo systemctl restart ollama
ollama -v

Pierwsze ollama -v zapisuje wersję, z której wychodzisz. Ostatnie potwierdza, która wersja działa teraz. Skrypt tworzy usługę /etc/systemd/system/ollama.service z ustawieniem Restart=always i włącza ją, gdy w systemie działa systemd.

Tymczasowy powrót do starszej wersji po nieudanej aktualizacji

Bywa odwrotnie: model działał, potem przyszła aktualizacja i pojawił się błąd 500. Skrypt instalacyjny przyjmuje zmienną OLLAMA_VERSION, która instaluje wybraną wersję. Dokumentacja nie nazywa tego cofaniem wersji. To po prostu instalacja konkretnego numeru, ale do powrotu nadaje się dobrze.

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=<x.y.z> sh
sudo systemctl restart ollama
ollama -v

Zwróć uwagę, że OLLAMA_VERSION stoi po prawej stronie potoku, przy sh, tak jak w dokumentacji. Skrypt dopisuje tę wartość do adresu pobierania jako ?version=. Za <x.y.z> wstaw wersję, na której model ostatnio działał. Dlatego warto zapisywać wynik ollama -v przed każdą aktualizacją. Numery wydań znajdziesz na stronie releases. Ta lista nie zawsze jest ułożona ściśle według dat, więc szukaj numeru, a nie pozycji na liście.

Traktuj to jako rozwiązanie tymczasowe. Modele i sama Ollama zmieniają się szybko, więc nie przypinaj wersji na stałe. Stara wersja z czasem przestanie obsługiwać nowe modele i wrócisz do przyczyny nr 1. Gdy w notkach wydań pojawi się poprawka, wróć do zwykłej aktualizacji.

Przekroczony limit czasu też może być błędem ładowania modelu. W kodzie wersji 0.40.7, gdy ładowanie utknie i przez dłuższy czas nie robi postępu, serwer zwraca timed out waiting for llama-server to start - …, a odpowiedź HTTP ma wtedy zwykły kod 500. Taki błąd diagnozuj jak pozostałe z tego poradnika: przeczytaj tekst po myślniku i log serwera. Inne przypadki przekroczonego limitu czasu opisujemy w poradniku jak naprawić błąd context deadline exceeded w Ollamie.

FAQ

Co oznacza „Error: 500 Internal Server Error: unable to load model” w Ollamie?

Oznacza, że serwer Ollamy nie zdołał załadować modelu. Sam komunikat nie podaje przyczyny. Na Linuksie z systemd przeczytaj log usługi poleceniem journalctl -e -u ollama. Linia przed błędem pokaże prawdziwą przyczynę, na przykład nieznaną architekturę modelu albo brak pamięci.

Jak sprawdzić, czy moja wersja Ollamy obsługuje dany model?

Uruchom ollama -v i porównaj wynik z informacjami o wydaniu modelu oraz z notkami wydań Ollamy na GitHubie. Jeśli log pokazuje unknown model architecture, Twój build nie zna architektury zapisanej w pliku modelu. Zaktualizuj Ollamę poleceniem curl -fsSL https://ollama.com/install.sh | sh. Jeśli najnowsza wersja też jej nie zna, wybierz inny model.

Czy na VPS bez GPU błąd 500 może oznaczać brak RAM?

Tak. Na serwerze bez GPU cały model musi zmieścić się w pamięci RAM. Gdy się nie mieści, w logu serwera pojawia się linia model is too large for system memory. Ta linia trafia tylko do logu. W terminalu widzisz błąd 500, czasem z doklejonym opisem przyczyny, więc sprawdź log, a potem free -h i ollama ps. Pomoże mniejszy model albo mocniej skwantyzowana wersja. Jeśli to nie wystarcza, potrzebujesz planu z większą pamięcią.

Jak wrócić do starszej wersji Ollamy po nieudanej aktualizacji?

Uruchom skrypt instalacyjny z wybraną wersją: curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=<x.y.z> sh, a potem sudo systemctl restart ollama i ollama -v. Numer wersji znajdziesz na stronie wydań Ollamy na GitHubie. Traktuj to jako krok tymczasowy, bo stara wersja z czasem przestanie obsługiwać nowe modele.