Introduzione a Keras e ai modelli di machine learning 2026

Q: Come si passa da un backend all'altro senza rompere nulla?

Se il codice usa solo API Keras e keras.ops per le operazioni numeriche, il passaggio è immediato. I problemi nascono quando dentro un layer personalizzato ci sono chiamate dirette a funzioni di un backend specifico: in quel caso vanno riscritte. Conviene adottare questa disciplina fin dall'inizio, anche quando non si prevede di cambiare motore, perché è ciò che tiene aperta l'opzione.

Che cos'è Keras nel 2026, perché dalla versione 3 non è più «la parte facile di TensorFlow», che cosa cambia potendo scegliere fra JAX, PyTorch e TensorFlow senza riscrivere una riga, quanto costa davvero un progetto e quando conviene rispetto a scrivere tutto a mano

C'è una frase che nelle discussioni tecniche torna da almeno tre anni: «Keras ormai non si usa più, si usa PyTorch». È una frase che descrive bene la ricerca accademica e male tutto il resto. Nei trenta giorni precedenti alla stesura di questa guida il pacchetto keras è stato scaricato da PyPI 14,65 milioni di volte, per un totale storico di 897 milioni di download. Non è il numero di una libreria morta: è il numero di una libreria che sta dentro i sistemi in esercizio, dove nessuno scrive post per raccontarlo.

Questa guida percorre Keras per intero — caratteristiche principali, vantaggi competitivi, costi, funzionalità avanzate e integrazioni, alternative e confronto, strategie di crescita e tendenze — ed è la quarta di una serie dopo quelle su TensorFlow, PyTorch e scikit-learn. Arriva per ultima perché è quella che ha più senso dopo aver capito le altre tre: Keras nel 2026 non è un concorrente di PyTorch, è un modo di usarlo. E la stessa cosa vale per JAX e per TensorFlow.

Il punto che rende questa guida meno scontata di quanto sembri è proprio questo ribaltamento. Dal novembre 2023, con Keras 3, il progetto è stato riscritto per girare su quattro motori di calcolo diversi: lo stesso identico file Python addestra su GPU con PyTorch, scala su TPU con JAX, si integra in una pipeline TensorFlow esistente e va in inferenza su un PC industriale con OpenVINO. Nel frattempo sono arrivate quantizzazione a quattro bit, distillazione ed export verso cinque formati di produzione, incluso il modulo PyTorch nativo. Se l'immagine che hai in testa è quella di «Keras strumento per principianti», è ferma al 2022.

INDICE DEI CONTENUTI

Che cos'è Keras, e il malinteso da chiarire subito
Le caratteristiche principali
I vantaggi competitivi
Costi
Funzionalità avanzate e integrazioni
Alternative a Keras e confronto
Strategie di crescita usando Keras
Tendenze future
Domande frequenti
In sintesi

Che cos'è Keras, e il malinteso da chiarire subito

Keras è l'API di alto livello per costruire e addestrare reti neurali creata da François Chollet e pubblicata per la prima volta nel marzo 2015. L'obiettivo dichiarato allora è rimasto identico oggi: ridurre al minimo il tempo che passa fra l'idea e il risultato misurabile. Si scrive l'architettura come la si descriverebbe a voce, si chiama un metodo per addestrare e uno per valutare, e il framework si occupa di tutto il resto — batch, shuffling, device, metriche, salvataggi.

Il malinteso nasce dalla storia. Per anni Keras è stato distribuito dentro TensorFlow come tf.keras, al punto che in molti l'hanno archiviato come «l'interfaccia semplice di TensorFlow». Quella fase è finita: Keras 3 è un progetto indipendente dal backend, installabile con JAX, con PyTorch o con TensorFlow indifferentemente, e con un quarto backend dedicato alla sola inferenza. La licenza è Apache 2.0: uso commerciale libero, anche dentro prodotti closed source, nessun obbligo di pubblicare il proprio codice.

Versioni e ritmo

La versione stabile corrente è la 3.15.1, rilasciata il 29 luglio 2026. Il ritmo è di una versione minore ogni pochi mesi, con patch frequenti: più veloce di scikit-learn, più prevedibile dei framework in fase di rincorsa. Il progetto richiede Python 3.11 o superiore — la linea 3.13 ha alzato il requisito minimo, ed è la prima cosa da verificare se si lavora su immagini Docker ereditate.

Le versioni minime dei backend dichiarate dal progetto sono TensorFlow 2.16.1, JAX 0.4.20, PyTorch 2.1.0 e OpenVINO 2025.3.0. È un dettaglio che conta nei progetti reali: se il cliente ha un ambiente congelato su una versione precedente di uno di questi, la migrazione a Keras 3 va pianificata e non improvvisata.

I numeri, con la metodologia dichiarata

La premessa metodologica è la stessa usata nelle altre guide della serie, ed è obbligatoria: i download dei pacchetti Python includono integrazione continua, ricostruzioni di container e mirror automatici, quindi sovrastimano largamente il numero di persone che usano davvero una libreria, e non contano le installazioni fatte con conda o con altri sistemi. Servono per il confronto relativo fra librerie, non per contare gli sviluppatori. Le stelle su GitHub, dal canto loro, misurano l'attenzione, non l'uso.

