Modellrouting konfigurieren

Auf dieser Seite wird beschrieben, wie Sie das Modellrouting in API Gateway mit OpenAPI 3.x-Spezifikationen konfigurieren, bereitstellen und testen.

Hinweis

Bevor Sie das Modellrouting konfigurieren, prüfen Sie, ob Ihre Umgebung die folgenden Voraussetzungen erfüllt:

  1. IAM-Berechtigungen prüfen: Prüfen Sie, ob Sie Zugriff auf die API Gateway-Steuerungsebene und Vertex AI Model Garden haben. Sie benötigen die Rolle „API Gateway-Administrator“ (roles/apigateway.admin), um API-Konfigurationen und Gateways zu erstellen. Außerdem muss dem Dienstkonto, das von Ihrem API-Gateway verwendet wird – entweder dem Compute Engine-Standarddienstkonto oder einem vom Nutzer verwalteten Dienstkonto, das beim Erstellen der API-Konfiguration angegeben wurde – die Rolle „Vertex AI-Nutzer“ (roles/aiplatform.user) zugewiesen werden, um auf Zielmodelle zuzugreifen.
  2. Modellverfügbarkeit und Endpunktzugriff prüfen: Prüfen Sie, ob Ihre routingfähigen Modelle vorab bereitgestellte offene Modelle für Model as a Service (MaaS) in Vertex AI Model Garden sind. Alle Modelle, auf die von einem einzelnen Router verwiesen wird, müssen denselben Hostnamen haben. Wählen Sie für jedes Modell, auf das in diesem Router verwiesen wird, entweder den globalen Endpunkt (aiplatform.googleapis.com) oder einen einzelnen regionalen Endpunkt aus (z. B. us-central1-aiplatform.googleapis.com).
  3. Bereitstellung des Gateways prüfen: 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.
  4. VPC Service Controls und Endpunktkompatibilität prüfen: Modellrouting-Gateways unterstützen keine VPC Service Controls- oder Private Service Connect-Endpunktkonfigurationen (PSC). Prüfen Sie, ob Ihr Zielprojekt und Ihre API Gateway-Instanzen nicht durch VPC Service Controls-Perimeter eingeschränkt sind und ob Ihre Modelle öffentliche regionale oder globale Endpunkte verwenden.

Konfigurationsprüfung

Wenn Sie eine API-Konfiguration bereitstellen, validiert die API Gateway-Steuerungsebene Ihre OpenAPI-Spezifikation. Die Steuerungsebene lehnt ungültige Konfigurationen während der Bereitstellung mit einem informativen Validierungsfehler ab. Beim Validierungsprozess werden die folgenden Regeln erzwungen:

Struktur- und Standortprüfungen

  • Die Erweiterung x-google-api-management und die zugehörigen Blöcke (backends, ai.models.routing.routers, einzelne Router und rules) müssen wohlgeformt sein. Die Schlüssel müssen mit den erwarteten Datentypen übereinstimmen (Map, Liste oder String). Die Steuerungsebene lehnt Typkonflikte mit dem Fehler expected map/list/string ab.
  • Die Erweiterung x-google-api-management muss einen gültigen backends-Block enthalten, wenn das Modellrouting aktiviert ist.
  • Die Erweiterung x-google-model-router wird nur in OpenAPI 3.x-Spezifikationen unterstützt (nicht in OpenAPI 2.0 / Swagger).
  • Die Erweiterung x-google-model-router kann nur auf Vorgangsebene angegeben werden. Die Steuerungsebene lehnt x-google-model-router-Definitionen, die auf Pfad- oder Stammebene (oberste Ebene) platziert sind, explizit ab.
  • Der Block ai.models.routing.routers muss in x-google-api-management definiert sein, wenn ein Vorgang auf x-google-model-router verweist.
  • Sie können nicht sowohl x-google-model-router als auch x-google-backend für denselben API-Vorgang angeben.
  • Eine OpenAPI-Spezifikation darf keine Mischung aus Modellrouting- und Nicht-Modellrouting-Vorgängen enthalten. Sie können nicht für einige Vorgänge Standardrouting-Erweiterungen (z. B. x-google-backend) angeben, während Sie für andere Vorgänge innerhalb derselben API-Spezifikation x-google-model-router verwenden.

