Pourquoi ne pas vous fier uniquement aux plafonds de dépenses des fournisseurs ?

Les plafonds de dépenses des fournisseurs sont des filets de sécurité utiles, mais ils fonctionnent généralement au niveau des limites de l'organisation, du projet, de l'espace de travail, du compte de facturation, du service cloud, de l'abonnement, de la région, du modèle ou du déploiement. L'application de la passerelle peut cartographier les limites des dimensions de propriété internes telles que l'équipe, l'application, l'environnement, le client, le partenaire ou le flux de travail.

Les estimations de contrôle en amont doivent-elles utiliser des jetons de sortie maximale ou des jetons de sortie attendus ?

Pour une application stricte du budget, utilisez des jetons de sortie maximale ou une autre limite supérieure conservatrice. Le résultat attendu est meilleur pour les prévisions, mais il peut sous-réserver le budget lorsqu'une demande génère une réponse plus longue que d'habitude.

Que doit-il se passer lorsqu’un budget atteint une limite souple ?

Les limites souples doivent généralement avertir, informer les propriétaires, rétrograder les modèles, réduire la longueur de sortie maximale ou désactiver un comportement facultatif coûteux. Elles ne doivent pas se comporter de la même manière que des limites strictes, à moins que la charge de travail ne soit soumise à des contrôles de dépenses explicitement stricts.

Comment les réponses en continu doivent-elles être contrôlées ?

Réservez le budget avant le début du flux, suivez les jetons générés lorsque cela est possible, arrêtez la génération lorsque le budget réservé est épuisé et renvoyez une raison de fin claire telle que budget_exhausted afin que les clients puissent gérer la réponse partielle.

À quelle fréquence les dépenses liées à la passerelle doivent-elles être rapprochées des données de facturation du fournisseur ?

La réconciliation quotidienne est une méthode pratique par défaut. Les estimations du temps de requête peuvent différer du coût déclaré par le fournisseur en raison des différences entre les tokenizer, la mise en cache, les tentatives, les remises par lots, les arrondis, les exportations retardées et les dimensions de facturation spécifiques au fournisseur.

Comment appliquer les limites de dépenses LLM sur API Gateway

Les plafonds de dépenses des fournisseurs sont des mesures de sécurité utiles, mais ils correspondent rarement à la manière dont une entreprise gère réellement ses dépenses LLM. La finance veut des limites par équipe, application, environnement, client, partenaire ou flux de travail. Les équipes de plate-forme doivent appliquer ces limites avant qu'une requête ne soit transmise à OpenAI, Anthropic, Gemini, Azure OpenAI ou à un autre fournisseur de modèles. Le bon point de contrôle est généralement la API passerelle, où chaque demande peut être attribuée, estimée, admise, déclassée, bloquée et rapprochée.

Ce guide décrit une implémentation de couche passerelle pour IA APIcontrôle des coûts. Il se concentre sur l'application du budget en temps réel, et non sur les rapports de rétrofacturation rétrospectifs ou sur de vastes programmes d'optimisation des coûts.

Ce que les contrôles des dépenses des fournisseurs peuvent et ne peuvent pas faire

Fait : Les principaux fournisseurs proposent des contrôles utiles, mais ils fonctionnent dans les limites définies par le fournisseur. OpenAI documente les limites de dépenses mensuelles API au niveau de l'organisation et du projet, ainsi que des erreurs distinctes pour les limites de l'organisation, les limites du projet, les limites d'utilisation attribuées et les crédits prépayés épuisés. Anthropic documente les limites de dépenses et de tarifs de l'espace de travail, et fournit également des API pour récupérer les limites configurées de l'organisation et de l'espace de travail pour les alertes internes. Google Les alertes budgétaires cloud à elles seules ne plafonnent pas automatiquement les dépenses, tandis que Google documente également les budgets plafonnés pour les services éligibles tels que Gemini API et Agent Platform. Le quota Azure OpenAI est attribué par abonnement, région, modèle et type de déploiement en unités de jetons par minute, et les calculs de limite de débit peuvent inclure une estimation rapide et un nombre maximal de jetons, et pas seulement les jetons facturés finaux.

