Ollama na VPS: bezpieczne uruchamianie modelu 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ęć to w przybliżeniu jego rozmiar pliku, plus około gigabajta narzutu środowiska uruchomieniowego, oraz dodatkowa przestrzeń na okno kontekstowe. Domyślne tagi większości popularnych modeli Ollama, w tym llama3.2:3b, llama3.1:8b oraz mistral:7b, są kwantyzowane do 4 bitów (oznaczenie Q4_K_M), co wymaga około pół gigabajta pamięci RAM na każdy miliard parametrów. Nie każdy model domyślny jest w formacie Q4: bardzo małe modele, takie jak smollm2:135m, są dostarczane w 16 bitach, dlatego przed wykonaniem obliczeń należy sprawdzić wiersz kwantyzacji na stronie biblioteki modelu. Arytmetyka jest prosta i to ona o wszystkim decyduje. Ostatni składnik to wartość definiowana samodzielnie: zwiększenie num_ctx powyżej domyślnej, niskiej wartości Ollama pozwala na dłuższe prompty, ale zwiększa rozmiar pamięci podręcznej KV w RAM, więc przed oceną, czy model się zmieści, należy ustalić długość kontekstu.

Model 3B, taki jak llama3.2:3b, to pobranie około 2 GB danych i zapotrzebowanie na 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 RAM, przy czym 16 GB zapewnia komfortową pracę. Model 13B lub 14B wymaga około 16 GB RAM. Każdy model z zakresu 30B-70B wymaga serwera z dużą ilością pamięci RAM lub, realistycznie rzecz biorąc, karty graficznej; na VPS z samym CPU taki model albo się nie uruchomi, albo będzie odpowiadał tak wolno, że stanie się bezużyteczny.

Teraz kwestia szybkości, ponieważ jest to element często niedoceniany. Inferencja na CPU jest ograniczona przepustowością pamięci, a nie taktowaniem procesora, a współdzielony VPS z vCPU ma 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 jest mniej więcej o rząd wielkości szybsza. Są to wartości przybliżone; uczciwym podejściem jest samodzielny pomiar na własnym serwerze, co opisano w kroku uruchomienia poniżej. Należy ufać własnym wynikom eval rate, a nie liczbom z jakiegokolwiek artykułu, w tym tego.

Wniosek praktyczny: małe, kwantyzowane modele na CPU są użyteczne do tworzenia szkiców, podsumowań i klasyfikacji, jeśli akceptowalna jest niska prędkość działania. W przypadku zadań wymagających większej skali lub szybkości należy zaplanować budżet na instancję z GPU. Jeśli potrzebne jest prześledzenie tych obliczeń na przykładzie konkretnego modelu, artykuł uruchamianie Nemotron 3.5 Lightning na VPS wyjaśnia, który tag pobrać, ile pamięci RAM faktycznie potrzeba oraz czy konfiguracja oparta wyłącznie na CPU jest wystarczająca.

Aby porównać konkretny model z konkretnym serwerem, 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.

Uruchamianie jako kontrolowana usługa

Skrypt instalacyjny zarejestrował już ollama.service, więc usługa restartuje się automatycznie po uruchomieniu systemu bez dodatkowych działań. Ustawieniem wartym zmiany jest 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 ładowania wag; ustaw 0 na maszynie z ograniczonymi zasobami, aby zwolnić pamięć RAM natychmiast po zakończeniu żądania. Jeśli model ma pozostać w pamięci na stałe, a nie przez określony czas, artykuł utrzymywanie modelu Ollama w pamięci na stałe opisuje pole keep_alive dla poszczególnych żądań oraz sposób ponownego ładowania wag po restarcie, co eliminuje opóźnienie przy pierwszym zapytaniu. systemctl edit przeładowuje pliki jednostek, więc zrestartuj usługę, aby zastosować zmiany:

sudo systemctl restart ollama

Najważniejsza kwestia bezpieczeństwa

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

API nie posiada żadnego mechanizmu uwierzytelniania. Żadnego. Nie ma klucza API, logowania ani limitów zapytań. Jedyna dostępna lista dozwolonych adresów, OLLAMA_ORIGINS, kontroluje jedynie, które źródła w przeglądarce mogą wywoływać API (CORS); nie blokuje ona narzędzi typu curl ani skryptów uruchomionych na innych maszynach. Każdy, kto ma dostęp do portu 11434, może uruchomić dowolny pobrany model, pobrać nowe, usunąć je oraz obciążyć procesor lub kartę graficzną w 100% na dowolny czas. Skanery takie jak Shodan indeksują tysiące otwartych instancji Ollama, a wystawiona na świat instancja zostaje znaleziona i wykorzystana w ciągu kilku godzin.