HTTP-Methodenprüfung

  • Die Erweiterung x-google-model-router kann nur auf Vorgänge angewendet werden, die die HTTP-Methode POST verwenden. Die Steuerungsebene lehnt das Modellrouting für alle anderen HTTP-Methoden (z. B. GET, PUT oder DELETE) ab.

Backend-Gültigkeit

  • Jedes Backend, das unter x-google-api-management.backends definiert ist, muss ein nicht leeres address-Feld enthalten.
  • Die address des Backends muss eine gültige URL mit dem Schema http oder https sein. Um Prompt-Nutzlasten und Authentifizierungsdaten bei der Übertragung über öffentliche oder Remote-Endpunkte zu schützen, geben Sie beim Definieren des Felds address immer das Schema https an.
  • Jedes Backend, das unter x-google-api-management.backends definiert und von einem Modellrouter referenziert wird, muss pathTranslation: CONSTANT_ADDRESS verwenden. Die Steuerungsebene lehnt Konfigurationen mit pathTranslation: APPEND_PATH_TO_ADDRESS für Modellrouting-Backends ab, da die Pfadübersetzung im Laufzeitpfad des Modellrouters ignoriert wird.
  • Modellrouting-Backends unterstützen keine VPC Service Controls- oder Private Service Connect-Endpunktkonfigurationen (PSC). Alle address-Felder des Backends müssen auf öffentliche regionale oder globale MaaS-Endpunkte für offene Modelle verweisen.

Auflösung von Routerreferenzen

  • Der Routername, auf den von x-google-model-router eines Vorgangs verwiesen wird, muss mit einem gültigen Routerschlüssel übereinstimmen, der unter ai.models.routing.routers definiert ist.
  • Das backend, auf das von defaultModel eines Routers verwiesen wird, muss mit einem gültigen Backend übereinstimmen, das unter x-google-api-management.backends definiert ist.
  • Das backend, auf das von jeder Regel in einem Router verwiesen wird, muss mit einem gültigen Backend übereinstimmen, das unter x-google-api-management.backends definiert ist.

Routerinhalte

  • Jeder Router muss ein defaultModel definieren.
  • defaultModel muss ein gültiges backend-Feld enthalten.
  • defaultModel muss ein nicht leeres targetModel-Feld enthalten.
  • Jeder Eintrag unter rules muss ein nicht leeres model-Feld enthalten. Der Stringwert default ist reserviert und kann nicht als model-Wert einer Regel verwendet werden.
  • Jeder Eintrag unter rules muss ein nicht leeres targetModel-Feld enthalten.
  • Die für alle Regeln innerhalb eines einzelnen Routers definierten model-Werte müssen eindeutig sein. Die Steuerungsebene lehnt doppelte model-Werte innerhalb desselben Routers ab.

Konsistenz von Backend-Host und -Schema

  • Alle Backends, auf die von einem einzelnen Router verwiesen wird (einschließlich defaultModel.backend und backend jeder Regel), müssen denselben Hostnamen und dasselbe URL-Schema verwenden. Die Steuerungsebene lehnt Konfigurationen mit unterschiedlichen Hostnamen oder inkonsistenten Schemas (http im Vergleich zu https) innerhalb desselben Routers ab, um sicherzustellen, dass der Router alle Anfragen an einen konsistenten Upstream-Dienstendpunkt weiterleitet.

Validierung des Zielmodells

  • Der <provider>-Teil des targetModel-Strings (google, openai oder anthropic) und das Format der Kennung <provider>/<model> werden beide beim Erstellen (Bereitstellen) der Konfiguration validiert. Die Steuerungsebene lehnt ein targetModel ab, das nicht als <provider>/<model> formatiert ist oder dessen Anbieter nicht google, openai oder anthropic ist, und gibt während der Bereitstellung den Fehler InvalidArgument: unsupported publisher zurück.

Schritt 1: Zielmodelle identifizieren

Identifizieren Sie die Zielmodelle und die entsprechenden Vertex AI-Endpunkt-URLs. Alle routingfähigen Modelle innerhalb eines Routers müssen denselben Hostnamen verwenden. Bei offenen MaaS-Modellen ist dieser Hostname aiplatform.googleapis.com.

