LLM 101: Una guida pratica (Edizione 2026)

Inizia con il ciclo. Il testo diventa token. I token attraversano un Transformer. L'attenzione decide quali token precedenti sono importanti. Il runtime mantiene una cache KV in modo che il modello non ricalcoli l'intera conversazione ogni volta. Poi il modello sceglie il token successivo e ripete il ciclo.

Una guida pratica su come funzionano gli LLM, come i modelli pensano un token alla volta e come eseguirli localmente.

Una volta che questo ciclo è chiaro, le scelte hardware e software diventano più facili da valutare. VRAM, quantizzazione, lunghezza del contesto, template di chat, decodifica, RAG, motori di serving e selezione dei modelli derivano tutti dagli stessi meccanismi.

Inizia con il ciclo: token in ingresso, probabilità in uscita, un token alla volta. I pesi dicono al modello quali pattern ha appreso. Il contesto gli dice cosa sta guardando ora. La cache KV è la memoria di lavoro che rende il ciclo utilizzabile. Hardware, runtime e selezione del modello hanno senso solo dopo aver capito la memoria, il contesto e le regole di formattazione che il modello sta rispettando.

L'obiettivo è rendere intuitive prima di tutto le meccaniche degli LLM locali, poi darti un percorso pratico verso hardware, runtime, serving e la ricerca attuale sugli LLM aggiornata al 21 maggio 2026.

Focus

Questa è una guida incentrata sul modello. Inizia con le meccaniche: inferenza, token, Transformer, attenzione, cache KV, prefill, decode, controlli di decodifica, pacchetti di modello, template di chat, tipi di modello, contesto lungo, RAG, agenti, fine-tuning e modelli multimodali.

Dopo, passa al livello di deployment locale: cosa significa realmente locale, quantizzazione, calcoli sulla VRAM, livelli hardware, scelte del runtime, modalità di serving, licenze, selezione del modello, privacy, risoluzione dei problemi, benchmark, percorsi di configurazione e casi d'uso pratici.

Quest'ordine è importante. Dovresti capire perché un prompt lungo costa memoria prima di scegliere una GPU. Dovresti capire perché i template di chat sono importanti prima di giudicare un modello. Dovresti capire perché la decodifica è sequenziale prima di preoccuparti dei token al secondo.

Per il percorso più approfondito su hardware e software, ho una serie in tre parti che insegna LLM self-hosted / AI locale:

I primi due articoli spiegano la capacità hardware e la matematica della larghezza di banda. Il terzo spiega il livello software che trasforma quell'hardware in inferenza utilizzabile. Questo articolo ti fornisce prima le basi dal lato modello, poi ti rimanda a quei livelli di deployment una volta chiare le meccaniche.

Cosa Fa Realmente un LLM

Eseguire un modello si chiama inferenza. Per un LLM decoder-only standard, l'inferenza è lo stesso ciclo ripetuto all'infinito:

Converti il tuo testo in token.
Inserisci quei token nel modello.
Calcola i punteggi per ogni possibile token successivo.
Scegli un token con una politica di decodifica.
Aggiungi quel token alla sequenza.
Ripeti finché il modello si ferma, l'utente lo ferma o viene raggiunto un limite di token.

Il modello non sta scrivendo un'intera risposta in un colpo solo. Genera un token alla volta. Ogni nuovo token diventa parte della sequenza che influenza il token successivo.

Matematicamente, il modello è una funzione appresa:

f(theta, sequenza) -> distribuzione di probabilità sul prossimo token

Dove:

theta indica i pesi del modello.
sequenza indica il prompt più i token generati finora.
I logit sono i punteggi grezzi prima della softmax.
Le probabilità sono i punteggi normalizzati dopo la softmax.
La decodifica trasforma quelle probabilità in un token selezionato.

Ecco perché la velocità di generazione locale si misura in token al secondo. Il tuo sistema esegue ripetutamente un forward pass, seleziona o campiona un token, aggiorna la cache KV e continua.

La percezione conta qui. Un prefill lungo significa una lunga pausa prima che appaia la prima parola. Una decodifica lenta significa che la risposta arriva lentamente. I costruttori locali spesso si ossessionano sulla velocità di decodifica perché è ciò che gli utenti percepiscono, ma il tempo di prefill è ciò che fa male quando incolli un documento di 10.000 token.

Token

Gli LLM non vedono il testo grezzo come parole. Vedono token: piccoli frammenti di testo rappresentati internamente come ID interi.

Un token può essere:

Una parola intera: "ciao"
Un frammento di parola: "inter", "nazion", "ale"
Un segno di punteggiatura
Una stringa preceduta da spazio
Un fallback a livello di byte
Un marcatore di controllo speciale come <|user|>, <|assistant|>, <bos>, <eos>

Il tokenizer mappa il testo in ID di token e viceversa. Le famiglie comuni di tokenizer includono tokenizer stile BPE e tokenizer stile SentencePiece. Diverse famiglie di modelli usano tokenizer diversi, e questo è importante. Un documento di 4.000 parole può essere 5.000 token in un tokenizer e 7.500 in un altro.

Anche la dimensione del vocabolario è importante. Un tokenizer con un vocabolario più grande può comprimere del testo in meno token, ma cambia anche la dimensione dell'embedding e della proiezione di output. Questo è uno dei motivi per cui i token al secondo non sono perfettamente confrontabili tra famiglie di modelli.

I token sono importanti perché determinano:

Quanto testo entra nella finestra di contesto.
Quanto grande diventa la cache KV.
Quanta latenza paghi durante l'elaborazione del prompt.
Se il testo multilingua o ricco di codice è efficiente.
Se il modello vede correttamente i marcatori speciali di chat.

La finestra di contesto di un modello è il numero massimo di token a cui può prestare attenzione contemporaneamente. Nel 2026, i modelli locali comuni vanno da contesti di 8K e 32K a 128K, 256K e persino 1 milione di token nei sistemi di classe server.

Ma la lunghezza del contesto supportata non è la stessa cosa di un contesto economico, veloce o ugualmente accurato. Un modello che può tecnicamente gestire 128K token potrebbe rallentare drasticamente a 64K e perdere coerenza a 100K. Testa sempre le lunghezze di contesto che intendi effettivamente utilizzare.

I token sono l'unità di lavoro. Una volta capito questo, il contesto lungo smette di sembrare magico e inizia a sembrare un conto che puoi stimare.

Esercizio utile: Prova la mia app demo del tokenizer per vedere come il testo viene suddiviso in token in tempo reale.

Transformer

La maggior parte degli LLM moderni si basa sull'architettura Transformer. La maggior parte degli LLM di chat locali sono Transformer decoder-only: predicono il token successivo guardando indietro ai token precedenti.

Tutto quanto sopra, inclusi token, pesi, configurazione e template di chat, è la preparazione per il vero motore sottostante. Il Transformer è lo scheletro che sposta i numeri.

Un livello Transformer semplificato contiene:

Embedding dei token: gli ID dei token diventano vettori.
Informazioni posizionali: il modello ha bisogno dell'ordine dei token. Molti LLM moderni usano RoPE (Rotary Position Embeddings), che codifica la posizione ruotando le rappresentazioni.
Self-attention: ogni rappresentazione di token guarda indietro alle rappresentazioni dei token precedenti e decide cosa è importante.
Blocco MLP/feed-forward: un calcolo non lineare denso che espande e comprime le rappresentazioni. Una grande frazione dei parametri vive qui.
Normalizzazione dei layer e connessioni residue: stabilizzano le reti profonde e aiutano il flusso di informazioni attraverso molti livelli.
Proiezione di output: lo stato nascosto finale diventa logit sull'intero vocabolario.

Impila questa ricetta decine o centinaia di volte e ottieni un modello linguistico.

