Introduzione alla piattaforma distribuita MLflow per automatizzare i flussi di lavoro Machine Learning su big data 2026

Caratteristiche, architettura distribuita, costi reali, integrazioni e alternative della piattaforma open source che governa il ciclo di vita di modelli ML e agenti LLM

MLflow è il livello di controllo su cui, nel 2026, gira la maggior parte del lavoro di machine learning che arriva in produzione: oltre 30 milioni di download al mese, più di 20.000 stelle su GitHub, 900 contributori, integrazioni con più di 100 strumenti. La versione stabile di riferimento è la 3.15.2, rilasciata il 25 agosto 2026. Il progetto vive sotto la Linux Foundation, non dentro il listino di un singolo fornitore — un dettaglio che nel mercato attuale pesa quanto una funzionalità.

Questa guida percorre la piattaforma per intero: che cosa fa davvero e che cosa non fa, come è costruita per reggere quando i dati diventano grandi, quali vantaggi porta su machine learning e deep learning, quanto costa esercirla sul serio, quali funzionalità avanzate sono arrivate negli ultimi dodici mesi, quali alternative esistono e con quali prezzi, come si costruisce una strategia di crescita attorno ad essa e dove sta andando. Una precisazione va messa subito, perché circola male: MLflow non è un motore AutoML. È lo strato che rende ripetibile, tracciabile e distribuibile il lavoro degli AutoML, degli hyperparameter tuner e — dal 2025 in poi — degli agenti LLM. Non è una questione di terminologia: cambia che cosa vi aspettate dallo strumento e che cosa dovete comprare o costruire altrove.

Che cos'è MLflow, e che cosa non è

MLflow nasce nel 2018 dentro Databricks per risolvere un problema banale e universale: dopo la quarantesima esecuzione di un training, nessuno ricorda più quale combinazione di iperparametri ha prodotto il modello che sta girando in produzione. Nel 2020 il progetto è stato donato alla Linux Foundation. Da allora la governance è aperta: chiunque può forkare, self-hostare, contribuire.

I numeri, e quelli che non esistono

I dati pubblicati dal progetto sono questi: oltre 30 milioni di download mensili, più di 20.000 stelle su GitHub, oltre 900 contributori. Fra le aziende che ne dichiarano l'uso compaiono Databricks, Microsoft, Meta, Zillow, Toyota, Booking, Wix, Accenture, ASML.

Quello che non esiste è un numero affidabile di installazioni in produzione. I download PyPI contano anche le pipeline CI che reinstallano il pacchetto cinquanta volte al giorno, e nessuno pubblica quanti tracking server siano effettivamente accesi. Quando leggete "la piattaforma MLOps più usata al mondo" state leggendo un'inferenza dai download, non una misurazione. È probabilmente vera, ma resta un'inferenza, ed è giusto dirlo.

Perché non è un AutoML, e perché va detto chiaramente

MLflow non seleziona algoritmi al posto vostro, non fa feature engineering automatico, non lancia una ricerca architetturale. Non contiene un motore AutoML. Contiene il registro dove un motore AutoML deposita i propri risultati.

In pratica: Optuna, FLAML, AutoGluon, H2O e Databricks AutoML producono decine o centinaia di trial. MLflow li registra tutti come esecuzioni confrontabili, con parametri, metriche, artefatti e lineage completo. Databricks AutoML, per esempio, genera notebook Python leggibili e logga ogni tentativo su MLflow, così il "modello automatico" resta ispezionabile invece di essere una scatola nera. La formulazione corretta è: MLflow è la piattaforma su cui l'AutoML diventa verificabile. Se cercate un prodotto che, dato un CSV, restituisce un modello senza scrivere codice, MLflow non è quel prodotto e nessuna configurazione lo farà diventare tale.

Chi lo governa, e perché conta più di quanto sembri

Il 4 dicembre 2025 OpenAI ha annunciato l'acquisizione di Neptune.ai, piattaforma di experiment tracking con una base utenti solida. Il 4 marzo 2026 alle 10:00 PST l'applicazione ospitata e le API sono state spente, e i dati residui cancellati in modo irreversibile. Neptune stessa ha pubblicato le istruzioni per migrare verso MLflow e Weights & Biases.

Chi aveva self-hostato si è trovato con una roadmap ferma. Chi era su SaaS ha avuto tre mesi per esportare anni di esperimenti. È il caso di scuola del rischio di piattaforma, ed è il motivo per cui nel 2026 "il progetto sta sotto una fondazione neutrale ed è self-hostabile" va messo in tabella accanto alle funzionalità, non nelle note a piè di pagina.

