Strategie di Ottimizzazione dei Token AI: un approccio realistico per ridurre il costo dei token usati

La spesa in token ha una proprietà strana: cresce in silenzio. Un workload che la primavera scorsa costava 4.000 dollari al mese ora ne costa 28.000, la superficie del prodotto sembra la stessa, e nessuno nel team sa esattamente da dove arrivino le chiamate in più. Quando il numero finisce su una slide del board, l'istinto è inseguire qualunque tecnica di ottimizzazione sia di tendenza su Hacker News quella settimana — semantic caching, fine-tuning, routing verso modelli più economici. La maggior parte di queste tecniche è reale. La maggior parte è anche il posto sbagliato da cui iniziare.

La risposta onesta, dopo aver eseguito questo audit su stack enterprise che bruciano 50K–500K dollari al mese in inferenza, è che le leve si impilano in un ordine specifico. Le prime tre ti danno il 50–80% dei risparmi che la maggior parte dei team può realisticamente catturare. Il resto sono strumenti chirurgici — potenti quando servono, pericolosi se si va a prenderli troppo presto. Questo articolo percorre lo stack, con i numeri e i failure mode che non arrivano nelle pagine marketing.

00Prima di tutto: misurare

Non puoi ottimizzare ciò che non riesci a misurare. Sembra ovvio. Eppure metà degli engagement in cui entriamo non conosce la propria cache-hit rate per route, la distribuzione di lunghezza degli output o il costo unitario per feature. Conoscono il totale mensile e basta.

L'equipaggiamento minimo prima di qualunque altra leva:

• Un layer di tracing su ogni chiamata LLM — Helicone, Langfuse, o Phoenix. Conteggio token in/out, modello usato, cache hit/miss, latenza, tipo di errore.
• Costo suddiviso per route (quale feature utente, quale step agentico), non per giorno. Il costo-per-feature è l'unico numero che ti permette di decidere cosa ottimizzare.
• Un eval set offline su cui rieseguire i prompt dopo ogni modifica. Se non ce l'hai, costruiscilo prima di toccare qualunque altra cosa.

Saltare questo step è il singolo errore più costoso che fanno i team. Abbasserai un numero, ne alzerai un altro in silenzio, e spedirai una regressione di cui scoprirai l'esistenza da un cliente.

01Prompt caching — la leva con il ROI più alto, punto

Anthropic, OpenAI e Google offrono ora tutti il prompt caching a tariffe profondamente scontate. La meccanica è la stessa: quando riusi un prefisso stabile — system prompt, schemi dei tool, few-shot examples, documenti recuperati — su molte chiamate, il provider tokenizza il prefisso una volta e legge dalla cache nelle chiamate successive a una frazione del prezzo input.

L'economia 2026 è netta:

Per Anthropic Claude Sonnet 4.6, le cache read si pagano $0,30 per milione di token contro $3,00 base — un taglio 10× sulla porzione cached di ogni chiamata. Il trade-off è il costo di write: 1,25× sul prezzo base con TTL di 5 minuti, o 2× sul TTL di 1 ora. Quindi il caching ripaga solo quando lo stesso prefisso viene riusato più volte all'interno di quella finestra.

L'unica cosa che conta: l'ordine del prompt

L'errore che vediamo costantemente è team che attivano il caching, vedono la bolletta muoversi appena, e concludono che "non funziona". Funziona. Il loro prompt è strutturato male. La cache combacia sul prefisso. Un singolo valore dinamico (un timestamp, uno user ID, un saluto randomizzato) in testa al prompt invalida l'intera cache per quella chiamata.

La regola: contenuto statico per primo, contenuto dinamico per ultimo. Istruzioni di sistema, schemi tool, persona, regole di formattazione, few-shot — tutto va nel blocco prefisso stabile. Dati per-utente, documenti recuperati specifici per la query, il messaggio reale dell'utente — vanno nella coda variabile.

Un team con cui abbiamo lavorato ha portato la propria cache-hit rate dal 7% al 74% con un singolo esercizio di riordino prompt — nessun cambio architetturale, nessun cambio modello, solo riordino. La bolletta mensile è scesa del 59% il mese successivo. Punta a ≥70% di cache-hit rate sui workload stabili. Sotto il 60%, il tuo prefisso è nel posto sbagliato.

02Structured outputs & la fine dei retry loop

OpenAI Structured Outputs (GA da Ago 2024) e il constrained decoding di Anthropic (Nov 2025) ti permettono di vincolare l'output del modello a uno schema JSON. Il modello non può divagare, non può andare in deriva, non può restituire un JSON semi-rotto su cui il tuo parser deve poi fare retry. Emette esattamente lo schema o nulla.

