La scorsa settimana, su Reddit, un utente ha condiviso la propria esperienza con un modello di linguaggio locale: il Qwen 3.6 35B A3B. Il suo post, dal titolo «local already feels good enough», descrive un utilizzo mirato – coding, pianificazione tecnica e configurazione hardware – e un verdetto netto: il LLM «non ha mai fallito se usato con un piano di lavoro strutturato e gli strumenti giusti». Le poche volte in cui il modello lo ha deluso, aggiunge, sono state risolte migliorando disciplina e workflow, non cambiando modello o passando al cloud.

L’aneddoto è tutt’altro che banale. Mette a fuoco un punto di svolta per chi valuta deployment on-premise: con un modello quantizzato (la sigla A3B suggerisce una quantization spinta, forse a 3 bit) che gira localmente e basta a coprire compiti tecnici complessi, il gap reale non è più nella capacità di calcolo del modello, ma nella qualità dell’interazione che l’utente riesce a costruire. L’ingegneria del prompt, l’integrazione con tool esterni e un flusso di lavoro disciplinato diventano i veri moltiplicatori di efficacia.

Questo scivolamento del collo di bottiglia ha ripercussioni profonde sul settore. Se un LLM on-premise è “abbastanza buono” per molte attività tecniche, l’argomento economico che spinge verso le API cloud – costi per token, latenza di rete, lock-in del vendor – perde mordente. Il costo totale di possesso (TCO) va ricalcolato: l’hardware acquistato per l’inference locale può ammortizzarsi su tempi lunghi, azzerando i costi variabili e tenendo i dati in casa, un vantaggio netto per la sovranità e la conformità. Al contempo, chi fornisce servizi cloud dovrà giustificare un valore aggiunto che vada ben oltre la potenza grezza, puntando su ecosistemi integrati o capacità che il locale non può ancora replicare.

C’è però un rovescio della medaglia. L’esperienza dell’utente mette in luce una verità scomoda: molte organizzazioni potrebbero inseguire modelli sempre più grandi quando invece il vero salto di qualità sta nell’affinare i processi. Un LLM potente ma usato male produce frustrazione; uno modesto ma inserito in un ciclo di lavoro ben progettato può bastare. Il rischio è che l’industria continui a pompare risorse verso mega-modelli onnivori, alimentando una corsa che per molti casi d’uso è già superata.

Non è una tesi universale – per compiti altamente specialistici o conversazionali complessi i modelli più grandi mantengono un margine – ma per attacchi blockchain di sviluppo software e pianificazione tecnica il segnale è chiaro: la soglia di sufficienza è stata oltrepassata. La domanda provocatoria dell’utente («Is everything past this point just enabling laziness?» – tutto ciò che va oltre abilita solo pigrizia?) colpisce un nervo scoperto. Abbiamo già strumenti locali sufficienti, eppure continuiamo a rincorrere giganti dell’AI nella speranza che leggano la mente. Forse il vero progresso sta nel coltivare la disciplina, non nel modello.

Per chi valuta il deployment on-premise, questa testimonianza offre un riferimento concreto. Non servono cluster di GPU da decine di migliaia di euro per ottenere risultati utili: un approccio quantizzato e una solida ingegneria del flusso di lavoro possono spostare l’ago della bilancia, restituendo controllo, prevedibilità dei costi e indipendenza.