Ollama na VPS: jak bezpiecznie uruchomić własny LLM

Co budujesz

Pojedynczy model językowy o otwartych wagach, uruchomiony na własnym serwerze, obsługiwany przez API HTTP oraz, opcjonalnie, stronę czatu w przeglądarce. Ollama to komponent, który pobiera model, ładuje go do pamięci i obsługuje żądania na http://127.0.0.1:11434. Instalacja sprowadza się do jednego polecenia. Trudne aspekty tego rozwiązania znajdują się gdzie indziej: dobór modelu, który zmieści się w pamięci RAM serwera VPS, oraz uniknięcie przypadkowego udostępnienia nieautoryzowanego serwera inferencji w całym Internecie.

Najpierw dwa szczere ostrzeżenia. Serwer VPS działający wyłącznie na procesorze (CPU) obsługuje małe modele powoli, a API nie posiada żadnego wbudowanego mechanizmu uwierzytelniania. Oba te zagadnienia zostały szczegółowo omówione poniżej, ponieważ to właśnie w tych obszarach najczęściej dochodzi do problemów.

Weryfikacja zapotrzebowania na zasoby w liczbach

Zapotrzebowanie modelu na pamięć operacyjną odpowiada w przybliżeniu rozmiarowi jego pliku, powiększonemu o około jeden gigabajt narzutu środowiska uruchomieniowego oraz dodatkową przestrzeń na okno kontekstowe. Domyślne modele w Ollama są kwantyzowane do 4 bitów (oznaczenie Q4), co przekłada się na około pół gigabajta pamięci RAM na każdy miliard parametrów. Prosta arytmetyka determinuje zatem możliwości sprzętowe.

Model 3B, taki jak llama3.2:3b, zajmuje około 2 GB po pobraniu i wymaga około 4 GB wolnej pamięci RAM do działania. Model 7B lub 8B, taki jak mistral:7b lub llama3.1:8b, zajmuje około 5 GB na dysku i wymaga około 8 GB pamięci RAM, przy czym 16 GB zapewnia komfortową pracę. Model 13B lub 14B wymaga około 16 GB pamięci RAM. Każdy model z zakresu 30B-70B wymaga serwera z dużą ilością pamięci RAM lub, w praktyce, karty graficznej (GPU). Na serwerze VPS opartym wyłącznie na CPU taki model albo nie zostanie uruchomiony, albo będzie generował odpowiedzi tak wolno, że stanie się bezużyteczny.

Kwestia szybkości jest często niedoceniana. Wydajność wnioskowania na CPU jest ograniczona przepustowością pamięci, a nie taktowaniem procesora, a współdzielone vCPU na serwerach VPS oferują ograniczoną przepustowość. Należy spodziewać się wydajności rzędu kilku do kilkunastu tokenów na sekundę: model 7-8B Q4 może osiągnąć od 4 do 10 tokenów na sekundę, a model 3B od 10 do 25. Karta graficzna (GPU) jest zazwyczaj o rząd wielkości szybsza. Powyższe wartości są szacunkowe; rzetelne podejście wymaga przeprowadzenia pomiarów na własnej maszynie, co opisano w kroku dotyczącym uruchamiania. Należy polegać na wynikach eval rate, a nie na liczbach podawanych w artykułach, w tym w tym tekście.

Wniosek praktyczny: małe, kwantyzowane modele uruchamiane na CPU są użyteczne do tworzenia szkiców, podsumowań i klasyfikacji, o ile akceptowalne jest tempo ich pracy. W przypadku zadań wymagających większej skali lub szybkości, należy zaplanować budżet na instancję z GPU.

Aby dopasować konkretny model do posiadanych zasobów, należy oszacować zapotrzebowanie na pamięć w tym miejscu:

Instalacja Ollama

Istnieją dwie poprawne metody. Oficjalny skrypt jest najprostszym rozwiązaniem na czystym VPS:

curl -fsSL https://ollama.com/install.sh | sh

Tworzy on użytkownika systemowego o nazwie ollama, instaluje plik binarny w /usr/local/bin/ollama oraz rejestruje usługę systemd o nazwie ollama.service, która uruchamia się przy starcie systemu i nasłuchuje na 127.0.0.1:11434. Należy potwierdzić działanie usługi:

