Attention nei transformer: perché raddoppiare il prompt quadruplica il lavoro

Fai una domanda a Claude o a ChatGPT incollando due righe di contesto: la risposta comincia ad arrivare quasi subito. La stessa domanda con dentro l’intero verbale di una riunione, o tre file di codice, e la barra resta ferma per qualche secondo prima che compaia la prima parola. Non è la tua connessione, e non è il modello «che ci pensa su». È che il lavoro da fare per leggere quel prompt non cresce come la sua lunghezza: cresce come il suo quadrato. Il meccanismo di attenzione dei transformer è la ragione per cui i modelli di oggi capiscono il contesto, ed è anche la ragione per cui il contesto è una risorsa da scegliere, non un serbatoio da riempire.

In questo articolo scoprirai:

• Il prompt lungo che rallenta più di quanto ti aspetti
• Cosa fa il meccanismo di attenzione dei transformer: ogni token guarda tutti gli altri insieme
• Query, key e value: il conto su «il pesce nuota» e «il pesce nel piatto»
• Quando questo ti costa: latenza, contesto pieno, conto della serva
• Cosa si fa per non pagare un contesto che non serve

Il prompt lungo che rallenta più di quanto ti aspetti

Il fenomeno si riproduce in due minuti, senza scrivere una riga di codice. Prendi una domanda breve, mandala una volta da sola e cronometra quanti secondi passano prima che appaia il primo carattere. Poi rimandala identica, incollandoci sopra cinquantamila token di documento che con la domanda non c’entrano nulla. La risposta finale sarà simile; il tempo di attesa prima del primo carattere non lo sarà.

Quel tempo ha un nome nella documentazione dei fornitori: time to first token. È la fase in cui il modello legge tutto il prompt prima di produrre qualcosa, la fase di prefill. Ed è l’unica parte del processo in cui la lunghezza di ciò che hai scritto non si paga una volta, ma due.

La sensazione tipica di chi ci sbatte contro è: «ho raddoppiato il contesto, mi aspettavo il doppio del tempo, ne ho visto molto di più». È una sensazione corretta, e non è un difetto di implementazione: è la forma dell’operazione che sta sotto. La cosa importante, e che quasi nessuno dice, è che quel quadrato non compare nella fattura, compare nella latenza, nella memoria della GPU e nel motivo per cui i contesti lunghi sono cari da servire. Ci arriviamo, ma prima serve capire cosa fa esattamente l’attention quando legge.

Cosa fa il meccanismo di attenzione dei transformer: ogni token guarda tutti gli altri insieme

Prima del 2017 il testo si leggeva in fila. Le reti ricorrenti scorrevano una parola alla volta portandosi dietro un vettore-riassunto che veniva aggiornato a ogni passo: a venti parole di distanza, il legame fra un pronome e il suo soggetto era già consumato dagli aggiornamenti intermedi. Nella tabella comparativa di Attention Is All You Need questo è scritto in due colonne: per uno strato ricorrente il numero di operazioni sequenziali è O(n) e la distanza massima fra due posizioni è O(n); per uno strato di self-attention entrambe valgono O(1) (Vaswani et al., 2017). Prima e ultima parola, per l’attention, sono alla stessa distanza. È lo stesso salto che abbiamo raccontato altrove confrontando cosa cambia nei transformer rispetto a RNN e LSTM.

Il meccanismo di attenzione confronta tutte le coppie di token

Il meccanismo di attenzione è l’operazione con cui ogni token di un testo confronta se stesso con tutti gli altri token presenti nella finestra, assegna a ciascuno un peso fra 0 e 1 e si riscrive come media pesata delle informazioni che quegli altri portano. Non c’è nessuna memoria che scorre e si consuma: ci sono confronti diretti fra tutte le coppie, calcolati tutti nello stesso momento. Il costo di quest’operazione cresce col quadrato del numero di token, perché il numero di coppie da confrontare è n×n.

L’attention dei transformer si parallelizza, la lettura in fila no

