Samodzielnie hostuj Ollama na serwerze LLM i przejmij kontrolę nad cenzurą AI

Słowa kluczowe

Zanim przejdziesz do konfiguracji, oto terminy, które najprawdopodobniej mogą być mylące dla czytelników tego przewodnika. Ten szybki słownik wyjaśnia terminologię Linux, GPU i modeli lokalnych od samego początku.

Dlaczego warto samodzielnie hostować LLM

Jeśli już wykonałeś trudną część — wynająłeś serwer GPU, zainstalowałeś Ubuntu, nauczyłeś się poruszać po SSH i utrzymujesz własne usługi — szybko staje się frustrujące, gdy hostowana AI nadal kontroluje ostatnią milę. Może odrzucić całkowicie zwykłe żądanie, ukryć odpowiedź pod zastrzeżeniami, zmienić styl odpowiedzi bez ostrzeżenia i utrzymać każdy prompt przepływający przez czyjąś granicę. Dla wielu użytkowników technicznych to jest prawdziwa frustracja: nie tylko to, co mówi model, ale kto kontroluje warstwę serwowania, gdy to mówi.

Ten przewodnik dotyczy naprawy tego za pomocą otwartych i lokalnych modeli, a nie sztuczek obejścia dla zastrzeżonych API. Będziesz samodzielnie hostować Ollama na serwerze Ubuntu GPU, uruchamiać wnioskowanie lokalnie, weryfikować, że ścieżka GPU jest rzeczywista, i zobaczyć, co się zmienia, gdy wybierzesz inną rodzinę modeli. Jedno nieporozumienie do wyjaśnienia na wstępie: samodzielnie hostowany nie oznacza automatycznie nieograniczony. Oznacza to, że kontrolujesz znacznie więcej stosu — i przestajesz zależeć od ścieżki serwowania kontrolowanej przez dostawcę — ale model, który uruchamiasz, może nadal mieć własne zachowanie wyrównania.

📝 Uwaga: Polecenia w tym przewodniku są zweryfikowane względem bieżącej dokumentacji Ollama, ale wyjścia terminala pokazane poniżej są reprezentatywnymi przykładami, a nie przechwytywaniem benchmarku na żywo. Używaj ich jako wzorca sukcesu, a nie jako roszczenia wydajności.

Na koniec będziesz mieć działającą usługę Ollama na Ubuntu, zweryfikowany lokalny API na 127.0.0.1:11434, dowód, że wnioskowanie wspierane GPU faktycznie się dzieje, i ugruntowane porównanie między głównym wyrównanym modelem a mniej restrykcyjną alternatywą. Ten samouczek jest napisany dla czytelników, którzy czują się komfortowo z SSH, Ubuntu, sudo i systemd, ale którzy nie potrzebują wcześniejszego doświadczenia z Ollama.

Dokładny serwer GPU Ubuntu używany w tym przewodniku

Ten przewodnik jest zakotwiczony w rzeczywistej maszynie Ubuntu z jednym GPU, ponieważ niejasne porady “powinno działać na większości serwerów” to sposób, w jaki przewodniki samodzielnego hostowania stają się mylące. Pole odniesienia tutaj to rzeczywista klasa hosta używana w tym przewodniku: rodzaj maszyny, którą wynajęłaby zaawansowana osoba, laboratorium lub mały zespół, gdy chcą prywatnego lokalnego wnioskowania bez przechodzenia bezpośrednio do stojaków akceleratorów korporacyjnych. Będzie to nadal omawiać zachowanie wielu GPU później, ponieważ Ollama zmienia się, gdy model przerastnie jedną kartę, ale traktuj tę część jako kontekst skierowany w przyszłość, a nie jako dowód z tego dokładnego serwera.

Serwer GPU — Ryzen 9 3950X + RTX 4070 Ti Super

