Ollama-Umgebungsvariablen und Dienstkonfiguration
Ollama hat keine traditionelle Konfigurationsdatei; nahezu das gesamte Dienstverhalten wird über Umgebungsvariablen gesteuert: Listen-Adresse, Modellpfad, Kontext, Parallelität, Proxy und Debugging.
Dieser Abschnitt behandelt zunächst die Einrichtungsmethoden für die drei Plattformen und erklärt anschließend jede Kernvariable im Detail über drei Ebenen hinweg: Netzwerkeinstieg, Anfrageplanung und Modell-Laufzeit.
Wo Konfigurationsvariablen im Dienst angesiedelt sind
Erstellen wir zuerst eine Übersicht: Die etwa ein Dutzend Umgebungsvariablen befinden sich nicht alle auf derselben Ebene; sie wirken jeweils auf unterschiedliche Phasen des Dienstprozesses.
Um die vollständige Liste der von der aktuellen Version unterstützten Variablen anzuzeigen, führen Sie `ollama serve --help` aus.
Wie man Umgebungsvariablen auf drei Plattformen setzt
Dieselbe Variable hat auf den drei Plattformen völlig unterschiedliche Einstiegspunkte für die Einrichtung; hier bleiben Anfänger am leichtesten hängen.
macOS：launchctl
Wenn Ollama als App läuft, müssen Umgebungsvariablen über launchctl injiziert werden; nach dem Festlegen müssen Sie die App neu starten, damit sie wirksam werden:
Beispiel
launchctl setenv OLLAMA_HOST "0.0.0.0:11434"
# Dann die Ollama-App beenden und erneut öffnen
Linux: systemd-Dienst-Override
Beispiel
sudo systemctl edit ollama.service
# Im Editor hinzufügen (Hinweis: muss unter dem Abschnitt [Service] stehen):
# [Service]
# Environment="OLLAMA_HOST=0.0.0.0:11434"
# Dienst neu laden und neu starten
sudo systemctl daemon-reload
sudo systemctl restart ollama
Windows: Systemumgebungsvariablen
Suchen Sie im Startmenü nach "Umgebungsvariablen", wählen Sie "Umgebungsvariablen für Ihr Konto bearbeiten", erstellen oder bearbeiten Sie die Variable und speichern Sie dann.
Wichtiger Schritt: Beenden Sie Ollama zuerst über das Tray, starten Sie es nach dem Speichern über das Startmenü neu; erst dann werden die neuen Variablen im neuen Prozess wirksam.
Es gibt außerdem eine JSON-Konfigurationsdatei server.json (zu finden unter ~/.ollama/) für eine kleine Anzahl von Umschalt-Einstellungen; schreiben Sie beispielsweise {"disable_ollama_cloud": true}, um Cloud-Funktionen zu deaktivieren. Die große Mehrheit der Konfiguration erfolgt weiterhin über Umgebungsvariablen.
Netzwerkzugang: HOST, ORIGINS und Proxy
OLLAMA_HOST: Lassen Sie Ihr LAN auf Ihre Modelle zugreifen
Standardmäßig lauscht es nur auf 127.0.0.1, sodass nur der lokale Rechner es nutzen kann; damit andere Geräte im LAN darauf zugreifen können, ändern Sie es so, dass es auf allen Netzwerkschnittstellen lauscht:
Beispiel
OLLAMA_HOST=0.0.0.0:11434 ollama serve
# Von einem anderen Gerät aus überprüfen (durch Ihre tatsächliche IP ersetzen)
curl http://192.168.1.100:11434/api/version
Die Öffnung für das LAN ist gleichbedeutend damit, einen nicht authentifizierten Modelldienst für alle Geräte im selben Subnetz freizugeben. In einem Heimnetzwerk ist das akzeptabel, aber in einem Unternehmensnetzwerk müssen Sie es mit Firewall-Regeln oder einem Reverse-Proxy kombinieren (ausführlich behandelt im Kapitel zur privaten Bereitstellung).
OLLAMA_ORIGINS: Cross-Origin-Allowlisting
Standardmäßig akzeptiert Ollama Cross-Origin-Anfragen nur von 127.0.0.1 und 0.0.0.0. Wenn Webseiten oder Browsererweiterungen direkt eine Verbindung zur lokalen API herstellen, müssen Sie sie explizit auf die Allowlist setzen:
Beispiel
OLLAMA_ORIGINS=chrome-extension://*,moz-extension://*,safari-web-extension://* ollama serve
Proxy: HTTPS_PROXY ist der Einzige, der benötigt wird
Modell-Downloads verwenden HTTPS für ausgehenden Datenverkehr; in netzwerkbeschränkten Umgebungen richten Sie HTTPS_PROXY einfach auf den Proxy.
Setzen Sie nur HTTPS_PROXY, nicht HTTP_PROXY: Ollama ruft Modelle nicht über HTTP ab, und das Hinzufügen eines HTTP-Proxys kann tatsächlich die Verbindung zwischen Client und Server unterbrechen. In Docker-Szenarien übergeben Sie -e HTTPS_PROXY=... beim Starten des Containers; wenn Sie einen Proxy mit selbstsigniertem Zertifikat verwenden, müssen Sie außerdem das CA-Zertifikat im System installieren (oder es in das Image einbacken).
Modell-Laufzeit: Pfad, Kontext und Keep-Alive
OLLAMA_MODELS: Modelle auf einem anderen Laufwerk speichern
Standardmäßig werden Modelle im Benutzerverzeichnis gespeichert; die Pfade für die drei Plattformen sind wie folgt:
| Plattform | Standard-Modellpfad |
|---|---|
| macOS | ~/.ollama/models |
| Linux | /usr/share/ollama/.ollama/models |
| Windows | C:\Users\<username>\.ollama\models |
Richten Sie OLLAMA_MODELS auf das neue Verzeichnis aus, um alles zu migrieren; nachdem die heruntergeladenen Modelldateien dorthin verschoben wurden, können sie direkt verwendet werden.
Beispiel
OLLAMA_MODELS=/data/ollama-models ollama serve
# Hinweis: Standard-Linux-Installationen führen den Dienst als Benutzer ollama aus
# Der Besitzer des neuen Verzeichnisses muss geändert werden, andernfalls hat der Dienst keine Lese-/Schreibberechtigung
sudo chown -R ollama:ollama /data/ollama-models
OLLAMA_CONTEXT_LENGTH: Globale Kontextlänge
Legt die Standardkontextlänge für alle Modelle fest; sie greift, wenn sie nicht auf Modell- oder Anfrageebene überschrieben wird:
Beispiel
OLLAMA_CONTEXT_LENGTH=8192 ollama serve
Priorität von höchster zu niedrigster: options.num_ctx in der API-Anfrage, PARAMETER num_ctx in der Modelfile, diese Umgebungsvariable und der automatische gestufte Standardwert basierend auf VRAM.
OLLAMA_KEEP_ALIVE: Globale Keep-Alive-Dauer
Passt einheitlich an, wie lange ein Modell nach dem Laden im Speicher bleibt; das Werteformat entspricht dem keep_alive-Parameter in der API:
Beispiel
OLLAMA_KEEP_ALIVE=30m ollama serve
Ein individuell in einer API-Anfrage übergebenes keep_alive hat Vorrang vor diesem globalen Wert, was eine gestufte Strategie ermöglicht wie "10 Minuten global, Schlüsselmodelle immer im Speicher."
Anfrageplanung: Das Nebenläufigkeits-Trio
Ollama unterstützt zwei Ebenen der Nebenläufigkeit: mehrere gleichzeitig geladene Modelle und ein einzelnes Modell, das mehrere Anfragen parallel bearbeitet – jeweils gesteuert durch eine eigene Variable.
| Variable | Standardwert | Zweck |
|---|---|---|
| OLLAMA_NUM_PARALLEL | 1 | Anzahl der Anfragen, die ein einzelnes Modell gleichzeitig bearbeitet; der benötigte Speicher skaliert mit diesem Wert × Kontextlänge |
| OLLAMA_MAX_LOADED_MODELS | 3 × Anzahl der GPUs (3 für CPU-Inferenz) | Gesamtzahl der Modelle, die gleichzeitig geladen werden dürfen, sofern VRAM/RAM sie aufnehmen kann |
| OLLAMA_MAX_QUEUE | 512 | Maximale Anzahl von in der Warteschlange befindlichen Anfragen, wenn der Dienst ausgelastet ist; darüber hinausgehende Anfragen geben sofort 503 zurück |
Die Planungslogik ist es wert, verstanden zu werden: Wenn VRAM ausreicht, verarbeiten Modelle Anfragen parallel; wenn VRAM nicht ausreicht, werden neue Anfragen in die Warteschlange gestellt und warten darauf, dass inaktive Modelle entladen werden und Speicher freigeben.
NUM_PARALLEL ist die Variable, die dich am ehesten ins Stolpern bringt: Wenn man sie auf 4 setzt, wird der Kontext-Cache mit 4 multipliziert, der VRAM-Verbrauch vervierfacht sich sofort, und Modelle können dadurch von der GPU verdrängt werden. Die Planung für gemeinsame Multi-User-Instanzen wird im Kapitel zur privaten Bereitstellung behandelt.
Debugging und Protokollierung: OLLAMA_DEBUG
Der erste Schritt bei der Fehlersuche ist immer, das Debugging zu aktivieren und die Protokolle zu prüfen.
Beispiel
OLLAMA_DEBUG=1 ollama serve
So aktivieren Sie das Debugging in der Windows-GUI-App: Beenden Sie die App zuerst über den Infobereich, und führen Sie dann in PowerShell aus:
Beispiel
& "ollama app.exe"
Zusammenfassung der Protokollspeicherorte in den vier Umgebungen:
| Umgebung | Protokollspeicherort |
|---|---|
| macOS | ~/.ollama/logs/server.log |
| Linux（systemd） | journalctl -u ollama --no-pager --follow --pager-end |
| Windows | %LOCALAPPDATA%\Ollama\server.log |
| Docker | docker logs <Containername> (stdout/stderr) |
Kurzübersicht für andere nützliche Variablen
Die verbleibenden Variablen sind größtenteils an bestimmte Szenarien gebunden; vollständige Erklärungen Kapitel für Kapitel werden in den entsprechenden Themenabschnitten behandelt. Hier erstellen wir zunächst einen Index.
| Variable | Beispielwert | Zweck |
|---|---|---|
| OLLAMA_FLASH_ATTENTION | 1 / 0 | Flash Attention ein-/ausschalten erzwingen; spart bei langen Kontexten deutlich VRAM (ausführlich im GPU-Kapitel) |
| OLLAMA_KV_CACHE_TYPE | q8_0 / q4_0 | Quantisierungstyp des KV-Cache; erfordert Flash Attention (ausführlich im GPU-Kapitel) |
| OLLAMA_VULKAN | 0 | Vulkan-Backend deaktivieren (ein Schalter für den Fall, dass Vulkan Fehlfunktionen aufweist) |
| OLLAMA_LLM_LIBRARY | cpu_avx2 | Eine bestimmte Inferenzbibliothek erzwingen, unter Umgehung der automatischen Erkennung |
| OLLAMA_TMPDIR | /data/tmp | Speicherort des Temp-Verzeichnisses ändern (wenn das systemweite /tmp mit noexec eingebunden ist) |
| OLLAMA_NO_CLOUD | 1 | Cloud-Modelle und Websuche deaktivieren; reiner lokaler Modus |