Miglior LLM per Chat, RAG e Agenti: Matrice Decisionale Modello + Costi 2026

TL;DR — Scegliere il modello LLM “migliore” non è una questione da singolo benchmark: dipende da cosa stai costruendo, che sia un chatbot, un’API RAG/batch o un agente AI. Ogni forma ha una struttura di prompt diversa, un profilo di hit-rate diverso, un TTL diverso e una diversa tolleranza alla latenza, e questo impone un abbinamento ottimale diverso tra modello e strategia di caching. Questa guida parte dai numeri misurati nella Parte 3: stesso gateway, stesso OpenAI SDK, basta cambiare il campo model a ogni chiamata.

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

0. La formula universale del costo

Prima di entrare nei casi d’uso, ecco l’equazione che ogni scelta dovrebbe ottimizzare:

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

Quattro leve:

1. Abbassa il prezzo unitario (P_in / P_out) → scegli un modello più economico.
2. Aumenta l’hit rate → ristruttura il prompt; adatta il TTL alla cadenza del tuo traffico.
3. Abbassa il coefficiente di sconto della cache → scegli un provider con un caching più aggressivo.
4. Scegli il provider con il prefill in cache più veloce → la latenza conta per la UX.

Ogni caso d’uso qui sotto tira queste leve in modo diverso.

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

Profilo di traffico

• Ogni richiesta = system prompt lungo (persona + conoscenza + regole) + cronologia multi-turno + nuovo messaggio utente.
• Contesto medio: 4K–20K token.
• Gli utenti sono estremamente sensibili al time-to-first-token (>2 s dà l’impressione che qualcosa sia rotto).
• All’interno di una sessione le richieste arrivano a distanza di secondi o minuti, ben dentro il TTL della cache di qualsiasi provider.

Perché la chat si mette in cache quasi da sola

La chat è il carico più adatto al caching. Nel corso di una singola 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 le pause tra un messaggio e l’altro restano sotto il TTL (pochi minuti presso ogni provider), la parte del system prompt supera il 90% di hit rate senza alcuno sforzo. Non servono keep-alive.

Modelli consigliati (misurato 2026-05)

* Misurato su un system prompt stabile di 7.300 token, singola esecuzione sequenziale, senza carico concorrente. Vedi la Parte 3 §6 per la tabella completa.

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
        ],
    )

Tutto qui. Il caching è automatico per ogni modello elencato sopra e non serve alcun marker. Durante lo sviluppo, leggi resp.usage.prompt_tokens_details.cached_tokens per verificare gli hit.

Errori comuni con i chatbot

• ❌ Non inserire il timestamp corrente nel system prompt ("Today is 2026-05-25 14:30:25"). La precisione al secondo invalida ogni cache.
• ❌ Non ricostruire la history a ogni turno: mantieni l’ordinamento dell’array di messaggi byte per byte e limitati ad aggiungere in coda.
• ✅ Metti i dati della persona utente nel primo messaggio utente, non nel system prompt. Così la variazione per utente non contamina il prefisso condiviso.
• ✅ Per le sessioni che si raffreddano oltre il TTL, invia un ping keep-alive da 1 token (vedi Part 3 §8.2) prima che arrivi il messaggio successivo dell’utente.

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

Profilo di traffico

• Q&A con RAG: input = system stabile + documenti recuperati variabili + query variabile.
• Generazione di contenuti (testi marketing, codice, traduzioni): template stabile, dati variabili.
• Batch processing (classificazione documenti, pulizia dati): stesso task in grande volume.
• La latenza è secondaria; domina il costo per chiamata.

Il problema difficile: il retrieval riordina il tuo prefisso

Il problema centrale del caching nel RAG: i documenti recuperati cambiano tra una chiamata e l’altra e spezzano il prefisso a metà del 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 ─────────↑

Tre soluzioni, in ordine di complessità crescente:

Soluzione A — Sposta i documenti recuperati in coda, non in testa.

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: l’intera parte system (i ~3,5K token stabili) va in cache. A ogni chiamata manca solo la parte rivolta all’utente. Per la maggior parte dei RAG in produzione basta questo. Hit rate misurato su questo pattern con gpt-5.4-mini: oltre l’80% sui token di system.

