Guide de mise en œuvre des budgets de tokens

Les budgets de tokens sont la couche opérationnelle du contrôle des coûts des LLM. L'attribution vous indique où va l'argent ; les budgets empêchent qu'il aille où vous ne le souhaitez pas. Sans budgets, une boucle d'agent mal configurée ou un pic du trafic utilisateur peut consommer une allocation mensuelle en quelques heures. Ce guide couvre la mise en œuvre de quatre types de budgets de tokens en production, avec du pseudocode pour chaque modèle.

Types de budgets

Type de budgetGranularitéApplicationCas d'usage
Par requêteUn seul appel APILimite rigide via le paramètre max_tokensPrévenir les complétions incontrôlables, limiter la latence
Quota par équipeÉquipe ou projet sur une périodeLimite souple avec alertes, limite rigide au seuilAllocation des coûts par département, empêcher une équipe de consommer le budget partagé
Par période de tempsQuotidien, hebdomadaire ou mensuelLimite rigide avec période de grâcePlafonds de budget mensuel, dépenses au niveau du sprint
Par flux de travailUn seul pipeline ou exécution d'agentLimite rigide par étape et totaleAgents multi-étapes, pipelines RAG, exécutions d'évaluation

Limites par requête

Le budget le plus simple : limiter chaque requête avec max_tokens. C'est obligatoire - chaque requête de production devrait avoir une limite explicite de tokens de sortie. Sans elle, une réponse verbale du modèle peut consommer des tokens inattendus et augmenter la latence.

// Application du budget par requête
function appellerLLM(prompt, config):
    reponse = fournisseur.completer(
        prompt: prompt,
        modele: config.modele,
        max_tokens: config.max_tokens_sortie,    // limite rigide
        temperature: config.temperature
    )
    if reponse.usage.tokens_totaux > config.seuil_alerte:
        log.avertir("La requête a dépassé la limite souple",
            tokens: reponse.usage.tokens_totaux,
            seuil: config.seuil_alerte
        )
    return reponse

Quotas par équipe

Les quotas par équipe nécessitent un compteur partagé qui persiste entre les requêtes. Le modèle : vérifier le budget restant avant chaque appel, refuser ou rétrograder si le budget est épuisé.

// Quota d'équipe avec compteur sauvegardé dans Redis
function verifierBudgetEquipe(equipoId, tokensEstimes):
    cle = "budget:" + equipoId + ":" + periodeActuelle()
    restant = redis.obtenir(cle) or obtenirQuotaEquipe(equipoId)

    if restant < tokensEstimes:
        if restant < tokensEstimes * 0.1:
            return REFUSER    // limite rigide : rejeter la requête
        else:
            return RETROGRADER   // limite souple : utiliser un modèle moins coûteux

    return PERMETTRE

function enregistrerUtilisation(equipoId, tokensReels):
    cle = "budget:" + equipoId + ":" + periodeActuelle()
    redis.decrementer(cle, tokensReels)
    restant = redis.obtenir(cle)
    if restant < obtenirQuotaEquipe(equipoId) * 0.2:
        alerte.quotaBasse(equipoId, restant)

Budgets par période de temps

Les budgets par période de temps associent les quotas d'équipe avec une fenêtre temporelle. La différence clé : vous avez besoin d'un mécanisme de période de grâce. Quand une équipe atteint 80% de son budget mensuel, envoyer une alerte. À 100%, permettre une période de grâce configurable (par exemple, 24 heures) avant que l'application rigide n'entre en vigueur. Cela empêche une équipe d'être bloquée au milieu d'une tâche le dernier jour du mois.

// Budget par période avec période de grâce
function appliquerBudget(equipoId):
    utilisation = obtenirUtilisationPeriode(equipoId, moisActuel())
    limite = obtenirLimiteMensuelleEquipe(equipoId)

    if utilisation < limite * 0.8:
        return PERMETTRE

    if utilisation < limite * 1.0:
        alerte.avisiBudget(equipoId, utilisation, limite)
        return PERMETTRE   // zone d'avertissement souple

    if utilisation < limite * 1.1 and dansLaperiodeGrace(equipoId):
        alerte.budgetDepasse(equipoId, utilisation, limite)
        return PERMETTRE   // période de grâce : permettre le dépassement

    return REFUSER  // arrêt rigide

Budgets par flux de travail

Les agents et pipelines multi-étapes nécessitent des budgets à deux niveaux : par étape (empêcher une seule étape de consommer trop) et par exécution (empêcher tout le pipeline de dépasser son allocation). Tracer les deux dans le contexte du flux de travail.

// Suivi du budget du flux de travail
class BudgetFlux:
    constructeur(maxParEtape, maxTotal):
        this.maxParEtape = maxParEtape
        this.maxTotal = maxTotal
        this.depense = 0

    function executerEtape(fnEtape, prompt):
        if this.depense >= this.maxTotal:
            return reponseSecours("Budget dépassé")

        reponse = appellerLLM(prompt, {
            max_tokens: min(this.maxParEtape,
                           this.maxTotal - this.depense)
        })

        this.depense += reponse.usage.tokens_totaux
        return reponse

Dégradation gracieuse quand le budget est dépassé

Ne pas simplement retourner une erreur quand un budget est atteint. Rétrograder avec grâce. Passer à un modèle moins coûteux (GPT-4o-mini au lieu de GPT-4o), réduire la taille de la fenêtre de contexte, sauter les étapes de traitement optionnelles ou retourner un résultat partiel avec une note indiquant que le traitement complet nécessite une approbation budgétaire. L'expérience utilisateur devrait se dégrader, pas se casser.

// Chaîne de dégradation
function appellerAvecDegradation(prompt, config):
    if verifierBudget(config.equipoId, MODELE_COMPLET):
        return appellerLLM(prompt, { modele: config.modelePrimaire })

    if verifierBudget(config.equipoId, MODELE_ECONOMIQUE):
        log.info("Rétrogradation du modèle pour budget")
        return appellerLLM(prompt, { modele: config.modeleSecours })

    if verifierBudget(config.equipoId, TOKENS_MINIMES):
        tronque = tronquerContexte(prompt, 50%)
        return appellerLLM(tronque, {
            modele: config.modeleSecours,
            max_tokens: 256
        })

    return cacheeOuSecours(prompt)

Surveillance de la santé du budget

Tracer trois métriques : taux de consommation (tokens consommés par heure par rapport au budget), prévision (au rythme actuel, quand le budget sera-t-il épuisé) et nombre de dérogations (combien de fois la période de grâce a-t-elle été utilisée). Si l'utilisation de la période de grâce dépasse 10% des requêtes totales, le budget est défini trop bas pour la charge de travail.

Associé


Voulez-vous appliquer cela à vos propres dépenses en LLM ? FinOps LLM effectue un audit gratuit de vos coûts d'IA et montre où se trouvent les économies. Réserver un audit gratuit →

Retour à la recherche