W praktyce jest to bardzo silna konfiguracja dla codziennych modeli klasy 8B i nadal przydatna dla większej pracy lokalnej do punktu, w którym 16GB VRAM staje się rzeczywistym ograniczeniem. Model taki jak llama3.1:8b o rozmiarze około 4,9GB łatwo mieści się na tej karcie. Model taki jak gpt-oss:20b o rozmiarze około 14GB to rodzaj testu na górnym końcu pojedynczego GPU, który nadal ma sens tutaj. Model taki jak qwen3:30b o rozmiarze około 19GB lepiej traktować jako punkt odniesienia dla tego, co zmienia się na większym lub dwu-GPU hoście, niż jako czysty pasuje do tej dokładnej maszyny.

To rozróżnienie ma znaczenie, ponieważ celem tego artykułu nie jest wciśnięcie największej możliwej liczby w nagłówek. Chodzi o pokazanie, jak wygląda rozsądny samodzielnie hostowany serwer LLM, gdy chcesz prywatności, lokalnej kontroli i wystarczającej pamięci GPU do uruchamiania użytecznych modeli bez ciągłych kompromisów. Ta klasa sprzętu to miejsce, gdzie samodzielne wnioskowanie staje się realistyczne, a nie teoretyczne.

Wyjaśnia to również kilka wyborów, które zobaczysz później: mistral jest używany najpierw, ponieważ daje szybki, niskofrykcyjny dowód, że stos działa, podczas gdy porównanie zachowania pozostaje w klasie 8B, gdzie ta maszyna czuje się komfortowo. qwen3:30b nadal pojawia się później, ale jako teoretyczny przykład rodzaju modelu, który może wyzwolić umieszczenie wielu GPU na większym hoście, a nie jako żywy dowód z tego serwera. Mając ustalone oczekiwania, następnym krokiem jest walidacja hosta przed dotknięciem go przez Ollama.

Uruchom te kontrole przed instalacją Ollama

Zacznij od nvidia-smi. Jeśli ta komenda jest niedostępna lub się nie powiedzie, zatrzymaj się tutaj i najpierw napraw sterownik NVIDIA. Nie instaluj jeszcze Ollama, ponieważ uszkodzony stos NVIDIA sprawi, że każdy późniejszy objaw będzie wyglądać jak błąd aplikacji, podczas gdy naprawdę jest to błąd platformy.

Najpierw uruchom kontrolę GPU:

nvidia-smi

❗Jeśli Ubuntu mówi, że nvidia-smi jest niedostępne, nie zakładaj, że serwer nie ma GPU. Częstym błędem na wynajmowanych maszynach Ubuntu jest to, że karta jest obecna, ale wciąż przypisana do nouveau zamiast sterownika NVIDIA. Najpierw sprawdź sekcję “Napraw problem sterownika Nvidia na Ubuntu“.

Zdrowy wynik na tej klasie serwera powinien wyglądać mniej więcej tak:

Gdy nvidia-smi działa i GPU jest widoczne, kontynuuj z poniższymi kontrolami.

To, co chcesz potwierdzić, jest proste: zainstalowany GPU jest widoczny, zgłasza mniej więcej 16GB VRAM na tym hoście, a sterownik jest załadowany czyszczenie. Jeśli jesteś na serwerze z wieloma GPU, ta sama komenda powinna wyświetlić każdą kartę.

nvidia-smi -L

❗ Ważne: Aktualna dokumentacja obsługi GPU Ollama używa sterownika NVIDIA 531+ jako rzeczywistego minimum dla obsługiwanego wnioskowania NVIDIA. Traktuj 531+ jako wymóg dla tego przewodnika, nawet jeśli widziałeś starsze notatki społeczności cytujące niższe wersje.

Teraz potwierdź, że host naprawdę jest środowiskiem Ubuntu, które zakłada ten przewodnik:

lsb_release -a

Na koniec sprawdź wolne miejsce na dysku przed rozpoczęciem pobierania modeli. Sama instalacja jest mała; modele nie są. Gdy przejdziesz poza małe testy, biblioteka 20B-30B może szybko zjeść dziesiątki gigabajtów, więc 100GB+ wolnego miejsca to właściwe podejście przed poważną pracą z modelami lokalnymi.

df -h /

Jeśli te kontrole przejdą, wyjaśniłeś główne niewiadome infrastruktury: GPU są obecne, linia bazowa sterownika jest rozsądna, Ubuntu jest potwierdzone, a dysk ma miejsce na rzeczywiste pobieranie modeli. To punkt, w którym instalacja Ollama staje się czystym następnym krokiem zamiast zgadywanką.