Riassunto del Transformer: i token diventano vettori, l'attenzione connette la sequenza, gli MLP rimodellano la rappresentazione, RoPE mantiene diritta la posizione e la proiezione finale trasforma l'ultimo stato nascosto in logit per il token successivo.

Attenzione

L'attenzione è il modo in cui un token decide quali token precedenti sono importanti per la prossima predizione. È anche uno dei motivi per cui l'inferenza locale è così sensibile alla memoria.

La MHA classica (multi-head attention) memorizza stato chiave/valore separato per molti head. Dà flessibilità al modello, ma rende la cache KV grande.

I modelli locali moderni spesso usano progetti di attenzione più efficienti:

MQA: più query head condividono un singolo key/value head. È efficiente in memoria, ma può essere meno espressivo.
GQA: gruppi di query head condividono key/value head. È il compromesso comune in molti modelli locali attuali.
MHA: attenzione multi-head completa. Può essere potente, ma il contesto lungo diventa rapidamente costoso.

Kernel moderni come FlashAttention e implementazioni stile SDPA riducono il traffico di memoria dell'attenzione e mantengono la GPU più occupata. Un runtime con buoni kernel di attenzione può essere drammaticamente più veloce di uno senza, anche sullo stesso modello e hardware.

Questo è il motivo per cui due modelli da 7B possono comportarsi in modo molto diverso con contesto lungo. Il numero di parametri non è tutta la storia. Un modello 7B MHA con contesto a 128K può esaurire una GPU da 24 GB, mentre un modello 7B GQA con lo stesso contesto pubblicizzato potrebbe starci con spazio extra.

Quando confronti i modelli, guarda il tipo di attenzione, il numero di head KV, la lunghezza del contesto e il supporto del runtime, non solo il numero di parametri.

Cache KV

La cache KV è la memoria di lavoro del modello durante la generazione. Memorizza gli stati di attenzione chiave/valore per i token precedenti, in modo che il modello non debba ricalcolare l'intera storia da capo per ogni token generato.

Senza una cache KV, la generazione sarebbe brutalmente inefficiente. Con una cache KV, la generazione è utilizzabile, ma la cache consuma memoria proporzionale a:

token x layer x kv_heads x head_dim x precisione x 2

Il x 2 è per chiavi e valori.

Una regola pratica utile per i vecchi modelli MHA da 7B simili a Llama è circa 0,5 MiB per token in cache KV FP16. Ciò significa che 4K token possono costare circa 2 GiB solo di cache KV. A 32K token, potresti guardare a 16 GiB di sola cache KV.

I modelli GQA/MQA più recenti riducono sostanzialmente questo valore. Alcuni runtime supportano anche cache KV in FP8 o INT8. Questa è spesso la soglia di compressione pratica che raccomanderei per gli utenti locali nel 2026.

Non trattare la cache KV sotto gli 8 bit come predefinita. Sistemi di ricerca come KIVI, KVQuant e kernel di cache compressa più recenti mostrano che cache KV a 2-4 bit possono funzionare con algoritmi attenti, calibrazione e kernel personalizzati. Questo non è la stessa cosa di attivare casualmente un interruttore Q4 KV in un runtime desktop. Sotto gli 8 bit, fai benchmark approfonditi, specialmente per coding, chiamate a strumenti, JSON, recupero in contesto lungo e attività in cui token esatti precedenti sono importanti.

Inoltre, non confondere la quantizzazione della cache KV con la decodifica speculativa. DFlash e DDTree, spesso abbreviati informalmente come DTree, attaccano la latenza di decodifica abbozzando token futuri e verificandoli. Possono migliorare la velocità, ma non cancellano il costo di memoria della cache KV.

Questo è il motivo per cui un modello può stare in memoria con un prompt vuoto ma crashare quando carichi un documento lungo. I pesi ci stanno. La memoria di lavoro no.

Prefill e Decode

L'inferenza degli LLM ha due diversi regimi di prestazioni: prefill e decode.

Il prefill elabora il prompt che hai dato al modello. Se incolli un documento di 20.000 token, il modello deve elaborare quei 20.000 token prima di poter produrre il primo token di risposta. Il prefill è relativamente parallelizzabile, quindi le GPU possono gestirlo efficientemente, ma può comunque essere costoso.

Il tempo che aspetti per la comparsa del primo token è di solito il tempo di prefill.

La decodifica genera nuovi token uno alla volta. Ogni token generato dipende dalla sequenza finora, quindi la decodifica è molto più sequenziale. È qui che nasce l'effetto di digitazione in streaming, ed è di solito la fase che determina se un modello sembra veloce o lento.

I prompt lunghi penalizzano il prefill. Le risposte lunghe penalizzano la decodifica. Le conversazioni lunghe penalizzano entrambi perché la cache KV cresce.

In una sessione di chat, ogni turno aggiunge alla cache. Se lasci che una conversazione arrivi a 16K token, stai pagando il costo di memoria per tutti i 16K token per ogni nuovo token generato. Questo è il motivo per cui le UI di chat che mantengono una cronologia infinita alla fine rallentano o crashano.

Decodifica

Dopo che il modello produce i logit, non ha ancora scritto nulla. Ha solo valutato ogni possibile token successivo. La decodifica è la politica che trasforma quei punteggi in un token effettivo, aggiunge quel token al contesto e ripete il ciclo.

Il runtime, o motore di inferenza, può scegliere i token in diversi modi. Può selezionare il token con la probabilità più alta ogni volta. Può campionare da un insieme ristretto di token probabili. Può penalizzare le ripetizioni. Può fermarsi a un delimitatore. Può usare un seed fisso in modo che lo stesso prompt si comporti in modo riproducibile.

Queste scelte non cambiano i pesi del modello, ma cambiano la voce del modello, la determinismo, la creatività, il profilo di rischio e la tendenza a ripetersi.

Le manopole importanti rispondono a tre domande pratiche:

Casualità: quanta variazione è consentita?
Portata della coda: quanto in profondità nei token a bassa probabilità può andare il campionatore?
Confini: cosa impedisce cicli, divagazioni, rotture dello schema o output fuori controllo?

Per lavori precisi, inizia in modo restrittivo: temperatura bassa, limiti massimi di token brevi, sequenze di stop esplicite e decodifica vincolata quando l'output deve corrispondere a JSON o a uno schema. Per lavori creativi, lascia più spazio al campionatore con temperatura più alta, top-p e più candidati classificati successivamente. Per il coding, mantieni conservativo il primo passaggio, poi campiona alternative solo quando stai esplorando intenzionalmente.

La decodifica greedy non è sempre più accurata. Spesso è fragile. Un decoder greedy può bloccarsi in cicli o produrre risposte generiche perché non esplora mai alternative. Per le valutazioni, usa impostazioni deterministiche. Per l'ideazione, lascia respirare il modello.

Cosa Contiene un Pacchetto di Modello

Un LLM locale eseguibile è più di un singolo grande file di pesi. Un pacchetto di modello di solito include:

Architettura/configurazione: numero di layer, dimensione nascosta, tipo di attenzione, impostazioni RoPE, dimensione del vocabolario, token speciali e lunghezza del contesto.
Pesi: i parametri appresi, spesso memorizzati come safetensors, GGUF, GPTQ, AWQ, EXL2 o altri formati specifici del runtime.
Tokenizer: le regole che trasformano il testo in ID di token e viceversa.
Template di chat: il markup esatto per messaggi di sistema, utente, assistente, strumento e ragionamento.
Configurazione di generazione: valori predefiniti per temperatura, top-p, token di stop, penalità di ripetizione e token massimi.
Licenza e scheda del modello: le istruzioni legali e operative su come può essere utilizzato il modello.

I pesi sono il file più grande, ma non sono l'intero modello. Se il tokenizer, la configurazione o il template di chat è sbagliato, gli stessi pesi possono sembrare rotti.

La sezione del pacchetto ti dice cosa deve viaggiare insieme. La prossima sezione spiega perché il template di chat è la parte che le persone rompono più spesso.

