ollama-top — Terminal-Monitor für Ollama, GPUs, Multi-Instance LLMs & Enterprise-Datenbanken

Wer lokale Large Language Models (LLMs) mit Ollama, llama.cpp oder vLLM in Entwicklungs- und Produktions-Pipelines betreibt, stößt bei der Überwachung schnell an Grenzen. Werkzeuge wie nvidia-smi, htop oder der Windows Task-Manager zeigen zwar GPU-Speicher und Kernauslastung an, bleiben jedoch stumm, wenn es um das Entscheidende geht: Wie viele Tokens pro Sekunde verarbeitet das Modell beim Prompt-Einlesen? Wie schnell generiert es die Ausgabe? Welches Modell belegt welchen Slot? Und welche Client-Prozesse kommunizieren gerade mit welchen Datenbank-Sockets?

🚀 Open Source auf GitHub

Vollständig quelloffen unter MIT-Lizenz. Multi-Instance-Tracking, dedizierte + integrierte GPU-Sensoren, universelle Datenbank-Socket-Erkennung und 1-Klick Installer.

Zum GitHub-Repository →

🎓 Inhouse-Training & Praxis

Lernen Sie lokale LLM-Integration, Hardware-Dimensionierung, Prompt Engineering und hochperformante Datenbank-Pipelines im Praxis-Seminar.

KI & Datenbank-Seminar ansehen →

1. Die Diagnose-Lücke: Warum Standard-Tools bei LLM-Workloads versagen

Klassische Systemmonitore wurden für herkömmliche Serverprozesse konzipiert, nicht für Memory-Bandwidth-getriebene Transformer-Netzwerke. In der Praxis führen typische Szenarien zu blinden Flecken:

nvidia-smi: Zeigt VRAM, Temperatur und Kernauslastung, kennt jedoch weder das geladene Modell noch das Context-Fenster oder die Generierungsgeschwindigkeit (Tokens/s).
Task-Manager / htop: Bieten keinen Einblick in Tensor-Kerne, GPU-Engines oder die Zuordnung von Client-Prozessen zu Remote-Datenbanken.
Ollama CLI (ollama ps): Liefert eine Momentaufnahme der geladenen Modelle, bietet jedoch keinen fortlaufenden Live-Refresh, keine Hardware-Sensoren und keine Durchsatz-Statistiken.

ollama-top (otop) schließt diese Lücke: Es kombiniert Hardware-Telemetrie (nvidia-smi, Windows Performance-Counter, /proc), die REST-APIs aller aktiven Ollama-Instanzen und die Socket-Zustände des Betriebssystems in einem kompakten Terminal-Dashboard.

2. Live-Dashboard: Terminal-Vorschau

Das Tool nutzt lückenlose Box-Drawing-Zeichen (─ und ═), um in Monospace-Terminals pixelgenaue Tabellen ohne Strich-Lücken darzustellen:

════════════════════════════════════════════════════════════════════════════════════════════════════════════
  OLLAMA-TOP: AI, DATABASE & HARDWARE MONITOR  |  09:30:00  |  Host: BLADE
  Author: Frank Glück (Glück IT)  |  Web: https://dozent.net  |  GitHub: https://github.com/glueck-it/ollama-top
────────────────────────────────────────────────────────────────────────────────────────────────────────────
  NVIDIA GPU SENSORS (GeForce RTX 5070 Ti):
  GPU Core Load:   [████████████████  ]  90%  | Clock: 2160 MHz
  GPU Memory Bus:  [████████████      ]  65%  | Clock: 11001 MHz
  VRAM Belegung:   [███████           ]  4.9 / 11.9 GB (41%)
  GPU Power/Temp:  114.3 W Power Draw  |  GPU Temp: 78° C

  HOST CPU & SYSTEM (Intel Core Ultra 9 275HX - 24C/24T):
  CPU Auslastung:  [████              ]  23%  | Clock: 2700 MHz
  System RAM:      [████████          ] 44.9 / 95.5 GB (47%)
  CPU Status/Temp: Package Thermal: 91° C   |  Architecture: x64 (24C/24T)

  INTEL NPU & iGPU SENSORS (Intel(R) AI Boost):
  NPU Neural Load: [                  ]   0%  | Engine: Neural (Standby / Ollama nutzt iGPU Vulkan)
  Intel iGPU Load: [██████████████████] 100%  | Device: Intel(R) Graphics

  NETWORK TRAFFIC & ADAPTER (Realtek USB GbE):
  Gesamt Live:     [In / Download] 48.2 KB/s   [Out / Upload] 12.4 KB/s   | Session: In 14.2 MB / Out 3.1 MB

  ACTIVE SERVICES & ENDPOINTS (Database, Cache & AI):
  PORT    SERVICE                 ENDPOINT / TARGET               SOCKETS       SCOPE / NETWORK             