Die Pfade der Endpunkt-URLs variieren je nach Modellanbieter:

  • Google Gemini: Verwendet die Methode :generateContent.
  • Anthropic Claude: Verwendet die :rawPredict Methode.
  • OpenAI: Verwendet den /endpoints/openapi/chat/completions Endpunktpfad.

In der folgenden Tabelle sind die MaaS-Endpunkte aufgeführt, die im Beispiel für die OpenAPI-Spezifikation weiter unten in diesem Abschnitt verwendet werden:

Modell Endpunkt-URL
google/gemini-3.5-flash-lite https://aiplatform.googleapis.com/v1/projects/YOUR_PROJECT_ID/locations/global/publishers/google/models/gemini-3.5-flash-lite:generateContent
anthropic/claude-opus-4-7 https://aiplatform.googleapis.com/v1/projects/YOUR_PROJECT_ID/locations/global/publishers/anthropic/models/claude-opus-4-7:rawPredict
openai/gpt-oss-120b-maas https://aiplatform.googleapis.com/v1/projects/YOUR_PROJECT_ID/locations/global/endpoints/openapi/chat/completions

Ersetzen Sie YOUR_PROJECT_ID durch Ihre Google Cloud Projekt-ID.

Schritt 2: OpenAPI 3.x-Spezifikation konfigurieren

Erstellen oder aktualisieren Sie Ihre OpenAPI 3.x-Spezifikation, um Ihre Backend-Endpunkte und Modellrouting-Konfigurationen zu definieren.

Das folgende Beispiel zeigt eine OpenAPI 3.0.3-Spezifikation, in der zwei verschiedene Modellrouter definiert sind. Um horizontales Scrollen zu vermeiden, werden lange Backend-Adress-URLs mit der YAML-Fortsetzung für mehrzeilige Strings mit doppelten Anführungszeichen (``) fortgesetzt:

openapi: 3.0.3

info:
  title: OpenAPI 3.x spec using Model Routing
  description: Using Model Routing in an OAS 3.x spec
  version: 1.0.0

x-google-api-management:
  backends:
    gemini-35-flashlite:
      address: "https://aiplatform.googleapis.com/v1/projects/\
        YOUR_PROJECT_ID/locations/global/publishers/google/\
        models/gemini-3.5-flash-lite:generateContent"
      deadline: 60.0
      pathTranslation: CONSTANT_ADDRESS

    anthropic-claude-opus-47:
      address: "https://aiplatform.googleapis.com/v1/projects/\
        YOUR_PROJECT_ID/locations/global/publishers/anthropic/\
        models/claude-opus-4-7:rawPredict"
      deadline: 60.0
      pathTranslation: CONSTANT_ADDRESS

    openai-gpt-oss-120b:
      address: "https://aiplatform.googleapis.com/v1/projects/\
        YOUR_PROJECT_ID/locations/global/endpoints/openapi/\
        chat/completions"
      deadline: 60.0
      pathTranslation: CONSTANT_ADDRESS

  ai:
    models:
      routing:
        routers:
          # Router 1: route between Gemini (default) and Claude.
          gemini-claude-router:
            defaultModel:
              backend: gemini-35-flashlite
              targetModel: google/gemini-3.5-flash-lite
            rules:
              - model: "claude-opus-4-7"
                backend: anthropic-claude-opus-47
                targetModel: anthropic/claude-opus-4-7

          # Router 2: route between OpenAI GPT (default) and Gemini.
          openai-gemini-router:
            defaultModel:
              backend: openai-gpt-oss-120b
              targetModel: openai/gpt-oss-120b-maas
            rules:
              - model: "gemini-3.5-flash-lite"
                backend: gemini-35-flashlite
                targetModel: google/gemini-3.5-flash-lite

servers:
  - url: "https://my-gateway-url.com"

paths:
  /v1/chat/gemini-claude:
    post:
      summary: "Endpoint:defaults to Gemini & Claude as an option."
      operationId: "chatGeminiClaude"
      x-google-model-router: gemini-claude-router
      responses:
        '200':
          description: "OK"

  /v1/chat/openai-gemini:
    post:
      summary: "Endpoint:defaults to OpenAI & Gemini as an option."
      operationId: "chatOpenAIGemini"
      x-google-model-router: openai-gemini-router
      responses:
        '200':
          description: "OK"