E qui sta il punto che ha cambiato tutto, più della qualità linguistica: quei confronti sono indipendenti fra loro. Leggere in fila non si parallelizza, il passo 2 ha bisogno del risultato del passo 1. Guardare tutti insieme sì: è una moltiplicazione di matrici, che è esattamente ciò che una GPU fa meglio. Gli autori del paper lo dicono in modo brutale: preferiscono il prodotto scalare all’attenzione additiva perché «è molto più veloce ed efficiente in memoria, dato che può essere implementato con codice di moltiplicazione matriciale altamente ottimizzato». La scala dei modelli di oggi nasce da questa riga, e da lì passa tutto come funziona un large language model.

Query, key e value: il conto su «il pesce nuota» e «il pesce nel piatto»

Prendi due frasi italiane: il pesce nuota e il pesce nel piatto. La parola «pesce» è la stessa stringa e, dopo come un modello spezza il testo in token, è lo stesso token. Ma nel primo caso è un animale, nel secondo una portata. Chi glielo dice al modello? Il contesto, e il contesto arriva attraverso tre vettori che ogni token produce da sé:

• Query: cosa sto cercando. La query di «pesce» chiede: qual è il verbo o il complemento che mi qualifica?
• Key: cosa offro. La key di «nuota» annuncia «sono un’azione da essere vivente»; quella di «piatto» annuncia «sono un contenitore da tavola».
• Value: cosa porto davvero, cioè l’informazione che verrà effettivamente mescolata dentro chi mi ha scelto.

Il punteggio fra due token è il prodotto scalare fra la Query dell’uno e la Key dell’altro, diviso per la radice di d_k, nel modello base del paper d_k vale 64, quindi si divide per 8, e serve solo a tenere i numeri in un intervallo dove la softmax non satura. La formula è tutta lì: softmax(QKᵀ/√d_k)·V. La softmax trasforma i punteggi grezzi in pesi che sommano esattamente a 1: se «pesce» distribuisse 0,55 su «nuota», 0,25 su «il» e 0,20 su se stesso, l’uscita sarebbe quella media pesata dei Value. I tre numeri sono inventati per l’esempio; il vincolo che sommino a 1 non lo è, ed è ciò che rende l’attention una redistribuzione di attenzione finita e non un’aggiunta gratuita di informazione.

Ora il conto vero. Con n token servono n×n punteggi. Dieci token: 100 confronti. Venti token: 400. Mille token: un milione. Duemila: quattro milioni. Raddoppiare la lunghezza quadruplica il lavoro di lettura, sempre.

Multi-head attention: otto attenzioni in parallelo, non una

E non è nemmeno una griglia sola. Il modello base del paper ha 8 teste di attenzione (h = 8), ciascuna con d_k = d_v = 64, che ricomposte tornano al d_model di 512. Ogni testa impara una relazione diversa, chi è il soggetto, a chi si riferisce quel «lo», con cosa concorda quell’aggettivo, e le loro uscite vengono concatenate e riproiettate. Su 6 strati di encoder, un prompt da 1.000 token produce quindi 1.000.000 × 8 × 6 = 48 milioni di prodotti scalari, ognuno su 64 dimensioni: circa 3 miliardi di moltiplicazioni solo per calcolare i punteggi. Ed è il transformer del 2017, che oggi si considera minuscolo.

Quando questo ti costa: latenza, contesto pieno, conto della serva

Il primo costo è il tempo, e lo paga l’utente. Ogni volta che un’interfaccia riceve un contesto lungo, il prefill va rifatto prima di poter scrivere la prima parola: un agente che riceve in pasto tutto lo storico della conversazione a ogni giro sconta quel ritardo a ogni giro. Il quadrato, però, sta nel numero di operazioni, non nella memoria: da FlashAttention (2022) in poi i kernel usati per servire i modelli non tengono mai in memoria la griglia n×n intera, la calcolano a blocchi e la consumano man mano, con un’occupazione che cresce in modo lineare. Il vero divoratore di memoria a contesto lungo è un altro: la cache di Key e Value, cioè i vettori dei token già letti che vanno conservati per generare i successivi, e che crescono linearmente col numero di token. È la somma di questi due, compute quadratico in prefill, cache KV lineare ma pesante, il motivo per cui i fornitori mettono un tetto alla finestra, anche quando le finestre da un milione di token diventano lo standard.

