Übersicht
Live-Zustand des Gateways
––
Traffic
Requests und Credits der letzten Ereignisse
System
Scheduler und Worker
Top Modelle
nach Compute Credits
Letzte Requests
ohne Prompt-/Response-Inhalte
Request Pulse Map
Echte Request-Lifecycles als animierter Datenfluss: Tenant → Admission → Fair Queue → Worker; Streaming-Pulse laufen zurück zum Client.
verbinde …
Warte auf laufende Requests …
QueueComputeStreamingFinished
Aktive Requests
Keine Prompts oder Antworten – nur Routing-, Timing- und Usage-Metadaten.
Worker-Pulse
Aktuelle Request-Verteilung auf die Ollama-Worker.
LLM Infrastructure Map
Lokale Echtzeit-Topologie aus der In-Memory-Engine: Tenant → Gateway → Fair Queue → Ollama Worker → geladenes Modell. Request-Pulse bewegen sich auf dem tatsächlichen Routing-Pfad.
verbinde …
Warte auf In-Memory-Telemetrie …
GatewayQueueComputeStreaming
Gateway-Nodes
Prozesszustand, Queue, Running und zugeordnete Worker.
Worker-Ressourcen
Slots sowie residenter Modell- und VRAM-Footprint aus Ollama /api/ps.
Worker Routing
Model-Affinity, gelernter Token-Durchsatz, GPU-/VRAM-Druck und per-model Concurrency beeinflussen den Routing-Score.
Virtuelle Modelle / Aliases
Stabile Client-Namen werden auf das erste routbare reale Modell aufgelöst. CRUD-Änderungen werden persistent gespeichert und sofort für neue Requests aktiv.
Modell-Inventar
Aggregiert über alle Worker. Capabilities und maximaler Kontext werden über Ollama /api/show erkannt und vor Inferenz geprüft.
Model Placement Matrix
Harte Routing-Grenzen vor dem adaptiven Worker-Score. Klick auf eine Zelle setzt eine exakte Ausnahme; ein weiterer Klick setzt sie auf die geerbte Regel zurück.
erlaubt + installiert erlaubt, nicht installiert aktuell geladen gesperrt↳ exakte UI-Ausnahme
Priorität: exakter Modellname → längstes passendes Prefix wie
gemma4:* → Worker-Modus. Bei gleich spezifischen Regeln gewinnt „deny“. Ein Modell wird nur auf Worker geroutet, auf denen es erlaubt und laut Inventar verfügbar ist; bei unbekanntem Inventar bleibt ein kontrollierter Fallback möglich.Worker Rulesets
Allow all eignet sich für allgemeine Worker; Whitelist für dedizierte Nodes. UI-Overrides werden sofort angewendet und persistent gespeichert.
Policy Simulator
Simuliert ACL, Alias-Auflösung, Capabilities, Kontext, Kosten, QoS, Placement und den aktuellen Worker-Score – ohne einen Inferenzjob zu starten.
Noch keine Simulation ausgeführt.
Tenant Policies
Overrides gelten sofort für neue Requests und werden persistent im lokalen State-Verzeichnis gespeichert.
Tenant Model Access
Tenant-basierte Modell-ACLs gelten vor Alias-Auflösung und Routing. Runtime-Änderungen werden persistent gespeichert und sofort angewendet.
Service Classes / QoS
Priorisiert interaktive, System-, Background- und Batch-Last innerhalb der Tenant-Fairness.
Tenant-Nutzung
Persistente Zusammenfassung aus dem Usage-Journal
Fairness-Modell
Admission und Scheduling sind getrennt.
Compute Credit Bucket
↓Tenant WFQ
↓Actor WFQ
↓Model-aware Worker Router
Concurrency Benchmark
Misst TTFT, Durchsatz und optional GPU/VRAM für ein Modell auf genau einem Worker. Der Benchmark erzeugt echte Inferenzlast.
OpenTelemetry
OTLP/HTTP-Tracing ohne Prompt-/Response-Inhalte. Queue, Routing und Ollama-Upstream erscheinen als Spans.
Benchmark-Historie
Empfehlungen können direkt als persistente per-model Concurrency-Overrides angewendet oder zurückgesetzt werden.
Messstufen
Wähle ein Profil aus, um TTFT, Throughput und Score zu vergleichen.
Residency Policy
Hot hält Modelle resident, Warm entlädt nach Idle-Timeout, Cold entlädt aggressiv. Placement und Worker-Drain bleiben harte Grenzen.
VRAM Eviction Vorschläge
Nur inaktive, nicht-Hot Modelle werden vorgeschlagen. Es erfolgt keine automatische aggressive Eviction.
Warm Model Rules
Runtime-Overrides werden persistent gespeichert und wirken ohne Gateway-Neustart.
Letzte Residency-Aktionen
Preload/Unload-Aktionen werden separat vom Inference-Hot-Path ausgeführt.
Aktive Alerts
Worker, Circuit, Queue, VRAM, Storage, OOM und Quota-Signale.
Webhooks
Generic JSON Webhooks; mit Secret werden Payloads via HMAC-SHA256 signiert.
Alert-Historie
Firing und Resolved Events werden persistent gespeichert.
Webhook Deliveries
Letzte Zustellversuche inklusive HTTP-Status bzw. Fehler.
Historische Aggregate
Nach Ablauf der Detail-Retention bleiben Tages- und Monatswerte für langfristige Trends erhalten.
Request Journal
Detaillierte Request-Metadaten innerhalb des konfigurierten Retention-Fensters.
Aktive Inferenz-Jobs
Queued, Running und Streaming Requests können hier administrativ abgebrochen werden. Bereits verbrauchte Tokens/Credits werden soweit messbar weiter erfasst.
Lade Batch-Status …
Durable Batch Jobs
Persistente Hintergrundjobs laufen über Quotas, Fair Scheduler, Placement, Usage und die Service Class batch. Inhalte werden separat in der Batch-Spool gehalten.
Modell-Operationen
Pull-Fortschritt und administrative Aktionen.
Persistenter Gateway-State
Control-Plane-State wird atomar gespeichert; Usage wird automatisch von Detaildaten in Tages-/Monatsaggregate verdichtet.
Usage Retention
Request-Details werden automatisch durch dimensionsbezogene Rollups ersetzt.
Bewusst flüchtig
Diese Zustände lassen sich nach einem Prozessneustart nicht sinnvoll fortsetzen.
Persistente Konfiguration
Änderungen werden atomar gespeichert und beim nächsten Gateway-Start geladen. Secrets bleiben redigiert; API-Keys werden separat verwaltet.
Effektive Konfiguration. Änderungen an der Storage-Sektion sind nur in der Bootstrap-Datei möglich.