Modelli AI locali per programmare nel 2026: Qwen3.6, Devstral Small 2 e GLM-4.7-Flash a confronto

Qwen3.6-27B è il migliore tra i modelli AI locali per programmare per la maggior parte degli sviluppatori nel 2026. Tuttavia, il pacchetto Ollama da 17 GB è solo l’inizio del fabbisogno di memoria. Se si acquista nuovo hardware soltanto per evitare un abbonamento Copilot Pro da $10 al mese, una RTX 5090 da $1,999 raggiunge il pareggio dopo 199.9 mesi, senza ancora considerare l’elettricità, il resto della workstation o il tempo impiegato.

In breve: come scegliere i modelli AI locali per programmare in base alla memoria

Scegliete Qwen3.6-27B se disponete di una GPU da 24 GB o di un sistema con memoria unificata della stessa fascia e cercate un’unica soluzione locale solida per lavorare sui repository, usare strumenti e affrontare il ragionamento quotidiano. Preferite Devstral Small 2 quando il compito riguarda in modo specifico l’ingegneria software su più file e la macchina rispetta le indicazioni di Mistral: una singola RTX 4090 o un Mac con 32 GB. GLM-4.7-Flash è indicato per chi vuole un modello agentico efficiente ed è disposto ad accettare uno stack di esecuzione locale meno maturo. Qwen3-Coder-Next va riservato a una macchina da 64 GB o a un server condiviso. Su un sistema da 8 GB, è più sensato usare Qwen3.5-9B per modifiche circoscritte, senza aspettarsi che si comporti come un ingegnere autonomo sull’intero repository.

Prezzi, schede dei modelli, dati sulla memoria in esecuzione e licenze riportati di seguito sono stati verificati sulle pagine ufficiali attive il 15 agosto 2026.

La classifica applica prima di tutto un criterio di compatibilità: prima la memoria accelerata o unificata disponibile, poi il flusso di lavoro di coding, infine il punteggio nei benchmark. Quest’ordine evita l’errore di acquisto più comune nell’AI locale. Un modello può entrare in memoria come file, ma lasciare troppo poco spazio per una finestra di contesto utile, il runtime, il sistema operativo e l’agente di coding che gli fornisce file e risultati degli strumenti.

Tre valori che sembrano simili descrivono in realtà vincoli diversi:

1. Dimensione del pacchetto: è il download quantizzato del modello. Ollama indica 17 GB per il pacchetto qwen3.6:27b.
2. Memoria minima di sistema: è la soglia necessaria al runtime per caricare il modello. LM Studio indica 16 GB per lo stesso modello, ma il minimo non è un obiettivo operativo confortevole.
3. Memoria per il contesto: cresce con la conversazione, i file sorgente, l’output dei comandi e la cronologia degli strumenti. Qwen suggerisce esplicitamente di ridurre il contesto dopo un errore di memoria insufficiente, anche se il modello supporta nativamente una finestra molto più ampia.

Immaginate il file del modello come una persona che entra in ascensore. Il fatto che passi dalla porta dimostra soltanto che riesce a salire. Un agente di coding deve portare anche i bagagli: contesto del repository, token generati, buffer del runtime e strumenti circostanti. Riempire l’ascensore fino alla capienza dichiarata non è un buon modo di pianificare una giornata di lavoro.

Se l’obiettivo è un’esperienza completa di editor, revisione e agente cloud, e non soltanto il modello sottostante, confrontate gli attuali assistenti AI per programmare. Un modello locale è solo un componente: non offre automaticamente indicizzazione del repository, controlli dei permessi, un’interfaccia per esaminare le patch, sandboxing o un esecutore di comandi sicuro.

1. Qwen3.6-27B: il migliore tra i modelli AI locali per programmare

Qwen3.6-27B è la scelta predefinita migliore perché racchiude coding agentico attuale, uso degli strumenti, input visivi e ragionamento a livello di repository in un pacchetto Ollama da 17 GB. È adatto allo sviluppatore che desidera un solo modello per esaminare un monorepo TypeScript, spiegare un test non riuscito, preparare una patch e ragionare sulla logica di prodotto collegata, senza passare da un modello all’altro. Il limite è il margine di memoria: il minimo di 16 GB indicato da LM Studio e il pacchetto Ollama da 17 GB non trasformano una macchina da 16 GB in una workstation comoda per il coding con contesti lunghi. L’acquisto o l’allocazione vanno dimensionati sul contesto che sarà realmente usato, non sul numero più basso mostrato nella pagina di download.

