Ollama auf Ubuntu installieren: Dienst, Modell und lokale API prüfen

Ollama auf Ubuntu: Rechner und Voraussetzungen prüfen

Diese Anleitung richtet sich an einen Ubuntu-Rechner mit einem üblichen systemd-Dienstaufbau. Du brauchst einen passenden Benutzer mit den für die Installation erforderlichen Administratorrechten, eine Netzwerkverbindung für Downloads und ausreichend Speicher für das gewählte Modell. Für Container, WSL oder einen verwalteten Server gelten zusätzliche Rahmenbedingungen.

uname -m
cat /etc/os-release
free -h
df -h

uname -m hilft dir, die Architektur einzuordnen. Ein x86-64- und ein ARM64-Paket sind unterschiedliche Downloads. Prüfe daneben Arbeitsspeicher und freien Speicherplatz; die Größe der Modelldatei ist nicht mit dem gesamten Arbeitsspeicherbedarf gleichzusetzen.

Wenn curl fehlt, beschreibt Ubuntu für die interaktive Paketverwaltung den Weg über sudo apt update und danach sudo apt install curl ca-certificates. Das aktualisiert zunächst den Paketindex und installiert anschließend diese Hilfsprogramme. Es installiert noch kein KI-Modell.

Du kannst vor dem ersten Download Ollama als Laufzeit und Modellverwaltung verstehen. Die Modellantwort entsteht durch die gewählten Gewichte, nicht allein durch die erfolgreiche Installation der Anwendung.

Ubuntu unter WSL2: Dienststart und Netzwerk getrennt prüfen

Unter Windows ist Ubuntu in WSL2 ein eigener Ausführungsort. Prüfe zuerst in Windows PowerShell deinen WSL-Stand:

wsl --version

Microsoft nennt für die manuelle systemd-Aktivierung WSL0.67.6 oder neuer. Öffne dann Ubuntu und prüfe mit systemctl status, ob systemd bereits verfügbar ist. Bei der aktuellen Ubuntu-Standardinstallation über WSL ist es laut Microsoft normalerweise aktiviert.

Falls es fehlt, prüfst du WSL- und Paketstand nach der Microsoft-Anleitung. Ergänze bei passendem Aufbau die Datei /etc/wsl.conf, ohne vorhandene Einstellungen zu überschreiben:

[boot]
systemd=true

Speichere vorher deine Arbeit in allen WSL-Umgebungen. wsl.exe --shutdown in Windows PowerShell beendet alle laufenden WSL-Instanzen. Öffne Ubuntu anschließend neu und kontrolliere systemd erneut. Führe die weiteren Linuxschritte dieses Guides innerhalb dieser Ubuntu-Umgebung aus. Systemd-Dienste allein halten WSL nicht dauerhaft aktiv.

Die API-Prüfung unten findet zunächst innerhalb Ubuntu statt. Für Windows- und WSL-Prozesse unterscheiden sich Netzwerkperspektiven: Im üblichen NAT-Aufbau ist der Zugriff aus Linux auf einen Windows-Dienst anders als der Rückweg; Mirrored Networking hat ein anderes Verhalten. Prüfe den tatsächlichen Zielserver anhand der Microsoft-Netzwerkhilfe, bevor du Bindungen änderst. Die WSL-Nutzung ist außerdem keine pauschale GPU-Freigabe aus einer nativen Linuxliste.

Offiziellen Installer bewusst verwenden

Die Linuxhilfe verweist auf das offizielle Installationsskript von ollama.com. Für einen nachvollziehbaren Ablauf kannst du es zunächst als Datei speichern und lesen. Verwende einen eigenen Arbeitsordner und prüfe die Quelle, bevor du einen Installationsbefehl ausführst.

curl -fsSL https://ollama.com/install.sh -o ollama-install.sh
less ollama-install.sh

Mit q verlässt du die Anzeige in less. Das Herunterladen und Lesen führt das Skript noch nicht aus. Erst der nächste Schritt installiert Software und kann Administratorrechte benötigen.

sh ollama-install.sh

Die offizielle Dokumentation beschreibt alternativ einen manuellen Weg mit zur Architektur passenden Archiven und eigener Diensteinrichtung. Vermische beide Verfahren nicht ohne Plan. Insbesondere gehören Löschbefehle aus einer Aktualisierungs- oder Deinstallationsanleitung nicht automatisch zu einer Neuinstallation.

Unsere Ablaufgrafik trennt den Installationsschritt vom Dienststart, der API-Prüfung und dem Modellversuch. Sie ist keine Ausgabe eines hier ausgeführten Installers.

Den Ollama-Dienst und die lokale API prüfen

Nach der Installation prüfst du zunächst die erreichbare Programmversion und den Serverdienst. Wenn der Dienst nicht läuft, lies seine Meldung, bevor du mehrfach einen zweiten Server mit ollama serve startest.

