Startseite / Artikel / Phlox-GW: Open-Source LLM Gateway mit Budgets, Schutzmechanismen und Hochverfügbarkeit

llm-gateway phlox openai anthropic observability self-hosted

Phlox-GW: Open-Source LLM Gateway mit Budgets, Schutzmechanismen und Hochverfügbarkeit

Einen selbst gehosteten LLM-Gateway mit Rückerstattungen, Rate-Limits, Schutzmaßnahmen für personenbezogene Daten, Audit-Logs, Endpunkten von OpenAI und Anthropic sowie clustergestützter Architektur mit Postgres-Unterstützung.

2581 Wörter

Open-Source-LLM-Gateways bieten oft „Unternehmens“-Funktionen wie Rückerstattungen, Budgets, SSO, Schutzmechanismen, Audit-Spuren, HA-Klustering, Rate-Limits und Routing – allerdings nur im Rahmen einer kostenpflichtigen Lizenz. Phlox-GW (Phlox Gateway) stellt diese Funktionen in einem vollständig open-source-basierten Gateway zur Verfügung, das für selbst gehostete Team-Infrastrukturen konzipiert ist: ein einheitlicher Eingangspunkt über verschiedene Anbieter hinweg, mit Endpunkten von OpenAI und Anthropic sowie Protokollübersetzungen, sodass Clients wie Claude Code mit Modellen aus gemischten Backend-Systemen kommunizieren können.

Phlox-GW ist ein einzelnes Go-Binärdatei für macOS, Linux (einschließlich WSL) und Windows. Kleine Umgebungen können mit SQLite eine Instanz betreiben; größere Umgebungen skalieren auf mehrknotige Clustern mit gemeinsam genutztem PostgreSQL. Ein verwandtes Projekt, die Phlox AI Platform, kann neben dem Gateway genutzt werden, wenn eine vollständige Chat-Oberfläche benötigt wird; dieser Leitfaden konzentriert sich auf das Gateway selbst.

Führung durch die Phlox-GW-Schnittstelle

Operations-Dashboard

Administratoren sehen hochrangige Zahlen – Benutzer, Anbieter, API-Schlüssel, Ereignisse, Gesamtausgaben – sowie 30-Tage-Diagramme für tägliche Kosten, Tokens, Anfragen, Fehler und durchschnittliche Latenz.

Kosten- und Budgetüberwachung

Monatliche Budgets werden Personen und Abteilungen zugeordnet. Benutzer tragen ein Abteilungssymbol, sodass die Ausgaben zusammengefasst werden. Wenn eine Warnschwelle überschritten wird, erfolgt eine Benachrichtigung; bei Erreichen der Obergrenze werden die bezahlten Modelle bis zum nächsten Zyklus oder bei Erhöhung der Grenze blockiert. Dieser Rückbuchungsmechanismus ist ein Hauptgrund dafür, dass Teams lieber auf Gateways als auf reine Anbieter-Schlüssel zurückgreifen.

Auslastungsgrenzen

Grenzen gelten auf Ebene von Benutzer, Abteilung, Anbieter oder Modell und werden in Anfragen pro Minute (RPM) und/oder Tokens pro Minute (TPM) angegeben.

HA und Skalierung durch Clustering

Ein einzelner Go-Prozess auf PostgreSQL reicht bereits aus. Für höhere Verfügbarkeit oder tausende gleichzeitige Sitzungen sollten Instanzen hinzugefügt werden, die sich einen Postgres teilen, und ein Netzwerklastverteiler mit Health-Checks vorangestellt werden, um fehlerhafte Knoten zu entfernen.

Auditing

Audit-Einträge erfassen Anmeldungen sowie Konfigurationsaktionen: Zeit, Ausführender, Aktion, Ziel, Details und IP-Adresse.

Protokollierung unter Wahrung der Privatsphäre

Jeder Gateway-Aufruf protokolliert Metadaten – Zeit, Anfrage-ID, Benutzer, Abteilung, API-Schlüssel, Anbieter, Modell, Protokoll, Endpunkt – ohne die Inhaltsteile der Anfragen oder Antworten zu speichern, sodass die Inhalte privat bleiben, während den Betriebsabteilungen dennoch eine Nachverfolgungsmöglichkeit für Vorfälle bleibt.