Napraw problem sterownika Nvidia na Ubuntu

Wykonaj poniższe kroki, aby naprawić problemy z komendą “nvidia-smi”.

lspci -nnk | grep -A3 -Ei 'VGA|3D|NVIDIA'

Jeśli to wyjście pokazuje kartę NVIDIA i linię taką jak Kernel driver in use: nouveau, zainstaluj zalecany pakiet sterownika Ubuntu zamiast instalowania samego nvidia-utils.

Zainstaluj pakiet ubuntu-drivers-common (potrzebny do zarządzania sterownikami) i nagłówki jądra dla aktualnie uruchomionego jądra.

apt update
apt install -y ubuntu-drivers-common linux-headers-$(uname -r)

Przeskanuj system i wyświetl listę dostępnych sterowników własnościowych (np. sterowniki GPU NVIDIA), które można zainstalować.

ubuntu-drivers devices

Następnie zainstaluj zalecany pakiet sterownika. W naszym przypadku był to: nvidia-driver-595-open:

apt install -y nvidia-driver-595-open
reboot

Po ponownym uruchomieniu uruchom ponownie:

nvidia-smi
nvidia-smi -L

Zainstaluj Ollama i potwierdź, że usługa jest w dobrej kondycji

Obsługiwana ścieżka Ubuntu to oficjalny instalator Ollama, a nie niestandardowy przepływ tarball ani obejście Docker. To ma znaczenie, ponieważ ten przewodnik dotyczy uzyskania niezawodnej usługi lokalnej z przewidywalnymi ustawieniami domyślnymi, integracją systemd i rozsądnym zachowaniem własności na Linuksie.

Uruchom instalator dokładnie tak, jak udokumentowano:

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

W zdrowym systemie skrypt instaluje plik binarny, tworzy użytkownika usługi ollama, dodaje prawidłowe członkostwa w grupach, gdy są dostępne, zapisuje jednostkę systemd i uruchamia usługę powiązaną z 127.0.0.1:11434.

Po zakończeniu skryptu zweryfikuj usługę zamiast zakładać sukces:

sudo systemctl status ollama --no-pager

Szukasz tutaj trzech rzeczy: plik jednostki jest obecny, usługa jest włączona do rozruchu i Active: active (running) potwierdza, że serwer jest faktycznie uruchomiony.

Najpierw ustanów konto użytkownika usługi Linux w konkretny sposób, a dopiero potem myśl o tym, jak i gdzie będzie przechowywana pamięć modelu.

getent passwd ollama

Ta pojedyncza linia wyjaśnia wiele przyszłych zachowań. Modele na Linuksie znajdują się pod własnością usługi, a jeśli później przeniesiesz je na inny dysk bez naprawienia uprawnień dla użytkownika ollama, stworzysz własne uszkodzenie.

Jeszcze jedna kontrola zamyka pętlę na domyślnym wiązaniu:

ss -tlnp | grep 11434

⚠️ Ostrzeżenie: Ollama domyślnie nie wymaga uwierzytelniania w lokalnym API. To jest w porządku, gdy jest powiązane z 127.0.0.1, ale nie jest bezpieczne bezpośrednio eksponować port 11434 do internetu, tak jakby była to wzmocniona usługa publiczna.

Jeśli usługa nie uruchomi się czyszczej, przejdź najpierw do dzienników zamiast ślepo przeinstalowywać:

journalctl -u ollama -n 100 --no-pager

To najszybszy sposób na wychwycenie problemów z uprawnieniami, błędów uruchamiania, problemów z wykrywaniem sterowników lub problemów z wiązaniem. Po uzdrownieniu usługi na localhost, następną rzeczą do zrozumienia jest zachowanie umieszczania GPU w czasie wykonywania.

Jak Ollama faktycznie wykorzystuje jeden lub wiele GPU