ollama --version
systemctl status ollama --no-pager
journalctl -u ollama --no-pager -n 80

Ein Status wie „active“ beschreibt den Dienstzustand. Er beweist noch nicht, dass ein bestimmtes Modell geladen wurde. Ein nicht aktiver oder fehlender Dienst ist dagegen zunächst ein Thema der Installation beziehungsweise Diensteverwaltung.

curl --fail http://127.0.0.1:11434/api/tags

Die Abfrage startet keine Modellgenerierung. Eine leere Modellliste ist etwas anderes als eine fehlgeschlagene Verbindung: Der Server kann bereits erreichbar sein, obwohl du noch keine Gewichte geladen hast.

Bei einer unklaren Verbindung kannst du den lokalen Ollama-Port und die Serveradresse prüfen. Beachte, dass Loopback auf einem entfernten Server nicht automatisch den Rechner bezeichnet, an dem dein Browser geöffnet ist.

Ein lokales Modell auswählen und erstmals laden

Wähle in der offiziellen Modellbibliothek einen konkreten lokalen Modelltag, dessen Variante und Voraussetzungen zu deinem Rechner passen. Prüfe Modellquelle, Lizenz und Speicherbedarf. Ersetze den Platzhalter in den folgenden Befehlen durch genau diesen vollständigen Tag.

ollama pull DEIN_LOKALES_MODELL
ollama run DEIN_LOKALES_MODELL

Der Download und das Laden in den Arbeitsspeicher sind verschiedene Vorgänge. Ein abgeschlossener Download sagt noch nicht, ob die gewählte Variante mit deinem Kontext und deiner sonstigen Systemlast ausführbar ist. Beginne mit einer kleinen, selbst prüfbaren Aufgabe.

Eigene fiktive Probe: „Fasse diesen Satz kürzer zusammen, ohne Zahl und Tag zu ändern: Der Test umfasst drei Aufgaben und findet am Freitag statt.“ Prüfe anschließend, ob drei Aufgaben und Freitag erhalten geblieben sind. Eine flüssige Antwort reicht als Abnahme nicht aus.

Öffne bei Bedarf ein zweites Terminal und kontrolliere mit ollama ps die geladenen Modelle. Die PROCESSOR-Spalte beschreibt die Speicherplatzierung auf CPU, GPU oder beiden; sie ist kein Tempobenchmark.

Bei einer AMD-Karte kannst du AMD-Support, ROCm und Vulkan getrennt prüfen. Eine vorhandene GPU ist keine allgemeine Freigabe für jede Modellgröße und Laufzeitkonfiguration.

Modelldaten und Dienstumgebung nachvollziehen

Die FAQ nennt für die Standard-Linuxinstallation den Modellpfad /usr/share/ollama/.ollama/models. Ein von dir manuell gestarteter Server, eine andere Installationsart oder ein Container kann einen anderen Datenpfad und Benutzer verwenden. Prüfe den tatsächlichen laufenden Aufbau.

Ein eigener Modellordner wird über OLLAMA_MODELS konfiguriert. Der Dienstbenutzer braucht Zugriff auf diesen Ordner. Ändere keine Eigentümer ganzer Verzeichnisbäume auf Verdacht; kläre zuerst, welcher konkrete Ordner und welcher Benutzer betroffen sind.

Bei einem systemd-Dienst reicht eine Variable in einem anderen Terminal nicht automatisch aus. Ollama beschreibt dafür sudo systemctl edit ollama.service. Ein Eintrag für den bewusst lokalen Server kann so aussehen:

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

Wenn du die Dienstkonfiguration selbst geändert hast, gehören sudo systemctl daemon-reload und sudo systemctl restart ollama sowie eine erneute Status- und Verbindungsprüfung dazu. Ein Neustart kann laufende Anfragen unterbrechen.

Die lokale Bindung ist der Standardweg für diesen Einstieg. Eine Freigabe für andere Rechner braucht eine eigene Prüfung von Netzwerk, Authentifizierung und Datenzugriff. Sie ist kein notwendiger Teil der Installation.

Fehler unter Ubuntu geordnet eingrenzen

Halte Fehlermeldung und Zeitpunkt fest und ändere jeweils nur eine Sache. Die Troubleshooting-Hilfe trennt unter anderem Dienstlogs, temporäre Ausführung und Hardwareerkennung. Ein GPU-Override ist keine allgemeine Lösung für einen falschen Pfad oder fehlende Modellgewichte.

Eigenes Ubuntu-/Ollama-Prüfblatt herunterladen. Es hält deine tatsächlichen Beobachtungen fest, ohne bereits bestandene Installations- oder Leistungstests vorzugeben.

Vor einem späteren Update notierst du Version und deinen Datenpfad. Stoppen, Aktualisieren und Deinstallieren sind unterschiedliche Aufgaben. Sichere eigene Einstellungen und benötigte Daten, bevor du bewusst einen bestehenden Aufbau veränderst.