Schutzmaßnahmen/Redaktion und Blockierung von PII

Mittelwerke können Nachrichten redigieren oder blockieren, wenn sensible Muster erkannt werden – beim Eintreffen (um Datenlecks an Anbieter zu verhindern) und beim Verlassen (um Datenlecks an Kunden zu verhindern), je nach Konfiguration.

Selbstbedienungs-API-Schlüssel

Eingeloggte Benutzer erstellen benannte Schlüssel mit optionaler Gültigkeitsdauer, widerrufen sie und sehen die letzten Nutzungzeiten. Administratoren erhalten einen Überblick über alle Schlüssel, um Budgets/Limits zuzuweisen und sie zu widerrufen. Die vollständigen Schlüsseldaten werden einmal bei der Erstellung angezeigt.

Selbstbedienung zur Überwachung der Nutzung

Einzelne Benutzer können ihre Anfragenanzahl, Eingangs-/Ausgabetoken, Ausgaben sowie die Kostenaufschlüsselung nach Modell einsehen, ohne auf eine Finanzexportdatei warten zu müssen.

Installation von Phlox-GW

Zur Evaluierung auf der Arbeitsstation ist die Binärdatei selbstständig und erstellt bei erster Ausführung eine SQLite-Datenbank. Die Erstellung aus Quellencode erfordert ein aktuelles Go-Toolchain sowie npm für die UI-Ressourcen. Ein typischer Startvorgang:

curl \
  --proto '=https' \
  --tlsv1.2 \
  -fsSL \
  https://raw.githubusercontent.com/robert-mcdermott/phlox-gw/main/install.sh \
  | sh

Erstellen Sie ein Datenverzeichnis und starten Sie den Dienst:

  mkdir -p "/Users/<your-username>/.local/share/phlox-gw"
  cd "/Users/<your-username>/.local/share/phlox-gw"
  phlox-gw

Weisen Sie einen Browser auf die lokale Benutzeroberfläche hin, erstellen Sie den ersten Administrator und setzen Sie die Konfiguration dort fort. In Produktivumgebungen werden in der Regel Umgebungsvariablen für den Postgres DSN, die Abhör-Adresse, die TLS-Verarbeitung am Load Balancer sowie Session-Secrets festgelegt – siehe die Repository-Dokumentation für die vollständige Liste der Variablen.

Konfigurieren von Phlox-GW

Es gibt keine verpflichtende Konfigurationsdatei: Umgebungsvariablen zusammen mit der Web-Benutzeroberfläche reichen aus, um die Einrichtung durchzuführen.

Hinzufügen/Konfigurieren eines Anbieters

Registrieren Sie jeden Upstream-Anbieter (kompatibel mit OpenAI, Anthropic oder andere unterstützte Anbieter) unter Angabe der Basis-URL sowie der von dem Gateway – und nicht von jedem Laptop – gespeicherten Anmeldeinformationen.

Hinzufügen und Konfigurieren eines Modells

Verknüpfen Sie die Modell-IDs der Anbieter mit Namen, die für das Gateway sichtbar sind, legen Sie Preise für Rückerstattungen fest und wählen Sie bei mehreren Backend-Systemen, die dasselbe logische Modell bereitstellen können, geeignete Routing- und Failover-Peers aus.

Testen eines Anbieters und Modells im Playground

Der integrierte Playground sendet einen Probenchat über den ausgewählten Anbieter/Modellpfad, sodass Verbindungsprobleme bereits vor der Weiterleitung an die Clients sichtbar werden.

Benutzer hinzufügen

Erstellen Sie Konten (oder verbinden Sie SSO/OIDC, falls aktiviert), weisen Sie Rollen und Abteilungen zu sowie legen Sie Budgets/Beschränkungen fest.

Budgete erstellen