Le caratteristiche principali

MLflow oggi è cresciuto ben oltre i quattro componenti originali. La superficie attuale copre due mondi che convivono nello stesso server: il machine learning classico e le applicazioni GenAI ad agenti.

Tracking: run, parametri, metriche, artefatti

Il cuore resta lo stesso. Una riga — mlflow.autolog() — e la libreria intercetta il training di scikit-learn, PyTorch, TensorFlow, XGBoost, LightGBM, Keras, transformers e decine di altri framework, registrando iperparametri, metriche per epoca, curve, modello serializzato e ambiente di esecuzione. Chi vuole controllo esplicito usa log_param, log_metric, log_artifact.

Il valore non è il logging in sé: è poter ordinare 400 esecuzioni per metrica, filtrarle per tag, confrontarne cinque affiancate e — dalla 3.15 — salvare e condividere una vista della tabella tramite URL, con colonne, filtri, ordinamenti e larghezze. Sembra una piccolezza. In un team di sei persone è la differenza fra una discussione e uno screenshot incollato in chat.

LoggedModel: il cambio di paradigma di MLflow 3

La novità architetturale più importante degli ultimi due anni è l'entità LoggedModel, promossa a cittadino di prima classe. Prima, tutto ruotava attorno all'esecuzione: il modello era un artefatto appeso a una run. Adesso il modello ha identità propria e tiene insieme, in un unico grafo di lineage, le esecuzioni che lo hanno prodotto, i checkpoint intermedi, i prompt usati, le tracce raccolte e le metriche di valutazione.

Per il deep learning risolve un fastidio concreto: un training da trenta ore produce decine di checkpoint, e prima della versione 3 non c'era un modo pulito per trattarli come entità confrontabili invece che come file dentro una cartella. Per gli agenti GenAI ne risolve uno più grosso: la stessa "versione dell'agente" viene interrogata mille volte, valutata in batch notturni e ritoccata con un prompt nuovo; senza un'entità che tenga insieme tutto questo, il lineage si spezza al primo ciclo.

Model Registry: versioni, alias, promozione

Il registry è il punto in cui un modello smette di essere un esperimento e diventa un asset: versionamento incrementale, alias mobili come @champion, @production e @staging, tag, descrizioni, e un'API che il codice di serving interroga per alias invece che per numero di versione. È la differenza fra un rollback che è un comando e un rollback che è un deploy.

Tracing: l'osservabilità che parla OpenTelemetry

MLflow Tracing è la componente che ha cambiato la natura del prodotto. Registra, per ogni chiamata a un'applicazione LLM o a un agente, l'albero completo degli span: input e output di ogni passo intermedio, metadati, latenza, token consumati e costo stimato.

Il punto tecnico che conta: è pienamente compatibile con OpenTelemetry e supporta nativamente le GenAI Semantic Conventions. Le tracce escono in un formato standard, si esportano verso lo stack di osservabilità che già avete e non restano prigioniere del fornitore. L'auto-tracing funziona con una riga per OpenAI, Anthropic, LangChain, DSPy, Vercel AI, PydanticAI, smolagents e molti altri. Per la produzione ci sono il logging asincrono — per non pagare la latenza del tracing sulla richiesta dell'utente — e un SDK leggero, mlflow-tracing, che riduce del 95% l'impronta di installazione: utile quando il tracing deve entrare in un container di inferenza e non in un notebook.

Evaluation: scorer, giudici LLM e dataset immutabili

La suite di valutazione mette insieme quattro pezzi: oltre 50 metriche integrate, giudici LLM configurabili (LLM-as-a-judge), dataset di valutazione gestiti come un database di test centralizzato, e una review app per raccogliere feedback umano strutturato.

Le aggiunte recenti sono quelle che contano in produzione. I giudici multimodali (3.15) accedono a immagini e screenshot convertendo gli allegati in base64 e supportano modelli Anthropic, Gemini e OpenAI: valutare un agente che legge interfacce non richiede più una pipeline artigianale. Le versioni immutabili dei dataset di valutazione (3.15.2) chiudono il buco più insidioso della valutazione — se il dataset cambia sotto i piedi, i confronti storici fra versioni dell'applicazione non valgono niente. Gli scorer ensemble, sempre nella 3.15.2, permettono di combinare più giudici invece di affidarsi al parere di uno solo.

Prompt Registry e AI Gateway

