~/tools / Eseguire un LLM locale sul tuo server / Ollama Log Reader

Ollama Log Reader — Leggi un log di Ollama: memoria, layer sulla GPU, contesto, velocità

Incolla il log del server di Ollama, da server.log, journalctl o docker logs, e lo strumento ne estrae ciò che conta: quanta memoria ha usato ogni caricamento di modello e dove (pesi, cache KV, buffer di calcolo, per CPU o GPU), quanti layer sono andati sulla GPU, la lunghezza del contesto, le richieste e il loro stato, la velocità del prompt e della generazione, e ogni avviso, con una spiegazione. Mostra quando un prompt è stato tagliato per stare nel contesto, quando un modello non è entrato in memoria e quando Ollama ha ricaricato un modello. Nulla lascia il tuo browser.

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

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

# Docker
docker logs <container-name>

# Windows
explorer %LOCALAPPDATA%\Ollama

Quando Ollama è lento, le risposte ignorano l'inizio di un prompt lungo o una richiesta fallisce con un errore 500, la spiegazione di solito è nel log del server. Il log mescola le righe di Ollama stesso (time=… level=… msg=…), una riga per ogni richiesta HTTP ([GIN] …) e l'output di llama-server, il programma di llama.cpp che Ollama esegue per caricare ogni modello GGUF. Questo strumento legge tutte e tre le cose. Per ogni caricamento di modello mostra la lunghezza del contesto (-c), il numero di richieste parallele (-np), il tipo e la dimensione del file del modello, la lunghezza del contesto con cui è stato addestrato, quanti layer sono stati scaricati sulla GPU, e la memoria dei pesi, della cache KV e dei buffer di calcolo, per dispositivo. Elenca anche le richieste con il loro stato e la loro durata, e la velocità del prompt e della generazione che llama-server stampa dopo ogni richiesta. Poi spiega che cosa è andato storto, usando i messaggi del codice sorgente di Ollama (v0.40.15). Quando un prompt non sta nel contesto, Ollama conserva i primi num_keep token e la fine del prompt, e scarta ciò che sta in mezzo, finché il prompt occupa circa metà del contesto: nel nostro test, un prompt di 633 token con num_ctx 256 è stato tagliato a 130 token. Con truncate impostato a false, la stessa richiesta è stata rifiutata con un errore 400. Un num_ctx superiore alla lunghezza con cui il modello è stato addestrato viene ridotto a quella lunghezza. Quando un modello non entra in memoria, il caricamento fallisce: nel nostro test su Linux con 1.9 GiB di memoria e senza GPU, qwen2.5:7b aveva bisogno di 4,460 MiB per i pesi, llama-server è stato fermato con signal: killed e la richiesta ha restituito 500. Una riga che dice che llama-server è terminato, seguita subito da un nuovo avvio, significa che Ollama stava caricando di nuovo il modello con altre impostazioni, non che è andato in crash. Il formato del log cambia da una versione all'altra; lo strumento legge le righe che conosce e salta le altre. L'abbiamo verificato con log reali di Ollama 0.40.11 su macOS (Apple M1) e su Linux in Docker, senza GPU.

La logica principale di questo strumento è open source, con licenza MIT. github.com/seigo5555/toolkitbox-lib/src/ollama-log.ts