Libreria	Download totali	Ultimi 30 giorni	Stelle su GitHub
scikit-learn	5,39 miliardi	214,5 milioni	67,2 mila
PyTorch	2,07 miliardi	77,6 milioni	102 mila
TensorFlow	1,40 miliardi	15,1 milioni	197 mila
Keras	897 milioni	14,7 milioni	64,2 mila

Due letture oneste di questa tabella. La prima: il volume mensile di Keras è praticamente identico a quello di TensorFlow, e non è un caso, perché per anni i due pacchetti sono stati installati insieme. La seconda: con 64,2 mila stelle Keras ha meno visibilità di TensorFlow e PyTorch ma un volume di installazioni dello stesso ordine di grandezza di TensorFlow. È esattamente il profilo di una tecnologia matura: poco discussa, molto usata.

Chi lo mantiene, e che cosa significa per chi ci costruisce sopra

Keras è sviluppato principalmente da un team in Google con una comunità di contributori esterni, ed è ospitato nell'organizzazione keras-team su GitHub insieme alle librerie dell'ecosistema. La dipendenza da un singolo sponsor industriale è un fattore di rischio da conoscere, ma va pesato con due elementi concreti: la licenza Apache 2.0, che rende il codice forkabile in qualunque momento, e il fatto che dalla versione 3 il framework non dipende più da un solo motore di calcolo. Un progetto costruito su Keras 3 non è esposto alle sorti di un singolo backend, che è più di quanto si possa dire per molte alternative.

Sul fronte della manutenzione c'è un dato che merita attenzione più della roadmap: le versioni 3.12.3, 3.13.2 e 3.14.1 sono state pubblicate specificamente per irrobustire il caricamento dei modelli contro deserializzazione insicura, exploit su file HDF5 e attraversamento dei percorsi negli archivi. È un segnale di progetto adulto, ed è anche un promemoria operativo: un file di modello scaricato da internet è codice, non un documento.

Le caratteristiche principali

L'architettura multi-backend, cioè il vero cambio di paradigma

Il backend si sceglie con una variabile d'ambiente, KERAS_BACKEND, impostata prima di importare la libreria, oppure una volta per tutte nel file di configurazione ~/.keras/keras.json. I valori ammessi sono jax, tensorflow, torch e openvino, più un backend NumPy utile per il debug. Da quel momento in poi il codice del modello non cambia. Non «cambia poco»: non cambia.

Le conseguenze pratiche sono tre, e sono quelle che si scrivono in una proposta commerciale. La prima è la portabilità della performance: JAX è spesso il backend più veloce su GPU e TPU, ma non sempre, perché dipende dall'architettura del modello; con Keras si provano i tre backend in un pomeriggio e si tiene quello che va meglio sul carico di lavoro reale. La seconda è l'assenza di vincolo tecnologico: se fra un anno il cliente standardizza su PyTorch perché ha assunto un team che lo usa, il lavoro fatto non va buttato. La terza è l'accesso agli ecosistemi: un modello Keras può essere istanziato come modulo PyTorch, esportato come SavedModel TensorFlow o usato come funzione senza stato in JAX, il che significa poter usare gli strumenti di serving di uno qualunque dei tre mondi.

keras.ops: scrivere la matematica una volta sola

Il pezzo di ingegneria che rende possibile tutto questo si chiama keras.ops: uno spazio di funzioni che replica l'API di NumPy, più le operazioni tipiche delle reti neurali, e la traduce nel backend attivo. Una funzione di perdita personalizzata, una metrica di business, un layer scritto su misura: se sono scritti con keras.ops, funzionano identici su JAX, TensorFlow e PyTorch.

Chi ha provato a portare a mano una loss personalizzata da TensorFlow a PyTorch sa quanto tempo fa risparmiare questa singola caratteristica, e soprattutto quanti bug silenziosi evita. La regola operativa che ne discende è semplice e va adottata dal primo giorno: nel codice del modello non devono comparire chiamate dirette a funzioni di un backend specifico. È la disciplina che tiene aperta la porta del cambio di motore.

Tre modi di costruire un modello, uno per ogni livello di complessità

Keras offre tre API di costruzione, e sceglierle bene è metà del lavoro. Sequential descrive una pila lineare di strati: ottima per prototipi e didattica, inadeguata appena servono più ingressi o connessioni che saltano strati. Functional descrive il modello come un grafo di strati ed è l'API che copre la grande maggioranza dei casi professionali — più ingressi, più uscite, rami paralleli, riuso di sottoreti. Subclassing significa ereditare dalla classe base e scrivere a mano il metodo di forward: massima libertà, per architetture dinamiche o sperimentali.

La rivelazione progressiva della complessità

È il principio di design dichiarato del progetto, e tradotto in italiano operativo significa una cosa sola: non esiste un salto nel vuoto. Si comincia con l'addestramento automatico in tre righe; quando serve controllo si riscrive solo il passo di addestramento mantenendo però tutto l'apparato di callback, early stopping e checkpoint; quando serve controllo totale si scrive un ciclo di addestramento nativo in JAX o in PyTorch continuando a usare strati, ottimizzatori e metriche Keras.

Detta così sembra una finezza da manuale. Nella pratica è la differenza fra un progetto che a metà strada si blocca e uno che prosegue: non devi scegliere fra facilità e potenza all'inizio, quando ancora non sai di che cosa avrai bisogno. Nei framework in cui si parte a basso livello si paga subito un costo di complessità per una flessibilità che nel 70% dei progetti non verrà mai usata.

Dati, salvataggio e sicurezza