Recommandation : Maintenez les plafonds de dépenses natifs du fournisseur activés en tant que garde-fou de dernier recours. Ne les considérez pas comme le principal mécanisme de mise en œuvre des budgets internes. Ils sont trop grossiers pour la plupart des modèles de propriété et se déclenchent généralement une fois que le chemin de la requête a déjà quitté votre contrôle.

Prédiction : Les contrôles des fournisseurs continueront de s'améliorer, mais les entreprises auront toujours besoin d'une politique au niveau de la passerelle, car la propriété des coûts internes change plus rapidement que les structures de comptes des fournisseurs.

Définir d'abord le modèle de politique budgétaire

Commencez par la politique, pas par le code. Une passerelle ne peut pas faire respecter un budget qui n'a pas été décrit avec précision.

Un dossier de politique pratique doit inclure :

Propriétaire du budget : propriétaire d'une équipe, d'un service, d'un client, d'un partenaire, d'une application ou d'un workflow.
Portée : les dimensions qui correspondent aux requêtes, telles que team_id, app_id, environment, customer_id et workflow_id.
Intervalle de réinitialisation : quotidien, hebdomadaire, mensuel, période de contrat ou fenêtre personnalisée.
Seuil souple : le point où la passerelle avertit, rétrograde, réduit la longueur de sortie ou oriente vers des modèles moins chers.
Seuil strict : le point où le trafic non critique est bloqué.
Modèles autorisés : les modèles que cette étendue peut utiliser.
Modèles de secours : modèles moins chers ou de capacité inférieure autorisés après un seuil souple.
Criticité : si la charge de travail est critique pour la production, destinée aux utilisateurs, interne, par lots ou expérimentale.
Dérogation d'urgence : qui peut prolonger la limite, pour combien de temps et avec quelle piste d'audit.
Cibles de notification : canal Slack, groupe de messagerie, service d'incident, webhook ou file d'attente financière.

Exemple de stratégie :

{
  "budget_id": "budget_support_prod_monthly",
  "owner_type": "team",
  "owner_id": "customer_support",
  "scope": {
    "team_id": "customer_support",
    "app_id": "support_assistant",
    "environment": "production"
  },
  "currency": "USD",
  "limit": 5000.00,
  "reset_interval": "monthly",
  "soft_threshold_percent": 80,
  "hard_threshold_percent": 100,
  "allowed_models": ["premium-chat", "standard-chat", "economy-chat"],
  "fallback_models": ["standard-chat", "economy-chat"],
  "criticality": "user_facing_production",
  "on_soft_limit": ["notify", "downgrade_model", "reduce_max_output_tokens"],
  "on_hard_limit": ["block_noncritical", "allow_emergency_override"],
  "notification_targets": ["slack:#support-platform", "email:[email protected]"]
}

Exiger des métadonnées de propriété pour chaque demande

L'application du budget dépend de l'attribution. Si une demande ne peut pas être mappée à un périmètre budgétaire, la passerelle ne peut pas prendre une décision d'admission fiable.

Exiger que les clients internes envoient des métadonnées de propriété stables :

{
  "model": "premium-chat",
  "messages": [...],
  "max_tokens": 1200,
  "metadata": {
    "team_id": "customer_support",
    "app_id": "support_assistant",
    "environment": "production",
    "customer_id": "cust_48291",
    "workflow_id": "ticket_reply_draft"
  }
}

Recommandation : Déployez cela par étapes. Enregistrez d’abord le trafic non attribué. Alors prévenez-le. Rejetez ensuite le trafic de production non attribué une fois que les propriétaires ont eu le temps de mettre à jour les clients. Pour le trafic de développement, mettez-le en quarantaine dans un budget par défaut avec un faible plafond plutôt que de le mélanger avec les dépenses de production.

Validez également les métadonnées par rapport à votre système d'identité. Un client ne devrait pas pouvoir réclamer le budget d’une autre équipe en modifiant team_id. Associez API clés, comptes de service ou identifiants de partenaire aux étendues budgétaires autorisées.