Qui non c'è una % di risparmio in titolo perché il beneficio è silenzioso: ogni retry loop che facevi prima — "parse fallito, richiediamo, stavolta ritorna davvero un JSON valido" — scompare. Sui workload pesanti in output, parliamo tipicamente del 15–40% della spesa token totale che non sapevi essere retry. Anche la latenza cala, perché gli engine moderni (vLLM, SGLang, TensorRT-LLM) spediscono constrained decoding basato su XGrammar con overhead sotto i 40 microsecondi per token.

Se la tua applicazione fa qualcosa che assomiglia a "estrai questi campi da un documento", "classifica questo in una di queste categorie", oppure "decidi quale tool chiamare", e non stai usando structured output, è la seconda fix più economica della lista.

03Batch API — lo sconto del 50% che quasi nessuno usa

OpenAI, Anthropic, Together, Fireworks e Groq offrono tutti endpoint batch. Sottometti un insieme di richieste indipendenti; i risultati arrivano entro 24 ore; la bolletta è il 50% del prezzo sincrono sia in input sia in output. Anthropic Message Batches gestisce fino a 100.000 richieste per submission.

Per qualunque workload che non richiede una risposta sotto il minuto, il batch è denaro gratis. I workload che si qualificano sono più di quanto la gente creda:

• Eval offline (re-scoring del golden dataset)
• Pipeline di arricchimento documenti (tagging, summarization, generazione embedding)
• Job di classificazione giornaliera (ticket in entrata, lead, content moderation queue)
• Rigenerazione di indici RAG
• Generazione di contenuti catalog-wide
• Summarization post-hoc (call transcript, meeting note processate di notte)

Il pattern: se andrebbe bene che il risultato arrivasse mentre l'utente dorme, appartiene al batch. La maggior parte dei team ha almeno un workload così che gira su endpoint sincroni per pura abitudine. Spostarlo è un progetto da un giorno per il 50% di sconto.

04Model routing — la seconda leva più grande, con un failure mode reale

Non ogni query ha bisogno di un frontier model. Classificazioni di triage, intent detection, lookup semplici, pass di formattazione — tutto questo gira benissimo su un Haiku, un Gemini Flash, un Llama 3.x, o un Mistral. Il compito di un router è classificare la difficoltà della query in entrata e dispatcharla al modello più economico in grado di gestirla, escalando al tier più costoso solo quando quello economico flunka un confidence check.

Il numero in titolo di RouteLLM (UC Berkeley, Anyscale, Canva, ICLR 2025): 85% di riduzione costi su MT Bench al 95% della qualità di GPT-4, chiamando il modello strong solo sul 14% delle query. Verifica prima di festeggiare, però — lo stesso paper mostra che i risparmi calano al 45% su MMLU e al 35% su GSM8K. I guadagni del routing dipendono fortemente dalla tua distribuzione di query. L'aspettativa real-world conservativa è 30–60% di riduzione costi, non 85%.

Altri pattern di produzione documentati: uno split 70/30 Haiku/Opus taglia il costo input di circa il 67%. Uno split 80/20 verso i tier più economici si avvicina al 79%. Nel 2026, circa il 37% delle enterprise gira cinque o più modelli in produzione dietro un router.

E poi c'è DeepSeek V3 / V4 a $0,14 per milione di token input — 18–36× più economico del frontier. Per qualunque workload che non richieda reasoning di frontiera, è il singolo cambio di unit economics più grande dell'ultimo anno. Vale la pena valutarlo prima di assumere che Claude o GPT siano il floor giusto.

05Il loop di sviluppo local-first

Ecco un pattern che vediamo convergere nel 2026, in particolare nei team con cultura ingegneristica forte: modelli locali per l'inner loop di sviluppo, API frontier solo per l'outer loop.

L'argomento è semplice. Uno sviluppatore che itera su un prompt o un agente durante una giornata di lavoro fa forse 200–1.000 chiamate al modello — la maggior parte usa-e-getta. La maggior parte di quelle chiamate sta provando a rispondere a "il mio code path funziona?", non "la qualità dell'output del modello è alta?". Far girare ognuna di queste contro un'API a pagamento significa pagare un prezzo frontier per quello che è di fatto uno unit test. Un server GPU on-prem condiviso — un singolo H100, una coppia di RTX 5090, o un Mac M4 Ultra — che serve un team via Ollama, vLLM o SGLang può assorbire la maggior parte di quel traffico a costo marginale zero.

L'hardware è finalmente pronto. Una configurazione dual RTX 5090 gira DeepSeek-R1 70B quantizzato a circa 27 token/secondo, al 35–45% del costo di un H100. Qwen3-Coder-Next (Feb 2026) raggiunge 58,7% su SWE-bench Verified, gira su una singola GPU da 24GB, e fornisce feedback sotto i 150ms a oltre 1.100 token/secondo su una 5090. I dati di Epoch AI mostrano che capacità frontier di 6–12 mesi prima sono ora eseguibili su una singola GPU consumer.