Oto jeden błąd, którego nigdy nie wolno popełnić: nie należy ustawiać OLLAMA_HOST=0.0.0.0 i otwierać portu 11434 w firewallu. Powoduje to wystawienie nieuwierzytelnionego serwera wnioskowania (inference server) na cały internet. Żadna konfiguracja nie uczyni surowego portu 11434 na 0.0.0.0 bezpiecznym, ponieważ żadne z udokumentowanych ustawień Ollama nie dodaje uwierzytelniania do lokalnego API, a lista dozwolonych źródeł nie jest mechanizmem logowania. Jest to zasada dotycząca tej konkretnej usługi, a nie zakaz otwierania portów w ogóle: własny przekaźnik RustDesk do zdalnego pulpitu musi przyjmować ruch publiczny, aby działać, co jest uzasadnione posiadaniem własnego uwierzytelniania opartego na kluczach oraz krótką, udokumentowaną listą portów, czego Ollama nie posiada.

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 i wywoływać API przez 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), dzięki czemu tylko węzły VPN będą mogły się połączyć. Publiczny internet nadal nie widzi żadnego ruchu na porcie 11434.
• Umieszczenie przed usługą reverse proxy z uwierzytelnianiem. Należy zakończyć połączenie TLS i wymagać hasła lub tokena w nginx, Traefik lub Caddy, a następnie przekierować ruch do 127.0.0.1:11434. Ollama zachowuje powiązanie z localhost; proxy jest jedynym komponentem nasłuchującym na publicznym porcie. Jest to rozwiązanie analogiczne do umieszczenia certyfikatu Let's Encrypt w nginx przed dowolną usługą lokalną.

Opcja z reverse proxy jest dokładnie tym, co oferuje interfejs czatu w kolejnym kroku, wraz z dołączonym 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 Linux VPS. 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. Spotykana w innych poradnikach metoda z siecią typu bridge, --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, a usługa powiązana z 127.0.0.1 na hoście nie jest osiągalna przez bridge, przez co Open WebUI zgłasza brak połączenia z Ollama.

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

Aby otworzyć czat z laptopa przez HTTPS, należy umieścić TLS reverse proxy przed 127.0.0.1:8080. Jeśli na serwerze działa 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. Taki sam model routingu oparty na etykietach dla każdej aplikacji jest stosowany przez wszystkie inne interfejsy przeglądarkowe na serwerze, niezależnie od tego, czy jest to pulpit nawigacyjny, czy coś bardziej rozrywkowego, jak Halcyon, prezentujący bibliotekę Jellyfin w stylu wypożyczalni kaset z lat 90., gdzie każda usługa posiada własną nazwę hosta i własny mechanizm logowania. Zasada z sekcji bezpieczeństwa pozostaje aktualna: proxy obsługuje port publiczny i logowanie, podczas gdy Ollama pozostaje na localhost, a port 8080 używany przez 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: adresu bazowego (base 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)

Parametr api_key jest wymagany przez bibliotekę kliencką, ale ignorowany przez Ollama, więc można użyć dowolnego ciągu znaków. Wartość model musi odpowiadać nazwie modelu, który został już pobrany; nieznana nazwa spowoduje błąd 404 z komunikatem model 'x' not found. Zwykłe wywołanie curl działa 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, podobnie jak Claude Code uruchomiony na VPS wewnątrz tmux, co pozwala na wykonywanie tanich, prywatnych zadań roboczych poza płatnym API, podczas gdy zaawansowane wnioskowanie pozostaje po stronie modelu hostowanego.

Tryby awarii z dokładnymi komunikatami

Proces zostaje „Killed” w trakcie generowania. Uruchamiany jest duży model, a terminal wyświetla Killed albo dziennik serwera (journalctl -u ollama) zawiera wiersz zaczynający się od llama-server process has terminated. Jest to komunikat używany w Ollama 0.40.7, sprawdzony 21 October 2026; starsze wydania wyświetlały llama runner process has terminated: signal: killed. Linux OOM killer zatrzymał proces, ponieważ model wymagał więcej RAM niż jest dostępne na serwerze. Przyczynę można potwierdzić za pomocą sudo dmesg | grep -i oom, gdzie pojawi się wiersz podobny do Out of memory: Killed process .... Rozwiązaniem jest mniejszy lub silniej skwantyzowany model, llama3.2:3b zamiast 13B, albo dodanie swapu, aby obciążenie, które tylko nieznacznie przekracza fizyczny RAM, mogło zakończyć się powoli zamiast awarią. Swap zamienia natychmiastową awarię na powolną odpowiedź; nie sprawia, że model 70B staje się praktyczny przy 4 GB. Zakończenie procesu jest niewidoczne, chyba że monitorowany jest terminal. Dlatego na serwerze odpytywanym z innego miejsca dołączenie jednostki OnFailure= do ollama.service, która wysyła komunikaty do własnego serwera ntfy do powiadomień push, pozwala wykryć awarię od razu zamiast dopiero przy następnym żądaniu.

