Miglior LLM per caso d'uso (2026): matrice dei costi per chat, RAG e agenti

TL;DR: Non esiste un unico LLM “migliore”: la scelta cambia a seconda che si debba mettere in produzione un chatbot, un’API RAG o batch oppure un agente AI. Ogni workload ha una diversa struttura del prompt, percentuale di cache hit, compatibilità con il TTL e tolleranza alla latenza. Di conseguenza, cambia anche la combinazione ottimale tra modello e strategia di caching. Questa guida parte dai dati misurati nella Parte 3: stesso gateway, stesso SDK OpenAI, basta cambiare il campo model a ogni chiamata.

Serie: Parte 4 di 5 · In precedenza: Parte 1 — Principi del caching · Parte 2 — Confronto e valutazione dei provider · Parte 3 — Tutorial con codice funzionante · Prossimo articolo: Parte 5 — Integrazione con LangChain

0. La formula universale dei costi

Prima di passare ai casi d’uso, ecco l’equazione da ottimizzare per ogni scelta:

per-call cost = (input_uncached × P_in)
              + (input_cached   × P_in × cache_discount)
              + (output × P_out)

per-call TTFT ≈ prefill_time × (1 - hit_rate)
              + decode_time

Ci sono quattro leve:

1. Ridurre il prezzo unitario (P_in / P_out) → scegliere un modello più economico.
2. Aumentare la percentuale di hit → ristrutturare il prompt e adattare il TTL alla frequenza del traffico.
3. Ridurre il coefficiente di sconto della cache → scegliere un provider con un caching più conveniente.
4. Scegliere un provider con il prefill da cache più veloce → la latenza incide sulla UX.

I casi d’uso seguenti agiscono su queste leve in modi diversi.

Caso d’uso 1: chatbot, assistenza clienti e assistenti

Profilo del traffico

• Ogni richiesta = system prompt lungo (persona + conoscenze + regole) + cronologia multi-turn + nuovo messaggio dell’utente.
• Contesto medio: 4K-20K token.
• Gli utenti sono molto sensibili al time-to-first-token (>2 s dà l’impressione che il sistema non funzioni).
• All’interno di una sessione, le richieste arrivano a distanza di secondi o minuti, quindi ampiamente entro il TTL della cache di qualsiasi provider.

Perché la chat si presta naturalmente al caching

La chat è il workload più adatto alla cache. All’interno della stessa sessione:

Request 1: [system: 8K] + [history: 0]   + [user: Q1]
Request 2: [system: 8K] + [history: 200] + [user: Q2]
Request 3: [system: 8K] + [history: 400] + [user: Q3]
           ↑──────── prefix is monotonically growing ────────↑

Se l’intervallo tra i messaggi resta inferiore al TTL, che per tutti i provider è di qualche minuto, la parte del system prompt supera il 90% di hit senza interventi particolari. Non servono keep-alive.

Modelli consigliati (misurazioni del 2026-05)

* Misurato con un system prompt stabile di 7.300 token, in una singola esecuzione sequenziale e senza carico concorrente. La tabella completa è nella Parte 3 §6.

Codice minimo per la produzione

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/v1",
)

def chat(history: list, user_msg: str):
    return client.chat.completions.create(
        model="gpt-5.4-mini",
        max_tokens=512,
        messages=[
            {"role": "system", "content": STABLE_SYSTEM_PROMPT},   # front
            *history,                                              # middle
            {"role": "user", "content": user_msg},                 # back
        ],
    )

Non serve altro. Il caching è automatico per tutti i modelli elencati sopra e non richiede marker. Durante lo sviluppo, controllare resp.usage.prompt_tokens_details.cached_tokens per verificare le hit.

Errori comuni nei chatbot

• ❌ Non inserire il timestamp corrente nel system prompt ("Today is 2026-05-25 14:30:25"). La precisione al secondo invalida la cache a ogni chiamata.
• ❌ Non ricostruire la cronologia a ogni turno: mantenere l’ordine dell’array di messaggi identico byte per byte e aggiungere soltanto nuovi elementi.
• ✅ Inserire i dati sulla persona dell’utente nel primo messaggio user, non nel system prompt. In questo modo le variazioni tra utenti non invalidano il prefisso condiviso.
• ✅ Se una sessione resta inattiva oltre il TTL, inviare un ping keep-alive da 1 token (vedere Parte 3 §8.2) prima dell’arrivo del messaggio successivo.

Caso d’uso 2: workload API (RAG, generazione di contenuti, elaborazione batch)

Profilo del traffico