Definieren Sie monatliche Obergrenzen und Warnschwellenwerte für Personen und Abteilungen; preisgebundene Modelle berücksichtigen diese Grenzen bei der Abrechnung.

Verwendung von Phlox-GW

Eine API-Schlüssel erstellen

Mit dem Self-Service-Panel generieren Sie einen Schlüssel, kopieren Sie ihn einmal und speichern Sie ihn im geheimen Speicher des Clients.

Testen der Gateway-Endpunkte

Exportieren Sie den Schlüssel:

export PHLOX_API_KEY="pgw-sk-<rest-of-your-api-key>"

OpenAI-kompatible Chat-Completions am lokalen Gateway:

curl -Ns http://127.0.0.1:8080/v1/chat/completions \
  -H "Authorization: Bearer $PHLOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "local-ollama/glm-5.2:cloud",
    "messages": [{"role": "user", "content": "What is the capital of France?"}],
    "stream": false
  }'

Nachrichten im Anthropic-Stil über den übersetzten Endpunkt:

curl -sS http://127.0.0.1:8080/anthropic/v1/messages \
  -H "x-api-key: $PHLOX_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "local-ollama/glm-5.2:cloud",
    "max_tokens": 64,
    "messages": [{ "role": "user", "content": "What is the capital of Texas?" }]
  }'|jq

Nutzung von Claude Code mit Phlox-GW

Weisen Sie Claude Code (oder ähnliche Tools) auf die anthropic-kompatible Basis-URL sowie die Gateway-Schlüssel hin:

env \
  ANTHROPIC_BASE_URL="http://127.0.0.1:8080/anthropic" \
  ANTHROPIC_API_KEY="$PHLOX_API_KEY" \
  ANTHROPIC_MODEL="azure/gpt-5.5" \
  claude

Durch die Protokollumwandlung können kundenorientierte Clients auf alles zugreifen, wohin das Gateway weiterleitet.

Überprüfung der Nutzung

Nutzer aktualisieren die Anzeigen zu verfügbaren Tokens und Ausgaben; plötzliche Anstiege sollten mit bekannten Batch-Aufträgen oder unkontrolliert laufenden Agenten übereinstimmen.

Nutzungs- und Ausgabemonitoring als Administrator

Administratoren beobachten Dashboards zur Gesamtflotte, Zusammenfassungen der Abteilungen sowie Diagramme zu Fehlern und Latenzzeiten. Budgetüberschreitungen sowie Rate-Limit-Verstöße sind wichtige Betriebsereignisse, keine unerwarteten Entdeckungen in Tabellenkalkulationen.

Schutzmaßnahmen – Redaktion sensibler Informationen

Erstellen Sie Muster, die Geheimnisse, persönliche Identifikatoren oder interne Hostnamen erkennen. Wählen Sie für jede Musterfamilie zwischen Maskierung und Blockierung aus. Testen Sie dies mit synthetischen Beispielen im Playground, bevor Sie es im Produktivbetrieb einsetzen.

Protokollierung und Auditing

Anfragenprotokollierung

Protokolle, die nur Metadaten enthalten, unterstützen die Reaktion auf Vorfälle sowie Streitigkeiten bezüglich Chargebacks, ohne den privaten Anfragetext zu speichern.

Audit-Protokollierung

Konfigurations- und Authentifizierungsereignisse beantworten die Frage „Wer hat gestern die Routing-Einstellungen geändert?“ ohne das Durchforsten der Anwendungsprotokolle.

Fazit

Die Phlox-GW-Pakete integrieren Funktionen wie Chargebacks, Budgets, Rate Limits, Schutzmechanismen, Audit-Spuren sowie Clustering in ein einziges offenes Binärdateiformat mit OpenAI- und Anthropic-Schnittstellen. Beginnen Sie mit SQLite zur Bewertung, wechseln Sie bei hoher Verfügbarkeitsanforderung auf Postgres und ein NLB, und lagern Sie die Anbieterdaten sowie Richtlinien an einem Ort statt in verstreuten Laptop-Dateien.

