Hoste Ollama selbst auf einem LLM-Server und übernimm die Kontrolle über KI-Zensur

Schlüsselwörter

Bevor wir mit der Einrichtung beginnen, finden Sie hier die Begriffe, die Leser in diesem Leitfaden am ehesten verwirren könnten. Dieses kurze Glossar hält die Terminologie rund um Linux, GPU und lokale Modelle von Anfang an klar.

Warum es sich lohnt, ein LLM selbst zu hosten

Wenn Sie den schwierigen Teil bereits erledigt haben — einen GPU-Server gemietet, Ubuntu installiert, sich mit SSH vertraut gemacht und eigene Dienste am Laufen gehalten haben — wird es schnell frustrierend, wenn eine gehostete KI immer noch die letzte Meile kontrolliert. Sie kann eine völlig normale Anfrage ablehnen, die Antwort unter Disclaimern begraben, den Antwortstil ohne Vorwarnung ändern und jeden Prompt weiterhin durch die Grenzen von jemand anderem leiten. Für viele technisch versierte Nutzer ist das die eigentliche Frustration: nicht nur das, was das Modell sagt, sondern wer die Kontrolle über die Bereitstellungsschicht hat, wenn es antwortet.

Dieser Leitfaden handelt davon, das mit offenen und lokalen Modellen zu beheben – nicht von Umgehungstricks für proprietäre APIs. Sie werden Ollama auf einem Ubuntu-GPU-Server selbst hosten, Inferenz lokal ausführen, überprüfen, ob der GPU-Pfad tatsächlich genutzt wird, und sehen, was sich ändert, wenn Sie eine andere Modellfamilie wählen. Ein Missverständnis sollte frühzeitig ausgeräumt werden: Self-Hosted bedeutet nicht automatisch uneingeschränkt. Es bedeutet, dass Sie einen viel größeren Teil des Stacks kontrollieren — und nicht mehr von einem anbieterkontrollierten Bereitstellungspfad abhängig sind — aber das Modell, das Sie ausführen, kann immer noch sein eigenes Ausrichtungsverhalten mitbringen.

📝 Hinweis: Die Befehle in diesem Leitfaden wurden anhand der aktuellen Ollama-Dokumentation validiert, aber die unten gezeigten Terminal-Ausgaben sind repräsentative Beispiele und keine Live-Benchmark-Aufzeichnungen. Verwenden Sie sie als Erfolgsmuster, nicht als Leistungsaussage.

Am Ende werden Sie einen funktionierenden Ollama-Dienst auf Ubuntu haben, eine verifizierte lokale API unter 127.0.0.1:11434, den Beweis, dass GPU-gestützte Inferenz tatsächlich stattfindet, sowie einen fundierten Vergleich zwischen einem mainstream-ausgerichteten Modell und einer weniger eingeschränkten Alternative. Dieses Tutorial richtet sich an Leser, die mit SSH, Ubuntu, sudo und systemd vertraut sind, aber keine vorherige Ollama-Erfahrung benötigen.

Der genaue Ubuntu-GPU-Server, der für diesen Leitfaden verwendet wurde

Diese Anleitung basiert auf einem echten Single-GPU-Ubuntu-Rechner, da vage „sollte auf den meisten Servern funktionieren”-Ratschläge dazu führen, dass Self-Hosting-Leitfäden irreführend werden. Das hier verwendete Referenzsystem entspricht der tatsächlichen Art von Host, die für diesen Leitfaden genutzt wurde: die Art von Maschine, die eine fortgeschrittene Einzelperson, ein Labor oder ein kleines Team tatsächlich mieten würde, wenn sie private lokale Inferenz wünschen, ohne direkt zu einem Rack voller Enterprise-Beschleuniger zu greifen. Das Multi-GPU-Verhalten wird später noch besprochen, da sich Ollama ändert, sobald ein Modell über eine Karte hinauswächst – aber betrachten Sie diesen Teil als zukunftsorientierten Kontext und nicht als Beweis von diesem genauen Server.

GPU-Server — Ryzen 9 3950X + RTX 4070 Ti Super