systemctl status ollama
ollama --version

Jeśli używany jest już Docker, należy skorzystać z kontenera:

docker run -d --name ollama \
  -p 127.0.0.1:11434:11434 \
  -v ollama:/root/.ollama \
  --restart always \
  ollama/ollama

Należy zwrócić uwagę na prefiks 127.0.0.1: przy mapowaniu portu. Powoduje on powiązanie portu wyłącznie z localhost. Zastosowanie -p 11434:11434 spowodowałoby udostępnienie usługi na wszystkich interfejsach, co jest błędem, przed którym ostrzega sekcja dotycząca bezpieczeństwa. Należy wybrać jedną metodę instalacji; nie należy uruchamiać skryptu i kontenera jednocześnie, ponieważ oba procesy będą rywalizować o ten sam port.

Pobieranie i uruchamianie pierwszego modelu

ollama pull llama3.2:3b
ollama run llama3.2:3b

pull pobiera warstwy modelu na dysk (w tym przypadku około 2 GB). run wczytuje je do pamięci i wyświetla znak zachęty >>>. Wpisz pytanie. Wygenerowanie pierwszego tokena może potrwać kilka sekund, podczas gdy wagi są ładowane z dysku do pamięci RAM, po czym następuje strumieniowanie odpowiedzi. Wpisz /bye, aby zakończyć czat; Ollama pozostanie uruchomiona w tle.

Sprawdź, co jest załadowane i jak zajmuje pamięć:

ollama ps

Kolumna PROCESSOR wskazuje rzeczywisty stan. 100% CPU oznacza, że procesor GPU nie jest wykorzystywany, co jest przyczyną niskiej wydajności. Zmierz rzeczywistą prędkość za pomocą flagi verbose:

ollama run --verbose llama3.2:3b "Write two sentences about Linux."

Wiersz eval rate wyświetlony na końcu wskazuje liczbę tokenów na sekundę dla danego sprzętu. Jest to wartość, na której należy opierać planowanie wydajności.

Gdzie przechowywane są modele i ile miejsca na dysku zaplanować

Modele instalowane przez skrypt i uruchamiane jako usługa znajdują się w katalogu domowym użytkownika ollama:

sudo du -sh /usr/share/ollama/.ollama/models

W przypadku uruchomienia interaktywnego przez bieżącego użytkownika, modele znajdują się w ~/.ollama/models. W kontenerze są one przechowywane w wolumenie nazwanym ollama. Jest to istotne, ponieważ wagi kwantyzowane szybko zajmują miejsce: model 3B to około 2 GB, 7-8B to około 5 GB, a 14B to około 9 GB. Pobranie czterech modeli w celu porównania oznacza zużycie 20 GB bez wyraźnego zauważenia tego faktu. Należy dobrać rozmiar dysku do liczby modeli, które mają być przechowywane, a pozostałe usuwać za pomocą ollama rm <model>. Jeśli na tym samym serwerze VPS działa już usługa o dużym zapotrzebowaniu na miejsce, taka jak PhotoPrism lub Immich przechowujące bibliotekę zdjęć, należy najpierw odjąć to zużycie od dostępnej przestrzeni, a pozostałą część potraktować jako rzeczywisty budżet na modele.

Uruchomienie jako kontrolowana usługa

Skrypt instalacyjny zarejestrował już ollama.service, więc usługa restartuje się automatycznie po uruchomieniu systemu bez dodatkowych działań. Warto zmienić czas utrzymywania modelu w pamięci oraz, w niektórych konfiguracjach, adres powiązania (bind address). Oba parametry należy umieścić w pliku typu drop-in dla systemd, aby aktualizacja Ollama ich nie nadpisała:

sudo systemctl edit ollama.service