Operative Checkliste für den ersten Produktionsstart: (1) Preis jedes generierten Modells festlegen, damit die Budgets eine Bedeutung haben, (2) Benutzer vor dem ersten Rechnungszyklus den jeweiligen Abteilungen zuweisen, (3) ab dem ersten Tag Logs für Metadatenanfragen sowie Audits aktivieren, (4) synthetische PII-Beispiele durch die Sicherheitsregeln im Testumfeld laufen lassen, (5) vor der Zusicherung von Hochverfügbarkeit ein mit Postgres betriebenes Zwei-Node-System mit überprüftem Lastausgleich einsetzen, und (6) dokumentieren, wie Claude Code/SDK-Client die Basis-URL sowie den Schlüssel einstellen sollen, damit Shadow IT nicht mit rohen Anbieter-Zugangsdaten den Gateway umgeht. Die RPM/TPM-Grenzen nach einer Woche echter Agentenaktivität erneut überprüfen – die anfänglichen Grenzwerte sind fast immer zu großzügig bei sporadischen Tool-Aufrufen und zu streng beim interaktiven Chat. Ein Handbuch für den regelmäßigen Wechsel der Gateway-Schlüssel sowie Anbieter-Geheimnisse an verschiedenen Terminen führen, damit ein einziger Datenleck nicht zu einem doppelten Ausfall führt. Schließlich die Ausgaben nach Abteilungen in festem Rhythmus exportieren, selbst wenn

Bis jetzt hat sich niemand erkundigt; die Finanzabteilung wird nach der ersten überraschenden Rechnung fragen, und das Gateway verfügt bereits über die notwendigen Zahlen, sofern die Tags korrekt gesetzt wurden.

Wenn man über ein einzelnes Team hinaus expandiert, sollte das Gateway als Produktoberfläche betrachtet werden: Implementieren Sie Versionen für Routing-Regeln, überprüfen Sie die Failover-Peers bei regionalen Störungen eines Anbieters und warnen Sie separat vor zunehmenden 429-Fehlern von der Quelle, unabhängig von den vom Gateway festgelegten Grenzen. Für das Throttling in der Quelle sowie lokale Policy-Limits sind unterschiedliche Reaktionen erforderlich – entweder Kapazitäten kaufen oder einen störanfälligen Agenten anleiten. Koppeln Sie die Phlox-GW-Metriken mit den Statusseiten der Anbieter in derselben On-Call-Ansicht, damit die Operator nicht an einer „Gateway-Latenz“ arbeiten, die in Wirklichkeit ein regionaler Ausfall des Modells ist. Mit diesen Gewohnheiten bleibt das Gateway ein Kontrollflugzeug und kein weiterer undurchsichtiger Proxy.

Die SLOs für das Document Gateway werden genauso wie bei jedem anderen Edge-Service definiert: Verfügbarkeit der /v1- und /anthropic-Oberflächen, p95-Latenz – sofern möglich ohne Berücksichtigung der Zeit des upstream-Modells – sowie Budgetblock-Raten nach Abteilungen. Diese drei Diagramme fangen die meisten Meldungen zum „Funktionsfehler“ ab, bevor sie zu Slack-Threads werden.

Die SLOs für das Document Gateway werden genauso wie bei jedem anderen Edge-Service definiert: Verfügbarkeit der /v1- und /anthropic-Oberflächen, p95-Latenz – sofern möglich ohne Berücksichtigung der Zeit des upstream-Modells – sowie Budgetblock-Raten nach Abteilungen. Diese drei Diagramme erkennen die meisten Meldungen zum „Funktionsfehler“ bereits, bevor sie zu Slack-Threads werden.

Die SLOs für das Dokumentengateway werden genauso definiert wie für jeden anderen Edge-Service: Verfügbarkeit der Endpunkte /v1 und /anthropic, p95-Latenz – sofern möglich ohne Berücksichtigung der Zeit des upstream-Modells – sowie Budgetgrenzen pro Abteilung. Diese drei Kennzahlen ermöglichen es, die meisten Meldungen zum „Funktionsfehler“ bereits bevor sie zu Slack-Threads werden, frühzeitig zu erkennen.

Alle Artikel Brief senden