La scheda ufficiale del modello di Qwen descrive un modello da 27B parametri con una finestra di contesto nativa di 262,144 token, estendibile a 1,010,000 token. Cita inoltre coding agentico, uso degli strumenti, workflow frontend, ragionamento sui repository, input visivi e conservazione del contesto di ragionamento tra i messaggi precedenti. Sono capacità preziose per un agente di coding, perché un’attività su un repository raramente si conclude dopo una sola risposta: il modello deve ricordare perché ha scelto un approccio anche quando nella conversazione entrano test, log e nuovi file.

L’attuale elenco dei tag di Ollama rende la release pratica: qwen3.6:27b è un download da 17 GB con un contesto indicato di 256K. Un pacchetto NVFP4 orientato al coding pesa 20 GB. LM Studio indica una memoria minima di sistema di 16 GB, ma è soltanto la soglia di caricamento. Su una GPU da 24 GB o una macchina con memoria unificata equivalente, il pacchetto da 17 GB lascia molto più spazio al contesto e all’overhead del runtime. Con 16 GB conviene iniziare con un contesto più piccolo o un modello più leggero.

Il benchmark di punta è notevole, ma va letto insieme al metodo. Qwen dichiara 77.2 su SWE-bench Verified, 53.5 su SWE-bench Pro, 71.3 su SWE-bench Multilingual e 59.3 su Terminal-Bench 2.0. I risultati SWE-bench sono stati ottenuti con uno scaffold agentico interno dotato di bash e strumenti per modificare i file, oltre a una finestra di contesto di 200K. Terminal-Bench ha usato una finestra di 256K su un’infrastruttura con 32 CPU e 48 GB di RAM. Questi numeri mostrano le capacità ottenute nella configurazione di Qwen; non garantiscono lo stesso risultato o la stessa velocità su un desktop da 24 GB.

La documentazione del produttore contiene un secondo avvertimento sul contesto. Qwen raccomanda di ridurlo in caso di errore per memoria insufficiente, ma consiglia anche almeno 128K di contesto per preservare la capacità di ragionamento nei compiti complessi. Proprio questa tensione definisce il limite del modello: può esporre una finestra da 256K, ma una macchina locale compatta potrebbe costringere a utilizzarne una porzione più ridotta.

Ideale per: sviluppatori con una GPU da 24 GB o una macchina con memoria unificata della stessa fascia, alla ricerca di un unico modello locale versatile per il coding

Punto di forza: un pacchetto installabile con un clic da 17 GB, uso degli strumenti e ragionamento sui repository attuali, più un risultato SWE-bench Verified di 77.2 dichiarato dal produttore

Prezzo: $0 con il piano locale Free di LM Studio, verificato il 15 agosto 2026

Prova gratuita: non applicabile; il piano locale del runtime e il download del modello sono gratuiti

Configurare Qwen3.6-27B senza scambiare il contesto massimo per un obiettivo

1. 1

   Controllate la memoria prima del download

   Annotate la VRAM o la memoria unificata disponibile, non soltanto lo spazio totale su disco. Considerate 24 GB come fascia di partenza pratica per il pacchetto da 17 GB. Se la macchina dispone di soli 8 GB, passate direttamente a Qwen3.5-9B.

2. 2

   Installate LM Studio e selezionate il modello esatto

   Installate LM Studio su una macchina Apple Silicon, Windows o Linux supportata. Cercate Qwen3.6-27B, verificate che il publisher sia Qwen e scegliete una quantizzazione le cui dimensioni visualizzate lascino un adeguato margine operativo.

3. 3

   Partite al di sotto del contesto massimo

   Non iniziate da 256K solo perché il modello li supporta. Scegliete inizialmente un contesto adatto a un’attività rappresentativa sul repository, monitorate l’uso della memoria e aumentatelo soltanto se i file aggiuntivi migliorano la patch più di quanto rallentino o rendano instabile l’esecuzione.

4. 4

   Collegate il server locale a un solo agente di coding

   Attivate il server locale di LM Studio e collegategli un client di coding compatibile con OpenAI. Mantenete il server vincolato alla macchina locale, a meno che non abbiate configurato intenzionalmente autenticazione di rete e controlli di accesso.

