~/tools / Ein lokales LLM auf dem eigenen Server / Ollama Log Reader

Ollama Log Reader — Ollama-Server-Log lesen: Speicher, GPU-Schichten, Kontext, Tempo, Warnungen

Fügen Sie das Server-Log von Ollama ein, aus server.log, journalctl oder docker logs, und das Tool zieht heraus, worauf es ankommt: wie viel Speicher jedes Laden eines Modells gebraucht hat und wo (Gewichte, KV-Cache, Compute-Puffer, je CPU oder GPU), wie viele Schichten auf die GPU gingen, die Kontextlänge, die Anfragen mit ihrem Status, die Geschwindigkeit bei Prompt und Generierung und jede Warnung samt Erklärung. Es zeigt, wann ein Prompt gekürzt wurde, damit er in den Kontext passt, wann ein Modell nicht in den Speicher passte und wann Ollama ein Modell neu geladen hat. Nichts verlässt Ihren Browser.

# macOS
cat ~/.ollama/logs/server.log

# Linux (systemd)
journalctl -u ollama --no-pager

# Docker
docker logs <container-name>

# Windows
explorer %LOCALAPPDATA%\Ollama

Wenn Ollama langsam ist, Antworten den Anfang eines langen Prompts ignorieren oder eine Anfrage mit einem 500-Fehler scheitert, steht die Erklärung meist im Server-Log. Das Log mischt Ollamas eigene Zeilen (time=… level=… msg=…), eine Zeile pro HTTP-Anfrage ([GIN] …) und die Ausgabe von llama-server, dem llama.cpp-Programm, mit dem Ollama jedes GGUF-Modell lädt. Dieses Tool liest alle drei. Für jedes Laden eines Modells zeigt es die Kontextlänge (-c), die Zahl paralleler Anfragen (-np), Dateityp und Größe des Modells, die Kontextlänge, für die es trainiert wurde, wie viele Schichten auf die GPU ausgelagert wurden und den Speicher für die Gewichte, den KV-Cache und die Compute-Puffer, je Gerät. Es listet außerdem die Anfragen mit Status und Dauer auf sowie die Prompt- und Generierungsgeschwindigkeit, die llama-server nach jeder Anfrage ausgibt. Danach erklärt es, was schiefgelaufen ist, anhand der Meldungen im Quellcode von Ollama (v0.40.15). Wenn ein Prompt nicht in den Kontext passt, behält Ollama die ersten num_keep Tokens und das Ende des Prompts und verwirft, was dazwischen liegt, bis der Prompt etwa die Hälfte des Kontexts belegt: In unserem Test wurde ein Prompt mit 633 Tokens bei num_ctx 256 auf 130 Tokens gekürzt. Mit truncate auf false wurde dieselbe Anfrage mit einem 400-Fehler abgelehnt. Ein num_ctx über der Länge, für die das Modell trainiert wurde, wird auf diese Länge gesenkt. Wenn ein Modell nicht in den Speicher passt, schlägt das Laden fehl: In unserem Test unter Linux mit 1.9 GiB Speicher und ohne GPU brauchte qwen2.5:7b für seine Gewichte 4,460 MiB, llama-server wurde mit signal: killed gestoppt, und die Anfrage lieferte 500. Eine Zeile, die besagt, dass llama-server beendet wurde, gefolgt von einem sofortigen Neustart, bedeutet, dass Ollama das Modell mit anderen Einstellungen erneut geladen hat, und nicht, dass es abgestürzt ist. Das Format des Logs ändert sich von Version zu Version; das Tool liest die Zeilen, die es kennt, und überspringt den Rest. Wir haben es mit echten Logs von Ollama 0.40.11 unter macOS (Apple M1) und unter Linux in Docker ohne GPU geprüft.

Die Kernlogik dieses Tools ist Open Source unter der MIT-Lizenz. github.com/seigo5555/toolkitbox-lib/src/ollama-log.ts