I prompt sono codice, ma vivono spesso come stringhe dentro un file. Il Prompt Registry li versiona, li collega alle valutazioni e li ottimizza automaticamente a partire dal feedback di valutazione e da dataset etichettati: la stessa idea del tuning degli iperparametri, applicata al testo.

L'AI Gateway, invece, espone un endpoint unificato verso più provider — OpenAI, Anthropic, endpoint passthrough nei formati nativi. Da lì passano archiviazione centralizzata delle chiavi API, logging di richieste e risposte per audit, traffic splitting per A/B test, failover automatico fra provider, rate limiting, guardrail di contenuto e tracciamento dei costi con soglie e avvisi di budget. La configurazione è dinamica, senza riavvio del server. Tradotto in termini organizzativi: le chiavi non girano più nei file .env di otto sviluppatori, e quando un fornitore alza i prezzi si cambia rotta in un file di configurazione invece che in venti repository.

Lo stack in sintesi

Architettura distribuita: che cosa significa "su big data"

"Piattaforma distribuita", nel caso di MLflow, significa una cosa precisa e conviene disambiguarla subito: MLflow non distribuisce il calcolo. Distribuisce lo stato del vostro lavoro di ML fra più macchine, più team e più ambienti, mentre il calcolo lo fanno Spark, Ray, Kubernetes o il vostro cluster GPU.

Backend store e artifact store: due archivi, due problemi diversi

Il backend store conserva i metadati — identificativi delle esecuzioni, tempi, parametri, metriche, tag, tracce. Può essere il filesystem locale, adatto solo allo sviluppo, o un database compatibile con SQLAlchemy: SQLite, PostgreSQL, MySQL, SQL Server. In produzione è PostgreSQL nella grande maggioranza dei casi.

L'artifact store conserva i file grossi: pesi dei modelli, immagini, dataset, pacchetti di modello. Di default è la cartella locale mlruns, ma in un'installazione seria è Amazon S3, Azure Blob Storage, Google Cloud Storage o HDFS.

Separare i due archivi è esattamente ciò che rende MLflow scalabile: i metadati sono piccoli e interrogati di continuo, gli artefatti sono enormi e letti raramente. Metterli nello stesso posto è l'errore classico delle prime installazioni, e si paga quando il database supera i cento gigabyte e la UI inizia a impiegare dieci secondi per aprire una lista.

Il collo di bottiglia storico: gli artefatti che passano dal server

Per anni il tracking server ha fatto da proxy per upload e download degli artefatti: un checkpoint da 8 GB attraversava il server, che diventava il collo di bottiglia e andava regolarmente in timeout. Dalla 3.15 esistono i trasferimenti senza proxy tramite URL pre-firmati: il client parla direttamente con l'object storage, il server emette solo l'autorizzazione. È la singola modifica che più incide sulla capacità di reggere carichi di deep learning reali.

Spark, Ray e il training distribuito

Su Spark, MLflow si integra con il flavor dedicato e con mlflow.pyfunc.spark_udf, che trasforma un modello registrato in una UDF Spark: inferenza batch su miliardi di righe senza riscrivere il modello. Nel training distribuito il pattern corretto è uno solo e va imparato subito: logga solo il rank 0. Se tutti i worker scrivono sulla stessa esecuzione ottenete metriche duplicate e un database che cresce in modo insensato. Le integrazioni con PyTorch Lightning, Ray Train e Horovod gestiscono già questa logica, ma nel codice scritto a mano la responsabilità resta vostra.

Kubernetes e l'Helm chart ufficiale

Dalla 3.13 il progetto pubblica un Helm chart ufficiale con TLS, storage persistente e metriche Prometheus. Prima si passava da chart della comunità di qualità variabile. Per chi esercisce MLflow come servizio interno è il passaggio da "installazione artigianale" a "componente di piattaforma con un runbook" — e cambia chi, in azienda, è disposto a firmarne l'adozione.

I vantaggi competitivi

Il costo non cresce con le persone

Il vantaggio economico di MLflow non è "è gratis" — l'esercizio costa, e lo vediamo fra poco. È che il costo non cresce con il numero di persone. Le piattaforme commerciali di experiment tracking si pagano quasi tutte per postazione: aggiungere tre data scientist significa aggiungere tre canoni. Su MLflow aggiungere tre persone significa aggiungere tre utenze su un server che già gira.

Il punto di pareggio si sposta in fretta. Un team di dieci persone su una piattaforma da 50-60 dollari per utente al mese paga fra i 6.000 e i 7.000 dollari l'anno di sole licenze; un tracking server self-hosted decoroso costa meno, anche contando il tempo di chi lo mantiene. Sotto le tre persone, però, spesso vince la piattaforma gestita: è giusto dirlo, perché l'argomento economico non funziona in tutte le direzioni.

