Quanto costano effettivamente i token LLM e come pagarne meno

Ogni fattura API per un modello linguistico è una fattura per token e quasi nessuno ha un'intuizione di quanti token sia un dato pezzo di testo. Il risultato è la stessa sorpresa due volte al mese: una funzionalità che sembrava economica durante i test costa quaranta volte di più in produzione, oppure una finestra di contesto che "dovrebbe adattarsi" rifiuta la richiesta. Entrambi sono problemi aritmetici e vale la pena imparare l'aritmetica una volta.

Un token non è una parola

I modelli non leggono caratteri o parole. Leggono i token, ovvero pezzi prodotti da un codificatore di coppie di byte che hanno appreso, durante l'addestramento, quali sequenze si verificano abbastanza spesso da meritare il proprio simbolo. Le parole inglesi comuni sono un segno. Quelli rari si dividono. COSÌ token è uno e tokenization è tre, mentre una stringa casuale come x7Qp2 può costare cinque.

Le regole pratiche che vale la pena seguire:

• Prosa inglese: circa quattro caratteri per token o circa 0,75 token per parola. Un articolo di mille parole equivale a circa 1.300 token.
• Codice: notevolmente peggio. Gli identificatori di rientro, punteggiatura e camelCase sono tutti frammenti. Budget più vicino a tre caratteri per token e tratta il codice minimizzato come il suo stesso disastro: tokenizza male proprio perché è insolito.
• Scritture non latine: ancora molto peggio. Cinese, giapponese e coreano comunemente si avvicinano a un token per uno o due caratteri, quindi lo stesso contenuto in giapponese può costare molte volte quello della versione inglese. Il cirillico e il greco si trovano nel mezzo.
• JSON: la punteggiatura è denaro vero. Ogni virgoletta, parentesi graffa, due punti e virgola è almeno parte di un token e le strutture profondamente annidate con nomi di chiavi lunghi possono spendere di più sulla sintassi che sui valori.

Le regole pratiche servono per la stima. Quando conta, conta: il Gettone LLM e calcolatore dei costi tokenizza ciò che incolli e stampa il conteggio e può anche mostrare il testo con i limiti del token contrassegnati, che è il modo più veloce per capire perché uno dei tuoi prompt è inaspettatamente costoso. Vedere i nomi dei tuoi identificatori frantumarsi in quattro pezzi ciascuno spiega molto.

L’output costa molte volte di più dell’input

Il dettaglio dei prezzi non è noto alle persone: i fornitori addebitano separatamente i token inviati e i token generati dal modello e l'output è in genere da quattro a otto volte la velocità di input. Un prompt con 10.000 token di contesto e una risposta di 200 token è dominato dall'input. Un prompt con 500 token di istruzione che produce un saggio da 4.000 token è dominato, pesantemente, dall'output.

Ciò inverte molti istinti di ottimizzazione. Ridurre un prompt di sistema da 900 a 600 token consente di risparmiare molto poco se il modello scrive risposte lunghe a ogni chiamata. Dire al modello di rispondere in tre frasi anziché in tre paragrafi consente di risparmiare molto. Chiedi su quale lato della transazione risiede effettivamente il tuo carico di lavoro prima di ottimizzare quello sbagliato.

Il calcolatore valuta lo stesso testo rispetto a ogni modello nella sua tabella sia in termini di input che di output, in modo da poter confrontare un modello economico che esegue l'intero lavoro con uno costoso che ne esegue parte. I prezzi di riferimento vengono archiviati localmente e confrontati periodicamente con le pagine del fornitore: trattali come un aiuto per la pianificazione e confermali con la pagina dei prezzi del fornitore prima di impegnarti in un budget, perché le tariffe cambiano.

La chat è quadratica ed è qui che muoiono i budget

Una chiamata API one-shot costa quello che costa. Una conversazione invia nuovamente l'intera cronologia a ogni turno, quindi una chat di venti turni non costa venti volte un turno: costa all'incirca la somma di una serie crescente. Il turno venti paga nuovamente i turni da uno a diciannove.

