Come applicare i limiti di spesa LLM nel gateway API

I limiti di spesa del fornitore sono utili misure di protezione, ma raramente corrispondono al modo in cui un'azienda gestisce effettivamente la spesa LLM. Il reparto finanziario vuole limiti in base al team, all'applicazione, all'ambiente, al cliente, al partner o al flusso di lavoro. I team della piattaforma devono applicare tali limiti prima che una richiesta venga inviata a OpenAI, Anthropic, Gemini, Azure OpenAI o a un altro provider di modelli. Il punto di controllo corretto è solitamente il gateway API, dove ogni richiesta può essere attribuita, stimata, ammessa, declassata, bloccata e riconciliata.

Questa guida descrive un'implementazione a livello gateway per AI API controllo dei costi. Si concentra sull'applicazione del budget in tempo reale, non su resoconti retrospettivi di riaddebito o ampi programmi di ottimizzazione dei costi.

Cosa possono e non possono fare i controlli della spesa del fornitore

Fatto: I principali fornitori espongono controlli utili, ma operano entro limiti definiti dal fornitore. OpenAI documenta mensilmente API i limiti di spesa a livello di organizzazione e di progetto, insieme a errori distinti per limiti di organizzazione, limiti di progetto, limiti di utilizzo assegnati e crediti prepagati esauriti. Anthropic documenta la spesa per l'area di lavoro e i limiti di tariffa e fornisce inoltre API per recuperare i limiti dell'organizzazione e dell'area di lavoro configurati per gli avvisi interni. Google Gli avvisi sul budget cloud da soli non fissano automaticamente un limite di spesa, mentre Google documentano anche i budget con limite di spesa per servizi idonei come Gemini API e Agent Platform. La quota OpenAI di Azure viene assegnata per sottoscrizione, regione, modello e tipo di distribuzione in unità di token al minuto e i calcoli del limite di velocità possono includere una stima tempestiva e i token massimi, non solo i token fatturati finali.

Raccomandazione: mantieni abilitati i limiti di spesa nativi del fornitore come misura di ultima istanza. Non trattateli come il meccanismo principale per far rispettare i bilanci interni. Sono troppo grossolani per la maggior parte dei modelli di proprietà e di solito si attivano dopo che il percorso della richiesta ha già lasciato il tuo controllo.

Previsione: I controlli dei fornitori continueranno a migliorare, ma le aziende avranno ancora bisogno di policy a livello di gateway perché la proprietà dei costi interni cambia più velocemente delle strutture degli account dei fornitori.

Definisci innanzitutto il modello della politica di budget

Inizia dalle norme, non dal codice. Un gateway non può applicare un budget che non sia stato descritto con precisione.

Un documento pratico sulle politiche dovrebbe includere:

• Proprietario del budget: proprietario di team, dipartimento, cliente, partner, applicazione o flusso di lavoro.
• Ambito: le dimensioni che corrispondono alle richieste, come team_id, app_id, environment, customer_id e workflow_id.
• Intervallo di reimpostazione: giornaliero, settimanale, mensile, periodo contrattuale o finestra personalizzata.
• Soglia flessibile: il punto in cui il gateway avvisa, esegue il downgrade, riduce la lunghezza dell'output o indirizza a modelli più economici.
• Soglia definitiva: il punto in cui il traffico non critico viene bloccato.
• Modelli consentiti: i modelli che questo ambito può utilizzare.
• Modelli di riserva: modelli più economici o con capacità inferiore consentiti dopo una soglia flessibile.
• Criticità: se il carico di lavoro è critico per la produzione, rivolto all'utente, interno, batch o sperimentale.
• Ignoranza di emergenza: chi può estendere il limite, per quanto tempo e con quale traccia di controllo.
• Obiettivi di notifica: Canale Slack, gruppo email, servizio incidenti, webhook o coda finanziaria.

Esempio di policy:

{
  "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]"]
}

Richiedi metadati di proprietà su ogni richiesta

L'applicazione del budget dipende dall'attribuzione. Se una richiesta non può essere associata a un ambito di budget, il gateway non può prendere una decisione di ammissione affidabile.

Richiedi ai client interni di inviare metadati di proprietà stabili:

{
  "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"
  }
}

Consiglio: implementalo in più fasi. Innanzitutto registra il traffico non attribuito. Allora avvisalo. Quindi rifiutare il traffico di produzione non attribuito dopo che i proprietari hanno avuto il tempo di aggiornare i client. Per il traffico di sviluppo, mettilo in quarantena in un budget predefinito con un limite basso anziché mescolarlo con la spesa di produzione.

Convalida anche i metadati rispetto al tuo sistema di identità. Un cliente non dovrebbe essere in grado di richiedere il budget di un altro team modificando team_id. Associa API chiavi, account di servizio o credenziali del partner agli ambiti di budget consentiti.

Stima del costo prima della spedizione

La stima preliminare è il fulcro dell'applicazione in tempo reale. Il gateway stima il costo massimo probabile prima di inviare la richiesta a un provider.

Lo stimatore necessita di:

