Ein Model Router auf GCP: eine kontrollierte API vor mehreren offenen LLMs

Die meisten LLM-Projekte in Unternehmen beginnen mit einer Frage: Welches Modell soll die Anwendung aufrufen? Sobald eine Organisation mehrere Modelle betreibt, wird diese Frage zum Problem. Modelle unterscheiden sich in Stärken, Latenz, Ressourcenbedarf und Verfügbarkeit. Wer ein Modell fest in jede konsumierende App einbaut, verlagert diese Entscheidungen in die falsche Schicht des Systems.

Sauberer ist diese Regel: Anwendungen fragen eine KI-Fähigkeit an, und die KI-Infrastruktur entscheidet, welches Modell sie ausführt. In einem Design für die Open-LLM-Integration von Workato auf GCP sitzt ein Model Router vor vier Open-Weight-Modellen und stellt sie über eine einzige kontrollierte API bereit. Der Router erwies sich am Ende als spannenderes Stück als das Deployment der Modelle selbst.

Vom Integrieren der Modelle zu ihrer Abstraktion

Das herkömmliche Setup ist eine direkte Linie:

Application
    │
    ▼
Specific LLM

Kommen mehr Modelle hinzu, zerfällt es in eine Verdrahtung pro Anwendung:

Application A ──► Model A
Application B ──► Model B
Application C ──► Model C

Jetzt muss jede Anwendung Modellnamen, Endpoints, Authentifizierung, Fähigkeiten, Verfügbarkeit, Fallback-Modelle und wahrscheinlich Inferenzparameter kennen. Die bessere Form kehrt die Beziehung um:

┌──► Model A
                    │
Enterprise          ├──► Model B
Application ─► Router
                    ├──► Model C
                    │
                    └──► Model D

Aus Sicht der Anwendung gibt es einen einzigen KI-Dienst. Nur der Router weiß, dass dahinter ein ganzes Modellportfolio steht. Alles andere im Design hängt an dieser Trennlinie.

Die Gesamtarchitektur

Von außen bleibt der Aufbau einfach:

Enterprise Consumers
                 │
       Workato / Applications
                 │
                 ▼
          GCP API Gateway
                 │
                 ▼
           Model Router
                 │
       ┌─────────┼─────────┐
       │         │         │
       ▼         ▼         ▼
    Model A   Model B   Model C   Model D
       │         │         │         │
       └─────────┴─────────┴─────────┘
                    │
               GPU Inference

Darunter liegen GCP, containerisierte Inferenz und vLLM. Für den Betrieb sind sie wichtig, aber sie machen das Design nicht interessant. Seinen Wert bekommt es durch den Routing-Schritt zwischen dem öffentlichen API-Vertrag und den Engines, die die Inferenz ausführen.

Was der Router wirklich tut

Ein Router ist mehr als ein Reverse Proxy. Ein Proxy entscheidet, wohin ein HTTP-Request geht. Der Model Router entscheidet, welches Modell eine KI-Workload ausführen soll. Jeder Request durchläuft vier Stufen:

Request
   │
   ▼
1. Validation
   │
   ▼
2. Workload classification
   │
   ▼
3. Candidate model selection
   │
   ▼
4. Execution + fallback
   │
   ▼
Normalized response

Dadurch müssen Clients kein physisches Deployment benennen. Statt eines Payloads wie diesem:

{
  "model": "physical-model-name",
  "prompt": "..."
}

kann der öffentliche Vertrag eine logische Fähigkeit beschreiben:

{
  "task": "general_generation",
  "messages": [...]
}

Innerhalb der Plattform wird diese Fähigkeit auf das jeweils gewählte Modell aufgefächert:

general_generation
        │
        ▼
     Router
   /    |    \
  ▼     ▼     ▼
M1     M2     M3
        │
        ▼
selected model

Modellnamen werden zum Infrastrukturdetail und hören auf, Sache der Anwendung zu sein.

