~/tools / Lokalny LLM na własnym serwerze / Ollama Log Reader

Ollama Log Reader — Czytaj log serwera Ollamy: pamięć, warstwy GPU, kontekst, szybkość, ostrzeżenia

Wklej log serwera Ollamy, z server.log, journalctl lub docker logs, a narzędzie wybierze to, co ważne: ile pamięci zajęło każde załadowanie modelu i gdzie (wagi, KV cache, bufory obliczeniowe, osobno dla CPU i GPU), ile warstw trafiło na GPU, długość kontekstu, żądania i ich status, szybkość przetwarzania promptu i generowania oraz każde ostrzeżenie wraz z wyjaśnieniem. Pokazuje, kiedy prompt został przycięty, żeby zmieścić się w kontekście, kiedy model nie zmieścił się w pamięci i kiedy Ollama załadowała model ponownie. Nic nie opuszcza Twojej przeglądarki.

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

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

# Docker
docker logs <container-name>

# Windows
explorer %LOCALAPPDATA%\Ollama

Gdy Ollama działa wolno, odpowiedzi pomijają początek długiego promptu albo żądanie kończy się błędem 500, wyjaśnienie zwykle znajduje się w logu serwera. Log miesza własne wiersze Ollamy (time=… level=… msg=…), po jednym wierszu na każde żądanie HTTP ([GIN] …) oraz wyjście llama-server, programu llama.cpp, którym Ollama ładuje każdy model GGUF. To narzędzie czyta wszystkie trzy. Dla każdego załadowania modelu pokazuje długość kontekstu (-c), liczbę równoległych żądań (-np), typ i rozmiar pliku modelu, długość kontekstu, na jaką model był trenowany, ile warstw przeniesiono na GPU oraz pamięć na wagi, KV cache i bufory obliczeniowe, osobno dla każdego urządzenia. Wypisuje też żądania wraz ze statusem i czasem trwania oraz szybkość przetwarzania promptu i generowania, którą llama-server wypisuje po każdym żądaniu. Następnie wyjaśnia, co poszło nie tak, na podstawie komunikatów z kodu źródłowego Ollamy (v0.40.15). Gdy prompt nie mieści się w kontekście, Ollama zachowuje pierwsze num_keep tokenów i koniec promptu, a to, co jest pomiędzy, usuwa, aż prompt zajmie mniej więcej połowę kontekstu: w naszym teście prompt o długości 633 tokenów przy num_ctx 256 został przycięty do 130 tokenów. Przy truncate ustawionym na false to samo żądanie zostało odrzucone z błędem 400. Wartość num_ctx większa od długości, na jaką model był trenowany, jest obniżana do tej długości. Gdy model nie mieści się w pamięci, ładowanie kończy się niepowodzeniem: w naszym teście na Linuxie z 1.9 GiB pamięci i bez GPU qwen2.5:7b potrzebował na wagi 4,460 MiB, llama-server został zatrzymany z signal: killed, a żądanie zwróciło 500. Wiersz mówiący, że llama-server zakończył działanie, po którym od razu następuje nowy start, oznacza, że Ollama ładowała model ponownie z innymi ustawieniami, a nie że uległa awarii. Format logu zmienia się z wydania na wydanie; narzędzie czyta znane sobie wiersze i pomija resztę. Sprawdziliśmy je na prawdziwych logach z Ollamy 0.40.11 na macOS (Apple M1) oraz na Linuxie w Dockerze, bez GPU.

Główna logika tego narzędzia jest otwartoźródłowa, na licencji MIT. github.com/seigo5555/toolkitbox-lib/src/ollama-log.ts