Come creare un broker di limiti di velocità neutrale rispetto al fornitore per API LLM multimodello

Quando più team condividono più fornitori LLM, la limitazione della tariffa smette di essere un dettaglio dell'integrazione del fornitore. Diventa un problema di capacità condivisa. Un fornitore può limitare le richieste e i token di input, un altro può separare i token di input e di output e un terzo può applicare quote a livello di progetto o in una finestra di spesa continua. Un ciclo di tentativi all'interno di ogni SDK non può coordinare tali vincoli tra tenant, applicazioni, chiavi partner e route del modello.

La soluzione pratica è un broker di limiti di tasso centrale al gateway. Il broker stima la domanda, riserva la capacità prima della spedizione, mette in coda o rifiuta il lavoro in base alla politica e riconcilia la prenotazione con l'utilizzo effettivo dopo il completamento. Le risposte del fornitore poi perfezionano la visione del broker sulla capacità disponibile invece di innescare tempeste di tentativi indipendenti.

Questa architettura è utile per qualsiasi LLM aziendale API che necessita di un throughput prevedibile tra team interni, applicazioni di produzione, agenti di automazione o partner esterni.

Perché i limiti tariffari del fornitore non possono essere ridotti alle richieste al minuto

Fatto: le quote dei fornitori utilizzano dimensioni e ambiti diversi. Le dimensioni comuni includono richieste al minuto, token di input al minuto, token di output al minuto, token totali, richieste al giorno, concorrenza, finestre di spesa e limiti di accelerazione o velocità di rampa. Lo stesso fornitore può esporre limiti diversi per un'organizzazione, un progetto, un'area di lavoro, un modello o API prodotto.

Ad esempio, la documentazione del fornitore descrive combinazioni come:

• Limiti di richieste e token con capacità rimanente e informazioni di reimpostazione nelle intestazioni di risposta.
• Limiti separati per token di input e token di output per le API dei messaggi.
• Quote a livello di progetto anziché quote collegate a singole API chiavi.
• Limiti di richiesta giornalieri che si reimpostano in un momento definito dal provider.
• Finestre continue basate sulla spesa che possono rifiutare il traffico anche quando le tariffe delle richieste e dei token sembrano accettabili.
• Limiti di accelerazione che reagiscono a un forte aumento del traffico, anche quando l'utilizzo stazionario è inferiore alla quota pubblicata.

Un gateway che memorizza un solo numero chiamato RPM del provider finirà per ammettere un traffico eccessivo in una dimensione o sottoutilizzare la capacità in un'altra. Inoltre, non può spiegare se un rifiuto provenga da una policy del tenant, da una quota di progetto del provider, da un limite giornaliero o da una risposta di sovraccarico.

Architettura di riferimento per un broker di limiti di tasso

Inserisci il broker nel percorso della richiesta prima dell'adattatore del provider. Ogni richiesta deve passare attraverso lo stesso flusso di prenotazione, indipendentemente dal fatto che sia arrivata tramite una chiave SDK, un servizio interno, un agente di automazione o una chiave API del partner.

1. Normalizza l'identità. Risolvi l'organizzazione, il tenant, il team, l'applicazione, l'ambiente, il partner, la chiave API, il percorso del modello e la classe del carico di lavoro.
2. Stima della domanda. Calcola i token di input previsti, i token di output massimi, la spesa stimata e gli eventuali costi simultanei.
3. Valuta la policy. Controlla i budget dei tenant, le scadenze delle code, l'idoneità del percorso, la priorità e le regole di fallback.
4. Riserva capacità. Prenota atomicamente capacità nei relativi bucket interni e rivolti al fornitore.
5. Dispatch. Invia la richiesta solo dopo che la prenotazione è andata a buon fine.
6. Riconcilia. Sostituisci le stime con l'utilizzo effettivo, rilascia le prenotazioni non utilizzate, le intestazioni del fornitore di record e la classificazione delle risposte.
7. Decidi l'azione successiva. Restituisci il risultato, metti in coda il lavoro, riprova centralmente, fallback o rifiutalo in base al contratto del carico di lavoro.

