Architettura degli LLM: progettazione di sistemi per l'AI in produzione
L’esecuzione di un modello è un problema infrastrutturale. Ottenere valore da un modello è un problema architetturale.
Lo strato infrastrutturale — runtime, hardware, endpoint API — determina ciò che è possibile. Lo strato architetturale determina ciò che accade effettivamente a una richiesta: quale modello la gestisce, quanto costa, cosa la valida e come vengono gestiti i guasti.
La maggior parte dei sistemi inizia con un singolo modello e senza alcuna architettura. Questa è la scelta corretta per il prototipazione. In produzione diventa un passivo.
L’architettura LLM copre le decisioni progettuali che trasformano “un modello che posso chiamare” in “un sistema su cui posso affidarmi”.
Dove si colloca l’Architettura LLM nello Stack
L’architettura LLM si trova al centro di un modello a tre livelli:
| Livello | Cosa copre | Area Correlata |
|---|---|---|
| Modelli | Runtime, serving, configurazione GPU | Hosting LLM · Prestazioni LLM |
| Architettura | Routing, costi, guardrails, orchestrazione | Sei qui |
| Applicazioni | Assistenti AI, pipeline RAG, agenti | Sistemi AI · RAG |
Il livello architetturale viene spesso saltato nelle fasi iniziali. Diventa essenziale quando si dispone di più di un modello, più di un tipo di compito o più di un utente. Ogni pattern architetturale in questo cluster esiste perché l’approccio “un modello per tutto” ha smesso di funzionare.
Mappa del Cluster
I cinque argomenti di questo cluster si costruiscono a vicenda. Leggi in questo ordine per seguire il percorso più logico:
- Sei qui — questo pilastro: cos’è l’architettura LLM, come si integrano i vari componenti
- Prompt — Scrivere Prompt Efficaci per LLM — le fondamenta: modellare ciò che il modello riceve
- Routing — Strategie di Routing dei Modelli — il dispatcher: quale modello gestisce cosa
- Costi — Ottimizzazione dei Costi per Sistemi LLM — gestione del budget token, caching, economia locale vs API
- Sicurezza — Guardrails LLM nella Pratica — validazione degli input, filtraggio degli output, conformità
- Orchestrazione — Design di Sistemi Multi-Modello — pattern sequenziali, paralleli, gerarchici e di ensemble
Se hai tempo solo per uno, inizia con il routing. È il punto decisionale dove l’architettura prende forma.
Prompt Engineering
Il prompt engineering è lo strato più vicino al modello. Prima del routing, prima del caching, prima dei guardrails — c’è il prompt. Ciò che invii al modello determina ciò che ottieni in risposta.
Le tecniche pratiche che contano davvero:
- Chiarezza e struttura — istruzioni chiare superano l’efficienza di un framing ingegnoso
- Esempi specifici — esempi few-shot ancorano il comportamento del modello
- Assegnazione del ruolo — prompt basati su ruoli affinano tono e vincoli
- Approcci variati — formati diversi rivelano a cosa il modello risponde meglio
- Gestione del contesto — ciò che includi modella ciò che il modello pondera
Il prompt engineering non è un compito una tantum. È una calibrazione continua tra i requisiti del tuo compito e il comportamento del modello.
Approfondimento:
- Scrivere Prompt Efficaci per LLM — tecniche pratiche per le prestazioni dei modelli linguistici
Model Routing
Un livello di routing decide quale modello gestisce quale richiesta. Senza di esso, ogni richiesta va allo stesso modello — spesso troppo grande per compiti semplici, troppo piccolo per quelli complessi.
Quattro strategie di routing coprono la maggior parte dei casi di produzione:
| Strategia | Ottimizzare per | Ideale quando |
|---|---|---|
| Basata sulle capacità | Qualità del compito | Carichi di lavoro a complessità mista |
| Consapevole dei costi | Spesa di token | Sistemi vincolati dal budget |
| Consapevole della latenza | Tempo di risposta | Strumenti interattivi e chat in tempo reale |
| Ibrida | Tutte e tre | Sistemi di produzione con vincoli reali |
Una catena di fallback gestisce i guasti: ordina i modelli dal migliore al più affidabile, terminando con un modello locale che non può essere limitato dalla rate limit o spento da un’interruzione dell’API.
Approfondimento:
- Strategie di Routing dei Modelli: Locale vs API, Consapevole dei Costi, Consapevole della Latenza — routing basato su capacità, costi e latenza con codice Python
Ottimizzazione dei Costi
I costi degli LLM scalano linearmente con l’uso. Le strategie che riducono effettivamente la fattura:
Gestione del budget token stabilisce limiti per sessione, per compito o adattivi. I budget adattivi tracciano l’uso reale e restringono le allocazioni nel tempo.
Inferenza locale cambia completamente la struttura dei costi. Dopo l’ammortamento dell’hardware, i modelli locali funzionano al costo dell’elettricità. Una GPU con un utilizzo moderato si ripaga in pochi mesi.
Caching è l’ottimizzazione più sottovalutata. Il caching exact-match intercetta i prompt ripetuti. Il caching semantico intercetta i prompt che hanno lo stesso significato. Per i sistemi ad alto traffico, il caching semantico elimina una grande percentuale di chiamate API prima che avvengano.
Catene di fallback riducono il costo medio per richiesta: preferisci modelli costosi quando il budget lo permette, passa a quelli più economici o locali man mano che la sessione prosegue.
Approfondimento:
- Ottimizzazione dei Costi per Sistemi LLM: Gestione Budget Token, Modelli di Fallback, Caching — numeri hardware reali, tabelle di pareggio e pattern Python funzionanti
Guardrails
Gli LLM sono imprevedibili di default. I guardrails vincolano ciò che entra e ciò che esce — senza rimuovere le capacità del modello.
Tre livelli di guardrail contano nella pratica:
Validazione degli input ferma i problemi prima che raggiungano il modello. La sanitizzazione dei prompt intercetta i tentativi di iniezione. I limiti di lunghezza prevengono lo spreco di token. I filtri di contenuto bloccano le violazioni delle policy prima che l’inferenza costi qualcosa.
Filtraggio degli output intercetta i problemi dopo la generazione. La validazione strutturale garantisce forme di risposta attese. I controlli di contenuto bloccano output dannosi. Il fact-checking (per domini critici) valida le affermazioni contro una base di conoscenza.
Meccanismi di sicurezza proteggono il sistema nel tempo: la rate limiting previene l’abuso, i budget token limitano i costi per richiesta, la gestione della finestra di contesto previene l’overflow e la perdita di dati tra i turni.
Per i sistemi con pesanti requisiti di conformità (GDPR, HIPAA, SOC 2), aggiungi audit logging con entry strutturate e solo in append, e controlli di residenza dei dati.
I guardrails gestiscono la conversazione del modello, ma una volta che gli agenti chiamano strumenti e delegano il lavoro ad altri agenti, diventa necessario un secondo livello di sicurezza: chi può agire, a nome di chi e con quale traccia di audit. Si tratta di sicurezza del protocollo piuttosto che di filtraggio I/O del modello.
Approfondimenti:
- Guardrails LLM nella Pratica: Validazione Input, Filtraggio Output, Sicurezza — pattern pratici per i guardrails e note sulla conformità
- Sicurezza degli Agenti A2A e MCP: Identità, Delega e Audit Trails — sicurezza del protocollo degli agenti oltre la sicurezza dei prompt: identità, autorizzazione, gateway e controlli di delega
Design di Sistemi Multi-Modello
Quando un singolo modello non è sufficiente, la domanda architetturale è: come orchestri più modelli senza creare una complessità che costa più di quanto salva?
Cinque pattern coprono lo spazio:
| Pattern | Latenza | Costo | Qualità | Usare quando |
|---|---|---|---|---|
| Modello Singolo | Più bassa | Più basso | Variabile | Prototipazione, carichi di lavoro uniformi |
| Sequenziale (Pipeline) | Alta | Medio | Alta | Workflow multi-step con specializzazione |
| Parallelo (Fan-Out) | Bassa | Alto | Alta | Compiti indipendenti, test A/B |
| Gerarchico (Planner-Executor) | Alta | Alto | Più alta | Ragionamento complesso con esecuzione specializzata |
| Ensemble | Media | Più alto | Più alta | Decisioni critiche che richiedono consenso |
La regola empirica: inizia con il pattern più semplice che gestisce i tuoi vincoli effettivi. La maggior parte dei sistemi di produzione raggiunge il livello parallelo o gerarchico solo dopo che il routing basato sulle capacità da solo non è più sufficiente.
Approfondimento:
- Design di Sistemi Multi-Modello: Quando Usare Quale Modello e Perché — tutti e cinque i pattern con codice Python funzionante e tabelle dei compromessi
Framework per le Decisioni Architetturali
Usa questo come triage rapido su cosa aggiungere e quando:
| Problema | Soluzione | Quando aggiungerlo |
|---|---|---|
| La fattura è troppo alta | Routing consapevole dei costi, caching, inferenza locale | Quando i costi API diventano una voce di budget reale |
| La latenza è troppo alta | Routing consapevole della latenza, modelli più piccoli | Quando gli utenti notano lentezza |
| La qualità è inconsistente | Routing basato sulle capacità, catena di fallback | Quando i compiti semplici usano modelli costosi o quelli complessi usano quelli economici |
| Gli utenti abusano del sistema | Validazione degli input, rate limiting | Quando apri l’accesso oltre un team fidato |
| Le risposte sono insicure o fuori policy | Filtraggio degli output, guardrails di contenuto | Quando servi utenti generali |
| Un modello gestisce tutto | Design multi-modello | Quando i carichi di lavoro divergono abbastanza da giustificare la complessità |
| I prompt non funzionano | Iterazione di prompt engineering | Sempre — i prompt hanno bisogno di tuning man mano che i compiti evolvono |
Costruisci l’architettura dal basso verso l’alto. Il prompt engineering è sempre in scope. Aggiungi il routing quando i compromessi costo/qualità diventano reali. Aggiungi i guardrails quando servi utenti esterni. Aggiungi l’orchestrazione multi-modello per ultima.
Come l’Architettura LLM si Relaziona agli Altri Argomenti
L’architettura LLM si trova all’intersezione di diversi cluster correlati:
Infrastruttura (sotto questo livello):
- Hosting LLM nel 2026: Infrastruttura Locale, Self-Hosted e Cloud Confrontata — runtime (Ollama, llama.cpp, vLLM), hardware e decisioni di serving. I pattern architetturali dipendono dall’infrastruttura disponibile. Il routing consapevole dei costi ha senso solo se hai sia modelli locali che API in esecuzione.
- Prestazioni LLM nel 2026: Benchmark, Colli di Bottiglia e Ottimizzazione — numeri di latenza, limiti VRAM, misurazioni di throughput. Questi sono gli input empirici per le decisioni di routing e selezione del modello.
Livelli Applicativi (sopra questo livello):
- Sistemi AI: Assistenti Self-Hosted, RAG e Infrastruttura Locale — i sistemi che consumano le decisioni di routing, guardrails e orchestrazione. L’architettura multi-modello è un prerequisito per assistenti AI di produzione.
- Tutorial su Retrieval-Augmented Generation (RAG) — il RAG è esso stesso un pattern architetturale: una pipeline di recupero che alimenta il contesto in un LLM. I pattern di routing, costi e guardrails di questo cluster si applicano anche all’interno delle pipeline RAG.
Livello Operativo:
- Osservabilità: Monitoraggio, Metriche, Guida a Prometheus e Grafana — l’architettura LLM di produzione ha bisogno di osservabilità. Il tracciamento dei costi, il monitoraggio della latenza e le metriche di violazione dei guardrails richiedono tutti strumentazione a livello architetturale, non solo a livello infrastrutturale.