• Domande e risposte RAG: input = system stabile + documenti recuperati variabili + query variabile.
• Generazione di contenuti (testi di marketing, codice, traduzione): template stabile, dati variabili.
• Elaborazione batch (classificazione di documenti, pulizia dei dati): stesso task ad alto volume.
• La latenza è secondaria; domina il costo per chiamata.

Il problema principale: il retrieval riordina il prefisso

Il problema centrale del caching nei sistemi RAG è che i documenti recuperati cambiano tra una chiamata e l’altra, interrompendo la corrispondenza del prefisso a metà prompt.

Request 1: [system: 3K] + [doc_A, doc_B, doc_C] + [user: Q1]
Request 2: [system: 3K] + [doc_B, doc_D, doc_A] + [user: Q2]
           ↑─ hits ─────↑  ↑──── miss ─────────↑

Ci sono tre soluzioni, in ordine di complessità crescente:

Soluzione A: Mettere i documenti recuperati in fondo, non all’inizio.

messages = [
    {"role": "system", "content": SYSTEM_PROMPT},          # ~3K, stable
    {"role": "system", "content": INSTRUCTION_TEMPLATE},   # ~500, stable
    {"role": "user",   "content": f"References:\n{retrieved_docs}\n\nQuestion: {q}"},
]

Risultato: tutta la parte system, circa 3,5K token stabili, finisce in cache. Solo la parte rivolta all’utente genera un miss a ogni chiamata. Per la maggior parte dei sistemi RAG in produzione è sufficiente. Con questo schema e gpt-5.4-mini, abbiamo misurato una percentuale di hit superiore all’80% sui token di sistema.

Soluzione B: Ordinamento deterministico dei risultati del retrieval. Ordinare i chunk recuperati usando una chiave stabile (doc_id crescente), invece del punteggio di rilevanza. I chunk più frequenti restano in posizioni coerenti e il prefisso coincide più spesso. Il ranker perde leggermente in accuratezza, ma di solito l’effetto è trascurabile.

Soluzione C: Marker nativi per la cache esplicita tramite gli SDK diretti dei vendor. Usando Anthropic Claude direttamente, senza passare da questo gateway, lo schema con più cache_control permette di impostare breakpoint separati per le parti che “non cambiano mai”, “cambiano raramente” e “cambiano a ogni task”. È una soluzione molto efficace per sistemi RAG complessi, se si può gestire un SDK aggiuntivo.

Considerazioni sul TTL per i workload API

• Traffico continuo (endpoint RAG attivo 24/7): un TTL di 5 minuti è sufficiente, perché arriva sempre una nuova richiesta entro la finestra.
• Traffico a picchi / cron (batch giornaliero alle 09:00): usare un provider con TTL lungo (deepseek-v4-flash è quello più persistente tra quelli testati) oppure eseguire un keep-alive da 1 token ogni TTL/2 durante la finestra di elaborazione. Lo schema è descritto nella Parte 3 §8.2.

Modelli consigliati per task

† I marker multipli cache_control di Claude non hanno rivali per i sistemi RAG a più livelli. Usare l’SDK anthropic configurato verso il gateway; vedere Parte 3 §2.

Stima dei costi RAG (100.000 query al giorno)

3K token di system prompt + 5K token di documenti recuperati + query da 200 token + output da 300 token. I valori sono ricavati proporzionalmente dai costi per singola chiamata misurati nella Parte 3 §6, con un solo tenant e senza carico concorrente. Per stimare il proprio workload, usare il calcolatore dei costi LLM e verificare le tariffe correnti nel confronto dei prezzi dei modelli.

Sono stime dell’ordine di grandezza. In produzione ci sono chiamate concorrenti e picchi di traffico, mentre la distribuzione della lunghezza dei documenti recuperati incide più di ogni altro fattore.

Errori comuni nei sistemi RAG / API

• ❌ Non ordinare i chunk recuperati in base a un punteggio di rilevanza dinamico: ogni richiesta produrrebbe un prefisso diverso.
• ❌ Non scartare i log di utilizzo durante lo streaming, altrimenti non sarà possibile attribuire correttamente i costi. Passare stream_options={"include_usage": True} e salvare prompt_tokens_details.cached_tokens e usage.cost.
• ✅ Nei task batch, combinare le Batch API dei vendor (OpenAI Batch, Anthropic Message Batches) con il caching per ottenere un ulteriore risparmio di circa il 50%. Questa operazione va eseguita fuori dal gateway, chiamando direttamente il provider.

Caso d’uso 3: agenti AI (reasoning multi-step, uso di tool, catene lunghe)

