Aller au contenu principal

Rate Limiting pour Gateways IA : Stratégies de Quotas par Token

· 16 minutes de lecture
STOA Team
STOA Team
The STOA Platform Team

Les gateways IA nécessitent des approches de rate limiting spécialisées qui tiennent compte de la consommation de tokens, des réponses en streaming et des coûts variables des requêtes. Les limites traditionnelles de requêtes par seconde ne capturent pas la vraie utilisation des ressources par les charges de travail IA. Ce guide couvre les stratégies de rate limiting par token, la gestion des quotas par tenant et les patterns d'implémentation pour les gateways IA en production.

Pourquoi les Gateways IA Ont Besoin d'un Rate Limiting Différent​

Les gateways API traditionnels implémentent généralement le rate limiting basé sur des requêtes par seconde ou par minute. Un compteur simple suit le nombre de requêtes qu'un client a effectuées, et une fois le seuil atteint, les requêtes suivantes reçoivent des réponses 429 Too Many Requests. Cela fonctionne bien pour les APIs REST où chaque requête consomme des ressources à peu près équivalentes.

Les gateways IA et MCP (Model Context Protocol) font face à un défi fondamentalement différent. Considérez ces scénarios :

Scénario 1 : Deux comptages de requêtes identiques, coûts radicalement différents

  • Le Client A envoie 100 requêtes traitant chacune 50 tokens (5 000 tokens au total)
  • Le Client B envoie 100 requêtes traitant chacune 5 000 tokens (500 000 tokens au total)

Avec un rate limiting traditionnel, les deux clients semblent équivalents. Mais le Client B a consommé 100x plus de ressources de calcul, coûté 100x plus en frais d'API LLM, et a probablement dégradé la qualité de service pour les autres utilisateurs.

Scénario 2 : Réponses en streaming Un agent IA initie un seul stream SSE (Server-Sent Events) qui traite 50 000 tokens sur 45 secondes. Le rate limiting traditionnel voit "1 requête" pendant que le gateway gère une génération de tokens soutenue équivalente à des centaines de requêtes normales.

Scénario 3 : Complexité variable des requêtes

  • Invocation d'outil simple : 200 tokens (0,2 secondes)
  • Analyse de document : 8 000 tokens (12 secondes)
  • Conversation multi-tours : 15 000 tokens (22 secondes)

La variance de consommation des ressources dans les charges de travail IA nécessite de repenser le rate limiting depuis ses fondements. Comme discuté dans le Guide MCP Gateway, les gateways doivent équilibrer les capacités des agents avec la capacité backend.

Limites par Token vs par Requête​

Limites par Requête (Traditionnel)​

Le rate limiting par requête compte les appels API discrets indépendamment de leur payload ou des exigences de traitement :

# Approche traditionnelle - compte uniquement les requêtes
rate_limit:
  requests_per_minute: 60
  requests_per_hour: 1000

Avantages :

  • Simple à implémenter et raisonner
  • Rapide (opérations de compteur O(1))
  • Fonctionne bien pour les charges de travail uniformes

Inconvénients :

  • Ignore la consommation réelle des ressources
  • Permet les abus via des requêtes volumineuses
  • Mauvaise équité dans les environnements multi-tenant
  • Pas d'alignement avec la facturation des fournisseurs LLM