• Tabelle dei prezzi modello per input, output, input memorizzato nella cache, batch, utilizzo di strumenti, immagini, incorporamenti o altre dimensioni fatturabili.
• Tokenizer o logica di stima dei token per famiglia di modelli.
• Richiedi conteggio o stima dei token.
• Richiesto max_tokens o lunghezza massima dell'output.
• Presupposti della memorizzazione nella cache, se la memorizzazione nella cache dei prompt influisce sulla fatturazione.
• Regole di fatturazione specifiche del provider per tentativi, chiamate a strumenti, token di ragionamento, generazione di immagini o input multimodale.

Esempio di output dello stimatore:

{
  "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"
}

Raccomandazione: considera il costo del preflight come una stima conservativa dell'ammissione, non come una verità contabile. Se l'utente chiede max_tokens: 4000, prenota rispetto a quel limite superiore anche se la risposta di solito si ferma a 700 token. Ciò riduce il rischio di spesa eccessiva, ma può rifiutare le richieste che sarebbero state completate entro il budget. Questo compromesso è preferibile per controlli finanziari rigorosi e meno attraente per strumenti interni esplorativi.

Prenota budget prima di inviare la richiesta

Una modalità di errore comune è controllare il budget, trovare il saldo disponibile e quindi consentire il passaggio di molte richieste simultanee prima che la spesa venga registrata. La soluzione è la prenotazione.

La sequenza di ammissione dovrebbe essere:

1. Autentica il chiamante.
2. Convalida i metadati della proprietà.
3. Risolvi la politica di budget applicabile.
4. Stima del costo della richiesta.
5. Prenota atomicamente il costo stimato dal budget store.
6. Invia la richiesta al fornitore solo se la prenotazione ha esito positivo.
7. Rilascia la prenotazione non utilizzata al termine.
8. Registra l'utilizzo finale stimato o segnalato dal fornitore.

L'archivio prenotazioni deve supportare gli aggiornamenti atomici. Redis con script Lua, transazioni PostgreSQL o un servizio di contabilità dedicato possono funzionare. La proprietà importante è che due richieste non possono spendere lo stesso budget rimanente.

Esempio di record di prenotazione:

{
  "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"
}

Utilizza scadenze brevi per le prenotazioni in modo che le richieste abbandonate non blocchino il budget per sempre. Uno strumento di pulizia in background dovrebbe rilasciare le prenotazioni scadute che non hanno mai raggiunto uno stato terminale.

Separare i limiti morbidi da quelli rigidi

I limiti flessibili e rigidi dovrebbero comportarsi diversamente. Un limite morbido è un segnale politico. Un limite rigido è una decisione di ammissione.

Comportamento con limiti flessibili

Quando un ambito supera la soglia flessibile, il gateway può comunque servire il traffico riducendo la pressione sulla spesa. Le risposte utili includono:

• Invia avvisi al proprietario del budget e al canale finanziario o della piattaforma.
• Aggiungi intestazioni di risposta che mostrano lo stato limite e il budget rimanente.
• Indirizza le richieste non critiche ai modelli più economici.
• Riduci max_tokens per flussi di lavoro dettagliati.
• Disabilita funzionalità opzionali costose come la generazione di campioni multipli.
• Richiedi l'approvazione per nuovi esperimenti nell'ambito di tale budget.

Esempio di metadati di risposta con limite flessibile:

{
  "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"
}

Comportamento limite rigido

Alla soglia rigida, il gateway dovrebbe bloccare il traffico non critico con un contratto di errore prevedibile.

{
  "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
  }
}

Non restituire errori relativi al provider per errori di budget del gateway. I clienti interni devono distinguere i limiti tariffari del fornitore, i limiti di spesa del fornitore, i limiti di spesa del gateway, gli errori di autenticazione e i rifiuti delle norme.

Gestisci le richieste di streaming in modo esplicito

Lo streaming crea un diverso problema di applicazione delle norme. La richiesta viene ammessa prima che il gateway conosca i token di output finali e i token generati possono continuare ad accumulare costi mentre il flusso è aperto.

Uno schema realizzabile è:

1. Prenota un importo conservativo in base ai token di richiesta e ai token di output massimi.
2. Se possibile, monitora i token generati durante lo streaming.
3. Interrompi la generazione se l'importo prenotato è esaurito.
4. Restituisce un motivo di fine che il client può gestire.
5. Riconcilia l'utilizzo effettivo dopo che il provider ha inviato i metadati di utilizzo finali o dopo il completamento della stima del gateway.

Esempio di evento di terminazione del flusso:

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

Compromesso: L'interruzione di uno streaming protegge il budget, ma potrebbe produrre un output incompleto. Per i flussi di lavoro che richiedono risposte strutturate complete, preferisci il blocco preliminare o il downgrade del modello prima dell'inizio dello streaming. Per le esperienze in stile chat, un motivo di conclusione attento al budget può essere accettabile se il cliente può chiedere all'utente di riprovare più tardi o continuare con un modello più economico.

Esponi lo stato del budget ai clienti

