Übersicht über das Modellrouting

Das Modellrouting für API Gateway ist eine verwaltete Ebene für die Trafficverwaltung, die mit OpenAI kompatible Promptanfragen akzeptiert, sie während der Übertragung transcodiert und an bestimmte Gemini Enterprise Agent Platform-Modelle weiterleitet. Das Modellrouting ist eine verwaltete Alternative zu clientseitigen Proxys wie LiteLLM und bietet eine zentralisierte Infrastruktur zur Verwaltung des Lebenszyklus von KI-Agenten.

Beim Modellrouting wird die Routinglogik an den Netzwerkrand verlagert und in den Agent Platform Model Garden integriert, um Optimierungen auf demselben Host zu ermöglichen. Durch diese Architektur ist es nicht mehr erforderlich, nicht verwaltete Proxyserver zu hosten, zu skalieren und zu warten. Dadurch werden der Betriebsaufwand und die Infrastrukturkosten reduziert.

Umfang und Nutzerprozesse

Das Modellrouting unterstützt die folgenden zentralen Nutzerprozesse:

  • Modellauswahl: Ein KI-Entwickler verwendet offene Modelle aus Model as a Service (MaaS) im Agent Platform Model Garden. Dabei handelt es sich um Modelle der Gemini-, Anthropic Claude- oder OpenAI GPT-Familie.
  • Spezifikationserstellung: Ein KI-Entwickler erstellt oder aktualisiert eine Modellrouterkonfiguration in einer OpenAPI 3.x-Spezifikation, um auf die bereitgestellten Modelle zu verweisen.
  • Gateway-Bereitstellung: Ein KI-Entwickler stellt eine API-Konfiguration und eine API Gateway-Instanz mithilfe der erstellten OpenAPI-Spezifikation bereit.
  • Prompt-Routing: Clientanwendungen senden mit OpenAI kompatible Promptanfragen an das Gateway, das Anfragen weiterleitet und Nutzlasten basierend auf dem in der JSON-Nutzlast angegebenen Modellnamen übersetzt.

Zukünftige Versionen von API Gateway werden voraussichtlich zusätzliche Nutzerprozesse unterstützen.

Vorteile des Modellroutings

Die Implementierung des Modellroutings in API Gateway bietet die folgenden Vorteile:

  • Zentrale Verwaltung: Konsolidieren Sie die KI-Trafficverwaltung in einem einzigen verwalteten Gateway und ersetzen Sie fragmentierte clientseitige Routingkonfigurationen.
  • Geringerer Betriebsaufwand: Vermeiden Sie die Infrastrukturkosten und den Wartungsaufwand, die mit der Bereitstellung eigenständiger Proxyserver verbunden sind.
  • Für den Edge optimierte Leistung: Prüfen Sie Prompts und leiten Sie Traffic am Netzwerkrand weiter. Dabei wird die direkte Integration mit den Endpunkten des Agent Platform Model Garden genutzt.
  • Standardisierte Clientschnittstelle: Ermöglichen Sie Clientanwendungen die Interaktion mit einer einheitlichen, mit OpenAI kompatiblen REST-Schnittstelle, während Anfragen dynamisch an verschiedene zugrunde liegende Foundation-Modelle weitergeleitet werden.

Personas und Anwendungsfälle

Das Modellrouting erfüllt die Anforderungen der folgenden Personas:

  • Plattformingenieure: Stellen Sie eine verwaltete Infrastrukturlösung bereit, um die clientseitige Routinglogik in unternehmensweiten KI-Bereitstellungen zu ersetzen.
  • KI-Entwickler: Stellen Sie einen standardisierten API-Endpunkt bereit, der Anfragen basierend auf den Parametern der Anfragenutzlast dynamisch zwischen verschiedenen Foundation-Modellen (z. B. Gemini Pro, Gemini Flash oder Anthropic Claude) weiterleitet.
  • Governance-Administratoren: Erzwingen Sie zentralisierte Zugriffsrichtlinien (z. B. Authentifizierung und Kontingente) und überwachen Sie das gesamte KI-Trafficvolumen in einem Unternehmen.

Unterstützte Anwendungsfälle

Während der öffentlichen Vorschau unterstützt das Modellrouting das Routing ausschließlich basierend auf dem Modell-Tag oder -Namen (z. B. "model": "gemini-3.5-flash-lite"), der in der JSON-Nutzlast von mit OpenAI kompatiblen Clientanfragen angegeben ist.

Architektur und Anfragenfluss

