Plafonds et coûts : le moteur hold-and-settle

Des plafonds qui s'appliquent avant que la dépense arrive

Les plafonds d'usage d'une installation AI multi-utilisateurs vivent d'habitude dans un tableau de bord - un rapport que vous lisez après que la facture existe. Le quota engine de Simmetric Chat les place plus tôt : dans le chemin de la requête, avant le premier appel LLM. Le moteur couvre trois genres de plafonds - tokens, stockage et coût (une comptabilité à argent réel, en cents) - et le fait avec la même forme partout : un ledger comme vérité de la consommation, des soldes dérivés, des barrières pré-turn, et un échec toujours explicite.

Cet article parcourt le design : l'invariant « aucun second compteur » adossé au ledger, la chaîne de résolution qui décide du plafond de chaque utilisateur, le fonctionnement de la fenêtre mobile du reset (l'historique n'est jamais effacé), et la réservation hold-and-settle en deux phases qui fait d'un plafond de coût une vraie porte plutôt qu'une alarme renvoyée.

Un outil d'opérateur (la classe de fonction Community). Faits : FACT-CENSUS.md F-QUOTA-1.

Aucun second compteur

L'invariant non négociable : la vérité de la consommation reste dans le ledger de token-usage EXISTANT de la plateforme. Soldes, holds et ancres de reset sont un état dérivé - jamais une seconde table de compteurs qui pourrait dériver de la réalité. Les corollaires :

• Un reset est une ancre du ledger, un effacement. Un reset écrit une ligne-ancre qui borne la fenêtre mobile ; l'historique d'usage/de coûts n'est jamais supprimé ni remis à zéro. L'opérateur peut auditer en arrière à tout moment.
• Les barrières sont au niveau service et pré-turn - elles tournent où vivent les données du domaine (avant le premier appel LLM dans l'orchestrateur, avant l'ingest dans les chemins de téléversement). Il n'y a pas de middleware à contourner : le contrôle est dans le chemin du service lui-même.
• La math des sous est décimal-vers-cents. Chaque calcul de coût passe par la couche décimale et atterrit en cents ENTIERS - jamais en virgule flottante, jamais en dérive d'arrondi.

La chaîne de résolution

Le plafond d'un utilisateur se résout par une chaîne à trois niveaux, dans l'ordre :

1. La surcharge par utilisateur - l'admin fixe directement les plafonds token/stockage/coût d'un utilisateur nommé.
2. Le preset d'installation - les clés de défaut au niveau de l'installation dans la configuration système (plafond token, stockage Go, plafond de coût en EUR).
3. Illimité - le sentinel "0"/vide = NON configuré, et le moteur échoue ouvert : aucun changement de comportement pour les installations qui ne touchent jamais aux quotas.

Le fail-open est une fonction avec une forme explicite : le quota engine est l'outil opt-in de l'opérateur, et « non configuré » ne doit jamais devenir « bloqué » en silence.

Les trois genres

Les quotas token croulent sur une somme d'usage fenêtrée depuis le ledger, bornée par l'ancre de reset la plus récente. La résolution renvoie une limite et son palier source - l'interface de l'opérateur peut dire quelle ligne a tranché, par utilisateur. Le dépassement = une erreur de quota nommée dont le payload est la clé que la frontend, le widget et les gestionnaires de connecteurs partagent.

Les quotas stockage s'appliquent dans les chemins de téléversement avant l'envoi au collector : la surcharge par utilisateur, le défaut d'installation, ou l'illimité.

Les quotas de coût - le volet à argent réel - sont le design hold-and-settle, ci-dessous.

Hold-and-settle

Une dépense en token arrive quand les tokens arrivent ; une dépense en euro arrive pendant que le flux tourne. La barrière de coût réserve donc AVANT l'appel LLM et s'acquitte à la couture de l'usage :

1. Reserve (avant l'appel) - une mise à jour conditionnelle dont le prédicat est évalua row-locké par la base (dépensé + estimé ≤ plafond) : N requêtes concurrentes se SÉRIALISENT au lieu de toutes passer une vérification périmée, plus la ligne de hold dans la même transaction (la réservation est atomique avec le contrôle).
2. Settle (à la couture) - le hold se finalise et rembourse estimé moins réel. La fenêtre acceptée est le dépassement en vol (réel > estimé) - aucun kill en mi-flux pour un motif de coût ; l'invariant au repos est exact : dépense réglée + holds ouverts ≤ plafond.

Cette paire donne au plafond de coût la propriété qu'un rapport ne peut jamais avoir : le plafond s'applique avant que la dépense s'engage vers le modèle, par une réservation row-lockée honnête sous concurrence.

Le pricing : par modèle, gelé par snapshot, jamais gratuit en silence

La source de pricing par ligne : un snapshot figé des coûts modèles là où il existe (une rettouche de tarif ne réécrit jamais l'historique), sinon des tarifs de repli de l'installation (la doctrine SC-4 : un modèle sans prix ne contourne jamais le plafond de coût - un plancher non-nul s'applique avec un log warn-once, si bien que rien ne peut apparaître gratuit par omission). Les devises : le ledger suit des totaux par devise (USD, EUR, GBP, JPY, CNY, INR en v1 - aucune conversion) ; le coût atterrit à l'événement done du flux.

La configuration vit dans le chemin des opérateurs : Settings → Providers → l'action pricing du modèle (les tarifs entrée/sortie par 1M tokens + la devise), ou du pricing par utilisateur pour les clés own-provider. N/A signifie « configurez un tarif » ; $0.00 signifie explicitement gratuit (les modèles locaux retournés à 0).

Le principal du widget

Les visiteurs anonymes du widget ne sont pas des utilisateurs : la consommation du widget se lie au principal de l'organisation du widget - le trafic widget puise dans la chaîne de quota de cette organisation au lieu d'inventer des identités par visiteur. Le trafic des connecteurs et les chats internes partagent le même unique orchestrateur, si bien que les barrières pré-turn couvrent uniformément les trois classes de surface de chat.

Pour continuer

Le guide porte la référence d'opérateur complète - les clés, les endpoints, le comportement du reset, le détail du pricing - sur /fr/docs/quotas-and-costs :

• Quotas and costs - le guide
• Faits de ce billet : ligne FACT-CENSUS.md F-QUOTA-1 (les trois genres, le ledger sans second compteur, le moteur hold-and-settle)

Provenance : Simmetric Chat docs/QUOTAS.md (v0.28.1, Phases 207/216) + docs/MODEL_COSTS.md (Phases 203/209/216), quotaService.ts/costQuotaService.ts - à l'état documentaire épinglé par le census (SHA aca5b8ff).