Soluzione B — Ordinamento deterministico del retrieval. Ordina i chunk recuperati per una chiave stabile (doc_id crescente) invece che per punteggio di rilevanza. I chunk ad alta frequenza restano in posizioni costanti e il prefisso combacia più spesso. Costa un piccolo calo di accuratezza sul ranker, di solito irrilevante.

Soluzione C — Marker di cache espliciti nativi tramite gli SDK dei vendor. Se usi Anthropic Claude direttamente (non tramite questo gateway), il pattern con più cache_control ti permette di mettere in cache “non cambia mai” + “cambia raramente” + “cambia per task” come breakpoint separati. Ottimo per RAG complessi, quando puoi permetterti un SDK aggiuntivo.

Considerazioni sul TTL per i workload API

• Traffico continuo (endpoint RAG 24/7): i TTL di 5 minuti vanno benissimo, c’è sempre una richiesta successiva dentro la finestra.
• Traffico a raffiche / cron (batch giornaliero alle 09:00): usa un provider con TTL lungo (deepseek-v4-flash è quello più longevo nel nostro set di test) oppure esegui un keep-alive da 1 token ogni TTL/2 durante la finestra di esecuzione. Pattern in Part 3 §8.2.

Modelli consigliati per tipo di task

† I marker multi-cache_control di Claude non hanno rivali per il RAG a strati: usa l’SDK anthropic puntato al gateway, vedi Parte 3 §2.

Stima dei costi RAG (100K query/giorno)

3K di sistema + 5K di documenti recuperati + query da 200 token + output da 300 token. I numeri sono scalati dai costi misurati per singola chiamata in Part 3 §6 — single-tenant, senza carico concorrente. Per il tuo carico di lavoro specifico, stima la fattura con il calcolatore dei costi LLM e verifica le tariffe correnti sul confronto dei prezzi dei modelli in tempo reale.

Da leggere come ordine di grandezza. In produzione reale ci sono chiamate concorrenti, picchi, e la distribuzione della lunghezza dei documenti recuperati dominerà i conti.

Trappole RAG / API

• ❌ Non ordinare i chunk recuperati per punteggio di rilevanza dinamico: ogni richiesta ottiene un prefisso diverso.
• ❌ Non scartare i log di utilizzo durante lo streaming, altrimenti l’attribuzione dei costi va in pezzi. Passa stream_options={"include_usage": True} e salva prompt_tokens_details.cached_tokens e usage.cost.
• ✅ Per i task in batch, combina le Batch API dei vendor (OpenAI Batch, Anthropic Message Batches) con la cache per un altro ~50% di sconto — da fare fuori da questo gateway, chiamando direttamente il provider.

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

Profilo di traffico

• Un task di un agente = molte chiamate LLM, intervallate ai risultati dei tool.
• Contesto molto lungo (system + tool + storico accumulato): tipicamente 30K–100K token allo step 10.
• Prompt molto strutturati: prefisso stabile lungo, coda variabile piccola.
• Contano sia latenza sia costo: ogni secondo in più di prefill aggiunge attesa visibile, e un agente da 15 step la moltiplica per 15.

Perché gli agent dipendono dalla cache

Ogni step aggiunge la chiamata al tool e il relativo risultato dello step precedente. Senza cache, ogni step ripaga il prefill su 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 append-only e byte per byte identici tra uno step e l’altro. Qualsiasi riscrittura o riordino uccide la cache da quel punto in poi. Il bug più comune negli agent è “ho ripulito il risultato del tool prima di rimandarlo” → il cache rate crolla a zero → costo e latenza si moltiplicano.

Corrispondenza del TTL — l’unico caso in cui conta

Un tipico task di un agent dura 10–60 secondi; dentro un singolo task il TTL di default di 5 minuti va benissimo. Il problema sono gli agent che aspettano un’approvazione umana (“rivedi questo piano e rispondi”): possono restare fermi per minuti. Se la persona si prende una pausa di 10 minuti e la cache è ormai fredda, lo step successivo ripaga il prefill su 50K token. Per questi workflow hai due opzioni:

• Usa un provider con TTL più lungo (deepseek-v4-flash è quello con la durata maggiore nel nostro set di test), oppure
• Invia un ping keep-alive ogni TTL/2 mentre aspetti (vedi Parte 3 §8.2).

Modelli consigliati per gli agent

Gli agent richiedono capacità di reasoning: scegli prima in base alla qualità, poi ottimizza il costo.