Konfigurationsattribute

  1. backends: Das Objekt backends unter x-google-api-management definiert alle routingfähigen Modellendpunkte. Jeder Backend-Name steht für einen symbolischen Modellnamen (z. B. gemini-35-flashlite) mit der Zieladresse address. Das Feld backends ist eine vorhandene Google OpenAPI-Erweiterung.
  2. ai.models.routing: Die Modellrouting-Konfiguration befindet sich unter x-google-api-management als ai.models.routing und enthält eine Map mit benannten Routern. Jeder Zuordnungseintrag definiert einen Modellrouter, wobei der Schlüssel den Namen des Routers darstellt (z. B. gemini-claude-router) und der Wert Folgendes enthält:
    • defaultModel: Das erforderliche Fallback-Modellziel, das verwendet wird, wenn die Nutzlast einer eingehenden Anfrage mit keiner expliziten Regel übereinstimmt. Es hat dieselbe Struktur wie ein Regeleintrag, aber das übereinstimmende Feld model fehlt. Wenn bei OpenAI-kompatiblen Routen eine Anfrage auf defaultModel zurückgreift, wird der Wert von targetModel als ausgehendes model-Attribut im Anfragetext an Vertex AI weitergeleitet.
    • rules: Ein optionales Array, in dem jedes Element einen Modellstring der Clientnutzlast einem Ziel-Backend und einem Zielmodell zuordnet.
  3. Regelattribute: Jeder Eintrag in rules (und defaultModel) definiert die folgenden Attribute:
    • model (nur Regeln): Der Stringwert, der mit dem Attribut model in der eingehenden JSON-Prompt-Nutzlast des Clients verglichen wird. Der Router vergleicht den model-Wert der eingehenden Nutzlast mit diesem String. Wenn keine Regel übereinstimmt, wählt der Router defaultModel aus. Bei OpenAI-kompatiblen Routen (bei denen das Ziel-Backend /openapi/chat/completions ist) wird dieser String direkt als ausgehendes model-Attribut im Anfragetext an Vertex AI weitergeleitet. Daher muss der model Selektor für OpenAI-kompatible Routen selbst eine gültige Modell-ID des Publishers sein (z. B. openai/gpt-oss-120b-maas). Wenn Sie einen Alias wie gpt-oss verwenden, gibt Vertex AI den Fehler 400 Malformed publisher model zurück.
    • backend: Der symbolische Backend-Name, der unter x-google-api-management.backends definiert ist und an den das Gateway den Prompt sendet.
    • targetModel: Die Zielmodell-ID im Format <provider>/<model-id>. Der Modellrouter verwendet diesen String, um Anfragen und Antworten für das Zielmodell zu übersetzen. Das <provider> Präfix muss genau google, openai, oder anthropic sein. Die <model-id> muss eine gültige Modell-ID des Vertex AI Model Garden-Publishers sein. Das Gateway gibt diesen String im Feld model der Antwort zurück, die an den Client gesendet wird. Beispielwerte:
      • google/gemini-3.5-flash-lite
      • google/gemini-2.5-pro
      • openai/gpt-oss-120b-maas
      • anthropic/claude-opus-4-7
  4. x-google-model-router: Wenn Sie einen Modellrouter an einen API-Vorgangspfad anhängen möchten, geben Sie den Routernamen mit dem Attribut x-google-model-router an. Im vorherigen Beispiel ruft eine POST-Anfrage, die an /v1/chat/gemini-claude gesendet wird, gemini-claude-router auf, der den Prompt basierend auf dem in der JSON-Nutzlast angegebenen Modellnamen weiterleitet.

Schritt 3: API-Konfiguration erstellen und bereitstellen

Erstellen Sie eine API-Konfiguration mit Ihrer erstellten OpenAPI 3.x-Spezifikation und stellen Sie die Konfiguration für Ihre API Gateway-Instanz bereit, wie unter API für ein Gateway bereitstellen beschrieben.

Die API Gateway-Steuerungsebene verarbeitet Ihre Modellrouting-Konfiguration und aktiviert die Routingschicht. Nachdem die Bereitstellung des Gateways abgeschlossen ist, kann das Gateway Prompt-Anfragen im Format von OpenAI-kompatiblen JSON-Nutzlasten empfangen.