In der Praxis ist dies eine sehr starke Konfiguration für alltägliche 8B-Klasse-Modelle und immer noch nützlich für größere lokale Aufgaben bis zu dem Punkt, an dem 16GB VRAM zur eigentlichen Einschränkung werden. Ein Modell wie llama3.1:8b mit etwa 4,9GB passt problemlos auf diese Karte. Ein Modell wie gpt-oss:20b mit etwa 14GB ist die Art von Single-GPU-Test am oberen Ende, der hier noch sinnvoll ist. Ein Modell wie qwen3:30b mit etwa 19GB sollte eher als Referenzpunkt dafür betrachtet werden, was sich auf einem größeren oder Dual-GPU-Host ändert, als dass es ein sauberer Fit für diese genaue Maschine wäre.

Diese Unterscheidung ist wichtig, weil es in diesem Artikel nicht darum geht, die größtmögliche Zahl in eine Überschrift zu pressen. Es geht darum zu zeigen, wie ein vernünftiger selbst gehosteter LLM-Server aussieht, wenn man Datenschutz, lokale Kontrolle und genug GPU-Speicher möchte, um nützliche Modelle ohne ständige Kompromisse zu betreiben. Diese Hardware-Klasse ist der Punkt, an dem selbst gehostete Inferenz realistisch und nicht mehr theoretisch wird.

Es erklärt auch einige Entscheidungen, die Sie später sehen werden: mistral wird zuerst verwendet, weil es einen schnellen, reibungsarmen Beweis liefert, dass der Stack funktioniert, während der Verhaltensvergleich in der 8B-Klasse bleibt, in der sich diese Maschine wohl fühlt. qwen3:30b erscheint später noch, aber als theoretisches Beispiel für die Art von Modell, das auf einem größeren Host eine Multi-GPU-Platzierung auslösen kann, und nicht als Live-Beweis von diesem Server. Mit diesen Erwartungen können wir nun mit der Validierung des Hosts fortfahren, bevor Ollama ihn berührt.

Führen Sie diese Vorinstallationsprüfungen durch, bevor Sie Ollama installieren

Beginnen Sie mit nvidia-smi. Wenn dieser Befehl fehlt oder fehlschlägt, hören Sie dort auf und beheben Sie zuerst den NVIDIA-Treiber. Installieren Sie Ollama noch nicht, da ein defekter NVIDIA-Stack jeden späteren Symptom wie einen Anwendungsfehler aussehen lässt, obwohl es sich tatsächlich um einen Plattformfehler handelt.

Führen Sie zuerst die GPU-Prüfung durch:

❗Wenn Ubuntu meldet, dass nvidia-smi fehlt, nehmen Sie nicht an, dass der Server keine GPU hat. Ein häufiger Fehler bei gemieteten Ubuntu-Systemen ist, dass die Karte vorhanden ist, aber noch an nouveau statt an den NVIDIA-Treiber gebunden ist. Lesen Sie zuerst den Abschnitt „NVIDIA-Treiberproblem unter Ubuntu beheben“.

Ein gesundes Ergebnis auf dieser Serverklasse sollte ungefähr so aussehen:

Sobald nvidia-smi funktioniert und die GPU sichtbar ist, fahren Sie mit den nachstehenden Prüfungen fort.

Was Sie bestätigen möchten, ist einfach: Die installierte GPU ist sichtbar, sie meldet auf diesem Host etwa 16GB VRAM, und der Treiber ist sauber geladen. Wenn Sie sich auf einem Multi-GPU-Server befinden, sollte derselbe Befehl jede Karte auflisten.

❗ Wichtig: Die aktuelle Ollama-GPU-Support-Dokumentation verwendet NVIDIA-Treiber 531+ als tatsächliche Untergrenze für unterstützte NVIDIA-Inferenz. Betrachten Sie 531+ als Anforderung für diesen Leitfaden, auch wenn Sie ältere Community-Hinweise mit niedrigeren Versionen gesehen haben.

Bestätigen Sie nun, dass der Host tatsächlich die Ubuntu-Umgebung ist, die dieser Leitfaden voraussetzt:

Überprüfen Sie abschließend den freien Speicherplatz, bevor Sie mit dem Herunterladen von Modellen beginnen. Die Installation selbst ist klein; die Modelle sind es nicht. Sobald Sie über kleine Tests hinausgehen, kann eine 20B-30B-Bibliothek schnell Dutzende von Gigabytes verbrauchen, daher ist die richtige Denkweise für ernsthafte lokale Modellarbeit 100GB+ frei.

Wenn diese Prüfungen bestanden sind, haben Sie die wichtigsten Infrastruktur-Unbekannten geklärt: Die GPUs sind vorhanden, die Treiber-Basis ist in Ordnung, Ubuntu ist bestätigt, und die Festplatte hat Platz für echte Modell-Downloads. Das ist der Punkt, an dem die Installation von Ollama ein sauberer nächster Schritt ist und kein Ratespiel.

NVIDIA-Treiberproblem unter Ubuntu beheben

Befolgen Sie die nachstehenden Schritte, um Probleme mit dem Befehl „nvidia-smi” zu beheben.

Wenn diese Ausgabe eine NVIDIA-Karte und eine Zeile wie Kernel driver in use: nouveau anzeigt, installieren Sie das empfohlene Ubuntu-Treiberpaket, anstatt nur nvidia-utils zu installieren.

Installieren Sie das Paket ubuntu-drivers-common (wird für die Treiberverwaltung benötigt) und die Kernel-Header für Ihren aktuell laufenden Kernel.

Scannen Sie Ihr System und listen Sie verfügbare proprietäre Treiber auf (z. B. NVIDIA-GPU-Treiber), die installiert werden können.

Installieren Sie dann das empfohlene Treiberpaket. In unserem Fall war es: nvidia-driver-595-open:

Führen Sie nach dem Neustart erneut aus:

Ollama installieren und den Dienststatus überprüfen

Der unterstützte Ubuntu-Weg ist der offizielle Ollama-Installer, kein benutzerdefinierter Tarball-Flow und kein Docker-Umweg. Das ist wichtig, weil es in diesem Leitfaden darum geht, einen zuverlässigen lokalen Dienst mit vorhersehbaren Standardeinstellungen, systemd-Integration und vernünftigem Eigentumsverhalten unter Linux zu erhalten.

Führen Sie den Installer genau wie dokumentiert aus:

Auf einem gesunden System installiert das Skript die Binärdatei, erstellt den ollama-Dienstbenutzer, fügt die richtigen Gruppenmitgliedschaften hinzu, wenn verfügbar, schreibt die systemd-Unit und startet den Dienst gebunden an 127.0.0.1:11434.

Sobald das Skript abgeschlossen ist, validieren Sie den Dienst, anstatt den Erfolg vorauszusetzen:

Sie suchen hier nach drei Dingen: Die Unit-Datei ist vorhanden, der Dienst ist für den Start aktiviert, und Active: active (running) bestätigt, dass der Server tatsächlich läuft.

Stellen Sie zunächst das Linux-Dienstbenutzerkonto konkret fest und denken Sie erst danach darüber nach, wie und wo die Modellspeicherung gehandhabt wird.

Diese einzelne Zeile erklärt viele zukünftige Verhaltensweisen. Modelle unter Linux befinden sich im Eigentum des Dienstes, und wenn Sie sie später auf einen anderen Datenträger verschieben, ohne die Berechtigungen für den ollama-Benutzer zu korrigieren, verursachen Sie eigene Probleme.

Eine weitere Prüfung schließt den Kreis über die Standard-Bindung:

⚠️ Warnung: Ollama erfordert standardmäßig keine Authentifizierung für die lokale API. Das ist in Ordnung, wenn es an 127.0.0.1 gebunden ist, aber es ist nicht sicher, Port 11434 direkt dem Internet auszusetzen, als wäre es ein gehärteter öffentlicher Dienst.

Wenn der Dienst nicht sauber startet, schauen Sie zuerst in die Logs, anstatt blind neu zu installieren:

Das ist der schnellste Weg, Berechtigungsprobleme, Startfehler, Treiber-Erkennungsprobleme oder Binding-Probleme zu finden. Sobald der Dienst auf localhost gesund ist, sollte als nächstes verstanden werden, wie sich die GPU-Platzierung zur Laufzeit verhält.

Wie Ollama tatsächlich eine oder mehrere GPUs verwendet