Mimo że serwer użyty w tym przewodniku ma jeden GPU, warto zrozumieć zachowanie wielu GPU, ponieważ wielu użytkowników może mieć większe serwery lub może się rozwijać później. Wiele zamieszania związanego z dwoma GPU zaczyna się od błędnego oczekiwania: “Mam dwie karty, więc obie powinny być aktywne przez cały czas.” Tak nie działa Ollama. Praktyczna zasada jest znacznie prostsza: jeśli model zmieści się na jednym GPU, Ollama zwykle będzie go trzymać na jednym GPU. Rozprowadza go na wiele GPU tylko wtedy, gdy model nie zmieści się wygodnie na jednej karcie.

Używaj tych dwóch kontroli razem, gdy chcesz zobaczyć wydajność GPU:

ollama ps

watch -n 1 nvidia-smi

ollama ps pokazuje, jak załadowany model jest przetwarzany. 100% GPU oznacza, że model jest w pełni załadowany w pamięci GPU. 100% CPU oznacza, że przyspieszenie GPU nie jest używane. Stan mieszany mówi ci, że część obciążenia lub rezydencji wyciekła poza ścieżkę GPU. watch -n 1 nvidia-smi uzupełnia to, pokazując na żywo użycie VRAM na kartę, gdy model jest załadowany.

Najszybszy sposób, aby utrzymać te role w porządku, to:

📝 Uwaga: CUDA_VISIBLE_DEVICES to kontrola widoczności, a nie przełącznik “użyj obu GPU”. Jeśli kiedykolwiek ograniczysz dostęp do GPU, preferuj UUID z nvidia-smi -L zamiast identyfikatorów numerycznych, ponieważ kolejność GPU może się różnić między środowiskami i ponownym uruchomieniem.

Uruchom swój pierwszy lokalny model i zweryfikuj wnioskowanie GPU

W tym momencie nie potrzebujesz gigantycznego modelu, aby udowodnić, że serwer działa. Potrzebujesz szybkiego, uczciwego sukcesu. mistral to dobry pierwszy pull, ponieważ jest mały, szybko się pobiera i łatwo się ładuje, chociaż llama3.1:8b będzie później linią bazową do porównania zachowania.

Zacznij od pobrania modelu:

ollama pull mistral

Teraz uruchom przez niego małą podpowiedź, aby maszyna zrobiła coś użytecznego, a nie tylko administracyjnego. Odpowiedź może zająć kilka sekund.

ollama run mistral "In one sentence, explain why people self-host LLMs."

Aby udowodnić, że jest to wnioskowanie wspierane GPU, a nie powrót do CPU, sprawdź stan wykonania:

ollama ps

A aby zobaczyć, co już znajduje się na dysku, wylistuj lokalny inwentarz:

ollama list

mistral to właściwy pierwszy dowód, ponieważ daje ci szybką odpowiedź bez zamieniania walidacji konfiguracji w długie czekanie. Później llama3.1:8b staje się bardziej przydatny, ponieważ jest silniejszą wyrównaną linią bazową do porównywania zachowania modelu.

Na koniec sprawdź, gdzie instalacja Linux przechowuje modele:

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

Ta ścieżka — /usr/share/ollama/.ollama/models — to standardowy magazyn modeli Linux udokumentowany przez Ollama.

Gdy zobaczysz pomyślną odpowiedź, 100% GPU w ollama ps i rosnące użycie dysku w oczekiwanej lokalizacji, masz pierwszy znaczący dowód na to, że lokalny stos działa.

Udowodnij, że to serwer, a nie tylko wrapper CLI

Wiersz poleceń jest miły, ale powód do samodzielnego hostowania Ollama nie polega tylko na czatowaniu wewnątrz terminala. Chodzi o uruchomienie lokalnego serwera wnioskowania, który inne narzędzia, skrypty i aplikacje mogą wywoływać bez wysyłania podpowiedzi przez czyjąś granicę API. Najszybszym dowodem jest jedno czyste żądanie HTTP do natywnego punktu końcowego Ollama.

Wyślij lokalne żądanie generowania z wyłączonym streamingiem, aby pierwsza odpowiedź była łatwa do sprawdzenia:

curl http://localhost:11434/api/generate -d '{
"model": "mistral",
"prompt": "Say hello from a self-hosted Ollama server in one sentence.",
"stream": false
}'

