~/tools / Faire tourner un LLM local sur votre serveur / Ollama Log Reader

Ollama Log Reader — Lisez un journal Ollama : mémoire, couches GPU, contexte, vitesse

Collez le journal du serveur d'Ollama, issu de server.log, de journalctl ou de docker logs, et l'outil en extrait l'essentiel : la mémoire que chaque chargement de modèle a prise et où (poids, KV cache, tampons de calcul, par CPU ou GPU), le nombre de couches placées sur le GPU, la longueur de contexte, les requêtes et leur statut, la vitesse du prompt et de la génération, et chaque avertissement, avec une explication. Il montre quand un prompt a été coupé pour tenir dans le contexte, quand un modèle n'a pas tenu en mémoire et quand Ollama a rechargé un modèle. Rien ne quitte votre navigateur.

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

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

# Docker
docker logs <container-name>

# Windows
explorer %LOCALAPPDATA%\Ollama

Quand Ollama est lent, que les réponses ignorent le début d'un long prompt ou qu'une requête échoue avec une erreur 500, l'explication se trouve généralement dans le journal du serveur. Le journal mélange les lignes propres à Ollama (time=… level=… msg=…), une ligne par requête HTTP ([GIN] …) et la sortie de llama-server, le programme de llama.cpp qu'Ollama exécute pour charger chaque modèle GGUF. Cet outil lit ces trois sources. Pour chaque chargement de modèle, il indique la longueur de contexte (-c), le nombre de requêtes parallèles (-np), le type et la taille du fichier du modèle, la longueur de contexte pour laquelle il a été entraîné, le nombre de couches déchargées sur le GPU, et la mémoire des poids, du KV cache et des tampons de calcul, par appareil. Il liste aussi les requêtes avec leur statut et leur durée, ainsi que la vitesse du prompt et de la génération que llama-server affiche après chaque requête. Ensuite, il explique ce qui s'est mal passé, à partir des messages du code source d'Ollama (v0.40.15). Quand un prompt ne tient pas dans le contexte, Ollama garde les num_keep premiers tokens et la fin du prompt, et supprime ce qui se trouve entre les deux, jusqu'à ce que le prompt occupe environ la moitié du contexte : dans notre test, un prompt de 633 tokens avec num_ctx 256 a été coupé à 130 tokens. Avec truncate à false, la même requête a été rejetée avec une erreur 400. Un num_ctx supérieur à la longueur pour laquelle le modèle a été entraîné est ramené à cette longueur. Quand un modèle ne tient pas en mémoire, le chargement échoue : dans notre test sous Linux avec 1.9 GiB de mémoire et sans GPU, qwen2.5:7b avait besoin de 4,460 MiB pour ses poids, llama-server a été arrêté avec signal: killed et la requête a renvoyé 500. Une ligne indiquant que llama-server s'est terminé, suivie aussitôt d'un nouveau démarrage, signifie qu'Ollama rechargeait le modèle avec d'autres réglages, pas qu'il a planté. Le format du journal change d'une version à l'autre ; l'outil lit les lignes qu'il connaît et ignore les autres. Nous l'avons vérifié avec de vrais journaux d'Ollama 0.40.11 sous macOS (Apple M1) et sous Linux dans Docker, sans GPU.

Le cœur de cet outil est open source, sous licence MIT. github.com/seigo5555/toolkitbox-lib/src/ollama-log.ts