AWS: oltre il prezzo per token per scegliere un modello

AWS mette in guardia chi usa modelli in produzione: il prezzo per token non basta a stimare il costo reale di un esito, come un ticket risolto o un riepilogo corretto¹.

Nel post, il team confronta tre modelli su Amazon Bedrock — gpt-5.6-luna, gpt-5.6-terra e gpt-5.6-sol — con due baseline economiche sull’API OpenAI: gpt-5.4-mini e gpt-5.4-nano¹. La scelta delle baseline serve a partire da opzioni a basso costo diffuse tra i team, non a misurare pari generazionali dei modelli Bedrock¹.

Per misurare i costi di outcome, AWS usa un harness di benchmark open-source. Lo strumento tiene conto di tre fattori che il listino ignora: quante volte il modello fornisce una risposta corretta, quanti token consuma per arrivarci e, nei workload agentici, quanti turni servono per chiudere la task, perché ogni scambio reinvia una conversazione che cresce¹. Questi elementi, moltiplicati per il prezzo per token, portano al conto finale¹.

La pratica corrente nei fogli di calcolo guarda ai dollari per milione di token. È un numero comodo, ma parziale¹. In produzione si paga l’esito, non il gettone. Se un modello sbaglia più spesso, consuma più token per centrarsi o accumula turni che rialimentano l’intera cronologia, il “risparmio” da listino evapora¹.

L’indicazione operativa è netta: valutare un modello significa misurare outcome su task concreti e il percorso per ottenerli¹. Serve annotare:

• tasso di correttezza sul dataset di interesse;
• token effettivi per task fino alla soluzione;
• turni necessari negli agenti, con la consapevolezza che ogni turno rinvia la conversazione completa, che si allunga e quindi costa di più¹. Il prezzo per token resta un input, non il totale¹.

AWS applica questa cornice ai modelli su Bedrock e alle baseline scelte sull’API OpenAI per mostrare come piccole differenze di accuratezza, verbosità o numero di turni modifichino il costo per esito, anche quando i listini sembrano favorevoli ai modelli meno cari¹. L’obiettivo è aiutare i team a leggere il conto alla luce dell’esito desiderato: un ticket chiuso, un brief completato, un riepilogo finanziario corretto¹.

Indicazione finale per chi porta modelli in produzione: impostare un mini-benchmark interno prima della scelta. Per ciascun task nel campione, registrare esito corretto/errato, token totali scambiati e turni. Sommare i token dei casi testati e applicare il prezzo per token del modello. Poi mettere questo costo accanto al numero di esiti corretti ottenuti. Così si vede quanto si spende per raggiungere un risultato utile, non solo quanto costa un milione di token¹.