Selbst gehostetes LLM-Netzwerk: ein Gateway anstelle eines Hosts pro Modell

Die Selbsthosting von Open-Weight-Modellen beginnt oft einfach: ein Modell, eine Hostnamen, ein reibungsloser Ablauf. Die Probleme tauchen auf, wenn ein zweites und drittes Modell hinzukommen. Jedes neue Gewichtsdatei führt in der Regel zu zusätzlichen Netzwerkkonfigurationen, Peering-Verbindungen sowie Anwendungs-Einstellungen – obwohl das Produkt lediglich eine weitere Modell-ID verlangt hat. Durch das Hinterlegen eines Gateways vor den Backend-Systemen wird wieder ein einziger Endpunkt geschaffen, während die Modelle dahinter hinzukommen und verschwinden. Die Lektion ist architektonischer Natur und nicht produktbezogen: Man sollte nicht jedem Kunden die Topologie jeder GPU-Box erklären.

Es begann mit einem Modell

Ein Open-Weight-Qwen-Klassenergebnis wurde lokal bereitgestellt und über einen Hostnamen zugänglich gemacht:

llm.my-app.com

Die Anwendung rief diesen Endpunkt mit dem Modellnamen sowie dem Rest des Anfrage-Payloads auf. Der Datenverkehr funktionierte, die Dashboards sahen in Ordnung aus. Dann wollte eine schnellere Gemma-Instanz ihren eigenen Listener für latenzempfindliche Anfragen haben:

flash.llm.my-app.com

Auch das hat funktioniert. Bildmodelle sowie Evaluierungsversionen von DeepSeek-ähnlichen Checkpoints lockten weitere Hosts an:

images.llm.my-app.com

deepseek-v4.llm.my-app.com

Die Produktionsversion von Qwen blieb unverändert, während die Entwicklung auf den Experiment-Endpunkt ausgerichtet war. Jeder Schritt war für sich genommen sinnvoll. Gemeinsam bildeten sie ein Netzwerk aus Basis-URLs, das nur die Person, die sie konfiguriert hatte, sich merken konnte.

Es hat funktioniert, aber etwas schien falsch zu sein

Niemand der Schritte war schwierig – und das war das Problem. Jedes Modell wiederholte dieselbe Abfolge: Gewichte bereitstellen, einen Dienst freigeben, die Netzwerkkonfiguration anpassen, VPCs miteinander verbinden, damit private Modell-Hosts auf die Anwendung zugreifen konnten, und anschließend der Anwendung eine neue Basis-URL beibringen. Nichts davon ist „das Modell“ – es handelt sich dabei um standardisierte Infrastrukturprozesse. Den Teammitgliedern konnte man nicht einfach sagen „verwenden Sie unseren LLM-Dienst und wählen Sie dieses Modell“; sie benötigten die genaue Angabe des richtigen Hosts, und das Gespräch musste jedes Mal neu beginnen, wenn ein neuer Endpunkt auftauchte. Um einen Auftragnehmer einzuarbeiten, musste stattdessen ein privates Glossar mit Hostnamen verschickt werden anstelle eines einzigen Katalogs.

Das DeepSeek-Experiment machte das deutlich

Die Bewertung einer separaten DeepSeek-basierten Implementierung, ohne die Produktumgebung von Qwen zu stören, bedeutete erneut den Anschluss eines weiteren Endpunkts an die Entwicklungsumgebung. Technisch gesehen war nichts kaputt. Die drängende Frage blieb: Warum muss beim Hinzufügen eines Modells auch eine Netzwerkinfrastruktur hinzugefügt werden? Das, was sich änderte, waren die Gewichte; die Infrastruktur der Anwendung sollte nicht zwangsläufig im Gleichschritt verändert werden. Wenn jedes Experiment DNS-Einstellungen und Peerings ändert, verlangsamt sich das Experimentieren auf das Tempo der Netzwerkkorrekturen.

Wie stellen große Anbieter dann Modelle bereit?

Die großen Anbieter erstellen keine eigene öffentliche Basis-URL pro Modell. Die Nutzer müssen sich nicht mit verschiedenen Host-Gruppen herumschlagen wie:

gpt-4.api.openai.com
gpt-5.api.openai.com
some-other-model.api.openai.com

Sie behalten eine einzige API bei und wählen das Modell innerhalb der Anfrage aus. Wenn Anbieter Dutzende von Modellen hinter einer einzigen Schnittstelle bereitstellen können, können selbst gehostete Systeme dasselbe Ziel anstreben. Der Client-Vertrag bleibt stabil, während sich die dahinterliegenden Systeme ändern können.

Die Idee: Ein Proxy vor den Modellen platzieren

Anwendungen sollten stets mit einer stabilen Basis kommunizieren:

llm.my-app.com