Il servizio di prenotazione dovrebbe essere scalabile orizzontalmente, ma la sua decisione deve essere atomica per ogni richiesta. Un contatore distribuito che consente a due lavoratori di osservare la stessa capacità rimanente può ricreare il problema 429 del provider all'interno del gateway.

Utilizza un modello di quote canonico senza nascondere le differenze tra i provider

Definisci un modello canonico in grado di rappresentare i vincoli specifici del fornitore invece di forzare ogni fornitore in un'astrazione.

Rappresenta ciascun limite come un bucket con ambito, capacità, regola di riempimento o reimpostazione, unità e origine. Un bucket di progetto del provider potrebbe contenere richieste e token di input. Un bucket dell'area di lavoro potrebbe contenere token di output. Una policy dei partner interni potrebbe aggiungere concorrenza e limiti di spesa. La decisione di ammissione ha esito positivo solo se tutte le prenotazioni richieste hanno esito positivo.

Non considerare le intestazioni dei provider come una completa fonte di verità. Usali per correggere le stime del broker, ma mantieni un modello configurato per i limiti che non sono esposti su ogni risposta. I nomi delle intestazioni, la disponibilità e la semantica di reimpostazione variano in base al provider e al percorso.

Prenota i token prima dell'invio, quindi riconciliali

La prenotazione dei token è la differenza più importante tra un broker e un wrapper di tentativi. Il broker necessita di una stima della domanda prima di inviare la richiesta.

Per i token di input, stima dai messaggi serializzati, dalle definizioni degli strumenti, dallo schema di output strutturato e da qualsiasi contesto recuperato. Per i token di output, utilizzare il numero massimo di richieste quando disponibile o una stima specifica del modello e del carico di lavoro quando il cliente non ne fornisce una. Mantieni la stima allegata alla prenotazione in modo che possa essere confrontata con l'utilizzo effettivo in un secondo momento.

Un semplice record di prenotazione può contenere:

• Una richiesta e un ID prenotazione univoci.
• Tenant, applicazione, chiave API, percorso e classe di carico di lavoro.
• Token di input stimati, token di output, token totali e spesa.
• Ogni bucket addebitato dalla prenotazione.
• Ora di creazione, ora di scadenza, scadenza della coda e chiave di idempotenza.
• Utilizzo effettivo finale e importo rilasciato o addebitato durante la riconciliazione.

Le stime prudenti riducono le risposte del provider 429 ma possono compromettere la capacità. Misura l'errore di stima in base al modello, al percorso, alla famiglia di prompt, alla lunghezza del contesto e alla modalità di output strutturato. Quindi modifica le stime utilizzando correzioni limitate anziché consentire a una singola richiesta insolita di distorcere l'intero modello.

Lo streaming richiede norme specifiche. È possibile riservare la capacità di output massima e rilasciare la parte inutilizzata al termine del flusso oppure riservare la capacità di output in incrementi più piccoli man mano che arrivano i token. Il primo approccio è più facile da ragionare; il secondo può migliorare l'utilizzo ma richiede una gestione affidabile di annullamento, timeout e disconnessione.

Applica le quote in modo gerarchico

La capacità deve essere controllata dalla policy più ristretta alla risorsa condivisa più ampia. Una tipica gerarchia è:

1. API chiave o identità del servizio.
2. Applicazione e ambiente.
3. Team o tenant del cliente.
4. Account partner o rivenditore.
5. Area di lavoro o account secondario del fornitore.
6. Progetto o organizzazione del fornitore.
7. Modello e percorso.

Una richiesta proveniente da un'applicazione partner potrebbe quindi richiedere quattro prenotazioni riuscite: la policy di concorrenza del partner, il budget del token del tenant del cliente, l'allocazione del percorso del gateway e la quota disponibile del progetto del provider. Se una prenotazione fallisce, rilascia quelle già acquisite e applica la decisione del bucket fallito.

