Jak uruchomić serwer llama.cpp na VPS krok po kroku

Co budujesz

Uruchomienie serwera llama.cpp na VPS sprowadza się do jednego pliku binarnego, llama-server, który wczytuje pojedynczy plik modelu GGUF i odpowiada na żądania HTTP za pomocą API zgodnego z OpenAI. Skieruj dowolnego klienta OpenAI na http://127.0.0.1:8080/v1, aby rozpocząć pracę. Instalacja to tylko połowa sukcesu.

Reszta pracy to operacje: przypięcie wersji, utrzymanie portu na localhost, utworzenie jednostki systemd oraz decyzja o zachowaniu systemu w przypadku braku pamięci RAM. Niniejszy przewodnik omawia te zagadnienia. Jeśli nie podjęto jeszcze decyzji między dwiema oczywistymi opcjami, należy najpierw przeczytać porównanie zalet i wad Ollama oraz llama.cpp, ponieważ jest to instrukcja, którą tamto porównanie celowo pomija.

Wybór tagu wydania i jego zapisanie

Projekt llama.cpp oznacza tagiem niemal każde scalenie, dlatego tagi pełnią rolę numerów kompilacji. W dniu 18 sierpnia 2026 r. najnowszym tagiem jest b10488. Nie istnieje długoterminowa stabilna gałąź, co oznacza, że "latest" jest pojęciem zmiennym, a wersja, która została przetestowana, jest jedyną, którą można wspierać. Należy wybrać tag, zapisać go i używać tego samego ciągu znaków podczas klonowania, w nazwie pliku binarnego oraz w notatkach.

Dla każdego tagu udostępniane są również gotowe archiwa. Dla serwera VPS x86 obsługującego wyłącznie CPU jest to llama-b10488-bin-ubuntu-x64.tar.gz, natomiast archiwum arm64 znajduje się obok, jeśli korzystasz z serwera VPS o architekturze ARM zamiast x86.

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10488/llama-b10488-bin-ubuntu-x64.tar.gz
tar tf llama-b10488-bin-ubuntu-x64.tar.gz | head

Przed rozpakowaniem archiwum należy wyświetlić jego zawartość, aby sprawdzić lokalizację plików. Pliki binarne są linkowane z biblioteką C systemu, w którym zostały zbudowane, dlatego na starszych dystrybucjach mogą nie uruchomić się, zgłaszając błąd dotyczący wersji GLIBC_, która nie jest zainstalowana. Kompilacja ze źródeł na małym serwerze VPS zajmuje kilka minut i eliminuje ten rodzaj problemów, dlatego poniżej przedstawiono tę właśnie ścieżkę.

Budowa llama-server z przypiętego tagu

sudo apt update
sudo apt install -y build-essential cmake git libssl-dev
git clone --depth 1 --branch b10488 https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DLLAMA_BUILD_TESTS=OFF -DLLAMA_BUILD_EXAMPLES=OFF
cmake --build build --config Release -t llama-server -j 2

--branch b10488 w ramach klonu --depth 1 powoduje pobranie wyłącznie wskazanego tagu, dzięki czemu proces budowy nie ulega zmianie podczas pracy.

libssl-dev jest istotne, ponieważ opcja LLAMA_OPENSSL jest domyślnie włączona, a to ona umożliwia plikowi binarnemu późniejsze pobieranie modeli przez HTTPS. Bez nagłówków krok konfiguracji kończy się niepowodzeniem.

-DBUILD_SHARED_LIBS=OFF pozwala uzyskać jeden, samowystarczalny plik binarny. Domyślna kompilacja umieszcza biblioteki współdzielone obok pliku wykonywalnego, więc skopiowanie samego pliku wykonywalnego do /usr/local/bin kończy się błędem error while loading shared libraries: libllama.so.

-t llama-server buduje wyłącznie cel serwera. Domyślna kompilacja tworzy również pozostałe narzędzia oraz testy, co na dwurdzeniowym serwerze VPS oznacza kilka dodatkowych minut pracy nad plikami, które nie będą używane.

-j 2 jest celowe. Każde równoległe zadanie kompilacji zajmuje własny zestaw danych, więc -j $(nproc) na małym planie kończy się błędem c++: fatal error: Killed signal terminated program cc1plus, co oznacza przerwanie kompilatora przez mechanizm OOM (Out-Of-Memory) jądra systemu. Należy zmniejszyć liczbę zadań lub dodać przestrzeń wymiany (swap) na czas budowy.