Template di Chat

Un modello di chat è stato addestrato con un formato di conversazione specifico. Ad esempio, potrebbe aspettarsi qualcosa come:

<|system|> Sei un assistente utile. <|user|> Spiega la cache KV. <|assistant|>

Un altro modello potrebbe aspettarsi:

[BOS] [INST] Spiega la cache KV. [/INST]

Un altro potrebbe usare marcatori in stile ChatML. Un altro potrebbe richiedere token speciali di ragionamento. Un altro potrebbe aver bisogno di wrapper XML o JSON per le chiamate a strumenti.

Usare il formato sbagliato può causare parole senza senso, confusione di ruoli, prompt di sistema ignorati, prompt ripetuti, stranezze nei rifiuti, chiamate a strumenti non funzionanti, risultati di benchmark negativi e conclusioni che il modello è stupido quando il template è il vero bug.

Buona prassi:

Usa apply_chat_template del tokenizer quando usi Transformers.
Usa template specifici del modello nei frontend basati su Harbor, llama.cpp, LM Studio, vLLM o SGLang.
Controlla se il modello è base, instruct, chat, reasoning o tool-tuned.
Assicurati che i token BOS/EOS siano corretti.
Tieni i prompt di sistema brevi a meno che non debbano essere lunghi.
Per l'uso di strumenti, segui lo schema esatto previsto dal modello/runtime.

Se stai costruendo un'applicazione che permette agli utenti di cambiare modello, hai bisogno anche del cambio di template. Hardcodare un formato di template e poi caricare un modello che ne prevede un altro è una causa comune di valutazioni errate dei modelli locali.

Tratta il template come un contratto API. Se lo sbagli, non stai realmente testando il modello che pensi di testare.

Tipi di Modello

Non tutti gli LLM sono ottimizzati per lo stesso comportamento.

Per la maggior parte degli utenti, il punto di partenza predefinito dovrebbe essere un modello recente instruct/chat-tuned in una dimensione che stia comodamente in memoria.

Non iniziare con un modello base a meno che tu non sappia perché. I modelli base completano il tuo prompt piuttosto che rispondere. Sono utili per ricercatori, fine-tuner e persone che costruiscono pipeline personalizzate. Sono frustranti per tutti gli altri.

Se chiedi a un modello base "Qual è la capitale della Francia?", potrebbe continuare con "e qual è la popolazione di Parigi?" invece di rispondere "Parigi".

La divisione pratica è semplice:

Modello base: buono per ricerca sul pre-training, fine-tuning e pipeline personalizzate.
Modello instruct: buono per seguire istruzioni dirette.
Modello chat: buono per dialoghi a più turni con formattazione dei ruoli.
Modello reasoning: buono quando l'attività beneficia di token di pensiero extra e verifica.
Modello tool-tuned: buono quando chiamate strutturate, JSON o uso di funzioni sono importanti.

Cosa Significa Realmente Locale

Un LLM locale è un modello i cui pesi e runtime di inferenza sono sotto il tuo controllo. Decidi tu quale modello esegue, come esegue, quali dati vede e cosa succede agli output.

Questa libertà comporta lavoro. Ora sei tu il team operativo. Gestisci download, aggiornamenti, compatibilità, limiti di memoria e sicurezza. Quando qualcosa si rompe, non c'è un ticket di supporto da aprire. Ci sei solo tu, i log e la documentazione.

Locale può significare:

Un modello da 2 miliardi di parametri eseguito su un telefono.
Un modello da 7 a 14 miliardi eseguito su una GPU consumer.
Un modello da 30 a 70 miliardi eseguito su una workstation di fascia alta.
Un modello MoE sparso eseguito su una o più GPU da datacenter.
Un deployment privato che usa vLLM, SGLang, TensorRT-LLM, llama.cpp, Harbor, LM Studio o uno stack PyTorch personalizzato.

Il punto chiave: locale non significa automaticamente offline, privato, sicuro, economico o open-source. Significa solo che stai eseguendo il modello da solo. Un'app locale può comunque chiamare casa. Un modello può essere open-weight ma non open-source. Un modello può essere locale ma non sicuro da caricare. Un modello quantizzato può stare in memoria ma rispondere male.

Il compromesso vale la pena quando hai bisogno di privacy, bassa latenza, comportamento personalizzato, funzionamento offline o controllo dei costi su larga scala. Non vale la pena quando hai bisogno della qualità assoluta del modello migliore e non hai l'hardware adatto. In quel caso, un'API ospitata è lo strumento giusto.

Gli LLM locali sono pratici quando capisci un'equazione:

Successo LLM locale = adattamento del modello + formato prompt corretto + runtime buono + valutazioni realistiche.

Tutto il resto sono dettagli. I dettagli contano.

Quantizzazione

La quantizzazione memorizza i pesi a precisione ridotta per ridurre la memoria e talvolta migliorare il throughput.

La regola pratica del 2026 per gli utenti locali:

FP16/BF16: migliore qualità quando la memoria è abbondante. Usalo come baseline per la valutazione.
Q8 / INT8: quasi senza perdita per molti compiti, ma ancora grande. Buono quando hai VRAM e vuoi una perdita di qualità minima.
Q6 / Q5: qualità eccellente con risparmi moderati. Questo è un buon compromesso.
Q4: il punto dolce consumer predefinito per molti flussi di lavoro di chat e documenti.
Q3 / Q2: solo quando devi far stare un modello più grande. Matematica, codice, output strutturato e uso di strumenti si degradano per primi.

La quantizzazione dei pesi non è la stessa cosa della quantizzazione della cache KV. La quantizzazione dei pesi riduce il modello. La quantizzazione della cache KV riduce la memoria del contesto attivo.

Per la cache KV, considera FP16/BF16 come la baseline pulita e FP8/INT8 come il pavimento pratico di compressione locale. Sotto gli 8 bit è ricerca pesante e sensibile al carico di lavoro. Usalo solo dopo aver misurato la qualità sui tuoi prompt reali.

Il fallimento della quantizzazione si manifesta prima in matematica, ragionamento multi-step, correttezza del codice, affidabilità dell'uso di strumenti, aderenza a JSON/schema, seguire istruzioni sottili e recupero in contesto lungo.

Un modello più piccolo a precisione più alta può battere un modello più grande schiacciato in troppo pochi bit. Non adorare il numero di parametri. Un modello da 7B a Q6 può battere un modello da 13B a Q2 in compiti di ragionamento usando meno memoria e correndo più veloce.

Formati di File e Sicurezza di Caricamento

safetensors è un formato di serializzazione tensoriale sicuro progettato per memorizzare tensori senza il comportamento pickle di Python. Usa safetensors quando possibile, specialmente per modelli PyTorch/Transformers.

Evita file .bin casuali da fonti non fidate. Il caricamento basato su pickle di PyTorch può eseguire codice arbitrario durante la deserializzazione. Regola numero uno della sicurezza AI locale: non lasciare che il file di modello di uno sconosciuto diventi esecuzione di codice di uno sconosciuto.

GGUF è il formato di modello binario dell'ecosistema llama.cpp. Usa GGUF quando vuoi llama.cpp, inferenza su CPU, inferenza su Apple Silicon, server locali semplici, modelli quantizzati portatili o strumenti desktop come LM Studio.

ONNX è utile per deployment standardizzati e accelerazione hardware specifica, specialmente al di fuori del solito stack PyTorch. Se stai distribuendo su NPU Intel, dispositivi ARM o acceleratori personalizzati, ONNX è spesso il percorso di minor resistenza.

TensorRT-LLM è il percorso di inferenza ad alte prestazioni di NVIDIA per deployment GPU in produzione. È potente, ma più complesso di llama.cpp o Harbor. Di solito converti un checkpoint in motori TensorRT, il che richiede tempo e memoria GPU, ma una volta costruito offre un throughput eccellente.

