Weiterleitung von LLM-Datenverkehr über verschiedene Anbieter hinweg

Einführung

Eine weitere Aufgabe des Agent-Gateways besteht darin, als Vermittler zwischen den Modellen zu fungieren, die Ihre Agenten aufrufen. Ihre Anwendung kommuniziert mit einem OpenAI-kompatiblen Endpunkt – dem Gateway – und das Gateway entscheidet, welcher Anbieter die jeweilige Anfrage tatsächlich bearbeitet. Das Wechseln oder Hinzufügen eines Anbieters erfolgt durch eine Konfigurationsänderung, ohne dass der Anwendungscode geändert werden muss.

In diesem Tutorial werden Chat-Vervollständigungen über AgentGateway an ein Modell weitergeleitet, das auf Ihrem eigenen Rechner läuft, und anschließend über zwei Anbieter verteilt. Durch die Verwendung eines selbst gehosteten Modells kommen im gesamten Tutorial keine kostenpflichtigen API-Aufrufe zum Einsatz.

In dieser Schritt-für-Schritt-Anleitung wird eine lokale llama.cpp Server auf Port 8090 im Dienst gemma-4-12b, erreichbar vom Cluster unter host.docker.internal:8090. Jeder OpenAI-kompatible Endpunkt funktioniert – geben Sie einfach Ihren eigenen Host, Port und Modellnamen ein.

Schritt 1 – Richten Sie ein Backend auf Ihr Modell aus

Ein LLM-Backend ist ein AgentGatewayBackend mit einem ai Anbieter. Der Gastgeber und Hafen unter Anbieter Überschreiben Sie den Standard-Endpunkt, damit das Gateway Anfragen an Ihren Server weiterleitet. Selbst gehostete Endpunkte benötigen in der Regel keinen Schlüssel, daher wird der Auth-Block weggelassen:

kubectl apply -f- <<'EOF'
apiVersion: agentgateway.dev/v1alpha1
kind: AgentgatewayBackend
metadata:
  name: local-llm
  namespace: agentgateway-system
spec:
  ai:
    provider:
      host: host.docker.internal
      port: 8090
      openai:
        model: gemma-4-12b-it-Q5_K_M.gguf
EOF

Bestätigen Sie, dass es akzeptiert wurde:

kubectl get agentgatewaybackend local-llm -n agentgateway-system

NAME        AKZEPTIERT   ALTER
local-llm   Ja       4s

Schritt 2 – Chat-Abschluss einrichten und testen

Verbinden Sie das Backend mit dem Gateway:

kubectl apply -f- <<'EOF'
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: local-llm
  namespace: agentgateway-system
spec:
  parentRefs:
    - name: agentgateway-proxy
      namespace: agentgateway-system
  rules:
    - backendRefs:
      - name: local-llm
        namespace: agentgateway-system
        group: agentgateway.dev
        kind: AgentgatewayBackend
EOF

Leiten Sie die Ports des Proxys weiter und senden Sie eine Standardanfrage zur Vervollständigung von OpenAI-Chats:

kubectl port-forward deployment/agentgateway-proxy -n agentgateway-system 8080:80

curl -s localhost:8080/v1/chat/completions -H 'content-type: application/json' -d '{
  "model": "",
  "messages": [{"role": "user", "content": "Reply with exactly: agentgateway works"}]
}'

{
  "model": "gemma-4-12b-it-Q5_K_M.gguf",
  "choices": [{ "message": { "role": "assistant", "content": "agentgateway works" }, "finish_reason": "stop" }],
  "usage": { "prompt_tokens": 23, "completion_tokens": 57, "total_tokens": 80 }
}

Ihre Anwendung hat eine normale OpenAI-Anfrage an das Gateway gesendet, und das Gateway hat diese anhand des Modells auf Ihrem Rechner bearbeitet.

Schritt 3 – Lastenausgleich zwischen den Anbietern

Um den Datenverkehr zu verteilen – oder ein Failover durchzuführen –, listen Sie mehrere Anbieter in einem Backend auf. agentgateway verteilt die Last über die Anbieter einer Gruppe mithilfe eines „Power-of-Two-Choices“-Algorithmus. Im folgenden Beispiel werden zwei Einträge verwendet, die auf denselben lokalen Server verweisen, um die Kosten gering zu halten; in der Produktion ist jeder Eintrag ein anderer Anbieter, und bei einem gehosteten Anbieter kommt noch ein auth Block, der auf ein Secret verweist:

kubectl apply -f- <<'EOF'
apiVersion: agentgateway.dev/v1alpha1
kind: AgentgatewayBackend
metadata:
  name: llm-pool
  namespace: agentgateway-system
spec:
  ai:
    groups:
      - providers:
          - name: local-a
            host: host.docker.internal
            port: 8090
            openai:
              model: gemma-4-12b-it-Q5_K_M.gguf
          - name: local-b
            host: host.docker.internal
            port: 8090
            openai:
              model: gemma-4-12b-it-Q5_K_M.gguf
EOF

Rufen Sie die Route zum Pool auf und testen Sie sie auf dieselbe Weise:

kubectl apply -f- <<'EOF'
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: llm-pool
  namespace: agentgateway-system
spec:
  parentRefs:
    - name: agentgateway-proxy
      namespace: agentgateway-system
  rules:
    - backendRefs:
      - name: llm-pool
        namespace: agentgateway-system
        group: agentgateway.dev
        kind: AgentgatewayBackend
EOF

curl -s localhost:8080/v1/chat/completions -H 'content-type: application/json' -d '{
  "model": "", "messages": [{"role": "user", "content": "Reply with exactly: pool ok"}]
}'

{ "model": "gemma-4-12b-it-Q5_K_M.gguf",
  "choices": [{ "message": { "content": "pool ok" }, "finish_reason": "stop" }],
  "usage": { "total_tokens": 105 } }

Damit es sich um ein echtes Failover handelt, geben Sie einem Anbieter-Eintrag einen anderen Gastgeber/Modell (zum Beispiel ein Hosting-Anbieter mit einem auth.secretRef) und behalten Sie Ihr selbst gehostetes Modell als das andere bei. Das Gateway verteilt dann die Last auf die funktionsfähigen Anbieter und leitet den Datenverkehr um einen ausfallenden Anbieter herum – und Ihre Anwendung ruft weiterhin denselben Endpunkt auf.

Ein Hinweis zum Hinzufügen eines gehosteten Anbieters

Ein gehosteter Anbieter benötigt einen Schlüssel. Erstellen Sie ein Secret und verweisen Sie in der Konfiguration des Anbieters darauf. policies.auth:

# innerhalb eines Provider-Eintrags
- name: openai
  openai:
    Modell: gpt-4o
  Richtlinien:
    Authentifizierung:
      secretRef:
        name: openai-secret

agentgateway erfasst zudem die Token-Nutzung pro Anfrage, was die Grundlage für Budgetierung und Kostenberichterstattung bildet (siehe die unten verlinkte LLM-Dokumentation).

Aufräumen

kubectl delete httproute local-llm llm-pool -n agentgateway-system
kubectl delete agentgatewaybackend local-llm llm-pool -n agentgateway-system

Wie geht es weiter?

Das Gateway fungiert nun als Schnittstelle zu Ihren Tools (MCP) und Ihren Modellen (LLM). Anschließend leitet es den Datenverkehr zwischen den Agenten selbst weiter: Agent-zu-Agent-Kommunikation (A2A) mit einheitlicher Sicherheit.

Als Nächstes in dieser Reihe: Kommunikation zwischen Agenten.

Zusammenfassung

Ein LLM-Backend ist ein AgentGatewayBackend dessen ai.provider Sätze Gastgeber, Hafenund openai.model; Selbst gehostete Endpunkte benötigen keinen Authentifizierungsblock.
Anwendungen senden normale OpenAI-Chat-Completion-Anfragen an das Gateway, und das Gateway stellt diese über den konfigurierten Anbieter bereit.
ai.groups[].providers[] listet mehrere Anbieter in einem Backend auf; das Gateway sorgt für den Lastausgleich zwischen diesen und leitet den Datenverkehr um einen ausgefallenen Anbieter herum.
Ein Hosting-Anbieter fügt hinzu policies.auth.secretRef; der Anwendungsendpunkt ändert sich nie.