Schritt 4: Routingverhalten testen

Warten Sie, bis das Gateway den Status ACTIVE erreicht hat, bevor Sie es testen. Rufen Sie dann die URL ab:

gcloud api-gateway gateways describe GATEWAY_ID \
  --location=GATEWAY_LOCATION \
  --project=PROJECT_ID \
  --format='value(defaultHostname)'

Während der öffentlichen Vorschau geben Modellrouting-Gateways einen *.run.app-Hostnamen zurück. Rufen Sie den Hostnamen erst ab, wenn das Gateway ACTIVE ist. Der Wert, der gemeldet wird, während das Gateway noch erstellt wird, ist nicht die endgültige URL.

Testen Sie das Routingverhalten Ihres Gateways, indem Sie mit curl OpenAI-kompatible Prompt-Anfragen an die Gateway-URL (https://GATEWAY_URL) senden. In den folgenden Beispielen steht $TOKEN für ein gültiges Authentifizierungstoken, das mit einer der unter Authentifizierungsmethode auswählen beschriebenen Methoden abgerufen wurde.

Routing mit expliziten Regeln testen

Senden Sie einen Prompt, in dem Sie das Claude-Modell anthropic/claude-opus-4-7 anfordern:

curl https://GATEWAY_URL/v1/chat/gemini-claude \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "model": "claude-opus-4-7",
    "messages": [
      {
        "role": "system",
        "content": "You are a helpful assistant."
      },
      {
        "role": "user",
        "content": "Explain the concept of recursion in one sentence."
      }
    ]
  }'

Wenn Sie die Anfrage an /v1/chat/gemini-claude senden, wird gemini-claude-router aufgerufen. Das Attribut "model": "claude-opus-4-7" in der JSON-Nutzlast entspricht der expliziten Regel in gemini-claude-router, wodurch das Gateway die Anfrage an das Backend anthropic-claude-opus-47 weiterleitet.

Fallback-Standardmodell testen

Senden Sie einen Prompt mit einem nicht übereinstimmenden Modellnamen, um das Fallback-Routing zu testen:

curl https://GATEWAY_URL/v1/chat/gemini-claude \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "model": "unrecognized-model",
    "messages": [
      {
        "role": "user",
        "content": "Write a short poem about the ocean."
      }
    ],
    "stream": true
  }'

Wenn Sie die Anfrage an /v1/chat/gemini-claude senden, wird gemini-claude-router aufgerufen. Da das Attribut "model": "unrecognized-model" mit keiner expliziten Regel übereinstimmt, leitet das Gateway die Anfrage an das konfigurierte defaultModel des Routers weiter, das Backend gemini-35-flashlite.

Alternativen Routerpfad testen

Senden Sie einen Prompt, in dem Sie Gemini über den sekundären Routerendpunkt anfordern:

curl https://GATEWAY_URL/v1/chat/openai-gemini \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "model": "gemini-3.5-flash-lite",
    "messages": [
      {
        "role": "user",
        "content": "List the three largest cities in the world."
      }
    ]
  }'

Wenn Sie die Anfrage an /v1/chat/openai-gemini senden, wird openai-gemini-router aufgerufen. Das Attribut "model": "gemini-3.5-flash-lite" entspricht der expliziten Regel in diesem Router, wodurch das Gateway die Anfrage an das Backend gemini-35-flashlite weiterleitet. Auf ein einzelnes Backend kann von mehreren Routern verwiesen werden. In dieser Konfiguration dient gemini-35-flashlite als explizites Regelziel in openai-gemini-router und als Fallback-defaultModel in gemini-claude-router.

Beobachtbarkeit

Der Modellrouter ist so instrumentiert, dass Sie prüfen können, ob Ihr Gateway Traffic verarbeitet, Metadaten pro Anfrage mit Cloud Logging untersuchen und Fehler mit Cloud Monitoring diagnostizieren können.

Cloud Logging

Jede Anfrage, die über das Gateway weitergeleitet wird, generiert einen Eintrag im Standard-API Gateway-Anfragelog in Ihrem Google Cloud Projekt unter:

projects/YOUR_PROJECT_ID/logs/apigateway.googleapis.com%2Frequests

Jeder Logeintrag enthält die folgenden Felder:

  • httpRequest.requestUrl, httpRequest.status, httpRequest.latency
  • api, apiConfig, apiMethod
  • backendRequest.hostname: Der Hostname des Vertex AI-Backends, an das die Anfrage weitergeleitet wurde.
  • responseDetails: Bei Fehlern des Modellrouters wird eine markenspezifische Fehlerkategorie eingefügt (siehe Fehlerbehebung bei Fehlern des Modellrouters weiter unten).

Verwenden Sie den folgenden Cloud Logging-Abfragefilter, um die letzten Anfragen zu finden, die an ein bestimmtes Gateway gesendet wurden:

(resource.type="apigateway.googleapis.com/Gateway" OR resource.type="api")
logName="projects/YOUR_PROJECT_ID/logs/apigateway.googleapis.com%2Frequests"

Cloud Monitoring

Der Standard-API Gateway-Messwert apigateway.googleapis.com/proxy/request_count (BETA) gibt das Gateway-Trafficvolumen aufgeschlüsselt nach Folgendem an:

  • response_code_class: Einer der Werte 2xx, 3xx, 4xx oder 5xx.
  • api_config: Der Name der API-Konfiguration, die vom Gateway verwendet wird.

Mit diesem Messwert können Sie das Gesamt-Trafficvolumen und die Fehlerraten prüfen. Modellrouterspezifische Messwerte (z. B. Aufschlüsselungen nach Router oder Zielmodell) werden in einer zukünftigen Version hinzugefügt.

Wenn Sie die aggregierte Anfragelatenz verfolgen möchten, können Sie einen logbasierten Messwert aus dem httpRequest.latency Feld im Anfragelog erstellen.

Fehlerbehebung bei Fehlern des Modellrouters

Wenn eine Anfrage, die über den Modellrouter weitergeleitet wurde, fehlschlägt, gibt das Feld responseDetails im entsprechenden Anfragelogeintrag an, ob der Fehler in der Modellrouterschicht aufgetreten ist. Der Modellrouter gibt vier markenspezifische Kategorien aus:

responseDetails-Wert Bedeutung Typische Lösung
model_router_application_error Die Anfrage konnte nicht weitergeleitet werden. Dies deutet in der Regel auf eine fehlende Regel, eine Nutzlast mit einem model-Wert, der mit keiner Regel übereinstimmt (ohne konfiguriertes defaultModel), oder eine fehlerhafte Anfragenutzlast hin. Kundenseite: Prüfen Sie, ob der model-Parameter Ihrer Nutzlast mit einem der rule.model-Strings in Ihrer Routerkonfiguration übereinstimmt oder ob ein defaultModel-Fallback definiert ist. Prüfen Sie, ob der Anfragetext gültiges OpenAI-kompatibles JSON ist und explizit ein model-Attribut enthält. Während der öffentlichen Vorschau wird ein fehlendes model-Attribut in der Anfragenutzlast fälschlicherweise verarbeitet, anstatt abgelehnt zu werden.
model_router_timeout Die Zeitüberschreitung des Modellrouters pro Anfrage wurde überschritten. Die Anfrage ist möglicherweise ungewöhnlich groß oder komplex oder es gibt einen Kapazitätsengpass. Prüfen Sie die Komplexität der Anfrage und die Einstellungen für die Zeitüberschreitung für alle Backends. Wenn das Problem bei normalen Nutzlasten weiterhin auftritt, wenden Sie sich mit dem Zeitstempel der Anfrage und einem Logbeispiel an den Google Cloud Support.
model_router_upstream_error Das Upstream-Zielmodell hat einen HTTP-Fehler an das Gateway zurückgegeben. Upstream-Dienstseite: Prüfen Sie den Statuscode und die Nutzlast des Vertex AI-Dienstendpunkts. Wenn dies bei gültigen Anfragen unerwartet ist, stellen Sie eine Supportanfrage.
model_router_unavailable Der Modellrouter war aufgrund eines Übertragungs- oder Verbindungsproblems nicht über das Gateway erreichbar. Plattformseite: Stellen Sie eine Supportanfrage bei Google Cloud Support.

Nächste Schritte