Zum Inhalt

LLM-Manager

LLM-Manager ist eine webbasierte Verwaltungsoberfläche für vLLM-Container auf Servern mit NVIDIA-GPUs. Die Anwendung deckt sieben Modell-Typen ab — von Chat-Sprachmodellen über Vision-Language-Modelle und Embedding-Modelle bis hin zu Spracherkennung, Sprachsynthese und Bildgenerierung — und stellt sie hinter einer einheitlichen, OpenAI-kompatiblen API bereit. Die Container-Orchestrierung erfolgt direkt über die Docker-API; ein Kubernetes-Cluster oder externe Cloud-Dienste sind nicht erforderlich.

Auf einen Blick

  • Verschiedene multimodale KI-Modelle auf einer Maschine bereitstellen — von Chat-Sprachmodellen bis zur Bildgenerierung.
  • Vorhandene NVIDIA-GPUs ohne manuelle Hardware-Konfiguration nutzen; Anzahl, Typ, VRAM, NVLink-Topologie und MIG-Status werden beim Start automatisch erkannt.
  • Modelle aus dem Hugging Face Hub auswählen, parametrisieren und über das Web-UI als Container starten und stoppen.
  • Modelle hinter einer einheitlichen, OpenAI-kompatiblen API anbieten und mit gestuften Schlüsseln nach Anwendungsfall absichern.
  • Token-Durchsatz, Latenz, GPU-Auslastung und Energieverbrauch pro Modell verfolgen und vergleichen.
  • Denselben Modellnamen über mehrere GPUs hinweg skalieren — Replicas mit transparentem Load Balancing erscheinen Clients als ein einziges Modell.
  • Die Oberfläche wahlweise auf Deutsch oder Englisch bedienen (Umschalter in der Kopfzeile).
  • Einzelne Modelle auf eigenen vLLM-Versionen betreiben, ohne den übrigen Bestand anzufassen.
  • Modelle unter mehreren API-Namen mit fest hinterlegten Parameter-Profilen anbieten — etwa abgestuften Reasoning-Modi.
  • Den vorherigen Betriebszustand nach einem Reboot in einem Schritt wiederherstellen.

Highlights

Im Unterschied zu einem manuell zusammengestellten vLLM-Setup übernimmt LLM-Manager die GPU-Erkennung, das Container-Layout, das API-Routing und die Schlüssel-Vergabe und bündelt sieben Modell-Typen unter einer einheitlichen API. Das vermeidet typische Fehlerquellen — falsche Image-Auswahl, fehlende Audio-Bibliotheken, inkonsistente Endpunkte, ungeschützte Direktrouten — und macht den Betrieb auch auf heterogenen Maschinen reproduzierbar.

  • Automatische Hardware-Erkennung — beim Start werden Anzahl, Typ, VRAM, NVLink-/NVSwitch-Topologie und MIG-Status aller NVIDIA-GPUs sowie System-RAM ausgelesen. Die Konfigurationsoberfläche markiert freie GPUs farblich und gibt Hinweise auf NVLink-kompatible Tensor-Parallel-Konstellationen.
  • Sieben Modell-Typen, eine Oberfläche — Chat, Vision-Language, Embedding, Batch-Speech-to-Text, Realtime-Speech-to-Text, Text-to-Speech und Bildgenerierung werden mit jeweils typgerechten Defaults, Docker-Images und API-Endpunkten verwaltet.
  • Zwei Routing-Pfade hinter einer URL — chat-, vision- und embedding-fähige Modelle laufen über LiteLLM unter /v1/*; Spracherkennungs-, Sprachsynthese- und Bildgenerierungs-Modelle laufen direkt unter /models/<name>/v1/*. Beide Pfade nutzen die OpenAI-API ohne Anpassung am Client.
  • Dreistufiges API-Key-System — ein Master-Key, beliebig viele Direkt-Routen-Keys (für interne Anwendungen) und Virtual Keys (mit RPM-Limits, Modell-Einschränkungen und Spend-Tracking, in PostgreSQL persistiert) lassen sich getrennt vergeben und revozieren.
  • MIG-Partitionierung — einzelne GPUs lassen sich in bis zu sieben isolierte Instanzen aufteilen; kleine Modelle (Spracherkennung, Sprachsynthese, Embedding) belegen MIG-Instanzen, große Modelle ganze GPUs. Die Konfiguration überlebt Reboots.
  • Replicas mit Load Balancing — derselbe Modellname kann auf mehreren GPUs laufen; LiteLLM verteilt Anfragen per least-busy-Strategie, ein Teilausfall einzelner Replicas wird automatisch erkannt. Für Clients bleibt es ein einziger Modellname.
  • Mischbetrieb mehrerer vLLM-Versionen — jedes Modell kann eine eigene vLLM- bzw. vLLM-Omni-Version festlegen; Bestandsmodelle laufen unverändert weiter, während neue Modelle auf aktuellen Linien starten. Eine Konsistenzprüfung vergleicht laufende Container mit der Konfiguration, und Versionswechsel starten nur die tatsächlich betroffenen Container neu.
  • Parameter-Bündel als Aliase — ein Modell lässt sich unter mehreren LiteLLM-Namen mit fest gebundenen Sampling- und Reasoning-Einstellungen bereitstellen; Clients wählen ein Verhalten (etwa schnelle Antwort oder ausführliches Reasoning) statt einzelner Parameter.
  • Anbindung an vier externe Quellen und Dienste — Hugging Face Hub für Modelle, Docker Hub und GitHub Container Registry für Container-Images sowie ACME-Server (z.B. Let's Encrypt) für TLS-Zertifikate.
  • Integriertes Monitoring — Prometheus, Grafana und der NVIDIA DCGM Exporter werden als Container mitgeliefert; vier vorkonfigurierte Dashboards aggregieren Token-Nutzung, Latenz-Perzentile, Throughput, Queue-Wartezeit, KV-Cache, Prefix-Cache-Hitrate sowie GPU-Metriken über Modellwechsel hinweg.
  • Energie-Tracking auf Sitzungsebene — Leistungsaufnahme pro GPU, Token-Durchsatz und Effizienz (Wh / 1000 Tokens) werden mitprotokolliert und sind als CSV exportierbar.
  • Datensparsamer Betrieb ohne Cloud-Abhängigkeiten — die Web-Oberfläche bindet ausschließlich auf 127.0.0.1, lädt keine Google Fonts und sendet keine Telemetrie. Sämtliche Modelle, Schlüssel und Logs verbleiben auf der Maschine.