I formati EXL2 / GPTQ / AWQ sono comuni nelle comunità di inferenza locale focalizzate su GPU, specialmente per comprimere modelli più grandi su singole GPU.

La scelta del formato file non è estetica. Determina quali runtime possono caricare il modello, quale quantizzazione puoi usare e quanto velocemente gira.

Runtime e Modalità di Serving

Un runtime è il software che carica il modello ed esegue l'inferenza. Nel 2026, l'ecosistema dei runtime per LLM locali è maturo, utile e frammentato.

Per una singola persona che sperimenta localmente, inizia con Harbor, LM Studio o llama.cpp. Harbor è la scelta migliore quando vuoi uno stack locale completo con frontend, backend e servizi di supporto collegati insieme. LM Studio è il percorso desktop-first più semplice. llama.cpp è il cavallo di battaglia portatile di basso livello.

Per un team o un servizio privato, guarda a vLLM o SGLang. Per le massime prestazioni di produzione NVIDIA, investiga TensorRT-LLM. Per deployment su browser o mobile, guarda a MLC o WebLLM.

La scelta del runtime spesso ti blocca in un ecosistema di formati. llama.cpp significa GGUF. vLLM e SGLang di solito significano safetensors o checkpoint Hugging Face. TensorRT-LLM significa motori ONNX o ottimizzati. Scegli prima il runtime, poi trova modelli nel formato giusto.

Ci sono tre modalità pratiche di serving.

Locale per singolo utente significa un'app desktop, stack CLI o server a riga di comando per una persona. Harbor, LM Studio, server llama.cpp, ExLlama/TabbyAPI e script Transformers piccoli rientrano tutti qui. L'obiettivo è iterazione rapida: confrontare comportamento, velocità, uso di memoria e formati di prompt senza costruire una piattaforma operativa.

API di team o privata significa un endpoint compatibile con OpenAI su una workstation o un server. vLLM, SGLang, TensorRT-LLM e server llama.cpp appaiono tutti qui a seconda della dimensione del modello e delle esigenze di throughput. Quando più persone o job condividono un modello, hai bisogno di monitoraggio, gestione di prompt/versioni, routing e misurazioni realistiche della latenza.

Il servizio in produzione è un lavoro diverso. Ora la conversazione include batching continuo, caching dei prefissi, decodifica speculativa, attenzione paginata, parallelismo dei tensori, parallelismo delle pipeline, serving quantizzato, output strutturati, bilanciamento del carico, utilizzo della GPU, percentili di latenza, caching dei prompt, controllo di ammissione, logging, failover, privacy e controllo dei costi.

Su scala produttiva, "posso caricare il modello?" è la domanda facile. La domanda difficile è: "posso servirlo in modo affidabile sotto traffico reale?"

Calcoli della VRAM per modelli locali

Ci sono tre principali consumatori di memoria:

Pesi del modello
Cache KV
Overhead del runtime

La formula approssimativa per la memoria dei pesi è:

memoria_pesi ~= parametri x byte_per_parametro

Approssimazioni utili:

FP16/BF16: circa 2 byte per parametro.
INT8/Q8: circa 1 byte per parametro.
Q4: circa 0,5 byte per parametro, più overhead del formato.

Poi aggiungi:

Overhead del runtime: buffer del framework, overhead di CUDA, frammentazione della memoria e tensori temporanei.
Cache KV: cresce con ogni token nel contesto attivo.
Memoria per batch/concorrenza: ogni richiesta concorrente necessita della propria cache.
Memoria per l'encoder visivo: anche le immagini diventano token.
Memoria per decodifica speculativa: i modelli draft, i draft head o le strutture extra di verifica non sono gratuiti.
Memoria per adapter: gli adapter LoRA sono piccoli, ma comunque reali.

I modelli MoE aggiungono un altro intoppo. Un modello può attivare solo una frazione dei suoi parametri per token, ma gli esperti inattivi di solito devono comunque risiedere da qualche parte in memoria. I parametri attivi influenzano il costo computazionale. I parametri totali influenzano ancora il caricamento e la pianificazione della capacità.

Una stima realistica assomiglia a:

memoria_totale = pesi_quantizzati + cache_KV_per_contesto + overhead_runtime + overhead_batch_o_concorrenza + margine_di_sicurezza

Ecco la trappola: un modello da 13B in Q4 può adattarsi facilmente con un contesto di 8K, ma fallire a 32K perché la cache KV è quadruplicata. I pesi non sono cambiati. Il contesto sì.

Lascia dal 10 al 20% di margine. Operare al 99% di utilizzo della VRAM è chiedere errori di memoria esaurita e fallimenti di frammentazione.

Fasce hardware nella pratica

Queste sono regole pratiche per il 2026, assumendo inferenza quantizzata e lunghezze di contesto ragionevoli. I risultati esatti dipendono da runtime, quantizzazione, architettura del modello, tipo di attenzione, lunghezza del contesto e overhead del sistema operativo/driver.

Per la maggior parte degli utenti locali seri nel 2026, 16 GB è il minimo praticabile per una GPU, 24 GB è il miglior rapporto qualità-prezzo per gli appassionati, e 48 GB+ è dove si apre il mondo locale più potente.

Le prestazioni dipendono da larghezza di banda della memoria, FLOP della GPU, capacità della VRAM, dimensione della cache KV, implementazione dell'attenzione, quantizzazione, dimensione del batch, lunghezza del prompt, lunghezza generata e maturità del runtime.

La decodifica è spesso limitata dalla larghezza di banda della memoria: la GPU trasmette ripetutamente i pesi mentre fa relativamente pochi calcoli per byte. Il prefill è più limitato dal calcolo perché può elaborare il prompt in parallelo. Ecco perché due schede con la stessa capacità di VRAM possono avere velocità di token molto diverse se una ha una larghezza di banda della memoria molto più alta.

La configurazione locale più dolorosa è quella in cui il modello quasi ci sta e riversa i livelli sulla CPU. Può tecnicamente funzionare, ma la velocità dei token può crollare. Lo scarico sulla CPU è accettabile per la sperimentazione. Non è una strategia per le prestazioni.

Scegli un modello che ci stia

La domanda pratica non è "qual è il modello migliore?" È "qual è il modello più piccolo che vince il tuo carico di lavoro reale sulla tua attrezzatura?".

Inizia con un modello instruct/chat recente che si adatta comodamente con la lunghezza del contesto di cui hai effettivamente bisogno. Se hai da 8 GB a 12 GB di VRAM o memoria unificata, inizia con modelli piccoli. Se hai da 16 GB a 24 GB, prova prima modelli della classe da 7B a 14B. Se hai 48 GB o più, modelli densi più grandi e modelli MoE diventano realistici.

Usa questo gate di memoria prima di innamorarti di un checkpoint:

pesi + cache KV + overhead runtime <= 80-90% della memoria disponibile

Poi esegui gli stessi 20-50 prompt tra i candidati. Includi i tuoi compiti reali: modifiche di codice, Q&A sui documenti, output JSON, riassunti, chiamate a strumenti, contesto lungo, o qualsiasi altra cosa ti serva. Misura la qualità delle risposte, la latenza, l'uso della memoria, l'affidabilità del template e le modalità di fallimento.

Una scelta pratica del modello di solito si riduce a cinque controlli:

Adattamento al compito: chat, coding, documenti, agenti, multimodale, edge o fine-tuning.
Adattamento della memoria: pesi, cache KV, overhead runtime e margine di sicurezza.
Adattamento dell'interfaccia: tokenizer, template di chat, token di stop, schema degli strumenti e modalità di ragionamento.
Adattamento del runtime: il tuo runtime supporta bene questa architettura, quantizzazione, lunghezza del contesto e modalità di serving?
Adattamento della licenza: puoi effettivamente usarlo dove intendi usarlo?