Pomyślna odpowiedź powinna wrócić jako JSON i wyglądać mniej więcej tak:

{
  "model": "mistral",
  "created_at": "2026-05-13T12:45:12.000000Z",
  "response": "Hello from a self-hosted Ollama server running locally on Ubuntu.",
  "done": true,
  "done_reason": "stop",
  "total_duration": 812345678,
  "load_duration": 12345678,
  "prompt_eval_count": 14,
  "eval_count": 12
}

Lista kontrolna sukcesu jest prosta: żądanie HTTP działa lokalnie, wraca prawidłowy JSON, obecne jest done: true, a odpowiedź modelu znajduje się w response. To jest punkt, w którym Ollama przestaje być „CLI, które zdarza się pobierać modele” i staje się infrastrukturą, którą możesz faktycznie zintegrować z lokalnymi narzędziami i automatyzacją.

Jeśli chcesz kompatybilności z oprogramowaniem, które oczekuje kształtu żądania zgodnego z OpenAI, Ollama również udostępnia punkty końcowe /v1 lokalnie:

curl -X POST http://localhost:11434/v1/chat/completions
-H "Content-Type: application/json"
-d '{
"model": "mistral",
"messages": [
{"role": "user", "content": "Say this is a test."}
]
}'

📝 Uwaga: Etykieta „kompatybilna z OpenAI” jest łatwa do błędnego odczytania. Nie oznacza to, że rozmawiasz z OpenAI, i nie zmienia faktu, że serwer jest nadal lokalny. Oznacza to tylko, że kształt żądania jest wystarczająco znany dla narzędzi i SDK zbudowanych wokół wzorca API OpenAI. Podstawowy adres URL pozostaje http://localhost:11434/v1/, a każdy zastępczy klucz API, na którym nalegają niektóre biblioteki klienckie, można zignorować w przypadku lokalnego użytku Ollama.

Skąd naprawdę pochodzą ograniczenia modelu

To jest część, która zwykle zostaje spłaszczona w jedną niejasną ideę „cenzury”, ale technicznie zaangażowane są trzy różne warstwy: warstwa serwowania dostawcy, wyrównanie modelu i dostrajanie instrukcji oraz zachowanie podpowiedzi/runtime, które kontrolujesz sam. Self-hosting dramatycznie zmienia niektóre z tych warstw. Nie usuwa ich wszystkich.

Prosty sposób, aby to sobie wyobrazić, to:

Cloud API request:
You -> Vendor API gateway -> Vendor moderation / policy layer -> Model -> Response

Self-hosted Ollama request:
You -> Local Ollama server on 127.0.0.1 -> Model -> Response

Wyniki:
– Warstwa serwowania kontrolowana przez dostawcę znika z ścieżki lokalnej
– Granica sieci lokalnej i rejestrowania staje się Twoja
– Własne szkolenie i wyrównanie modelu nadal towarzyszą modelowi

Po rozdzieleniu warstw wcześniejsze kroki konfiguracji stają się znacznie bardziej znaczące:

Możesz myśleć o tym jak o produkcji scenicznej. Self-hosting zmienia scenę, oświetlenie, mikrofony i notatki reżysera. Nie przeszkoła aktora. Jeśli model został dostrojony, aby odpowiadać ostrożnie, często się wahać lub odmawiać pewnych rodzajów ujęć, uruchomienie go lokalnie nie usunie magicznie tego szkolenia.

To, co Twoja obecna konfiguracja już udowodniła, jest węższe, ale nadal ważne: kontrolujesz proces serwera, kontrolujesz granicę API i nie kierujesz już lokalnych podpowiedzi przez warstwę moderacji należącą do dostawcy. To jest rzeczywista zmiana w prywatności i kontroli. To, czego **nie** udowodniło, to że każdy model lokalny będzie się zachowywać w ten sam sposób lub że każda odmowa w przyszłości była spowodowana dostawcą chmury.