Ollama odmawia załadowania modelu. Żądanie natychmiast kończy się błędem zamiast awarią, a dziennik serwera zapisuje model is too large for system memory (Ollama 0.40.7, sprawdzone 21 October 2026). Starsze wydania wyświetlały Error: model requires more system memory (X GiB) than is available (Y GiB) bezpośrednio w wierszu polecenia. Jest to kontrolowana wersja opisanej wyżej awarii: Ollama oblicza wymagania i zatrzymuje działanie, zamiast pozostawiać to OOM killerowi. Należy wybrać model, którego wymagania są mniejsze niż dostępny RAM (sprawdź za pomocą free -h), zmniejszyć długość kontekstu albo przenieść usługę na większy VPS. Żadna flaga nie sprawi, że model zmieści się w pamięci, ponieważ wymagana pamięć jest rzeczywista.

Pierwszy token pojawia się bardzo długo, a potem wszystko działa poprawnie. Zimny model przez pięć do trzydziestu sekund niczego nie wyświetla, a następnie zaczyna normalnie przesyłać odpowiedź. Jest to czas ładowania wag z dysku do RAM przy pierwszym użyciu. Wolny magazyn danych dodatkowo wydłuża ten etap. Po załadowaniu model pozostaje w pamięci przez czas OLLAMA_KEEP_ALIVE, dlatego druga odpowiedź pojawia się natychmiast. Jeśli pierwsze ładowanie trwa dłużej niż limit czasu w którymś miejscu ścieżki żądania, pojawia się błąd zamiast powolnej odpowiedzi. Ustalenie, która warstwa zgłosiła przekroczenie terminu kontekstu pozwala określić, czy limit przekroczył klient, proxy czy samo ładowanie. W razie potrzeby należy zwiększyć tę wartość. Za pomocą ollama ps można sprawdzić, czy model jest obecnie załadowany.

Wszystko działa po prostu wolno. Odpowiedź ma dziesięć tokenów na sekundę lub mniej, bez żadnego błędu. Jest to wnioskowanie na CPU, które działa zgodnie ze specyfiką wnioskowania na CPU. ollama ps wyświetla 100% CPU, co oznacza brak GPU. Nie jest to błąd. Żadne ustawienie nie zamieni CPU w GPU, ponieważ głównym ograniczeniem jest przepustowość pamięci. Jedno ustawienie warto jednak przetestować na maszynie wirtualnej: Ollama wybiera liczbę wątków na podstawie wykrytych rdzeni fizycznych, a hypervisor może zgłaszać ich nieprawidłową liczbę. W sesji ollama run --verbose należy wypróbować /set parameter num_thread 4 (albo liczbę vCPU), ponownie wykonać to samo żądanie i pozostawić wartość zapewniającą najlepszy eval rate. Poza tym należy użyć mniejszego modelu, zaakceptować tę szybkość albo przejść na instancję GPU. Przed uznaniem, że coś jest uszkodzone, należy zmierzyć rzeczywistą szybkość za pomocą --verbose. Jeśli oczekiwanie wynika z długości odpowiedzi, a nie z szybkości generowania, ograniczenie odpowiedzi za pomocą num_predict uniemożliwia modelowi, który ma tendencję do rozwlekłych odpowiedzi, generowanie przez wiele minut tokenów, których i tak nie zostanie odczytanych.

Z innego komputera pojawia się „Connection refused”. Z laptopa bieżący curl (8.23.0, sprawdzony 21 October 2026) wyświetla curl: (7) Failed to connect to <ip>:11434 after <n> ms: Could not connect to server, a curl 8.5.0 dostarczany z Ubuntu 24.04 wyświetla curl: (7) Failed to connect to <ip> port 11434 after <n> ms: Couldn't connect to server. Słowa „Connection refused” pojawiają się dopiero po dodaniu -v, w wierszu connect to <ip> port 11434 from ... failed: Connection refused. Jest to działanie zgodne z przeznaczeniem: Ollama nasłuchuje wyłącznie na localhost. Nie należy „naprawiać” tego przez nasłuchiwanie na 0.0.0.0, ponieważ byłby to dokładnie opisany wyżej błąd polegający na wystawieniu usługi. Model należy udostępniać przez VPN albo przez proxy uwierzytelniające.