† Il pattern a 4 marker cache_control di Claude resta la configurazione migliore per il caching negli agent (sconto cumulativo sul prefisso su oltre 10 step). Usa l’SDK anthropic puntato al gateway — vedi Parte 3 §2 per la forma esatta del payload e le opzioni di TTL.

Stima di costo reale: un task di 15 step

Ipotizza 5K di system + 3K di tools + ~3K aggiunti per step, per un totale di 15 step. Costo per chiamata preso dalla Parte 3 §6 e adattato alla forma dell’agent:

Anche qui, numeri indicativi. La variabile che pesa di più è se riesci davvero a mantenere il prefisso identico byte per byte da uno step all’altro.

Errori comuni con gli agent

• ❌ Non ricostruire la lista dei messaggi a ogni step — mantieni l’array identico byte per byte, aggiungi soltanto in coda.
• ❌ Non tagliare né riformattare i risultati dei tool — qualsiasi cambiamento di byte invalida la cache degli step successivi.
• ❌ Non condividere una chiave di cache tra istanze concorrenti dello stesso agent — l’ordine dei loro step diverge e si contaminano a vicenda.
• ✅ Monitora il rapporto cache_creation_tokens : cache_read_tokens per task — un valore sano è 1:50 o migliore entro lo step 10.

La matrice decisionale principale

                            ┌─ 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 al TTL per caso d’uso

Cosa fa e cosa non fa questo gateway

Per fissare aspettative oneste:

Se oggi ti serve una delle voci a destra, gestiscila nel tuo application layer o direttamente con l’SDK del vendor. Il gateway è un proxy sottile più un layer di pricing; tutto ciò che riguarda il caching avviene a monte, a livello del modello.

In sintesi

L’intera serie si comprime in quattro righe:

Il caching sono due vittorie, non una. Costo E latenza. Prima il contenuto stabile, per ultimo quello volatile. La disciplina sul prefisso è gratis, applicala ovunque. Adatta modello + comportamento della cache al caso d’uso. Chat ≠ RAG ≠ Agent. Misura sul tuo traffico. Un benchmark su singola run è un punto di partenza, non la risposta.

Il percorso più veloce da qui: scegli dalla matrice qui sopra il caso d’uso più vicino al tuo, applica le modifiche strutturali (prefisso stable-first, retrieval deterministico, stato dell’agent byte-identical), logga cached_tokens e usage.cost per una settimana e poi rivaluta.

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 in meno rispetto ai modelli ottimizzati per l’inglese quando lavorano su testo cinese, con una qualità pari a gpt-5.4-mini sui carichi di chat tipici.

Qual è il miglior LLM per il RAG nel 2026? Per l’inglese: gpt-5.4-mini con il layout di prompt Fix A (token di sistema in testa, riferimenti in fondo) raggiunge un hit rate superiore all’80% sulla porzione stabile. Per il cinese: deepseek-v4-flash. Per documenti molto lunghi interrogati spesso: gemini-2.5-pro, che gestisce nativamente contesti da oltre 1M di token.

Meglio GPT o Claude per gli agent? Entrambi sono validi; la scelta dipende da quanta disciplina sulla cache sei disposto a investire. Il pattern di Claude con 4 marker cache_control (tramite l’SDK anthropic puntato al gateway) è particolarmente potente per i prefissi cumulativi degli agent: riduzione del costo di input di circa il 90% una volta che il prefisso è caldo, su oltre 10 step. Se preferisci restare sul client in stile OpenAI e accontentarti di un risparmio in cache di circa il 50% senza marker, gpt-5.4-mini o gpt-5.5-pro è la scelta con meno attrito.

Quanto posso risparmiare realmente passando da un uso “ingenuo” a uno “ottimizzato” degli LLM? Sulle run 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 guadagno viene dal portare l’hit rate sopra l’80%, non dal cambiare modello.

Da dove comincio? Scegli dalla matrice il caso d’uso più vicino al tuo. Applica le modifiche strutturali al prompt. Misura cached_tokens e usage.cost su una settimana di traffico in produzione. Solo a quel punto valuta se cambiare modello.

Fonti e verifica: numeri misurati da Parte 3 §6, https://synthorai.io/v1 il 2026-05-25, SDK openai 2.38.0. Pagine di pricing dei vendor: OpenAI · Anthropic · Google Gemini · DeepSeek · Alibaba Bailian.

← Torna al blog