~/tools / ローカルLLMをサーバーで動かす / Ollama Log Reader

Ollama Log Reader — Ollama のログからメモリ・GPU・速度を読む

Ollama のサーバーログ(server.log、journalctl、docker logs のもの)を貼り付けると、重要な点を抜き出します。モデルを読み込むたびにどれだけのメモリをどこで使ったか(重みと KV キャッシュ、計算用バッファを 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 リクエストごとの1行([GIN] …)、そして Ollama が各 GGUF モデルを読み込むために実行する llama.cpp のプログラム llama-server の出力が混ざっています。このツールはその3種類をすべて読みます。モデルを読み込むたびに、コンテキスト長(-c)、並列リクエスト数(-np)、モデルのファイル形式とサイズ、学習時のコンテキスト長、GPU にオフロードされたレイヤー数、重みと KV キャッシュと計算用バッファのメモリをデバイスごとに表示します。また、リクエストをステータスと所要時間つきで一覧にし、llama-server が各リクエストの後に出力するプロンプトと生成の速度も示します。そのうえで、Ollama のソースコード(v0.40.15)のメッセージに基づいて、何が起きたかを説明します。プロンプトがコンテキストに収まらないとき、Ollama は先頭の num_keep トークンとプロンプトの末尾を残して間を捨て、プロンプトがコンテキストのおよそ半分になるまで切り詰めます。私たちのテストでは、num_ctx 256 に対して 633 トークンのプロンプトが 130 トークンに切り詰められました。truncate を false にすると、同じリクエストは 400 エラーで拒否されました。モデルの学習時の長さを超える num_ctx は、その長さまで下げられます。モデルがメモリに収まらないと、読み込みに失敗します。私たちのテストでは、メモリ 1.9 GiB で GPU のない Linux で、qwen2.5:7b の重みに 4,460 MiB が必要となり、llama-server は signal: killed で止められ、リクエストは 500 を返しました。llama-server が終了したという行のすぐ後に新しい起動が続く場合は、クラッシュではなく、Ollama が別の設定でモデルを読み込み直していることを意味します。ログの形式はリリースごとに変わります。このツールは知っている行を読み、それ以外は読み飛ばします。macOS (Apple M1)と、GPU のない Docker 上の Linux での Ollama 0.40.11 の実際のログで確認しました。

このツールの計算部分は、オープンソース(MIT ライセンス)で公開しています。 github.com/seigo5555/toolkitbox-lib/src/ollama-log.ts