~/tools / Run a local LLM on your server / Ollama Log Reader

Ollama Log Reader — Read an Ollama server log: memory, GPU layers, context, speed, warnings

Paste the server log of Ollama, from server.log, journalctl or docker logs, and the tool picks out what matters: how much memory each model load took and where (weights, KV cache, compute buffers, per CPU or GPU), how many layers went to the GPU, the context length, the requests and their status, the prompt and generation speed, and every warning, with an explanation. It shows when a prompt was cut to fit the context, when a model did not fit in memory, and when Ollama reloaded a model. Nothing leaves your browser.

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

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

# Docker
docker logs <container-name>

# Windows
explorer %LOCALAPPDATA%\Ollama

When Ollama is slow, answers ignore the start of a long prompt, or a request fails with a 500 error, the explanation is usually in the server log. The log mixes Ollama's own lines (time=… level=… msg=…), one line per HTTP request ([GIN] …), and the output of llama-server, the llama.cpp program that Ollama runs to load each GGUF model. This tool reads all three. For each model load it shows the context length (-c), the number of parallel requests (-np), the model's file type and size, the context length it was trained for, how many layers were offloaded to the GPU, and the memory for the weights, the KV cache and the compute buffers, per device. It also lists the requests with their status and duration, and the prompt and generation speed that llama-server prints after each request. Then it explains what went wrong, using the messages in Ollama's source code (v0.40.15). When a prompt does not fit in the context, Ollama keeps the first num_keep tokens and the end of the prompt, and drops what is in between, until the prompt takes about half of the context: in our test, a prompt of 633 tokens with num_ctx 256 was cut to 130 tokens. With truncate set to false, the same request was rejected with a 400 error. A num_ctx above the length the model was trained for is lowered to that length. When a model does not fit in memory, loading fails: in our test on Linux with 1.9 GiB of memory and no GPU, qwen2.5:7b needed 4,460 MiB for its weights, llama-server was stopped with signal: killed, and the request returned 500. A line saying that llama-server terminated, followed right away by a new start, means that Ollama was loading the model again with other settings, not that it crashed. The format of the log changes from release to release; the tool reads the lines it knows and skips the rest. We checked it against real logs from Ollama 0.40.11 on macOS (Apple M1) and on Linux in Docker, without a GPU.

The core logic of this tool is open source under the MIT License. github.com/seigo5555/toolkitbox-lib/src/ollama-log.ts