Jedną z flag, którą warto rozważyć, jest GGML_NATIVE – domyślnie włączona, sprawia, że kompilator optymalizuje kod pod konkretny procesor, na którym odbywa się budowa. Jest to pożądane, jeśli budowa i uruchomienie odbywają się na tej samej maszynie. W przypadku budowy na jednym hoście i kopiowania pliku binarnego na inny, należy dodać -DGGML_NATIVE=OFF, ponieważ plik binarny używający instrukcji nieobsługiwanych przez drugi procesor zakończy się błędem Illegal instruction (core dumped) przy pierwszej próbie wnioskowania (inference).

Zainstaluj plik pod nazwą zawierającą tag.

./build/bin/llama-server --version
sudo install -m 755 build/bin/llama-server /usr/local/bin/llama-server-b10488
sudo ln -sfn /usr/local/bin/llama-server-b10488 /usr/local/bin/llama-server

--version wyświetla numer budowy oraz commit. Musi on być zgodny z tagiem, który został pobrany. Jeśli tak nie jest, zbudowano inną wersję. Utrzymywanie numeru w nazwie pliku i wskazywanie na niego za pomocą dowiązania symbolicznego sprawia, że aktualizacja sprowadza się do jednego polecenia ln -sfn oraz restartu, a wycofanie zmian (rollback) do wykonania tego samego polecenia ze starą wersją numeru.

Pobieranie modelu GGUF i wstępna weryfikacja miejsca na dysku

GGUF to format pojedynczego pliku ładowanego przez llama.cpp. Jeden plik zawiera wagi, tokenizator oraz metadane, więc nie ma potrzeby instalowania dodatkowych komponentów. Sufiks w nazwie pliku oznacza kwantyzację, czyli precyzję zapisu wag: Q4_K_M to 4-bitowa mieszanka, Q8_0 to 8-bit, a f16 to niekwantyzowany plik o połowicznej precyzji.

Przed pobraniem jakichkolwiek danych należy utworzyć konto serwisowe oraz katalog modelu.

sudo useradd --system --home /srv/llama --create-home --shell /usr/sbin/nologin llama
sudo install -d -o llama -g llama /srv/models
df -h /srv

Serwer może samodzielnie pobrać model za pomocą -hf, co jest najszybszym sposobem na sprawdzenie poprawności kompilacji.

sudo -u llama env LLAMA_CACHE=/srv/models /usr/local/bin/llama-server \
  -hf ggml-org/gemma-3-1b-it-GGUF:Q4_K_M --host 127.0.0.1 --port 8080

LLAMA_CACHE definiuje katalog pobierania. Bez tego parametru plik trafia do ~/.cache/llama.cpp w ramach konta, które uruchomiło polecenie, co jest niewłaściwą lokalizacją dla usługi, której katalog domowy zostanie wkrótce zabezpieczony przed odczytem. Po zakończeniu należy uruchomić ls -lh /srv/models, ponieważ nazwa pliku w pamięci podręcznej wywodzi się z nazwy repozytorium, a nie z właściwej nazwy pliku.

W przypadku usług należy pobierać pliki do wybranej ścieżki, aby plik jednostki (unit file) wskazywał na stabilną lokalizację.

sudo -u llama curl -L --output-dir /srv/models -O \
  https://huggingface.co/ggml-org/gemma-3-1b-it-GGUF/resolve/main/gemma-3-1b-it-Q4_K_M.gguf

Miejsce na dysku jest ograniczeniem, z którym użytkownicy stykają się najszybciej. Poniżej przedstawiono opublikowane rozmiary plików dla dwóch modeli, zweryfikowane 18 sierpnia 2026 roku.

[
  {
    "label": "gemma-3-1b-it Q4_K_M",
    "size_gb": 0.81
  },
  {
    "label": "gemma-3-1b-it Q8_0",
    "size_gb": 1.07
  },
  {
    "label": "gemma-3-1b-it f16",
    "size_gb": 2.01
  },
  {
    "label": "gpt-oss-20b MXFP4",
    "size_gb": 12.11
  }
]