Tu wchodzi w grę wybór modelu. Jeśli chcesz praktycznego efektu mniejszej liczby zastrzeżeń, bardziej bezpośrednich odpowiedzi lub zachowania mniej opartego na odmowach, nie dojdziesz tam, mówiąc „self-hosted” głośniej. Dojdziesz tam, wybierając inną rodzinę modelu lub fine-tune — i rozumiejąc kompromisy, które się z tym wiążą.

Wybierz Model Lokalny Mniej Ograniczony

Jeśli chcesz uczciwego testu, porównaj modele zajmujące mniej więcej tę samą klasę wielkości. Dlatego ten przewodnik używa llama3.1:8b jako wyrównany baseline głównego nurtu i dolphin3 jako model porównawczy mniej ograniczony. Oba mają około 4,9GB, co ułatwia interpretację różnic w zachowaniu bez drastycznego zmieniania również śladu sprzętowego.

Pobierz modele porównawcze lokalnie:

ollama pull llama3.1:8b

ollama pull dolphin3

# Optional older reference model
ollama pull dolphin-mistral

Oto praktyczne wyjaśnienie trzech nazw, które najprawdopodobniej zobaczysz w tej części ekosystemu Ollama:

⚠️ Ostrzeżenie: Inne fine-tune to nie „ten sam model z usuniętą cenzurą”. Może zmienić bezpośredniość, gęstość zastrzeżeń i chęć do podążania za ramowaniem użytkownika, ale może również zmienić ton, dokładność, spójność i ogólną osobowość.

Wydajność GPU

Przed uruchomieniem żądanych modeli, najpierw konieczne jest zrozumienie możliwości i ograniczeń zaangażowanego sprzętu. Istnieją dwie rzeczy do przetestowania koncepcyjnie: po pierwsze, jak wygląda czyste zachowanie jednego GPU na rzeczywistym sprzęcie używanym w tym przewodniku; po drugie, co się zmienia, jeśli później uruchomisz ten sam stos na hoście z dwoma GPU. Oba są ważne, ale tylko pierwszy jest żywym dowodem z tej dokładnej maszyny.

Na tym serwerze lepszym testem czasu wykonania górnego zakresu jest gpt-oss:20b. Jest wystarczająco duży, aby być interesujący, a jednocześnie ma sens na jednej karcie 16GB.

ollama pull gpt-oss:20b

ollama stop mistral

ollama run gpt-oss:20b "Explain in one paragraph why a 14GB model is a realistic upper-end single-GPU test on a 16GB card."

Po załadowaniu modelu potwierdź stan czasu wykonania:

ollama ps

To jest praktyczny dowód, który chcesz na tej maszynie. Pokazuje, że mniejsze modele pasują łatwo i że większy, ale wciąż realistyczny model lokalny może zbliżyć jedną kartę 16GB do jej użytecznego zakresu bez potrzeby wielu GPU.

Jeśli później uruchomisz Ollama na hoście z dwoma GPU, model taki jak qwen3:30b staje się rodzajem obciążenia, które może zademonstrować umieszczenie na wielu GPU. Przepływ pracy jest taki sam — obserwuj nvidia-smi, uruchom model, sprawdź ollama ps — ale chodzi nie o to, aby obie karty zaświeciły się dla samego siebie. Chodzi o potwierdzenie, że Ollama rozprzestrzenia model na wiele GPU tylko wtedy, gdy model nie pasuje już czysto na jeden.

Rozważania dotyczące obejścia cenzury

Aby porównać zachowanie, utrzymuj warunki kontrolowane, aby testować model bardziej niż losowość. Użyj tego samego endpointu, tego samego promptu, stream: false, niskiej temperatury i stałego seed:

curl http://localhost:11434/api/generate -d '{
"model": "llama3.1:8b",
"prompt": "<comparison prompt>",
"stream": false,
"options": {
"temperature": 0.2,
"seed": 42
}
}'

Następnie powtórz to samo żądanie z “model”: “dolphin3”. Stały seed nie eliminuje całej wariancji, ale zmniejsza wystarczającą ilość losowości, aby różnice w tonie i zgodności były łatwiejsze do zauważenia.