Deep learning: i checkpoint diventano entità, non file

Per il deep learning MLflow offre tre cose che il tracking generico non dà: il logging per-step delle metriche durante l'addestramento, con visualizzazione delle curve mentre il training gira; la gestione dei checkpoint come entità di primo livello grazie a LoggedModel; e il supporto per artefatti pesanti e multimediali, video compresi. Se addestrate modelli che girano per giorni, il valore sta nel poter interrompere, confrontare, ripartire da un checkpoint preciso e dimostrare mesi dopo da dove veniva quel peso.

Portabilità: il formato è diventato lo standard

Il formato MLflow Model — codice, dipendenze, firma di input e output, ambiente — è ormai una lingua franca. Lo stesso modello registrato una volta si serve in locale con mlflow models serve, si impacchetta in Docker con mlflow models build-docker, si distribuisce su Kubernetes, Amazon SageMaker, Azure ML, Databricks Model Serving o Modal, oppure su target comunitari come Ray Serve, TorchServe e RedisAI attraverso i plugin. Un solo artefatto, molte destinazioni: è la definizione operativa di assenza di lock-in.

Il vantaggio di conformità, che nel 2026 è diventato concreto

Dal 2 agosto 2026 sono applicabili gli obblighi di trasparenza dell'articolo 50 dell'AI Act — dichiarare all'utente che sta interagendo con un sistema di IA, segnalare riconoscimento delle emozioni e categorizzazione biometrica, dichiarare l'origine artificiale dei deepfake — insieme ai regimi sanzionatori nazionali dell'articolo 99, con sanzioni fino a 35 milioni di euro o il 7% del fatturato mondiale per le pratiche vietate. Il Digital Omnibus, regolamento (UE) 2026/1744 in vigore dal 27 luglio 2026, ha rinviato la parte più pesante: i sistemi ad alto rischio dell'Allegato III al 2 dicembre 2027 e quelli dell'Allegato I al 2 agosto 2028.

Il rinvio è una proroga, non un'assoluzione. Gli obblighi rinviati chiedono documentazione tecnica, tracciabilità delle scelte, log conservati e capacità di dimostrare come un modello è stato addestrato e valutato: esattamente gli artefatti che un tracking server produce come effetto collaterale del lavoro quotidiano. A una condizione, però — che sia acceso prima, perché il lineage non si ricostruisce a posteriori. Chi comincia a tracciare oggi arriva alla scadenza con due anni di storia; chi comincia nel 2027 arriva con un foglio bianco.

Questo è un riepilogo tecnico, non un parere legale: per la qualificazione del vostro specifico sistema serve un consulente.

I limiti, detti chiaramente

Nessuno strumento fa tutto, e MLflow ha confini netti che conviene conoscere prima di sceglierlo:

• Non orchestra il calcolo. Non ha uno scheduler: per far girare le pipeline servono Airflow, Dagster, Prefect o Ray.

• Non fa data versioning. Traccia il riferimento a un dataset, non il dataset: per quello servono DVC, LakeFS, Delta Lake o simili.

• Non è un feature store. Il calcolo e la coerenza delle feature fra training e inferenza restano un problema vostro.

• Non è AutoML. Registra i risultati di chi lo fa, non li produce.

• Il database va curato. Senza retention, archiviazione delle tracce e potatura, con volumi GenAI alti degenera in qualche mese.

• L'interfaccia non è il suo punto di forza. Sui grafici e sulla condivisione visuale dei risultati, Weights & Biases resta più avanti.

Costi

MLflow è open source sotto licenza Apache 2.0. Il costo reale si compone di tre voci: infrastruttura, storage e il tempo di chi mantiene il servizio. La terza è quasi sempre la più grande, e quasi sempre quella che nessuno mette a bilancio.

Self-hosted: la struttura del conto

Un tracking server per un team piccolo è, all'osso, tre cose: un'istanza di calcolo modesta, un database PostgreSQL gestito, un bucket di object storage. Gli ordini di grandezza su un cloud pubblico — con listini che vanno sempre verificati al momento dell'acquisto, perché cambiano e variano per regione — sono questi:

• Calcolo, un'istanza da 2 vCPU e 8 GB sufficiente fino a qualche decina di utenti: poche decine di euro al mese;

• Database gestito, PostgreSQL piccolo con backup: cifra analoga, spesso superiore a quella del calcolo;