Plik 4-bitowy dla modelu 1B zajmuje 0.81 GB. Ten sam model bez kwantyzacji zajmuje 2.01 GB, zatem wybór formatu zmienia zapotrzebowanie na miejsce ponad dwukrotnie. Model 20B w formacie MXFP4 zajmuje 12.11 GB, co przekracza pojemność dysku w wielu podstawowych planach hostingowych, a po pobraniu plik musi jeszcze zostać wczytany do pamięci RAM.

Przed każdym pobieraniem należy sprawdzić df -h. Wypełnienie systemu plików root podczas transferu 12 GB danych powoduje awarię wszystkich procesów wymagających zapisu, w tym dziennika systemowego.

Uruchomienie ręczne i weryfikacja

sudo -u llama /usr/local/bin/llama-server \
  --model /srv/models/gemma-3-1b-it-Q4_K_M.gguf \
  --host 127.0.0.1 --port 8080 \
  --ctx-size 4096 --parallel 1 --threads 2 --no-webui

W drugiej sesji sprawdź, czy serwer jest gotowy do pracy.

curl -s http://127.0.0.1:8080/health

Podczas ładowania pliku zwracany jest kod HTTP 503 oraz następująca treść:

{"error":{"code":503,"message":"Loading model","type":"unavailable_error"}}

Po zakończeniu ładowania treść zmienia się na {"status": "ok" }. Następnie wyślij właściwe żądanie.

curl -s http://127.0.0.1:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"local","messages":[{"role":"user","content":"Say hello in five words."}]}'

Obiekt JSON zawierający tablicę choices oznacza, że serwer działa poprawnie. Pole model jest obecne, ponieważ klienci OpenAI zawsze je przesyłają. Serwer ma załadowany jeden model, więc wartość ta nie jest używana do wyboru konkretnej instancji.

Interfejs API zgodny z OpenAI oraz pozostałe funkcje portu

POST /v1/chat/completions, POST /v1/completions oraz POST /v1/embeddings to ścieżki zgodne z OpenAI, a GET /v1/models zwraca informacje o załadowanym modelu. GET /health to wspomniana wcześniej kontrola gotowości, GET /props zwraca bieżące ustawienia serwera, a GET /metrics udostępnia liczniki Prometheus, jeśli uruchomiono proces z flagą --metrics.

Każdy zestaw SDK zgodny z OpenAI działa po ustawieniu adresu bazowego na http://127.0.0.1:8080/v1 oraz podaniu niepustego ciągu znaków jako klucza API. Weryfikacja klucza nie następuje, dopóki użytkownik samodzielnie nie ustawi --api-key.

Nie należy przyjmować deklaracji przepustowości innych osób jako wyznacznika dla własnego planu. Szybkość inferencji na procesorze zależy od liczby rdzeni, przepustowości pamięci oraz sąsiedztwa na hoście, dlatego należy zmierzyć liczbę tokenów na sekundę na własnym serwerze i uznać ten wynik za wiarygodny. Czas kradziony przez obciążonego sąsiada objawia się tutaj jako zmienna w czasie szybkość generowania danych.

Pozostawienie usługi na 127.0.0.1 i umieszczenie proxy przed nią

--host domyślnie korzysta z 127.0.0.1, więc serwer jest niedostępny z zewnątrz, dopóki ustawienie to nie zostanie zmienione. Należy pozostawić je bez zmian. W llama-server brakuje modelu użytkownika, limitów zapytań (rate limit) oraz użytecznych dzienników audytu, a jedynym wbudowanym mechanizmem kontroli jest --api-key, który porównuje pojedynczy ciąg znaków. Otwarty port inferencji oznacza darmową moc obliczeniową dla każdego, kto go odnajdzie. Ten sam błąd popełniony w przypadku Ollama ma identyczne skutki: zabezpieczanie lokalnego API modelu ma tu pełne zastosowanie.

Należy dokonać terminacji TLS (transport layer security) w nginx i przekierować ruch na port loopback.

server {
    listen 443 ssl;
    server_name llm.example.com;

    location /v1/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_buffering off;
        proxy_read_timeout 600s;
    }
}

proxy_buffering off jest wymagane do obsługi strumieniowania. Przy włączonym buforowaniu, nginx przetrzymuje zdarzenia wysyłane przez serwer (SSE) do momentu zakończenia odpowiedzi, przez co klient czeka w ciszy, a następnie otrzymuje całą odpowiedź naraz. proxy_read_timeout 600s jest niezbędne przy długich generacjach, ponieważ domyślny limit 60 sekund powoduje, że wolna odpowiedź kończy się błędem 504 Gateway Time-out. Certyfikat można uzyskać zgodnie z instrukcją Certbot i Let's Encrypt w nginx.

