Spiegazione di token e richieste

Una richiesta e un token non sono la stessa cosa

UN Richiesta API è una chiamata all'endpoint. Gettoni sono le unità di testo all'interno di quella chiamata. Una richiesta può contenere una manciata di token o centinaia di migliaia. I fornitori LLM fatturano in base a token; molte altre API (pagamenti, mappe, SMS) fatturano per richiesta o per azione. Mescolare i due è l’errore di budget più comune.

Dove si applica ciascun modello

Come stimare prima di costruire

Per una funzionalità LLM, stima: token per chiamata × chiamate per utente × utenti. Una risposta in chat potrebbe essere di ~500 input + ~300 token di output; moltiplicalo per le conversazioni mensili per ottenere il volume del token, quindi valutalo. Questo è molto più accurato che indovinare "per richiesta", perché il conteggio dei token per richiesta varia notevolmente. Mantieni input e output separati fino in fondo: i fornitori li valutano in modo diverso, spesso 3-5 volte di più, quindi una stima mista di "token medio" può essere errata di un ampio margine.

La stessa ripartizione si ripresenta nei limiti di velocità

La maggior parte dei provider LLM limita l'utilizzo Entrambi assi contemporaneamente: un tetto di richieste al minuto (RPM) e un tetto di token al minuto (TPM). Quale premi per primo dipende interamente dal numero di token trasportati dalla tua chiamata media: il numero esatto di cui tratta questa pagina.

• Chiamate brevi, alta frequenza (ad esempio un classificatore che si attiva ad ogni pressione di un tasto) tendono a colpire il giri al minuto cap first: ogni chiamata costa poco in termini di token, ma ce ne sono molti.
• Chiamate lunghe, frequenza più bassa (ad esempio un endpoint di riepilogo del documento con un contesto token da 20k) tendono a raggiungere il TPM prima il limite: una manciata di chiamate può già saturare il budget del token.

Sapere quale limite raggiungerai cambia la soluzione: un carico di lavoro legato a RPM ne trae vantaggio dosaggio diverse piccole chiamate in un'unica richiesta più grande (meno richieste, stessi token totali), mentre un carico di lavoro associato a TPM ne trae vantaggio rifilatura contesto o lunghezza dell'output anziché ridurre la frequenza delle chiamate. Vedere Spiegazione dei limiti di velocità API per i livelli RPM/TPM concreti per fornitore.

Esempio realizzato: dimensionamento di una funzionalità di chatbot

Supponiamo che tu stia pianificando un chatbot di supporto per 5.000 utenti attivi mensili, ciascuna media 2 sessioni/mese Di 3 giri al pezzo. Ogni turno porta all'incirca 900 gettoni di input (prompt di sistema + cronologia recente delle conversazioni + messaggio dell'utente) e 250 gettoni di uscita.

• Gettoni per turno: 900 + 250 = 1,150
• Turni per utente/mese: 3 × 2 = 6
• Token per utente/mese: 1.150 × 6 = 6,900 (≈4.900 ingressi / 1.500 uscite)
• Token mensili totali: 6.900 × 5.000 = 34,5 milioni (≈24,5 milioni di ingresso / ~10 milioni di uscita)

Esegui i totali di input e output tramite un calcolatore del costo dei token separatamente per il modello scelto: poiché l'output ha un prezzo più alto, i token di output da 10 milioni possono costare tanto quanto i token di input da 24,5 milioni, anche se si tratta di un terzo del volume.

Errori comuni che fanno saltare una stima

• Unire input e output in un unico prezzo. I token di output sono solitamente 3-5 volte il tasso di input: stimare entrambi al prezzo di input sottostima il conto.
• Dimenticare la storia risentita. La chat a più turni che invia nuovamente i messaggi precedenti a ogni chiamata significa che il numero di token per turno aumenta durante una sessione, non solo per messaggio.
• Stima in base ai personaggi, non ai token. Il conteggio dei token per carattere varia in base alla lingua e al contenuto: codice, JSON e testo non inglese in genere utilizzano più token per carattere rispetto al semplice inglese.
• Ignorando i tentativi. Una chiamata non riuscita che viene ritentata consuma comunque la quota di richieste e spesso anche i token, quindi le integrazioni soggette a errori costano più di quanto suggerisce la matematica del percorso felice.
• Tralasciando il resto della pipeline. Una funzionalità RAG o agente di solito aggiunge richieste di incorporamento, chiamate di ricerca vettoriale e talvolta un modello di routing più piccolo, ciascuno fatturato separatamente, separatamente dai token del modello principale.

Continua ad imparare

Domande frequenti

Qual è la differenza tra un token e una richiesta API?

Una richiesta API è una singola chiamata all'endpoint; i token sono le unità di testo al suo interno. Una richiesta può contenere pochissimi token o centinaia di migliaia. Gli LLM fatturano per token, mentre molte altre API fatturano per richiesta.

Quanti token è un tipico messaggio di chatbot?

Un breve messaggio utente più un prompt di sistema corrisponde spesso a poche centinaia di token di input e una risposta a poche centinaia di token di output: circa 500-1.000 token per scambio, sebbene vari con la lunghezza del prompt e la verbosità della risposta.

Come posso stimare il mio utilizzo mensile di token?

Multiply tokens per call by calls per user by number of users. Stima separatamente i token di input e output poiché hanno un prezzo diverso, quindi esegui il totale tramite un calcolatore del costo dei token per il modello scelto.

Un token costa lo stesso sia che sia in input che in output?

No: i token di output hanno in genere un prezzo più alto rispetto ai token di input per lo stesso modello, spesso 3-5 volte di più. Mantenere separati i totali di input e output, anziché fonderli in un’unica media, fornisce una stima dei costi molto più accurata.

Cos'altro dovrei mettere in preventivo oltre ai token del modello principale?

In una pipeline RAG o agente, il budget per l'incorporamento di richieste, le query del database vettoriale e qualsiasi chiamata più piccola al modello di routing o classificazione: ciascuno viene fatturato separatamente dai token del modello principale e può sommarsi a una funzionalità a volume elevato.

I limiti di velocità contano richieste o token?

Di solito entrambi contemporaneamente: i fornitori impostano un limite separato di richieste al minuto (RPM) e di token al minuto (TPM) e tu raggiungi quello che il tuo modello di traffico satura per primo. Le chiamate brevi ad alta frequenza tendono a raggiungere prima gli RPM; le chiamate a contesto lungo a bassa frequenza tendono a colpire prima il TPM.