Übersicht über das Modellrouting

Das Modellrouting für API Gateway ist eine verwaltete Ebene für die Trafficverwaltung, die mit OpenAI kompatible Prompts akzeptiert, sie während der Übertragung transcodiert und an bestimmte Vertex AI-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 Vertex AI Model Garden für Optimierungen auf demselben Host integriert. 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 wichtigsten Nutzerprozesse:

  • Modellauswahl: Ein KI-Entwickler verwendet offene Modelle von Model as a Service (MaaS) in Vertex AI 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 Prompts 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 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 Vertex AI Model Garden-Endpunkten genutzt.
  • Standardisierte Clientschnittstelle: Ermöglichen Sie Clientanwendungen, mit einer einheitlichen, mit OpenAI kompatiblen REST-Schnittstelle zu interagieren, während Anfragen dynamisch an verschiedene zugrunde liegende Foundation Models weitergeleitet werden.

Personas und Anwendungsfälle

Das Modellrouting erfüllt die Anforderungen der folgenden Personas:

  • Plattform-Entwickler: 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 Models (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 Prompt-Anfrage 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 Vertex AI-Vorhersagen.
  5. Backend-Versand: Das Gateway sendet die transcodierte Anfrage an den angegebenen Vertex AI Model Garden-Endpunkt 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 in Vertex AI 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 API Gateway OpenAPI 3.x-Erweiterungen 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 (servergesendete 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 Prompts aus, die als mit OpenAI kompatible JSON-Nutzlasten formatiert sind, und leitet sie ausschließlich basierend auf dem model Tag oder Namen in der Nutzlast weiter.
  • Erforderliche Nutzlastfelder: Die eingehende JSON-Anfragenutzlast muss ein Attribut model enthalten. Während der öffentlichen Vorschau verarbeitet das Gateway die Anfrage fälschlicherweise, anstatt sie mit einem Fehler abzulehnen, wenn das Feld model in der Nutzlast der Clientanfrage fehlt. Achten Sie immer darauf, dass Clientanfragen ein Feld model in der JSON-Nutzlast angeben.
  • 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