Estimation du coût avant expédition

L'estimation en amont est au cœur de l'application en temps réel. La passerelle estime le coût maximum probable avant d'envoyer la demande à un fournisseur.

L'estimateur a besoin :

Modèles de tableaux de prix pour les entrées, les sorties, les entrées mises en cache, les lots, l'utilisation d'outils, les images, les intégrations ou d'autres dimensions facturables.
Logique d'estimation de jeton ou de jeton par famille de modèles.
Inviter le nombre ou l'estimation des jetons.
Demandé max_tokens ou longueur de sortie maximale.
Hypothèses de mise en cache, si la mise en cache des invites affecte la facturation.
Règles de facturation spécifiques au fournisseur pour les tentatives, les appels d'outils, les jetons de raisonnement, la génération d'images ou les entrées multimodales.

Exemple de résultat de l'estimateur :

{
  "request_id": "req_7f1b",
  "budget_scope": "team:customer_support/app:support_assistant/env:production",
  "model": "premium-chat",
  "input_tokens_estimated": 1850,
  "max_output_tokens": 1200,
  "estimated_cost": 0.0845,
  "estimate_basis": "prompt_tokens_plus_max_output_tokens",
  "confidence": "conservative"
}

Recommandation : Considérez le coût du contrôle en amont comme une estimation d'admission prudente, et non comme une vérité comptable. Si l'utilisateur demande max_tokens: 4000, réservez cette limite supérieure même si la réponse s'arrête généralement à 700 jetons. Cela réduit le risque de dépenses excessives, mais peut rejeter des demandes qui auraient été réalisées en dessous du budget. Ce compromis est préférable pour des contrôles financiers stricts et moins attrayant pour les outils internes exploratoires.

Réserver le budget avant d'envoyer la demande

Un mode d'échec courant consiste à vérifier le budget, à trouver le solde disponible, puis à laisser passer de nombreuses demandes simultanées avant que les dépenses ne soient enregistrées. Le correctif est la réservation.

La séquence d'admission doit être :

Authentifier l'appelant.
Valider les métadonnées de propriété.
Résolvez la politique budgétaire applicable.
Estimer le coût de la demande.
Réservez atomiquement ce coût estimé dans le magasin budgétaire.
Envoyez la demande au fournisseur uniquement si la réservation réussit.
Libérez la réservation inutilisée une fois terminée.
Enregistrer l'utilisation finale estimée ou déclarée par le fournisseur.

Le magasin de réservation doit prendre en charge les mises à jour atomiques. Redis avec des scripts Lua, des transactions PostgreSQL ou un service de grand livre dédié peuvent fonctionner. La propriété importante est que deux requêtes ne peuvent pas dépenser le même budget restant.

Exemple d'enregistrement de réservation :

{
  "reservation_id": "res_9d42",
  "request_id": "req_7f1b",
  "budget_id": "budget_support_prod_monthly",
  "estimated_cost": 0.0845,
  "state": "reserved",
  "expires_at": "2026-09-28T12:45:00Z"
}

Utilisez des expirations de réservation courtes afin que les demandes abandonnées ne bloquent pas le budget pour toujours. Un nettoyeur d'arrière-plan doit libérer les réservations expirées qui n'ont jamais atteint un état terminal.

Séparez les limites souples des limites strictes

Les limites souples et strictes doivent se comporter différemment. Une limite souple est un signal politique. Une limite stricte est une décision d'admission.

Comportement de limite logicielle

Lorsqu'un champ d'application dépasse son seuil souple, la passerelle peut toujours desservir le trafic tout en réduisant la pression sur les dépenses. Les réponses utiles incluent :

Envoyer des alertes au responsable du budget et au canal financier ou de plateforme.
Ajoutez des en-têtes de réponse indiquant l'état limite et le budget restant.
Acheminez les requêtes non critiques vers des modèles moins chers.
Réduire max_tokens pour les workflows verbeux.
Désactivez les fonctionnalités facultatives coûteuses telles que la génération de plusieurs échantillons.
Exiger l'approbation pour les nouvelles expériences dans le cadre de ce budget.

