Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Übersicht über das Modellrouting

Das Modellrouting für API Gateway ist eine verwaltete Traffic-Management-Ebene, die OpenAI-kompatible Prompts entgegennimmt, 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 zentrale Infrastruktur zur Verwaltung des Lebenszyklus von KI-Agents.

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. Bei dieser Architektur entfällt die Notwendigkeit, nicht verwaltete Proxyserver zu hosten, zu skalieren und zu warten. Dadurch werden der Betriebsaufwand und die Infrastrukturkosten reduziert.

Umfang und Kaufprozesse

Das Modellrouting unterstützt die folgenden Hauptprozesse:

Modellauswahl: Ein KI-Entwickler verwendet offene Modelle von Model as a Service (MaaS) im Model Garden der Agent Platform. Dazu gehören 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 OpenAI-kompatible Prompt-Anfragen 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 Nutzeraktionen unterstützen.

Vorteile des Modellroutings

Die Implementierung von Modell-Routing in API Gateway bietet die folgenden Vorteile:

Zentrale Verwaltung: Die KI-Traffic-Verwaltung wird in einem einzigen verwalteten Gateway konsolidiert. Dadurch werden fragmentierte clientseitige Routingkonfigurationen ersetzt.
Geringerer Betriebsaufwand: Sie sparen die Infrastrukturkosten und den Wartungsaufwand für die Bereitstellung eigenständiger Proxyserver.
Für Edge optimierte Leistung: Untersuchen Sie Prompts und leiten Sie Traffic am Netzwerkrand weiter. Dabei wird die direkte Integration in die Model Garden-Endpunkte der Agent Platform genutzt.
Standardisierte Clientschnittstelle: Ermöglichen Sie Clientanwendungen, mit einer einheitlichen 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 Rollen:

Plattform-Entwickler: Sie stellen eine verwaltete Infrastrukturlösung bereit, um die clientseitige Routing-Logik in KI-Bereitstellungen für Unternehmen zu ersetzen.
KI-Entwickler: Stellen Sie einen standardisierten API-Endpunkt bereit, der Anfragen basierend auf den Parametern der Anfrage-Payload dynamisch zwischen verschiedenen Foundation Models (z. B. Gemini Pro, Gemini Flash oder Anthropic Claude) weiterleitet.
Governance-Administratoren: Erzwingen zentralisierte Zugriffsrichtlinien (z. B. Authentifizierung und Kontingente) und überwachen das gesamte KI-Traffic-Volumen in einer Organisation.

Unterstützte Anwendungsfälle

Während der öffentlichen Vorschau wird das Modellrouting nur auf Grundlage des Modell-Tags oder -Namens (z. B. "model": "gemini-3.5-flash-lite") unterstützt, der in der JSON-Nutzlast von OpenAI-kompatiblen Clientanfragen angegeben ist.

Architektur und Anfrageablauf

Das Modell-Routing funktioniert als verwaltete Routingebene in der Datenebene des API Gateways. Wenn eine Clientanwendung eine OpenAI-kompatible Prompts-Anfrage an das Gateway sendet, läuft Folgendes ab:

Abfangen von Anfragen: Das Gateway fängt die eingehende POST-Anfrage ab (z. B. POST /chat/completions).
Nutzlastprüfung: Der Modellrouter prüft das Attribut model in der eingehenden JSON-Nutzlast (z. B. {"model": "claude-opus-4-7", "messages": [...]}).
Regelauswertung: Der Router vergleicht den String model mit den in Ihrer OpenAPI-Spezifikation definierten Routingregeln. Wenn keine Regel übereinstimmt, wählt der Router das konfigurierte Standardmodell aus.
Transcodierung während der Übertragung: Das Gateway transcodiert die OpenAI-kompatible Anfrage in das Vorhersageschema der Ziel-Agent-Plattform.
Backend-Dispatch: Das Gateway leitet die transkodierte Anfrage an den angegebenen Agent Platform Model Garden-Endpunkt weiter und gibt die Modellantwort an den Client zurück.

Leistung und Einschränkungen

Beachten Sie vor der Implementierung des Modellroutings die folgenden technischen Einschränkungen:

Hosteinschränkungen: Beim Modellrouting werden nur Routings zu vorab bereitgestellten MaaS-Modellen unterstützt, die im Agent Platform Model Garden gehostet werden. Alle Modelle, auf die von einem einzelnen Router verwiesen wird, müssen denselben Hostnamen haben, z. B. den globalen Endpunkt aiplatform.googleapis.com oder einen einzelnen regionalen Endpunkt wie us-central1-aiplatform.googleapis.com.
Anforderungen an die Spezifikation: 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 Modellrouting zu aktivieren. Außerdem können Sie ein Gateway, das mit Modellrouting bereitgestellt wurde, nicht aktualisieren, um Modellrouting zu deaktivieren oder zu entfernen. Wenn Sie den Routingmodus wechseln möchten, müssen Sie eine neue API-Konfiguration und Gateway-Instanz erstellen und bereitstellen.
Gemischte Konfigurationen: Eine OpenAPI-Spezifikation darf keine Operationen mit und ohne Modellrouting enthalten. Für alle Vorgänge in der Spezifikation muss entweder Modell-Routing oder Standard-Gateway-Routing verwendet werden.
VPC Service Controls: Modell-Routing-Gateways unterstützen VPC Service Controls nicht. Sie können keine VPC Service Controls-Perimeter mit API Gateway-Instanzen verwenden, die Modellrouting ermöglichen.
Streaming und nicht unterstützte Protokolle: Das Modellrouting unterstützt Antwortstreaming (vom Server gesendete Ereignisse), aber kein anfrageseitiges Streaming, gRPC, WebSockets oder Gemini Live.
Unterstützte Modalitäten: Während der öffentlichen Vorschau geht beim Modellrouting von textbasierten Prompts aus, die als OpenAI-kompatible JSON-Nutzlasten formatiert sind. Das Routing erfolgt ausschließlich auf Grundlage des Tags oder Namens model in der Nutzlast.
Erforderliche Nutzlastfelder: Die eingehende JSON-Anfrage-Nutzlast muss das Attribut model enthalten. Wenn während der öffentlichen Vorschau das Feld model in der Nutzlast der Clientanfrage fehlt, verarbeitet das Gateway die Anfrage fälschlicherweise, anstatt sie mit einem Fehler abzulehnen. Achten Sie immer darauf, dass in Clientanfragen das Feld model in der JSON-Nutzlast angegeben ist.
Laufzeiteinschränkungen: Für die Routing-Endpunkte Ihres Modells gelten die Infrastrukturdienstlimits und ‑verhalten für das Standard-Gateway-Hosting:
- Maximales Zeitlimit: Das Gateway erzwingt ein maximales Zeitlimit für Anfragen von 3.600 Sekunden (1 Stunde), das für Streaminganfragen mit langer Laufzeit gilt.
- Kaltstartlatenz: Wenn Ihre Gateway-Instanz in Phasen der Inaktivität auf null skaliert wird, kann es bei der ersten Anfrage zu einer Kaltstartlatenz kommen, die sich auf latenzempfindliche KI-Inferenzpfade auswirken kann.
- Reservierte URL-Pfade: Sie können keine reservierten URL-Pfade verwenden, die mit /_ah/ beginnen oder mit z enden. Um Konflikte zu vermeiden, sollten Sie keine Pfadnamen verwenden, die mit z enden.
- Decodierung von URL-Zeichen: Das Gateway decodiert automatisch bestimmte codierte Zeichen in Anfrage-URLs, bevor die Anfrage verarbeitet wird (z. B. wird %41 in A decodiert).