Anfrage- und Ausgabenlimits für AI-Gateways steuern

Einführung

Eine KI-Anwendung benötigt zwei verschiedene Arten von Schutz vor Datenverkehr. Ein Rate Limit zählt Anfragen innerhalb eines Zeitfensters und stoppt plötzliche Spitzen, bevor sie das Modell erreichen. Ein Ausgabenlimit verfolgt die geschätzten Modellkosten über ein längeres Zeitfenster und schützt ein Budget. Das eine steuert, wie oft Aufrufer Arbeit senden dürfen; das andere steuert, wie viel diese Arbeit kosten darf.

Sie erstellen ein temporäres authentifiziertes AI Gateway. Es erlaubt innerhalb eines kurzen gleitenden Zeitfensters nur zwei Anfragen. Dadurch können drei kleine Anfragen eine 429 Too Many Requests-Antwort demonstrieren, ohne unnötigen Modellverkehr zu erzeugen. Nachdem das Zeitfenster abgelaufen ist, weisen Sie nach, dass normale Inferenz wieder funktioniert. Zusätzlich fügen Sie eine tägliche Ausgabenregel über fünf Dollar hinzu, die auf Workers AI und das ausgewählte Modell begrenzt ist. Sie lesen die gespeicherte Regel aus, anstatt Geld auszugeben, bis das Limit erreicht ist.

Wenn Sie diesen Kurs direkt aufgerufen haben, absolvieren Sie zuerst LabEx mit Ihrem Cloudflare-Konto verbinden. Dort werden das LabEx-Terminal, die Wrangler-Geräteautorisierung und die Konto-ID vorgestellt. Absolvieren Sie außerdem zuerst Inferenz über ein Gateway weiterleiten, da dieses Lab dessen separates Gateway und dessen Grenzen für die Upstream-Autorisierung wiederverwendet.

Das Lab verwendet das von Cloudflare gehostete Modell @cf/meta/llama-3.3-70b-instruct-fp8-fast mit der Standardabrechnung von Workers AI. Workers Paid, Unified Billing und Anmeldedaten externer Anbieter sind nicht erforderlich. Nur drei kleine Anfragen sollten das Modell erreichen. Beenden Sie das Lab, statt wiederholt Anfragen zu senden, wenn die gemeinsam genutzte tägliche Workers-AI-Zuweisung nicht verfügbar ist.

Das Setup installiert Node.js 22.22.0 und Wrangler 4.132.0 als projektspezifische Version unter /home/labex/project/ai-gateway-limits. Es bereitet unabhängige Prüfungen mit Lesezugriff vor, autorisiert Wrangler jedoch nicht, erstellt kein Gateway, erzeugt kein Token und sendet keinen Modellverkehr. LabEx zerstört die VM nach dem Lab. Sie löschen das Cloud-Gateway und das Token trotzdem, da eine zerstörte VM keine entfernten Ressourcen entfernen kann.

Die VM autorisieren und das Experiment benennen

In diesem Schritt verbinden Sie die neue VM mit Ihrem Lernkonto und speichern eindeutige Namen für die Ressourcen, die Sie besitzen.

Jedes LabEx-Lab startet in einer neuen VM. Durch die Autorisierung kann Wrangler Workers AI in Ihrem Lernkonto aufrufen. Ein Gateway wird dadurch noch nicht erstellt.

Wechseln Sie in das vorbereitete Projekt, prüfen Sie die festgelegte CLI-Version und starten Sie die Geräteautorisierung:

cd /home/labex/project/ai-gateway-limits
npx wrangler --version
npx wrangler login --device --browser=false --scopes account:read user:read ai:write

Öffnen Sie den angezeigten Link, geben Sie den Code ein und autorisieren Sie das vorgesehene Lernkonto. Prüfen Sie anschließend strukturierte Identitätsdaten:

npx wrangler whoami --json

Erwarten Sie Wrangler 4.132.0 und loggedIn: true. Ersetzen Sie YOUR_ACCOUNT_ID durch die tatsächliche 32-stellige ID, die für das vorgesehene Konto angezeigt wird:

GATEWAY_ID="labex-c09-g04-$(openssl rand -hex 6)"
TOKEN_NAME="$GATEWAY_ID-token"
cat > .labex/state.json <<JSON
{
  "accountId": "YOUR_ACCOUNT_ID",
  "gatewayId": "$GATEWAY_ID",
  "tokenName": "$TOKEN_NAME"
}
JSON
cat .labex/state.json