Obwohl der für diesen Leitfaden verwendete Server eine GPU hat, lohnt es sich dennoch, das Multi-GPU-Verhalten zu verstehen, da viele Benutzer auf größeren Systemen sein können oder später erweitern möchten. Viele Zwei-GPU-Verwirrungen beginnen mit der falschen Erwartung: „Ich habe zwei Karten, also sollten beide ständig aktiv sein.” So funktioniert Ollama nicht. Die praktische Regel ist viel einfacher: Wenn ein Modell auf eine GPU passt, behält Ollama es normalerweise auf einer GPU. Es verteilt sich nur auf mehrere GPUs, wenn das Modell nicht komfortabel auf eine einzelne Karte passt.

Verwenden Sie diese beiden Prüfungen zusammen, wenn Sie die GPU-Leistung sehen möchten:

ollama ps zeigt Ihnen, wie das geladene Modell verarbeitet wird. 100% GPU bedeutet, dass das Modell vollständig im GPU-Speicher gehalten wird. 100% CPU bedeutet, dass die GPU-Beschleunigung nicht verwendet wird. Ein gemischter Zustand zeigt an, dass ein Teil der Arbeitslast oder des Speichers außerhalb des GPU-Pfads liegt. watch -n 1 nvidia-smi ergänzt dies, indem es die Live-VRAM-Nutzung pro Karte anzeigt, während das Modell geladen ist.

Die schnellste Möglichkeit, diese Rollen auseinanderzuhalten, ist diese:

📝 Hinweis: CUDA_VISIBLE_DEVICES ist eine Sichtbarkeitskontrolle, kein „beide GPUs verwenden”-Schalter. Wenn Sie den GPU-Zugriff jemals einschränken, bevorzugen Sie die UUIDs aus nvidia-smi -L gegenüber numerischen IDs, da die GPU-Reihenfolge zwischen Umgebungen und Neustarts variieren kann.

Führen Sie Ihr erstes lokales Modell aus und verifizieren Sie die GPU-Inferenz

An diesem Punkt brauchen Sie kein riesiges Modell, um zu beweisen, dass der Server funktioniert. Sie brauchen einen schnellen, ehrlichen Erfolg. mistral ist ein guter erster Download, weil es klein, schnell heruntergeladen und leicht zu laden ist, obwohl llama3.1:8b später als Baseline für den Verhaltensvergleich dienen wird.

Beginnen Sie mit dem Herunterladen des Modells:

Führen Sie nun einen kleinen Prompt durch, damit die Maschine etwas Nützliches tut und nicht nur Administratives. Die Antwort kann einige Sekunden dauern.

Um zu beweisen, dass es sich um GPU-gestützte Inferenz handelt und nicht um einen CPU-Fallback, überprüfen Sie den Laufzeitzustand:

Und um zu sehen, was sich bereits auf der Festplatte befindet, listen Sie den lokalen Bestand auf:

mistral ist der richtige erste Beweis, weil es eine schnelle Antwort liefert, ohne die Setup-Validierung zu einem langen Warten zu machen. Später wird llama3.1:8b nützlicher, weil es eine stärkere ausgerichtete Baseline zum Vergleich des Modellverhaltens bietet.

Überprüfen Sie abschließend, wo die Linux-Installation Modelle speichert:

Dieser Pfad — /usr/share/ollama/.ollama/models — ist der von Ollama dokumentierte Standard-Linux-Modellspeicher.

Sobald Sie eine erfolgreiche Antwort, 100% GPU in ollama ps und zunehmende Festplattennutzung am erwarteten Ort sehen, haben Sie den ersten bedeutsamen Beweis, dass der lokale Stack funktioniert.

Beweisen Sie, dass es ein Server ist, nicht nur ein CLI-Wrapper

Ein Befehlszeilen-Prompt ist schön, aber der Grund für das Self-Hosting von Ollama ist nicht nur, im Terminal zu chatten. Es geht darum, einen lokalen Inferenzserver zu betreiben, den andere Tools, Skripte und Anwendungen aufrufen können, ohne Prompts durch die API-Grenze von jemand anderem zu senden. Der schnellste Beweis ist eine saubere HTTP-Anfrage an den nativen Ollama-Endpunkt.