Exemple de métadonnées de réponse à limite souple :

{
  "budget_scope": "team:customer_support/app:support_assistant/env:production",
  "limit_state": "soft_limit_exceeded",
  "estimated_cost": 0.0310,
  "remaining_budget": 912.44,
  "applied_policy": ["downgrade_model", "reduce_max_output_tokens"],
  "selected_model": "standard-chat"
}

Comportement de limite stricte

Au seuil strict, la passerelle doit bloquer le trafic non critique avec un contrat d'erreur prévisible.

{
  "error": {
    "type": "budget_limit_exceeded",
    "code": "llm_budget_hard_limit",
    "message": "The budget for this scope has been exhausted.",
    "budget_scope": "team:customer_support/app:support_assistant/env:production",
    "retry_after": "2026-10-01T00:00:00Z",
    "override_required": true
  }
}

Ne renvoie pas d'erreurs en forme de fournisseur en cas d'échec du budget de la passerelle. Les clients internes doivent faire la distinction entre les limites tarifaires des fournisseurs, les plafonds de dépenses des fournisseurs, les limites de dépenses de la passerelle, les échecs d'authentification et les refus de politique.

Gérer explicitement les requêtes de streaming

Le streaming crée un problème d'application différent. La demande est admise avant que la passerelle ne connaisse les jetons de sortie finaux, et les jetons générés peuvent continuer à accumuler des coûts pendant que le flux est ouvert.

Un modèle réalisable est :

Réservez un montant prudent en fonction des jetons d'invite et des jetons de sortie maximum.
Suivez les jetons générés pendant le flux lorsque cela est possible.
Arrêtez la génération si le montant réservé est épuisé.
Renvoyer une raison de fin que le client peut gérer.
Réconcilier l'utilisation réelle une fois que le fournisseur a envoyé les métadonnées d'utilisation finale ou une fois l'estimation de la passerelle terminée.

Exemple d'événement de fin de flux :

{
  "type": "response.completed",
  "finish_reason": "budget_exhausted",
  "budget_scope": "customer:cust_48291/workflow:ticket_reply_draft",
  "estimated_cost": 0.0845,
  "remaining_budget": 0.00
}

Compromis : Couper un flux protège le budget, mais cela peut produire un résultat incomplet. Pour les flux de travail qui nécessitent des réponses structurées complètes, préférez le blocage en amont ou la rétrogradation du modèle avant le début de la diffusion. Pour les expériences de type chat, une raison de fin tenant compte du budget peut être acceptable si le client peut demander à l'utilisateur de réessayer plus tard ou de continuer avec un modèle moins cher.

Exposer l'état du budget aux clients

L'application du budget est plus facile à adopter lorsque les appelants peuvent voir ce qui s'est passé. Ajoutez des en-têtes de réponse ou des métadonnées pour les clients internes et les API partenaires.

Les champs utiles incluent :

budget_scope
limit_state : normal, soft_limit_near, soft_limit_exceeded, hard_limit_exceeded
estimated_cost
reserved_cost
final_cost_when_available
remaining_budget
applied_policy
selected_model

Pour les API de partenaires publics, évitez de divulguer les noms des équipes internes ou la base de coûts si cela est commercialement sensible. Exposez plutôt l'état du quota sécurisé par les locataires, tel que remaining_quota, limit_state et retry_after.

Rapprocher les estimations avec l'utilisation du fournisseur

L'application des délais de requête et le reporting des coûts de niveau comptable sont liés, mais ce ne sont pas la même chose. L'estimation de la passerelle prend une décision d'admission dans un contexte d'incertitude. Les exportations de facturation des fournisseurs, les API d'utilisation et les factures fournissent les enregistrements dont le service financier se souciera.

Recommandation : Rapprochez les dépenses estimées de la passerelle avec l'utilisation déclarée par le fournisseur au moins quotidiennement. Les différences peuvent provenir d'une inadéquation du tokenizer, de la mise en cache des invites, de remises par lots, de tentatives, d'appels échoués, d'arrondis spécifiques au fournisseur, de facturation de l'utilisation d'images ou d'outils et d'exportations de facturation retardées.