Diese Bezeichner sind keine Geheimnisse. Durch das Speichern richten sich alle späteren Lese- und Bereinigungsvorgänge ausschließlich auf die temporären Ressourcen dieses Labs.

Ein Gateway mit einem kurzen Anfragelimit erstellen

In diesem Schritt konfigurieren Sie einen gatewayweiten Anfragezähler, mit dem sich der Schutz vor Anfrage-Spitzen sicher demonstrieren lässt.

Ein Anfrage-Rate-Limit ist ein Zähler innerhalb eines Zeitfensters. Dieses Lab verwendet ein gleitendes Zeitfenster: AI Gateway betrachtet jederzeit die vergangenen 20 Sekunden. Nach zwei Anfragen in diesem Zeitraum wird eine weitere Anfrage mit HTTP 429 abgewiesen, bevor sie Workers AI erreicht.

Öffnen Sie das Cloudflare-Dashboard und wählen Sie AI → AI Gateway → Create a custom gateway. Verwenden Sie die gespeicherte gatewayId. Lassen Sie Collect Logs und Authenticated Gateway aktiviert. Aktivieren Sie Rate Limit Requests, wählen Sie Change und legen Sie Folgendes fest:

Limit: 2 Anfragen;
Intervall: 20 Sekunden;
Technik: sliding.

Lassen Sie Caching und Wiederholungen deaktiviert. Lassen Sie die Workers-AI-Abrechnung auf Standard und erstellen Sie anschließend das Gateway. Wenn Sie zuerst die Anfragerichtlinie erstellen, haben Sie eine stabile Ressource, bevor Sie die separate Kostenrichtlinie hinzufügen.

Ein begrenztes Ausgabenlimit hinzufügen und auslesen

In diesem Schritt fügen Sie demselben Gateway ein Kostenbudget hinzu und legen genau fest, welche Anfragen darunterfallen.

Ein Ausgabenlimit ist ein Budget, kein Anfragezähler. AI Gateway schätzt die Kosten jeder abgeschlossenen Anfrage anhand der Modellpreise und der Nutzung und addiert sie zu den passenden Regeln. Die Schätzung ist letztlich konsistent; paralleler Datenverkehr kann ein Budget daher kurzzeitig überschreiten. Rate Limiting bleibt auch dann nützlich, wenn eine Ausgabenregel vorhanden ist.

Öffnen Sie im neuen Gateway den Tab Settings. Aktivieren Sie Spend Limits, wählen Sie Add rule und konfigurieren Sie eine Regel:

Kostenlimit: $5;
Zeitfenster: 1 day;
Technik: Sliding;
Anbieterauswahl: workers-ai;
Modellauswahl: meta/llama-3.3-70b-instruct-fp8-fast.

Speichern Sie die Regel und prüfen Sie anschließend beide Kontrollen. Das Modellfeld verwendet die Form author/model, weil der Anbieter bereits separat ausgewählt wurde. Die spätere Inferenz-URL verwendet weiterhin den vollständigen Workers-AI-Namen, der mit @cf/ beginnt.

Die Gateway-Einstellungen zeigen ein gleitendes Limit von zwei Anfragen und eine aktivierte Ausgabenlimitregel

Durch die Filter für Anbieter und Modell wird daraus eine eng begrenzte Regel statt eines gemeinsamen Budgets für nicht zusammengehörigen Gateway-Verkehr. Fünf Dollar sind für diese kleine Übung absichtlich hoch angesetzt: Sie prüfen die Richtlinie, ohne zu versuchen, sie auszuschöpfen.

Öffnen Sie My Profile → API Tokens, wählen Sie Create Token → Create Custom Token und verwenden Sie den gespeicherten tokenName. Fügen Sie die beiden Kontoberechtigungen AI Gateway — Edit und AI Gateway — Run hinzu und schließen Sie ausschließlich das vorgesehene Lernkonto ein. Edit ermöglicht es dem Lab, das genaue Gateway auszulesen und später zu löschen; Run authentifiziert den Inferenzverkehr. Wrangler stellt die separate Upstream-Anmeldedaten für Workers AI bereit.