Due conseguenze. Innanzitutto, i loop di agenti di lunga durata rappresentano la forma più costosa di utilizzo del LLM e quella che con maggiore probabilità verrà prototipata senza misurazione. In secondo luogo, la memorizzazione nella cache del prompt conta più di qualsiasi modifica di testo: i fornitori scontano i token che ripetono un prefisso che hanno già visto, il che significa mettere il contenuto stabile (il prompt di sistema, lo schema, gli esempi) in primo piano e la parte variabile alla fine. Riordina lo stesso prompt in modo che il timestamp che cambia si trovi in alto e hai invalidato la cache su ogni chiamata senza modificare nient'altro.

Rimpicciolire un messaggio prima di inviarlo

La maggior parte dei prompt di grandi dimensioni sono sovradimensionati per motivi noiosi: qualcuno ha incollato un intero file quando tre funzioni erano rilevanti e il file è composto da metà commenti e righe vuote. IL Compressore del contesto LLM mira esattamente a questo: rimuove i commenti del codice, comprime sequenze di righe vuote, rientra e rimuove le parole di riempimento dalla prosa, quindi segnala quanti token sono stati salvati dalla rifinitura. Su un file sorgente reale che viene eseguito regolarmente al 20-40% senza toccare nulla di cui il modello ha bisogno.

I tagli manuali che vale la pena fare prima:

1. Invia estratti, non file. Anche l’attenzione del modello non è gratuita; il contesto irrilevante degrada in modo misurabile le risposte oltre a costare denaro.
2. Elimina i log nell'area in errore. Diecimila righe di output di avvio riuscito non contribuiscono nulla a una diagnosi.
3. Rilascia il boilerplate ripetuto. Intestazioni di licenza, importazioni generate, la stessa limitazione di responsabilità su ogni record.
4. Riepilogare invece di inviare nuovamente. In una lunga conversazione, sostituire i turni da uno a quindici con un paragrafo di stato è il più grande risparmio possibile.

Quando l'input davvero non si adatta

Le finestre di contesto sono grandi ora, ma "grande" è ancora limitato e un libro, un anno di registri o una trascrizione completa ne supereranno uno. La divisione è la risposta standard e il punto in cui dividi è importante: tagliare a metà frase o a metà funzione produce pezzi che il modello deve indovinare. IL divisore rapido divide il testo in blocchi della dimensione scelta rispettando i confini e numera le parti in modo da poterle alimentare in sequenza con un'istruzione coerente allegata a ciascuna.

Una nota sulle unità: i token non sono byte. IL Contatore byte UTF-8 risponde a una domanda diversa - quanto spazio occupa il testo sul cavo o in una colonna del database - e i due numeri divergono nettamente per il testo non latino, dove i byte per carattere aumentano contemporaneamente alla diminuzione dei caratteri per token. Utilizza i byte per i limiti di archiviazione e i token per i limiti del modello e non sostituirli mai l'uno con l'altro.

Un esempio pratico

Supponiamo di rispondere a venti domande su un documento di trenta pagine. Trenta pagine equivalgono a circa 15.000 parole, quindi circa 20.000 token. Ingenuamente, invii il documento con ogni domanda: 20 × 20.000 = 400.000 token di input, più forse 20 × 300 token di output.

Metti il documento per primo e mantienilo identico in byte tra le chiamate, e la maggior parte dei provider fornisce il prefisso ripetuto dalla cache a una frazione della tariffa. Taglia prima il documento del boilerplate e anche la base si restringe. Raggruppa cinque domande per chiamata invece di una e invii il documento quattro volte invece di venti. Lo stesso compito, lo stesso modello e un ordine di grandezza tra la versione negligente e quella attenta: che è il punto centrale da contare prima di inviare.

Sia il contatore che il compressore funzionano interamente nel tuo browser: la richiesta che stai valutando non viene caricata da nessuna parte per essere misurata.