Le classifiche sono utili per la scoperta. Non sostituiscono le tue valutazioni. Il tuo carico di lavoro è il benchmark che conta.

Per un semplice assistente locale, scegli un modello instruct recente da 7B a 14B, quantizzazione Q4/Q5, il template di chat corretto, contesto da 8K a 32K, e Harbor, LM Studio o llama.cpp. Dai priorità alla reattività piuttosto che alle dimensioni enormi.

Per un assistente di coding locale, scegli un modello capace di codice da 14B a 32B se hai abbastanza VRAM. Usa temperatura bassa, recupero dal repository, esecuzione di test e un flusso di lavoro basato su patch. Un modello di codice senza strumenti è mezzo prodotto.

Per un assistente documentale privato, scegli un modello instruct forte, un modello di embedding locale, un reranker, una pipeline RAG, applicazione delle citazioni e contesto da moderato a lungo. Non incollare un PDF di 200 pagine e sperare.

Per una configurazione di ragionamento, scegli un modello ottimizzato per il ragionamento, stanzia token extra, usa temperatura da bassa a media, aggiungi verifica e usa strumenti per matematica, codice o ricerca. I modelli di ragionamento consumano più token. Pianifica di conseguenza.

Per una configurazione a basse risorse, scegli un modello da 1B a 4B, Q4/Q5, prompt brevi, compiti strutturati, recupero o strumenti e uno schema di output stretto. I modelli piccoli diventano utili quando il compito è vincolato.

Cosa controlla la velocità

I token al secondo non sono controllati da una sola cosa. Sono il risultato di dimensione del modello, larghezza di banda della memoria, calcolo, kernel di attenzione, lunghezza del contesto, quantizzazione, batching e qualità del runtime.

Le leve principali sono:

Larghezza di banda della memoria: la decodifica spesso trasmette ripetutamente i pesi del modello, quindi la larghezza di banda domina la velocità dei token per un singolo utente.
FLOP della GPU: il prefill e i grandi batch usano più calcolo parallelo, quindi i FLOP contano di più lì.
Capacità della VRAM: se il modello o la cache KV si riversano sulla CPU, le prestazioni possono crollare.
Implementazione dell'attenzione: FlashAttention, SDPA, attenzione paginata e kernel specifici del runtime cambiano sia la velocità che il comportamento della memoria.
Quantizzazione: pesi più piccoli riducono il movimento dei dati, ma una quantizzazione aggressiva può danneggiare la qualità e talvolta aggiungere overhead di dequantizzazione.
Dimensione del batch e concorrenza: il batching migliora il throughput, ma ogni sequenza attiva necessita della cache KV.
Lunghezza del prompt: i prompt lunghi aumentano il tempo di prefill.
Lunghezza generata: le risposte lunghe espongono la velocità di decodifica.
Decodifica speculativa: metodi come EAGLE, MTP, DFlash e DDTree possono verificare più di un token draft per passata di destinazione quando supportati.

La configurazione dolorosa è quella "quasi adatta". Un modello che riversa livelli o cache sulla CPU può tecnicamente funzionare, ma la velocità dei token può passare da accettabile a miserabile.

Fai benchmark esattamente con il runtime, la quantizzazione, la lunghezza del contesto, la forma del prompt e il carico di lavoro che intendi usare. Un numero in classifica BF16 non ti dice come si comporterà il tuo stack locale Q4.

Contesto lungo

Il contesto lungo sembra magico: 128K, 256K o addirittura 1 milione di token in un solo prompt. È utile, ma ha costi reali.

Più contesto significa più memoria della cache KV, elaborazione del prompt più lenta, più lavoro di attenzione, valutazione più difficile e più modi in cui il testo irrilevante può distrarre il modello. La qualità può anche degradare con la distanza. Un modello può gestire bene la fine di un documento lungo mentre perde dettagli critici sepolti vicino all'inizio.

Usa il contesto lungo per l'analisi dell'intero documento, sezioni di codebase, revisione legale o tecnica, riassunto di trascrizioni, ragionamento su più file e fallback RAG quando il recupero perde il contesto.

Non trattare il contesto lungo come un sostituto del recupero. È un complemento. Usa RAG per grandi corpora e contesto lungo per le prove finali selezionate.

Abitudini pratiche aiutano:

Metti le istruzioni critiche vicino all'inizio e vicino alla fine.
Usa intestazioni di sezione e delimitatori.
Chiedi citazioni legate a blocchi di origine.
Comprimi la cronologia irrilevante.
Usa la memoria di riepilogo invece della cronologia chat infinita.

Pensa al contesto lungo come a un'attenzione costosa, non a un taccuino gratuito.

Multimodalità

I modelli locali multimodali accettano immagini, e talvolta audio o video, oltre al testo. Gli ecosistemi open-weight moderni includono sempre più questi modelli.

Il costo nascosto è che anche l'input non testuale diventa token. Gli encoder visivi aggiungono memoria. I patch delle immagini consumano contesto. L'audio e il video possono far esplodere il budget di input. I template multimodali sono anche più facili da sbagliare rispetto a quelli solo testuali.

Una singola immagine ad alta risoluzione può consumare migliaia di token nella finestra di contesto. Se stai eseguendo un modello multimodale localmente, conta i token delle immagini allo stesso modo in cui conti i token di testo. Provengono dallo stesso budget.

I piccoli VLM possono allucinare dettagli visivi. L'affidabilità dell'OCR varia. Grafici e tabelle sono ancora difficili. Per flussi di lavoro seri su documenti o immagini, valuta con campioni reali. Non fidarti di una demo di una semplice foto per provare la qualità dell'estrazione delle fatture.

Il panorama dei modelli locali nel 2026

Il panorama dei modelli cambia rapidamente. Al 21 maggio 2026, gli utenti locali di LLM dovrebbero pensare in termini di famiglie ed ecosistemi, non di un unico modello migliore.

Qwen 3.5 / Qwen 3.6 è una famiglia open-weight importante perché copre l'intero stack: modelli piccoli per laptop, modelli densi di medie dimensioni per workstation, modelli MoE per serving multi-GPU, varianti FP8, contesto lungo, lavoro multilingue, coding, strumenti e flussi di lavoro agentici. Il messaggio pratico è semplice: Qwen è un'ottima famiglia predefinita quando si vuole un ecosistema che vada dagli esperimenti su laptop al serving locale serio.

Gemma 4 è importante perché Google DeepMind sta spingendo la famiglia verso un'implementazione locale utile: modelli edge efficienti, opzioni dense e MoE più grandi, multimodalità, contesto lungo sui modelli più grandi, ampio supporto linguistico, comportamento di coding/agente più forte e licenza Apache 2.0. Questa combinazione la rende degna di essere testata quando l'uso commerciale e l'implementazione sul dispositivo sono importanti.

Anche Kimi / Moonshot AI, GLM / Z.ai, DeepSeek, MiniMax e Mistral sono famiglie fondamentali da tenere d'occhio. Kimi è rilevante per il coding a lungo termine, il ragionamento multimodale, l'uso di strumenti e i flussi di lavoro agente. GLM è importante per agenti di coding, compiti a lungo termine, sistemi MoE e rilascio di modelli orientati all'implementazione. DeepSeek rimane influente per i grandi sistemi MoE, l'attenzione Multi-head Latent, DeepSeekMoE, i percorsi di serving FP8, l'attenzione sparsa e l'hosting autonomo ad alto throughput. MiniMax merita attenzione per carichi di lavoro agente pratici e modelli MoE efficienti per l'inferenza. Mistral conta ancora perché la sua gamma copre casi d'uso generalisti, coding, ragionamento, multimodalità e specialisti con un forte supporto all'implementazione.