Jednostka systemd

Zapisz /etc/systemd/system/llama-server.service.

[Unit]
Description=llama.cpp server
After=network-online.target
Wants=network-online.target

[Service]
User=llama
Group=llama
Environment=LLAMA_ARG_MODEL=/srv/models/gemma-3-1b-it-Q4_K_M.gguf
Environment=LLAMA_ARG_HOST=127.0.0.1
Environment=LLAMA_ARG_PORT=8080
Environment=LLAMA_ARG_CTX_SIZE=4096
Environment=LLAMA_ARG_N_PARALLEL=1
Environment=LLAMA_ARG_THREADS=2
ExecStart=/usr/local/bin/llama-server --no-webui
Restart=on-failure
RestartSec=5
TimeoutStopSec=30
MemoryHigh=3G
MemoryMax=3500M
OOMPolicy=stop
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes

[Install]
WantedBy=multi-user.target

Ustawienia znajdują się w liniach Environment=, ponieważ llama-server odczytuje zmienne LLAMA_ARG_* dla większości flag, a argument wiersza poleceń nadpisuje odpowiadającą mu zmienną. Pozwala to na zmianę rozmiaru kontekstu w jednym miejscu i sprawia, że ExecStart pozostaje wystarczająco krótki, aby przejrzeć go jednym spojrzeniem.

ProtectSystem=strict ustawia cały system plików jako tylko do odczytu dla tej jednostki, co jest dopuszczalne, ponieważ serwer jedynie odczytuje model. Dodaj ReadWritePaths=/srv/models, jeśli usługa ma samodzielnie pobierać modele za pomocą -hf. ProtectHome=yes ukrywa /home oraz /root i jest to drugi powód, dla którego warto przechowywać modele w /srv: przy włączonym ProtectHome, domyślna ścieżka ~/.cache/llama.cpp jest całkowicie niewidoczna dla procesu.

sudo systemctl daemon-reload
sudo systemctl enable --now llama-server
systemctl status llama-server
curl -s http://127.0.0.1:8080/health
journalctl -u llama-server -n 50 --no-pager

enable --now to krok, który często jest pomijany. Bez enable serwer przestanie działać po kolejnym restarcie. Jeśli planowane są zadania wokół usługi, takie jak nocne sprawdzanie dostępności nowego wydania, mechanizmem do tego celu jest usługa systemd wraz z timerem.

Decyzja o zachowaniu w przypadku OOM przed jego wystąpieniem

Zużycie pamięci składa się z dwóch części, które zachowują się odmiennie po osiągnięciu limitu. Plik modelu jest domyślnie mapowany w pamięci, więc jego strony są wspierane przez plik: jądro może je usunąć i ponownie odczytać z dysku. Pamięć podręczna KV, czyli stan dla każdego tokena utrzymywany przez serwer dla każdej aktywnej konwersacji, jest pamięcią anonimową. Nie można jej usunąć, dlatego to ona powoduje zabicie procesu.

Dlatego dwa limity w jednostce pełnią różne funkcje. MemoryHigh=3G to limit miękki: po jego przekroczeniu jądro wywiera presję na cgroup, więc zmapowane strony modelu są usuwane i odczytywane z dysku przy kolejnym tokenie. Usługa działa dalej, ale wolniej. MemoryMax=3500M to limit twardy: po jego przekroczeniu proces jest zabijany, co jest wyraźnie odnotowywane w dzienniku.

llama-server.service: A process of this unit has been killed by the OOM killer.

Ustaw --ctx-size samodzielnie. Wartość domyślna to 0, co oznacza kontekst, z którym model był trenowany, a w nowoczesnych modelach z długim kontekstem powoduje to alokację bardzo dużej pamięci podręcznej KV podczas startu. Usługa kończy działanie, zanim obsłuży choć jedno żądanie. --parallel mnoży ten sam koszt, ponieważ każdy slot przechowuje własny stan konwersacji, więc pozostaw wartość 1, dopóki nie będziesz mieć pewności, że potrzebujesz współbieżności.

