Ottimizzazione dei costi dell'IA — la guida completa per ridurre del 70-90% la spesa per gli LLM

Cinque tecniche si sommano. Ognuna riduce una parte diversa della fattura — combinandone realisticamente tre si arriva al 70% di riduzione senza alcuna perdita di qualità; usandole tutte e cinque ci si avvicina all'85-90%. Questa guida presenta il menu completo, con risparmi misurati e codice eseguibile per ogni tecnica. Ogni tecnica rimanda a un approfondimento dedicato in fondo.

Le cinque tecniche, classificate per ROI

1. Prompt caching — di gran lunga la tecnica con il ROI più alto

Se il tuo system prompt supera i 1.000 token e chiami lo stesso prompt più di due volte in una finestra di 5 minuti, il prompt caching è denaro gratis. Anthropic addebita l'input memorizzato nella cache a 10% della tariffa dell'input (2,5% su Claude Fable 5.1, 5% su Claude Opus 5.5); OpenAI applica automaticamente l'equivalente a 10%. Basta aggiungere un campo:

# Prompt caching: 1 extra field = 10% rate on cached input
resp = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=600,
    system=[{
        "type": "text",
        "text": LONG_SYSTEM_PROMPT,
        "cache_control": {"type": "ephemeral"},   # cache this part
    }],
    messages=[{"role": "user", "content": question}],
)

Risparmio realistico: 60-90% del costo dell'input se il tuo system prompt è grande e stabile. Controlla la dashboard /app/usage — se cache_read_input_tokens è 0, hai 30 minuti di lavoro davanti a te che ripagheranno per sempre. Approfondimento.

2. Suddivisione per livello del modello — usa il modello più economico che sia abbastanza valido

Claude Haiku 4.5 costa circa il 10% di Claude Opus 4.7. Per classificazione, formattazione, decisioni di routing e riepiloghi semplici — Haiku è più che sufficiente. Riserva Opus alle chiamate che richiedono un ragionamento davvero complesso.

# Pick the cheapest model that's still good enough for the task.
# Escalate by difficulty: cheap (Haiku 4.5 / GPT-5.6 Terra) -> Sonnet 5 -> Opus 4.7
def pick_model(difficulty: int) -> str:
    if difficulty <= 2: return "claude-haiku-4-5"     # ~10x cheaper than Opus
    if difficulty <= 4: return "gpt-5-6-terra"        # a second family, cheap output
    if difficulty <= 7: return "claude-sonnet-5"
    return "claude-opus-4-7"

Come costruire la decisione di suddivisione: prima un classificatore leggero (anche Haiku può farlo in 100 token di input), poi il routing. Misura la qualità dell'output con eval tenute da parte. Non lasciare che scelga l'intuizione — esegui benchmark.

• Livello 0 (Haiku 4.5): classificazione, estrazione, traduzione, riepilogo di input <2K — centesimi per chiamata
• Livello 1 (GPT-5.6 Terra): riepiloghi più lunghi, completamento del codice, uso semplice degli strumenti — anch'esso a centesimi, ma migliore sui contesti lunghi
• Livello 2 (Sonnet 5): ragionamento reale, agenti multi-step, attività di visione — il cavallo di battaglia della produzione
• Livello 3 (Opus 4.7): solo quando hai verificato che Sonnet non riesce a farlo correttamente

3. Limiti dell'output — limita ciò che generano, non solo ciò che leggono

I token di output sono in genere 4-5 volte più costosi dell'input. Un valore predefinito max_tokens=4096 troppo permissivo invita il modello a divagare. Imposta limiti aggressivi e usa sequenze di arresto per interrompere al marcatore corretto:

# Two-layer caps: per-call max_tokens + per-key wallet cap
client.chat.completions.create(
    model="claude-sonnet-5",
    messages=[...],
    max_tokens=800,             # cap each call
    stop=["</answer>"],         # cut at terminator
)
# /app/keys → set "Spending limit" per key:
#   Production: $50/day · Experiment: $5/day · CI: $1/day

Abbina il max_tokens per chiamata a un limite di spesa del wallet per chiave in /app/keys — un ciclo incontrollato o un bug non può superare il tuo tetto giornaliero. Due livelli, entrambi importanti.

4. Parallelismo — per carichi di lavoro strutturati in batch

Se elabori 1.000 elementi indipendenti (classificando feedback, valutando lead, generando descrizioni), le chiamate seriali richiedono un'ora. L'elaborazione asincrona con AsyncOpenAI e un limite di concorrenza permette di completare il lavoro in meno di un minuto — e timeout più stretti consentono alle chiamate di fallire rapidamente quando i servizi upstream sono lenti. Il parallelismo non riduce il costo per token, ma abilita pattern architetturali (elaborazione idempotente, budget di retry più stretti) che lo riducono.

5. Igiene dei retry — non pagare retry incontrollati

Il codice ingenuo riprova a ogni errore, inclusi i 400. Significa pagare per i fallimenti (le richieste 4xx su Kunavo non sono fatturate, ma consumano comunque il budget di rate limit e il tempo di esecuzione). Politica corretta: riprovare solo 408/429/5xx, exponential backoff con jitter, massimo 5 tentativi e 30 secondi di attesa totale. Per tutto il resto, interrompere subito e mostrare l'errore.

Come si presenta il risparmio nella pratica

Risparmi realistici misurati su un SaaS che utilizza Kunavo con una spesa di $5.000/mese:

• Prompt caching aggiunto: $2.000 risparmiati (−40%)
• Suddivisione Haiku per la classificazione: $800 risparmiati (−16%)
• max_tokens più stretto: $400 risparmiati (−8%)
• Totale: $3.200/mese risparmiati, $1.800 spesi (−64% complessivo)

Questi risparmi si sommano — ogni tecnica successiva agisce sulla base già ridotta. Senza applicare prima il caching, le altre fanno risparmiare meno. L'ordine conta: inizia da #1, poi #2, quindi #3.

Cosa non funziona come pubblicizzato

• "Embedding per tutto" — gli embedding fanno risparmiare sulla ricerca testuale, non sulla generazione. Sono economici, ma non riducono il costo delle chiamate LLM
• "Fine-tuning locale per risparmiare" — giustificabile solo se elabori oltre 10M di token al giorno per un'attività ristretta. Per la maggior parte dei team, prompt caching + suddivisione Haiku è preferibile alla complessità operativa dell'hosting autonomo
• "Aggregator più economici" — Kunavo offre già la maggior parte dei modelli a prezzi inferiori alla tariffa ufficiale del provider. Gli aggregator più economici di solito vincono sostituendo silenziosamente il modello richiesto con uno più economico

Prossimi passi

Applica prima il caching — è il ROI più alto per ora investita. Poi analizza la suddivisione della dashboard /app/usage per modello e livello. Quindi crea i livelli. Tieni traccia del costo mensile per utente attivo come metrica principale — se rimane stabile o diminuisce mentre il coinvolgimento cresce, stai ottenendo buoni risultati.

Domande frequenti