Il terzo costo è quello che finisce sul conto, e va guardato con i prezzi in mano. La documentazione di Google segna per Gemini 3.1 Pro Preview 2 dollari per milione di token in input fino a 200.000 token e 4 dollari sopra quella soglia, con l’output che passa da 12 a 18 (Gemini API pricing). Sul listino di agosto 2026, per Sonnet e Opus 4.6, Anthropic sceglie l’opposto e lo scrive esplicitamente: la finestra da 1 milione è a prezzo standard, «una richiesta da 900k token è fatturata alla stessa tariffa per token di una richiesta da 9k» (Claude pricing). Due strategie diverse sullo stesso problema fisico: uno lo scarica sul listino a scalini, l’altro lo assorbe, con l’avvertenza che sulla finestra da 1M, quando era in beta, una maggiorazione oltre i 200.000 token esisteva, quindi vale come scelta di listino del momento e non come strategia permanente.

Perché «i prompt lunghi costano di più perché l’attention è quadratica» è una frase imprecisa

Questa è la parte che distingue chi ha capito da chi ripete, e vale anche come limite della spiegazione qui sopra. Il costo quadratico riguarda la lettura del prompt. In generazione non si ricalcola nulla da zero: le Key e le Value dei token già visti restano in cache, quindi ogni nuovo token costa in proporzione a quelli che lo precedono, lineare, non quadratico. E soprattutto: si paga a token, non a confronti. Su Claude Sonnet 4.6 a 3 dollari per milione, 1.000 token di input costano 0,003 dollari e 2.000 token ne costano 0,006: il doppio, non il quadruplo. Il quadrato non è in fattura. Sta nella latenza, nella memoria e nella ragione economica per cui certi listini mettono uno scalino a 200.000 token.

Cosa si fa per non pagare un contesto che non serve

Tre mosse, in ordine di resa.

Ridurre il contesto che entra nell’attention

Tagliare invece di caricare. Il contesto non è un serbatoio: ogni token in più entra in tutte le griglie, in tutte le teste, in tutti gli strati. Incollare un PDF intero perché «magari serve» è la versione moderna del cc: tutti. Vale la pena rileggere le regole di base su cos’è un prompt e come si scrive in modo efficace: la selezione è quasi sempre più efficace dell’abbondanza.

Riassumere lo storico. In una conversazione lunga o in un agente che gira in loop, sostituisci i turni vecchi con una sintesi compatta e tieni per esteso solo gli ultimi. Meno token in prefill, meno attesa sul primo carattere.

Il prompt caching taglia il costo del contesto che non cambia

Mettere in cache la parte che non cambia. Qui il numero è netto. La documentazione di Anthropic sul prompt caching dà i moltiplicatori sul prezzo base dell’input: 1,25× per scrivere la cache a 5 minuti, 0,1× per rileggerla. Con 100.000 token di istruzioni e documenti fissi su Sonnet 4.6, dieci turni a prezzo pieno fanno 10 × 0,30 = 3,00 dollari; con la cache fanno 0,375 + 9 × 0,03 = 0,645 dollari. Circa il 78% in meno, a parità di risposta.

Nessuna delle tre è una scelta tecnica: sono decisioni su cosa il sistema ha il diritto di leggere ogni volta. È esattamente il punto in cui un progetto pilota diventa una voce di budget, e conviene affrontarlo prima, abbiamo scritto come si decide, con tre schemi visti in produzione, come si sceglie cosa dare in pasto a un agente che gira ogni giorno.

Un’ultima nota di onestà: la latenza qui non la abbiamo misurata noi con un banco di prova pubblicabile, e non inventiamo secondi. Il test del cronometro descritto all’inizio, però, lo può rifare chiunque in due minuti, ed è il modo più rapido per vedere con i propri occhi la differenza fra ciò che cresce lineare e ciò che cresce col quadrato.

Guardare tutto il contesto insieme è la svolta che ha reso possibili i modelli di oggi, e sta al centro di una catena più lunga: il percorso da una frase alla risposta mostra cosa viene prima dell’attention e cosa viene dopo.

Fonti:

• Vaswani et al., «Attention Is All You Need» — testo integrale in HTML (arXiv v7)
• Gemini API pricing — listino ufficiale Google
• Claude pricing — listino ufficiale Anthropic
• Prompt caching — documentazione Anthropic