Un modello Keras 3 accetta indifferentemente pipeline tf.data, DataLoader di PyTorch, array NumPy, DataFrame pandas e generatori personalizzati basati sulla classe PyDataset. Anche qui il punto pratico conta più del principio: la scelta della pipeline dati e la scelta del backend sono indipendenti, quindi si può conservare l'ingestione dati che il cliente ha già scritto e collaudato e cambiare solo il motore di addestramento.

Il formato nativo di salvataggio è il file .keras, che contiene architettura, pesi e configurazione in un unico archivio; restano disponibili il salvataggio dei soli pesi e l'esportazione della sola architettura. Sul caricamento vale la raccomandazione già anticipata: tenere la libreria aggiornata e non disattivare le protezioni sul caricamento di modelli di terze parti. È la stessa classe di rischio della deserializzazione in qualunque altro linguaggio, e si gestisce allo stesso modo: fidandosi solo di artefatti di provenienza nota.

I vantaggi competitivi

Elencare vantaggi in astratto serve a poco. Li metto come li userei davanti a un responsabile tecnico che deve approvare una scelta, cioè legati a un beneficio che si può misurare.

Il tempo fra l'idea e il primo risultato

Un classificatore di immagini in transfer learning — si parte da un modello pre-addestrato, si congela la base, si addestra una testa nuova sui dati del cliente — sta in poche decine di righe e si addestra in minuti su una GPU media. Per chi lavora su commessa questo significa poter portare al primo incontro un risultato e non una slide. Sul tasso di conversione dei preventivi la differenza è tutt'altro che marginale.

Vale anche all'interno di un'azienda: la fase in cui un'iniziativa di machine learning muore più spesso è quella in cui non si riesce a dimostrare niente abbastanza in fretta da tenere vivo il budget.

Il codice che qualcun altro dovrà mantenere

Il codice Keras si legge come una descrizione dell'architettura. Quando il progetto passa di mano — al team interno del cliente, a un altro fornitore, a te stesso fra diciotto mesi — questa leggibilità è denaro risparmiato. Un ciclo di addestramento scritto a mano è un debito tecnico che non compare nel preventivo ma si paga sempre, e si paga nel momento peggiore, cioè quando il modello va aggiornato e chi l'ha scritto non c'è più.

Meno errori sistemici, che sono i più cari

Batching, mescolamento dei dati, gestione dei dispositivi, accumulo delle metriche, interruzione anticipata, salvataggio del miglior checkpoint: sono tutte cose che il metodo di addestramento di Keras fa correttamente per costruzione. Sono anche tutte cose che, riscritte a mano, generano i bug più insidiosi del machine learning — quelli che non fanno fallire il programma, fanno solo scendere l'accuratezza di qualche punto senza spiegazione. Un errore che non si manifesta come errore è il tipo di problema che costa settimane.

Una competenza, tre ecosistemi

Imparare Keras 3 significa poter lavorare su progetti JAX, TensorFlow e PyTorch. Per un professionista è un moltiplicatore del mercato indirizzabile: non si rinuncia a una commessa perché «io uso l'altro framework». Per un'azienda è un'assicurazione sul personale: il codice resta leggibile a chi arriva da un ecosistema diverso.

Il vantaggio nei team misti

Nei progetti reali il modello non lo tocca solo chi fa data science. Lo tocca chi lo deve mettere dietro un endpoint, chi prepara i dati, a volte l'esperto di dominio che vuole capire che cosa sta succedendo. Keras è il framework di deep learning che queste tre figure riescono a leggere senza un corso dedicato, e questo riduce il numero di riunioni necessarie a prendere una decisione tecnica.

Dove il vantaggio si rovescia

Per onestà, tre casi in cui consiglierei altro. Ricerca su architetture nuove con dinamiche esotiche e codice che la comunità deve poter forkare: lì l'aspettativa è PyTorch puro, e andare controcorrente costa più di quanto rende. Riproduzione fedele di un paper il cui repository ufficiale è in PyTorch: riscriverlo è tempo speso male. Problemi tabellari con poche migliaia di righe: lì la risposta corretta è il gradient boosting, come abbiamo argomentato per esteso nella guida su scikit-learn, e usare una rete neurale è un errore professionale, non una scelta di stile.

Costi

La licenza, che è la parte facile

Keras è distribuito con licenza Apache 2.0: zero euro, per sempre, anche dentro un prodotto commerciale chiuso, senza obbligo di rilasciare il proprio codice e con una concessione esplicita sui brevetti che le licenze più permissive non sempre includono. Lo stesso vale per le librerie ufficiali dell'ecosistema. Nessun costo per utente, per modello o per deployment.

Detto questo, «gratis» è la parola che manda fuori budget più progetti di machine learning di qualunque altra. Il costo di un progetto Keras è tutto altrove, e la parte più cara non è quasi mai quella che il cliente si aspetta.

Le voci del conto

