Contrôler les limites de requêtes et de dépenses d’une passerelle IA

Introduction

Une application d’IA a besoin de deux types différents de protection du trafic. Une limite de débit compte les requêtes sur une période donnée et bloque un pic soudain avant qu’il n’atteigne le modèle. Une limite de dépenses suit le coût estimé du modèle sur une période plus longue et protège un budget. La première contrôle la fréquence à laquelle les appelants peuvent envoyer du travail ; la seconde contrôle le coût maximal de ce travail.

Vous allez créer une passerelle AI Gateway authentifiée et temporaire. Elle n’autorisera que deux requêtes sur une courte fenêtre glissante, afin que trois petites requêtes puissent démontrer une réponse 429 Too Many Requests sans générer un trafic inutile vers le modèle. Une fois la fenêtre écoulée, vous vérifierez que les inférences normales fonctionnent de nouveau. Vous ajouterez également une règle de dépenses quotidienne de cinq dollars, limitée à Workers AI et au modèle sélectionné. Vous relirez la règle enregistrée au lieu de dépenser de l’argent pour l’épuiser.

Si vous avez accédé directement à ce cours, commencez par terminer Connect LabEx to Your Cloudflare Account. Ce laboratoire présente le terminal LabEx, l’autorisation de l’appareil Wrangler et l’ID du compte. Terminez également Route Inference Through a Gateway avant ce laboratoire, car celui-ci réutilise ses limites distinctes entre la passerelle et l’autorisation en amont.

Le laboratoire utilise le modèle hébergé par Cloudflare @cf/meta/llama-3.3-70b-instruct-fp8-fast avec la facturation Workers AI Standard. Workers Paid, Unified Billing et les identifiants de fournisseurs externes ne sont pas nécessaires. Seules trois petites requêtes doivent atteindre le modèle. Arrêtez-vous au lieu de réessayer continuellement si l’allocation quotidienne Workers AI partagée n’est pas disponible.

La configuration installe Node.js 22.22.0 et Wrangler 4.132.0, installé localement dans le projet /home/labex/project/ai-gateway-limits. Elle prépare des vérifications indépendantes en lecture seule, mais n’autorise pas Wrangler, ne crée pas de passerelle, ne crée pas de jeton et n’envoie pas de trafic au modèle. LabEx détruit la machine virtuelle à la fin du laboratoire ; vous devez néanmoins supprimer la passerelle et le jeton cloud, car la destruction d’une machine virtuelle ne peut pas supprimer les ressources distantes.

Autoriser la machine virtuelle et nommer l’expérience

Dans cette étape, vous allez connecter la nouvelle machine virtuelle à votre compte d’apprentissage et enregistrer des noms uniques pour les ressources qui vous appartiennent.

Chaque laboratoire LabEx démarre dans une nouvelle machine virtuelle. Autoriser cette machine virtuelle permet à Wrangler d’appeler Workers AI dans votre compte d’apprentissage ; cela ne crée pas encore de passerelle.

Accédez au projet préparé, vérifiez la version de la CLI épinglée et démarrez l’autorisation de l’appareil :

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

Ouvrez le lien affiché, saisissez le code et autorisez le compte d’apprentissage prévu. Inspectez ensuite les informations d’identité structurées :

npx wrangler whoami --json

Vous devez obtenir Wrangler 4.132.0 et loggedIn: true. Remplacez YOUR_ACCOUNT_ID par l’ID réel de 32 caractères affiché pour le compte prévu :

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

Ces identifiants ne sont pas des secrets. Les enregistrer permet à toutes les étapes ultérieures de cibler uniquement les ressources temporaires de ce laboratoire, y compris lors du nettoyage.

Créer une passerelle avec une limite de requêtes courte

Dans cette étape, vous allez configurer un compteur de requêtes au niveau de la passerelle afin de démontrer la protection contre les pics de trafic en toute sécurité.

Une limite de débit est un compteur associé à une fenêtre temporelle. Ce laboratoire utilise une fenêtre glissante : à tout moment, AI Gateway examine les 20 secondes précédentes. Après deux requêtes dans cette période, une autre requête est rejetée avec le statut HTTP 429 avant d’atteindre Workers AI.

