Amazon Nova 2 Lite: come calcolare il costo reale per flusso tra token, cache, livelli di servizio e fallimenti

Dal prezzo unitario al costo di un risultato utile

Il prezzo per milione di token è una componente necessaria, ma da solo non risponde alla domanda operativa rilevante: quanto costa completare un'attività con il risultato e la latenza richiesti dal sistema. In un flusso Amazon Nova 2 Lite su Amazon Bedrock intervengono il volume di input e output, il contesto ripetuto, le chiamate che falliscono, la convalida della risposta e, in base al progetto, il livello di servizio selezionato. Una previsione difendibile deve quindi essere espressa sia in unità di consumo sia in risultati accettati.

È opportuno definire fin dall'inizio un'unità di lavoro. Può essere una richiesta classificata, una pagina elaborata, un documento estratto, una sessione oppure un'automazione che produce un oggetto strutturato valido. L'unità scelta deve comprendere la condizione di accettazione: per esempio, che il JSON superi il validatore, che lo strumento completi l'operazione o che non sia necessaria una revisione umana. In questo modo non viene presentata come un successo una risposta che ha consumato risorse ma è stata scartata.

Questa guida non stabilisce importi: le fonti fornite descrivono identificazione del modello, modalità, cache, livelli di servizio, percorsi di inferenza, quote e dati di utilizzo fatturabile, ma non includono una tabella dei prezzi aggiornata. Prima di elaborare un budget, il team deve fissare la tariffa ufficiale applicabile al di fuori di questo articolo e registrare la data della consultazione. Inserire tale dato nelle formule è preferibile a riutilizzare cifre obsolete o a dedurre prezzi a partire da un altro modello.

L'identificatore di base documentato per il modello è amazon.nova-2-lite-v1:0. La scheda documenta anche profili di inferenza per Stati Uniti, Europa, Giappone e Global. Non si deve supporre che due profili, percorsi o regioni abbiano lo stesso prezzo, la medesima capacità o lo stesso trattamento dei dati soltanto perché invocano il medesimo modello di base.

La scheda di fatturazione da fissare prima di fare i calcoli

Ogni foglio di calcolo dovrebbe iniziare con una scheda di perimetro. Annota data e ora di consultazione della tariffa, valuta, account o ambiente, identificatore del modello, regione di origine, profilo di inferenza, percorso In-Region o Cross-Region, livello di servizio richiesto e unità funzionale. Aggiungi una versione del prompt, la configurazione dell'output, lo schema di convalida e il periodo di osservazione. Questi campi permettono di spiegare perché due misurazioni apparentemente uguali finiscono per avere costi diversi.

La documentazione sui report di costo e utilizzo di Bedrock distingue, per Nova 2 Lite, tipi di utilizzo per input, output, lettura della cache e scrittura della cache. Documenta inoltre suffissi che consentono di distinguere il livello Flex o Priority e l'instradamento Cross-Region. Questa separazione è importante: una stima che somma soltanto token di input e output può omettere operazioni di cache, mentre una riconciliazione aggregata può nascondere una combinazione di percorsi o livelli di servizio.

L'inferenza geografica Cross-Region può elaborare le richieste all'interno della geografia scelta, anche se prompt e risultati possono spostarsi dalla regione di origine a una regione di destinazione in quella geografia. Questo va valutato come requisito di architettura e residenza dei dati, non soltanto come variabile di prezzo. La documentazione fornita non è sufficiente per affermare qui un'equivalenza di prezzo, quota o fatturazione tra In-Region, Geo Cross-Region e Global Cross-Region.

Variabili fatturabili e quattro formule verificabili

Per ogni tentativo, separa almeno token di input ordinari, token di output, letture della cache e scritture della cache. Se il flusso include input multimodali, strumenti integrati, ragionamento o qualche modalità aggiuntiva, aggiungi colonne specifiche soltanto se la tariffa e il registro di utilizzo applicabili le identificano. Non attribuire automaticamente un sovrapprezzo a una funzione per il solo fatto di usarla: con le fonti disponibili non è possibile confermare il trattamento tariffario di ragionamento, immagini, documenti, strumenti o errori API per questo modello.

Usa prezzi unitari convertiti in costo per token oppure mantieni in modo coerente il denominatore per milione di token. Chiama P_i il prezzo dell'input, P_o quello dell'output, P_cr quello della lettura della cache e P_cw quello della scrittura della cache. Per un tentativo j, i consumi corrispondenti sono I_j, O_j, CR_j e CW_j. Se esistono altri concetti pubblicati, incorporali come somma di quantità per prezzo, senza nasconderli all'interno dell'input o dell'output.

La prima formula stima il costo di una singola chiamata. La seconda ripartisce un lotto tra gli elementi elaborati. La terza serve per sessioni che riutilizzano istruzioni o contesto. La quarta trasforma il consumo in costo per attività completata correttamente. In tutte, il risultato dipende dal fatto che la telemetria contabilizzi ogni tentativo, compresi quelli terminati con una convalida non riuscita o abbandonati dopo un'attesa eccessiva.

Cache del prompt: misurare il risparmio netto, non darlo per scontato