Voce	Ordine di grandezza	Note operative
Licenza Keras ed ecosistema	0 €	Apache 2.0, uso commerciale libero.
Sperimentazione e prototipi	0 – 50 € al mese	I piani gratuiti di Google Colab e Kaggle Notebooks bastano per imparare e per i primi esperimenti; i piani a pagamento danno GPU più stabili e sessioni più lunghe.
GPU in cloud per addestramento serio	circa 0,5 – 1,5 $/h fascia media, circa 2 – 7 $/h fascia alta	Fascia molto ampia secondo comparazioni di mercato 2026: i provider specializzati costano meno degli hyperscaler e le istanze interrompibili ancora meno, a rischio di interruzione. Da riverificare prima di ogni preventivo.
Hardware locale	1.500 – 4.000 € una tantum	Una workstation con GPU da 16-24 GB copre la maggior parte del lavoro su commessa e si ripaga in pochi mesi se l'addestramento è continuativo.
Archiviazione e traffico dati	decine di € al mese	Voce sistematicamente sottovalutata: su dataset di immagini o video il costo di uscita dei dati cresce in fretta.
Inferenza in produzione	da pochi € al mese a migliaia	Dipende interamente dalla latenza richiesta. Un modello quantizzato che gira su CPU costa una frazione di un endpoint GPU sempre acceso.
Annotazione dei dati	spesso la voce più alta in assoluto	Etichettare diecimila esempi con controllo di qualità costa più di tutto il resto messo insieme. Va messo a preventivo in modo esplicito, non nascosto nelle giornate di sviluppo.
Tempo delle persone	il costo vero	Preparazione dati, valutazione, messa in esercizio, monitoraggio. L'addestramento è la fase breve del progetto, quasi sempre meno del 20% dell'impegno.

Tre ordini di grandezza

Progetto piccolo — un classificatore su dati già etichettati e già puliti, poche migliaia di esempi, transfer learning, consegna di un modello quantizzato che gira su CPU: si ragiona in giorni-uomo, con costi di calcolo trascurabili. È il formato tipico del proof of concept.

Progetto medio — dati da raccogliere e in parte da etichettare, più cicli di sperimentazione, valutazione strutturata, endpoint di inferenza e monitoraggio di base: si ragiona in settimane-uomo, con la voce di annotazione che tipicamente supera quella di calcolo.

Progetto grande — fine-tuning di un modello di grandi dimensioni, addestramento distribuito su più acceleratori, requisiti di latenza stringenti, documentazione di conformità: qui il calcolo diventa una voce vera e la scelta del backend ha un impatto economico misurabile, perché una differenza del 20% sui tempi di addestramento si traduce direttamente in fattura.

Tre regole per non sforare

Prima: prototipa sempre su un sottoinsieme. Il 10% dei dati e tre epoche bastano a capire se l'impostazione regge. Bruciare quaranta ore di GPU per scoprire che metà delle etichette sono sbagliate è un classico che ho visto ripetersi troppe volte. Seconda: misura prima di comprare hardware. Moltissimi addestramenti sono limitati dalla pipeline dei dati e non dall'acceleratore: una scheda più potente non cambia nulla se il collo di bottiglia è la lettura da disco. Terza: separa nel preventivo il costo di addestramento da quello di inferenza. Sono due voci con dinamiche opposte — la prima è una tantum, la seconda è ricorrente e il cliente la pagherà per anni — e confonderle è il modo più rapido per ritrovarsi con un cliente scontento al terzo mese.

Funzionalità avanzate e integrazioni

È la sezione che smentisce l'etichetta di «framework per principianti». Le versioni pubblicate fra il 2024 e il 2026 hanno aggiunto capacità che riguardano direttamente chi lavora con modelli di grandi dimensioni e chi deve portarli in esercizio a costi sostenibili.

Quantizzazione: la funzione con l'impatto economico più diretto

Keras 3 espone la quantizzazione post-addestramento come un metodo del modello, non come una procedura esterna. Le modalità disponibili nelle versioni recenti sono int8 e float8 per la riduzione classica di precisione, GPTQ (dalla 3.12) per la compressione dei pesi fino a quattro bit procedendo strato per strato con metodi del second'ordine, e AWQ (dalla 3.15), la quantizzazione consapevole delle attivazioni, che protegge i pesi più sensibili e recupera parte dell'accuratezza persa con le compressioni aggressive.

Tradotto in termini di bilancio: un modello che entra nella memoria di una GPU consumer, o che gira accettabilmente su CPU, è un modello che il cliente può permettersi di tenere acceso. Nella maggior parte dei progetti che ho visto fallire in fase di messa in produzione, il problema non era l'accuratezza, era il costo mensile dell'inferenza.

Distillazione e attenzione efficiente

Dalla versione 3.12 esiste un'API dedicata alla distillazione della conoscenza: si addestra un modello piccolo a imitare le uscite di uno grande. È il complemento naturale della quantizzazione quando l'obiettivo è tagliare i costi di inferenza mantenendo la qualità su un dominio ristretto — e il dominio, nei progetti aziendali, è quasi sempre ristretto.

Sul fronte dei modelli basati su attenzione, le versioni recenti integrano flash attention e sliding window attention, cioè le tecniche che rendono praticabile l'elaborazione di contesti lunghi senza far esplodere memoria e tempi. Non è un dettaglio da ricercatori: è la differenza fra analizzare un contratto di ottanta pagine in un colpo solo e doverlo spezzare, perdendo per strada i riferimenti incrociati.

Addestramento distribuito

L'API di distribuzione permette il parallelismo sui dati — la stessa copia del modello su più acceleratori, batch diversi — in due righe di configurazione, senza toccare il codice del modello. Per il parallelismo sul modello, cioè spezzare una rete troppo grande per una singola memoria, si descrive lo sharding delle variabili tramite una mappa di layout basata su espressioni regolari.

