Ollama na serwerze linuksowym bez monitora — dysk się zapełnia, API nieosiągalne

Partycja / jest pełna, a API odpowiada tylko na localhoście

Autor Jakub Rusinowski

Błąd

Error: write /usr/share/ollama/.ollama/models/blobs/sha256-...: no space left on device

$ curl http://server.local:11434/api/tags
curl: (7) Failed to connect to server.local port 11434: Connection refused

1. 1

   Ustal, co naprawdę zapełnia dysk

   Zanim cokolwiek przeniesiesz, potwierdź, że winowajcą jest katalog modeli, a nie logi czy rozbiegany kontener, i zobacz, co ci się nazbierało. ollama list niemal zawsze ujawnia parę dużych modeli pobranych raz podczas oceniania i nieużywanych od tamtej pory. Ich usunięcie jest natychmiastowe i darmowe.

   bashKopiuj

   # bash
   df -h /
   sudo du -sh /usr/share/ollama/.ollama/models
   sudo du -xh / --max-depth=2 2>/dev/null | sort -rh | head -15
   
   ollama list
   ollama rm llama3.1:70b

   Czy zadziałało?Zwolnione miejsce pojawia się od razu w df -h /, a ollama list nie zawiera już tego modelu.

   bashKopiuj

   df -h / && ollama list

2. 2

   Przenieś katalog na wolumen z danymi i oddaj go użytkownikowi ollama

   Najpierw zatrzymaj usługę — działająca Ollama trzyma uchwyty do plików w katalogu. Przenieś katalog, wykonaj na nim chown na ollama:ollama (to ten krok, który ludzie pomijają, i powód, dla którego usługa potem nie może pisać), ustaw OLLAMA_MODELS przez drop-in systemd, a nie w swojej powłoce, i zrestartuj.

   Uwaga: Sprawdź, czy miejsce docelowe jest kompletne, zanim cokolwiek usuniesz ze źródła. Katalog jest adresowany treścią, więc częściowo przeniesiona kopia wygląda strukturalnie poprawnie i zawodzi wyłącznie na tych modelach, których bloby nie dotarły.

   bashKopiuj

   # bash
   sudo systemctl stop ollama
   sudo mkdir -p /data/ollama-models
   sudo rsync -a --info=progress2 /usr/share/ollama/.ollama/models/ /data/ollama-models/
   sudo chown -R ollama:ollama /data/ollama-models
   
   sudo systemctl edit ollama.service
   # [Service]
   # Environment="OLLAMA_MODELS=/data/ollama-models"
   
   sudo systemctl daemon-reload && sudo systemctl start ollama
   ollama list

   Czy zadziałało?Wszystkie modele są nadal wypisywane, a świeże pobranie ląduje na wolumenie z danymi. Dopiero wtedy usuń stary katalog.

   bashKopiuj

   ollama list
   ollama pull gemma3:1b
   sudo du -sh /data/ollama-models
   sudo ls /usr/share/ollama/.ollama/models/blobs | wc -l

3. 3

   Zajmij się szczegółami utwardzonego serwera: noexec na /tmp i proxy

   Dwie rzeczy gryzą szczególnie na serwerach zbudowanych według standardu utwardzania. Jeśli /tmp jest zamontowany z noexec, Ollama nie może wykonywać kodu ze swojego katalogu tymczasowego i zawodzi w sposób wyglądający na uszkodzenie plików; OLLAMA_TMPDIR kieruje ją tam, gdzie wolno jej to robić. A za firmowym proxy zmienną, którą Ollama czyta, jest HTTPS_PROXY, a nie HTTP_PROXY — rejestr działa po HTTPS, a forma pisana małymi literami po prostu nie jest sprawdzana.

   bashKopiuj

   # bash — is /tmp noexec?
   mount | grep -E ' /tmp '
   
   sudo mkdir -p /var/tmp/ollama && sudo chown ollama:ollama /var/tmp/ollama
   sudo systemctl edit ollama.service
   # [Service]
   # Environment="OLLAMA_TMPDIR=/var/tmp/ollama"
   # Environment="HTTPS_PROXY=http://proxy.internal:3128"
   
   sudo systemctl daemon-reload && sudo systemctl restart ollama

   Czy zadziałało?Pobranie przechodzi przez proxy, a w logu nie ma błędów o uprawnieniach do wykonywania.

   bashKopiuj

   ollama pull gemma3:1b && journalctl -u ollama --no-pager -n 20