Ouvrez le tableau de bord Cloudflare et choisissez AI → AI Gateway → Create a custom gateway. Utilisez le gatewayId enregistré. Laissez Collect Logs et Authenticated Gateway activés. Activez Rate Limit Requests, choisissez Change, puis définissez :

limite : 2 requêtes ;
intervalle : 20 secondes ;
méthode : sliding.

Laissez la mise en cache et les nouvelles tentatives désactivées. Conservez la facturation Workers AI sur Standard, puis créez la passerelle. Créer d’abord la règle de requêtes fournit une ressource stable avant l’ajout de la règle de coûts distincte.

Ajouter une limite de dépenses ciblée et la relire

Dans cette étape, vous allez ajouter un budget de coûts à la même passerelle et définir précisément les requêtes qui lui sont associées.

Une limite de dépenses est un budget, pas un compteur de requêtes. AI Gateway estime le coût de chaque requête terminée à partir du prix du modèle et de son utilisation, puis l’ajoute aux règles correspondantes. Cette estimation est finalement cohérente ; un trafic simultané peut donc dépasser brièvement un budget. La limitation de débit reste utile même lorsqu’une règle de dépenses existe.

Ouvrez l’onglet Settings de la nouvelle passerelle. Activez Spend Limits, choisissez Add rule, puis configurez une règle :

limite de coût : $5 ;
fenêtre : 1 day ;
méthode : Sliding ;
filtre du fournisseur : workers-ai ;
filtre du modèle : meta/llama-3.3-70b-instruct-fp8-fast.

Enregistrez la règle, puis vérifiez les deux contrôles. Le champ du modèle utilise le format author/model, car le fournisseur est déjà sélectionné séparément ; l’URL d’inférence utilisée plus tard conserve le nom complet de Workers AI commençant par @cf/.

Les paramètres de la passerelle affichent une limite glissante de deux requêtes et une règle de limite de dépenses activée

Les filtres du fournisseur et du modèle rendent cette règle ciblée, plutôt qu’un budget partagé pour le trafic sans rapport avec cette expérience. Cinq dollars constituent volontairement une limite élevée pour cet exercice très court : vous vérifierez la règle sans chercher à l’épuiser.

Ouvrez My Profile → API Tokens, choisissez Create Token → Create Custom Token, puis utilisez le tokenName enregistré. Ajoutez deux autorisations de compte, AI Gateway — Edit et AI Gateway — Run, puis n’incluez que le compte d’apprentissage prévu. Edit permet au laboratoire de lire puis de supprimer précisément sa passerelle ; Run authentifie le trafic d’inférence. Wrangler fournit l’identifiant distinct nécessaire à Workers AI en amont.

Après avoir vérifié le récapitulatif, créez le jeton. Cloudflare l’affiche une seule fois dans une commande de vérification. Copiez uniquement la valeur du jeton située après Bearer, sans la commande curl environnante, puis enregistrez-la avec une saisie masquée :

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
'

Relisez les champs importants qui ne sont pas secrets via l’API de gestion :

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

Vous devez obtenir une règle de limitation de débit glissante de deux requêtes sur 20 secondes et une règle de coûts quotidienne de cinq dollars activée, avec les filtres du fournisseur et du modèle. Cette relecture prouve la configuration ; elle ne signifie pas que le budget a été consommé.

Observer le rejet d’une requête avec trois appels

Dans cette étape, vous allez utiliser trois petites requêtes pour observer la règle de comptage sans créer un pic de trafic important.

Vous allez maintenant envoyer trois petites requêtes séquentielles. Les deux premières sont autorisées. La troisième doit recevoir le statut 429 et ne jamais atteindre le modèle. Cette méthode est plus sûre et moins coûteuse que la génération d’un important pic de trafic.

Enregistrez de manière privée le jeton Wrangler de courte durée de cette machine virtuelle pour autoriser Workers AI en amont :

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

Envoyez les trois appels. Chacun contient des métadonnées synthétiques afin de reconnaître facilement les requêtes dans les journaux ; la règle de dépenses les associe elle-même grâce aux filtres du fournisseur Workers AI et du modèle :

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

Vous devez obtenir :

200
200
429

Le statut 429 indique que la protection fonctionne correctement. Il signifie que la requête a été bloquée par la passerelle ; elle n’a donc pas déclenché une autre inférence du modèle ni augmenté le compteur de dépenses.

