[KI, Security, Tech-Deep-Dive]

llmproxy: Das Herzstück meiner KI-Infrastruktur (oder: Warum meine KI Pause macht, wenn ich zocke)

2026-05-20 // Marco Frischkorn

KI generiert und vom Menschen redigiert

Tja... wer mich kennt, weiß: Ich liebe meine lokale KI-Infrastruktur auf dana. Aber ich liebe es auch, abends mal ne Runde zu zocken, ohne dass mein VRAM von irgendeinem Hintergrund-Agenten weggefressen wird, der gerade meint, die Weltformel berechnen zu müssen.

Genau aus diesem Frust (und dem Drang nach totaler Kontrolle) ist llmproxy entstanden. Heute werfen wir mal einen Blick unter die Haube dieses kleinen Biests, das mittlerweile der Türsteher für alles ist, was auf meinem Server an LLMs (Ollama) oder ComfyUI-Workflows läuft.

Was ist das eigentlich für ein Teil?

Kurz gesagt: Ein transparenter Proxy, der zwischen meinen Clients (Roo Cline, Open WebUI, LLM-Monitor) und den eigentlichen Engines sitzt. Statt direkt dana:11434 anzusprechen, gehen alle Anfragen über Port 11435.

llmproxy Dashboard Live

Warum der Umweg? Weil der Standard-Ollama zwar super ist, aber in Sachen Observability und Management eher... sagen wir mal... „puristisch“ daherkommt. llmproxy reichert das Ganze mit Features an, die ich nicht mehr missen möchte.

Die Highlights (aka: Warum ich das gebaut habe)

1. Der heilige Gaming-Mode 🎮

Das ist vermutlich das Feature, das meinen Blutdruck am meisten senkt. Der Proxy prüft alle 10 Sekunden via pgrep steam, ob ich gerade auf dem Host zocke. Wenn ja? Dann gehen die Schotten dicht. Alle LLM-Anfragen werden mit einem freundlichen HTTP 503 (Service Unavailable) abgelehnt und im Dashboard leuchtet ein fetter roter „GAMING MODE“-Banner. Keine Ruckler im Spiel, nur weil eine KI gerade „hilfreich“ sein will. Prioritäten, Leute!

2. Hardware-Monitor & SSE-Stream 🖥️

Ich hasse es, ständig per SSH und nvidia-smi zu prüfen, wie viel VRAM noch frei ist. Der Proxy nutzt psutil und die NVIDIA-Tools, um CPU, RAM, GPU-Last und Temperaturen live auszulesen. Das Ganze wird per SSE (Server-Sent Events) an alle verbundenen Dashboards und Monitor-Apps gestreamt. Real-time ohne Polling-Overhead.

llmproxy Setup & Architektur

3. Token-Budgeting & Forensic Logging 📊

Wer frisst meine Ressourcen? Der Proxy loggt jeden einzelnen Request in eine SQLite-Datenbank (WAL-Mode, weil Performance!). Wir speichern Tokens, Dauer, tps (Tokens per Second), ttft (Time to First Token) und sogar die Komplexität der Anfrage.
Über die budget.yaml kann ich zudem pro IP-Adresse tägliche Token-Limits festlegen. Wenn Roo mal wieder in eine Endlosschleife läuft: Zack, Limit erreicht, Ruhe im Karton.

4. Auto-Router & Idle Eviction 🤖

Nicht jede Anfrage braucht ein 70B-Modell. Der Auto-Router schaut sich die Anfrage an und leitet einfache Tasks (wie „Schreib ein kurzes Summary“) automatisch auf kleinere, effizientere Modelle um.
Und wenn der VRAM mal wieder voll ist, aber seit 10 Minuten keiner mehr was gefragt hat? Dann sorgt die Idle Eviction dafür, dass inaktive Modelle entladen werden. Platz schaffen für Neues.

5. Ein Gateway für alle Geräte (Multi-Device) 🔗

Das Beste zum Schluss: Ich bin nicht an einen Rechner gebunden. Ob ich an meinem Haupt-PC sitze, mit dem Laptop auf der Couch lümmle oder sogar vom iPad aus via Open WebUI zugreife – alle Anfragen gehen zentral über den Proxy.
* Der Vorteil: Ich habe ein gemeinsames Logging und Budgeting für mein komplettes Heimnetz. Ich muss nicht auf jedem Gerät einzeln schauen, was los ist. Ein Blick ins Dashboard reicht.

Technische Unterbau (Nerd-Talk)

Das Ganze ist in Python geschrieben (einfach, weil es für KI-Integrationen nichts Besseres gibt) und läuft als systemd-Service direkt auf dana. Die Datenhaltung übernimmt eine SQLite-DB, was für ein Single-User-Setup wie meines absolut ausreicht und super einfach zu sichern ist.

Das Dashboard (das ihr auf den Screenshots seht) läuft in einem Docker-Container und zieht sich die Daten via SSE vom Proxy. Es ist quasi das Fenster in die Seele meines Servers.

llmproxy Verlauf

Fazit: Brauchst du das auch?

Wenn du nur ab und zu mal eine Frage an Ollama stellst: Wahrscheinlich nicht.
Wenn du aber – wie ich – ein ganzes Arsenal an Agenten, Browser-Extensions und Desktop-Apps hast, die alle gleichzeitig auf deine GPU zugreifen wollen, dann ist ein zentraler „Türsteher“ Gold wert.

Es ist das Ende vom Blindflug. Ich sehe genau, wer was macht, wie heiß meine GPU wird und – am wichtigsten – meine Spiele laufen flüssig. B-)


Transparency Note: Dieser Post wurde mit Unterstützung von Antigravity erstellt. Der Code von llmproxy ist aber echtes Marco-Handwerk (mit ein bisschen KI-Assistenz beim Refactoring). ;-)