────────────────────────────────────────────────────────────────────────────────────────────────────────────
  11434   Ollama (NVIDIA/Primary) 127.0.0.1:11434 (RTX 5070 Ti)   12 aktiv      Localhost IPC (Loopback)    
  11435   Ollama (iGPU/Secondary) 127.0.0.1:11435 (iGPU Vulkan)   6 aktiv       Localhost IPC (Loopback)    
  5432    PostgreSQL              192.168.1.150:5432              4 aktiv       Local LAN / On-Premise      

  LLM ENGINES & INFERENCE SPEED:
  PORT    MODEL / ENGINE          CONTEXT     VRAM/RAM    TOKENS IN (INPUT)         TOKENS OUT (GEN)        
────────────────────────────────────────────────────────────────────────────────────────────────────────────
  11434   gemma4:e4b              40960       3.04 GB     5.012 Tok/s               91.3 Tok/s              
  11435   gemma4:e4b              40960       3.60 GB     109 Tok/s                 9.8 Tok/s               

  Stats Port 11434 (gemma4:e4b):
    Tokens In:   Min: 5.012 | Max: 5.012 | Avg: 5.012 | Med: 5.012 Tok/s  (n=12)
    Tokens Out:  Min:  88.5 | Max:  94.2 | Avg:  91.3 | Med:  91.3 Tok/s  (n=12)

  Stats Port 11435 (gemma4:e4b):
    Tokens In:   Min:    97 | Max:   112 | Avg:   104 | Med:   104 Tok/s  (n=8)
    Tokens Out:  Min:   9.5 | Max:  10.2 | Avg:   9.8 | Med:   9.8 Tok/s  (n=8)

  ACTIVE CLIENTS & PARALLEL WORKERS: [4 parallel verbunden]
  PID      CLIENT          TARGET ENDPOINT                 LOCAL PORT    MEMORY            CPU TIME         
────────────────────────────────────────────────────────────────────────────────────────────────────────────
  18504    php             127.0.0.1:11434                 64297         41.4 MB           4.9 s            
  20380    php             127.0.0.1:11434                 58296         41.3 MB           5.1 s            
  35284    php             127.0.0.1:11435                 61306         47.1 MB           3.8 s            
  39824    php             192.168.1.150:5432              58189         41.7 MB           4.7 s            
════════════════════════════════════════════════════════════════════════════════════════════════════════════
  Refresh: 1.2s  |  [Leertaste]/[R]: Reset  |  https://dozent.net  |  https://github.com/glueck-it/ollama-top

3. Das NPU-Mysterium: Warum NPU Neural Load bei 0 % steht

Eine häufige Frage beim Betrieb von Ollama auf modernen Intel Core Ultra- oder AMD Ryzen AI-Prozessoren lautet: „Mein Prozessor besitzt eine NPU (z. B. Intel AI Boost mit 13–48 TOPS) — warum zeigt das Monitoring 0 % NPU-Last, während die integrierte Grafikkarte (iGPU) unter 100 % Volllast läuft?“

Die Ursache liegt in der Software-Architektur lokaler LLM-Engines:

Vulkan vs. OpenVINO: Ollama nutzt für Nicht-NVIDIA-Hardware standardmäßig die Schnittstelle Vulkan (oder SYCL). Vulkan steuert universelle GPU-Shader an — und läuft damit auf den Ausführungseinheiten der Intel Arc / Intel Graphics iGPU.
Spezialisierung der NPU: Die NPU ist ein separater ASIC-Hardwareblock auf dem Prozessor-Die. Sie versteht kein allgemeines Vulkan, sondern setzt herstellerspezifische Bibliotheken wie Intel OpenVINO oder Microsoft DirectML voraus.
Bandbreitenvorteil der iGPU bei LLMs: Aktuelle NPUs sind für extrem stromsparende INT8/INT4-Dauerlasten (Webcam-Filter, Eye-Contact, Audio-DSP) gebaut. LLM-Inferenz ist jedoch primär durch die Speicherbandbreite limitiert und profitiert massiv von FP16/BF16-Shadern und schnellem LPDDR5X/DDR5-RAM-Zugriff. Die iGPU erzielt über Vulkan mit ~10 Tok/s in der Praxis oft eine spürbar höhere Leistung als die NPU.