Dodaj poniższą treść pod nagłówkiem [Service], który wyświetli edytor:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE określa czas, przez jaki model pozostaje w pamięci po ostatnim żądaniu (domyślnie 5 minut). Zwiększ tę wartość na serwerze, z którego korzystasz przez cały dzień, aby uniknąć każdorazowego przeładowywania wag. Ustaw wartość 0 na maszynie z ograniczonymi zasobami, aby zwolnić pamięć RAM natychmiast po zakończeniu żądania. systemctl edit przeładowuje pliki jednostek, więc wykonaj restart, aby zastosować zmiany:

sudo systemctl restart ollama

Kluczowy aspekt bezpieczeństwa

Domyślnie Ollama wiąże się z 127.0.0.1:11434, dzięki czemu dostęp do niej mają tylko procesy działające na samym VPS. To ustawienie domyślne jest prawidłowe. Należy je zachować.

Interfejs API nie posiada żadnego mechanizmu uwierzytelniania. Brak kluczy API, logowania, limitów zapytań czy list dozwolonych adresów. Każdy, kto uzyska dostęp do portu 11434, może uruchomić dowolny pobrany model, pobrać nowe, usunąć istniejące oraz trwale obciążyć procesor lub kartę graficzną w 100%. Skanery takie jak Shodan indeksują tysiące otwartych instancji Ollama, a wystawiona usługa zostaje wykryta i wykorzystana w ciągu kilku godzin.

Jest więc jeden błąd, którego nie wolno popełnić: nie ustawiaj OLLAMA_HOST=0.0.0.0 i nie otwieraj portu 11434 w zaporze. Spowoduje to udostępnienie nieuwierzytelnionego serwera wnioskowania w całym Internecie. Żadna konfiguracja nie zabezpieczy bezpośredniego dostępu do 11434 przez 0.0.0.0, ponieważ w Ollama nie ma czego konfigurować — uwierzytelnianie po prostu nie istnieje. Jest to zasada dotycząca tej konkretnej usługi, a nie zakaz otwierania jakichkolwiek portów: samodzielnie hostowany przekaźnik RustDesk do zdalnego pulpitu musi przyjmować ruch publiczny, aby w ogóle działać, a uzasadnia to własnym uwierzytelnianiem opartym na kluczach oraz krótką, udokumentowaną listą portów. Ollama nie ma żadnego z tych mechanizmów.

Istnieją trzy bezpieczne sposoby na uzyskanie dostępu do modelu spoza serwera:

• Pozostawienie usługi lokalnie. Jeśli jedynym klientem jest inny program na tym samym VPS, skrypt cron, bot lub serwer MCP łączący narzędzia z modelem, należy pozostawić powiązanie na 127.0.0.1, a program powinien łączyć się z http://127.0.0.1:11434. Nic nie jest wystawione na zewnątrz i nie są wymagane dodatkowe zabezpieczenia.
• Dostęp przez prywatny tunel. Należy umieścić VPS w sieci WireGuard VPN zarządzanej samodzielnie, ustawić OLLAMA_HOST na adres tunelu (na przykład 10.8.0.1, a nie 0.0.0.0) i zezwolić na połączenia tylko dla węzłów VPN. Publiczny Internet nadal nie będzie widział żadnej usługi na porcie 11434.
• Zastosowanie uwierzytelniającego reverse proxy. Należy zakończyć połączenie TLS i wymagać hasła lub tokena na poziomie nginx, Traefik lub Caddy, a następnie przekierować ruch do 127.0.0.1:11434. Ollama zachowuje powiązanie z localhost, a proxy jest jedynym komponentem nasłuchującym na publicznym porcie. Jest to rozwiązanie analogiczne do umieszczenia certyfikatu Let's Encrypt na nginx przed dowolną usługą lokalną.

Opcja z reverse proxy jest dokładnie tym, co oferuje interfejs czatu w kolejnym kroku, wraz z wbudowanym mechanizmem logowania.

Dodawanie interfejsu czatu za pomocą Open WebUI z obsługą TLS

Open WebUI to samodzielnie hostowany interfejs czatu. Uruchom go w Docker i skieruj na lokalną instancję Ollama:

docker run -d \
  --name open-webui \
  --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data \
  --restart always \
  ghcr.io/open-webui/open-webui:main