Prüfen Sie die Zusammenfassung und erstellen Sie anschließend das Token. Cloudflare zeigt es einmal innerhalb eines Prüfungsbefehls an. Kopieren Sie nur den Tokenwert nach Bearer, nicht den umgebenden curl-Befehl, und speichern Sie ihn über eine verborgene Eingabe:

bash -c '
while :; do
  read -ersp "Paste the AI Gateway token: " GATEWAY_TOKEN
  printf "\n"
  [ -n "$GATEWAY_TOKEN" ] && break
  printf "Token cannot be empty; paste it again.\n" >&2
done
umask 077
printf "%s" "$GATEWAY_TOKEN" > .labex/gateway-token
unset GATEWAY_TOKEN
chmod 600 .labex/gateway-token
'

Lesen Sie die wichtigen nicht geheimen Felder über die Verwaltungs-API aus:

ACCOUNT_ID=$(node -p 'JSON.parse(require("fs").readFileSync(".labex/state.json")).accountId')
GATEWAY_ID=$(node -p 'JSON.parse(require("fs").readFileSync(".labex/state.json")).gatewayId')
GATEWAY_TOKEN=$(cat .labex/gateway-token)
curl --http1.1 -fsS \
  -H "Authorization: Bearer $GATEWAY_TOKEN" \
  "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/ai-gateway/gateways/$GATEWAY_ID" \
  > .labex/gateway.json
unset GATEWAY_TOKEN
node - <<'NODE'
const b=require('./.labex/gateway.json'), g=b.result||{}, spend=g.spend_limits||{};
console.log(JSON.stringify({
  success:b.success,
  id:g.id,
  rate:{limit:g.rate_limiting_limit,interval:g.rate_limiting_interval,technique:g.rate_limiting_technique},
  spend_limits:{enabled:spend.enabled,rules:spend.rules}
},null,2));
NODE

Erwarten Sie eine gleitende Ratenregel mit zwei Anfragen und 20 Sekunden sowie eine aktivierte tägliche Kostenregel über fünf Dollar mit den Filtern für Anbieter und Modell. Dieses Auslesen bestätigt die Konfiguration. Es bedeutet nicht, dass das Budget bereits verbraucht wurde.

Die Ablehnung von Anfragen mit drei Aufrufen beobachten

In diesem Schritt verwenden Sie drei kleine Anfragen, um die Anfragezählungsrichtlinie zu beobachten, ohne eine große Spitze zu erzeugen.

Nun senden Sie drei kleine Anfragen nacheinander. Die ersten beiden werden zugelassen. Die dritte sollte 429 erhalten und das Modell nie erreichen. Das ist sicherer und kostengünstiger, als eine große Verkehrsspitze zu erzeugen.

Speichern Sie das kurzlebige Wrangler-Token dieser VM geschützt für die Upstream-Autorisierung von Workers AI:

umask 077
npx wrangler auth token --json \
  | node -e 'let s="";process.stdin.on("data",d=>s+=d).on("end",()=>process.stdout.write(JSON.parse(s).token))' \
  > .labex/upstream-token
chmod 600 .labex/upstream-token

Senden Sie die drei Aufrufe. Jeder Aufruf enthält synthetische Metadaten, damit die Anfragen in den Protokollen leicht erkennbar sind. Die Ausgabenregel selbst findet sie über die Filter für Workers-AI-Anbieter und Modell:

ACCOUNT_ID=$(node -p 'JSON.parse(require("fs").readFileSync(".labex/state.json")).accountId')
GATEWAY_ID=$(node -p 'JSON.parse(require("fs").readFileSync(".labex/state.json")).gatewayId')
MODEL='@cf/meta/llama-3.3-70b-instruct-fp8-fast'
GATEWAY_TOKEN=$(cat .labex/gateway-token)
UPSTREAM_TOKEN=$(cat .labex/upstream-token)
for NUMBER in 1 2 3; do
  METADATA=$(printf '{"lab":"g04-limits","request":"burst-%s","synthetic":true}' "$NUMBER")
  STATUS=$(curl --http1.1 -sS \
    -o ".labex/burst-$NUMBER-response.json" -w '%{http_code}' \
    -H "cf-aig-authorization: Bearer $GATEWAY_TOKEN" \
    -H "Authorization: Bearer $UPSTREAM_TOKEN" \
    -H "cf-aig-metadata: $METADATA" \
    -H 'Content-Type: application/json' \
    --data "{\"prompt\":\"Reply with the number $NUMBER.\",\"max_tokens\":4}" \
    "https://gateway.ai.cloudflare.com/v1/$ACCOUNT_ID/$GATEWAY_ID/workers-ai/$MODEL")
  printf '%s\n' "$STATUS" | tee ".labex/burst-$NUMBER-status.txt"
