~/tools / Rodar um LLM local no seu servidor / Ollama Log Reader

Ollama Log Reader — Leia um log do Ollama: memória, camadas na GPU, contexto, velocidade

Cole o log do servidor do Ollama, de server.log, journalctl ou docker logs, e a ferramenta extrai o que importa: quanta memória cada carga de modelo usou e onde (pesos, KV cache, buffers de computação, por CPU ou GPU), quantas camadas foram para a GPU, o tamanho do contexto, as requisições e o status delas, a velocidade do prompt e da geração, e cada aviso, com uma explicação. Ela mostra quando um prompt foi cortado para caber no contexto, quando um modelo não coube na memória e quando o Ollama recarregou um modelo. Nada sai do seu navegador.

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

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

# Docker
docker logs <container-name>

# Windows
explorer %LOCALAPPDATA%\Ollama

Quando o Ollama está lento, as respostas ignoram o início de um prompt longo ou uma requisição falha com um erro 500, a explicação costuma estar no log do servidor. O log mistura as linhas do próprio Ollama (time=… level=… msg=…), uma linha por requisição HTTP ([GIN] …) e a saída do llama-server, o programa do llama.cpp que o Ollama executa para carregar cada modelo GGUF. Esta ferramenta lê as três coisas. Para cada carga de modelo, mostra o tamanho do contexto (-c), o número de requisições paralelas (-np), o tipo e o tamanho do arquivo do modelo, o tamanho de contexto com que ele foi treinado, quantas camadas foram descarregadas para a GPU, e a memória dos pesos, do KV cache e dos buffers de computação, por dispositivo. Ela também lista as requisições com seu status e duração, e a velocidade do prompt e da geração que o llama-server imprime depois de cada requisição. Depois explica o que deu errado, usando as mensagens do código-fonte do Ollama (v0.40.15). Quando um prompt não cabe no contexto, o Ollama mantém os primeiros num_keep tokens e o final do prompt, e descarta o que está no meio, até que o prompt ocupe cerca de metade do contexto: no nosso teste, um prompt de 633 tokens com num_ctx 256 foi cortado para 130 tokens. Com truncate definido como false, a mesma requisição foi rejeitada com um erro 400. Um num_ctx acima do tamanho com que o modelo foi treinado é reduzido a esse tamanho. Quando um modelo não cabe na memória, a carga falha: no nosso teste em Linux com 1.9 GiB de memória e sem GPU, o qwen2.5:7b precisou de 4,460 MiB para os pesos, o llama-server foi parado com signal: killed e a requisição retornou 500. Uma linha dizendo que o llama-server terminou, seguida logo por um novo início, significa que o Ollama estava carregando o modelo de novo com outras configurações, não que ele travou. O formato do log muda de versão para versão; a ferramenta lê as linhas que conhece e ignora o resto. Nós a verificamos com logs reais do Ollama 0.40.11 em macOS (Apple M1) e em Linux no Docker, sem GPU.

A lógica principal desta ferramenta é de código aberto, sob a licença MIT. github.com/seigo5555/toolkitbox-lib/src/ollama-log.ts