Une tâche de rapprochement devrait :

Importer les données d'utilisation et de coût du fournisseur.
Normalisez-le dans le schéma d'utilisation de la passerelle.
Faire correspondre les enregistrements du fournisseur aux ID de demande de passerelle, le cas échéant.
Allouez les dépenses inégalées des fournisseurs à la portée connue la plus spécifique.
Ajustez les grands livres budgétaires en cas de surréservation ou de sous-réservation.
Émettez des rapports sur les écarts par fournisseur, modèle, équipe, application et environnement.

Utilisez des champs de télémétrie normalisés pour les jetons d'entrée, les jetons de sortie, le modèle, le fournisseur, l'ID de demande et l'état. Les conventions sémantiques OpenTelemetry GenAI définissent les attributs d'utilisation des jetons qui peuvent aider à standardiser la télémétrie d'utilisation entre les fournisseurs.

Choisissez délibérément le comportement d'ouverture en cas d'échec ou de fermeture en cas d'échec

Le magasin de budget devient une partie du chemin de la requête. Il s'agit du principal coût architectural de l'application en temps réel.

Si le magasin budgétaire n'est pas disponible, la passerelle a besoin d'un comportement défini :

Échec de l'ouverture : autorise les requêtes et les marque pour un rapprochement ultérieur. Cela protège la disponibilité mais peut entraîner des dépenses excessives.
Échec fermé : bloque les requêtes jusqu'à ce que l'état du budget soit disponible. Cela protège les dépenses mais peut interrompre les flux de production.
Échec limité : autorisez uniquement le trafic de production critique, utilisez des modèles moins chers, appliquez de faibles plafonds par requête et bloquez les expériences ou les charges de travail par lots.

Recommandation : Utilisez la contrainte d'échec pour la plupart des systèmes d'entreprise. Les flux de production critiques se poursuivent avec une exposition aux coûts réduite, tandis que les charges de travail discrétionnaires sont suspendues jusqu'à ce que le plan de contrôle récupère.

Liste de contrôle de mise en œuvre

Définissez les étendues du budget et les métadonnées de propriété.
Lier API clés ou comptes de service aux étendues autorisées.
Créez des enregistrements de stratégie avec des limites souples, des limites strictes, des modèles autorisés, des solutions de secours, des remplacements et des cibles de notification.
Créez un estimateur de coûts adapté aux fournisseurs.
Utilisez les réservations de budget atomique avant l'envoi du fournisseur.
Libérez les réservations inutilisées une fois terminées.
Mettez en œuvre des erreurs strictes avec un contrat stable.
Ajoutez le suivi des jetons de streaming et les raisons de finition tenant compte du budget.
Exposer l'état du budget via des en-têtes internes ou des métadonnées de réponse.
Gardez les plafonds de dépenses des fournisseurs activés comme mesures de sécurité.
Réconcilier quotidiennement les estimations de la passerelle avec les rapports d'utilisation et de coûts du fournisseur.
Alerte en cas d'écart, de trafic non attribué, de budgets épuisés et d'utilisation de remplacement.

Conclusion exploitable

Pour appliquer de manière fiable les limites de dépenses LLM, prenez la décision là où les demandes entrent dans votre système. Les plafonds des fournisseurs peuvent arrêter les dommages au niveau du compte, mais la politique de passerelle peut imposer les limites commerciales réellement demandées par les dirigeants : budgets d'équipe, d'application, d'environnement, de client, de partenaire et de flux de travail.

La conception minimale viable est simple : exiger des métadonnées de propriété, estimer le coût avant l'expédition, réserver le budget de manière atomique, appliquer des seuils souples et stricts, gérer le streaming séparément et réconcilier avec les données d'utilisation du fournisseur. Le plus difficile n’est pas la première décision de blocage. Le plus difficile est de rendre le système suffisamment prévisible pour que le service financier lui fasse confiance et que les équipes de production puissent continuer à fonctionner même si le budget est sous pression.

Lecture connexe

grand livre des coûts LLM par équipe