Profilo del traffico

• Un task agentico richiede molte chiamate LLM, intervallate dai risultati dei tool.
• Contesto molto lungo (system + tool + cronologia accumulata): in genere 30K-100K token entro il decimo passaggio.
• Prompt molto strutturati: prefisso lungo e stabile, coda variabile ridotta.
• Contano sia la latenza sia i costi: ogni secondo aggiuntivo di prefill aumenta l’attesa percepita e, in un agente da 15 passaggi, viene moltiplicato per 15.

Perché gli agenti dipendono dal caching

Ogni passaggio aggiunge la chiamata al tool e il relativo risultato a quelli del passaggio precedente. Senza caching, a ogni step si ripaga il prefill di decine di migliaia di token.

Step 1: [system: 5K] + [tools: 3K]
Step 2: [system: 5K] + [tools: 3K] + [call_1: 1K] + [result_1: 2K]
Step 3: [system: 5K] + [tools: 3K] + [call_1: 1K] + [result_1: 2K]
                                   + [call_2: 1K] + [result_2: 5K]
        ↑──── prefix grows monotonically — perfect for caching ────↑

Regola fondamentale: le chiamate ai tool e i loro risultati devono essere solo aggiunti e restare identici byte per byte tra uno step e l’altro. Qualsiasi riscrittura o riordinamento invalida la cache da quel punto in poi. L’errore più comune negli agenti è “ho ripulito il risultato del tool prima di reinviarlo”: la percentuale di hit scende a zero e costi e latenza si moltiplicano.

Compatibilità con il TTL: l’unico caso d’uso in cui è decisiva

Un task agentico tipico dura 10-60 secondi; all’interno del singolo task, il TTL predefinito di 5 minuti è sufficiente. Gli agenti che attendono un’approvazione umana, ad esempio “rivedi questo piano e rispondi”, possono però restare inattivi per diversi minuti. Se l’utente impiega 10 minuti e la cache scade, lo step successivo ripaga il prefill di 50K token. Per questi workflow:

• Usare un provider con un TTL più lungo (deepseek-v4-flash è quello più persistente tra quelli testati), oppure
• Inviare un ping keep-alive ogni TTL/2 durante l’attesa (vedere Parte 3 §8.2).

Modelli consigliati per gli agenti

Gli agenti richiedono buone capacità di reasoning: scegliere prima in base alla qualità, poi ottimizzare i costi.

† Lo schema di Claude con 4 marker cache_control resta la configurazione più efficace per il caching degli agenti, grazie allo sconto cumulativo sul prefisso lungo oltre 10 step. Usare l’SDK anthropic configurato verso il gateway. La struttura esatta del payload e le opzioni TTL sono nella Parte 3 §2.

Stima dei costi reali: un task agentico da 15 step

Ipotesi: 5K token di system prompt + 3K token di tool + circa 3K token aggiunti per step, per un totale di 15 step. Il costo per chiamata della Parte 3 §6 è stato adattato a questo schema agentico:

Anche in questo caso sono stime. La variabile principale è la capacità di mantenere il prefisso identico byte per byte da uno step all’altro.

Errori comuni negli agenti

• ❌ Non ricostruire la lista dei messaggi a ogni step: mantenere l’array identico byte per byte e aggiungere soltanto nuovi elementi.
• ❌ Non accorciare o riformattare i risultati dei tool: qualsiasi modifica a livello di byte invalida la cache successiva.
• ❌ Non condividere una cache key tra istanze concorrenti dello stesso agente: l’ordine degli step diverge e le istanze si contaminano a vicenda.
• ✅ Monitorare il rapporto cache_creation_tokens : cache_read_tokens per task: entro il decimo step, un rapporto sano è 1:50 o migliore.

Matrice decisionale completa

                            ┌─ Chinese-heavy ─→ deepseek-v4-flash + auto cache
                  ┌─ High ─→│
                  │          └─ Global users ──→ gpt-5.4-nano / claude-haiku-4-5
   Chatbot ──────→│
                  │          ┌─ Quality-first ─→ gpt-5.4-mini / claude-sonnet-4-5
                  └─ Mid ──→│
                            └─ Balanced ──────→ gemini-2.5-flash / qwen3-max

                            ┌─ Chinese RAG ───→ deepseek-v4-flash / qwen3-max
                  ┌─ Live ─→│
                  │          └─ English RAG ───→ gpt-5.4-mini / claude-sonnet-4-5†
   API ──────────→│
                  │          ┌─ Translation ───→ gpt-5.4-nano (template caches)
                  └─ Batch →│
                            └─ Doc review ────→ qwen3.5-flash + Batch APIs

                            ┌─ Simple ────────→ deepseek-v4-flash / qwen3-max
                  ┌─ China ─→│
                  │          └─ Complex ───────→ qwen3-max (plan) + deepseek (execute)
   Agent ────────→│
                  │          ┌─ Simple ────────→ gpt-5.4-mini + auto
                  └─ Global →│
                            └─ Complex ───────→ claude-sonnet-4-5† / gpt-5.5-pro

  † Claude with multi-`cache_control` breakpoints via the `anthropic` SDK pointed at the gateway (see Part 3 §2)