4. 4

   Wybierz sposób udostępnienia API — w tej kolejnościNajczęstsze rozwiązanie

   OLLAMA_HOST=0.0.0.0:11434 wystawia API bez żadnego uwierzytelniania. Każdy, kto dosięgnie portu, może liczyć na twoim GPU i pobierać modele na twój dysk, a otwarty endpoint w publicznym internecie jest gorszy, niż brzmi: nieuwierzytelnione, wielogigabajtowe zapisy, nierozliczana moc obliczeniowa i żadnego śladu, kto z niej korzystał. W kolejności, w jakiej je polecamy: (1) tunel SSH — nic nie jest wystawione, działa od zaraz, a klient nadal rozmawia z localhost; (2) reverse proxy z uwierzytelnianiem i TLS-em kończonym na proxy, przy Ollamie wciąż przypiętej do pętli zwrotnej; (3) bindowanie na adres interfejsu VPN albo Tailscale zamiast 0.0.0.0, żeby dosięgła go tylko sieć prywatna; (4) 0.0.0.0 z zaporą ograniczoną do konkretnych adresów źródłowych, w sieci lokalnej, którą administrujesz — a „zaufana” znaczy, że znasz każde urządzenie w niej, a nie że stoi u ciebie w domu.

   bashKopiuj

   # bash — (1) SSH tunnel, from the CLIENT machine
   ssh -N -L 11434:127.0.0.1:11434 you@server.example.com
   curl http://localhost:11434/api/tags
   
   # (3) Bind to a Tailscale address only, never 0.0.0.0
   # [Service]
   # Environment="OLLAMA_HOST=100.101.102.103:11434"

   Czy zadziałało?Przy tunelu klient sięga do API po własnym localhoście, a ss na serwerze wciąż pokazuje Ollamę nasłuchującą wyłącznie na 127.0.0.1.

   bashKopiuj

   ss -ltnp | grep 11434

   Sprawdź, co pasuje do Twojego sprzętudobierz modele na współdzielonym serwerze do VRAM-u, który naprawdę maszOtwórz kalkulator VRAM →
5. 5

   Postaw z przodu reverse proxy zamiast otwierać port

   Dla czegokolwiek więcej niż jedna osoba właściwym kształtem jest reverse proxy: Ollama zostaje na pętli zwrotnej, proxy trzyma certyfikat i dane uwierzytelniające, a ty dostajesz log dostępu — czego otwarty port ci nie daje. Caddy to dwie linijki. Przy okazji zachowaj domyślne OLLAMA_HOST równe 127.0.0.1: proxy łączy się lokalnie, więc nie ma żadnego powodu, by port w ogóle wystawiać.

   bashKopiuj

   # Caddyfile — TLS and basic auth in front of a loopback-bound Ollama
   # ollama.example.com {
   #     basic_auth {
   #         alice $2a$14$...   # caddy hash-password
   #     }
   #     reverse_proxy 127.0.0.1:11434
   # }
   
   # bash
   sudo systemctl reload caddy
   curl -u alice:secret https://ollama.example.com/api/tags

   Czy zadziałało?Żądanie z danymi uwierzytelniającymi przechodzi, a bez nich zostaje odrzucone, przy czym Ollama jest wciąż przypięta do 127.0.0.1.

   bashKopiuj

   curl -s -o /dev/null -w "%{http_code}\n" https://ollama.example.com/api/tags
   ss -ltnp | grep 11434

6. 6

   Dostrój keep-alive, równoległość i liczbę modeli do współdzielonej maszyny

   Trzy wartości domyślne to wartości laptopowe. OLLAMA_KEEP_ALIVE wynosi 5 minut, więc pierwsze żądanie po ciszy płaci pełny czas ładowania — podniesienie tej wartości trzyma model ciepłym, kosztem trzymania jego VRAM-u przez cały czas, co na współdzielonej karcie jest realnym kompromisem. OLLAMA_NUM_PARALLEL wynosi 1 żądanie na model, więc równocześni użytkownicy stoją w kolejce. OLLAMA_MAX_LOADED_MODELS to trzykrotność liczby kart GPU (3 na CPU), a każdy jednocześnie załadowany model trzyma własne wagi i własny cache KV. Podnoś te wartości względem zmierzonego wolnego VRAM-u, a nie optymizmu: każde równoległe gniazdo potrzebuje własnego cache'u KV, więc podwojenie równoległości potrafi kosztować więcej pamięci niż załadowanie drugiego modelu.

   bashKopiuj

   # bash
   sudo systemctl edit ollama.service
   # [Service]
   # Environment="OLLAMA_KEEP_ALIVE=30m"
   # Environment="OLLAMA_NUM_PARALLEL=4"
   # Environment="OLLAMA_MAX_LOADED_MODELS=2"
   
   sudo systemctl daemon-reload && sudo systemctl restart ollama
   journalctl -u ollama -f

   Czy zadziałało?Pod obciążeniem ollama ps nadal pokazuje umieszczenie na GPU, a nie podział, a VRAM ma zapas.

   bashKopiuj

   ollama ps
   nvidia-smi --query-gpu=memory.used,memory.total --format=csv