~/tools / Ejecutar un LLM local en tu servidor / Ollama Log Reader

Ollama Log Reader — Lee un log de Ollama: memoria, capas en la GPU, contexto, velocidad

Pega el log del servidor de Ollama, de server.log, journalctl o docker logs, y la herramienta extrae lo importante: cuánta memoria usó cada carga de modelo y dónde (pesos, caché KV, buffers de cómputo, por CPU o GPU), cuántas capas fueron a la GPU, la longitud de contexto, las solicitudes y su estado, la velocidad del prompt y de la generación, y cada advertencia, con su explicación. Muestra cuándo se recortó un prompt para que cupiera en el contexto, cuándo un modelo no cupo en la memoria y cuándo Ollama volvió a cargar un modelo. Nada sale de tu navegador.

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

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

# Docker
docker logs <container-name>

# Windows
explorer %LOCALAPPDATA%\Ollama

Cuando Ollama va lento, las respuestas ignoran el principio de un prompt largo o una solicitud falla con un error 500, la explicación suele estar en el log del servidor. El log mezcla las líneas propias de Ollama (time=… level=… msg=…), una línea por solicitud HTTP ([GIN] …) y la salida de llama-server, el programa de llama.cpp que Ollama ejecuta para cargar cada modelo GGUF. Esta herramienta lee las tres cosas. Para cada carga de modelo muestra la longitud de contexto (-c), el número de solicitudes en paralelo (-np), el tipo y el tamaño del archivo del modelo, la longitud de contexto con la que se entrenó, cuántas capas se descargaron a la GPU, y la memoria de los pesos, de la caché KV y de los buffers de cómputo, por dispositivo. También lista las solicitudes con su estado y su duración, y la velocidad del prompt y de la generación que llama-server imprime después de cada solicitud. Después explica qué salió mal, usando los mensajes del código fuente de Ollama (v0.40.15). Cuando un prompt no cabe en el contexto, Ollama conserva los primeros num_keep tokens y el final del prompt, y descarta lo que hay en medio, hasta que el prompt ocupa aproximadamente la mitad del contexto: en nuestra prueba, un prompt de 633 tokens con num_ctx 256 se recortó a 130 tokens. Con truncate en false, la misma solicitud fue rechazada con un error 400. Un num_ctx superior a la longitud con la que se entrenó el modelo se reduce a esa longitud. Cuando un modelo no cabe en la memoria, la carga falla: en nuestra prueba en Linux con 1.9 GiB de memoria y sin GPU, qwen2.5:7b necesitó 4,460 MiB para sus pesos, llama-server se detuvo con signal: killed y la solicitud devolvió 500. Una línea que dice que llama-server terminó, seguida enseguida de un nuevo inicio, significa que Ollama estaba cargando el modelo otra vez con otros ajustes, no que se haya caído. El formato del log cambia de una versión a otra; la herramienta lee las líneas que conoce y omite el resto. Lo comprobamos con logs reales de Ollama 0.40.11 en macOS (Apple M1) y en Linux dentro de Docker, sin GPU.

La lógica principal de esta herramienta es de código abierto, con licencia MIT. github.com/seigo5555/toolkitbox-lib/src/ollama-log.ts