L'applicazione del budget è più semplice da adottare quando i chiamanti possono vedere cosa è successo. Aggiungi intestazioni o metadati di risposta per client interni e API partner.

I campi utili includono:

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

Per le API dei partner pubblici, evita di divulgare i nomi dei team interni o la base dei costi se ciò è commercialmente sensibile. Esporre invece lo stato della quota tenant-safe, ad esempio remaining_quota, limit_state e retry_after.

Riconcilia le stime con l'utilizzo del fornitore

L'applicazione al momento della richiesta e la rendicontazione dei costi di livello contabile sono correlati, ma non sono la stessa cosa. La stima del gateway prende una decisione di ammissione in condizioni di incertezza. Le esportazioni della fatturazione del fornitore, le API di utilizzo e le fatture forniscono il record di cui si occuperà il reparto finanziario.

Raccomandazione: riconcilia la spesa stimata dal gateway con l'utilizzo segnalato dal fornitore almeno ogni giorno. Le differenze possono derivare da mancata corrispondenza del tokenizzatore, memorizzazione nella cache delle richieste, sconti batch, nuovi tentativi, chiamate non riuscite, arrotondamenti specifici del provider, fatturazione per l'utilizzo di immagini o strumenti ed esportazioni ritardate della fatturazione.

Un processo di riconciliazione dovrebbe:

1. Importa dati sull'utilizzo e sui costi del fornitore.
2. Normalizzalo nello schema di utilizzo del gateway.
3. Abbina i record del fornitore agli ID di richiesta del gateway, ove disponibile.
4. Assegna la spesa del fornitore senza corrispondenza all'ambito noto più specifico.
5. Rettifica i registri del budget in caso di prenotazione eccessiva o insufficiente.
6. Genera report sulla varianza per fornitore, modello, team, applicazione e ambiente.

Utilizza campi di telemetria normalizzati per token di input, token di output, modello, provider, ID richiesta e stato. Le convenzioni semantiche di OpenTelemetry GenAI definiscono gli attributi di utilizzo dei token che possono aiutare a standardizzare la telemetria di utilizzo tra i provider.

Scegli deliberatamente il comportamento di Fail-Open o Fail-Closed

L'archivio budget diventa parte del percorso della richiesta. Questo è il costo architettonico principale dell'applicazione in tempo reale.

Se il budget store non è disponibile, il gateway necessita di un comportamento definito:

• Fail open: consente le richieste e le contrassegna per la riconciliazione successiva. Ciò protegge la disponibilità ma può spendere troppo.
• Chiusura non riuscita: blocca le richieste finché lo stato del budget non è disponibile. Ciò protegge la spesa ma può interrompere i flussi di lavoro di produzione.
• Limitazione degli errori: consenti solo il traffico di produzione critico, utilizza modelli più economici, applica limiti bassi per richiesta e blocca esperimenti o carichi di lavoro batch.

Raccomandazione: utilizza il limite di errore per la maggior parte dei sistemi aziendali. I flussi di lavoro di produzione critici continuano con un'esposizione dei costi ridotta, mentre i carichi di lavoro discrezionali vengono sospesi fino al ripristino del piano di controllo.

Elenco di controllo per l'implementazione

• Definisci gli ambiti del budget e i metadati della proprietà.
• Associa API chiavi o account di servizio agli ambiti consentiti.
• Crea record di criteri con limiti flessibili, limiti rigidi, modelli consentiti, fallback, sostituzioni e obiettivi di notifica.
• Crea uno stimatore dei costi basato sul fornitore.
• Utilizza prenotazioni con budget atomico prima dell'invio del fornitore.
• Rilascia le prenotazioni non utilizzate dopo il completamento.
• Implementa errori con limiti rigidi con un contratto stabile.
• Aggiungi il monitoraggio dei token di streaming e ragioni per la finitura in base al budget.
• Esponi lo stato del budget tramite intestazioni interne o metadati di risposta.
• Mantieni abilitati i limiti di spesa del fornitore come backstop.
• Riconcilia quotidianamente le stime del gateway con l'utilizzo del provider e i report sui costi.
• Avviso su varianza, traffico non attribuito, budget esauriti e utilizzo di override.

Conclusione attuabile

Per applicare i limiti di spesa LLM in modo affidabile, prendi la decisione dove le richieste entrano nel tuo sistema. I limiti dei fornitori possono arrestare i danni a livello di account, ma le policy del gateway possono applicare i limiti aziendali effettivamente richiesti dai leader: budget per team, app, ambiente, cliente, partner e flusso di lavoro.

La progettazione minima praticabile è semplice: richiedere metadati di proprietà, stimare i costi prima dell'invio, riservare il budget in modo atomico, applicare soglie flessibili e rigide, gestire lo streaming separatamente ed effettuare la riconciliazione con i dati di utilizzo del fornitore. La parte difficile non è la decisione del primo blocco. La parte difficile è rendere il sistema sufficientemente prevedibile in modo che il reparto finanziario abbia fiducia in esso e i team di produzione possano continuare a operare anche quando il budget è sotto pressione.

Leggi correlati

• registro dei costi LLM per team