—ultimo turno da solo
—rispetto al costo forfettario
—con finestra/cache
Il costo accelera con il conteggio dei turni
L’input per turno continua a salire man mano che la storia si accumula, quindi la curva dei costi cumulativi si piega verso l’alto: raddoppiando i turni si raddoppia il conto.
| A turno | Questo turno costa | Cumulativo |
|---|
Paghi per la cronologia ad ogni turno
Un modello linguistico è senza stato: non ricorda nulla tra le chiamate API, quindi per continuare una conversazione la tua applicazione invia nuovamente l'intera trascrizione (prompt di sistema, ogni messaggio utente passato e ogni risposta passata) come input di ogni nuova richiesta. Ciò significa che l’input cresce di uno scambio alla volta e il costo dell’intera conversazione cresce all’incirca con il quadrato del numero di turni, non in modo lineare. L'ultimo turno di una chat lunga è quello più costoso perché contiene la maggior parte della cronologia e il prompt di sistema fisso viene fatturato una volta per turno. Tre leve lo riportano giù: a finestra scorrevole che conserva solo le svolte recenti (il costo diventa lineare, a scapito della memoria), memorizzazione nella cache tempestiva questo fattura il prefisso ripetuto con un forte sconto e il riassunto del vecchio si trasforma in un breve riepilogo. Confronta una singola finestra sul calcolatore dei costi della finestra di contesto, dimensiona la vincita della memorizzazione nella cache su calcolatore rapido del risparmio di memorizzazione nella cache, e costa un assistente completo sul calcolatore dei costi del chatbot.
Come funziona questa calcolatrice
IL Calcolatore dei costi di conversazione multi-turno stima il costo totale dei token di una sessione di chat completa, non di una singola richiesta. Poiché la maggior parte delle API di chat sono stateless, ogni nuovo turno invia nuovamente l'intera cronologia precedente, quindi la calcolatrice moltiplica il tuo richiesta del sistema, token per messaggio utente, E token per risposta dell'assistente attraverso la trascrizione in crescita per ciascuno degli elementi specificati gira, quindi applica i prezzi di input e output per milione di token. Il principale fattore di costo è che il reinvio della cronologia comporta l'accumulo di token di input quadraticamente con il conteggio dei turni, motivo per cui una lunga conversazione può costare molto di più di quanto suggeriscono i singoli messaggi.
Il compromesso chiave è controllare tale crescita. Impostazione a finestra scorrevole mantiene solo le svolte più recenti, limitando la quantità di cronologia risentita, mentre a sconto sulla cache riduce il prezzo del prefisso ripetuto. Entrambi hanno un costo inferiore, ma una finestra più ristretta indica il modello dimentica contesto precedente, quindi osserva con quanta aggressività rifinisci prima che la qualità ne risenta.
Domande frequenti
Perché una lunga chat costa più di quanto suggerisce il numero di messaggi?
Poiché un LLM non ha memoria tra le chiamate, ogni turno deve inviare nuovamente l'intera conversazione precedente come input in modo che il modello possa vedere il contesto. Al turno dieci il modello rilegge tutti i nove scambi precedenti più il prompt del sistema, al turno venti ne rilegge diciannove e così via. I gettoni di input quindi crescono ad ogni turno e il costo cumulativo dell'intera conversazione cresce all'incirca con il quadrato del conteggio dei turni anziché in modo lineare. Una conversazione da cento giri può costare molto di più di cento chiamate a turno singolo con la stessa dimensione del messaggio: la cronologia è ciò per cui paghi, ancora e ancora.
Come posso impedire che i costi delle conversazioni esplodano?
Tre leve. Una finestra scorrevole conserva solo gli ultimi giri della storia, limitando l’input a una dimensione fissa in modo che il costo cresca in modo lineare anziché quadratico, al prezzo che il modello dimentichi il contesto precedente. La memorizzazione nella cache immediata consente al fornitore di memorizzare il prefisso ripetuto e di fatturarlo con un ampio sconto su ogni riutilizzo, il che è l'ideale quando la cronologia iniziale e la richiesta di sistema rimangono identiche. E il riepilogo comprime i vecchi passaggi in un breve riepilogo in modo da mantenere il significato senza conservare i token. Questo calcolatore mostra il costo ingenuo della cronologia completa insieme a una versione in finestra e a una memorizzata nella cache in modo da poter vedere quale leva ripaga per la durata della conversazione.
Un sistema più grande ha importanza in una lunga conversazione?
Sì, più di quanto la gente si aspetti, perché il prompt del sistema viene inviato nuovamente ad ogni singolo turno. Un prompt di sistema da 2.000 token in una conversazione da cinquanta turni viene fatturato cinquanta volte: centomila token di input prima che venga conteggiato qualsiasi messaggio dell'utente. Nelle chat lunghe o ad alto volume, il prompt di sistema fisso rappresenta spesso una quota maggiore del conto rispetto alla conversazione effettiva, che è esattamente il tipo di costo che la memorizzazione nella cache del prompt è progettata per rimuovere. Il calcolatore separa il contributo del prompt di sistema in modo da poter vedere se vale la pena tagliarlo o memorizzarlo nella cache.