Qui c'è un limite da conoscere prima di impegnarsi: il parallelismo sul modello è disponibile solo con backend JAX. Se il progetto prevede modelli che non entrano in un singolo acceleratore, la scelta del backend è già fatta e va comunicata al cliente all'inizio, non a metà.

Export: dove può finire un modello Keras

È la caratteristica che nel 2026 rende Keras interessante anche a chi non lo userebbe per addestrare. Il metodo di esportazione accetta cinque formati.

Formato	Destinazione tipica	Note
TensorFlow SavedModel	TensorFlow Serving, Vertex AI, ambienti TensorFlow esistenti	È il formato predefinito.
ONNX	ONNX Runtime, applicazioni in C++, C#, Java	La via maestra per far girare l'inferenza dentro un applicativo che non ha un interprete Python.
OpenVINO	Inferenza ottimizzata su CPU e acceleratori Intel, PC industriali, retail	Esiste anche come backend di sola inferenza, senza conversione manuale.
LiteRT	Android, iOS, dispositivi embedded	Con backend PyTorch richiede una firma di ingresso statica: niente dimensioni dinamiche.
PyTorch nativo	Consegna del modello come modulo PyTorch al team del cliente	Introdotto con la 3.15. L'esportazione è supportata con i backend TensorFlow, JAX e Torch.

L'ultima riga è quella commercialmente più interessante: si sviluppa con la produttività di Keras e si consegna un artefatto PyTorch puro, che il team interno gestirà con i propri strumenti senza sapere né dover sapere come è stato prodotto. Per un consulente è la risposta definitiva all'obiezione «ma noi in azienda usiamo PyTorch».

L'ecosistema ufficiale

Progetto	A che cosa serve	Quando usarlo
KerasHub	Modelli pre-addestrati per testo, immagini e audio con un'API di caricamento uniforme: BERT, T5, Whisper, Stable Diffusion, YOLO, Segment Anything e altri, ospitati su Kaggle Models.	Ogni volta che il problema non è nuovo. Cioè quasi sempre.
KerasTuner	Ricerca degli iperparametri con ricerca casuale, Hyperband e ottimizzazione bayesiana.	Quando il modello funziona ma l'ultimo punto percentuale fa la differenza contrattuale.
KerasRS	Componenti per sistemi di raccomandazione: recupero, ordinamento, embedding di grandi dimensioni.	E-commerce, portali di contenuti, marketplace.
AutoKeras	Ricerca automatica dell'architettura in poche righe.	Baseline rapide, o clienti che vogliono vedere il massimo ottenibile prima di decidere.
keras.applications	Una quarantina di architetture di visione con pesi pre-addestrati, incluse nel pacchetto base.	Transfer learning classico senza dipendenze aggiuntive.

Su KerasHub vale una nota specifica per chi lavora con modelli linguistici: le API supportano il fine-tuning con LoRA, cioè l'addestramento di un numero ridotto di parametri aggiuntivi invece che dell'intero modello. È la tecnica che rende economicamente sensato specializzare un modello sui dati di un singolo cliente, e si combina con la quantizzazione per ottenere un artefatto che gira su hardware ordinario.

Integrazioni con l'infrastruttura

Sul cloud, Vertex AI, SageMaker e Azure ML accettano container personalizzati, quindi qualunque combinazione di Keras e backend; sui TPU il percorso naturale è Keras con JAX. Per il tracciamento degli esperimenti esistono callback pronti per MLflow, Weights & Biases e Comet, mentre TensorBoard è integrato nativamente. Per il serving le strade sono TensorFlow Serving, ONNX Runtime, Triton, TorchServe o semplicemente un endpoint applicativo che carica il file del modello. Su edge e mobile si usano LiteRT per gli smartphone e OpenVINO per i PC industriali. Esiste inoltre un binding ufficiale per R, utile in contesti statistici e accademici.

Lo scenario che ricorre più spesso nelle PMI italiane, e che vale la pena descrivere perché è quello che si incontra davvero: dati in un database relazionale, estrazione in Python, addestramento in locale o su una singola GPU in cloud, esportazione in ONNX e inferenza dentro l'applicativo gestionale esistente — spesso in PHP o in .NET — tramite un microservizio o direttamente con ONNX Runtime. Non serve una piattaforma MLOps completa per il primo progetto: serve che il modello entri nel software che l'azienda già usa tutti i giorni. La varietà dei formati di esportazione rende Keras particolarmente comodo in questo scenario, ed è un argomento che nei preventivi funziona meglio di qualunque discorso sull'accuratezza.

Alternative a Keras e confronto

Il confronto in una tabella

