Model Catalog & scelta del modello

1. Le famiglie di modelli e chi le produce

Il mercato degli LLM è oggi dominato da pochi player che rilasciano famiglie di modelli, ciascuna con varianti di diverse dimensioni e capacità. Per un team enterprise conta conoscere i big ma anche sapere cosa esiste dal lato open-source.

Player principali (aprile 2026, sintetico)

La tassonomia in famiglie è utile perché i vendor rilasciano varianti dello stesso modello a diverse taglie: un modello "grande" (migliore qualità, più caro, più lento) e uno o più "piccoli" (più rapidi, più economici, meno potenti). Scegliere la variante giusta è spesso più importante che scegliere il vendor.

2. Generalisti vs specialistici

Modelli generalisti

Sono quelli che leggi sui giornali: GPT, Claude, Gemini. Allenati su enormi dataset multi-dominio, sono forti quasi ovunque e la scelta di default per task nuovi o esplorativi. Tendono a vincere anche su coding, perché le scale e le tecniche di post-training superano la specializzazione.

Modelli specialistici di coding

Pensati, allenati o fine-tuned specificamente su codice. Esempi storici e attuali: Codestral (Mistral), DeepSeek Coder, Qwen Coder, StarCoder, CodeLlama. Possono essere competitivi a parità di taglia, eccellenti per fill-in-the-middle (tipico dell'autocompletion) e per scenari self-hosted dove i big generalisti non sono disponibili.

Modelli multimodali

Aggiungono visione (immagini, PDF), audio, video. Rilevanti per documentazione con screenshot, analisi di UI, estrazione dati da documenti scansionati. Oggi quasi tutti i generalisti top sono multimodali; le versioni piccole spesso no.

Modelli "reasoning" / thinking

Una classe recente (o-series OpenAI, Claude con extended thinking, Gemini Thinking) che investe più token in ragionamento interno prima di rispondere. Costano e latenzano di più, ma su task difficili (algoritmi, bug complessi, refactoring multi-file) portano un salto di qualità che spesso giustifica il costo.

Quando preferire uno specialistico?

• Quando servono molte inference a bassissimo costo (es. autocompletion in editor, classificazione massiva).
• Quando c'è un vincolo di deployment on-prem.
• Quando il task è molto definito e benchmarkabile (es. generazione di test unitari in un linguaggio specifico).
• Quando si vuole fare fine-tuning su dati proprietari senza passare da un cloud vendor.

3. Trade-off pratici: costo, latenza, qualità, compliance

Ogni scelta di modello è un compromesso tra quattro assi. Nessun modello vince su tutti.

Costo

Si misura quasi sempre in dollari per milione di token (input + output separati). Le differenze sono enormi: un modello "grande" può costare 20–40× un modello piccolo della stessa famiglia. Per un caso d'uso ad alto volume, la differenza tra un modello mid e uno top può trasformare un business case verde in rosso.

Regola operativa: per task ripetitivi ad alto volume, parti dal modello più piccolo che supera la tua soglia di qualità. Non dal più potente.

Latenza

Due componenti: time to first token (quanto aspetti prima di vedere qualcosa) e throughput (quanti token al secondo genera). Per UX interattive (chat, completions in editor) il time-to-first-token conta più di tutto; per job batch (documentazione, analisi) conta il throughput.

I modelli reasoning possono avere latenze di decine di secondi perché "pensano" prima di parlare: ottimo in background, pessimo in autocompletion.

Qualità

I benchmark pubblici (MMLU, HumanEval, SWE-Bench) danno un'idea ma non sostituiscono un eval sui tuoi casi. La pratica matura è costruire un piccolo set di 20–50 prompt rappresentativi dei task aziendali e valutare ogni modello candidato su quel set, con metriche semplici: "passa / non passa", tempo, costo.

Compliance & privacy

Variabili principali:

• Data residency: dove vengono processati i dati? UE? USA?
• Logging vendor: il provider salva i prompt? Per quanto? È opt-out?
• Uso per training: i dati vengono usati per retraining? Le offerte enterprise dicono no per default; quelle consumer spesso sì.
• Certificazioni: ISO 27001, SOC2, eventualmente GDPR DPA.
• PII e segreti: che policy hai sui dati personali e sulle credenziali?

4. Cloud vs locale vs self-hosted

Cloud managed (default)

API di vendor: OpenAI, Anthropic, Google. Oppure in tenant dedicato: Azure OpenAI, AWS Bedrock, GCP Vertex. Vantaggi: massima qualità, zero operations, SLA, pagamento a consumo, aggiornamenti automatici. Svantaggi: dati fuori dal perimetro (mitigabile con tier enterprise), costi variabili, dipendenza dal vendor.

Cloud self-hosted

Modelli open-weight deployati su infrastruttura cloud propria (VM con GPU, servizi gestiti come Bedrock Custom Model, Runpod, Modal). Vantaggi: controllo, possibilità di fine-tuning, costi prevedibili sopra certe soglie di volume. Svantaggi: operations significativa, qualità inferiore ai top cloud, aggiornamenti manuali.

On-premises

Modelli open-weight su hardware aziendale. Vantaggi: massima data sovereignty, nessun token esce. Svantaggi: costi capex GPU, ops, difficoltà a tenere il passo coi modelli migliori.

Quando self-hostare vale?

• Volumi molto alti e stabili → l'ammortamento hardware batte i costi API dopo qualche mese.
• Requisiti di compliance stringenti (es. dati sanitari, difesa) → la policy è "niente fuori".
• Task benchmarkato in cui un modello open è sufficiente → non serve top-tier.
• Necessità di fine-tuning pesante su dati proprietari sensibili.

Altrimenti, il default sensato è cloud managed con tenant enterprise. Il 90% dei team che "vogliono self-hostare per principio" finisce per spendere di più e ottenere di meno.

5. Una matrice di decisione usabile davvero

Quando arriva un caso d'uso nuovo, le domande da farsi, in ordine:

1. Che vincoli di privacy ha? Se i dati non possono uscire → shortlist self-hosted / EU data residency.
2. Che latenza richiede l'UX? Interactive (<1s TTFT) → modelli fast/flash; batch → qualunque.
3. Che volumi previsti? Bassi → generalisti top; alti → valuta small + routing.
4. Il task è standard o richiede reasoning? Standard → mid-tier; reasoning → thinking model.
5. Contesto necessario per call? Piccolo → qualunque modello; enorme (repo intero) → modelli con contesto lungo (Claude, Gemini).
6. Serve multimodalità? → restringe la scelta.
7. Serve fine-tuning su dati proprietari? → open weights o servizi managed con fine-tuning.

Esempio di scelta per tre scenari Blulink

Router pattern

In soluzioni mature, non si sceglie un modello: si costruisce un router che smista le richieste al modello più adatto. Es: query semplici al modello small, query che contengono keyword come "refactor" o richiedono tool use al reasoning model. Un router ben fatto può dimezzare i costi senza perdere qualità percepita.