Per correttezza, utilizza code eque ponderate o round robin in deficit anziché consentire al lavoratore che arriva per primo di consumare il pool condiviso. Assegna pesi più elevati al traffico di produzione e pesi inferiori ai lavori in background, preservando i crediti burst per ciascun tenant. Il partizionamento rigido è più semplice da spiegare, ma può lasciare la capacità inattiva quando un tenant non è attivo. La condivisione ponderata generalmente utilizza la capacità in modo più efficiente, a condizione che i tenant rumorosi abbiano limiti di burst limitati.

Code di progettazione relative ai contratti dei carichi di lavoro

Una coda non è automaticamente una caratteristica di affidabilità. Può trasformare un 429 visibile in un ritardo invisibile di dieci minuti. Ogni classe della coda necessita di una scadenza, un comportamento di annullamento, una profondità massima e un'azione di sovraccarico.

• Interattivo: scadenza breve, coda ridotta, rifiuto prevedibile o degrado del modello quando la capacità non è disponibile.
• Contesto di produzione: Scadenza più lunga, coda durevole, chiave di idempotenza e budget per tentativi controllato.
• Partner: Quote specifiche del tenant, metadati di risposta pubblicati e nessun accesso allo stato della coda di un altro tenant.
• Batchable: Esecuzione ritardata, coda più grande e instradamento opzionale a un batch del provider API quando il carico di lavoro lo consente.

L'ammissione in coda dovrebbe restituire una decisione chiara. A seconda del contratto API, esponi una risposta di sovraccarico 429 o specifica del gateway con un valore retry-after, un identificatore di coda e un codice motivo. Non promettere un tempo di completamento a meno che il sistema non possa far rispettare tale promessa.

L'elaborazione batch può rimuovere il lavoro non interattivo dalla capacità sincrona, ma modifica la tempistica dei risultati, il comportamento dei nuovi tentativi, l'annullamento e la riconciliazione. Trattalo come un percorso di esecuzione separato anziché semplicemente inserire richieste sincrone in una coda molto lunga. Per i carichi di lavoro in background, confronta i compromessi operativi con i criteri di controllo dei costi dell'AI API e le operazioni batch esistenti.

Centralizza la gestione dei tentativi e dell'overload

Fatto: Le risposte temporanee al limite di velocità utilizzano comunemente HTTP 429, mentre le condizioni di sovraccarico del provider possono utilizzare 503 o un codice di errore specifico del provider. Alcuni provider restituiscono un'intestazione Retry-After e la documentazione del provider consiglia di rispettarla quando presente. Una rampa di traffico rapida può anche produrre un comportamento di accelerazione o rallentamento senza il normale esaurimento del secchio.

Raccomandazione: considera Retry-After come un limite inferiore, non come un suggerimento facoltativo. Metti in pausa l'ambito del provider interessato fino a quel momento, aggiungi un jitter limitato per impedire riattivazioni sincronizzate e lascia che sia il broker a decidere quali richieste in coda possono utilizzare la capacità recuperata.

Quando Retry-After è assente o non valido, utilizza il backoff esponenziale limitato con jitter. Mantieni il budget per i nuovi tentativi nel broker, non separatamente in ogni SDK e adattatore del provider. Altrimenti, una richiesta logica può produrre un nuovo tentativo del gateway, un SDK nuovo tentativo, un HTTP nuovo tentativo del client e una riproduzione lato provider.

Classifica gli errori prima di riprovare:

• Capacità riprovabile: Risposta temporanea 429 o quota transitoria documentata.
• Sovraccarico riprovabile: Segnale di sovraccarico temporaneo del provider 503 o equivalente.
• Errore irreversibile del criterio: Quota giornaliera, limite di spesa, progetto disattivato o limite tenant.
• Richiesta irreversibile non riuscita: Schema non valido, parametro non supportato, errore di autenticazione o input non valido.
• Scadenza fallita: una richiesta la cui scadenza per l'utente o il flusso di lavoro rimanente è più breve del successivo tentativo sicuro.