Dzięki Restart=on-failure zabita usługa powraca. Jeśli jest zabijana przy każdym starcie, systemd poddaje się, a systemctl status wyświetla start request repeated too quickly. Jest to poprawne zachowanie: pętla restartów, która odczytuje 12 GB plik co pięć sekund, jest gorsza niż awaria. Skoryguj limit lub rozmiar kontekstu, a następnie wyczyść stan za pomocą sudo systemctl reset-failed llama-server.

Monitoruj rzeczywistą wartość za pomocą systemctl show llama-server -p MemoryCurrent podczas wykonywania żądania. Ograniczanie pamięci procesu i procesora za pomocą systemd omawia te dyrektywy bardziej szczegółowo.

Unikaj swap dla tego obciążenia. Model przeniesiony do swap zamienia każdy token w odczyt dyskowy o losowym przesunięciu. Mapowanie pliku modelu w pamięci osiąga ten sam efekt przy mniejszej szkodliwości, ponieważ jądro odczytuje potrzebne strony bezpośrednio z pliku.

Kiedy Ollama stanowi lepsze rozwiązanie

To moment wyboru ścieżki. Wybierz llama-server, gdy wymagany jest pojedynczy proces z określonymi flagami, konkretną wersją kompilacji oraz wybranym plikiem, gdzie środowisko pozostaje niezmienne, ponieważ nie działają żadne inne procesy.

Wybierz Ollama, gdy potrzebne jest zarządzanie modelami: pobieranie modeli po nazwie, przechowywanie kilku z nich na dysku, zwalnianie pamięci przez nieaktywne modele oraz aktualizacja za pomocą jednej komendy zamiast ponownej kompilacji. Jest to realna praca, którą w przeciwnym razie trzeba byłoby oskryptować samodzielnie. Uruchamianie Ollama na VPS to to samo zadanie z odwrotnym kompromisem. Oba rozwiązania udostępniają API zgodne z OpenAI, więc kod klienta pozostaje użyteczny po zmianie w dowolnym kierunku.

Aktualizacja przypiętej wersji kompilacji

Zastąp bNNNNN znacznikiem, na który chcesz przejść.

cd llama.cpp
git fetch --tags
git checkout bNNNNN
cmake -B build -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DLLAMA_BUILD_TESTS=OFF -DLLAMA_BUILD_EXAMPLES=OFF
cmake --build build --config Release -t llama-server -j 2
sudo install -m 755 build/bin/llama-server /usr/local/bin/llama-server-bNNNNN
sudo ln -sfn /usr/local/bin/llama-server-bNNNNN /usr/local/bin/llama-server
sudo systemctl restart llama-server

Stary plik binarny pozostaje na dysku, więc wycofanie zmian wymaga jednego polecenia ln -sfn powrotu do llama-server-b10488 oraz jednego restartu. Przed aktualizacją należy zapoznać się z informacjami o wydaniu. Pliki GGUF są wersjonowane i starsze wersje nadal będą się ładować, jednak nazwy flag ulegają zmianie: --mlock oraz --no-mmap zostały już uznane za przestarzałe na rzecz --load-mode, a plik jednostki przekazujący usuniętą flagę spowoduje błąd przy starcie z komunikatem o nierozpoznanym argumencie.

Tryby awarii i komunikaty, które zobaczysz

error while loading shared libraries: libllama.so po skopiowaniu pliku binarnego w inne miejsce. Domyślna kompilacja tworzy obok niego biblioteki współdzielone. Skompiluj ponownie z użyciem -DBUILD_SHARED_LIBS=OFF lub skopiuj cały katalog build/bin.

Illegal instruction (core dumped) podczas uruchamiania lub przy pierwszym żądaniu. Plik binarny został skompilowany z włączoną opcją GGML_NATIVE dla innego procesora niż ten, na którym jest uruchamiany. Skompiluj ponownie na tej maszynie lub skonfiguruj za pomocą -DGGML_NATIVE=OFF.

c++: fatal error: Killed signal terminated program cc1plus podczas budowania. Kompilator został zamknięty z powodu zbyt dużego zużycia pamięci. Zmniejsz -j lub dodaj przestrzeń wymiany (swap) na czas budowania i usuń ją po zakończeniu.