Riferimento rapido del TTL per caso d’uso

Cosa fa e cosa non fa questo gateway

Per chiarire cosa aspettarsi:

Se serve una delle funzionalità nella colonna di destra, va implementata nel livello applicativo oppure usando direttamente l’SDK del vendor. Il gateway è un proxy leggero con un livello di pricing; tutto ciò che riguarda il caching avviene a monte, nel livello del modello.

Conclusioni

L’intera serie si riassume in quattro righe:

Il caching offre due vantaggi, non uno. Costi E latenza. Contenuti stabili all’inizio, contenuti variabili alla fine. Gestire bene il prefisso non costa nulla: va fatto sempre. Adattare modello e comportamento della cache al caso d’uso. Chat ≠ RAG ≠ agenti. Misurare sul proprio traffico. I benchmark su una singola esecuzione sono un punto di partenza, non una risposta definitiva.

Il percorso più rapido è scegliere nella matrice il caso d’uso più vicino al proprio, applicare le modifiche strutturali (prefisso stabile all’inizio, retrieval deterministico, stato dell’agente identico byte per byte), registrare cached_tokens e usage.cost per una settimana, quindi rivalutare.

FAQ

Qual è l’LLM più economico per un chatbot in lingua cinese? Nel nostro set di test, deepseek-v4-flash e qwen3.5-flash costano un ordine di grandezza meno dei modelli ottimizzati per l’inglese sui testi in cinese, mantenendo una qualità paragonabile a gpt-5.4-mini nei normali workload di chat.

Qual è il miglior LLM per RAG nel 2026? Per l’inglese, gpt-5.4-mini con il layout della soluzione A, cioè token di sistema all’inizio e riferimenti in fondo, supera l’80% di hit sulla parte stabile. Per il cinese, deepseek-v4-flash. Per documenti molto lunghi interrogati spesso, gemini-2.5-pro, che gestisce nativamente contesti da oltre 1M token.

È meglio usare GPT o Claude per gli agenti? Entrambi sono validi; la scelta dipende dall’impegno che si vuole dedicare alla gestione della cache. Lo schema di Claude con 4 marker cache_control, tramite l’SDK anthropic configurato verso il gateway, è particolarmente efficace per i prefissi cumulativi degli agenti: dopo il warm-up del prefisso riduce di circa il 90% i costi di input su oltre 10 step. Per restare sul client compatibile con OpenAI e accettare un risparmio da cache di circa il 50% senza marker, gpt-5.4-mini o gpt-5.5-pro richiedono meno lavoro.

Quanto si può risparmiare davvero passando da un utilizzo “ingenuo” a uno ottimizzato degli LLM? Nelle esecuzioni misurate in questa serie: riduzione dei costi del 50-88% e riduzione del TTFT del 30-60% a parità di modello. La maggior parte del risparmio deriva dal portare la percentuale di hit oltre l’80%, non dalla scelta di un modello diverso.

Da dove conviene iniziare? Scegliere nella matrice il caso d’uso più vicino al proprio. Applicare le modifiche strutturali al prompt. Misurare cached_tokens e usage.cost su una settimana di traffico in produzione. Solo a quel punto valutare un cambio di modello.

Come si confrontano i prezzi delle API LLM tra provider? La pagina dei modelli di Synthorai offre un confronto dei prezzi aggiornato: si può filtrare per provider e ordinare per prezzo di input o output per milione di token, sempre in linea con i prezzi effettivi del gateway. La matrice precedente indica il tipo di modello adatto al caso d’uso; la pagina dei modelli mostra quanto costa oggi.

Fonti e verifiche: dati misurati dalla Parte 3 §6, https://synthorai.io/v1 in data 2026-05-25, SDK openai 2.38.0. Pagine dei prezzi dei vendor: OpenAI · Anthropic · Google Gemini · DeepSeek · Alibaba Bailian.

← Torna al blog