Nemotron 3 è la famiglia di modelli open di NVIDIA per sistemi agente di livello produttivo su hardware NVIDIA. La famiglia include le dimensioni Nano, Super e Ultra, utilizza design ibridi Mamba-Transformer MoE ed è strettamente legata a TensorRT-LLM, NIM, Dynamo, percorsi Blackwell NVFP4/FP8 e implementazione di agenti enterprise. Trattala meno come una famiglia casuale per chat desktop e più come un segnale di dove NVIDIA vuole che vadano gli stack di serving open-weight.

L'AI a pesi aperti non è più solo Llama contro tutto il resto. Stai scegliendo un ecosistema: pesi, licenza, tokenizer, template, quantizzazioni, supporto runtime, percorso di serving, strumenti della community e modalità di fallimento.

Il modello denso Qwen 27B

Qwen 3.5 / 3.6 27B (Denso) è una delle opzioni a pesi pubblici più pratiche per gli utenti locali che si preoccupano di coding, lavoro multilingue, uso di strumenti, modalità pensiero/non pensiero e contesto lungo. Le schede dei modelli Qwen 3.5 27B e Qwen 3.6 27B descrivono percorsi di serving compatibili con OpenAI, impostazioni predefinite della modalità di pensiero, uso di strumenti e lunghezze di contesto fino a 262.144 token, con estensione del contesto più lungo tramite YaRN in framework supportati.

Qwen è un'ottima opzione predefinita per una configurazione con 2x RTX 3090 quando il runtime è configurato correttamente per coding, agenti o copertura multilingue.

Ricerca sull'inferenza

La frontiera del 2026 non è solo la qualità del modello. È anche l'efficienza dell'inferenza. PagedAttention attacca lo spreco di memoria della cache KV nel serving. La cache KV in FP8 è ora una funzionalità runtime pratica in sistemi come vLLM. DFlash e DDTree esplorano la decodifica speculativa con modelli draft a diffusione di blocchi e alberi draft. NVFP4 merita anche attenzione sull'hardware NVIDIA perché cambia la conversazione pratica sull'implementazione per gli stack supportati.

Parte di questo è pronto per la produzione. Parte è ancora ricerca. Parte conta solo se il tuo runtime lo supporta pulitamente. Non trattare i miglioramenti di velocità dei paper come una casella da spuntare in un'app desktop.

Modalità di fallimento e soluzioni

La maggior parte dei fallimenti degli LLM locali non sono misteriosi. Di solito derivano da adattamento della memoria, formattazione, supporto runtime, impostazioni di decodifica o qualità del recupero.

Memoria esaurita: i pesi, la cache KV, l'overhead runtime o la dimensione del batch non ci stanno. Usa un modello più piccolo, riduci il contesto, abbassa il batch/concorrenza, scegli una quantizzazione migliore o lascia più margine.

Incoerenze o confusione di ruolo: il template di chat, il tokenizer, il token BOS/EOS, l'interruttore della modalità di ragionamento o lo schema degli strumenti sono sbagliati. Verifica la scheda del modello e il template del runtime prima di incolpare la qualità del modello.

Primo token lento: il prefill è costoso. Accorcia il prompt, usa il caching dei prefissi, migliora il recupero, riduci il contesto o usa un runtime più veloce.

Streaming lento: la decodifica è il collo di bottiglia. Controlla la larghezza di banda della memoria, la quantizzazione, lo spill sulla CPU, il backend dell'attenzione, il supporto della decodifica speculativa e se il modello è semplicemente troppo grande per l'hardware.

Risposte errate sui documenti: probabilmente il recupero ha fallito. Ispeziona il testo analizzato, i confini dei chunk, i metadati, il recupero top-k, il reranking e l'ancoraggio delle citazioni.

Chiamate JSON o a strumenti errate: usa temperatura più bassa, decodifica vincolata, schemi più severi, esempi migliori e un modello ottimizzato per l'uso di strumenti.

Loop di ripetizione: riduci la temperatura o top-p, aggiungi penalità di ripetizione, controlla i token di stop e assicurati che il template non stia facendo vedere al modello la propria risposta come un nuovo prompt.

Inizia con i controlli noiosi. Risolvono più problemi del cambio di modello.

Come far crescere lo stack

Principiante: configurazione utile più semplice

Usa Harbor o LM Studio, un modello instruct recente da 4B a 9B, quantizzazione Q4, contesto da 8K a 32K e un'interfaccia chat integrata. Scarica due o tre modelli nella stessa classe di dimensione e confrontali sugli stessi prompt.

Obiettivo: imparare a fare prompt, confrontare modelli, capire velocità e memoria, ed evitare codice personalizzato all'inizio.

Intermedio: configurazione per sviluppatori

Usa llama.cpp o Transformers, GGUF o safetensors, un server locale compatibile con OpenAI, una semplice pipeline RAG e un piccolo set di valutazione. Chiama il tuo server locale da un'applicazione o script reale invece di usare solo un'interfaccia chat.

Obiettivo: costruire app locali, testare il recupero, misurare la qualità e servire da localhost.

Avanzato: configurazione di serving privato

Usa vLLM o SGLang, una o più GPU, un'API compatibile con OpenAI, monitoraggio, gestione di prompt/versioni, una suite di valutazione, RAG con reranking e sandboxing degli strumenti.

Obiettivo: servire utenti reali o flussi di lavoro interni, ottimizzare throughput e latenza, e mantenere sicurezza e osservabilità.

Esperto: ottimizzazione personalizzata

Usa TensorRT-LLM, kernel personalizzati, runtime specializzati, esperimenti di quantizzazione, decodifica speculativa, parallelismo multi-GPU, fine-tuning, distillazione e valutazioni di produzione.

Obiettivo: scambiare tempo di ingegneria per efficienza dell'inferenza, costi inferiori e maggiore qualità su larga scala.

La privacy non è automatica

Gli LLM locali migliorano la privacy perché prompt e output possono rimanere sulla tua attrezzatura. Ma locale non significa automaticamente sicuro.

Le minacce includono file di modello dannosi, caricamento di pesi basato su pickle, trust_remote_code non fidato, iniezione di prompt nei documenti recuperati, abuso di chiamate a strumenti, perdita di segreti tramite log, telemetria da app desktop, estensioni del browser o plugin, allucinazioni del modello in contesti ad alto rischio, violazioni di licenza e contaminazione dei dati durante il fine-tuning.

Una linea di base di sicurezza AI locale funzionante ha quattro abitudini:

Carica con attenzione: preferisci safetensors o GGUF da fonti affidabili, evita file .bin non fidati e non abilitare trust_remote_code con leggerezza.
Esegui con confini: usa un utente non privilegiato, contenitori o sandbox per gli agenti e disabilita l'accesso alla rete quando la privacy offline è importante.
Proteggi i segreti: tieni le credenziali fuori da prompt e indici RAG, rivedi le impostazioni di telemetria delle app desktop e valida le chiamate a strumenti prima dell'esecuzione.
Versiona ciò che conta: tieni traccia delle versioni di modello, prompt, adapter, runtime e quantizzazione, e registra abbastanza per il debug senza creare un disastro per la privacy.

La sicurezza dell'AI locale è per lo più una disciplina operativa noiosa. È anche così si evita di scaricare un checkpoint casuale, eseguirlo come root e trasformare l'AI locale in una compromissione locale.

Benchmark che contano

Fai benchmark dello stack che effettivamente eseguirai. Il punteggio in classifica BF16 di un modello non è la tua realtà locale Q4.

Misura qualità, latenza, memoria, affidabilità e idoneità operativa:

Qualità: correttezza sui tuoi compiti reali, non solo benchmark generici.
Latenza: tempo al primo token, token di decodifica al secondo e tempo end-to-end.
Memoria: memoria dei pesi, crescita della cache KV, picco di VRAM e margine sotto carico.
Formattazione: correttezza del template di chat, successo JSON/schema, affidabilità delle chiamate a strumenti e comportamento dei token di stop.
Recupero: fedeltà delle citazioni, ancoraggio delle risposte, comportamento in caso di prove mancanti e impatto del reranker.
Operazioni: tempo di avvio, comportamento di warmup, ripristino dopo crash, logging, privacy e tracciamento delle versioni.