5. 5

   Provate un’attività circoscritta sul repository

   Usate un bug con un test già noto come non riuscito, una piccola modifica su più file e un compito di spiegazione. Esaminate ogni comando e ogni diff proposti. Registrate le patch accettate, il tempo dedicato alle correzioni, il picco di memoria e l’eventuale perdita dei vincoli precedenti da parte del modello.

2. Devstral Small 2: il miglior agente locale dedicato al coding

Devstral Small 2 è la scelta specializzata per chi vuole affidare al modello l’esplorazione della codebase, la modifica di più file e l’uso di strumenti di ingegneria software. Mistral ha progettato questo modello da 24B per il coding agentico, invece di presentarlo come un assistente generalista capace anche di scrivere codice. Un team che gestisce un grande servizio Python può assegnargli un problema ben delimitato, lasciare che l’infrastruttura cerchi e modifichi i file e poi revisionare una patch coerente su più file. Il limite sta nella differenza tra riuscire appena a caricarlo e lavorare comodamente: LM Studio indica un minimo di 16 GB, mentre Mistral suggerisce per l’esecuzione locale una singola RTX 4090 o un Mac con 32 GB di RAM.

La scheda ufficiale di Mistral attribuisce a Devstral Small 2 una finestra di contesto da 256K, input visivo e uso degli strumenti per esplorare repository e intervenire su più file. Il modello è inoltre distribuito con licenza Apache 2.0, un punto di partenza più chiaro per l’uso e la modifica in ambito commerciale rispetto a un upload della community con condizioni vaghe. Può comunque servire una valutazione legale per il codice e l’infrastruttura circostanti, ma la licenza del modello è esplicita.

Mistral dichiara 68.0% su SWE-bench Verified, 55.7% su SWE-bench Multilingual e 22.5% su Terminal Bench 2. In due benchmark condivisi questi punteggi sono inferiori ai risultati di punta dichiarati per Qwen3.6, ma la posizione grezza in classifica non esaurisce il confronto. Il perimetro di Devstral è più ristretto e più facile da spiegare: è un modello agentico per l’ingegneria software, progettato per usare strumenti, ispezionare codice e modificare file.

Le indicazioni sulla memoria dovrebbero risolvere il dubbio sull’hardware. LM Studio riporta 16 GB come minimo, mentre Mistral afferma che il modello è abbastanza leggero per una singola RTX 4090 o un Mac da 32 GB. Quando si compra nuovo hardware, conviene seguire la macchina esplicitamente consigliata. Il valore inferiore dimostra che un file quantizzato può essere caricato, non che una lunga esecuzione agentica manterrà tutto il contesto desiderato.

Ideale per: un agente di coding dedicato alle modifiche su più file, eseguito su una singola workstation di fascia alta

Punto di forza: addestramento esplicito come agente di ingegneria software, contesto da 256K, input visivo e licenza Apache 2.0

Prezzo: $0 con il piano locale Free di LM Studio, verificato il 15 agosto 2026

Prova gratuita: non applicabile; il piano locale del runtime e il download del modello sono gratuiti

3. GLM-4.7-Flash: la migliore opzione mixture-of-experts efficiente

GLM-4.7-Flash è la scelta per chi vuole sperimentare in modo efficiente: un modello mixture-of-experts da 30B che attiva 3B parametri per token e viene distribuito da Ollama in un pacchetto da 19 GB. È adatto a chi cerca capacità agentiche su una macchina da 24 GB ed è disposto a verificare un percorso di serving più recente prima di adottarlo come standard per il team. Z.ai dichiara risultati di coding competitivi per queste dimensioni, mentre LM Studio offre controlli per strumenti e thinking. Il limite è la maturità dell’integrazione: la scheda ufficiale spiega che il supporto di vLLM e SGLang dipendeva dai rispettivi branch main, un segnale d’allerta per gli ambienti di produzione che preferiscono release stabili e bloccate.

Un modello mixture-of-experts conserva molti gruppi di parametri, ma per ogni token ne attiva soltanto una parte. Il dato di 3B attivi aiuta a comprendere l’efficienza di calcolo; non riduce il download a un modello da 3B. La pagina dei tag Ollama riporta 19 GB per il pacchetto Q4, mentre LM Studio indica una memoria minima di sistema di 16 GB e un contesto da 128K. Per pianificare la memoria accelerata, la dimensione del pacchetto è il promemoria più utile.