1. Bezpiecznym pierwszym promptem jest: “Czy self-hosting LLM oznacza, że użytkownik w pełni kontroluje zachowanie modelu? Odpowiedz w 4 punktach. Bądź bezpośredni i pomiń wstępy.” Reprezentatywna odpowiedź llama3.1:8b zwykle brzmi tak:

   - Self-hosting gives you more control over deployment, privacy, and availability.
   - It does not automatically remove the model's built-in alignment behavior.
   - The model may still refuse or soften some responses depending on its training.
   - Full control comes from combining self-hosting with careful model selection and configuration.

   Reprezentatywna odpowiedź dolphin3 na ten sam prompt często brzmi bardziej zwięźle:

   - You control the machine, the network boundary, and the serving layer.
   - You do not erase the model's training history just by running it locally.
   - Vendor-side policy can disappear, but model-side alignment can still remain.
   - Real control comes from choosing a model whose behavior matches your use case.

2. Drugi użyteczny prompt to: “Napisz ostry pięcioznaniowy argument, dlaczego zespół wrażliwy na prywatność może odrzucić AI zarządzane przez dostawcę. Bez wstępu i bez zakończenia.” llama3.1:8b zwykle się zgadza, ale w bardziej wyważonym tonie korporacyjnym. dolphin3 chętniej podąża za żądaną ostrością. To jest rodzaj różnicy, którą szukasz tutaj: nie dramatyczne bezprawne dane wyjściowe, ale zmiany w bezpośredniości, ramowaniu i gęstości zastrzeżeń.
3. Trzecia kategoria promptów do walidacji może być następująca: poproś o pięć faktycznych powodów, dla których pisarz może preferować model lokalny do niezwykłej, niszowej lub niekonwencjonalnej pracy twórczej. W praktyce oba modele odpowiadają, ale dolphin3 zwykle pozostaje bliżej żądanego tonu bez moralizowania i bezpośrednich odpowiedzi.

Wzór wygląda następująco:

I dlatego oto szczere wnioski:

1. Wybór modelu lokalnego znacząco zmienia zachowanie danych wyjściowych.
2. Różne modele różnią się bezpośredniością i gęstością zastrzeżeń.
3. Self-hosting usuwa warstwę serwowania kontrolowaną przez dostawcę.

Teraz Kontrolujesz Stack, Nie Tylko Prompt

Frustracja z początku tego przewodnika nigdy nie dotyczyła tylko modelu odmawiającego żądania. Chodziło o fakt, że warstwa serwowania, warstwa polityki i granica prywatności znajdowały się gdzieś indziej. Po tej konfiguracji to się zmieniło. Twój serwer wnioskowania działa na Twojej maszynie Ubuntu, lokalna granica API jest Twoja, menu modeli jest Twoje, a domyślne ustawienia promptu/runtime są Twoje do dostrojenia.

To, co nadal wymaga osądu, to część, którą żaden instalator nie może rozwiązać dla Ciebie: wybór modeli pasujących do Twojego przypadku użycia, kierowanie nimi rozsądnymi ustawieniami domyślnymi i bezpieczne udostępnianie dostępu, jeśli wyjdziesz poza localhost. To jest rzeczywisty kształt kontroli self-hostingu. Nie magiczna wolność od każdego ograniczenia, ale własność stacku, który decyduje o tym, jak, gdzie i za pomocą którego modelu następuje wnioskowanie. Jeśli chcesz najlepszy następny krok, zacznij od utworzenia niestandardowego Modelfile — lub od umieszczenia bezpiecznego dostępu zdalnego przed lokalnym API, gdy będziesz gotowy.

Co zrobić po podstawowej konfiguracji

W tym momencie podstawowa obietnica jest spełniona. Serwer działa, API działa, ścieżka GPU jest rzeczywista, a różnice w zachowaniu modelu nie są już abstrakcyjne. Następny ruch to nie „ślepo instaluj więcej rzeczy”. To dostrojenie części stosu, które teraz do ciebie należą.

Dostosowywanie zachowania modelu za pomocą Modelfile

Modelfile to najczystszy sposób na zmianę lokalnych domyślnych ustawień promptu bez dotykania samych wag modelu. Zacznij od sprawdzenia bieżącej definicji modelu, aby zrozumieć, co rozszerzasz:

ollama show --modelfile dolphin3

Następnie utwórz prostą lokalną wariacją:

FROM dolphin3

SYSTEM You are a direct, factual assistant for a self-hosted Ubuntu LLM server. 
Prefer short, practical answers and avoid padded disclaimers.

PARAMETER temperature 0.2
PARAMETER num_ctx 8192

Zbuduj ją jako nową nazwę modelu i przetestuj:

ollama create dolphin3-local -f ./Modelfile
ollama run dolphin3-local "Summarize what changed in this custom model in 3 bullets."

❗ Ważne: Modelfile zmienia zachowanie promptu i środowiska uruchomieniowego, a nie historię trenowania modelu. Może kierować tonem i ustawieniami domyślnymi, ale nie przeprowadza ponownego trenowania modelu bazowego.

Zabezpieczanie konfiguracji

Wiązanie localhost to dobra domyślna opcja, ale to nie koniec historii bezpieczeństwa. Najpierw ponownie sprawdź bieżący adres nasłuchiwania:

ss -tlnp | grep 11434

Jeśli celem jest utrzymanie Ollama tylko lokalnie, jawnie przypnij to zachowanie za pomocą przesłonięcia systemd:

sudo systemctl edit ollama

Dodaj następujące:

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_NO_CLOUD=1"

Następnie przeładuj i uruchom ponownie usługę:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Jeśli później będziesz potrzebować dostępu zdalnego, nie publikuj 11434 bezpośrednio. Zamiast tego umieść przed nim odwrotny proxy z TLS i uwierzytelnianiem:

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

    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host localhost:11434;
    }
}

⚠️ Ostrzeżenie: Traktuj publiczne ujawnienie jako oddzielny projekt wzmacniania bezpieczeństwa. Ollama sama w sobie to lokalny serwer wnioskowania, a nie gotowa do produkcji publiczna brama API z wbudowanym uwierzytelnianiem, ograniczaniem szybkości i domyślnymi ustawieniami skierowanymi do Internetu.

Rekomendowane modele dla tego sprzętu

Gdy podstawowa instalacja działa, największą wartość dodaną stanowi wybór modeli, które rzeczywiście dobrze pasują do tej maszyny, zamiast gonić za największymi nagłówkami. Dla serwera z pojedynczym GPU 4070 Ti SUPER użytego tutaj praktyczne menu wygląda następująco:

Automatyczne uruchamianie i konserwacja

Po części zabawy przychodzi część, która utrzymuje lokalny serwer LLM użytecznym miesiąc od teraz. Potwierdź zachowanie podczas rozruchu, utrzymuj usługę zaktualizowaną, obserwuj dzienniki i wiedz, jak wyładować duże modele, gdy będziesz potrzebować VRAM z powrotem.

sudo systemctl is-enabled ollama

sudo systemctl enable --now ollama

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

journalctl -u ollama -n 100 --no-pager

Do codziennych operacji na modelach będziesz najczęściej używać tych poleceń:

ollama list
ollama ps
ollama stop gpt-oss:20b
sudo du -sh /usr/share/ollama/.ollama/models

A jeśli przechowywanie modeli musi przenieść się na większy dysk, przygotuj katalog dla użytkownika usługi, zanim ponownie skierujesz Ollama:

sudo mkdir -p /mnt/ai/ollama-models
sudo chown -R ollama:ollama /mnt/ai/ollama-models

Następnie ustaw OLLAMA_MODELS przez systemctl edit ollama. Ten jeden szczegół własności to to, co zapobiega zamianie przechowywania w problem uprawnień.

Odniesienie do rozwiązywania problemów

Gdy coś się zepsuje, najszybszą ścieżką jest zwykle dopasowanie objawu do właściwej warstwy zamiast próbowania losowych pętli ponownej instalacji. Użyj tej tabeli jako pierwszego przejścia:

Jeśli pamiętasz tylko jedną regułę operacyjną z tej sekcji, niech to będzie ta: traktuj Ollama jak rzeczywistą usługę, a nie jednorazowe narzędzie CLI. Dzienniki, własność, adresy wiązania i ścieżki przechowywania są równie ważne jak okno promptu.