Jak uruchomić serwer llama.cpp na VPS z systemd

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 pośrednictwem API zgodnego z OpenAI. Skieruj dowolnego klienta OpenAI na http://127.0.0.1:8080/v1, aby rozpocząć pracę. Instalacja to tylko połowa zadania.

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. Ten przewodnik omawia właśnie te kwestie. Jeśli nie podjąłeś jeszcze decyzji między dwiema oczywistymi opcjami, przeczytaj najpierw porównanie zalet i wad Ollama oraz llama.cpp, ponieważ niniejszy poradnik pomija te aspekty celowo.

Wybierz tag wydania i zapisz go

Projekt llama.cpp oznacza tagiem niemal każde scalenie, więc tagi pełnią rolę numerów kompilacji. b10488 to najnowsza wersja na dzień 18 sierpnia 2026. Nie istnieje długoterminowa stabilna gałąź, co oznacza, że "latest" jest pojęciem zmiennym, a wersja, którą przetestowano, 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.

Każde wydanie zawiera również gotowe archiwa. Dla serwera VPS z procesorem x86 (tylko CPU) jest to llama-b10488-bin-ubuntu-x64.tar.gz, a archiwum dla architektury arm64 znajduje się obok, jeśli korzystasz z serwera VPS opartego na 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, więc 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ę postępowania.

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 wewnątrz klonu --depth 1 przełącza na dany tag i nic więcej, 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 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 budowa umieszcza biblioteki współdzielone obok pliku wykonywalnego, więc skopiowanie samego pliku 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 budowa kompiluje również pozostałe narzędzia oraz testy, co na VPS z dwoma rdzeniami oznacza kilka dodatkowych minut poświęconych na pliki, które nigdy nie zostaną uruchomione.

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

Jedną z flag, którą warto rozważyć, jest GGML_NATIVE, domyślnie włączona, dzięki czemu kompilator optymalizuje kod pod konkretny procesor, na którym odbywa się budowa. Jest to pożądane, gdy budowa odbywa się na maszynie, która będzie uruchamiać serwer. Jeśli budowa odbywa się raz, a plik binarny jest kopiowany na inny host, należy dodać -DGGML_NATIVE=OFF, ponieważ plik binarny używający instrukcji, których drugi procesor nie posiada, zakończy się błędem Illegal instruction (core dumped) przy pierwszej próbie wnioskowania.

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, na który przełączono repozytorium. Jeśli tak nie jest, zbudowano inny kod. Przechowywanie numeru w nazwie pliku i wskazywanie na niego za pomocą dowiązania symbolicznego sprawia, że aktualizacja to jedno polecenie ln -sfn oraz restart, a wycofanie zmian to to samo polecenie z użyciem starego numeru.

Pobranie 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 mieszanka 4-bitowa, Q8_0 to 8-bitowa, a f16 to plik o połowicznej precyzji bez kwantyzacji.

Przed pobraniem jakichkolwiek plików 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 użytkownika, który uruchomił polecenie, co jest niewłaściwą lokalizacją dla usługi, której katalog domowy zostanie wkrótce zabezpieczony przed odczytem. Po pobraniu należy wykonać ls -lh /srv/models, ponieważ nazwa pliku w pamięci podręcznej jest pochodną nazwy repozytorium, a nie oryginalnej nazwy pliku.

W przypadku usług należy pobierać pliki do wybranej ścieżki, aby plik jednostki miał stabilny punkt odniesienia.

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 r.