La scheda ufficiale del modello di Z.ai dichiara 59.2 su SWE-bench Verified e 64.0 su LiveCodeBench v6. Il modello è addestrato all’uso degli strumenti e tramite LM Studio permette di controllare il thinking. Può essere un agente locale interessante quando conta il throughput per parametro attivo, ma le valutazioni restano dichiarazioni del produttore e lo stack di serving merita una prova pilota.

Per un piccolo team che gestisce una piattaforma interna, il caso d’uso sensato è un unico servizio locale dietro un client di coding, vincolato a uno specifico file del modello e a una versione precisa del runtime. Prima di offrire un endpoint condiviso, vanno verificati ricerca nel repository, generazione delle patch, interpretazione delle chiamate agli strumenti e output lunghi. Se dopo un aggiornamento il team non riesce a riprodurre l’ambiente, il vantaggio di efficienza non si è trasformato in un vantaggio operativo.

Ideale per: chi sperimenta con un modello agentico efficiente su una macchina da 24 GB

Punto di forza: 30B parametri totali, 3B attivi per token, addestramento agli strumenti e un pacchetto Ollama da 19 GB

Prezzo: $0 con il piano locale Free di LM Studio, verificato il 15 agosto 2026

Prova gratuita: non applicabile; il piano locale del runtime e il download del modello sono gratuiti

4. Qwen3-Coder-Next: il migliore per un server locale da 64 GB

Qwen3-Coder-Next è lo specialista per un server locale con molta memoria, non il modello economico che l’etichetta “3B attivi” potrebbe far immaginare. Qwen lo ha progettato appositamente per gli agenti di coding e lo sviluppo locale, con ragionamento su orizzonti lunghi, uso complesso degli strumenti e capacità di riprendersi dagli errori di esecuzione. È una scelta sensata per un piccolo team di piattaforma che centralizza un endpoint agentico locale controllato e dispone di 64 GB di memoria unificata o di sistema. Il limite è fisico: l’attuale pacchetto Q4 di Ollama pesa 52 GB, quindi una comune GPU da 24 GB per sviluppatori non è la destinazione prevista.

La scheda del modello Qwen descrive 80B parametri totali, con 3B attivi per token, un contesto nativo di 262,144 token e la sola modalità non-thinking. L’addestramento è rivolto al lavoro degli agenti di coding, non soltanto al completamento statico del codice. Qwen cita in modo specifico compiti su orizzonti lunghi, uso degli strumenti, integrazione con IDE e CLI e recupero dopo un errore di esecuzione.

Il download chiarisce il requisito hardware. Ollama indica 52 GB per il pacchetto Q4 e 85 GB per Q8, entrambi con un contesto indicato di 256K. LM Studio riporta una memoria minima di sistema di 42 GB. Pianificare 64 GB per Q4 lascia un po’ di spazio al sistema operativo e a un contesto ridotto, ma non garantisce comunque che l’intera finestra nativa possa essere usata comodamente.

Qwen riconosce questo confine. Le istruzioni ufficiali suggeriscono di ridurre il contesto a 32,768 se il server non si avvia o incontra un errore di memoria insufficiente. È un’indicazione di deployment più utile del valore massimo della finestra: una sessione agentica affidabile da 32,768 token, capace di modificare e testare i file corretti, vale più di un’opzione da 256K che continua a bloccarsi.

Il comportamento non-thinking può essere un vantaggio oppure un limite. Evita di esporre una lunga fase di ragionamento e può rendere l’interazione più diretta, ma chi desidera espressamente mantenere il thinking dovrebbe scegliere Qwen3.6 o valutare un altro modello. Il nome Qwen in comune non implica un comportamento identico.

Ideale per: un server locale da 64 GB che gestisce uno o pochi carichi agentici di coding controllati

Punto di forza: specializzazione per agenti di coding, con 80B parametri totali, 3B attivi per token e addestramento orientato al recupero dagli errori

Prezzo: $0 con il piano locale Free di LM Studio, verificato il 15 agosto 2026

Prova gratuita: non applicabile; il piano locale del runtime e il download del modello sono gratuiti

5. Qwen3.5-9B: il migliore per hardware da 8 GB

