Scopra quanto costa davvero ogni modello dietro il suo gateway Requesty

Colleghi la sua organizzazione Requesty a Cloud Intelligence™ e visualizzi la spesa LLM per modello, hosting provider, chiave API e policy di routing, calcolata al prezzo effettivamente pagato per i crediti, accanto al resto della spesa cloud

Un gateway LLM è utile proprio perché nasconde dei dettagli alla sua applicazione: quale provider ha servito la richiesta, in quale regione, quale fallback è scattato quando il provider primario ha raggiunto un rate limit. È esattamente ciò che si desidera nel percorso della richiesta, ma non ciò che si vuole in fattura. Requesty addebita ogni richiesta su un saldo crediti prepagato al prezzo di listino del provider e applica il suo 5% al momento della ricarica: le cifre per richiesta nella sua dashboard risultano quindi inferiori del 5% rispetto a quanto il reparto finance ha effettivamente pagato. L'utilizzo è indicizzato per nome del modello, per cui gpt-6-astra servito da OpenAI e gpt-6-astra servito da Azure finiscono sotto la stessa etichetta, a meno di suddividere anche per provider. Capire quanto un team ha speso il mese scorso su Claude via Bedrock rispetto a Vertex richiede un export, un foglio di calcolo e un estratto conto della carta di credito.

Cloud Intelligence™ ora legge l'utilizzo direttamente dalla sua organizzazione Requesty e valorizza ogni riga esattamente come fa la sua fattura. Il report che mostra quanto è costato ieri il suo cluster EKS può mostrare quanto ha speso in token tramite Requesty, fino alla chiave API e alla policy di routing che ha scelto il modello.

Cosa ottiene

Spesa giornaliera e utilizzo di token per ogni modello utilizzato dalla sua organizzazione Requesty, importati in Cloud Analytics come provider a tutti gli effetti. Lo SKU è composto da hosting provider più modello, quindi openai/gpt-6-astra e azure/gpt-6-astra restano separati e bedrock/claude-haiku-4-5@us-east-1 è una riga a sé. Le etichette indicano l'hosting provider, la chiave API, l'organizzazione Requesty e la policy di routing quando è stata una policy di fallback, load balancing o latenza a scegliere il modello al posto del suo codice. Token di input, token di output e numero di richieste vengono importati come metriche.

I numeri significano ciò che il reparto finance pensa che significhino. Il costo corrisponde ai crediti consumati più il margine del 5% di Requesty, quindi coincide con i crediti acquistati. Il costo di listino è il prezzo di listino del provider, quindi coincide con la dashboard di analytics di Requesty. Su un'organizzazione di test abbiamo riconciliato entrambi al centesimo rispetto all'addebito sul saldo. Le richieste bring-your-own-key vengono fatturate direttamente dal provider a monte, quindi qui hanno costo zero per evitare doppi conteggi con il suo feed OpenAI o AWS; la loro spesa stimata presso il provider viene conservata come metrica separata, genai.cost.byok_external.

Poiché Requesty entra come una normale origine di costi e utilizzo, tutto ciò che sta a valle funziona da subito: report, budget, rilevamento delle anomalie, previsioni e la dashboard GenAI Intelligence, dove Requesty compare accanto a OpenRouter, Anthropic, OpenAI, Fireworks AI e al resto della sua spesa di inferenza.

La configurazione è volutamente banale. Basta creare una chiave API nella Requesty Console con il permesso Manage impostato su Read e Completions su None, scegliere un nome per la connessione, e il gioco è fatto. Consigliamo anche di impostare un piccolo limite di spesa mensile su quella chiave; Cloud Intelligence™ si limita a leggere l'utilizzo e non invia mai richieste di inferenza. Alla prima connessione recuperiamo fino a 12 mesi di storico, poi aggiorniamo i dati ogni 6 ore man mano che Requesty chiude ogni giornata UTC.

Come iniziare

1. Crei una chiave API di gestione nella Requesty Console con Manage: Read, Completions: None e un limite di spesa mensile.
2. Colleghi la sua organizzazione Requesty in Cloud Intelligence™, in Data ingestion and integrations > Integrations, ed esegua Test connection.
3. Crei un report raggruppato per SKU, oppure per le etichette Provider, API key e Routing policy, una volta ricevuta l'email di avvenuta importazione. Le dimensioni di reporting di Requesty elencano tutte le corrispondenze.
4. Apra la dashboard GenAI Intelligence per vedere Requesty accanto agli altri suoi provider GenAI.

Il connettore Requesty è [CONFIRM: disponibile da subito per tutti i clienti Cloud Intelligence™] ed è il quarto gateway LLM che supportiamo, dopo OpenRouter, LiteLLM e Bifrost. Se utilizza Requesty in produzione, lo colleghi e ci segnali dove i numeri non coincidono con la sua fattura. Il traffico bring-your-own-key, in particolare, finora è passato solo dalla nostra organizzazione di test, e ciò che ci serve adesso è volume reale da un'organizzazione reale. Il suo account manager o una richiesta a un esperto sono la via più rapida.