Soluzione	Punti di forza	Limiti	Sceglila quando
Keras 3	API di alto livello, multi-backend, export verso cinque formati, ecosistema pre-addestrato, codice leggibile	Meno diffuso nella ricerca; parallelismo sul modello solo su JAX; astrazione da aggirare nei casi esotici	Progetti applicativi, team misti, tempi stretti, necessità di portabilità
PyTorch «puro»	Standard di fatto nella ricerca, comunità enorme, controllo totale, ogni paper ha il suo repository	Ciclo di addestramento e impalcatura a carico tuo: più righe, più superficie di errore	Ricerca, architetture non standard, riproduzione di paper
PyTorch Lightning	Struttura il codice PyTorch, ottimo supporto multi-GPU, molto usato in ambito industriale	Legato a PyTorch; API che cambia fra le versioni principali	Team già su PyTorch che vuole ordine e scalabilità senza cambiare mondo
fastai	Risultati ottimi con pochissimo codice, valori predefiniti eccellenti, didattica di qualità	Astrazioni molto opinionate, più difficili da personalizzare e da portare in esercizio	Prototipi rapidi e formazione
JAX con Flax	Prestazioni ai vertici su TPU e GPU, compilazione, paradigma funzionale pulito	Curva ripida, ecosistema più piccolo, debug meno immediato	Addestramento su larga scala, ricerca sulle prestazioni, TPU
Hugging Face Transformers	Catalogo di modelli imbattibile, strumenti di addestramento maturi, standard per il linguaggio	Specializzato sui transformer; meno adatto ad architetture custom non testuali	Qualunque progetto basato su modelli linguistici pre-addestrati
scikit-learn, XGBoost, LightGBM	Imbattibili sui dati tabellari, velocissimi, interpretabili, costo di calcolo irrisorio	Non fanno deep learning	Dati tabellari, poche migliaia di righe, necessità di spiegare il modello
tf.keras (Keras 2)	Compatibilità con codice preesistente tramite il pacchetto dedicato	In sola manutenzione: nessuna funzionalità nuova	Solo per mantenere progetti vecchi. Per il nuovo, Keras 3

Keras o PyTorch: la domanda sbagliata

Nel 2026 la contrapposizione non ha più molto senso tecnico, perché Keras gira su PyTorch. La domanda corretta è un'altra: vuoi scrivere tu il ciclo di addestramento? Se la risposta è no, perché il valore del progetto sta nei dati, nella valutazione e nella messa in esercizio, Keras con backend PyTorch dà l'ergonomia dell'uno e l'ecosistema dell'altro. Se la risposta è sì, perché stai facendo qualcosa di davvero non standard, usa PyTorch nativo — sapendo che puoi comunque riusare strati e ottimizzatori Keras dentro il tuo ciclo, e che la scelta non è definitiva.

Il criterio di scelta in tre domande

I dati sono tabellari e in quantità moderata? Allora gradient boosting, non deep learning, e la guida su scikit-learn spiega perché. Il problema è già risolto da un modello pre-addestrato? Allora KerasHub o Hugging Face, fine-tuning, fine — e il valore che aggiungi sta nei dati e nella valutazione, non nell'architettura. Devi inventare un'architettura nuova? Allora PyTorch o JAX. In tutti gli altri casi, che nella pratica professionale italiana sono la maggioranza, Keras 3.

Strategie di crescita usando Keras

Per un'azienda: il percorso che funziona

Il percorso che nelle aziende italiane porta a qualcosa di utile ha quasi sempre la stessa forma, e raramente comincia da dove ci si aspetta. Primo passo: un problema con un numero attaccato. Non «vogliamo usare l'intelligenza artificiale», ma «gli scarti in linea sono il 3% e vogliamo dimezzarli», oppure «la classificazione manuale dei documenti in ingresso occupa due persone a tempo pieno». Senza un numero di partenza non esiste un modo di dire se il progetto è riuscito, e senza quello non esiste il secondo progetto.

Secondo passo: verificare i dati prima di parlare di modelli. Nella grande maggioranza dei casi i dati esistono, ma sono sparsi, incoerenti o non etichettati, e questa è la fase in cui si decide se il progetto è fattibile. Terzo passo: un prototipo su un sottoinsieme, con transfer learning, per stabilire se il segnale c'è. Quarto: valutazione seria, con metriche legate al business e non solo all'accuratezza — un modello con il 95% di accuratezza può essere inutile se sbaglia proprio sui casi che costano. Quinto: messa in esercizio e monitoraggio. È il passo che quasi nessuno mette a budget e che decide se il modello sopravvive oltre sei mesi.

Per un professionista: che cosa ha mercato

«Faccio machine learning» non vende. «Automatizzo il controllo qualità visivo per le aziende metalmeccaniche» vende. La tecnologia sottostante è la stessa — una rete convoluzionale in transfer learning — ma la formulazione verticale permette di riusare il grosso del lavoro fra un cliente e l'altro, di parlare la lingua del settore e di sostenere una tariffa più alta senza discuterla.

I verticali che in Italia hanno domanda concreta e barriera d'ingresso ragionevole sono, per esperienza diretta e per quello che passa dalle richieste sulla piattaforma: controllo qualità visivo in ambito manifatturiero, classificazione e estrazione dati da documenti per studi professionali e assicurazioni, previsione della domanda per retail e distribuzione, manutenzione predittiva su macchinari già sensorizzati, analisi e smistamento automatico delle richieste di assistenza.

Il proof of concept a prezzo fisso

È il formato commerciale che funziona meglio per entrare da un cliente nuovo: durata due-quattro settimane, prezzo fisso, e criteri di successo scritti prima di iniziare — per esempio un valore minimo di una metrica concordata su un insieme di test fornito dal cliente e mai visto dal modello. Costa poco al cliente, rischia poco per te se hai già i tuoi modelli di partenza, e se funziona apre un progetto strutturato con un interlocutore che ormai si fida.

Keras è il framework giusto per questo formato proprio perché comprime i tempi della parte di modellazione, lasciando spazio a quella che decide l'esito: capire i dati del cliente.

Costruirsi una libreria di componenti riutilizzabili