• Object storage: qualche centesimo per GB al mese, più il traffico in uscita — la voce che sorprende chi scarica spesso checkpoint da diversi gigabyte.

Un'installazione di questo tipo sta ampiamente sotto i 200 euro al mese. È questo il numero da confrontare con le licenze, non lo zero della licenza open source.

Gestito: quanto costa non occuparsene

I servizi gestiti pubblicano listini eterogenei. Nebius, per esempio, espone un prezzo trasparente per il suo Managed Service for MLflow: un cluster medium da 8 vCPU e 32 GiB costa 0,48 dollari l'ora, cioè circa 350 dollari al mese di calcolo continuo, più circa 14,20 dollari al mese per i 200 GiB di disco SSD inclusi — intorno ai 364 dollari mensili, object storage escluso.

Databricks offre MLflow gestito dentro la piattaforma, fatturato in DBU insieme al resto, e una Free Edition che include MLflow ospitato: è la via più rapida per provarlo senza costruire niente, con i limiti tipici di un livello gratuito. AWS, Azure e Google lo espongono rispettivamente dentro SageMaker, Azure Machine Learning e Vertex AI, con modelli di prezzo integrati nei rispettivi servizi.

Il costo che non compare in fattura

Chi aggiorna il server quando esce una versione minore? Chi gestisce le migrazioni dello schema del database? Chi risponde quando un data scientist dice che la UI è lenta perché il database ha quaranta milioni di righe di metriche? In un'organizzazione strutturata è mezza giornata al mese di un ingegnere di piattaforma; nelle prime settimane è parecchio di più. Stimatelo, mettetelo a budget e poi confrontatelo con il canone del gestito. A volte il gestito vince, e non è una sconfitta.

Scenari a confronto

Funzionalità avanzate e integrazioni

RBAC e multi-workspace: MLflow diventa multi-tenant

La 3.13 ha introdotto un sistema di controllo degli accessi basato sui ruoli: i ruoli sono insiemi riutilizzabili di permessi, si assegnano agli utenti e coprono esperimenti, modelli, prompt, scorer ed endpoint dell'AI Gateway. C'è una Admin UI per amministrare utenti, ruoli e permessi senza passare dalle REST API. La 3.10 aveva già aggiunto il supporto multi-workspace.

Le due cose insieme cambiano la categoria dello strumento: da tracking server di un team a servizio condiviso di un'organizzazione, dove il progetto del cliente A non vede quello del cliente B. Per un'agenzia o un freelance con più clienti è la funzionalità che rende difendibile ospitare tutto su un'unica installazione.

Trace archival: come non far esplodere il database

Un'applicazione GenAI con traffico reale produce tracce a un ritmo che il database SQL non regge a lungo. Il trace archival, introdotto nella 3.13, sposta automaticamente le tracce più vecchie dal database verso object storage economico mantenendole leggibili nell'interfaccia. Si configura in YAML indicando destinazione, policy di retention e intervallo di esecuzione. È la differenza fra un sistema che si mantiene da solo e uno da potare a mano ogni trimestre.

MCP Registry: il pezzo nuovo del 2026

La 3.15 ha introdotto un registro dei server MCP (Model Context Protocol): configurazioni con versionamento semantico, alias promuovibili come @production e @staging, condivisione fra team. È lo stesso pattern del Model Registry applicato agli strumenti che un agente può chiamare, e arriva esattamente nel momento in cui MCP è diventato il modo standard di dare strumenti a un LLM. Chi costruisce agenti in azienda smette di avere sette configurazioni divergenti in sette repository.

Assistant, coding agent e review queue

La piattaforma ha assorbito il lavoro con gli agenti di codice. L'MLflow Assistant supporta più provider — Claude Code, Codex, endpoint API, Ollama — con configurazione tramite chiave API, e mostra in chiaro chiamate agli strumenti e costi. Dalla 3.13 c'è il provisioning con un click di endpoint preconfigurati per agenti come Claude Code e Gemini CLI; dalla 3.14, il setup di un agente in un comando solo, le Review Queue per organizzare il feedback umano come una coda di lavoro e l'integrazione con pytest, che porta la valutazione dentro la suite di test invece che accanto ad essa. La 3.11.1 aveva aggiunto il rilevamento automatico dei problemi e i modelli senza pickle — dettaglio di sicurezza non banale, visto che il pickle è codice arbitrario travestito da file di dati.

Integrazioni e linguaggi