Flaga --network=host jest kluczowym szczegółem na serwerze VPS z systemem Linux. Umieszcza ona kontener w przestrzeni nazw sieci hosta, dzięki czemu 127.0.0.1 wewnątrz kontenera staje się własnym interfejsem loopback hosta, a kontener uzyskuje dostęp do Ollama pod adresem 127.0.0.1:11434 bez konieczności nasłuchiwania Ollama na innych interfejsach. Receptura z siecią typu bridge, którą można znaleźć w innych źródłach, --add-host=host.docker.internal:host-gateway z OLLAMA_BASE_URL=http://host.docker.internal:11434, tutaj nie zadziała: ta nazwa wskazuje na bramę sieciową Docker bridge, a usługa powiązana z 127.0.0.1 na hoście nie jest osiągalna przez bridge, więc Open WebUI zgłasza błąd braku połączenia z Ollama.

Wadą pracy w sieci hosta jest to, że Open WebUI nasłuchuje teraz na porcie 8080 hosta na wszystkich interfejsach; każde mapowanie -p jest ignorowane, a Docker wyświetla stosowne ostrzeżenie. Dlatego należy zamknąć port 8080 zarówno na firewallu hosta, jak i dostawcy, pozostawiając TLS reverse proxy jako jedyną publiczną bramę. Przy pierwszej wizycie Open WebUI poprosi o utworzenie konta administratora; to konto stanowi warstwę uwierzytelniania, więc należy wybrać silne hasło.

Aby otworzyć czat z laptopa przez HTTPS, umieść TLS reverse proxy przed 127.0.0.1:8080. Jeśli na serwerze obsługujesz już kilka aplikacji Docker, Traefik z automatycznym TLS dla wielu aplikacji będzie najczystszym rozwiązaniem: jeden blok etykiet wystawia certyfikat i kieruje ruch chat.example.com do Open WebUI. Zasada z sekcji dotyczącej bezpieczeństwa pozostaje w mocy: proxy zarządza portem publicznym i logowaniem, podczas gdy Ollama pozostaje na localhost, a port 8080 należący do Open WebUI pozostaje zablokowany przez firewall.

Użycie punktu końcowego zgodnego z OpenAI w kodzie

Ollama obsługuje podzbiór API czatu OpenAI pod adresem /v1, dzięki czemu większość bibliotek klienckich OpenAI działa po zmianie dwóch elementów: bazowego adresu URL oraz dowolnego klucza.

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama")

resp = client.chat.completions.create(
    model="llama3.2:3b",
    messages=[{"role": "user", "content": "Name three Linux distributions."}],
)
print(resp.choices[0].message.content)

Wartość api_key jest wymagana przez bibliotekę kliencką, ale ignorowana przez Ollama, więc można użyć dowolnego ciągu znaków. model musi być nazwą modelu, który został już pobrany; nieznana nazwa spowoduje zwrócenie błędu model "x" not found, try pulling it first. Zwykłe wywołanie curl opiera się na tej samej zasadzie:

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Hello"}]}'

W ten sposób można również zintegrować model z narzędziami typu agent lub edytorami. Jeśli programowanie odbywa się bezpośrednio na serwerze, lokalny model może wspierać skrypty i wtyczki obok uruchomionego na VPS wewnątrz tmux Claude Code, co pozwala na tanie i prywatne tworzenie szkiców bez użycia płatnego API, podczas gdy zaawansowane wnioskowanie pozostaje po stronie modelu hostowanego.

Tryby awarii i odpowiadające im komunikaty

