# Come risparmiare sui costi AI senza peggiorare il servizio

[Pagina originale](https://danilolapegna.com/guides/come-risparmiare-sui-costi-ai.html)

Lingua: it. Aggiornamento del contenuto: 2026-10-16.

Da dove iniziare per spendere meno con l'AI: chiamate inutili, modelli, cache e contesto, con esempi e una prova di confronto in 14 giorni.

La spesa AI sale quasi sempre in modo poco spettacolare: un prompt si allunga, la cronologia cresce, partono due tentativi invece di uno, un modello costoso finisce anche sui casi facili. Poi arriva la fattura. La prima mossa non è inseguire il token meno caro: è misurare il **costo di un risultato che qualcuno accetta davvero** e togliere ciò che non contribuisce a quel risultato.

Puoi preparare il confronto senza programmare. Per modificare modello, cache o configurazione coinvolgi chi gestisce il sistema.

Questa guida ti aiuta a trovare la prima riduzione sensata, provarla su casi reali e capire quando fermarti. Non serve conoscere il codice del sistema. Serve poter vedere almeno le chiamate, i costi e qualche esempio di output.

## Se hai poco tempo, fai queste tre cose

1. **Separa la spesa per lavoro.** Non fermarti a provider e modello. Distingui, per esempio, assistenza clienti, analisi documenti, generazione contenuti e attività interne.
2. **Scegli un solo lavoro ricorrente.** Prendi venti casi reali e segna per ciascuno costo, tentativi, risultato accettato e minuti di correzione umana.
3. **Cambia una leva alla volta.** Prima elimina chiamate e tentativi inutili; poi prova modello, lunghezza della risposta, riuso del contesto ed elaborazione in lotti. Tieni la variante soltanto se supera lo stesso controllo di qualità.

Se oggi non riesci a fare il punto 1, hai già trovato il primo problema: **la spesa non è attribuibile**. Prima di ottimizzare, va resa leggibile.

## Dove stanno andando i soldi

I token sono le unità con cui i modelli leggono il materiale inviato, chiamato input, e producono la risposta, chiamata output. Ma la fattura di un sistema AI può contenere molto altro:

- Chiamate ripetute dopo un errore o una risposta scartata;
- Modelli e livelli di ragionamento più potenti del necessario;
- Cronologie, istruzioni e documenti reinviati a ogni richiesta;
- Risposte molto più lunghe di quanto serva;
- Ricerca documentale, archivi semantici, controlli di sicurezza, strumenti e spazio occupato;
- Controllo umano e rilavorazione;
- Capacità riservata o infrastruttura che resta inutilizzata.

Per questo “usiamo troppi token” è spesso una diagnosi incompleta. Questa tabella aiuta a scegliere da dove cominciare.

| Quello che vedi | Causa probabile | Prima verifica |
|---|---|---|
| Molte chiamate per una sola attività | tentativi automatici, cicli o passaggi duplicati | conta chiamate e fallimenti per risultato accettato |
| Input enorme e quasi identico | istruzioni o documenti reinviati | misura parte stabile, parte variabile e riuso effettivo |
| Pochi casi molto costosi | eccezioni, tool o contesto fuori scala | guarda il 10% più caro, non soltanto la media |
| Output lunghi che nessuno usa | formato non vincolato | confronta lunghezza prodotta e parte realmente utilizzata |
| Modello premium su tutto | nessun instradamento per difficoltà | separa casi semplici, ambigui e ad alto rischio |
| Fattura alta, token normali | costi esterni al modello | isola ricerca documentale, spazio, controlli di sicurezza, calcolo e revisione |

## La metrica che evita i falsi risparmi

Una chiamata da un centesimo può costare più di una da cinque se deve essere ripetuta, corretta o scartata.

Usa questo denominatore:

> **Costo per risultato accettato = (costo tecnico di tutti i tentativi + costo umano di verifica e correzione) ÷ numero di risultati accettati.**

Non serve un modello finanziario perfetto. Per un primo confronto bastano:

| Campo | Che cosa registrare |
|---|---|
| Lavoro | il processo o la funzione servita |
| Volume | richieste e risultati prodotti |
| Consumo | input, output, cache, tool e costo infrastrutturale |
| Fallimenti | errori, interruzioni, tentativi ripetuti e risultati scartati |
| Qualità | quanti risultati superano il controllo concordato |
| Rework | minuti necessari per verificare e correggere |

La media da sola non basta. Conserva anche il caso mediano e il 10% più costoso: spesso la spesa nasce nelle eccezioni.

Esempio illustrativo su venti richieste: il sistema attuale costa 2 euro di elaborazione e 10 di revisione, con venti casi accettati: 0,60 euro per risultato. La variante costa 1 euro di elaborazione e 15 di revisione, con sedici casi accettati: 1 euro per risultato. La fattura del modello è scesa; il servizio costa di più. Con zero risultati accettati il processo non è utilizzabile: il costo unitario non è zero.

## Le leve, nell'ordine in cui le proverei

### 1. Elimina il lavoro che non doveva partire

È la leva più concreta perché non chiede al modello di diventare più bravo con meno informazioni.

Cerca chiamate duplicate, cicli, tentativi ripetuti senza limite, richieste lanciate anche quando mancano i dati minimi e risultati generati ma mai usati. Se dieci chiamate producono cinque risultati accettati, il problema non si risolve limando il prompt dell'8%.

**Funziona bene quando:** il flusso è cresciuto per aggiunte successive e nessuno possiede il conto completo delle chiamate.

**Non basta quando:** ogni chiamata è necessaria e la spesa è concentrata nel modello o nel contesto.

### 2. Usa potenza e ragionamento soltanto dove servono

Dividi i casi in tre gruppi: semplici, ambigui, ad alto rischio. Prova un modello o un livello di ragionamento più leggero sui primi, mantenendo quello più capace per gli altri.

Non promuovere questo instradamento perché “sembra uguale” su tre esempi. Esegui lo stesso lotto di casi e usa lo stesso controllo. Il modello più economico non fa risparmiare se genera più errori o più casi da passare a una persona.

**Funziona bene quando:** gran parte del volume è ripetitiva e soltanto una quota richiede davvero giudizio complesso.

**Non funziona quando:** la regola che sceglie il modello non sa riconoscere i casi difficili o il controllo di qualità è vago.

### 3. Chiedi l'output che verrà davvero usato

Se al sistema servono cinque campi, non chiedere prima una relazione e poi estrarre i cinque campi. Definisci uno schema, limita la verbosità e fai fallire in modo leggibile ciò che non rispetta il formato.

Ridurre l'output è spesso più sicuro che togliere informazioni dall'input: cambia la forma della risposta, non ciò che il modello può conoscere.

**Funziona bene quando:** le risposte vengono lette da software o finiscono in campi strutturati.

**Non basta quando:** il vero costo viene da documenti e cronologie molto lunghi.

### 4. Riusa il contesto stabile con la cache

I provider principali offrono forme di prompt caching. In pratica, le istruzioni e i documenti identici possono essere riutilizzati senza pagarli ogni volta come nuovo input, secondo regole e prezzi del provider.

Metti la parte stabile all'inizio e quella variabile alla fine. Poi verifica i campi di utilizzo: il supporto alla cache non garantisce che ogni chiamata riusi davvero il blocco. Considera anche costo di scrittura, durata e spazio occupato.

**Funziona bene quando:** molte richieste condividono un prefisso ampio e realmente identico.

**Non funziona quando:** il contenuto cambia continuamente, viene riusato troppo poco o la cache costa più di quanto evita.

### 5. Porta nel contesto soltanto ciò che serve a quel caso

Inviare tutto è semplice da costruire e costoso da mantenere. La soluzione non è aggiungere in astratto un sistema di ricerca documentale, spesso chiamato RAG. È recuperare poche fonti pertinenti, conservarne il riferimento e verificare che i fatti obbligatori siano ancora presenti.

Per una cronologia lunga, conserva fatti, decisioni, vincoli e punti aperti, lasciando fuori gli scambi che non servono più al compito attuale. Per un archivio, recupera sezioni precise invece dell'intero manuale. Per il risultato di uno strumento, passa i campi utili e un riferimento alla fonte invece di pagine grezze.

**Funziona bene quando:** gran parte dell'input non cambia la decisione finale.

**Non funziona quando:** la selezione elimina un'eccezione, una scadenza o una fonte necessaria. Il test Distill qui sotto mostra entrambe le possibilità.

### 6. Sposta in lotti il lavoro che può aspettare

Classificazioni notturne, estrazioni massive e valutazioni offline non devono per forza usare lo stesso percorso delle richieste interattive. Al 15 settembre 2026, OpenAI e Anthropic documentano uno sconto del 50% per le rispettive API batch, in cambio di elaborazione asincrona e vincoli specifici.

**Funziona bene quando:** il risultato può arrivare più tardi e il lotto è abbastanza stabile.

**Non funziona quando:** la persona aspetta la risposta, il carico è piccolo o il ritardo crea più lavoro operativo.

### 7. Valuta contratti e infrastruttura soltanto dopo

Capacità riservata, sconti di volume e modelli ospitati in proprio possono ridurre il costo unitario. Possono anche trasformare una fattura variabile in capacità inutilizzata, manutenzione e reperibilità.

Questa leva viene dopo, non prima. Ha senso quando volume, profilo di carico e requisito di qualità sono già stabili.

## Distill: due prove per ridurre il contesto

Nel DL Frontier Lab abbiamo provato una domanda precisa: **quanto contesto possiamo togliere conservando i fatti necessari al lavoro?**

Nel primo test, dedicato a riprendere un'attività di ricerca dopo una settimana, il pacchetto completo conteneva il rapporto precedente, la nota di consegna e il registro dell'ultima attività. La variante conservava soltanto nota di consegna e registro dell'attività.

- Dimensione misurata: da 8.074 a 1.353 parole;
- Riduzione: 83,24%;
- Fatti richiesti conservati: 5 su 5;
- Verdetto: **promossa**.

Le parole erano un proxy ripetibile della dimensione del contesto, non token fatturati dal provider. Quindi il risultato prova una forte riduzione dell'input su quel lavoro; non prova un risparmio universale dell'83,24% in euro.

Il secondo test sembrava ancora migliore: da 4.326 a 604 parole. Però la variante ricordava soltanto 3 fatti su 5 e perdeva due scadenze operative. Verdetto: **bocciata per qualità**.

Il dato utile non è “possiamo comprimere dell'83%”. È questo: **la selezione funziona quando il pacchetto ridotto contiene già le fonti giuste; fallisce quando una fonte esclusa possiede un fatto che il lavoro deve ricordare**.

Puoi approfondire il metodo, le prove e i limiti di [Distill, l'esperimento per ridurre il contesto inviato all'AI](/lab/distill-contesto-senza-perdere-fatti).

## Che cosa tende a funzionare di più

Non esiste una classifica universale, ma esiste un ordine prudente:

1. **Chiamate, tentativi ripetuti e risultati inutili:** impatto alto e rischio basso, perché elimini spreco puro.
2. **Output più corto e strutturato:** facile da misurare, spesso poco invasivo.
3. **Routing di modello e ragionamento:** può incidere molto sui volumi alti, ma richiede un buon test di qualità.
4. **Cache del contesto stabile:** molto efficace se il riuso è reale; irrilevante senza riuso effettivo.
5. **Selezione e distillazione del contesto:** potenziale alto, rischio più alto; serve un controllo sui fatti.
6. **Batch:** risparmio di listino chiaro sui provider che lo offrono, ma soltanto per lavori non urgenti.
7. **Modello ospitato in proprio o capacità riservata:** può avere senso su carichi maturi; è una decisione infrastrutturale, non un trucco sui token.

Questo ordine evita di cominciare dalla leva più affascinante e finire con un sistema più complicato del problema.

## Le scorciatoie che spesso non fanno risparmiare

- **Scegliere il modello più economico per tutto.** I tentativi ripetuti e le correzioni possono mangiare il vantaggio.
- **Accorciare prompt e documenti alla cieca.** Una frase tolta può contenere proprio l'eccezione costosa.
- **Aggiungere un RAG senza misurare selezione delle fonti e qualità.** Introduce altre chiamate, spazio occupato e nuovi punti di errore.
- **Fare addestramento aggiuntivo, o fine-tuning, come prima mossa.** Può servire per comportamento e specializzazione; non ripara un flusso che chiama troppo o porta dati inutili.
- **Mettere in cache contenuto quasi sempre diverso.** Paghi scrittura o storage senza riuso sufficiente.
- **Ospitare un modello in proprio perché il listino API sembra alto.** Il costo totale include GPU, picchi, osservabilità, aggiornamenti e persone reperibili.
- **Guardare soltanto la fattura del modello.** Strumenti, controlli di sicurezza, database, revisione e output scartati restano invisibili.

## Un piano di prova in quattordici giorni

### Giorni 1-2: rendi la spesa leggibile

Esporta almeno trenta giorni di utilizzo. Mappa provider, modello, ambiente e tipo di lavoro. Se mancano le etichette, ricostruisci un campione da log, destinazione del servizio o chiavi progetto.

### Giorni 3-4: scegli il caso e il controllo

Prendi un lavoro con volume o costo sufficiente. Raccogli venti casi rappresentativi, inclusi quelli difficili. Scrivi i fatti che devono sopravvivere e gli errori che rendono l'output inutilizzabile.

### Giorni 5-8: costruisci la misura iniziale

Esegui il flusso attuale. Registra costo tecnico, chiamate, tentativi ripetuti, qualità e minuti di controllo. Non correggere i numeri dopo aver visto la variante.

### Giorni 9-11: prova una sola leva

Scegli la prima leva compatibile con il segnale: togli chiamate, limita la risposta, cambia instradamento, riusa il contesto, riducilo o sposta il lavoro in lotti. Mantieni tutto il resto uguale.

### Giorni 12-14: decidi e registra il confronto

Confronta l'intero lotto con gli stessi criteri. Includi il costo di tutti i tentativi, anche scartati; dividi per i risultati accettati e riporta anche quanti casi hanno superato il controllo. Se una condizione obbligatoria peggiora, torna alla configurazione precedente. Altrimenti decidi se adottare la variante o correggerla prima di un'altra prova. Annota le due configurazioni, i casi confrontati, il risultato e quando lo controllerai di nuovo.

## La scheda da copiare

> - **Lavoro:** ___
> - **Volume mensile:** ___
> - **Costo tecnico attuale:** ___
> - **Risultati accettati / casi totali:** ___
> - **Minuti di controllo e correzione:** ___
> - **Costo orario usato per valorizzarli:** ___
> - **Costo totale del lotto, scarti inclusi:** ___
> - **Costo per risultato accettato:** ___
> - **Fatti che devono sopravvivere:** ___
> - **Errori che impediscono di adottare la variante:** ___
> - **Prima leva da provare:** ___
> - **Lotto di test:** ___
> - **Regola di ripristino:** ___

Se non riesci a riempire costo, risultati accettati o fatti obbligatori, il primo lavoro è misurare il punto di partenza.

## Nota sui prezzi e sulle funzioni dei provider

Le funzioni cambiano. Questa guida è stata verificata il 15 settembre 2026 sulle documentazioni ufficiali di OpenAI, Anthropic, Google Cloud e AWS. Elaborazione in lotti, cache e scelta automatica del modello hanno prezzi, soglie, durata e campi di utilizzo diversi. Controlla sempre la pagina corrente del fornitore prima di approvare un business case.

Fonti operative consultate:

- [OpenAI: elaborazione Batch](https://platform.openai.com/docs/guides/batch) e [prompt caching](https://platform.openai.com/docs/guides/prompt-caching);
- [Anthropic: prompt caching](https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching) e [Message Batches](https://docs.anthropic.com/en/docs/build-with-claude/message-batches);
- [Google Cloud: prezzi Vertex AI](https://cloud.google.com/vertex-ai/generative-ai/pricing);
- [AWS Bedrock: prompt caching](https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html) e [instradamento intelligente](https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-routing.html).

Se la spesa attraversa più provider o nessuno riesce ad attribuirla ai lavori reali, il [servizio AI Spend Audit](/services/ai-spend-audit) ricostruisce misura iniziale, sprechi e prime prove entro un perimetro concordato. La richiesta è assistita: non è un acquisto automatico e non promette una percentuale di risparmio prima di vedere i dati.

## Domande frequenti

### Da dove comincio per ridurre i costi AI?

Attribuisci almeno trenta giorni di spesa a uno o più lavori reali, poi scegli un solo lavoro ricorrente e misura costo per risultato accettato, tentativi ripetuti e tempo di correzione. Senza questa base, qualsiasi ottimizzazione è una supposizione.

### Ridurre i token riduce sempre la fattura?

No. Il prezzo dipende da provider, modello, input, output, cache e altri servizi. Inoltre un contesto più corto può aumentare errori, retry e lavoro umano. Conta il costo di tutti i tentativi, compresi gli scarti, e dividilo per i risultati accettati con gli stessi criteri; riporta anche il tasso di accettazione.

### Conviene usare sempre un modello AI più economico?

No. Conviene provarlo sui casi semplici e mantenere un percorso più capace per quelli ambigui o ad alto rischio. Il confronto deve includere errori, passaggi alla persona responsabile e correzioni, non soltanto il prezzo della singola chiamata.

### Quando il prompt caching fa risparmiare?

Quando un blocco ampio e identico viene riusato abbastanza volte da compensare eventuali costi di scrittura e conservazione. Va verificato sui campi di utilizzo reali: il semplice supporto alla cache non garantisce un riuso effettivo.

### Che cosa fa un AI Spend Audit?

Ricostruisce dove nasce la spesa per provider, modello e attività; separa sprechi tecnici e costi operativi; sceglie esperimenti limitati; definisce controlli di qualità e ripristino. Non promette una percentuale di risparmio prima di vedere dati e processi.

## Fonti

[OpenAI Batch API guide](https://platform.openai.com/docs/guides/batch)

[OpenAI prompt caching guide](https://platform.openai.com/docs/guides/prompt-caching)

[Anthropic prompt caching documentation](https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching)

[Anthropic Message Batches documentation](https://docs.anthropic.com/en/docs/build-with-claude/message-batches)

[Google Vertex AI generative AI pricing](https://cloud.google.com/vertex-ai/generative-ai/pricing)

[AWS Bedrock prompt caching documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html)

[AWS Bedrock intelligent prompt routing documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-routing.html)

Contenuto realizzato con assistenza AI e revisione umana.