Senden Sie eine lokale Generate-Anfrage mit deaktiviertem Streaming, damit die erste Antwort leicht zu inspizieren ist:

Eine erfolgreiche Antwort sollte als JSON zurückkommen und ungefähr so aussehen:

{
  "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
}

Die Erfolgscheckliste ist unkompliziert: Die HTTP-Anfrage funktioniert lokal, gültiges JSON kommt zurück, done: true ist vorhanden, und die Antwort des Modells befindet sich in response. Das ist der Punkt, an dem Ollama aufhört, „ein CLI, das zufällig Modelle herunterlädt” zu sein, und zur Infrastruktur wird, die Sie tatsächlich in lokale Tools und Automatisierung integrieren können.

Wenn Sie Kompatibilität mit Software wünschen, die eine OpenAI-ähnliche Anfrage-Form erwartet, stellt Ollama auch lokal /v1-Endpunkte bereit:

📝 Hinweis: Das Label „OpenAI-kompatibel” ist leicht misszuverstehen. Es bedeutet nicht, dass Sie mit OpenAI kommunizieren, und es ändert nichts daran, dass der Server noch lokal ist. Es bedeutet nur, dass die Anfrage-Form vertraut genug ist für Tools und SDKs, die auf das OpenAI-API-Muster ausgerichtet sind. Die Basis-URL bleibt http://localhost:11434/v1/, und jeder Platzhalter-API-Schlüssel, auf dem einige Client-Bibliotheken bestehen, kann für die lokale Ollama-Nutzung ignoriert werden.

Woher Modellbeschränkungen wirklich kommen

Das ist der Teil, der normalerweise zu einem einzigen vagen Begriff von „Zensur” vereinfacht wird, aber technisch gesehen sind drei verschiedene Schichten beteiligt: die Bereitstellungsschicht des Anbieters, die Ausrichtung und Instruktionsanpassung des Modells sowie das Prompt- und Laufzeitverhalten, das Sie selbst kontrollieren. Self-Hosting verändert einige dieser Schichten erheblich. Es löscht sie nicht alle aus.

Eine einfache Möglichkeit, es sich vorzustellen, ist diese:

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

Ergebnisse:
– Die anbieterkontrollierte Bereitstellungsschicht verschwindet aus dem lokalen Pfad
– Die lokale Netzwerk- und Protokollierungsgrenze gehört Ihnen
– Das eigene Training und die Ausrichtung des Modells kommen weiterhin mit dem Modell

Sobald Sie die Schichten trennen, werden die früheren Einrichtungsschritte viel bedeutsamer:

Man kann es sich wie eine Bühnenproduktion vorstellen. Self-Hosting ändert die Bühne, die Beleuchtung, die Mikrofone und die Regieanweisungen. Es trainiert den Schauspieler nicht neu. Wenn ein Modell darauf ausgerichtet war, vorsichtig zu antworten, häufig abzusichern oder bestimmte Formulierungen abzulehnen, wird das Ausführen auf einem lokalen System dieses Training nicht magisch rückgängig machen.

Was Ihre aktuelle Einrichtung bereits bewiesen hat, ist enger gefasst, aber dennoch wichtig: Sie kontrollieren den Serverprozess, Sie kontrollieren die API-Grenze, und Sie leiten lokale Prompts nicht mehr durch eine anbietereigene Moderationsschicht. Das ist eine echte Verschiebung in Bezug auf Datenschutz und Kontrolle. Was es nicht bewiesen hat, ist, dass sich jedes lokale Modell gleich verhält oder dass jede zukünftige Ablehnung durch einen Cloud-Anbieter verursacht wurde.

Hier kommt die Modellwahl ins Spiel. Wenn Sie den praktischen Effekt von weniger Disclaimern, direkteren Antworten oder weniger ablehnungsfreudigem Verhalten wünschen, erreichen Sie das nicht, indem Sie „self-hosted” lauter sagen. Sie erreichen es, indem Sie eine andere Modellfamilie oder Fine-Tune wählen – und die damit verbundenen Kompromisse verstehen.

Weniger eingeschränktes lokales Modell wählen