Crea un piccolo set di valutazione con 30-100 prompt rappresentativi. Includi risposte attese o criteri di punteggio, misurazioni di latenza e memoria, categorie di fallimento, controlli di ancoraggio specifici per RAG, controlli di conformità JSON se pertinenti e revisione umana per compiti ambigui.

Poi confronta i modelli. Non lasciare che una classifica scelga il tuo stack locale al posto tuo.

Coding con modelli locali

Il coding è uno dei migliori casi d'uso per gli LLM locali perché i prompt spesso includono codice privato, la latenza è importante, l'iterazione è frequente, i costi API possono crescere rapidamente e i modelli locali possono integrarsi con editor, shell, grep, test runner e flussi di lavoro con patch.

La configurazione locale più potente per il coding non è un chatbot nudo. È un modello instruct capace di codice connesso a contesto mirato del repository, recupero sulla codebase, percorsi di file, snippet pertinenti, esecuzione di test e un ciclo di patch.

Mantieni la decodifica deterministica o a bassa temperatura. Chiedi patch invece di consigli vaghi. Esegui i test automaticamente. Tieni un piccolo set di valutazione di bug e compiti reali in modo da poter dire quando un nuovo modello è effettivamente migliore.

Non lasciare che un modello locale riscriva una grande codebase senza revisione. Locale non rende un agente di coding saggio. Rende solo il contesto privato, il ciclo più economico e l'integrazione più facile da controllare.

Gli agenti locali hanno bisogno di protezioni

Un LLM locale diventa molto più utile quando può usare strumenti: ricerca di file, comandi shell, automazione del browser, database, esecuzione di codice, calendari, sistemi di ticketing, API interne, database vettoriali, automazione domestica, robotica o dispositivi edge.

L'uso di strumenti cambia il modello di sicurezza. Un chatbot che allucina è fastidioso. Un agente con accesso al filesystem può cancellare cose. Un agente con accesso al browser può far trapelare segreti. Un agente con accesso alla shell può danneggiare la macchina più velocemente di quanto tu possa leggere i log.

La sicurezza degli agenti locali ha quattro livelli. Limita l'agente strettamente dandogli solo le directory, le API, l'accesso alla rete e le credenziali di cui ha effettivamente bisogno. Vincola l'esecuzione con sandbox, contenitori, utenti con privilegi minimi, conferme per azioni distruttive e argomenti di strumenti validati da schema. Tratta gli input come ostili perché documenti recuperati, pagine web, ticket ed email possono contenere iniezioni di prompt. Mantieni una traccia di audit registrando le chiamate a strumenti, le versioni del modello, i prompt e le approvazioni senza riversare segreti nei log.

Gli output strutturati aiutano, ma non sono un confine di sicurezza. Schemi JSON, decodifica vincolata e firme di funzione rendono più facile la validazione delle chiamate a strumenti. Non dimostrano che il modello ha capito la richiesta, scelto l'azione sicura o evitato istruzioni iniettate.

Per un uso serio degli strumenti, metti i controlli delle politiche al di fuori del modello.

RAG batte i prompt giganti

RAG significa Retrieval-Augmented Generation. Invece di infilare tutte le informazioni nel prompt, recuperi chunk pertinenti da una base di conoscenza e dai solo quei chunk al modello.

Un buon sistema RAG locale di solito ha: inserimento documenti, analisi, suddivisione in chunk, embeddings, un indice vettoriale, recupero, reranking, costruzione del prompt, generazione della risposta, controlli di ancoraggio e valutazione. Ogni fase è un punto di fallimento.

Un'analisi scadente trasforma le tabelle in spazzatura. Una suddivisione in chunk scadente divide la risposta attraverso i confini. Un recupero scadente restituisce paragrafi irrilevanti. Un reranking scadente seppellisce la risposta giusta al rango 20. Un buon modello non può rispondere in modo affidabile da prove che non ha mai ricevuto.

La maggior parte dei sistemi RAG scadenti non sono scadenti a causa dell'LLM. Sono scadenti a causa della suddivisione in chunk, del recupero, del reranking e della valutazione.

La strategia di chunking è il killer silenzioso. Chunk di dimensione fissa senza sovrapposizione possono dividere frasi e perdere contesto. Il chunking semantico o il chunking gerarchico con recupero del documento padre spesso funzionano meglio, ma non esiste una risposta universale. Devi valutare dimensione del chunk, sovrapposizione e regole di suddivisione sui tuoi documenti reali.

Un buon reranker può salvare un recupero mediocre. Nessun reranker può risolvere chunk che hanno perso la risposta durante l'inserimento.

Documenti e lavoro di conoscenza

Per i documenti privati, gli LLM locali eccellono: riassunti di trascrizioni di riunioni, revisione di contratti, Q&A su documentazione tecnica, sintesi di note di ricerca, bozze di email, ricerca di policy, assistenti interni di supporto e flussi di lavoro di conformità beneficiano tutti del mantenere il materiale di origine vicino alla macchina o all'organizzazione che lo possiede.

Il flusso di lavoro è semplice ma spietato. Analizza i documenti con cura, preserva i metadati di pagina e sezione, chunk semantico, usa embeddings e reranker, chiedi citazioni, separa le risposte dalle fonti dal ragionamento generale e valuta la fedeltà delle citazioni.

Non dare per scontato che il modello sappia cosa c'è nei tuoi documenti. Sa solo ciò che metti nel prompt o recuperi nel contesto.

Per le trascrizioni di riunioni, preserva le etichette dei relatori e i timestamp. Per la revisione di contratti, chunk per clausola o sezione invece del conteggio arbitrario di token. Per il Q&A sulla documentazione tecnica, includi numeri di pagina o ancore di sezione nei chunk recuperati in modo che il modello possa citare le fonti accuratamente.

Per il lavoro sui documenti, il tuo parser e il tuo retriever contano quanto il modello.

Implementazione edge

I modelli piccoli sono sempre più utili su telefoni, laptop, robot, gateway IoT, dispositivi di fabbrica, veicoli, dispositivi medici, apparecchiature da campo offline e app browser. L'edge non è solo una versione più piccola della workstation. Ha una serie diversa di vincoli.

La distribuzione edge è dominata da memoria ridotta, basso consumo energetico, limiti termici, connettività intermittente, requisiti di privacy, latenza in tempo reale, piccole finestre di contesto e un comportamento di fallback prevedibile. Su questi dispositivi, un modello piccolo e affidabile batte un modello grande e fragile.

Una configurazione edge pratica usa spesso un modello da 0,5B a 4B, una quantizzazione aggressiva dei pesi, prompt minuscoli, schemi fissi, flussi di lavoro assistiti da strumenti, embedding locali, caching e nessuna cronologia chat superflua.

Quando la connettività cade, un modello locale che continua a funzionare vale più di un modello più grande che fallisce. Il futuro dell'AI locale non è solo modelli giganti da workstation. Sono anche modelli piccoli che fanno lavoro utile vicino ai dati.

Un Manuale Operativo per LLM Locali

Usa questo come ultimo gate prima di fidarti di un modello locale per lavoro reale.

Scegli e adatta: Seleziona una famiglia di modelli adatta al compito, leggi la licenza, conferma i requisiti hardware, scegli un livello di quantizzazione e stima il costo totale di memoria. Non fermarti alla dimensione dei pesi. Includi KV cache, overhead runtime, batch/concorrenza e margine di sicurezza.

Carica e formatta: Preferisci safetensors o GGUF da fonti affidabili, evita file basati su pickle non verificati, verifica tokenizer e chat template, imposta intenzionalmente la lunghezza del contesto e scegli i parametri di decoding per il compito. Se il template è sbagliato, la valutazione è invalida.