Ogni progetto dovrebbe lasciare qualcosa di riusabile: uno scheletro di repository con la struttura dati-addestramento-valutazione già pronta, una raccolta di callback e metriche personalizzate, script di preparazione per i formati che si incontrano più spesso, un modello di report di valutazione da consegnare al cliente. Dopo tre progetti, il quarto costa la metà a parità di prezzo: è così che un professionista aumenta il margine senza aumentare la tariffa oraria, ed è l'unico modo di scalare quando si vende tempo.

Vendere il servizio, non il modello

Un modello consegnato una tantum è un ricavo unico e un rischio permanente, perché i dati cambiano e l'accuratezza scende: si chiama deriva, ed è fisiologica. La struttura corretta è progetto iniziale a corpo più canone mensile di monitoraggio, riaddestramento periodico e supporto. Il canone si giustifica con un argomento che al cliente va spiegato in modo semplice — i dati di domani non sono quelli di ieri, il modello va ritarato — e trasforma una consulenza episodica in ricavo ricorrente. È anche, non secondariamente, la struttura che protegge il cliente da una brutta sorpresa al diciottesimo mese.

Autorevolezza tecnica come canale di acquisizione

Nel machine learning il cliente non sa valutare la competenza prima di comprarla, quindi si affida ai segnali. Notebook pubblici, contributi ai repository dell'ecosistema, articoli tecnici in italiano su casi concreti, interventi a incontri locali. Vale la pena insistere su un punto: la produzione di contenuti tecnici di qualità in lingua italiana su questi temi è scarsissima, il che significa che chi la fa bene si posiziona nei risultati di ricerca con una concorrenza molto più debole di quella che troverebbe in inglese. È lavoro non fatturabile che genera richieste senza dover fare chiamate a freddo.

Il mercato italiano, e dove si concentra la domanda

Il tessuto produttivo italiano è fatto di piccole e medie imprese con dati reali e poche competenze interne, il che produce una domanda molto specifica: progetti di dimensione contenuta, budget prudenti, forte diffidenza verso le soluzioni che richiedono di mandare i dati fuori dall'azienda. È un contesto in cui la combinazione di modelli piccoli, quantizzati e installabili in sede vale più di qualunque discorso sullo stato dell'arte, e in cui la capacità di integrare il modello nel gestionale esistente conta più dell'accuratezza dell'ultimo punto percentuale. Keras, con la sua flessibilità di esportazione, si trova in una posizione favorevole proprio qui.

Tendenze future

Modelli piccoli, specializzati, quantizzati

La direzione è chiara e va contro l'intuizione mediatica: nelle applicazioni aziendali sta vincendo il modello piccolo e specializzato, non quello gigantesco e generalista. Un modello distillato e quantizzato a quattro bit che risolve un compito meglio di un modello generico, a un decimo del costo di inferenza, è quello che un direttore finanziario approva. Il fatto che Keras abbia integrato GPTQ, AWQ e la distillazione proprio nelle ultime versioni non è una coincidenza: è il framework che segue il mercato invece della narrazione.

L'inferenza si sposta sul dispositivo

Latenza, costi ricorrenti e — soprattutto in Europa — riservatezza dei dati stanno spingendo l'inferenza fuori dal cloud. I percorsi verso LiteRT per il mobile e verso OpenVINO per i PC industriali sono oggi molto più lisci di due anni fa. Per chi lavora con clienti che trattano dati sensibili — sanità, studi legali, manifattura con segreti industriali — «il dato non esce dall'azienda» è un argomento commerciale che chiude i contratti, spesso più di qualunque dimostrazione tecnica.

La convergenza dei framework

La barriera fra framework si sta dissolvendo, e Keras 3 ne è il sintomo più evidente. Con ONNX come formato di scambio, l'esportazione verso modulo PyTorch nativo e i backend intercambiabili, la domanda «quale framework usi?» sta diventando meno rilevante di «quale artefatto consegni, e chi lo dovrà mantenere?». Questa tendenza accelererà, e chi imposta oggi i progetti pensando all'artefatto finale invece che allo strumento si troverà in vantaggio.

Sistemi composti, non modelli singoli

I progetti del 2026 raramente sono «un modello». Sono catene: un modello di embedding per la ricerca, un modello linguistico per la generazione, un classificatore per lo smistamento, regole deterministiche per i vincoli di business. La competenza che cresce di valore non è addestrare il modello migliore, è orchestrare i componenti e misurare il sistema nel suo insieme. Keras entra in queste catene come mattone specializzato, tipicamente per i pezzi su misura che nessun modello pre-addestrato copre.

Conformità e documentazione tecnica

Il quadro normativo europeo sull'intelligenza artificiale sta entrando progressivamente in vigore con obblighi crescenti, in particolare per i sistemi classificati ad alto rischio, e il calendario di applicazione è stato oggetto di discussioni e di proposte di rimodulazione: per questo qui si parla di direzione e non di date. La direzione, però, è irreversibile: servirà documentare i dati di addestramento, le metriche di valutazione, i limiti noti e le misure di sorveglianza umana. Chi prende oggi l'abitudine di produrre una scheda tecnica del modello per ogni progetto si troverà pronto quando servirà — e nel frattempo potrà fatturarla come parte del servizio.

Hardware: più scelta, meno vincoli

Con l'ingresso di nuovi acceleratori e la maturazione dei backend, la capacità di cambiare hardware senza riscrivere il codice diventa un vantaggio economico misurabile. È esattamente la scommessa architetturale su cui Keras 3 è stato costruito, ed è la ragione principale per cui, se si deve imparare un framework di deep learning adesso, questo è il momento giusto per scegliere quello che non lega le mani.