Nova 2 Lite supporta una cache esplicita con un minimo di 1.000 token per checkpoint, fino a quattro checkpoint, un tempo di vita di cinque minuti e un massimo di 20.000 token di cache. Questi limiti delimitano i progetti che possono trarne beneficio: un'istruzione lunga e stabile, condivisa da richieste ravvicinate nel tempo, è un candidato più evidente di un contesto piccolo, molto variabile o distribuito nel tempo.

Il confronto corretto non è astrattamente «con cache contro senza cache». Misura token scritti, token letti, numero di richieste idonee, percentuale di hit, intervallo tra le chiamate, complessità aggiuntiva e variazioni nel tasso di successo. La scrittura iniziale può avere un costo diverso da una lettura, e il report di costo e utilizzo consente di distinguere entrambe le categorie. Il risparmio netto si manifesta soltanto se le letture riutilizzate compensano le scritture e la manutenzione del progetto.

Una cache può anche peggiorare l'economia se aumenta la complessità della segmentazione, riduce la personalizzazione necessaria, causa scadenze frequenti o incentiva l'inclusione di contesto irrilevante. Il fatto che un blocco sia memorizzabile non dimostra che riduca la fattura. La decisione deve basarsi su una coorte comparabile e sui costi per attività accettata, non soltanto sui token di input osservati.

Standard, Flex e Priority: una decisione basata sul costo atteso

La documentazione sui livelli di servizio descrive Flex per carichi di lavoro tolleranti ai ritardi e Priority come un'opzione richiesta per chiamata. Indica inoltre che le quote on-demand sono condivise tra Priority, il comportamento predefinito e Flex. La scelta di un livello non elimina quindi la necessità di misurare la domanda aggregata né garantisce di per sé che il flusso operi entro i propri limiti di quota.

Il livello effettivamente servito può essere osservato nella risposta API, in CloudTrail e in CloudWatch secondo la documentazione. Conserva questo dato insieme al livello richiesto. È essenziale per rilevare differenze tra intenzione e servizio erogato e per riconciliare le analisi di latenza, consumo e tipi di utilizzo nel report dei costi.

L'alternativa meno costosa per unità può risultare più cara per risultato utile se aumenta l'abbandono, i timeout o la ripetizione del lavoro. Al contrario, un livello orientato alla priorità giustifica il proprio costo aggiuntivo soltanto se riduce perdite operative che il flusso subisce effettivamente. Questa è una conclusione di analisi economica, non un'affermazione sui prezzi o sulle prestazioni garantite di un livello specifico.

Fallimenti, tentativi ripetuti e risposte scartate: il moltiplicatore da contabilizzare una sola volta

Un flusso robusto deve registrare tutti i tentativi: prima chiamata, tentativo ripetuto automatico, riparazione del JSON, nuova chiamata dopo un timeout ed escalation a revisione umana. Per evitare il doppio conteggio, assegna un identificatore dell'attività radice e un identificatore del tentativo. Ogni costo del modello appartiene a un tentativo; il costo per attività accettata si ottiene aggregando una sola volta i tentativi dell'attività e dividendo per le attività accettate.

Distingui gli errori prima dell'invocazione del modello, che potrebbero non produrre consumo di inferenza, dalle risposte o dai guasti successivi a un'invocazione. Non è sicuro considerare gratuito ogni errore HTTP né identico al primo tentativo ogni retry. La riconciliazione deve usare dati di risposta, registri operativi e i tipi di utilizzo Bedrock disponibili nel report dei costi. Se manca una correlazione per richiesta, documenta questa limitazione invece di attribuire tutta la spesa all'ultimo passaggio visibile.

Le quote pubblicate includono limiti di richieste al minuto e token al minuto per l'inferenza Cross-Region di Nova 2 Lite, e alcune quote possono essere adattate tramite Service Quotas. Misura rifiuti, attese e retry legati ai limiti. Una modifica della quota o del modello di arrivo può cambiare il tasso di successo e il costo effettivo senza che vari il prezzo unitario.

Budget mensile sostituibile e riconciliazione con la spesa

Per predisporre il budget, parti da una previsione delle attività avviate al mese, da una distribuzione attesa dei tentativi per attività e da consumi medi per tipo di tentativo. Calcola ogni segmento separatamente: richieste semplici, documenti, sessioni con contesto ripetuto e automazioni strutturate. Moltiplica il costo medio per tentativo di ogni segmento per i tentativi previsti; quindi somma il costo delle operazioni ausiliarie e della revisione umana se fanno parte del costo operativo su cui si vuole decidere.

Come esempio di struttura, un foglio può avere una riga per segmento e colonne per attività avviate, tasso di accettazione, tentativi per attività, input, output, scrittura e lettura della cache per tentativo, prezzi in vigore, costo stimato e costo per accettato. Le celle dei prezzi devono restare vuote fino alla copia della tariffa verificata per la configurazione concreta. Non è opportuno riempirle con cifre illustrative, perché potrebbero essere interpretate come tariffa corrente.

Alla chiusura del periodo, confronta previsione e realtà per modello, percorso, livello di servizio e tipo di utilizzo. Spiega lo scostamento attraverso cambiamenti nella composizione degli input, nella lunghezza dell'output, negli hit della cache, nei retry e nell'accettazione, prima di attribuirlo a una modifica dei prezzi. Ricalcola quando cambiano il modello, la regione o il profilo, il prompt, la politica di cache, il livello di servizio, la combinazione multimodale, il volume, le quote o le regole di convalida.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.