Il fallback è una decisione separata. Un fornitore diverso può avere comportamenti di output, prezzi, latenza, residenza o limiti di contesto diversi. Utilizza il fallback solo quando la policy di route conferma che il contratto del carico di lavoro può tollerare tali differenze.

Esporre le decisioni e misurare la saturazione

I team non possono risolvere i problemi di limitazione se il gateway restituisce solo un generico 429. Restituisce metadati sicuri come il limite applicabile, la capacità rimanente, il tempo di reimpostazione, la decisione sulla coda, la classe del carico di lavoro e il motivo del rifiuto. Evita di esporre l'utilizzo di un altro tenant o le credenziali non elaborate del fornitore.

Come minimo, monitora:

• Tasso di prenotazione riuscita e rifiuto per tenant, percorso e bucket.
• Profondità della coda, tempo di attesa della coda, scadenze delle scadenze e annullamenti.
• Tariffe provider 429 e 503, frequenza Retry-After e tassi di rifiuto graduali.
• Utilizzo stimato del token rispetto a quello effettivo e capacità sprecata a causa di una prenotazione eccessiva.
• Saturazione della concorrenza e quota di capacità consumata da ciascun tenant.
• Tentativi per richiesta logica e frequenza di fallback.
• Quota giornaliera e margine di spesa nel periodo di spesa.

I test di carico dovrebbero includere traffico burst, richieste di contesto lungo, richieste di output massimo, disconnessioni di streaming, esaurimento della quota giornaliera, risposte 429 e 503 del provider e un tenant rumoroso in competizione con il traffico di produzione. Verifica non solo se le richieste vengono infine completate, ma anche se le scadenze della coda, l'equità e i budget per i nuovi tentativi rimangono intatti.

Elenco di controllo per l'implementazione

• Definisci le dimensioni canoniche senza ignorare i limiti specifici del provider.
• Assegna a ogni richiesta un tenant, un percorso, una classe di carico di lavoro e una chiave di idempotenza normalizzati.
• Stima e prenota input, output, token totali, spesa, richieste e concorrenza prima dell'invio.
• Rendi atomiche le prenotazioni multi-bucket e fai scadere le prenotazioni abbandonate in modo sicuro.
• Riconcilia l'utilizzo effettivo del provider e le intestazioni di risposta dopo ogni tentativo.
• Utilizza equità ponderata, burst credit e classi di priorità esplicite.
• Assegna a ogni coda una scadenza, una profondità massima e un'azione di sovraccarico.
• Centralizza i nuovi tentativi e rispetta i valori Retry-After del provider.
• Separare gli errori di capacità temporanei dai criteri permanenti e dagli errori di richiesta.
• Pubblica metadati di limitazione e monitora la saturazione per tenant e percorso.
• Testare l'esaurimento della quota del fornitore, i limiti di rampa, lo streaming, il fallback e il comportamento dei vicini rumorosi.

Conclusione

Un gateway multimodello dovrebbe gestire la quota del provider come capacità dell'infrastruttura condivisa, non come una raccolta di impostazioni SDK indipendenti. Un broker di limiti tariffari neutrale rispetto al fornitore offre ai team della piattaforma un percorso di ammissione, una politica di equità, un budget per i nuovi tentativi e un luogo in cui riconciliare le stime con la realtà.

La progettazione richiede più di un bucket di token generico. Deve rappresentare richieste, token di input e output, quote giornaliere, finestre di spesa, concorrenza, ambito del provider e velocità di rampa. Una volta che queste dimensioni sono esplicite, il gateway può fare scelte prevedibili: inviare adesso, fare la coda con una scadenza, eliminare il lavoro, riprovare centralmente o utilizzare un fallback sicuro per il contratto. È così che il controllo del throughput diventa una capacità operativa anziché una fonte ricorrente di incidenti di produzione 429 e 503.

Leggi correlati

• elaborazione batch per carichi di lavoro LLM non interattivi