MLflow espone SDK per Python, TypeScript/JavaScript, Java e R. Le integrazioni coprono i framework di ML classico (scikit-learn, XGBoost, LightGBM, PyTorch, TensorFlow, Keras, Prophet, statsmodels, ONNX), quelli GenAI (LangChain, LlamaIndex, DSPy, OpenAI, Anthropic, Vercel AI, PydanticAI, smolagents), i motori distribuiti (Spark, Ray) e l'osservabilità via OpenTelemetry. Il supporto TypeScript merita una nota: significa che il tracing può partire dal front-end di un'applicazione Node invece che solo dal backend Python, cosa che fino a due anni fa costringeva a scrivere un proxy apposta.

Deployment: dove finisce il modello

Le destinazioni supportate ufficialmente sono server locale con mlflow models serve, container Docker, Kubernetes, Amazon SageMaker, Azure ML con endpoint gestiti, ACI o AKS, Databricks Model Serving e Modal per il serverless con GPU on-demand. Attraverso i plugin della comunità si aggiungono Ray Serve, TorchServe e RedisAI. In tutti i casi la gestione dell'ambiente e delle dipendenze viaggia con il modello, che è il motivo per cui "funziona sul mio portatile" smette di essere una frase sensata.

Alternative a MLflow e confronto

Il mercato dell'experiment tracking si è consolidato parecchio negli ultimi diciotto mesi, e la consolidazione ha un costo per chi compra.

Il caso Neptune, e perché riguarda anche voi

Neptune.ai era una delle alternative più citate. Dopo l'acquisizione da parte di OpenAI, annunciata il 4 dicembre 2025, la piattaforma ospitata è stata spenta il 4 marzo 2026 e i dati residui cancellati. Chi la usava ha avuto tre mesi per migrare, con le istruzioni fornite da Neptune stessa verso MLflow e Weights & Biases.

La lezione non è "evitate i prodotti commerciali": è che la sostenibilità della piattaforma va valutata come una caratteristica tecnica. Un progetto sotto fondazione neutrale e self-hostabile non può essere spento da un'acquisizione. Un SaaS sì, per quanto buono sia.

Il confronto

Quando MLflow non è la scelta giusta

Va detto, perché una guida che consiglia sempre la stessa cosa non serve a niente:

• Siete una persona sola con due progetti l'anno. Un livello gratuito gestito vi risparmia un server da mantenere per niente.

• Il cuore del lavoro è la ricerca visuale. Se dovete confrontare centinaia di esecuzioni con dashboard elaborate e report condivisi con stakeholder non tecnici, l'interfaccia di Weights & Biases resta più avanti.

• Vi serve anche l'orchestrazione del calcolo. MLflow da solo non basta: dovrete affiancargli Airflow, Dagster, Prefect o Ray, mentre ClearML e Kubeflow coprono di più in un pezzo solo.

• Non avete nessuno che sappia amministrare un database. Self-hostare MLflow vi creerà un problema invece di risolverne uno: meglio il gestito, o meglio niente.

Strategie di crescita usando MLflow

La sequenza di adozione che funziona

L'errore più comune è partire dall'infrastruttura: si progetta il cluster, si discute lo schema del database, e dopo tre settimane nessuno ha ancora visto un beneficio. La sequenza che porta risultati è l'inversa — si parte dal valore percepito e si aggiunge struttura quando il dolore la giustifica.

1. Settimana 1. mlflow.autolog() nei notebook esistenti, tracking su SQLite locale. Zero infrastruttura, zero permessi da chiedere. Serve solo a far vedere la tabella delle esecuzioni a qualcuno che decide.

2. Settimane 2-3. Tracking server condiviso con PostgreSQL e object storage. Da qui in poi gli esperimenti smettono di essere personali.

3. Mese 2. Model Registry con alias: il deploy comincia a leggere @production invece di un percorso su disco.

4. Mese 2-3. CI che registra automaticamente il modello a ogni merge e blocca la promozione se una metrica peggiora.

5. Mese 3. Tracing sulle applicazioni LLM, se ce ne sono. È il punto in cui la piattaforma inizia a servire anche a chi non fa training.

6. Mese 4. Dataset di valutazione versionati e scorer automatici dentro pytest: la qualità diventa un test che fallisce, non un'opinione in riunione.

7. Mesi 5-6. RBAC, workspace separati, trace archival, monitoraggio dei costi via AI Gateway.

8. In continuo. Potatura: esperimenti morti archiviati, metriche inutili smesse di loggare, retention definita. Un tracking server non curato diventa rumore nel giro di un anno.

Per freelance e piccole strutture: dove sta il margine