Proces zostaje „Killed” w trakcie generowania. Uruchomienie dużego modelu kończy się wyświetleniem przez terminal komunikatu Killed albo wpisem llama runner process has terminated: signal: killed w dzienniku serwera. Linux OOM killer zatrzymał proces, ponieważ model wymagał więcej pamięci RAM, niż jest dostępne na serwerze. Przyczynę można potwierdzić za pomocą sudo dmesg | grep -i oom, gdzie będzie widoczny wpis podobny do Out of memory: Killed process ... (ollama). Rozwiązaniem jest mniejszy lub silniej skwantyzowany model, llama3.2:3b zamiast modelu 13B, albo dodanie swapu. Dzięki temu obciążenie, które tylko nieznacznie przekracza dostępną pamięć fizyczną, zakończy się powoli zamiast awarią. Swap zamienia natychmiastową awarię na powolną odpowiedź; nie sprawia jednak, że model 70B staje się praktyczny na serwerze z 4 GB pamięci. Zakończenie procesu pozostaje niewidoczne, chyba że terminal jest aktualnie monitorowany. Na serwerze sprawdzanym z innego miejsca podłączenie jednostki OnFailure= do ollama.service, która wysyła powiadomienia do własnego serwera ntfy do powiadomień push, informuje o awarii natychmiast, zamiast pozostawiać jej wykrycie dopiero przy następnym żądaniu.

"Error: model requires more system memory". Ollama odmawia uruchomienia modelu i wyświetla Error: model requires more system memory (X GiB) than is available (Y GiB). To uprzejma wersja powyższej awarii: Ollama wykonała obliczenia i zatrzymała się, zamiast pozwolić na interwencję OOM killera. Narzędzie podaje nawet obie wartości. Wybierz model, którego wymagania mieszczą się w dostępnej pamięci RAM (sprawdź za pomocą free -h), zmniejsz długość kontekstu lub przenieś usługę na większy serwer VPS. Żadna flaga nie sprawi, że model zacznie się mieścić w pamięci – wymagania sprzętowe są rzeczywiste.

Pierwszy token pojawia się dopiero po długim czasie, a potem wszystko działa prawidłowo. Zimny model nie zwraca żadnych danych przez pięć do trzydziestu sekund, a następnie strumieniuje odpowiedź normalnie. Przyczyną jest pierwsze wczytywanie wag z dysku do pamięci RAM. Wolny nośnik dodatkowo wydłuża ten proces. Po wczytaniu model pozostaje w pamięci przez czas trwania OLLAMA_KEEP_ALIVE, dlatego druga odpowiedź jest generowana natychmiast. Jeżeli pierwsze wczytywanie trwa dłużej niż limit czasu w którymś miejscu ścieżki żądania, zwracany jest błąd zamiast opóźnionej odpowiedzi. ustalenie, która warstwa zgłosiła przekroczenie terminu kontekstu pozwala określić, czy limit został przekroczony przez klienta, proxy czy samo wczytywanie modelu. W razie potrzeby zwiększ tę wartość, a za pomocą ollama ps sprawdź, czy model jest obecnie wczytany.

Wszystko działa po prostu wolno. Dziesięć tokenów na sekundę lub mniej, bez żadnych błędów. To typowe zachowanie wnioskowania na procesorze (CPU). ollama ps pokazuje 100% CPU, co oznacza brak akceleracji GPU. Nie jest to błąd i żadne ustawienie go nie naprawi, ponieważ ograniczeniem jest przepustowość pamięci, a nie błędna konfiguracja. Użyj mniejszego modelu, zaakceptuj tę prędkość lub przenieś się na instancję z GPU, a przed wyciągnięciem wniosków o awarii zmierz rzeczywistą wydajność za pomocą --verbose.

Błąd "Connection refused" przy próbie połączenia z innej maszyny. Z laptopa otrzymujesz curl: (7) Failed to connect to <ip> port 11434: Connection refused. Jest to działanie zgodne z projektem: Ollama wiąże się wyłącznie z adresem localhost. Nie "naprawiaj" tego poprzez wiązanie z 0.0.0.0, co jest dokładnie tym błędem wystawienia usługi, o którym mowa powyżej. Uzyskaj dostęp do modelu przez VPN lub za pośrednictwem uwierzytelniającego proxy.

Wystawiono port 11434 na świat. Jeśli ustawiono OLLAMA_HOST=0.0.0.0, otwarto zaporę sieciową, a teraz widzisz pobieranie modeli, których nie inicjowałeś, lub procesor jest obciążony w 100% przez nieznanych klientów, oznacza to, że usługa została znaleziona i jest wykorzystywana. To kardynalny błąd, a nie przypadek brzegowy. Zmień powiązanie na 127.0.0.1 lub adres VPN, zamknij port 11434 na zaporze i dodaj warstwę uwierzytelniania. Przyjmij, że każdy, kto miał dostęp do tego adresu w czasie, gdy był on otwarty, mógł wysyłać zapytania do modelu.