Attendre la récupération de la fenêtre glissante

Dans cette étape, vous allez attendre que la fenêtre courte soit écoulée et vérifier que la passerelle autorise de nouveau les inférences normales.

Une limite de débit doit protéger contre les pics sans désactiver définitivement l’application. Attendez légèrement plus longtemps que la fenêtre de 20 secondes, puis envoyez une autre petite requête :

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)'

Vous devez obtenir le statut HTTP 200 et une courte réponse générée. La récupération prouve que le statut 429 provenait de la fenêtre temporelle configurée, et non d’identifiants incorrects ou d’un modèle défaillant.

Relier la règle aux éléments visibles dans le tableau de bord

Dans cette étape, vous allez relier les résultats de l’API et des requêtes HTTP aux contrôles et aux journaux visibles dans le tableau de bord.

Retournez dans AI → AI Gateway, sélectionnez la passerelle enregistrée et ouvrez Settings. Vérifiez que la limite de débit indique toujours deux requêtes, 20 secondes et une application glissante. Dans Spend Limits, inspectez l’unique règle et vérifiez son coût de cinq dollars, sa fenêtre glissante d’un jour ainsi que ses filtres du fournisseur et du modèle.

La passerelle sélectionnée affiche les contrôles de débit enregistrés et la limite de dépenses ciblée

Ouvrez ensuite Logs. Les deux premières requêtes réussies et la requête de récupération devraient apparaître après la propagation normale des journaux. La troisième requête rejetée peut être représentée différemment, car elle s’est arrêtée avant l’inférence auprès du fournisseur ; le statut HTTP enregistré est la preuve faisant autorité de la limitation de débit.

Les journaux de la passerelle affichent uniquement les petits appels Workers AI autorisés autour du test de limitation de débit

Notez ce qui n’est pas nécessaire : vous ne dépensez pas cinq dollars, vous ne réduisez pas la règle à une valeur dangereusement faible et vous ne bouclez pas jusqu’à l’apparition d’un rejet lié aux coûts. La relecture via l’API de gestion prouve la portée de la règle de dépenses, tandis que l’expérience en trois appels prouve séparément l’application du comptage des requêtes.

Supprimer la passerelle temporaire

Dans cette étape, vous allez supprimer uniquement la passerelle indiquée dans l’inventaire du laboratoire et prouver son absence tout en conservant l’autorisation disponible.

Supprimez la passerelle tant que le jeton de gestion peut encore prouver que la ressource exacte a disparu :

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"

Vous devez obtenir gateway absent: true. Un inventaire authentifié distingue une véritable suppression d’une défaillance réseau ou d’une page à laquelle vous n’avez plus accès.

Révoquer le jeton et se déconnecter

Dans cette étape, vous allez révoquer le dernier jeton du tableau de bord, supprimer les deux copies présentes dans la machine virtuelle et déconnecter Wrangler.

Dans le tableau de bord Cloudflare, ouvrez My Profile → API Tokens. Recherchez le tokenName exact enregistré, ouvrez Actions, choisissez Delete, vérifiez la confirmation, puis supprimez uniquement ce jeton. Vous pouvez le révoquer maintenant, car la suppression de la passerelle a déjà été vérifiée.

Supprimez les deux copies temporaires des jetons et déconnectez 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"

Vous devez obtenir loggedIn: false et local token files removed. La session du tableau de bord est distincte et reste ouverte. LabEx détruit cette machine virtuelle temporaire à la fin du laboratoire au lieu de la conserver.

Résumé

Vous avez appliqué deux contrôles complémentaires d’AI Gateway. Une fenêtre glissante de deux requêtes a rejeté la troisième requête à faible volume avec le statut HTTP 429, puis a automatiquement autorisé de nouveau le trafic après l’expiration de la fenêtre. Une règle de dépenses quotidienne distincte de cinq dollars a été limitée à Workers AI et à un modèle ; sa configuration enregistrée a été vérifiée sans gaspiller d’utilisation du modèle.

Le prochain laboratoire utilise un autre contrôle de fiabilité de la passerelle : une solution de secours limitée. Vous acheminerez l’échec contrôlé d’un modèle principal vers un second modèle compatible, tandis qu’une requête saine vers le modèle principal aboutira dès sa première tentative.

Contrôler les requêtes et les limites de dépenses