Cost-per-Task al posto del Benchmark Score: il metodo di 30 minuti per decidere se cambiare modello
TL;DR: Le tabelle dei benchmark confrontano i modelli su compiti estranei alla tua attività. Ma le tue decisioni si basano sui tuoi task specifici. Con cinque task reali, due cicli di misurazione e una mini-tabella per categoria di token, in 30 minuti avrai il tuo calcolo Cost-per-Task personalizzato — e deciderai di cambiare modello solo se ci guadagni in euro e secondi, non solo nel punteggio astratto.
Perché la sola tabella dei benchmark raramente è sufficiente
I punteggi pubblici come GPQA o MMLU sono utili per una prima selezione. Tuttavia, per valutare la sostituzione di un modello in uso, mancano di tre elementi chiave: non conoscono la lunghezza dei tuoi prompt, ignorano la "tassa di contesto" (il carico aggiuntivo sulle performance) nelle sessioni lunghe e non dicono nulla sul tuo reale rapporto qualità-prezzo per singolo task.
Un modello può avere 3 punti in più sulla carta ed essere comunque più costoso o più lento nella tua infrastruttura — magari perché richiede più token di output per risposta o sfrutta peggio la tua cache. Per questo: misurazioni proprie, calcoli propri.
Il metodo dei 30 minuti in 5 passaggi
- Scegliere cinque task reali: le ultime cinque richieste effettuate in produzione nel tuo workflow, non esempi da tutorial.
- Stessi prompt, entrambi i modelli: esegui una volta col vecchio, una volta col nuovo, mantenendo gli stessi parametri (temperatura, max tokens).
- Annotare quattro valori per esecuzione: token di input, token di output, secondi impiegati, risposta corretta (sì/no).
- Calcolare il Cost-per-Task: dividi il numero di token per 1.000.000, moltiplica per il rispettivo prezzo del token, poi somma i risultati per ogni task.
- Confrontare dopo 5 task: calcola le mediane — non le medie, altrimenti eventuali valori anomali (outlier) falseranno il quadro.
Il report si riduce a una singola tabella. Non serve altro.
Esempio di calcolo con dati di prezzo reali
Hy-4 Preview (Tencent, 770B totali / 49B parametri attivi, licenza Apache 2.0) tramite API costa 0,834 USD per milione di token di input e 2,001 USD per milione di token di output. Un tipico task di supporto con 8.000 token di input e 2.000 di output:
| Modello | Input | Output | Cost-per-Task |
|---|---|---|---|
| Hy-4 Preview | 8.000 × $0,834/M = $0,0067 | 2.000 × $2,001/M = $0,0040 | ≈ $0,011 |
| Modello Frontier (Rif.) | 8.000 × $1,25/M = $0,0100 | 2.000 × $10/M = $0,0200 | ≈ $0,030 |
Con 2.000 task al mese arriviamo a circa 22 USD contro 60 USD. Il passaggio conviene se le risposte fornite ai cinque task sono qualitativamente almeno equivalenti — misurate sul tuo corpus personale, non su una leaderboard.
Chi effettua test in locale applica la stessa logica utilizzando il tempo hardware al posto dei prezzi dei token: Qwen3.8-27B in formato GGUF richiede un footprint di circa 11,8 GB e gira a circa 40 token/s su una RTX 5060 Ti — anche questo è un valore Cost-per-Task, solo espresso in secondi anziché in dollari.
Un template di test da copiare
task_01:
prompt_hash: a1b2c3
model_old: {input: 8000, output: 2000, seconds: 6.4, correct: true}
model_new: {input: 8000, output: 1700, seconds: 4.1, correct: true}
cost_old: 0.030
cost_new: 0.010
task_02: ...
# Calcolare le mediane alla fine, non le medie
Errori tipici
- Serie troppo brevi: con meno di cinque task la varianza supera la differenza reale. Misurare invece di tirare a indovinare.
- Modifica dei parametri: chi altera la temperatura o altri parametri sul nuovo modello sta testando il modello in sé, non l'efficacia del passaggio.
- Dimenticare la "tassa di contesto": le sessioni lunghe gonfiano enormemente i token di input. Proprio per questo bisogna contare a livello di task, non in modo forfettario per modello.
- Confrontare solo i dollari: per i workflow in cui la latenza è critica, la colonna dei secondi è l'ago della bilancia.
FAQ
Di quanti task ho bisogno per un calcolo affidabile del Cost-per-Task? Cinque task sono il limite minimo, dieci offrono un buon margine. Il motivo: il numero di token varia notevolmente a seconda del tipo di task, e la mediana di cinque esecuzioni livella i dati molto meglio rispetto alla media di due. Se dopo cinque task non emerge un pattern coerente, significa che la selezione dei task era troppo mista; in tal caso, dividila in due serie distinte (es. classificazioni brevi vs riassunti lunghi).
Cosa succede se il nuovo modello restituisce un numero diverso di token per lo stesso prompt? È normale e fa parte della misurazione: annota separatamente i token di input e output per ogni modello. Il calcolo del Cost-per-Task ammortizza automaticamente la differenza, poiché entrambi i valori rientrano nella somma. Dovresti confrontare il numero di secondi solo a parità di lunghezza del prompt, altrimenti andrai a mescolare gli effetti di latenza con le differenze intrinseche del modello.
Il metodo funziona anche per i modelli locali? Sì, in quel caso invece di calcolare i dollari per token, calcolerai i secondi per task all'interno della tua finestra hardware fissa. Un'esecuzione in locale con un footprint di 11,8 GB a 40 token/s è direttamente paragonabile al tempo di esecuzione tramite API, poiché entrambe terminano nella stessa unità di misura (secondi per task). Il vantaggio: il comportamento della tua cache e il peso del contesto vengono misurati in condizioni di assoluta realtà.
Come gestisco il caching? Devo disattivarlo? No, al contrario: fai le misurazioni nella stessa identica modalità che usi in produzione. Il prompt caching fa parte del profilo di costo della tua infrastruttura. Segna semplicemente nella tabella di test se la cache era calda (warm) o fredda (cold), in modo da confrontare mele con mele. Una singola esecuzione a freddo (cold start) per ogni modello è sufficiente come base di riferimento.
Quando ha senso rifare le misurazioni in un secondo momento? A ogni major release del nuovo modello e in caso di modifiche al listino prezzi — entrambe le cose avvengono di rado, quindi farai misurazioni al massimo ogni trimestre. Nel frattempo, la prima misurazione è più che sufficiente, poiché i prezzi dei token e l'architettura dei modelli non cambiano di continuo. Solo se la lunghezza dei tuoi prompt dovesse subire variazioni importanti in produzione dovrai aggiornare la serie, poiché la curva del Cost-per-Task si sposterà di conseguenza.
Fonti
- Tencent Hy-4 Preview (dati sul modello e sui prezzi): https://www.youtube.com/watch?v=Dmlszfz2LjM
- Deltafin — Layer-Streaming per Kimi K3 da 2,8T su NVMe per laptop: https://github.com/argonautlabsai/deltafin
- Valori di misurazione Qwen3.8-27B GGUF (Footprint, tok/s): Kontext-Studios-Daily-Intel-Run #175
- Google Gemini API-Pricing (prezzi di riferimento): https://ai.google.dev/gemini-api/docs/pricing