Wenn Sie einen fairen Test wünschen, vergleichen Sie Modelle, die ungefähr dieselbe Größenklasse belegen. Deshalb verwendet dieser Leitfaden llama3.1:8b als mainstream-ausgerichtete Baseline und dolphin3 als weniger eingeschränktes Vergleichsmodell. Beide sind etwa 4,9GB groß, was den Verhaltensunterschied leichter interpretierbar macht, ohne gleichzeitig den Hardware-Fußabdruck zu stark zu verändern.

Laden Sie die Vergleichsmodelle lokal herunter:

Hier ist der praktische Rahmen für die drei Namen, die Sie in diesem Teil des Ollama-Ökosystems am häufigsten sehen werden:

⚠️ Warnung: Eine andere Fine-Tune-Version ist nicht „dasselbe Modell ohne Zensur”. Sie kann Direktheit, Disclaimer-Dichte und Bereitschaft, der Nutzerformulierung zu folgen, ändern, kann aber auch Ton, Faktizität, Konsistenz und Gesamtpersönlichkeit verändern.

GPU-Leistung

Bevor die gewünschten Modelle ausgeführt werden, ist es zunächst wichtig, die Möglichkeiten und Grenzen der beteiligten Hardware zu verstehen. Es gibt also zwei Dinge, die konzeptionell getestet werden sollen: erstens, wie sauberes Single-GPU-Verhalten auf der tatsächlich für diesen Leitfaden verwendeten Hardware aussieht; zweitens, was sich ändert, wenn Sie denselben Stack später auf einem Dual-GPU-Host ausführen. Beides ist wichtig, aber nur das Erste ist ein Live-Beweis von dieser genauen Maschine.

Auf diesem Server ist der bessere obere Laufzeittest gpt-oss:20b. Es ist groß genug, um interessant zu sein, und passt dennoch auf eine 16GB-Karte.

Nachdem das Modell geladen ist, bestätigen Sie den Laufzeitzustand:

Das ist der praktische Beweis, den Sie auf dieser Maschine wünschen. Er zeigt, dass kleinere Modelle problemlos passen und dass ein größeres, aber immer noch realistisches lokales Modell eine 16GB-Karte nahe an ihre nutzbare Grenze bringen kann, ohne mehrere GPUs zu benötigen.

Wenn Sie Ollama später auf einem Zwei-GPU-Host ausführen, wird ein Modell wie qwen3:30b zu der Art von Arbeitslast, die Multi-GPU-Platzierung demonstrieren kann. Der Arbeitsablauf ist derselbe — nvidia-smi beobachten, das Modell ausführen, ollama ps prüfen — aber der Punkt ist nicht, beide Karten um ihrer selbst willen zum Leuchten zu bringen. Der Punkt ist zu bestätigen, dass Ollama ein Modell nur dann auf mehrere GPUs verteilt, wenn es nicht mehr sauber auf eine passt.

Überlegungen zur Umgehung von Einschränkungen

Halten Sie für den Verhaltensvergleich die Bedingungen kontrolliert, damit Sie eher das Modell als die Zufälligkeit testen. Verwenden Sie denselben Endpunkt, denselben Prompt, stream: false, eine niedrige Temperatur und einen festen Seed:

Wiederholen Sie dann dieselbe Anfrage mit “model”: “dolphin3”. Ein fester Seed eliminiert nicht alle Varianz, reduziert aber genug Zufälligkeit, um Ton- und Compliance-Unterschiede leichter sichtbar zu machen.

1. Ein sicherer erster Prompt ist: „Bedeutet das Self-Hosting eines LLMs, dass der Benutzer das Verhalten des Modells vollständig kontrolliert? Antworten Sie in 4 Stichpunkten. Seien Sie direkt und überspringen Sie Präambeln.” Eine repräsentative llama3.1:8b-Antwort klingt tendenziell so:

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

   Eine repräsentative dolphin3-Antwort auf denselben Prompt klingt oft reduzierter:

   - 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. Ein zweiter nützlicher Prompt ist: „Schreiben Sie fünf prägnante Sätze als Argument dafür, warum ein datenschutzsensibles Team von einem anbietermanagierten KI absehen könnte. Kein Intro und kein Fazit.” llama3.1:8b entspricht der Anforderung in der Regel, aber in einem gemäßigteren, sachlicheren Ton. dolphin3 folgt der geforderten Prägnanz bereitwilliger. Das ist die Art von Unterschied, nach der Sie hier suchen: keine dramatisch gesetzlose Ausgabe, sondern Veränderungen in Direktheit, Formulierung und Disclaimer-Dichte.