Domande frequenti

Keras è gratuito anche per uso commerciale?

Sì. Keras è distribuito con licenza Apache 2.0: si può usare, modificare e includere in prodotti commerciali chiusi senza pagare nulla e senza obbligo di rilasciare il proprio codice. I costi di un progetto derivano da hardware, dati e tempo delle persone, non dalla licenza.

Devo installare TensorFlow per usare Keras?

No, non più. Da Keras 3 si può installare Keras con JAX, con PyTorch o con TensorFlow indifferentemente. Il backend si sceglie con la variabile d'ambiente KERAS_BACKEND oppure nel file di configurazione ~/.keras/keras.json. Esiste inoltre un backend OpenVINO dedicato alla sola inferenza.

Meglio Keras o PyTorch per iniziare?

Se l'obiettivo è ottenere risultati su problemi applicativi in tempi brevi, Keras: richiede meno codice, ha meno punti in cui sbagliare e produce codice che altri riescono a leggere. Se l'obiettivo è la ricerca o la riproduzione di paper, PyTorch, perché è lo standard in quel contesto. Non è comunque una scelta esclusiva: Keras 3 può usare PyTorch come backend, quindi si possono imparare entrambi in modo graduale.

Keras è adatto ai modelli linguistici di grandi dimensioni?

Sì, con i limiti del caso. Tramite KerasHub si caricano e si specializzano modelli linguistici pre-addestrati, con supporto a LoRA, quantizzazione GPTQ e AWQ fino a quattro bit, flash attention e sliding window attention. Per l'addestramento da zero di modelli di frontiera l'ecosistema di riferimento resta un altro, ma per il fine-tuning e la messa in esercizio di modelli di dimensioni medie Keras è pienamente attrezzato.

Posso portare in produzione un modello Keras senza Python?

Sì. Il metodo di esportazione genera un artefatto ONNX, OpenVINO, LiteRT, SavedModel TensorFlow oppure un modulo PyTorch nativo. ONNX in particolare permette di eseguire l'inferenza da C++, C#, Java e altri linguaggi tramite ONNX Runtime, senza che l'applicazione ospite debba avere un interprete Python installato.

Quanto hardware serve per iniziare seriamente?

Per imparare e per i primi prototipi bastano i piani gratuiti di Google Colab o Kaggle Notebooks. Per lavoro su commessa continuativo, una workstation con GPU da 16-24 GB di memoria copre la grande maggioranza dei casi di transfer learning e si ripaga rapidamente rispetto all'affitto di GPU in cloud. Gli acceleratori di fascia alta in cloud hanno senso per i picchi di lavoro, non come regime permanente.

Il codice scritto con Keras 2 funziona con Keras 3?

In larghissima parte sì: Keras 3 implementa l'intera superficie pubblica dell'API di Keras 2, con poche eccezioni documentate e una guida ufficiale alla migrazione. Per il codice legacy che non si può toccare esiste un pacchetto dedicato che congela il comportamento di Keras 2, ma è in sola manutenzione: per i progetti nuovi la scelta è Keras 3.

Come si passa da un backend all'altro senza rompere nulla?

Se il codice usa solo API Keras e keras.ops per le operazioni numeriche, il passaggio è immediato. I problemi nascono quando dentro un layer personalizzato ci sono chiamate dirette a funzioni di un backend specifico: in quel caso vanno riscritte. Conviene adottare questa disciplina fin dall'inizio, anche quando non si prevede di cambiare motore, perché è ciò che tiene aperta l'opzione.

In sintesi

Primo: Keras nel 2026 è una cosa diversa da quella che molti ricordano. Non è più il livello semplificato di TensorFlow, è un framework di modellazione indipendente che gira su quattro motori di calcolo, esporta verso cinque formati di produzione, integra quantizzazione a quattro bit, distillazione e attenzione efficiente, e mantiene la caratteristica che lo ha reso famoso: il codice si scrive in fretta e si legge ancora più in fretta. Secondo: la domanda «Keras o PyTorch» è mal posta, perché Keras gira su PyTorch; la domanda giusta è se vuoi scrivere tu il ciclo di addestramento, e nella maggior parte dei progetti applicativi la risposta onesta è no, perché il valore sta nei dati e nella messa in esercizio. Terzo: il costo di un progetto non è nella licenza, che è zero, ma nell'annotazione dei dati e nel tempo delle persone — e chi presenta un preventivo che lo dice chiaramente parte avvantaggiato rispetto a chi promette miracoli.

Il consiglio con cui chiudo è lo stesso che darei a un cliente e a un collega: non partire dal modello, parti dal dato e dalla metrica. Il modello, con Keras, è la parte veloce.

Se stai valutando come introdurre il deep learning nella tua azienda, o hai modelli da costruire, da mettere in produzione o da rendere sostenibili come costo di esercizio, su FreelanceWWW trovi professionisti che quel lavoro lo hanno già fatto: pubblica il tuo progetto e ricevi le offerte. Se stai confrontando gli strumenti, questa guida fa parte di una serie con quelle su PyTorch, TensorFlow e scikit-learn; sul profilo professionale trovi invece il freelance Python per l'intelligenza artificiale e che cosa fa un freelance Python.

Introduzione a Keras e alla costruzione di modelli di machine learning 2026