done
unset GATEWAY_TOKEN UPSTREAM_TOKEN METADATA

Erwarten Sie:

200
200
429

Die 429-Antwort ist ein erfolgreicher Schutzmechanismus. Sie bedeutet, dass die Anfrage am Gateway gestoppt wurde. Daher hat sie keine weitere Modellinferenz verbraucht und den Ausgabenzähler nicht erhöht.

Warten, bis sich das gleitende Zeitfenster erholt

In diesem Schritt warten Sie, bis das kurze Zeitfenster abgelaufen ist, und weisen nach, dass das Gateway wieder normale Inferenz zulässt.

Ein Rate Limit soll Spitzen schützen, ohne die Anwendung dauerhaft zu deaktivieren. Warten Sie etwas länger als das Zeitfenster von 20 Sekunden und senden Sie anschließend eine weitere kleine Anfrage:

sleep 22
ACCOUNT_ID=$(node -p 'JSON.parse(require("fs").readFileSync(".labex/state.json")).accountId')
GATEWAY_ID=$(node -p 'JSON.parse(require("fs").readFileSync(".labex/state.json")).gatewayId')
MODEL='@cf/meta/llama-3.3-70b-instruct-fp8-fast'
GATEWAY_TOKEN=$(cat .labex/gateway-token)
UPSTREAM_TOKEN=$(cat .labex/upstream-token)
STATUS=$(curl --http1.1 -sS \
  -o .labex/recovery-response.json -w '%{http_code}' \
  -H "cf-aig-authorization: Bearer $GATEWAY_TOKEN" \
  -H "Authorization: Bearer $UPSTREAM_TOKEN" \
  -H 'cf-aig-metadata: {"lab":"g04-limits","request":"recovery","synthetic":true}' \
  -H 'Content-Type: application/json' \
  --data '{"prompt":"Reply only with recovered.","max_tokens":4}' \
  "https://gateway.ai.cloudflare.com/v1/$ACCOUNT_ID/$GATEWAY_ID/workers-ai/$MODEL")
unset GATEWAY_TOKEN UPSTREAM_TOKEN
printf '%s\n' "$STATUS" | tee .labex/recovery-status.txt
node -e 'const b=require("./.labex/recovery-response.json"); console.log(b.result?.response ?? b.result)'

Erwarten Sie HTTP 200 und eine kurze generierte Antwort. Die Wiederherstellung zeigt, dass die 429-Antwort vom konfigurierten Zeitfenster verursacht wurde und nicht durch falsche Anmeldedaten oder ein fehlerhaftes Modell.

Die Richtlinie mit Nachweisen im Dashboard verknüpfen

In diesem Schritt ordnen Sie die API- und HTTP-Ergebnisse den im Dashboard sichtbaren Kontrollen und Protokollen zu.

Kehren Sie zu AI → AI Gateway zurück, wählen Sie das gespeicherte Gateway aus und öffnen Sie Settings. Bestätigen Sie, dass das Rate Limit weiterhin zwei Anfragen, 20 Sekunden und eine gleitende Durchsetzung anzeigt. Prüfen Sie unter Spend Limits die einzelne Regel und kontrollieren Sie deren Kostenlimit von fünf Dollar, das gleitende Zeitfenster von einem Tag sowie die Filter für Anbieter und Modell.

Das ausgewählte Gateway zeigt die gespeicherten Rate- und begrenzten Ausgabenkontrollen

Öffnen Sie anschließend Logs. Die beiden anfänglich erfolgreichen Anfragen und die wiederhergestellte Anfrage sollten nach der normalen Protokollverzögerung erscheinen. Die abgewiesene dritte Anfrage kann anders dargestellt werden, weil sie vor der Inferenz beim Anbieter gestoppt wurde. Der gespeicherte HTTP-Status ist der maßgebliche Nachweis für das Rate Limit.

Die Gateway-Protokolle zeigen nur die kleinen erlaubten Workers-AI-Aufrufe rund um den Rate-Limit-Test

