---
title: "Dentro un Transformer: attention, MLP e residual stream spiegati per chi integra LLM in produzione"
description: "Architettura interna del Transformer spiegata per ingegneri: attention multi-head, MLP come store fattuale, residual stream e implicazioni operative."
canonical: "https://www.mauriziofonte.it/blog/post/architettura-transformer-interno-attention-mlp-residual-stream-llm.html"
author: "Maurizio Fonte"
date: "2026-05-05T08:08:22+02:00"
modified: "2026-10-29T15:29:46+01:00"
section: "Architettura Software"
tags: ["Architettura Software", "LLM Automation"]
license: "Riuso e citazione consentiti con attribuzione e link alla fonte"
---

[Architettura Software](https://www.mauriziofonte.it/blog/cat/architettura_software.html) [LLM Automation](https://www.mauriziofonte.it/blog/cat/llm-automation.html)

# [Dentro un Transformer: attention, MLP e residual stream spiegati per chi integra LLM in produzione](https://www.mauriziofonte.it/blog/post/architettura-transformer-interno-attention-mlp-residual-stream-llm.html)

Martedì 5 Mag 2026, alle 08:08 ![Dentro un Transformer: attention, MLP e residual stream spiegati per chi integra LLM in produzione](https://www.mauriziofonte.it/image/004350200-architettura-transformer-interno-attention-mlp-residual-stream-llm.jpg)

Il 27 aprile 2026 ho passato un pomeriggio nella mia sandbox di sperimentazione AI a confrontare come due diverse implementazioni di retrieval producevano risultati drasticamente diversi sullo stesso corpus di documentazione tecnica italiana: stesso Claude Sonnet 4.6, stessi prompt, embedding diversi, recall@10 passato dal 62% all'88%. Per capire perché il cambio di embedding faccia così tanta differenza e perché il prompt engineering non possa compensarlo, serve aver presente cosa succede dentro un Transformer riga per riga. Nessuna magia: quattro componenti ben definiti, ciascuno con un ruolo operativo preciso. Qui il tour interno per chi integra LLM in produzione, con le implicazioni pratiche che nessuna pagina marketing del vendor ti racconta.

## Cos'è davvero l'architettura Transformer proposta nel 2017?

Il paper fondazionale è [Attention Is All You Need](https://arxiv.org/abs/1706.03762) di Vaswani et al. NeurIPS 2017, autori Google Brain, pubblicato il 12 giugno 2017. Al 2025 il paper ha superato le 173.000 citazioni, ottavo paper più citato del XXI secolo. L'architettura proposta elimina completamente ricorrenza e convoluzione e si basa solo su meccanismi di attention.

Schema del modello originale: stack di 6 encoder layer + 6 decoder layer, ogni layer con due sub-layer (self-attention multi-head + feed-forward position-wise). Dimensione del modello $d_{model}=512$, 8 teste di attention, $d_k=d_v=64$. Una residual connection attorno a ciascun sub-layer, seguita da layer normalization: $text{LayerNorm}(x + text{Sublayer}(x))$. Dropout 0,1.

I LLM moderni (GPT-4, Claude Opus, Gemini) sono evoluzioni di questa architettura: decoder-only (abbandonato l'encoder), dimensioni enormemente più grandi (GPT-4 stimato a 1.800 miliardi di parametri distribuiti su decine di transformer block), numerose varianti architetturali (Multi-Query Attention, Grouped-Query Attention, Sliding Window, Mixture of Experts). Ma la struttura base resta quella di Vaswani: attention + MLP + residual stream, ripetuti ricorsivamente.

## Componente 1: embedding lookup (la porta d'ingresso del modello)

Il prompt testuale viene spezzato in token dal tokenizer (BPE, SentencePiece, Tiktoken). Ciascun token è un intero che indicizza una riga della matrice di embedding, una matrice di dimensione $|V| times d_{model}$ dove $|V|$ è la dimensione del vocabolario (tipicamente 50.000-200.000) e $d_{model}$ è la dimensione del modello (4.096 su Llama 3, molto di più su modelli frontier). Il risultato è una sequenza di vettori.

Qui si aggiunge il positional encoding: una funzione (originariamente sinusoidale, poi RoPE su Llama/Mistral) che inietta informazione sulla posizione del token nella sequenza. Senza positional encoding il modello vedrebbe la sequenza come un bag-of-words senza ordine.

Implicazione operativa: due prompt con gli stessi token ma ordine diverso producono risultati diversi perché il positional encoding è diverso. Questo è il motivo per cui nei miei articoli precedenti ho sottolineato che l'ordine degli esempi few-shot conta: gli esempi "tipici" all'inizio e gli "edge case" alla fine non sono un vezzo, sono una leva sull'attention distribuzione.

## Componente 2: multi-head self-attention (i token che si parlano)

Il blocco di attention è il cuore concettuale del Transformer. Prende la sequenza di vettori e la trasforma in una nuova sequenza dove ciascun vettore "attende" (presta attenzione) agli altri in base a una metrica di rilevanza appresa.

Matematicamente, per ogni testa di attention $h$ si calcolano tre matrici $Q_h$, $K_h$, $V_h$ (query, key, value) proiettando la sequenza input. L'output della testa è $text{softmax}(Q_h K_h^T / sqrt{d_k}) V_h$. Le teste operano in parallelo e i loro output sono concatenati e proiettati di nuovo a dimensione $d_{model}$.

Intuizione operativa: quando il modello processa il token "it" in "The animal didn't cross the street because it was tired", l'attention assegna un peso alto a "animal" perché il modello ha imparato che "it" in quel contesto riferisce "animal". Non è magia: è l'output di un calcolo matriciale sulle proiezioni apprese in pretraining.

Implicazione per chi integra: l'attention è quadratica nella lunghezza della sequenza. Un prompt di 100k token richiede 10^10 operazioni di attention. Per questo la latenza cresce non-linearmente con la lunghezza del contesto, e per questo i vendor hanno introdotto varianti (flash attention, sliding window, grouped-query) che tagliano i costi mantenendo la qualità.

Se vuoi vedere come progetto pipeline LLM con attenzione al costo computazionale del context window, nel [mio hub dedicato allo sviluppo AI](https://www.mauriziofonte.it/ai-aziende/claude-code-aziende.html) trovi articoli tecnici con metodologia applicata e perimetro dichiarato.

## Componente 3: MLP (dove stanno i fatti)

Dopo l'attention, c'è il blocco feed-forward, un MLP (multi-layer perceptron) a due layer con una non-linearità nel mezzo (originalmente ReLU, ora SwiGLU o GeGLU). Dimensione interna tipicamente 4x $d_{model}$, quindi l'MLP è la componente con più parametri del blocco.

La ricerca di [mechanistic interpretability di Anthropic](https://transformer-circuits.pub/) ha evidenziato che l'MLP è la componente dove si concentra la memoria fattuale del modello. Fatti appresi durante pretraining ("Parigi è la capitale della Francia") sono distribuiti sparsamente tra i neuroni dell'MLP. Il paper [Scaling Monosemanticity](https://transformer-circuits.pub/2024/scaling-monosemanticity/) di maggio 2024, che applica sparse autoencoder al residual stream a metà di Claude 3 Sonnet, ha identificato migliaia di feature interpretabili corrispondenti a concetti semantici.

Implicazione operativa: il prompt non cambia la memoria fattuale dell'MLP (i pesi sono congelati). Non puoi "aggiornare" un LLM dicendogli "da oggi la capitale della Francia è Lione". Puoi solo sovrascrivere la sua risposta con informazione fornita nel context (RAG), ma il modello continua a "sapere" la risposta originale sotto.

## Componente 4: residual stream (il nastro che trasporta i vettori)

Il residual stream è il concetto che ha rivoluzionato il modo in cui i ricercatori di interpretability analizzano il Transformer. Non è un componente aggiuntivo ma la connessione $x + text{Sublayer}(x)$ che passa da layer a layer. Ogni sub-layer legge il residual stream, calcola una modifica, e riaggiunge la modifica. Alla fine il residual stream contiene l'informazione accumulata attraverso tutti i layer.

Anthropic descrive il residual stream come "il nastro su cui il modello scrive e legge". Le attention head scrivono sul residual stream informazione appresa sulla relazione fra token; i layer MLP scrivono informazione fattuale. All'ultimo layer, il residual stream viene proiettato sul vocabolario tramite un'unembedding matrix e softmaxato per ottenere la distribuzione di probabilità del prossimo token.

Implicazione operativa: il residual stream è la variabile da monitorare per fare interpretability. Anthropic (team di 17 persone al 2024) pubblica su [transformer-circuits.pub](https://transformer-circuits.pub/) paper che descrivono feature estratte dal residual stream di Claude. Per una PMI, conoscere questo framework è il prerequisito per capire cosa stia facendo davvero il modello quando risponde in modo anomalo.

## Implicazioni operative per chi integra LLM: quattro osservazioni non ovvie

**Prima osservazione.** L'ordine dei token conta per via del positional encoding. I prompt non sono insiemi di parole, sono sequenze. Rimuovere una virgola, aggiungere uno spazio extra, cambiare l'ordine di due esempi few-shot può modificare significativamente l'output.

**Seconda osservazione.** La lunghezza del contesto costa quadraticamente per via dell'attention. Il trade-off "metto tutto nel prompt" fallisce oltre una soglia: non solo per costi monetari ma per latenza. Il retrieval mirato batte il contesto lungo in quasi tutti i casi di produzione.

**Terza osservazione.** Il modello non distingue nativamente system prompt da user input a livello architetturale; la distinzione è implementata nel template di tokenizzazione. Prompt injection sfrutta esattamente questa non-distinzione: un'istruzione nascosta in un documento fornito come user input viene processata dall'attention con lo stesso meccanismo del system prompt.

**Quarta osservazione.** I fatti nell'MLP sono fissi. RAG, fine-tuning, prompting sono tutti modi di bypassare o sovrascrivere la memoria fattuale a runtime, non di aggiornarla. Ogni qualvolta il vendor rilascia un nuovo modello, l'MLP è diverso: i fatti possono cambiare silenziosamente fra versioni.

## Come questo impatta le decisioni di progetto AI in PMI italiane

Quattro scenari ricorrenti in cui la conoscenza architetturale cambia la risposta.

**Scenario 1: scelta del contesto RAG.** Un cliente chiede "quanti documenti inserisco nel contesto del RAG?". Risposta ingenua: più possibili. Risposta informata: il minimo necessario per coprire la domanda, perché l'attention è quadratica e il "lost in the middle" fa perdere precisione sui documenti centrali. Il pattern corretto è retrieval mirato con reranking, non dumping di contenuto.

**Scenario 2: prompt engineering disciplinato.** Conoscere che il positional encoding assegna peso diverso ai token in base alla posizione ti fa scrivere prompt con istruzioni critiche alla fine (dove l'attention si concentra di più sui token finali), esempi variati (per evitare over-weighting di un sottotipo), delimitatori espliciti (che aiutano l'attention a segmentare blocchi logici).

**Scenario 3: audit di comportamento anomalo.** Il cliente segnala che il modello risponde male a un pattern di domande. Senza conoscere l'architettura, la diagnosi è impossibile; con l'architettura, le domande giuste sono: il prompt sta saturando il context? C'è un'interazione di positional bias? Gli embedding di termini specifici del dominio sono distorti?

**Scenario 4: scelta fra vendor e modello self-hosted.** Il vendor cambia tokenizer tra versioni (Claude 4.7 ha cambiato tokenizer rispetto a 4.6, come descritto nell'articolo [claude-opus-4-7-tokenizer-nuovo-costi-api-aumento-35-percento](https://www.mauriziofonte.it/blog/post/claude-opus-4-7-tokenizer-nuovo-costi-api-aumento-35-percento.html)). Questo significa che l'embedding lookup cambia, i fatti nell'MLP possono essere riallocati, e il comportamento complessivo è diverso. Chi non conosce l'architettura non sa nemmeno quale parametro varia quando il vendor fa un minor release.

## Edge case: cosa osservo quando confronto modelli in sandbox

Tre pattern che emergono ripetutamente quando confronto Claude, GPT, Gemini sullo stesso task.

**Pattern A: sensibilità al fraseggio.** Due formulazioni semanticamente identiche ("come migliorare la performance" vs "come ottimizzare le prestazioni") producono risposte significativamente diverse. È l'attention che pesa in modo diverso le proiezioni dei token sinonimi.

**Pattern B: bias di recency.** Le istruzioni alla fine del prompt pesano di più di quelle all'inizio, a parità di importanza logica. È un artefatto della distribuzione di attention sui token finali, spesso più concentrata.

**Pattern C: errore catastrofico su long-context.** Oltre una certa lunghezza di prompt, il modello perde l'istruzione iniziale e si concentra sugli ultimi N token. È il "lost in the middle" visto nei paper 2023-2024, ancora parzialmente presente nei modelli 2026 nonostante le ottimizzazioni.

## Framework operativo: cosa diagnosticare in ciascun componente

Una mappa mentale che uso nei code review di pipeline LLM.

Se il problema è nell'**embedding lookup**, i sintomi sono: parole di dominio specifiche trattate come sinonimi di termini non correlati, peggioramento di qualità su lingue non-inglesi, costi token non proporzionali alla lunghezza apparente del testo. Soluzioni: embedding specializzati (vedi il draft embeddings dominio-specifici in pipeline), tokenizer awareness nelle stime di budget.

Se il problema è nell'**attention**, i sintomi sono: risposte che ignorano parti del prompt, bias di recency, degradazione sul long context. Soluzioni: prompt compressi con retrieval mirato, riformulazione con istruzioni critiche in posizione di peso.

Se il problema è nell'**MLP**, i sintomi sono: allucinazioni fattuali (il modello "sa" fatti sbagliati), regressioni fra versioni del modello su fatti specifici, confabulazioni contestualmente plausibili. Soluzioni: RAG per fatti, validation layer esterno, nessuna fiducia cieca nella memoria del modello.

Se il problema è nell'**unembedding/softmax**, i sintomi sono: instabilità dell'output (lo stesso prompt produce risposte diverse anche con temperature 0), dominanza di token specifici. Soluzioni: constrained decoding, structured output API, temperature tuning deliberato.

## Perché questa comprensione architetturale fa la differenza in produzione

Un ingegnere che integra LLM senza capire la struttura interna tratta il modello come una scatola nera: si affida al vendor marketing, prova varianti di prompt a caso, quando qualcosa non funziona ripete "proviamo un modello più potente". Un ingegnere che conosce l'architettura ha leve concrete: posizionamento dei token cruciali in zone di alta attention, gestione del context budget, consapevolezza di cosa cambi (e cosa non cambi) con RAG e fine-tuning, diagnostica delle regressioni fra versioni di modello.

Capire l'architettura del Transformer non è esercizio accademico; è la base per costruire sistemi AI che reggono il carico di produzione e che si possono auditare quando qualcosa va male. Se hai un progetto LLM in cui le scelte architetturali pesano (retrieval, context budget, prompt engineering sistematico) e vuoi verificare se l'architettura proposta dal fornitore regge al confronto con quello che davvero succede dentro il modello, il [modulo di preventivo gratuito](https://www.mauriziofonte.it/pages/preventivo-gratuito.html#consulenza-ai) ti risponde in due minuti se il caso rientra nel mio ambito. Il Transformer ha nove anni; chi lo usa senza averne mai aperto il cofano sta guidando un motore di cui non conosce nemmeno i cilindri, e quando il motore si ferma l'unica risposta sensata che sa dare è "proviamo un modello più grande", che è il modo più costoso e meno efficace di risolvere un problema architetturale. L'architettura si studia una volta, le sue implicazioni durano cinque anni di integrazioni AI ben progettate, e il ROI del tempo investito è sproporzionato rispetto a qualunque corso di prompt engineering offerto dal mercato italiano. I consulenti che parlano di LLM senza aver letto Vaswani 2017 e la serie di circuits Anthropic sono venditori di hype; i pochi che li hanno letti portano valore per dieci anni, perché la struttura è stabile anche quando i modelli specifici cambiano ogni sei mesi e quando le buzzword commerciali vanno e vengono su LinkedIn senza lasciare traccia nell'ingegneria reale dei sistemi in produzione.

Dall'articolo al lavoro vero

Se il codice di cui parla questo articolo è il tuo

Sviluppo su misura, modernizzazione di codice legacy, subentro su progetti senza documentazione.

[Vedi tre interventi con i numeri](https://www.mauriziofonte.it/programmatore-php.html) Ultima modifica: Giovedì 29 Ottobre 2026, alle 15:29 [« Articolo precedenteAnthropic Tool Search Tool e Programmatic Tool Calling: agenti con 50+ tool MCP senza saturare il context4 Mag 2026](https://www.mauriziofonte.it/blog/post/anthropic-tool-search-programmatic-tool-calling-mcp-ridurre-token.html)[Articolo successivo »Laravel: la scelta migliore per le applicazioni Web-based5 Mag 2026](https://www.mauriziofonte.it/blog/post/laravel-la-scelta-migliore-per-le-applicazioni-web-based.html)

### Articoli correlati a Dentro un Transformer: attention, MLP e residual stream spiegati per chi integra LLM in produzione

- [Framework CO-STAR per prompt enterprise: checklist applicativa e anti-pattern del prompt engineering 2026](https://www.mauriziofonte.it/blog/post/costar-framework-prompt-engineering-enterprise-checklist-applicativa.html)

  CO STAR GovTech Singapore, novembre 2023 : Context, Objective, Style, Tone, Audience, Response. Checklist rigorosa per prompt enterprise che · 13 Mag 2026

  ![Framework CO-STAR per prompt enterprise: checklist applicativa e anti-pattern del prompt engineering 2026](https://www.mauriziofonte.it/image/004380070-costar-framework-prompt-engineering-enterprise-checklist-applicativa.jpg)
- [Vocabolario AI 2026: i concetti tecnici che un decisore IT deve distinguere davvero](https://www.mauriziofonte.it/blog/post/vocabolario-ai-2026-concetti-tecnici-decisori-it-pmi.html)

  Quando un vendor ti propone un progetto AI per la tua azienda, sa distinguere pretraining da fine tuning? Sa perché Mixture of Experts cambia · 2 Aprile 2026

  ![Vocabolario AI 2026: i concetti tecnici che un decisore IT deve distinguere davvero](https://www.mauriziofonte.it/image/004250070-vocabolario-ai-2026-concetti-tecnici-decisori-it-pmi.jpg)
- [White-box analysis degli LLM: Persona Vectors, emozioni funzionali e checklist di audit per agenti di produzione](https://www.mauriziofonte.it/blog/post/white-box-analysis-llm-persona-vectors-emozioni-funzionali-audit-checklist.html)

  La system card di Mythos del 2026 include più di 40 pagine di white box analysis: feature distinte per etica, vergogna, stress, ostinazione si · 26 Giugno 2026

  ![White-box analysis degli LLM: Persona Vectors, emozioni funzionali e checklist di audit per agenti di produzione](https://www.mauriziofonte.it/image/004680070-white-box-analysis-llm-persona-vectors-emozioni-funzionali-audit-checklist.jpg)
- [Perché le allucinazioni LLM non si risolvono col prompting: rappresentazione distribuzionale e limiti architetturali](https://www.mauriziofonte.it/blog/post/allucinazioni-llm-rappresentazione-distribuzionale-perche-persistono.html)

  Nel 2023 Sam Altman prometteva di risolvere le allucinazioni in due anni; nel 2025 OpenAI stessa pubblica "Why Language Models Hallucinate" arxiv · 7 Mag 2026

  ![Perché le allucinazioni LLM non si risolvono col prompting: rappresentazione distribuzionale e limiti architetturali](https://www.mauriziofonte.it/image/004360070-allucinazioni-llm-rappresentazione-distribuzionale-perche-persistono.jpg)
- [In-context learning e few-shot prompting: il superpotere degli LLM spiegato per integrazioni di produzione](https://www.mauriziofonte.it/blog/post/in-context-learning-few-shot-prompting-llm-produzione-guida.html)

  Il paper GPT 3 del 2020 si chiama Language Models are Few Shot Learners non a caso. L'in context learning, la capacità di un LLM di apprendere · 8 Aprile 2026

  ![In-context learning e few-shot prompting: il superpotere degli LLM spiegato per integrazioni di produzione](https://www.mauriziofonte.it/image/004270070-in-context-learning-few-shot-prompting-llm-produzione-guida.jpg)

---

**Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali.  
Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile.

---

## Autore

**Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane.

Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore.

## Perché questa fonte è attendibile

- **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione).
- **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico.
- **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade".

## Entità e contatti (verificabili)

Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino).  
GitHub: https://github.com/mauriziofonte  
LinkedIn: https://www.linkedin.com/in/mauriziofonte  
Profilo: https://www.mauriziofonte.it/pages/about

---

## Come citare

> Maurizio Fonte, "Dentro un Transformer: attention, MLP e residual stream spiegati per chi integra LLM in produzione", mauriziofonte.it, 2026. https://www.mauriziofonte.it/blog/post/architettura-transformer-interno-attention-mlp-residual-stream-llm.html

Pubblicato: 2026-05-05 · Aggiornato: 2026-10-29.

**Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.