Se lavorate a progetto, MLflow cambia due cose nel rapporto con il cliente. La prima è dimostrativa: consegnate insieme al modello la storia completa di come ci siete arrivati — quali alternative avete provato, con quali metriche, su quali dati. È materiale che giustifica una tariffa e che nessuno riesce a ricostruire a posteriori.

La seconda è contrattuale. Un tracking server multi-workspace, con RBAC e retention, è un servizio ricorrente vendibile a sé: "manutengo la piattaforma su cui girano i vostri modelli" è un canone, "vi ho consegnato un notebook" è una fattura una tantum. Con l'AI Act che dal 2027-2028 chiederà documentazione tecnica verificabile sui sistemi ad alto rischio, quella manutenzione ha un argomento di vendita che si scrive da solo.

Evaluation-driven development: il pattern da importare

La pratica che MLflow codifica meglio è questa: prima il dataset di valutazione, poi l'applicazione. Si definiscono i casi di test e i criteri di qualità, si versiona il dataset in modo immutabile, si scrive lo scorer, e solo dopo si comincia a modificare prompt e catene. Ogni modifica produce un numero confrontabile con quello di ieri.

È lo stesso spostamento mentale che il test-driven development ha portato nello sviluppo software vent'anni fa, applicato però a sistemi non deterministici. Senza, l'ottimizzazione di un agente LLM resta un'attività basata sull'impressione di chi l'ha guardato per ultimo.

Il monitoraggio dei costi come leva, non come report

Il tracciamento di token e costi per traccia, unito al routing dell'AI Gateway, permette una cosa molto concreta: scoprire quale passo della catena consuma il 70% del budget e spostarlo su un modello più piccolo, misurando prima quanto peggiora la qualità sullo stesso dataset di valutazione. Nella maggior parte delle applicazioni reali questa singola operazione taglia la spesa in modo significativo senza che l'utente se ne accorga. È il tipo di intervento che si ripaga nella prima settimana.

Tendenze future

Guardando la cadenza di rilascio degli ultimi dodici mesi, la direzione è leggibile.

Il baricentro si è spostato sugli agenti. Delle novità del 2026 — tracing multimodale, coding agent, MCP Registry, Review Queue, giudici multimodali, MLflow Assistant — quasi nessuna riguarda il training di modelli. MLflow continuerà a servire il ML classico, ma l'investimento va dove va il mercato. Chi lavora solo su modelli tabellari vedrà meno novità utili, e non è un male: quella parte del prodotto è matura e stabile.

L'osservabilità converge su OpenTelemetry. L'adesione alle GenAI Semantic Conventions non è una scelta tecnica qualsiasi: significa che le tracce di un'applicazione LLM finiranno negli stessi sistemi dove finiscono quelle dei microservizi, e che il confine fra "osservabilità ML" e osservabilità tout court si sta chiudendo. Nei prossimi due anni è ragionevole attendersi strumenti APM tradizionali capaci di leggere tracce MLflow senza adattatori.

La valutazione diventa un test automatico. L'integrazione con pytest, i dataset immutabili e gli scorer ensemble puntano tutti nella stessa direzione: qualità di un sistema GenAI valutata in CI, con una soglia che blocca il merge. È la trasformazione della valutazione da attività di ricerca a controllo di processo.

Il registro degli strumenti conterà quanto quello dei modelli. Con MCP diventato standard, la domanda "quale versione di quale strumento aveva l'agente quando ha dato quella risposta?" pesa quanto "quale versione del modello". L'MCP Registry è la prima risposta strutturata, ed è probabile che diventi una componente centrale come il Model Registry.

La conformità diventerà un caso d'uso dichiarato. Con le scadenze del dicembre 2027 e dell'agosto 2028 all'orizzonte, è ragionevole attendersi funzionalità esplicitamente orientate alla documentazione normativa: export di schede modello, report di valutazione firmati, retention allineate ai requisiti. Oggi si ottengono componendo pezzi; domani saranno probabilmente pulsanti.

Una previsione che invece non facciamo: che MLflow diventi un AutoML. Non c'è nessun segnale in quella direzione, e l'ecosistema ha già chi lo fa meglio.

Domande frequenti

MLflow è davvero una piattaforma AutoML?

No, e conviene saperlo prima di sceglierlo. MLflow non seleziona modelli né fa feature engineering automatico: registra, versiona e rende confrontabili i risultati prodotti da motori AutoML come Optuna, FLAML, AutoGluon, H2O o Databricks AutoML. È lo strato che rende verificabile l'automazione, non l'automazione stessa.