Das Modellrouting fungiert als verwaltete Routingebene in der Datenebene von API Gateway. Wenn eine Clientanwendung eine mit OpenAI kompatible Promptanfrage an das Gateway sendet, geschieht Folgendes:

  1. Anfrage abfangen: Das Gateway fängt die eingehende POST-Anfrage ab (z. B. POST /chat/completions).
  2. Nutzlast prüfen: Der Modellrouter prüft das Attribut model in der eingehenden JSON-Nutzlast (z. B. {"model": "claude-opus-4-7", "messages": [...]}).
  3. Regelauswertung: Der Router vergleicht den model String mit den in Ihrer OpenAPI-Spezifikation definierten Routingregeln. Wenn keine Regel übereinstimmt, wählt der Router das konfigurierte Standardmodell aus.
  4. Transcodierung während der Übertragung: Das Gateway transcodiert die mit OpenAI kompatible Anfrage in das Zielschema für die Vorhersage der Agent Platform.
  5. Backend-Weiterleitung: Das Gateway leitet die transcodierte Anfrage an den angegebenen Endpunkt des Agent Platform Model Garden weiter und gibt die Modellantwort an den Client zurück.

Leistung und Einschränkungen

Lesen Sie die folgenden technischen Einschränkungen, bevor Sie das Modellrouting implementieren:

  • Hosteinschränkungen: Das Modellrouting unterstützt das Routing nur zu vorab bereitgestellten MaaS-Modellen, die im Agent Platform Model Garden gehostet werden. Dabei müssen alle Modelle, auf die von einem einzelnen Router verwiesen wird, denselben Hostnamen haben (z. B. der globale Endpunkt aiplatform.googleapis.com oder ein einzelner regionaler Endpunkt wie us-central1-aiplatform.googleapis.com).
  • Spezifikationsanforderungen: Für das Modellrouting ist eine OpenAPI 3.x-Spezifikation und die entsprechenden OpenAPI 3.x-Erweiterungen für API Gateway erforderlich. OpenAPI 2.0-Spezifikationen (Swagger) werden nicht unterstützt.
  • Gateway-Updates: Sie können ein vorhandenes Gateway, das ohne Modellrouting bereitgestellt wurde, nicht aktualisieren, um das Modellrouting zu aktivieren. Außerdem können Sie ein Gateway, das mit Modellrouting bereitgestellt wurde, nicht aktualisieren, um das Modellrouting zu deaktivieren oder zu entfernen. Wenn Sie den Routingmodus wechseln möchten, müssen Sie eine neue API-Konfiguration und eine neue Gateway-Instanz erstellen und bereitstellen.
  • Gemischte Konfigurationen: Eine OpenAPI-Spezifikation darf keine Mischung aus Modellrouting- und Nicht-Modellrouting-Vorgängen enthalten. Alle Vorgänge in der Spezifikation müssen entweder das Modellrouting oder das Standard-Gateway-Routing verwenden.
  • VPC Service Controls: Modellrouting-Gateways unterstützen VPC Service Controls nicht. Sie können VPC Service Controls-Perimeter nicht mit API Gateway-Instanzen verwenden, die das Modellrouting aktivieren.
  • Streaming und nicht unterstützte Protokolle: Das Modellrouting unterstützt das Antwortstreaming (vom Server gesendete Ereignisse), aber nicht das anfrageseitige Streaming, gRPC, WebSockets oder Gemini Live.
  • Unterstützte Modalitäten: Während der öffentlichen Vorschau geht das Modellrouting von textbasierten Promptanfragen aus, die als mit OpenAI kompatible JSON-Nutzlasten formatiert sind. Das Routing basiert ausschließlich auf dem model Tag oder Namen in der Nutzlast.
  • Erforderliche Nutzlastfelder: Die eingehende JSON-Anfragenutzlast muss ein Attribut model enthalten. Während der öffentlichen Vorschau verarbeitet das Gateway die Anfrage fälschlicherweise, wenn das Feld model in der Nutzlast der Clientanfrage fehlt, anstatt sie mit einem Fehler abzulehnen. Achten Sie immer darauf, dass in Clientanfragen ein Feld model in der JSON-Nutzlast angegeben ist.
  • Laufzeiteinsprung: Für Ihre Modellrouting-Endpunkte gelten die Standardlimits und Verhaltensweisen für den Hosting-Infrastrukturdienst des Gateways:
    • Maximale Zeitüberschreitung: Das Gateway erzwingt eine maximale Zeitüberschreitung für Anfragen von 3.600 Sekunden (1 Stunde). Dies gilt für Streaminganfragen mit langer Laufzeit.
    • Latenz beim Kaltstart: Wenn Ihre Gateway-Instanz in Zeiten der Inaktivität auf null skaliert wird, kann es bei der ersten Anfrage zu einer Latenz beim Kaltstart kommen, was sich auf latenzempfindliche KI-Inferenzpfade auswirken kann.
    • Reservierte URL-Pfade: Sie können keine reservierten URL-Pfade wie /eventlog, Pfade, die mit /_ah/ beginnen, oder bestimmte Pfade verwenden, die mit z enden (um Konflikte zu vermeiden, sollten Sie keine Pfadnamen verwenden, die mit z enden).
    • URL-Zeichendecodierung: Das Gateway decodiert bestimmte codierte Zeichen in Anfragen-URLs automatisch, bevor die Anfrage verarbeitet wird (z. B. %41 wird in A decodiert).

Nächste Schritte