Qwen3.5-9B è la scelta sensata per macchine compatte quando servono spiegazioni, snippet, generazione di test e modifiche ben circoscritte. LM Studio indica un minimo di 7 GB, quindi il modello può essere usato da uno sviluppatore con una macchina da 8 GB che non riesce a caricare i pacchetti da 17 GB a 52 GB descritti sopra. La scheda include thinking, strumenti, input visivo e capacità agentiche, rendendolo più versatile di un vecchio modello dedicato al solo completamento automatico. Il limite è l’ampiezza del compito: è un modello di base generalista da 9B, non un’autorizzazione ad affidare un intero repository a un agente senza supervisione.

La scheda ufficiale di Qwen3.5-9B assegna al modello denso una finestra di contesto nativa di 262,144 token, estendibile a 1,010,000 token. Qwen dichiara 65.6 su LiveCodeBench v6, 66.1 su BFCL-V4 e 79.1 su TAU2-Bench. LiveCodeBench misura la generazione di codice, mentre BFCL e TAU2 valutano il comportamento nell’uso di strumenti e come agente; nessuno di questi test equivale al completamento di un problema specifico del vostro repository tramite la vostra infrastruttura di coding.

Il valore massimo del contesto richiede la stessa cautela dei modelli più grandi. Qwen consiglia di ridurre il contesto dopo un errore di memoria insufficiente e suggerisce almeno 128K per preservare il thinking nei compiti complessi. È improbabile che una macchina da 8 GB riesca ad abbinare comodamente il modello a un contesto operativo di tali dimensioni. Usate un contesto contenuto, passate soltanto i file indispensabili e preferite una sequenza di modifiche revisionabili a un’unica lunga esecuzione autonoma.

Un buon caso d’uso è aiutare uno sviluppatore a comprendere una funzione poco familiare: fornite la funzione, i relativi test e le definizioni dei tipi pertinenti; chiedete una spiegazione e una patch minima; poi eseguite personalmente i test. Un caso d’uso inadeguato consiste nel chiedere al modello di esaminare un grande monorepo, riprogettare un’architettura, modificare decine di file e recuperare dagli errori senza supervisione. Il modello più piccolo vince perché è disponibile, non perché annulla il costo della complessità.

Ideale per: snippet, spiegazioni, test e diff circoscritti su una macchina da 8 GB

Punto di forza: minimo di 7 GB in LM Studio, con capacità attuali di thinking, input visivo e uso degli strumenti

Prezzo: $0 con il piano locale Free di LM Studio, verificato il 15 agosto 2026

Prova gratuita: non applicabile; il piano locale del runtime e il download del modello sono gratuiti

Quale modello scegliere in base alla macchina?

La decisione diventa semplice quando memoria e carico di lavoro vengono considerati insieme.

Su un Mac da 8 GB o una macchina compatta equivalente: scegliete Qwen3.5-9B e mantenete contenuto il contesto. I requisiti di sistema di LM Studio invitano chi usa un Mac da 8 GB a limitarsi a modelli più piccoli e contesti moderati. Aspettatevi spiegazioni utili, snippet e diff limitati, non un lavoro autonomo su tutto il repository.

Su una macchina da 16 GB: non considerate vincitore il modello più grande che riesce appena a caricarsi. Sia Qwen3.6 sia Devstral hanno un minimo di 16 GB in LM Studio, ma resta pochissimo margine intorno al modello. Una quantizzazione più piccola, Qwen3.5-9B o un pilot con contesto breve sono punti di partenza più sicuri.

Su una GPU da 24 GB o una macchina con memoria unificata della stessa fascia: Qwen3.6-27B è la scelta predefinita. Devstral Small 2 diventa preferibile quando l’ingegneria software su più file costituisce quasi l’intero carico. GLM-4.7-Flash passa in vantaggio quando l’efficienza mixture-of-experts giustifica una verifica più approfondita del runtime.

Su un Mac da 32 GB o una workstation con RTX 4090: Devstral Small 2 presenta la compatibilità più chiaramente sostenuta dal produttore. Qwen3.6 resta l’assistente più versatile: la decisione è quindi tra un agente di coding specializzato e un modello più ampio per ragionamento e input visivo.

Su una macchina o un server locale da 64 GB: Qwen3-Coder-Next diventa praticabile. Il pacchetto Q4 da 52 GB richiede comunque un budget per il contesto, mentre il server ha bisogno di un piano per accessi e concorrenza. Il fatto che un modello sia locale non significa che ogni sviluppatore debba esporre in ufficio un endpoint privo di autenticazione.