Beachten Sie, was nicht erforderlich ist: Sie müssen keine fünf Dollar ausgeben, die Regel nicht auf einen gefährlich kleinen Wert reduzieren und nicht so lange wiederholen, bis eine Kostenablehnung erscheint. Das Auslesen über die Verwaltungs-API bestätigt den Geltungsbereich der Ausgabenrichtlinie. Das Experiment mit drei Aufrufen weist die Durchsetzung der Anfragezählung separat nach.

Das temporäre Gateway löschen

In diesem Schritt entfernen Sie nur das Gateway, das im Lab-Inventar genannt ist, und weisen nach, dass es nicht mehr vorhanden ist, während die Autorisierung weiterhin verfügbar bleibt.

Löschen Sie das Gateway, solange das Verwaltungstoken noch nachweisen kann, dass genau diese Ressource entfernt wurde:

ACCOUNT_ID=$(node -p 'JSON.parse(require("fs").readFileSync(".labex/state.json")).accountId')
GATEWAY_ID=$(node -p 'JSON.parse(require("fs").readFileSync(".labex/state.json")).gatewayId')
GATEWAY_TOKEN=$(cat .labex/gateway-token)
curl --http1.1 -fsS -X DELETE \
  -H "Authorization: Bearer $GATEWAY_TOKEN" \
  "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/ai-gateway/gateways/$GATEWAY_ID" \
  | node -e 'let s="";process.stdin.on("data",d=>s+=d).on("end",()=>{const b=JSON.parse(s);if(!b.success)process.exit(1);console.log("gateway deletion accepted")})'
unset GATEWAY_TOKEN

GATEWAY_TOKEN=$(cat .labex/gateway-token)
curl --http1.1 -fsS \
  -H "Authorization: Bearer $GATEWAY_TOKEN" \
  "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/ai-gateway/gateways" \
  > .labex/gateways-after-delete.json
unset GATEWAY_TOKEN
node -e 'const b=require("./.labex/gateways-after-delete.json"),id=process.argv[1],found=(b.result||[]).some(g=>g.id===id);console.log("gateway absent:",!found);if(found)process.exit(1)' "$GATEWAY_ID"

Erwarten Sie gateway absent: true. Ein authentifiziertes Inventar unterscheidet eine tatsächliche Löschung von einem Netzwerkfehler oder einer Seite, auf die Sie keinen Zugriff mehr haben.

Das Token widerrufen und sich abmelden

In diesem Schritt widerrufen Sie das verbleibende Dashboard-Token, löschen beide Kopien in der VM und trennen Wrangler.

Öffnen Sie im Cloudflare-Dashboard My Profile → API Tokens. Suchen Sie den exakt gespeicherten tokenName, öffnen Sie Actions, wählen Sie Delete, prüfen Sie die Bestätigung und löschen Sie nur dieses Token. Der Widerruf ist jetzt sicher, da die Löschung des Gateways bereits nachgewiesen wurde.

Löschen Sie beide temporären Tokenkopien und trennen Sie Wrangler:

shred -u .labex/gateway-token .labex/upstream-token
npx wrangler logout
npx wrangler whoami --json || true
test ! -e .labex/gateway-token -a ! -e .labex/upstream-token \
  && echo "local token files removed"

Erwarten Sie loggedIn: false und local token files removed. Die Dashboard-Sitzung ist davon getrennt und bleibt angemeldet. LabEx zerstört diese temporäre VM, wenn das Lab endet, anstatt sie zu erhalten.

Zusammenfassung

Sie haben zwei sich ergänzende AI-Gateway-Kontrollen angewendet. Ein gleitendes Zeitfenster mit zwei Anfragen wies die dritte Anfrage mit geringem Volumen durch HTTP 429 ab und ließ den Datenverkehr nach Ablauf des Zeitfensters automatisch wieder zu. Eine separate tägliche Ausgabenregel über fünf Dollar wurde auf Workers AI und ein Modell begrenzt. Ihre gespeicherte Konfiguration wurde geprüft, ohne Modellnutzung zu verschwenden.

Im nächsten Lab verwenden Sie eine weitere Zuverlässigkeitskontrolle des Gateways: einen begrenzten Fallback. Sie leiten einen kontrollierten Fehler des primären Modells an ein kompatibles zweites Modell weiter, während eine erfolgreiche Anfrage an das primäre Modell bereits im ersten Schritt abgeschlossen wird.

Anfrage- und Ausgabenlimits steuern