Die Auswahl ist ein Constraint-Problem

Round-Robin passt hier nicht, weil LLMs keine austauschbaren Kopien eines Dienstes sind. Die erste Stufe ist die Eignung. Aus allen deployten Modellen leitet der Router die Teilmenge ab, die den Request legitim bedienen kann, anhand von Faktoren wie:

• ob das Modell läuft
• ob es die angefragte Aufgabe unterstützt
• der benötigten Kontextlänge
• freier Infrastrukturkapazität
• der Art der Workload

Erst danach beginnt das Ranking. Eine allgemeine Bewertungsfunktion kombiniert erwartete Eignung für die Aufgabe, erwartete Latenz, Inferenzkosten oder Ressourcendruck und aktuelle Verfügbarkeit, jeweils multipliziert mit einem Gewicht, das ihre Bedeutung ausdrückt. Die konkreten Koeffizienten sind eine Frage der Implementierungs-Policy. Architektonisch zählt, dass die Modellwahl zu expliziter Policy wird und kein Zufallsprodukt der Anwendungskonfiguration mehr ist.

Ein Beispiel mit vier Modellen

Stell dir vier Modelle mit unterschiedlichen Aufgaben vor:

Model A → general-purpose generation
Model B → stronger reasoning workload
Model C → lightweight / low-latency requests
Model D → alternate or fallback capability

Ein kurzer Klassifikations- oder Transformations-Request braucht nicht das größte Modell:

Short deterministic task
        │
        ▼
     Router
        │
        ▼
 Lightweight model

Ein schwierigerer Request nimmt eine andere Route:

Complex reasoning task
        │
        ▼
     Router
        │
        ▼
 Higher-capability model

Das verhindert auch ein bekanntes Anti-Pattern: das teuerste Modell für alles laufen zu lassen, nur weil es da ist.

Fallback gehört in den Router

Die Auswahl gibt der Fehlerbehandlung einen natürlichen Platz. Angenommen, die bevorzugte Route ist:

Request
   │
   ▼
Model B

Ist dieses Modell ungesund, überlastet oder weg, muss der Dienst nicht sofort aufgeben. Die Routing-Tabelle kann eine Kette von Alternativen festlegen:

Preferred
   │
   ▼
Model B
   │
 failure
   ▼
Model A
   │
 failure
   ▼
Model D

Der Router kann dann zwei Situationen unterscheiden:

MODEL failure

und

AI SERVICE failure

Das ist nicht dasselbe, und die Unterscheidung zahlt sich bei offenen Modellen aus, wo neue Runtimes oder Versionen ausprobiert werden und nichts von dieser Instabilität bei Unternehmensnutzern ankommen sollte.

Ein stabiler Vertrag über wechselnden Modellen

Die wertvollste Eigenschaft ist das, was gleich bleibt. Aus Sicht von Workato ändert sich dieser Endpoint nie:

POST /v1/chat/completions

Dahinter verändert sich das Bild mit der Zeit. Am Anfang:

Today

dann eine Entwicklung wie diese:

Router ──► Model A
LaterRouter ──► Model B
Later stillRouter ──► Models A/B/C/D
           selected dynamically

Der Geschäftsworkflow ändert sich überhaupt nicht. Das ist Entkopplung in der Praxis. Das KI-Team kann Modellversionen, Runtime-Einstellungen, GPU-Zuteilung, Routing-Regeln, Fallback-Prioritäten oder sogar die ganze Modellfamilie austauschen, ohne einen einzigen Unternehmensworkflow anzufassen.

Warum eine OpenAI-kompatible Schnittstelle

Die Inferenzschicht läuft auf vLLM, das eine OpenAI-kompatible HTTP-Schnittstelle bereitstellt. Der Nutzen ist keine Abhängigkeit von OpenAI. Diese API-Form ist schlicht zu einem praktischen Interoperabilitätsstandard geworden. Der Ablauf sieht so aus:

Client
   │
   │ standard request
   ▼
Router
   │
   │ model-specific decision
   ▼
Inference runtime
   │
   ▼
Open model

Auch Antworten lassen sich auf dem Rückweg normalisieren. Der Router isoliert also zwei Arten von Änderungen:

Northbound
Stable enterprise API

──────── Router boundary ────────Southbound
Changing models and runtimes

Das ist dieselbe Aufgabe, die eine Abstraktionsschicht auch anderswo in verteilten Systemen erfüllt.

Eine bewusst langweilige GCP-Schicht

Die unterstützende Infrastruktur ist absichtlich konventionell:

Workato
   │
   ▼
API Gateway
   │
   ▼
Containerized Router
   │
   ▼
vLLM inference
   │
   ▼
Open-weight models

Modellartefakte können in Cloud Storage liegen und in die Inferenzumgebung gemountet werden, sodass sie nicht in Anwendungs-Images eingebacken sind. API Gateway markiert die äußere Grenze. Für einen Proof of Concept reicht Authentifizierung per API-Key, um den Integrationspfad zu belegen. Produktive Workloads mit sensiblen Daten verlangen mehr: echte Identitätskontrollen, authentifizierte Dienste, privates Networking, Quotas, zentrale Logs und einen richtigen Secret Store.

Das Ziel ist nicht, ein neues GPU-Deployment-Muster zu erfinden. Es geht darum, alles unterhalb der Routing-Abstraktion austauschbar zu halten.

Workato als Konsument, nicht als Runtime

Das verändert, wofür Workato zuständig ist. Es sollte den Geschäftsablauf verstehen:

business event
     ↓
business workflow
     ↓
AI capability request

Um nichts von Folgendem sollte es sich kümmern müssen:

GPU
model checkpoint
vLLM process
context limits
model health
fallback order
routing policy

Das gehört zur KI-Plattform. Die Integration schrumpft auf einen einfachen Aufruf:

Workato Recipe
      │
      ▼
HTTP request
      │
      ▼
Governed AI API

Andere Konsumenten können dasselbe Muster nutzen:

┌── Workato
                    │
AI Gateway ◄────────┼── Copilot / Agent
                    │
                    ├── Web application
                    │
                    └── Internal service

So bedient ein Modellportfolio viele Plattformen, ohne dass für jede eine neue Inferenzintegration nötig ist.

Auf dem Weg zu einer internen KI-Control-Plane

Ein Projekt, das als Verbindung zwischen Unternehmensautomatisierung und offenen Modellen begann, deutet auf etwas Größeres:

Enterprise Layer
                       │
      ┌────────────────┼────────────────┐
      │                │                │
   Workato          Agents          Applications
      │                │                │
      └────────────────┼────────────────┘
                       │
                       ▼
                 AI API Gateway
                       │
                       ▼
                  Model Router
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       Model A      Model B      Model C      Model D

Der Router ist der Anfang einer KI-Control-Plane. Spätere Policies könnten Workload-Klassifikation, Latenz, Modellgesundheit, Kapazität, Aufgabeneignung, Kosten, Datenschutzanforderungen, Evaluationswerte und schließlich mandantenspezifische Regeln hinzufügen. Die Konsumenten bleiben von alldem abgeschirmt.

Die Lektion, die hervorsticht

Die ursprüngliche Frage war, wie man ein offenes LLM an Workato anbindet. Nach dem Bau zeigte sich, dass das die falsche Abstraktionsebene war. Besser ist die Frage, wie Unternehmensanwendungen KI nutzen können, ohne an einzelne Modelle gekoppelt zu werden. Die Antwort ist eine Kombination:

Stable API
    +
Model Router
    +
Explicit Selection Policy
    +
Multiple Open Models
    +
Fallback

Jedes Modell wird zu austauschbarer Infrastruktur, und für die KI-Architektur im Unternehmen ist das womöglich wichtiger als die Frage, welches Modell gewählt wird.