La regola decisiva è concisa: se due modelli sono compatibili, scegliete quello addestrato per il compito più simile; se soltanto uno lascia margine, scegliete quello che lascia margine. Nessuna posizione nei benchmark può salvare un modello che passa la giornata a usare lo swap, bloccarsi o funzionare con troppo poco contesto per comprendere la modifica.

Il punto di pareggio con gli abbonamenti: quando l’hardware entra nel budget

I pesi locali partono da $0, ma programmare in locale ha comunque un costo. La spesa si sposta dall’abbonamento a hardware, elettricità, configurazione, aggiornamenti, controllo degli accessi e tempo degli sviluppatori. Se la macchina è già disponibile, la valutazione cambia. Se invece viene acquistata soltanto per l’inferenza locale, deve giustificare quella voce di bilancio.

Il piano Free di LM Studio costa $0, esegue i modelli localmente sulla macchina dell’utente e dichiara che nessun dato lascia il dispositivo. La relativa documentazione di sistema spiega che, una volta scaricati i file del modello, l’applicazione può funzionare completamente offline. Questo confine di privacy e disponibilità offline può giustificare l’inferenza locale anche quando il confronto con un abbonamento non la premia. Può contare per codice sorgente non ancora pubblicato, lavoro sul campo senza una connessione stabile o team che devono poter usare il modello indipendentemente da un’interruzione del provider.

Per un confronto di budget corretto bisogna usare i prezzi pubblici di listino, non presentarli come costo complessivo. NVIDIA ha lanciato la RTX 5090 da 32 GB con un prezzo di partenza di $1,999. Gli attuali piani individuali di GitHub indicano Copilot Free a $0, Pro a $10 per utente al mese, Pro+ a $39 e Max a $100. I prezzi per le organizzazioni sono di $19 per utente al mese per Business e $39 per Enterprise.

• Un abbonamento Pro da $10 impiega 199.9 mesi, circa 16.7 anni, a eguagliare il prezzo iniziale di una GPU da $1,999.
• Dieci abbonamenti Business costano $190 al mese. Il prezzo di listino della GPU equivale a 10.5 mesi di questa voce.
• Dieci abbonamenti Enterprise costano $390 al mese. Il prezzo di listino della GPU equivale a 5.1 mesi di questa voce.

Questa conseguenza è più utile di una specifica di lancio. Non comprate una GPU di fascia alta soltanto per eliminare un abbonamento cloud da $10. L’acquisto si giustifica se il codice deve restare locale, l’accesso offline ha un valore operativo, l’hardware esiste già oppure un team può condividere la capacità senza trasformare una sola macchina in una coda.

Gli abbonamenti cloud includono inoltre molto più dell’inferenza. Un piano per assistenti di coding può comprendere modelli gestiti, integrazione con l’editor, agenti cloud, revisione del codice, identità, policy e supporto. Il download di un modello locale non fornisce da solo nessuno di questi controlli. Se il confronto più adatto è con l’inferenza a consumo invece che con un abbonamento, l’analisi sulle API AI più economiche mostra perché il prezzo per token rappresenta soltanto una parte del costo applicativo.

La decisione operativa è quindi asimmetrica. Uno sviluppatore singolo che possiede già una GPU da 24 GB dovrebbe provare Qwen3.6 prima di pagare un altro servizio. Chi lavora da solo e non dispone di hardware adatto dovrebbe iniziare con un abbonamento cloud oppure con Qwen3.5 sulla macchina attuale. Un team di dieci persone con codice sensibile dovrebbe condurre un pilot di due settimane su un server condiviso e misurare concorrenza, patch accettate, tempo di correzione e ore dell’operatore prima di acquistare più macchine.

Come sono stati scelti questi modelli locali per il coding

I cinque modelli sono stati selezionati per una decisione che uno sviluppatore può mettere in pratica oggi, non per creare l’elenco di nomi più lungo possibile. Ogni proposta corrisponde a una fascia di memoria o a un’attività di coding distinta ed è documentata abbastanza in profondità da mostrare su quale macchina e in quale workflow smette di essere la scelta giusta.

L’ordine si basa su sei criteri:

1. Disponibilità locale: il modello deve avere una scheda ufficiale aggiornata e una versione corrente installabile con un clic tramite LM Studio o Ollama.
2. Compatibilità hardware: dimensione del pacchetto, memoria minima, pressione esercitata dal contesto e indicazioni del produttore sulla macchina vengono valutate insieme.
3. Comportamento da agente di coding: uso degli strumenti, modifiche su più file, ragionamento sul repository, recupero dagli errori e supporto delle infrastrutture di coding contano più del solo completamento automatico.
4. Maturità operativa: un runtime riproducibile e istruzioni chiare per gli errori di memoria hanno valore. Il supporto disponibile soltanto sul branch main rappresenta un costo, anche quando i pesi sono gratuiti.
5. Condizioni attuali: prezzi e licenze provengono da pagine ufficiali attive. Una licenza chiara è un vantaggio concreto per un deployment commerciale.
6. Trasparenza delle prove: i benchmark del produttore sono utili soltanto se accompagnati dal loro perimetro e dall’infrastruttura usata. I punteggi ottenuti con scaffold diversi non vengono trattati come un’unica classifica perfettamente confrontabile.

Nessun modello è stato eseguito durante questa analisi: per questo il titolo parla di modelli a confronto, non testati. La classifica usa schede dei modelli aggiornate, pagine dei runtime, metodi di valutazione dichiarati e un’analisi originale dei costi. Un benchmark del produttore e una patch accettata nel vostro repository rimangono prove di natura diversa.

L’elenco esclude modelli notevoli ma poco pratici su una singola workstation attuale. Un modello da 480B può avere pesi aperti ed essere tecnicamente self-hosted, pur restando la risposta sbagliata per uno sviluppatore che chiede cosa eseguire in locale. Sono esclusi anche i modelli privi di un pacchetto locale aggiornato e riproducibile o descrivibili soltanto con elogi generici.

Quali modelli evitare per questo utilizzo

Evitate i modelli giganteschi presentati come normali opzioni locali. I più grandi modelli di punta Qwen3-Coder, Kimi e GLM possono avere pesi aperti ed essere self-hosted, ma ciò non li rende adatti a una singola workstation. Senza una quantizzazione precisa, un piano di memoria, un runtime e un obiettivo di concorrenza, “locale” descrive soltanto una possibilità di deployment.

Evitate di scegliere in base ai soli parametri attivi. GLM-4.7-Flash e Qwen3-Coder-Next attivano entrambi 3B parametri per token, ma i rispettivi pacchetti Ollama quantizzati pesano 19 GB e 52 GB. Il calcolo attivo e i pesi archiviati rispondono a domande diverse. La GPU deve comunque contenere o trasferire il pacchetto in esecuzione.

Evitate di adottare Code Llama o StarCoder2 come nuova scelta predefinita. I modelli di codice meno recenti possono restare utili in un workflow consolidato, soprattutto quando il team ne conosce già il comportamento. Per una nuova configurazione nel 2026, gli attuali modelli addestrati come agenti offrono uso degli strumenti, comportamento su contesti più lunghi e addestramento al recupero dagli errori, capacità più vicine al funzionamento degli agenti di coding.

Evitate di usare una quantizzazione sperimentale della community come standard del team. Una build della community può essere eccellente, ma prima che più sviluppatori inizino a dipenderne vanno registrati file esatto, quantizzazione, template del prompt, versione del runtime, licenza e checksum. Se il risultato non può essere riprodotto dopo un aggiornamento, la configurazione locale ha scambiato la dipendenza dal provider con quella dall’artefatto.

Evitate il contesto massimo fin dal primo giorno. Una pagina che indica 256K non ordina di allocare 256K per ogni attività. Iniziate con il contesto più piccolo che contenga il codice e la cronologia degli strumenti pertinenti. Aumentatelo dopo che una patch non riuscita avrà dimostrato l’assenza di informazioni necessarie, non soltanto perché un cursore consente di farlo.

Domande frequenti

Qual è il miglior modello AI per programmare?

Per una configurazione locale, Qwen3.6-27B è la migliore scelta generalista su una macchina da 24 GB. Devstral Small 2 è preferibile quando il carico consiste specificamente in ingegneria software su più file, mentre un modello cloud gestito può restare il sistema migliore se i veri vincoli sono concorrenza, manutenzione o strumenti ospitati.