Quanto costa MLflow?

Il software è gratuito con licenza Apache 2.0. Costa l'esercizio: un'installazione self-hosted per un team piccolo — istanza di calcolo, PostgreSQL gestito, object storage — sta tipicamente sotto i 200 euro al mese, più il tempo di chi la mantiene. I servizi gestiti partono da circa 360 dollari al mese nel caso di Nebius, mentre Databricks e i cloud provider lo fatturano dentro il consumo della piattaforma. Databricks Free Edition include MLflow ospitato gratuitamente per uso personale e formativo.

MLflow regge i volumi dei big data?

Sì, a condizione di configurarlo correttamente: backend store su PostgreSQL e mai su filesystem, artefatti su object storage separato, trasferimenti diretti tramite URL pre-firmati per evitare che il server faccia da proxy sui file di grandi dimensioni, logging solo dal rank 0 nel training distribuito e trace archival attivo con volumi GenAI elevati. I limiti che si incontrano nella pratica sono quasi sempre di configurazione, non di architettura.

Che differenza c'è fra MLflow 2 e MLflow 3?

MLflow 3 introduce l'entità LoggedModel come cittadino di prima classe, con lineage completo fra modelli, esecuzioni, tracce, prompt e metriche di valutazione, più la suite di valutazione GenAI e il prompt registry con ottimizzazione automatica. Ci sono anche rotture: sono stati rimossi Recipes e i flavor fastai e mleap, e alcuni parametri API legacy sono deprecati. L'aggiornamento va provato in un ambiente separato prima della produzione.

Conviene self-hostare MLflow o usare un servizio gestito?

Dipende dalla dimensione del team. Sotto le tre persone un livello gratuito o gestito evita di mantenere un server. Fra cinque e venti persone il self-hosted vince quasi sempre sul costo, perché MLflow non si paga per postazione. Sopra questa soglia la variabile decisiva è la presenza di un team di piattaforma: se c'è, self-hosted su Kubernetes con l'Helm chart ufficiale; se non c'è, il gestito costa meno di un incidente.

MLflow serve anche per le applicazioni LLM e gli agenti?

Sì, ed è ormai l'area di sviluppo principale. Offre tracing compatibile con OpenTelemetry e con le GenAI Semantic Conventions, oltre 50 metriche di valutazione, giudici LLM anche multimodali, prompt registry, AI Gateway con routing e controllo dei costi e un MCP Registry per gli strumenti degli agenti. Il supporto al machine learning classico resta completo, ma è la parte matura del prodotto.

Che cosa è successo a Neptune.ai e perché riguarda chi sceglie oggi una piattaforma MLOps?

Neptune.ai è stata acquisita da OpenAI con annuncio del 4 dicembre 2025; l'applicazione ospitata e le API sono state spente il 4 marzo 2026 e i dati residui cancellati in modo irreversibile. Neptune ha indicato MLflow e Weights & Biases come percorsi di migrazione. Il caso mostra che la sostenibilità della piattaforma è un criterio di scelta tanto quanto le funzionalità: un progetto sotto fondazione neutrale e self-hostabile non può essere spento da un'acquisizione.

MLflow aiuta con gli obblighi dell'AI Act?

Aiuta a produrre i materiali che serviranno: tracciabilità degli esperimenti, documentazione di come un modello è stato addestrato e valutato, log conservati e lineage fra dati, codice e versione in produzione. Non è uno strumento di conformità e non basta da solo. Gli obblighi sui sistemi ad alto rischio sono stati rinviati al 2 dicembre 2027 per l'Allegato III e al 2 agosto 2028 per l'Allegato I, ma il lineage non si ricostruisce a posteriori: chi accende il tracking oggi arriverà a quelle scadenze con una storia documentata.

In sintesi

MLflow nel 2026 è due prodotti nello stesso server: un tracking di esperimenti maturo e noioso nel senso migliore del termine, e una piattaforma di osservabilità e valutazione per agenti LLM in evoluzione rapida. Il primo lo installate e lo dimenticate; il secondo va seguito, perché cambia ogni sei settimane.

Il motivo principale per sceglierlo non è tecnico. È che il costo non cresce con le persone, il formato dei modelli è portabile ovunque, le tracce parlano OpenTelemetry e il progetto non appartiene a nessuno che possa decidere di spegnerlo. In un mercato che ha appena visto sparire Neptune nel giro di tre mesi, è un argomento che pesa quanto una funzionalità — e per chi deve arrivare alle scadenze dell'AI Act con una storia documentata alle spalle, pesa anche di più.