Il framing giusto, però, è più stretto di "locale per dev". Abbiamo visto team over-committarsi a questo e bruciare settimane. Lo scope onesto:

• Locale funziona per: il coding loop (Continue.dev + Ollama per autocompletamento, suggerimenti di refactor, run agentici throwaway nell'IDE); iterazione offline su bozze di prompt prima che arrivino a un eval reale; prototipazione privacy-sensitive su dati cliente che non possono uscire dalla rete; judge pass offline su golden dataset.
• Locale NON funziona per: prompt engineering finale contro il modello di produzione. Un prompt tunato su Qwen non si trasferirà pulitamente a Claude o GPT — tokenizer diversi, profili di instruction-following diversi, discipline di tool-use diverse. Tool calling, affidabilità degli structured output e recall su long context favoriscono ancora in modo significativo i modelli frontier.

C'è anche un inverso che vale la pena conoscere: il case study pubblicato di Arize va nell'altra direzione — prototipa il prompt contro Claude Sonnet, poi distilla / migra il prompt stabilizzato a Llama 3.2 3B per la produzione. Il loro risultato: costo per inferenza sceso da $0,44 a effettivamente zero, latenza migliorata del 16–25%. La chiave è che hanno fatto 84 eval per modello candidato su un golden set di 14 conversazioni prima di switchare. Il pattern è "prototipa grande, spedisci piccolo", non "prototipa piccolo, spera grande".

Il modello operativo difendibile, quindi: locale per l'inner loop (sviluppatori che scrivono, autocompletano, esplorano), frontier per l'outer loop (eval, CI di regressione, traffico di produzione). Una volta che un workload è stabile, valuta se un modello locale più piccolo distillato o fine-tunato possa prendere in carico quel path di produzione. Due ottimizzazioni distinte — non confonderle.

Consenso tooling (metà 2026)

• Ollama — iterazione individuale dello sviluppatore su laptop o workstation condivisa. Semplice, batterie incluse, single-user.
• vLLM — server on-prem condiviso, più sviluppatori, ampio supporto hardware, continuous batching, paged attention.
• SGLang — stessa nicchia di vLLM, attualmente vincente su conversazioni multi-turno e workload con structured output. Deployment xAI, NVIDIA e Azure lo stanno adottando per produzione. Vale la pena valutarlo accanto a vLLM.
• LM Studio — accesso non-ingegneristico; utile quando product manager o analisti vogliono far girare un modello locale senza command line.
• Continue.dev — integrazione IDE (VS Code, JetBrains) puntata su una qualunque delle opzioni sopra. Chiude il loop dal modello locale al workflow dello sviluppatore.

06Semantic caching — utile, ma venduto male

Il semantic caching sembra il cugino più furbo del prompt caching: invece di combaciare sul prefisso esatto, embedda la query in entrata, cerca risposte cached in cui l'embedding è entro una qualche soglia di similarità coseno, e restituisce la risposta memorizzata se trovata. Tool: GPTCache, Portkey, Helicone, Redis Vector.

Su un workload a query stabili — un FAQ bot di customer support, lookup strutturati — i case study pubblicati mostrano fino al 73% di riduzione costi. Sul workload sbagliato, è la tecnica più pericolosa di questa lista.

Usalo per domini stretti, stabili, ad alto volume. Saltalo per code generation, reasoning, o qualunque cosa dove due prompt semanticamente vicini possano avere output corretti significativamente diversi.

07Prompt compression & fix chirurgici

Quando il context è già saturo e il caching non aiuta (perché ogni chiamata ha contenuto diverso), la compressione del prompt diventa utile. LLMLingua e LLMLingua-2 rimuovono algoritmicamente token a bassa informazione; LongLLMLingua è tunato per workload RAG.

Benchmark pubblicati: una compressione 2–3× porta a ~80% di riduzione costi con un calo di accuratezza sotto il 5% sulla maggior parte dei task NLP; una compressione aggressiva 5–7× tocca l'85–90% di risparmio al prezzo di una regressione 5–15% sull'accuratezza. LongLLMLingua avrebbe migliorato la qualità RAG del 17–21% tagliando i token 4×.

I due trade-off da sapere: codice, matematica, e reasoning legale/contrattuale sono domini in cui ogni token porta peso semantico — la compressione fa male più velocemente di quanto aiuti. E la compressione può combattere il prompt caching: se l'output del compressor non è deterministico, distruggi il prefisso cache a ogni chiamata. Scegli una o l'altra sullo stesso workload, non entrambe.

08Fine-tuning & distillation — per ultimo, non per primo

Fine-tunare un modello open-weight più piccolo sul tuo task specifico, o distillare da un teacher frontier in uno student più piccolo, è l'ottimizzazione con leva più alta per un workload noto, stabile, ad alto volume. Oxide AI ha riportato 95% di accuratezza sul task e 37% di latenza in meno da un Llama tunato in LoRA contro GPT-4 sul loro problema specifico. Una coppia teacher/student (GPT-5 distillato in un Llama o Mistral) può consegnare qualità vicina al teacher a circa 10× costo unitario inferiore su task stretti.

Il motivo per cui è ultimo nella lista: è il più costoso da mantenere. Servono ≥500 esempi etichettati di alta qualità. Serve una eval pipeline che catturi le regressioni. Se la specifica del task sottostante cambia ogni trimestre, ti ritrovi a riallenare costantemente. E se il reasoning del modello frontier sta facendo il vero lavoro, la distillation collasserà silenziosamente sui casi limite.

Fai fine-tuning solo su workload stabili, ad alto volume e stretti. Se il workload soddisfa due su tre, conviene di più ottimizzare prompt + cache + route. Se solo una, lascia perdere.

09L'ordine onesto in cui farle

Se prendi una sola cosa da questo articolo, prendi questa sequenza. Abbiamo visto abbastanza engagement da essere sicuri che sia l'ordine che minimizza il rimpianto per dollaro speso.

1. Settimana 1 — Misurare. Helicone o Langfuse su ogni chiamata. Cache-hit rate, costo per route, latenza p50/p95, distribuzione lunghezza output. Costruisci l'eval set offline.
2. Settimana 2 — Prompt caching. Ristruttura i prompt: contenuto statico per primo, dinamico per ultimo. Punta a ≥70% di cache-hit rate. Aspettati 40–75% di riduzione costi sui workload stabili. Si ripaga prima della fine dello sprint.
3. Settimana 2 — Structured outputs. Schema-enforce ogni output possibile. Uccidi i retry loop.
4. Settimana 3 — Batch API. Sposta su batch ogni workload che non richiede una risposta sotto il minuto. 50% di sconto, immediato.
5. Settimane 4–6 — Model routing. Parti conservativo. Haiku / Flash per classificazione e triage; frontier per reasoning. Obbligatorio: judge sampling sulle decisioni di routing dal giorno uno.
6. Settimane 4–6, in parallelo — Loop di dev local-first. Tira su un endpoint Ollama o vLLM condiviso. Continue.dev per l'integrazione IDE. Taglia il 50–80% della spesa API in dev-time con zero rischio di produzione, a patto che le eval finali girino contro il modello di produzione.
7. Mese 3 — Semantic caching, solo scope ristretti. Workload tipo FAQ con campionamento di falsi positivi obbligatorio.
8. Mese 3 — Prompt compression, chirurgica. Dove il caching non aiuta e il context è gonfio.
9. Mese 4+ — Fine-tune / distilla i top uno-tre workload per spesa token. Solo dopo averli identificati tramite la strumentazione del punto 1.

Le tecniche che la maggior parte dei team afferra per prime — routing, fine-tuning, semantic caching — hanno il rapporto più alto "fa figura in un blog post / ROI reale più basso senza misurazione preventiva". Sono tecniche reali. Non sono le prime.

10Gli anti-pattern a cui fare attenzione

Alcuni pattern che vediamo abbastanza spesso da segnalare:

• Routing senza judge sampling → collasso silenzioso di qualità. Il singolo errore più costoso nello stack di routing.
• Semantic caching aggressivo senza monitoraggio dei falsi positivi → risposte sbagliate con confidenza indistinguibili da inferenze fresche. Documentati tassi di falso positivo del 95%+ in natura.
• TTL cache di 1 ora quando il traffico si rinfresca ogni 5 minuti → paghi il moltiplicatore 2× sulla write per zero beneficio. Combina il TTL al pattern di traffico reale.
• Comprimere prompt in modi che rompono il prefisso cache → le due ottimizzazioni si cancellano, spesso netto negativo.
• Costruire layer di routing o caching su una baseline non misurata → non puoi dire se ha funzionato, e disferai qualcosa di buono inseguendo qualcosa di neutro.
• Ottimizzare il costo unitario di un workload che non dovrebbe esistere. La singola maggior fonte di overspend sugli account da $50K+/mese che auditiamo non è inefficienza unit-cost — sono workload che non producono valore di business. Prima di tagliare il costo di una chiamata, decidi se la chiamata appartiene al prodotto.

Quest'ultima è la verità non glamour. L'ottimizzazione dei token è ingegneria. I dollari risparmiati rimuovendo un workload di cui i tuoi clienti non si accorgevano nemmeno sono più grandi dei dollari risparmiati da ogni tecnica sopra messa insieme.