Ollama-FAQ
Dieses Kapitel verdichtet Fehlerbehebungswissen zu einem praktischen Nachschlagewerk: Beginnen Sie mit der Log-Analyse, triagieren Sie nach Symptom und decken Sie sechs Hauptkategorien von Problemen ab - unzureichender VRAM, Download-Fehler, Portkonflikte, GPU-Anomalien, Überlastung und Upgrade-Kompatibilität.
Der universelle erste Schritt: Zuerst die Logs prüfen
Ollamas Fehlermeldungen sind oft sehr kurz; die eigentliche Ursache steht fast immer in den Logs.
| Umgebung | Befehl / Speicherort anzeigen |
|---|---|
| macOS | cat ~/.ollama/logs/server.log |
| Linux（systemd） | journalctl -u ollama --no-pager --follow --pager-end |
| Windows | %LOCALAPPDATA%\Ollama\server.log |
| Docker | docker logs <container_name> |
| Manueller Start | Logs werden direkt im aktuellen Terminal ausgegeben |
Wenn die Standard-Logs nicht detailliert genug sind, aktivieren Sie den Debug-Modus und starten Sie den Dienst neu, um wichtige Prozesse wie GPU-Erkennung und VRAM-Schätzung zu sehen:
# 调试模式启动 OLLAMA_DEBUG=1 ollama serve
Wenn eine Anomalie auftritt, führen Sie zuerst eine Triage anhand des Navigationsdiagramms unten durch und springen Sie dann zum entsprechenden Abschnitt:
Nicht genügend VRAM / Arbeitsspeicher (OOM)
Dies ist das häufigste Laufzeitproblem; es äußert sich typischerweise dadurch, dass der Prozess mitten in der Generierung verschwindet, das System einfriert oder Speicherzuweisungsfehler in den Logs auftreten.
| Symptom | Ursache | Gegenmaßnahme |
|---|---|---|
| Prozess beim Laden eines großen Modells beendet | Nicht genügend physischer Arbeitsspeicher | Wechseln Sie zu einem kleineren Tag; oder verwenden Sie create, um zu quantisieren und die Größe zu reduzieren |
| Absturz während der Generierung | Kontextakkumulation lässt den KV-Cache wachsen | num_ctx verringern; Flash Attention und KV-Cache-Quantisierung aktivieren |
| Kollektiver Ausfall bei mehreren Anfragen | NUM_PARALLEL ist zu groß, VRAM-Nutzung vervielfacht sich | Setzen Sie ihn auf 1 zurück, und erhöhen Sie ihn dann schrittweise, während Sie ollama ps beobachten |
| Modell läuft, wird aber auf die CPU ausgelagert | VRAM ist etwas geringer als erforderlich | Hintergrund-VRAM-Nutzung freigeben; eine Parametergrößenstufe heruntergehen |
Das Diagnose-Befehlstrio: ollama ps zur Prüfung der Modellbelegung und des Split-Verhältnisses, nvidia-smi (oder rocm-smi) zur Prüfung des VRAM in Echtzeit und free -h zur Prüfung des Systemspeichers.
Fehler beim Modell-Download und wiederaufnehmbare Unterbrechungen
Download-Probleme liegen fast immer im Netzwerkpfad; die gute Nachricht ist, dass Ollama schichtweise wiederaufnehmbare Downloads unterstützt, wodurch Wiederholungsversuche sehr günstig sind.
| Symptom | Ursache | Gegenmaßnahme |
|---|---|---|
| Downloads werden wiederholt unterbrochen | Instabile Netzwerkverbindung zum Quellserver | Führen Sie denselben Befehl erneut aus, um fortzufahren; konfigurieren Sie HTTPS_PROXY, falls erforderlich |
| Schlägt auch nach der Konfiguration des Proxys weiterhin fehl | HTTP_PROXY wurde versehentlich gesetzt | Behalten Sie nur HTTPS_PROXY und löschen Sie HTTP_PROXY |
| Proxy-Zertifikatfehler | Ein selbstsigniertes Zertifikat wird nicht als vertrauenswürdig eingestuft | Installieren Sie das CA-Zertifikat als Systemzertifikat |
| Warnung bei unzureichendem Speicherplatz | Die Kapazität der Zielpartition reicht nicht aus | Speicherplatz freigeben oder OLLAMA_MODELS verwenden, um den Speicherpfad zu migrieren |
Portkonflikte und abgelehnte Verbindung
Wenn der Client "connection refused" meldet, bedeutet das im Kern, dass auf Port 11434 kein Dienst antwortet.
| Symptom | Ursache | Gegenmaßnahme |
|---|---|---|
| Lokale curl-Verbindung abgelehnt | Ollama-Dienst ist nicht gestartet | Öffne die App unter macOS / Windows; führe unter Linux sudo systemctl start ollama aus |
| Logs melden, dass der Port bereits belegt ist | 11434 wird von einem anderen Programm belegt | Beende den belegenden Prozess oder starte auf einem anderen Port: OLLAMA_HOST=127.0.0.1:11435 |
| Remote-Rechner können keine Verbindung herstellen | Dienst lauscht nur auf der Loopback-Adresse | Setze OLLAMA_HOST=0.0.0.0 auf der Serverseite und erlaube es durch die Firewall |
| Manuelle Linux-Installation beendet sich sofort nach dem Start | /tmp ist mit noexec eingebunden, Inferenzbibliothek kann nicht geladen werden | Legen Sie OLLAMA_TMPDIR so fest, dass es auf ein ausführbares Verzeichnis zeigt |
GPU nicht verwendet / Erkennungsfehler
Symptom ist, dass ollama ps 100% CPU anzeigt oder Logs einen GPU-Erkennungsfehler anzeigen. NVIDIA und AMD haben unterschiedliche Wege zur Fehlerbehebung.
NVIDIA-Besonderheiten
Prüfen Sie zuerst den Treiber und die Passthrough-Umgebung und gehen Sie dann gemäß den Fehlercodes im Log vor:
| Prüfpunkt | Methode |
|---|---|
| Treiberversion | nvidia-smi gibt normal aus; aktualisieren Sie auf den neuesten Treiber |
| Container-Passthrough | Wenn docker run --gpus all ubuntu nvidia-smi fehlschlägt, liegt ein Problem mit dem Container Toolkit vor |
| Anomalie des Treibermoduls | Mit sudo rmmod nvidia_uvm && sudo modprobe nvidia_uvm neu laden und erneut versuchen |
| Schlägt nach dem Aufwachen aus dem Suspend-Modus fehl | Nach Linux-Sleep/Wake das nvidia_uvm-Modul neu laden |
| Docker verliert nach langer Laufzeit die GPU | native.cgroupdriver=cgroupfs zu /etc/docker/daemon.json hinzufügen und Docker neu starten |
Die CUDA-Fehlercodes in den Logs sind es wert, sich gemerkt zu werden: 3 bedeutet nicht initialisiert, 46 bedeutet Gerät nicht verfügbar, 100 bedeutet kein Gerät, 999 bedeutet unbekannter Fehler - die meisten deuten auf Treiber- oder Passthrough-Konfiguration hin.
AMD-Besonderheiten
| Symptom | Ursache | Gegenmaßnahme |
|---|---|---|
| Unter Linux überhaupt nicht erkannt | Benutzer ist nicht in der Gruppe video / render | Den ausführenden Benutzer zur entsprechenden Gruppe hinzufügen und den Dienst neu starten |
| Logs zeigen Discovery-Timeout | ROCm-Treiber ist zu alt (unter v7) | ROCm v7 mit amdgpu-install aktualisieren und neu starten |
| Alte Karten werden nicht unterstützt | Die Architektur ist nicht in der offiziell unterstützten Liste | Versuchen Sie HSA_OVERRIDE_GFX_VERSION, um eine ähnliche Architektur anzugeben |
| Einige alte Karten haben unter Windows kein ROCm | Einschränkung des Treiber-Stacks | Verwenden Sie den Standard-Vulkan-Pfad; prüfen Sie GGML_VK_VISIBLE_DEVICES, falls ungewöhnlich |
Systematische Fehlersuche bei 503-Überlastung und langsamer Antwort
Verknüpfen Sie die Methoden aus den vorherigen Kapiteln zu einem festen Verfahren; innerhalb von sechs Schritten können Sie die überwiegende Mehrheit der Leistungsprobleme lokalisieren:
Schritt eins: Verwenden Sie ollama ps, um zu bestätigen, ob PROCESSOR 100 % GPU ist; wenn eine Aufteilung auftritt, kehren Sie zuerst zur VRAM-Optimierung zurück.
Schritt zwei: Prüfen Sie die Logs auf Einträge zu Warteschlangenbildung, Entladen oder Erkennungsfehlern.
Schritt drei: Das Empfangen von 503 bedeutet, dass die Warteschlange voll ist; prüfen Sie das Volumen gleichzeitiger Anfragen und OLLAMA_MAX_QUEUE und bewerten Sie, ob skaliert werden sollte.
Schritt vier: Verifizieren Sie in Multi-Benutzer-Szenarien mit gemeinsamer Nutzung die multiplikative Beziehung zwischen OLLAMA_NUM_PARALLEL und VRAM.
Schritt fünf: Prüfen Sie die keep_alive-Strategie: Häufiges Entladen und Neuladen führt zu einem starken Anstieg der First-Token-Latenz.
Schritt sechs: Verwenden Sie das usage-Feld der API, um Token/s zu berechnen, und vergleichen Sie es mit der historischen Baseline, um die Wirkung jeder Anpassung zu quantifizieren.
Kompatibilitätsprobleme nach dem Upgrade und Rollback
Wenn das Verhalten nach einem Upgrade abnormal ist, lösen drei Maßnahmen die meisten Fälle:
# 1. Linux 手动升级前先清理旧库，避免新旧混用 sudo rm -rf /usr/lib/ollama # 2. 回退到指定版本 curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.5.7 sh # 3. AMD 显卡同步升级 ROCm v7 驱动后重启
Verstümmelte Blöcke, die im Windows-Terminal erscheinen, sind ein altes Problem mit der Terminal-Schriftart und stehen nicht mit dem Modell in Verbindung; wechseln Sie einfach zu Windows Terminal.
Andere Erweiterungen