Qual è il miglior modello AI locale per il coding nel 2026?

Qwen3.6-27B è la scelta migliore in assoluto perché il pacchetto Ollama da 17 GB unisce capacità attuali da agente di coding, ragionamento ampio e input visivo. Usate Devstral Small 2 per un agente specializzato sul codice, Qwen3-Coder-Next su un server da 64 GB e Qwen3.5-9B su una macchina da 8 GB.

Qual è il miglior modello AI locale in questo momento?

Il modello migliore è il più potente tra quelli che lasciano memoria sufficiente al runtime e a un contesto utile. Qwen3.6-27B vince nella comune fascia da 24 GB; su una macchina da 8 GB, il più piccolo Qwen3.5-9B può essere migliore perché funziona con un contesto praticabile invece di limitarsi a caricarsi.

Qual è il miglior modello AI self-hosted per programmare?

Qwen3-Coder-Next è la scelta specializzata per un server locale da 64 GB, perché è stato progettato per agenti di coding, uso degli strumenti su orizzonti lunghi e recupero dagli errori. Qwen3.6-27B è l’opzione self-hosted più pratica quando il server o la workstation dispone di circa 24 GB di memoria accelerata o unificata.

Qual è il miglior modello Ollama per il coding?

Iniziate da qwen3.6:27b se la macchina ha spazio per il pacchetto da 17 GB, oltre al contesto e all’overhead del runtime. Su una macchina compatta scegliete un pacchetto Qwen3.5 più piccolo; su un server da 64 GB valutate Qwen3-Coder-Next e partite con un contesto ridotto.

Quanta RAM o VRAM serve per un modello locale di coding?

Usate hardware da 8 GB per Qwen3.5-9B e attività circoscritte, circa 24 GB per Qwen3.6-27B o GLM-4.7-Flash, un PC con RTX 4090 o un Mac da 32 GB per Devstral Small 2 e circa 64 GB per il pacchetto Qwen3-Coder-Next da 52 GB. Sono obiettivi pratici, non garanzie: contesto, quantizzazione, runtime, sistema operativo e offload sulla GPU modificano il requisito finale.

I modelli AI locali per programmare sono gratuiti?

I cinque download e il piano locale di LM Studio partono da $0. Il sistema non è privo di costi: hardware, elettricità, configurazione, aggiornamenti, controllo degli accessi, backup e tempo degli ingegneri restano parte del costo di proprietà.

Cosa fare lunedì

Non iniziate ordinando una GPU. Partite da un test di compatibilità su un singolo repository.

Lunedì: fate l’inventario della macchina e scegliete un candidato

Annotate VRAM o memoria unificata disponibile, RAM di sistema, sistema operativo e compatibilità attuale della macchina con LM Studio. Scegliete Qwen3.5-9B per un sistema da 8 GB, Qwen3.6-27B per uno da 24 GB oppure Devstral Small 2 per la fascia RTX 4090/Mac da 32 GB. Non scaricateli tutti e cinque.

Martedì: definite tre attività rappresentative

Usate un test non riuscito con una correzione già nota, una piccola modifica su più file e un compito di spiegazione provenienti da un repository che il team conosce. Rimuovete i segreti e concedete all’agente di coding soltanto gli strumenti necessari. Salvate il comportamento atteso prima di iniziare.

Mercoledì: eseguite il modello al di sotto del contesto massimo

Partite da un contesto circoscritto e dal minimo insieme di file pertinenti. Registrate picco di memoria, tempo necessario per ottenere la prima patch utile, comandi richiesti, test superati e correzioni umane. Se il modello non individua una dipendenza, aggiungete il file mancante prima di ampliare l’intera finestra di contesto.

Giovedì: confrontate il risultato con il percorso cloud attuale

Eseguite le stesse tre attività con l’assistente o l’API che state già pagando. Confrontate patch accettate e minuti di correzione, non la sicurezza apparente della prosa. Per la soluzione locale includete il tempo di configurazione e quello dell’operatore.

Venerdì: prendete una delle tre decisioni

Mantenete la soluzione locale se privacy, uso offline, controllo o convenienza delle patch accettate sono migliorati. Conservate l’abbonamento cloud se resta più economico e semplice. Aggiornate l’hardware soltanto se il pilot individua nella memoria il fattore limitante e il vantaggio dell’esecuzione locale giustifica il possesso della macchina.