4. Multi-Instance Inferenz: Dedizierte GPU + iGPU parallel nutzen

In rechenintensiven Daten-Pipelines (z. B. Batch-Klassifikation von Dokumenten oder Log-Analysen) ist eine einzelne GPU oft der Engpass. ollama-top unterstützt die gleichzeitige Überwachung mehrerer Ollama-Daemons auf getrennten Ports:

Port 11434 (Primär / NVIDIA RTX CUDA): Verarbeitet große Dokumente mit Höchstgeschwindigkeit (~90–100 Tok/s Generation, ~5.000 Tok/s Prompt-Eval).
Port 11435 (Sekundär / Intel iGPU via Vulkan): Übernimmt gezielt kleine Anfragen oder kurze Klassifikationen (~10 Tok/s Generation, ~100 Tok/s Prompt-Eval).

Produktivgewinn: Das Auslagern kleinerer Aufgaben auf die integrierte Grafikeinheit entlastet die NVIDIA-GPU von ständigen Kontextwechseln. In unseren Tests stieg der Gesamtdurchsatz der Batch-Pipeline um 15 bis 20 %, ohne zusätzlichen Stromverbrauch durch externe Hardware.

5. Universal Database & Socket Scoping

Ein KI-Modell arbeitet selten isoliert. In Produktionsanwendungen liest ein Worker-Skript (in Python, PHP, Perl oder Node.js) Datensätze aus einer Datenbank, schickt den Prompt an Ollama und schreibt das Ergebnis zurück.

ollama-top enthält einen integrierten Enterprise-Service-Katalog und klassifiziert Verbindungen automatisch nach Netzwerk-Scope:

Localhost IPC (Loopback): Verbindung zu lokalen KI-Servern (127.0.0.1:11434).
Local LAN / On-Premise: Verbindung zu internen Datenbank-Clustern in privaten Netzen (10.x, 192.168.x, 172.16-31.x).
Remote WAN / Cloud: Externe Datenbank- und API-Verbindungen.

Erkannte Datenbanksysteme umfassen:

Enterprise RDBMS: Oracle (1521), Microsoft SQL Server (1433), IBM DB2 (50000), IBM Informix (9088), SAP HANA (30015, 39015).
Open Source & Web: PostgreSQL (5432–5440, PgBouncer 6432), MySQL / MariaDB (3306, 3307).
Caches & Queues: Redis (6379), MongoDB (27017), Apache Cassandra (9042), ClickHouse (8123, 9000), Apache Kafka (9092), RabbitMQ (5672).

6. Installation & Schnellstart

ollama-top benötigt keine externen Paketmanager oder Drittanbieter-Module (Zero Dependencies).

Windows (PowerShell 5.1 & Core 7+)

Installation über den 1-Klick One-Liner:

irm https://raw.githubusercontent.com/glueck-it/ollama-top/main/install.ps1 | iex

Starten über:

otop

Linux & macOS (Bash)

Installation via curl:

curl -fsSL https://raw.githubusercontent.com/glueck-it/ollama-top/main/install.sh | bash

Starten:

otop

Batch-Pipelines überwachen (Progress Bar & ETA)

Jedes Skript mit Fortschrittsausgabe kann direkt in ollama-top gepiped werden:

python process_batch.py | otop -Total 5000 -Title "ETL Ingestion Pipeline"

7. Open Source auf GitHub

Der Quellcode, Shell-Skripte und Dokumentation stehen unter der MIT-Lizenz frei zur Verfügung:

👉 GitHub-Repository: https://github.com/glueck-it/ollama-top

8. Vertiefende Seminare & Praxis-Schulungen

Sie möchten lokale Sprachmodelle, Inferenz-Pipelines und hochperformante Datenbanken produktionsreif in Ihrem Unternehmen etablieren?

Auf dozent.net bietet Dozent Frank Glück praxisnahe Inhouse- und Remote-Seminare für Entwickler, Datenarchitekten und Administratoren:

🎓 Datenbankanalysen mit KI – SQL-Seminar mit AI: Praxis-Einsatz von LLMs zur Abfrage- und Datenanalyse.
🎓 PostgreSQL Administration & Performance-Tuning: Hochverfügbarkeit, Autovacuum, Connection Pooling und Index-Optimierung.
🎓 Datenbankübergreifendes Performance-Tuning: Ursachenforschung für langsame Queries über PostgreSQL, Oracle und SQL Server hinweg.

Alle Schulungen werden maßgeschneidert auf Ihre bestehende Infrastruktur und Ihren Technologiestack abgestimmt.