Valuta e opera: Testa con prompt rappresentativi, misura il time to first token e la velocità di decoding, traccia il picco di memoria, valuta il recupero prima di aggiungere RAG, metti in sandbox gli strumenti prima di aggiungere agenti e fai fine-tuning solo dopo che metodi più semplici falliscono.

Versiona tutto ciò che conta: Modello, quantizzazione, runtime, prompt, chat template, adapter, modello di embedding, reranker, set di valutazione e profilo hardware. I sistemi locali sono più facili da controllare solo quando puoi riprodurre ciò che hai eseguito.

Fine-Tuning

Il fine-tuning modifica il comportamento del modello addestrandolo su dati aggiuntivi. Per gli utenti locali, i metodi più importanti sono LoRA e QLoRA.

LoRA congela il modello base e addestra piccoli pesi adapter a rango ridotto. Ciò riduce i parametri addestrabili e ti permette di mantenere più adapter leggeri. QLoRA estende questo concetto affinando attraverso un modello quantizzato a 4 bit congelato in adapter LoRA.

Fai fine-tuning quando hai bisogno di uno stile di scrittura coerente, un formato di output specifico per dominio, un comportamento di classificazione o estrazione ripetitivo, l'affidabilità del formato delle chiamate a strumenti, una personalità di assistente specializzata, un adattamento di dominio che RAG non può risolvere, o migliori prestazioni di modelli piccoli su un compito ristretto.

Non fare fine-tuning per primo. Prova quest'ordine: chat template corretto, prompt migliori, modello migliore, decoding migliore, RAG, reranking, esempi few-shot, poi fine-tuning.

La maggior parte dei problemi che sembrano "il modello non capisce il mio dominio" sono in realtà "il mio prompt è vago", "il mio template è sbagliato" o "il mio recupero è rotto".

Un buon piano di fine-tuning include dati puliti, split train/validation/test, valutazioni di base, comportamento target chiaro, revisione della sicurezza, controlli di overfitting, valutazioni di regressione, versioning degli adapter, revisione della licenza e un piano di rollback.

Pesi Aperti Non Significa Open Source

Nel 2026, l'espressione "modello aperto" viene spesso usata in modo approssimativo. Dovresti distinguere tra peso aperto, codice sorgente disponibile, open source e compatibile con locale.

Peso aperto di solito significa che puoi scaricare i pesi. Non significa automaticamente che puoi usare il modello commercialmente, modificarlo liberamente, addestrarlo sui suoi output, distribuirlo a qualsiasi scala o ignorare i requisiti di attribuzione.

Codice sorgente disponibile significa che il codice o i pesi sono visibili. Non significa necessariamente che la licenza sia open source.

Modello AI open source è un'affermazione più forte. La definizione di AI Open Source di OSI considera un sistema AI come comprensivo di architettura, parametri/pesi, codice di inferenza e informazioni e codice dati sufficienti per derivare i parametri. Questa è una barra molto più alta di "i pesi sono su Hugging Face".

Alcune licenze sembrano permissive ma contengono restrizioni: nessun uso competitivo, nessun addestramento sugli output, nessuna distribuzione al di sopra di una certa scala, esclusioni geografiche, requisiti di attribuzione, clausole sui brevetti o obblighi simili a copyleft sui derivati.

Regola: leggi la scheda del modello e la licenza prima di usare qualsiasi modello commercialmente. Un modello può essere eccellente, scaricabile e eseguibile localmente ma essere comunque inadatto per i tuoi vincoli legali o di distribuzione.

Glossario

Termini di Modello e Messa a Punto

Parametri Attivi: In un modello MoE, solo alcuni parametri sono usati per un dato token. Un modello può avere centinaia di miliardi di parametri totali ma molti meno parametri attivi per token.
Adapter: Un piccolo modulo addestrabile aggiunto a un modello base, spesso tramite LoRA.
Modello Base: Un modello preaddestrato non specificamente ottimizzato per chat o istruzioni.
Fine-Tuning: Addestramento aggiuntivo che modifica il comportamento del modello per un dominio target o uno stile di output.
Modello Istruttivo: Un modello ottimizzato per seguire le istruzioni.
LoRA / QLoRA: Metodi di fine-tuning efficienti che usano adapter a rango ridotto, con QLoRA che addestra attraverso modelli base quantizzati.
MoE: Mixture of Experts. Un'architettura sparsa in cui solo sottoreti esperte selezionate si attivano per token.
Pesi / Parametri: I valori numerici appresi all'interno del modello.

Meccaniche di Inferenza

BOS / EOS: Token di inizio sequenza e fine sequenza.
Chat Template: La formattazione usata per rappresentare messaggi di sistema, utente, assistente e strumento.
Finestra di Contesto: Il numero massimo di token che il modello può elaborare contemporaneamente.
Decode: La fase in cui il modello genera nuovi token uno per uno.
DFlash: Un approccio di decoding speculativo del 2026 che usa la diffusione a blocchi per la bozza parallela.
DDTree / DTree: Un metodo di decoding speculativo che costruisce un albero di bozze dalle distribuzioni di diffusione a blocchi e lo verifica efficientemente.
GQA / MQA: Varianti di attenzione che riducono la dimensione della KV cache e migliorano l'efficienza dell'inferenza.
Inferenza: Esecuzione del modello per produrre output.
KV Cache: Stati di attenzione chiave/valore memorizzati per token precedenti.
Prefill: La fase in cui il modello elabora il prompt di input prima di generare.
RoPE: Rotary Position Embeddings, un metodo di codifica posizionale comune nei LLM moderni.
Decoding Speculativo: Una tecnica di velocità in cui un bozzista più economico propone token e il modello target li verifica.
Tokenizer: Il componente che converte il testo in ID di token e viceversa.
Top-p / Top-k / Temperatura: Controlli di campionamento per la generazione di token.

Recupero, File e Servizio

AWQ: Quantizzazione dei pesi consapevole dell'attivazione.
Modello di Embedding: Un modello che converte il testo in vettori per ricerca/recupero.
KV Cache FP8: Una modalità pratica di compressione della KV cache a 8 bit supportata in alcuni runtime.
GGUF: Un formato di file modello usato pesantemente da llama.cpp.
PagedAttention: Una tecnica di gestione della memoria della KV cache usata dal servizio in stile vLLM.
Quantizzazione: Riduzione della precisione numerica per risparmiare memoria e migliorare l'efficienza.
RAG: Retrieval-Augmented Generation. Recupera contesto esterno rilevante e fornisce al modello.
Reranker: Un modello che riordina i passaggi recuperati per rilevanza.
Safetensors: Un formato di serializzazione dei tensori più sicuro che evita i rischi di esecuzione basati su pickle.

Parole Finali

L'ecosistema dei LLM locali include modelli edge compatti, forti modelli consumer da 7B a 32B, grandi sistemi MoE a pesi aperti, modelli multimodali, modelli a lungo contesto, modelli di ragionamento locali, runtime di inferenza maturi e stack di servizio privato sempre più capaci.

Ma le basi non sono cambiate: il modello predice un token alla volta, i token non sono parole, i pesi non sono l'intero modello, i chat template contano, la KV cache è la bolletta di memoria nascosta, la quantizzazione è un compromesso, il contesto lungo non è gratis, la qualità di RAG dipende dal recupero, il fine-tuning necessita di valutazioni e la privacy locale richiede ancora disciplina di sicurezza.

Non hai bisogno di mitologia per eseguire bene modelli locali. Devi sapere cosa entra in memoria, quale template il modello si aspetta, come si comporta il runtime e se le tue valutazioni corrispondono al lavoro che ti interessa.

I LLM locali sono principalmente matematica della memoria più formattazione più valutazione. Prendi queste bene, e il resto dello stack diventa molto più facile da ragionare.

Alla prossima.

-Ahmad