3. Die dritte Prompt-Kategorie zur Validierung kann wie folgt aussehen: Fragen Sie nach fünf sachlichen Gründen, warum ein Autor ein lokales Modell für ungewöhnliche, nischige oder nicht-mainstream kreative Arbeit bevorzugen könnte. In der Praxis antworten beide Modelle, aber dolphin3 tendiert dazu, näher am geforderten nicht-moralisierenden Ton zu bleiben und direkte Antworten zu geben.

Das Muster sieht so aus:

Und somit sind hier die ehrlichen Schlussfolgerungen:

1. Die Wahl des lokalen Modells verändert das Ausgabeverhalten erheblich.
2. Verschiedene Modelle unterscheiden sich in Direktheit und Disclaimer-Dichte.
3. Self-Hosting entfernt eine anbieterkontrollierte Bereitstellungsschicht.

Sie kontrollieren jetzt den Stack, nicht nur den Prompt

Die Frustration vom Anfang dieses Leitfadens war nie nur ein Modell, das eine Anfrage ablehnte. Es ging darum, dass die Bereitstellungsschicht, die Richtlinienschicht und die Datenschutzgrenze woanders lagen. Nach dieser Einrichtung hat sich dieser Teil verändert. Ihr Inferenzserver läuft auf Ihrer Ubuntu-Maschine, die lokale API-Grenze gehört Ihnen, das Modellmenü gehört Ihnen, und Ihre Prompt- und Laufzeit-Standardwerte sind Ihre zum Anpassen.

Was noch Urteilsvermögen erfordert, ist der Teil, den kein Installer für Sie lösen kann: Modelle wählen, die zu Ihrem Anwendungsfall passen, sie mit vernünftigen Standardwerten steuern und den Zugriff sicher bereitstellen, wenn Sie über localhost hinausgehen. Das ist die wahre Form der Self-Hosting-Kontrolle. Nicht magische Freiheit von jeder Einschränkung, sondern Eigentümerschaft des Stacks, der entscheidet, wie, wo und mit welchem Modell Inferenz stattfindet. Wenn Sie den besten nächsten Schritt wünschen, beginnen Sie damit, ein benutzerdefiniertes Modelfile zu erstellen – oder sichere Fernzugriff vor die lokale API zu schalten, wenn Sie bereit sind.

Was nach der Grundeinrichtung zu tun ist

An diesem Punkt ist das Kernversprechen erfüllt. Der Server funktioniert, die API funktioniert, der GPU-Pfad ist real, und die Modellverhaltensunterschiede sind nicht mehr abstrakt. Der nächste Schritt ist nicht „blind mehr Dinge installieren”. Es geht darum, die Teile des Stacks zu optimieren, die jetzt Ihnen gehören.

Modelverhalten mit einem Modelfile anpassen

Ein Modelfile ist der sauberste Weg, lokale Prompting-Standardwerte zu ändern, ohne die Modellgewichte selbst anzufassen. Beginnen Sie damit, die aktuelle Definition des Modells zu inspizieren, damit Sie verstehen, was Sie erweitern:

Erstellen Sie dann eine einfache lokale Variante:

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

Erstellen Sie es als neuen Modellnamen und testen Sie es:

❗ Wichtig: Ein Modelfile ändert das Prompting- und Laufzeitverhalten, nicht die Trainingsgeschichte des Modells. Es kann Ton und Standardwerte steuern, trainiert das zugrundeliegende Modell jedoch nicht neu.

Die Einrichtung absichern

Die Localhost-Bindung ist ein guter Standard, aber sie ist nicht das Ende der Sicherheitsgeschichte. Überprüfen Sie zuerst die aktuelle Abhöradresse:

Wenn das Ziel ist, Ollama nur lokal zu halten, fixieren Sie dieses Verhalten explizit mit einem systemd-Override:

Fügen Sie Folgendes hinzu:

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

Laden Sie dann den Dienst neu und starten Sie ihn neu:

Wenn Sie später Fernzugriff benötigen, veröffentlichen Sie 11434 nicht direkt. Setzen Sie stattdessen einen Reverse-Proxy mit TLS und Authentifizierung davor:

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;
    }
}

⚠️ Warnung: Behandeln Sie die öffentliche Exposition als separates Härtungsprojekt. Ollama allein ist ein lokaler Inferenzserver, kein produktionsbereites öffentliches API-Gateway mit eingebauter Authentifizierung, Ratenbegrenzung und internet-seitigen Standardwerten.

Empfohlene Modelle für diese Hardware

Sobald die Grundinstallation funktioniert, ist die wertvollste Verbesserung die Wahl von Modellen, die tatsächlich gut zu dieser Maschine passen, anstatt dem größten Schlagzeilen-Modell nachzujagen. Für den hier verwendeten Single-4070 Ti SUPER-Server sieht das praktische Menü so aus:

Automatischer Start und Wartung

Nach dem interessanten Teil kommt der Teil, der einen lokalen LLM-Server in einem Monat noch nutzbar hält. Bestätigen Sie das Boot-Zeitverhalten, halten Sie den Dienst aktualisiert, überwachen Sie die Logs und wissen Sie, wie Sie große Modelle entladen, wenn Sie den VRAM zurückbrauchen.

Für den täglichen Modellbetrieb sind dies die Befehle, die Sie am häufigsten verwenden werden:

Und wenn der Modellspeicher auf eine größere Festplatte verschoben werden muss, bereiten Sie das Verzeichnis für den Dienstbenutzer vor, bevor Sie Ollama neu verweisen:

Setzen Sie dann OLLAMA_MODELS über systemctl edit ollama. Dieses eine Eigentümerschaftsdetail verhindert, dass eine Speichermigration zu einem Berechtigungsproblem wird.

Fehlerbehebungsreferenz

Wenn etwas kaputt geht, ist der schnellste Weg normalerweise, das Symptom der richtigen Schicht zuzuordnen, anstatt zufällige Neuinstallations-Schleifen zu versuchen. Verwenden Sie diese Tabelle als ersten Durchlauf:

Symptom	Wahrscheinliche Ursache	Prüfung	Lösung
nvidia-smi schlägt fehl	Treiber- oder GPU-Stack-Problem	nvidia-smi, lspci -nnk | grep -A3 -Ei ‘VGA|3D|NVIDIA’, ubuntu-drivers devices	Beheben Sie zuerst die NVIDIA-Schicht; wenn Ubuntu nouveau verwendet, installieren Sie den empfohlenen NVIDIA-Treiber, starten Sie neu und führen Sie nvidia-smi erneut aus
ollama.service startet nicht	Dienst-, Berechtigungs- oder Binding-Problem	systemctl status ollama, journalctl -u ollama -n 100 — 15% auf alle Hosting-Dienste sparen Teste deine Fähigkeiten und erhalte Rabatt auf jeden Hosting-Plan Benutze den Code: Skills Anfangen Ollama selbst hosten auf einem LLM-Server und die Kontrolle über KI-Zensur übernehmen Table of Contents Schlüsselbegriffe Warum das Self-Hosting eines LLM sich lohnt Der genaue Ubuntu-GPU-Server, der für diesen Leitfaden verwendet... Ollama selbst auf einem LLM-Server hosten und die Kontrolle über KI-Zensur übernehmen Table of Contents Schlüsselwörter Warum es sich lohnt, ein LLM selbst zu hosten Der genaue Ubuntu-GPU-Server, der für diesen... Wie man 3x-ui installiert und die richtige Anti-Zensur-Konfiguration wählt Table of Contents Schlüsselbegriffe Wie man 3x-ui auf einem VPS installiert und die richtige Anti-Zensur-Konfiguration wählt Was 3x-ui eigentlich... We use cookies to improve your experience on alexhost.com, analyze site performance and traffic, and support our marketing efforts. We may also share information about your use of our site with our social media, advertising, and analytics partners. By clicking one of the buttons below, you can choose your cookie preferences. Note: Some technical cookies will be stored regardless of your choice. Accept All Cookies Necessary Cookies Only Decline All