~/tools / 在自己的伺服器上執行本機 LLM / Ollama Log Reader

Ollama Log Reader — 讀取 Ollama 伺服器記錄：記憶體、GPU 層數、上下文、速度、警告

貼上 Ollama 的伺服器記錄（來自 server.log、journalctl 或 docker logs），工具會挑出重點：每次載入模型用了多少記憶體、用在哪裡（權重、KV cache、運算緩衝區，依 CPU 或 GPU 分開），有多少層放到了 GPU、上下文長度、請求與其狀態、提示詞與生成的速度，以及每一則警告與說明。它會顯示提示詞何時為了配合上下文而被截斷、模型何時放不進記憶體，以及 Ollama 何時重新載入了模型。資料不會離開你的瀏覽器。

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

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

# Docker
docker logs <container-name>

# Windows
explorer %LOCALAPPDATA%\Ollama

當 Ollama 變慢、回答忽略長提示詞的開頭，或請求以 500 錯誤失敗時，原因通常就在伺服器記錄裡。記錄中混有 Ollama 自己的行（time=… level=… msg=…）、每個 HTTP 請求一行（[GIN] …），以及 llama-server 的輸出，也就是 Ollama 為了載入每個 GGUF 模型而執行的 llama.cpp 程式。本工具會讀取這三種內容。每次載入模型時，它會顯示上下文長度（-c）、平行請求數（-np）、模型的檔案類型與大小、訓練時的上下文長度、有多少層被卸載到 GPU，以及權重、KV cache 與運算緩衝區各自使用的記憶體，並依裝置分開。它也會列出請求的狀態與耗時，以及 llama-server 在每個請求之後印出的提示詞與生成速度。接著它根據 Ollama 原始碼（v0.40.15）中的訊息，說明哪裡出了問題。當提示詞放不進上下文時，Ollama 會保留最前面的 num_keep 個 token 與提示詞的結尾，捨棄中間的部分，直到提示詞約佔上下文的一半：在我們的測試中，num_ctx 為 256 時，633 個 token 的提示詞被截斷為 130 個 token。將 truncate 設為 false 時，同一個請求被以 400 錯誤拒絕。高於模型訓練長度的 num_ctx 會被降到該長度。當模型放不進記憶體時，載入會失敗：在我們的測試中，在記憶體 1.9 GiB、沒有 GPU 的 Linux 上，qwen2.5:7b 光是權重就需要 4,460 MiB，llama-server 被以 signal: killed 停止，請求回傳 500。若有一行說 llama-server 已終止，隨即又重新啟動，代表 Ollama 正以其他設定重新載入模型，而不是當機。記錄的格式會隨版本而變；工具會讀取它認得的行，並略過其餘的行。我們用 Ollama 0.40.11 在 macOS（Apple M1）上，以及在沒有 GPU 的 Docker 內 Linux 上的真實記錄做過檢查。

這個工具的核心邏輯以 MIT 授權開放原始碼。 github.com/seigo5555/toolkitbox-lib/src/ollama-log.ts