[
  {
    "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 wymagania przestrzeni dyskowej 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. W przypadku zainteresowania konkretną rodziną modeli, analogiczna analiza rozmiarów dla GLM pokazuje, jak szybko główny model staje się zbyt kosztowny dla VPS, podczas gdy jego mniejszy odpowiednik mieści się w limitach.

Przed każdym pobieraniem należy sprawdzić df -h. Wypełnienie głównego systemu plików 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ść odpowiedzi to {"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 występuje w odpowiedzi, ponieważ klienci OpenAI zawsze je przesyłają. Serwer ma załadowany tylko jeden model, więc wartość ta nie służy do wyboru żadnego z nich.

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 po uruchomieniu z flagą --metrics.

Każde SDK zgodne z OpenAI zadziała po ustawieniu adresu bazowego na http://127.0.0.1:8080/v1 i 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ć deklarowanej przepustowości innych osób jako wyznacznika dla własnego planu. Szybkość wnioskowania na procesorze (CPU inference) zależy od liczby rdzeni, przepustowości pamięci oraz sąsiadów współdzielących hosta, dlatego należy zmierzyć liczbę tokenów na sekundę na własnej maszynie i uznać ten wynik za wiarygodny. Czas kradziony przez obciążonego sąsiada (steal time) objawia się tutaj jako zmienna w czasie prędkość generowania danych.

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

--host domyślnie nasłuchuje na 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 nie zaimplementowano modelu użytkownika, limitów zapytań ani użytecznych dzienników audytu, a jedynym wbudowanym zabezpieczeniem jest --api-key, które 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: zasady opisane w zabezpieczaniu lokalnego API modelu mają tutaj 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 serwera (SSE) do momentu zakończenia odpowiedzi, przez co klient czeka w bezczynności, 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 powolna 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

Wpisz /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ą. Zapewnia to jedno miejsce do zmiany rozmiaru kontekstu 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 większość osób pomija. Bez enable serwer przestanie działać po kolejnym restarcie. Jeśli planowane są zadania wokół usługi, takie jak nocne sprawdzanie dostępności nowej wersji, 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 odczytać ponownie z dysku. Pamięć podręczna KV, czyli stan dla każdego tokena utrzymywany przez serwer dla każdej aktywnej konwersacji, to pamięć anonimowa. 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: powyżej niego 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 zwalnia. MemoryMax=3500M to limit twardy: po jego przekroczeniu proces jest zabijany, co jest wyraźnie odnotowane w dzienniku.

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

Ustaw --ctx-size samodzielnie. Wartością domyślną jest 0, co oznacza kontekst, z którym model był trenowany, a w przypadku nowoczesnych modeli 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ędzie wymagana obsługa 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 przetwarzania żądania. Ograniczanie pamięci procesu i procesora za pomocą systemd zawiera szczegółowy opis tych dyrektyw.

Unikaj partycji swap dla tego typu obciążenia. Model przeniesiony do swap zamienia każdy token w odczyt dyskowy z losowym przesunięciem. 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 jest lepszym rozwiązaniem

To punkt zwrotny. Wybierz llama-server, gdy potrzebujesz jednego procesu z określonymi flagami, ustaloną wersją kompilacji i wybranym plikiem, gdzie środowisko pozostaje niezmienne, ponieważ nie działają żadne inne procesy.

Wybierz Ollama, gdy potrzebujesz zarządzania modelami: pobierania modeli po nazwie, przechowywania kilku z nich na dysku, zwalniania pamięci nieużywanych modeli oraz aktualizacji za pomocą jednego polecenia zamiast przebudowywania całości. To realna praca, którą w przeciwnym razie musiałbyś oskryptować samodzielnie. Uruchamianie Ollama na VPS to to samo zadanie, ale z innym balansem korzyści. Oba rozwiązania udostępniają API zgodne z OpenAI, więc kod klienta pozostaje użyteczny po przejściu na dowolną ze stron.

Aktualizacja przypiętej kompilacji

Zastąp bNNNNN znacznikiem, na który przechodzisz.

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 (release notes). 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 (unit file) przekazujący usuniętą flagę nie uruchomi się, zwracając komunikat 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 flagą -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 połączenie 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 pliku o rozmiarze wielu gigabajtów zajmuje czas, 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 oczekiwanie, 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 błędem 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 utrzymać jeden model w jednym pliku, którego nikt nie zaktualizuje bez Twojej wiedzy. Uruchom Ollama, jeśli zależy Ci na zarządzaniu modelami i aktualizacjach 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 18 sierpnia 2026. Nie istnieje oddzielna gałąź stabilna, więc wersja "current" zmienia się kilka razy dziennie. Sklonuj repozytorium za pomocą --branch <tag>, zainstaluj plik binarny pod nazwą zawierającą ten 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 oraz dopuszczalnego 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 po każdym restarcie i trwa tak długo, jak odczyt pliku. 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ę wystawić llama-server bezpośrednio do Internetu?

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, które porównuje pojedynczy ciąg znaków. Pozostaw domyślne powiązanie 127.0.0.1, umieść przed nim nginx z TLS i ustaw również --api-key, aby jeden błąd w konfiguracji proxy nie pozostawił modelu otwartego dla wszystkich.