Limites par Token (Adapté à l'IA)​

Le rate limiting par token tient compte du travail computationnel réel en suivant les tokens d'entrée et de sortie :

# Approche adaptée à l'IA - suit la consommation de tokens
quota:
  tokens_per_minute: 100000
  tokens_per_day: 5000000
  max_tokens_per_request: 32000
  count_input_tokens: true
  count_output_tokens: true

Avantages :

  • Reflète la vraie consommation des ressources
  • S'aligne avec la facturation des fournisseurs LLM
  • Équitable entre différents types de requêtes
  • Prévient les abus via des requêtes à tokens élevés

Inconvénients :

  • Nécessite une infrastructure de comptage de tokens
  • Légèrement plus de surcharge
  • Peut nécessiter une estimation pour les requêtes en streaming

Approche Hybride (Recommandée)​

Les gateways IA de production devraient implémenter les deux couches :

quota_policy:
  # Protection contre les inondations (grain grossier)
  max_requests_per_second: 10

  # Gestion fine des ressources
  tokens_per_minute: 100000
  tokens_per_hour: 2000000
  tokens_per_day: 10000000

  # Protection des requêtes individuelles
  max_tokens_per_request: 32000
  max_request_duration_seconds: 60

Cela prévient à la fois les inondations de requêtes (protection DDoS) et les abus de tokens (contrôle des coûts).

Stratégies de Rate Limiting​

Fenêtre Fixe​

L'algorithme le plus simple : autoriser N opérations par fenêtre de temps fixe (ex : par minute).

rate_limit:
  algorithm: fixed_window
  window_size: 60s
  max_requests: 1000

Comment ça fonctionne :

  1. La fenêtre démarre à la frontière de la minute (ex : 10:00:00)
  2. Le compteur s'incrémente pour chaque requête
  3. À 10:01:00, le compteur se remet à zéro

Problème de burst :

  • L'utilisateur envoie 1 000 requêtes à 10:00:59
  • L'utilisateur envoie 1 000 requêtes à 10:01:00
  • Résultat : 2 000 requêtes en 2 secondes, malgré la limite "1 000/minute"

Quand l'utiliser : Services internes, APIs non critiques, quotas simples.

Fenêtre Glissante​

Suit les requêtes sur une fenêtre temporelle glissante, évitant le problème de burst.

rate_limit:
  algorithm: sliding_window
  window_size: 60s
  max_requests: 1000

Comment ça fonctionne :

  1. Heure actuelle : 10:00:45
  2. Compter les requêtes de 09:59:45 à 10:00:45
  3. La fenêtre glisse avec chaque nouvelle requête

Implémentation :

  • Log de fenêtre glissante : Stocker le timestamp de chaque requête, compter les requêtes dans la fenêtre (précis mais intensif en mémoire)
  • Compteur de fenêtre glissante : Approximation avec deux fenêtres fixes et interpolation pondérée (efficace mais légèrement imprécis)

Quand l'utiliser : APIs de production, services face aux utilisateurs, allocation équitable des ressources.

Token Bucket​

Un seau contient des tokens ; chaque requête consomme des tokens ; les tokens se rechargent à un rythme constant.

rate_limit:
  algorithm: token_bucket
  bucket_capacity: 1000
  refill_rate: 100  # tokens par seconde
  tokens_per_request: 1  # ou dynamique basé sur le compte réel de tokens

Comment ça fonctionne :

  1. Le seau commence avec 1 000 tokens
  2. Une requête arrive, consomme des tokens (ex : 50 tokens pour un prompt de 50 tokens)
  3. Le seau se recharge à 100 tokens/seconde
  4. Si le seau est vide, la requête est refusée avec 429

Gestion des bursts : Permet des bursts jusqu'à la capacité du seau, puis lisse au rythme de rechargement.

Quand l'utiliser : Charges de travail IA, tailles de requêtes variables, besoin de supporter des bursts occasionnels.

Leaky Bucket​

Les requêtes entrent dans une file d'attente (seau) ; la file est traitée à un rythme fixe (fuite).

rate_limit:
  algorithm: leaky_bucket
  bucket_capacity: 100  # taille max de la file
  leak_rate: 10  # requêtes par seconde

Comment ça fonctionne :

  1. Les requêtes entrantes entrent dans la file
  2. La file traite à 10 requêtes/seconde
  3. Si la file est pleine, les nouvelles requêtes sont rejetées

Caractéristiques :

  • Lisse le trafic vers un débit de sortie constant
  • Pas de bursts autorisés (contrairement au token bucket)
  • Mécanisme naturel de contre-pression

Quand l'utiliser : Protection des services downstream avec des limites de capacité strictes, façonnage du trafic pour les exigences de conformité.

Gestion des Quotas par Tenant​

Dans les gateways IA multi-tenant, l'allocation équitable des ressources est critique. Un seul tenant bruyant peut dégrader le service pour tous les utilisateurs. Le guide multi-tenant Kubernetes couvre l'isolation au niveau infrastructure ; ici nous nous concentrons sur l'application des quotas au niveau application.

Hiérarchie de Quotas​

quotas:
  # Quota par défaut pour tous les tenants
  default:
    tokens_per_minute: 10000
    tokens_per_day: 500000
    max_concurrent_requests: 5

  # Surcharges par tier
  tier_overrides:
    free:
      tokens_per_minute: 5000
      tokens_per_day: 100000
      max_concurrent_requests: 2

    pro:
      tokens_per_minute: 50000
      tokens_per_day: 2000000
      max_concurrent_requests: 20

    enterprise:
      tokens_per_minute: 200000
      tokens_per_day: 10000000
      max_concurrent_requests: 100

  # Surcharges spécifiques au tenant (priorité la plus haute)
  tenant_overrides:
    tenant-acme-corp:
      tokens_per_minute: 500000
      tokens_per_day: 50000000
      max_concurrent_requests: 200

Ordre de résolution : spécifique au tenant → tier → défaut.

Implémenter les Quotas par Tenant​

Quand une requête arrive, le gateway doit :

  1. Identifier le tenant (via clé API, token OAuth ou certificat mTLS)
  2. Résoudre la politique de quota (tenant → tier → défaut)
  3. Vérifier l'utilisation actuelle (requête au compteur distribué)
  4. Autoriser ou refuser (mettre à jour le compteur si autorisé)
  5. Retourner les en-têtes d'utilisation (informer le client du statut du quota)

Exemple d'en-têtes de réponse HTTP :

HTTP/1.1 200 OK
X-RateLimit-Limit: 100000
X-RateLimit-Remaining: 87340
X-RateLimit-Reset: 1614556800
X-Quota-Tokens-Used-Minute: 12660
X-Quota-Tokens-Used-Day: 456000
X-Quota-Tokens-Limit-Day: 2000000

Quand le quota est dépassé :

HTTP/1.1 429 Too Many Requests
Retry-After: 42
X-RateLimit-Limit: 100000
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1614556842
Content-Type: application/json

{
  "error": "quota_exceeded",
  "message": "Daily token quota of 2,000,000 exceeded",
  "retry_after_seconds": 42,
  "quota_reset_at": "2026-02-27T10:15:00Z"
}

Stockage des Quotas​

Le suivi des quotas distribué nécessite un état partagé :

Option 1 : Redis (recommandé pour la plupart des cas)

quota_backend:
  type: redis
  redis_url: redis://redis-cluster:6379
  key_prefix: quota:
  ttl: 86400  # 24 heures pour les quotas journaliers

Utilisez INCR Redis pour les mises à jour atomiques du compteur et EXPIRE pour la réinitialisation automatique des fenêtres.

Option 2 : En mémoire (instance unique seulement)

quota_backend:
  type: memory
  sync_interval: 5s  # pas vraiment distribué

Uniquement pour le développement ou les déploiements mono-réplique.

Option 3 : Base de données (latence élevée, non recommandé) La latence des requêtes rend les bases de données inadaptées pour les chemins critiques de rate limiting.

Implémenter avec STOA​

STOA Platform fournit une gestion de quota intégrée pour les gateways MCP. Voici comment la configurer.

Étape 1 : Définir les Politiques de Quota​

Créez une ressource de politique de quota :

apiVersion: gostoa.dev/v1alpha1
kind: QuotaPolicy
metadata:
  name: default-ai-quota
  namespace: tenant-acme
spec:
  # Limites basées sur les tokens (recommandé pour l'IA)
  tokens:
    perMinute: 100000
    perHour: 2000000
    perDay: 10000000
    maxPerRequest: 32000

  # Limites basées sur les requêtes (protection contre les inondations)
  requests:
    perSecond: 10
    perMinute: 600

  # Limites de concurrence
  maxConcurrentRequests: 20
  maxConcurrentStreams: 5

  # Protection par timeout
  maxRequestDurationSeconds: 120

  # Suivi des coûts (pour refacturation)
  trackCosts: true
  costPerMillionTokens: 15.00

Étape 2 : Appliquer aux Outils​

Référencez la politique de quota dans vos ressources Tool :

apiVersion: gostoa.dev/v1alpha1
kind: Tool
metadata:
  name: document-analyzer
  namespace: tenant-acme
spec:
  displayName: Document Analyzer
  endpoint: https://api.backend.local/analyze
  method: POST
  quotaPolicyRef:
    name: default-ai-quota

Plusieurs outils peuvent partager la même politique de quota pour des limites agrégées.

Étape 3 : Surveiller l'Utilisation​

Interrogez l'API STOA pour l'utilisation actuelle :

curl -H "Authorization: Bearer $TOKEN" \
  https://api.gostoa.dev/v1/quotas/tenant-acme/usage

Réponse :

{
  "tenant_id": "tenant-acme",
  "period": "current",
  "usage": {
    "tokens": {
      "current_minute": 12340,
      "limit_minute": 100000,
      "current_hour": 456000,
      "limit_hour": 2000000,
      "current_day": 3200000,
      "limit_day": 10000000
    },
    "requests": {
      "current_second": 2,
      "limit_second": 10,
      "current_minute": 87,
      "limit_minute": 600
    },
    "concurrent": {
      "active_requests": 4,
      "max_requests": 20,
      "active_streams": 1,
      "max_streams": 5
    }
  },
  "estimated_cost_usd": 48.00
}

Étape 4 : Gérer les Erreurs de Quota​

Les clients MCP devraient gérer gracieusement les réponses 429 :

async function callTool(toolName: string, input: object) {
  const response = await fetch(`https://mcp.gostoa.dev/mcp/tools/${toolName}`, {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${apiKey}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify(input)
  });

  if (response.status === 429) {
    const retryAfter = parseInt(response.headers.get('Retry-After') || '60');
    console.warn(`Quota exceeded, retrying after ${retryAfter}s`);
    await sleep(retryAfter * 1000);
    return callTool(toolName, input);  // Réessayer
  }

  return response.json();
}

Implémentez un backoff exponentiel pour la résilience en production. Consultez la checklist de sécurité API pour des patterns de gestion des erreurs supplémentaires.

Stratégies de Comptage de Tokens​

Un comptage précis des tokens est critique pour une gestion efficace des quotas. Voici les principales approches :

Estimation Avant Requête​

Estimez les tokens avant d'envoyer au backend LLM :

import { encode } from 'gpt-tokenizer';

function estimateTokens(prompt: string, model: string = 'gpt-4'): number {
  const encoded = encode(prompt);
  return encoded.length;
}

const prompt = "Analyze this document...";
const estimatedTokens = estimateTokens(prompt);

if (estimatedTokens > MAX_TOKENS_PER_REQUEST) {
  throw new Error('Request exceeds token limit');
}

Avantages : Rapide, empêche les requêtes hors quota Inconvénients : Approximation seulement (le backend réel peut utiliser un tokenizer différent)

Compte Réel Après Requête​

Extrayez l'utilisation réelle des tokens de la réponse LLM :

{
  "response": "...",
  "usage": {
    "prompt_tokens": 1240,
    "completion_tokens": 856,
    "total_tokens": 2096
  }
}

Mettez à jour les compteurs de quota avec les valeurs réelles :

const actualTokens = responseData.usage.total_tokens;
await updateQuota(tenantId, actualTokens);

Avantages : Précis, s'aligne avec la facturation Inconvénients : Réactif (quota déjà consommé)

Comptage de Tokens en Streaming​

Pour les réponses SSE/streaming, comptez de façon incrémentale :

let tokenCount = 0;

stream.on('data', (chunk) => {
  const chunkTokens = estimateTokens(chunk.content);
  tokenCount += chunkTokens;

  // Vérifier le quota en milieu de stream
  if (tokenCount > remainingQuota) {
    stream.close();
    throw new QuotaExceededError();
  }
});

stream.on('end', () => {
  updateQuota(tenantId, tokenCount);
});

STOA gère automatiquement les comptes de tokens en streaming quand vous activez le suivi de quota.

Surveiller les Patterns d'Utilisation​

Une gestion efficace des quotas nécessite de l'observabilité. Suivez ces métriques :

Métriques par Tenant​

# Métriques Prometheus (exemple)
quota_tokens_used_total{tenant="acme", window="minute"} 12340
quota_tokens_limit{tenant="acme", window="minute"} 100000
quota_requests_rejected_total{tenant="acme", reason="daily_limit"} 7
quota_cost_usd{tenant="acme", window="day"} 48.00

Règles d'Alerte​

# Alerter si le tenant atteint régulièrement ses limites
alert: TenantQuotaPressure
expr: |
  (quota_tokens_used_total / quota_tokens_limit) > 0.9
for: 10m
annotations:
  summary: "Le tenant {{ $labels.tenant }} utilise >90% de son quota"

Suivi des Coûts​

Générez des rapports de refacturation par tenant :

SELECT
  tenant_id,
  SUM(tokens_used) as total_tokens,
  SUM(tokens_used) / 1000000.0 * cost_per_million as estimated_cost_usd
FROM quota_usage
WHERE timestamp >= NOW() - INTERVAL '30 days'
GROUP BY tenant_id
ORDER BY total_tokens DESC;

Pour les tableaux de bord de surveillance en production, consultez la référence de configuration STOA.

Patterns Avancés​

Ajustement Dynamique des Quotas​

Ajustez automatiquement les quotas en fonction des patterns d'utilisation :

quota_policy:
  auto_scale:
    enabled: true
    scale_up_threshold: 0.8  # Augmenter le quota quand 80% est utilisé
    scale_down_threshold: 0.3  # Diminuer quand <30% est utilisé
    min_quota: 50000
    max_quota: 500000
    scale_factor: 1.5

File d'Attente par Priorité​

Toutes les requêtes ne sont pas égales. Assignez des priorités :

quota_policy:
  priority_classes:
    - name: critical
      weight: 1.0  # Toujours traité en premier
      max_queue_time: 5s

    - name: normal
      weight: 0.5
      max_queue_time: 30s

    - name: batch
      weight: 0.1
      max_queue_time: 300s

Quand le quota est dépassé, mettez les requêtes en file par priorité plutôt que de les rejeter immédiatement.

Emprunt de Quota​

Permettez aux tenants de dépasser temporairement leur quota avec remboursement :

quota_policy:
  borrowing:
    enabled: true
    max_borrow_percentage: 20  # Peut utiliser 120% du quota
    payback_period: 3600  # Doit rester sous le quota pendant 1 heure pour effacer la dette

Utile pour gérer les pics inattendus sans pannes brutales.

Pièges Courants​

Piège 1 : Ignorer la Surcharge du Streaming​

Problème : Les requêtes en streaming apparaissent comme "1 requête" mais consomment des ressources pendant des minutes.

Solution : Suivre la durée du stream et le débit de tokens :

quota_policy:
  streaming:
    max_duration_seconds: 120
    tokens_per_second_limit: 500
    count_as_equivalent_requests: 10  # 1 stream = 10 requêtes pour le quota

Piège 2 : Pas de Contre-Pression​

Problème : Accepter toutes les requêtes dans une file conduit à l'épuisement de la mémoire.

Solution : Implémenter des files bornées avec rejet :

quota_policy:
  queue:
    max_size: 100
    overflow_strategy: reject  # ou 'drop_oldest'

Piège 3 : Granularité Insuffisante​

Problème : Les quotas journaliers permettent les abus (consommer tout le quota dans la première heure).

Solution : Implémenter plusieurs fenêtres de temps :

quota_policy:
  tokens_per_minute: 10000   # Lisser les bursts
  tokens_per_hour: 200000    # Prévenir les abus horaires
  tokens_per_day: 2000000    # Budget journalier

Les trois limites doivent être satisfaites.

Piège 4 : Pas de Visibilité des Coûts​

Problème : Les tenants ne savent pas qu'ils approchent des limites jusqu'à ce que les requêtes échouent.

Solution : Notifications proactives :

quota_policy:
  notifications:
    warning_threshold: 0.8  # Avertir à 80%
    webhook_url: https://tenant.local/quota-warning

Piège 5 : Dérive d'Horloge​

Problème : Les systèmes distribués avec des horloges non synchronisées produisent une application incohérente des quotas.

Solution : Utiliser des timestamps UTC et tolérer une petite dérive :

quota_backend:
  clock_skew_tolerance: 5s
  prefer_server_time: true

FAQ​

Comment gérer les quotas pour les tiers gratuits vs payants ?​

Utilisez des politiques de quota par tier avec héritage :

quotas:
  default:
    tokens_per_day: 100000  # Tier gratuit de base

  tier_overrides:
    pro:
      tokens_per_day: 2000000  # Augmentation 20x
      inherits: default

    enterprise:
      tokens_per_day: 50000000  # Augmentation 500x
      inherits: default

Assignez les tenants aux tiers via les métadonnées. Quand un tenant passe à un tier supérieur, son quota augmente automatiquement sans changements de configuration. Pour les détails d'architecture multi-tenant, consultez la documentation des concepts multi-tenant.

Quel est le meilleur algorithme de rate limiting pour les charges de travail IA ?​

Le token bucket est généralement recommandé pour les gateways IA/MCP car :

  1. Gère naturellement les tailles de requêtes variables (petit prompt = peu de tokens, grand prompt = beaucoup de tokens)
  2. Permet des bursts contrôlés (critique pour l'initiation du streaming)
  3. Lisse vers un rythme durable (protège la capacité backend)
  4. S'aligne avec la facturation des fournisseurs LLM (basée sur les tokens)

Utilisez la fenêtre glissante pour les limites strictes de requêtes par seconde (couche de protection DDoS). Combinez les deux :

quota_policy:
  # Protection contre les inondations (fenêtre glissante)
  requests_per_second: 20

  # Gestion des ressources (token bucket)
  algorithm: token_bucket
  token_capacity: 100000
  token_refill_rate: 1000  # par seconde

Pour les implications de performance détaillées, consultez les benchmarks de performance du gateway.

Comment empêcher un tenant de monopoliser les ressources ?​

Implémentez la file équitable et les limites de concurrence :

quota_policy:
  # Limiter les requêtes concurrentes par tenant
  max_concurrent_requests: 10
  max_concurrent_streams: 3

  # Planification équitable quand le quota est dépassé
  scheduling:
    algorithm: weighted_fair_queuing
    tenant_weight: 1.0  # Poids égal pour tous les tenants

  # Timeout strict pour prévenir l'accaparement des ressources
  max_request_duration: 120s

  # Circuit breaker pour les tenants abusifs
  circuit_breaker:
    failure_threshold: 10
    timeout: 300s

Quand le tenant A épuise son quota, ses requêtes sont mises en file. Les requêtes du tenant B continuent à être traitées immédiatement (isolation). Si le tenant A abuse régulièrement des quotas, le circuit breaker le bloque temporairement.

De plus, envisagez la dégradation gracieuse : quand la charge système est élevée, réduisez les quotas proportionnellement pour tous les tenants plutôt que des pannes brutales. Consultez la documentation de référence des quotas pour les options de configuration avancées.

Prochaines Étapes​

Ce guide a couvert les fondamentaux du rate limiting et de la gestion des quotas pour les gateways IA. Points clés :

  1. Les limites par token reflètent mieux la vraie consommation des ressources que les comptages de requêtes
  2. L'approche hybride (limites requêtes + tokens) fournit à la fois une protection contre les inondations et une allocation équitable des ressources
  3. Les quotas par tenant avec tiers permettent des architectures multi-tenant flexibles
  4. La surveillance et les alertes préviennent l'épuisement surprenant des quotas

Pour continuer à apprendre :

Prêt à implémenter des quotas de gateway IA de niveau production ? Essayez STOA Platform avec un rate limiting par token intégré et une gestion des quotas multi-tenant.