und das Modell im Anfrageinhalt auswählen:

{
  model: "qwen-3.8",
  ...
}

{
  model: "gemma-3",
  ...
}

{
  model: "deepseek-v4",
  ...
}

Backends können zwischen Maschinen, Regionen oder Laufzeiten wechseln; der Client-Vertrag bleibt unverändert. Das ist dieselbe Abstraktion, die Cloud-Anbieter bereits anbieten – nur für von Ihnen kontrollierte Systeme.

Einen Proxy entwickeln versus ein Gateway nutzen

Ein naiver Forwarder – man denke an Modell, Routing und Rücksendung – erscheint unbedeutend, solange er als gemeinsamer Service genutzt wird. Erst dann tauchen virtuelle Schlüssel, Nutzungserfassung, Zugriffskontrolle, Modellkonfiguration, Geschwindigkeitsbeschränkungen, Protokollierung sowie eine Admin-Oberfläche auf. Das ist dann kein Spielzeug-Proxy mehr, sondern ein LLM-Gateway. Die Neuentwicklung dieser Kontrollmechanismen von Grund auf bedeutet, jahrelange Erfahrungen mit Sonderfällen (Schlüsselrotation, Teambudgets, Prüfprotokolle) erneut aufbauen zu müssen. LiteLLM zielt auf diese Steuerungs-Ebene ab, damit Teams das nicht tun müssen.

Warum LiteLLM geeignet ist

Anwendungen behalten einen einzigen Endpunkt bei:

llm.my-app.com

LiteLLM leitet Anfragen an heterogene Backend-Systeme weiter:

My Application
                        │
                        ▼
                 llm.my-app.com
                        │
                        ▼
                   LiteLLM
                  /   |    \
                 /    |     \
              Qwen  Gemma  DeepSeek

Die Hinzufügung eines experimentellen Modells bedeutet lediglich das Bereitstellen der Gewichte, deren Registrierung am Gateway sowie Beibehaltung der ursprünglichen App-URL. Hostnamen dringen nicht mehr in den Produktcode ein. Entwickler wählen Modelle genauso wie Temperaturwerte – innerhalb der Anfrage – anstatt die Umgebungsdateien für jedes Experiment manuell zu bearbeiten.

Die Implementierung war unkompliziert

LiteLLM wird als Docker-Image bereitgestellt und benötigt in der Regel PostgreSQL für dauerhafte Daten wie Schlüssel und Ausgaben:

LiteLLM container
        │
        ├── PostgreSQL
        │
        └── Open-weight model servers

Die Modellserver konzentrieren sich auf die Inferenz; das Gateway übernimmt die Steuerung darüber. GPU-Systeme müssen nicht mehr direkt von jedem Microservice erreichbar sein. Die Vernetzung konzentriert sich stattdessen auf die Ebene des Gateways anstelle eines N-by-M-Netzwerks zwischen Anwendungen und Modellhosten.

Der tatsächlich veränderte Teil

Vor Einführung des Gateways bedeutete das Hinzufügen eines Modells, das gesamte Netzwerkkonfigurationsverfahren erneut durchzuführen:

New model
   ↓
New deployment
   ↓
New networking
   ↓
New hostname
   ↓
Application changes

Danach beschränkt sich das Verfahren auf die Registrierung bei einer stabilen Eingangsstelle:

New model
   ↓
Deploy it
   ↓
Register it with the gateway
   ↓
Use the existing endpoint

Anwendungen sollten nicht wissen müssen, wo ein LLM ausgeführt wird – nur welches Modell angefordert werden soll. LiteLLM ist eine praktische Methode, diese Grenze durchzusetzen. Das ursprüngliche Problem lag nicht im Gateway-Produkt, sondern beim zweiten Modell. Sobald dieses Muster erkennbar wird, verstärkt jedes nachfolgende Modell entweder das Netzwerk der Hostnamen oder einen einzigen Katalog. Wählen Sie den Katalog.

Operative Anmerkungen, die man beibehalten sollte

• Betrachten Sie die Registrierung von Modellen als Vorgang mit Change-Management: Wer darf Backend-Dienste hinzufügen, wie werden Schlüssel den Teams zugeordnet und wie verfallen Experimente?
• Halten Sie die Überprüfungen des Zustands der Backends getrennt vom öffentlichen Endpunkt, damit ein nicht verfügbares Modell nicht wie ein vollständiger Ausfall erscheint.
• Dokumentieren Sie die einzige Basis-URL in den Einführungsunterlagen und weigern Sie sich, zusätzliche Hostnamen an die Anwendungs-Teams zu veröffentlichen, es sei denn, es besteht eine strenge Isolierungsanforderung.

Diese Gewohnheiten bewahren die Abstraktion, die mit Einführung des Gateways geschaffen wurde.