curl: (7) Failed to connect ... Connection refused z poziomu laptopa. Jest to poprawne zachowanie: serwer nasłuchuje na adresie loopback VPS-a. Przetestuj bezpośrednio na VPS-ie lub otwórz tunel za pomocą ssh -L 8080:127.0.0.1:8080 user@your-vps i użyj http://127.0.0.1:8080 lokalnie.

HTTP 503 z "message":"Loading model" przez pierwsze sekundy lub minuty po restarcie. Wczytywanie wielogigabajtowego pliku wymaga czasu, a systemd zgłasza jednostkę jako aktywną w momencie uruchomienia procesu, na długo przed załadowaniem modelu do pamięci.

Żądania zawieszają się, a następnie zwracają 504 Gateway Time-out. Proxy przerwało połączenie, zanim model zakończył pracę. Zwiększ proxy_read_timeout i wyłącz proxy_buffering, aby tokeny docierały do klienta w miarę ich generowania.

Jednostka restartuje się w pętli, a następnie zatrzymuje z komunikatem start request repeated too quickly. Coś przerywa jej działanie przy każdym starcie. Sprawdź journalctl -u llama-server pod kątem wpisu OOM killer, a następnie zmniejsz --ctx-size, zmniejsz --parallel lub zwiększ MemoryMax.

FAQ

Czy na serwerze VPS uruchomić serwer llama.cpp czy Ollama?

Uruchom llama-server, jeśli chcesz przypiąć konkretną wersję kompilacji, przekazać precyzyjne flagi i przechowywać jeden model w jednym pliku, którego nikt nie zaktualizuje bez Twojej wiedzy. Uruchom Ollama, jeśli oczekujesz zarządzania modelami i aktualizacji jednym poleceniem, ponieważ pobieranie modeli po nazwie, przechowywanie kilku na dysku i zwalnianie nieużywanych to zadania, które w przeciwnym razie musiałbyś oskryptować samodzielnie. Oba rozwiązania udostępniają API zgodne z OpenAI, więc kod klienta nie wymaga zmian w przypadku późniejszej migracji.

Do której wersji llama.cpp powinienem przypiąć konfigurację?

Do dowolnego tagu, który został faktycznie zbudowany i przetestowany. llama.cpp oznacza tagiem niemal każde scalenie, a nazwy są numerami kompilacji, takimi jak b10488, który był najnowszy w dniu 18 sierpnia 2026. Nie istnieje oddzielna gałąź stabilna, więc wersja "bieżąca" zmienia się kilka razy dziennie. Sklonuj repozytorium za pomocą --branch <tag>, zainstaluj plik binarny pod nazwą zawierającą dany tag i skieruj na niego dowiązanie symboliczne, aby aktualizacja i wycofanie zmian wymagały tylko jednego polecenia.

Ile pamięci RAM potrzebuje llama-server?

Zacznij od rozmiaru pliku GGUF, a następnie dodaj pamięć podręczną KV, która rośnie wraz z --ctx-size oraz liczbą slotów --parallel. Opublikowane dane nie zastąpią pomiarów własnej konfiguracji, ponieważ całkowite zużycie zależy od modelu, kwantyzacji i dopuszczonego kontekstu. Uruchom systemctl show llama-server -p MemoryCurrent podczas przetwarzania żądania i użyj uzyskanej wartości.

Dlaczego /health zwraca 503 z komunikatem "Loading model"?

Proces został uruchomiony, ale plik modelu nie znajduje się jeszcze w pamięci, więc serwer odpowiada {"error":{"code":503,"message":"Loading model","type":"unavailable_error"}}. Jest to normalne zachowanie po każdym restarcie, trwające tyle, ile odczyt pliku z dysku. Staje się to problemem tylko wtedy, gdy klient lub proxy traktuje pierwsze 503 jako błąd krytyczny. Odpytuj /health, aż zwróci {"status": "ok" }.

Czy mogę udostępnić llama-server bezpośrednio w Internecie?

Nie wiąż go z 0.0.0.0 i nie otwieraj portu. Serwer nie posiada kont, limitowania zapytań ani dziennika żądań nadającego się do audytu, a jedynym wbudowanym zabezpieczeniem jest --api-key, porównujące pojedynczy ciąg znaków. Pozostaw domyślne powiązanie 127.0.0.1, umieść przed nim nginx z TLS i skonfiguruj również --api-key, aby błąd w konfiguracji proxy nie pozostawił modelu otwartego dla każdego.