Kopie zapasowe i aktualizacje

Ilość danych stanu jest niewielka. Modele można pobrać ponownie, dlatego jedynymi elementami wymagającymi kopii zapasowej są wolumen danych Open WebUI, konta, historia czatów, ustawienia oraz wszelkie utworzone pliki typu drop-in dla systemd. Kopię zapasową wolumenu można wykonać przy użyciu tymczasowego kontenera:

docker run --rm -v open-webui:/data -v "$PWD":/backup alpine \
  tar czf /backup/open-webui.tgz -C /data .

Aktualizację Ollama przeprowadza się poprzez ponowne uruchomienie skryptu instalacyjnego; aktualizację Open WebUI wykonuje się za pomocą docker pull ghcr.io/open-webui/open-webui:main, a następnie odtworzenie kontenera. Nie należy stosować długoterminowego przypinania wersji: jakość modeli oraz środowisko uruchomieniowe zmieniają się dynamicznie, dlatego należy czytać informacje o wydaniach i przeprowadzać własne testy wydajnościowe zamiast polegać na danych z poprzedniego kwartału.

FAQ

Czy naprawdę można uruchomić LLM na VPS bez GPU?

Tak, w określonych granicach. Małe skwantyzowane modele z zakresu od 3B do 8B działają na CPU i są użyteczne do tworzenia szkiców, podsumowań oraz klasyfikacji, choć pracują wolno, osiągając od kilku do kilkunastu tokenów na sekundę na współdzielonym vCPU. Modele od 13B wzwyż działają bardzo wolno lub nie mieszczą się w pamięci RAM. Do uzyskania wysokiej wydajności lub obsługi większych modeli wymagana jest instancja z GPU.

Ile pamięci RAM wymaga dany model?

Przybliżona zasada dla domyślnych modeli skwantyzowanych do 4-bitów: około 0,5 GB RAM na miliard parametrów dla wag, plus około 1 GB narzutu i niewielki zapas na kontekst. Model 3B wymaga około 4 GB wolnej pamięci, model 7-8B około 8 GB, a model 14B około 16 GB. Sprawdź dostępność zasobów za pomocą free -h i pozostaw margines dla systemu operacyjnego oraz innych procesów na serwerze.

Czy API Ollama posiada uwierzytelnianie?

Nie. Ollama nie posiada wbudowanego uwierzytelniania, kluczy API ani limitów zapytań (rate limit). Każdy, kto ma dostęp do portu 11434, ma pełną kontrolę nad usługą. Z tego powodu domyślnie nasłuchuje ona na 127.0.0.1 i dlatego nigdy nie należy wystawiać portu 11434 na 0.0.0.0 do Internetu. Dostęp należy realizować lokalnie, przez prywatny VPN lub poprzez reverse proxy, które doda warstwę logowania.

Jak dodać interfejs czatu WWW?

Uruchom Open WebUI w Dockerze z flagą --network=host, aby współdzielił interfejs loopback hosta i łączył się z natywną usługą Ollama pod adresem http://127.0.0.1:11434, a następnie umieść reverse proxy z terminacją TLS przed portem 8080, aby uzyskać dostęp z komputera lokalnego. Utrzymuj port 8080 zamknięty na firewallu, aby proxy było jedynym publicznym punktem wejścia. Konto administratora Open WebUI zapewnia logowanie, a hasło ustawia się przy pierwszym uruchomieniu.

Jak wywołać model z własnej aplikacji?

Użyj endpointu zgodnego z OpenAI pod adresem http://127.0.0.1:11434/v1. Skieruj dowolny SDK OpenAI na ten bazowy URL, przekaż dowolny ciąg znaków jako klucz API (jest on ignorowany) i ustaw model na nazwę modelu, który został pobrany. Istniejący kod korzystający z OpenAI zazwyczaj działa bez zmian, poza koniecznością aktualizacji bazowego URL oraz klucza.