Port 11434 został wystawiony do Internetu. Jeśli ustawiono OLLAMA_HOST=0.0.0.0, otwarto firewall i obecnie widoczne są pobrania modeli, których nie uruchomiono, albo użycie CPU jest utrzymywane na poziomie 100% przez nieznanych klientów, oznacza to, że serwer został znaleziony i wykorzystany. Jest to podstawowy błąd, a nie rzadki przypadek brzegowy. Należy ponownie powiązać usługę z 127.0.0.1 albo adresem VPN, zamknąć port 11434 na firewallu i umieścić uwierzytelnianie przed usługą. Należy założyć, że wszystko, co było dostępne pod tym adresem podczas jego otwarcia, zostało odpytywane przez osoby postronne.

Kopie zapasowe i aktualizacje

Stan aplikacji jest minimalny. Modele można pobrać ponownie, więc jedynymi danymi wymagającymi kopii zapasowej są wolumen danych Open WebUI, konta, historia czatów, ustawienia oraz wszelkie utworzone pliki typu drop-in dla systemd. Wykonaj kopię zapasową wolumenu przy użyciu tymczasowego kontenera:

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

Zaktualizuj Ollama poprzez ponowne uruchomienie skryptu instalacyjnego; zaktualizuj Open WebUI za pomocą docker pull ghcr.io/open-webui/open-webui:main, a następnie odtwórz kontener. Uwaga dotycząca miejsca na dysku dla linii 0.40: Ollama 0.40.2 rozpoczęła aktualizację modeli pobranych we wcześniejszych wersjach w tle, zachowując oryginalne kopie jako kopie zapasowe. Zajmują one dodatkowe miejsce na dysku do momentu usunięcia, a wersja 0.40.3 (11 października 2026) wstrzymała tę aktualizację w tle. Sprawdź df -h po aktualizacji i zapoznaj się z informacjami o wydaniu, aby poznać polecenie usuwające te kopie zapasowe. Nie przypinaj wersji na stałe: jakość modeli oraz środowisko uruchomieniowe zmieniają się dynamicznie, dlatego należy czytać informacje o wydaniu i przeprowadzać własne testy wydajnościowe zamiast polegać na wynikach 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 prędkość od kilku do kilkunastu tokenów na sekundę na współdzielonym vCPU. Modele od 13B wzwyż działają bardzo wolno lub w ogóle 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 potrzebuje dany model?

Przybliżona zasada dla 4-bitowych (Q4) kwantyzacji, najpopularniejszych dla większości modeli, wynosi około 0,5 GB RAM na miliard parametrów dla wag, plus około 1 GB narzutu i dodatkowa przestrzeń 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. Należy sprawdzić dostępność zasobów za pomocą free -h i pozostawić zapas dla systemu operacyjnego oraz pozostałych 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, posiada pełną kontrolę nad usługą. Ustawienie OLLAMA_ORIGINS ogranicza jedynie źródła żądań z przeglądarki, a nie to, kto może nawiązać połączenie. Z tego powodu usługa domyślnie nasłuchuje na 127.0.0.1 i pod żadnym pozorem nie należy wystawiać portu 11434 na 0.0.0.0 do Internetu. Należy łączyć się lokalnie, przez prywatny VPN lub poprzez reverse proxy, które doda warstwę logowania.

Jak dodać interfejs czatu WWW?

Należy uruchomić Open WebUI w Dockerze z flagą --network=host, aby współdzielił interfejs loopback hosta i mógł połączyć się z natywną usługą Ollama pod adresem http://127.0.0.1:11434, a następnie umieścić reverse proxy z terminacją TLS przed portem 8080, aby uzyskać dostęp z urządzenia zewnętrznego. Należy pozostawić port 8080 zamknięty na firewallu, aby proxy było jedynym publicznym punktem dostępowym. Konto administratora Open WebUI zapewnia logowanie, a hasło ustawia się przy pierwszym uruchomieniu.

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

Należy użyć endpointu zgodnego z OpenAI pod adresem http://127.0.0.1:11434/v1. W dowolnym SDK OpenAI należy wskazać ten adres jako bazowy URL, przekazać dowolny ciąg znaków jako klucz API (jest on ignorowany) oraz ustawić model na nazwę pobranego modelu. Istniejący kod korzystający z OpenAI zazwyczaj działa bez zmian, poza koniecznością aktualizacji bazowego URL oraz klucza.