In breve. MLflow è oggi il livello di controllo standard del ciclo di vita dei modelli: oltre 30 milioni di download al mese, più di 20.000 stelle su GitHub, 900 contributori e un progetto che vive sotto la Linux Foundation invece che dentro il listino di un singolo fornitore. La versione stabile di riferimento al momento in cui scriviamo è la 3.15.2, del 25 agosto 2026. Questa guida percorre la piattaforma per intero — che cosa fa davvero, come regge quando i dati diventano grandi, quanto costa esercirla, quali funzionalità avanzate esistono nel 2026, quali alternative ci sono e che cosa cambia con l'AI Act. Mettiamo subito in chiaro una cosa che 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 avanti — degli agenti LLM. La differenza non è terminologica: cambia che cosa vi aspettate dallo strumento e che cosa dovete comprare o costruire altrove.
Indice
1. Che cos'è MLflow e perché l'etichetta "AutoML" va chiarita
MLflow nasce nel 2018 dentro Databricks come risposta a 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. Il progetto è stato donato alla Linux Foundation nel 2020 e da allora la governance è aperta: chiunque può forkare, self-hostare, contribuire. Questo dettaglio di governance vale quanto una funzionalità, e più avanti vedremo perché.
I numeri, e quelli che non esistono
I dati pubblicati dal progetto: oltre 30 milioni di download mensili, più di 20.000 stelle su GitHub, oltre 900 contributori, integrazioni con più di 100 strumenti. Sulla homepage compaiono i loghi di 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 il numero di tracking server attivi. Quando leggete "la piattaforma MLOps più usata al mondo", state leggendo un'inferenza dai download, non una misurazione. È probabilmente vera, ma è un'inferenza.
AutoML sì, ma come strato di orchestrazione
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 run confrontabili, con parametri, metriche, artefatti e lineage. 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 frase corretta è: MLflow è la piattaforma su cui l'AutoML diventa verificabile. Se cercate un prodotto che, dato un CSV, vi restituisce un modello senza scrivere codice, MLflow non è quel prodotto e nessuna configurazione lo farà diventare tale.
Perché la governance 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'app ospitata e le API sono state spente e i dati residui cancellati in modo irreversibile. Neptune stessa ha pubblicato istruzioni di migrazione verso MLflow e Weights & Biases.
Chi aveva self-hostato ha avuto un problema di roadmap. 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" è una voce da mettere in tabella accanto alle funzionalità.
2. Le caratteristiche principali della piattaforma
MLflow nel 2026 è cresciuto ben oltre i quattro componenti originali (Tracking, Projects, Models, Registry). 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 mlflow.log_param, log_metric, log_artifact.
Il valore non è il logging in sé: è che l'interfaccia permette di ordinare 400 run per metrica, filtrarli per tag, confrontarne cinque affiancati e — dalla 3.15 — salvare e condividere una vista della tabella tramite URL, colonne, filtri e larghezze comprese. Sembra una piccolezza. In un team di sei persone è la differenza fra una discussione e uno screenshot.
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 alla run: il modello era un artefatto appeso a un'esecuzione. Adesso il modello ha identità propria e collega, in un unico grafo di lineage, le run che lo hanno prodotto, i checkpoint intermedi, i prompt usati, le tracce raccolte e le metriche di valutazione.
Per il deep learning questo risolve un fastidio concreto: un training da trenta ore produce decine di checkpoint, e prima della 3 non c'era un modo pulito per trattarli come entità confrontabili invece che come file dentro una cartella. Per gli agenti GenAI risolve un fastidio ancora più grosso: la stessa "versione dell'agente" viene interrogata mille volte, valutata in batch notturni e patchata con un prompt nuovo; senza un'entità che tenga insieme tutto questo, il lineage si spezza.
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 (@champion, @production, @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 arriva da 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 vendor. L'auto-tracing funziona con una riga per OpenAI, Anthropic, LangChain, DSPy, Vercel AI, PydanticAI, smolagents e molti altri. Per la produzione esistono 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, LLM-as-a-judge configurabili, 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 fanno la differenza 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 a uno solo.
Prompt Registry e ottimizzazione automatica
I prompt sono codice, ma vivono spesso come stringhe dentro un file. Il Prompt Registry li versiona, li collega alle valutazioni e — parte più interessante — li ottimizza automaticamente a partire dal feedback di valutazione e da dataset etichettati. È la stessa idea del tuning degli iperparametri, applicata al testo.
AI Gateway: una porta sola verso i provider LLM
L'AI Gateway 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, 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 .env di otto sviluppatori, e quando il fornitore alza i prezzi si cambia rotta in un file di configurazione invece che in venti repository.
3. Architettura distribuita: come regge quando i dati diventano grandi
"Piattaforma distribuita" nel caso di MLflow significa una cosa precisa, e conviene disambiguarla: 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: run ID, tempi, parametri, metriche, tag, tracce. Può essere il filesystem locale (solo per 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, file di modello. Di default è la cartella mlruns, ma in un'installazione seria è Amazon S3, Azure Blob Storage, Google Cloud Storage o HDFS.
Separare i due archivi è ciò che rende MLflow scalabile: i metadati sono piccoli e interrogati continuamente, 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.
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 in timeout. Dalla 3.15 esistono i trasferimenti senza proxy tramite URL pre-firmati: il client parla direttamente con S3, il server emette solo l'autorizzazione. È la singola modifica che più incide sulla capacità di reggere carichi di deep learning veri.
Spark, Ray e il training distribuito
Su Spark, MLflow si integra con il flavor mlflow.spark 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 il rank 0. Se tutti i worker scrivono sullo stesso run, 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 custom la responsabilità è 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".
4. I vantaggi competitivi: che cosa comprate davvero
Il costo che non pagate: nessuna licenza per postazione
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 seat: 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, spesso vince la piattaforma gestita.
Deep learning: checkpoint, non solo run finali
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 in tempo reale), la gestione dei checkpoint come entità di primo livello grazie a LoggedModel, e il supporto per artefatti pesanti e multimediali — dalla 3.x anche video. Se addestrate modelli che girano per giorni, il valore sta nel poter interrompere, confrontare, ripartire da un checkpoint preciso e dimostrare da dove veniva.
Portabilità: il formato è lo standard
Il formato MLflow Model — codice, dipendenze, firma di input/output, ambiente — è diventato una lingua franca. Lo stesso modello registrato una volta si serve con mlflow models serve in locale, si impacchetta in Docker con mlflow models build-docker, si distribuisce su Kubernetes, Amazon SageMaker, Azure ML, Databricks Model Serving, Modal, o su target comunitari come Ray Serve, TorchServe e RedisAI tramite 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 il riconoscimento delle emozioni e la categorizzazione biometrica, dichiarare l'origine artificiale dei deepfake) e i 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. Sono esattamente gli artefatti che un tracking server produce come effetto collaterale del lavoro quotidiano — a patto che lo abbiate acceso prima, perché il lineage non si ricostruisce a posteriori. Chi comincia a tracciare oggi arriva al 2027 con due anni di storia; chi comincia nel 2027 arriva con niente.
Nota: questo è un riepilogo tecnico, non un parere legale. Per la qualificazione del vostro specifico sistema conviene un consulente.
5. Costi: il software è gratuito, l'esercizio no
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: un'istanza di calcolo modesta, un database PostgreSQL gestito, un bucket di object storage. Gli ordini di grandezza, su un cloud pubblico e con listini che vanno sempre verificati al momento dell'acquisto, sono questi:
Calcolo (istanza 2 vCPU / 8 GB, sufficiente fino a qualche decina di utenti): poche decine di euro al mese;
Database gestito (PostgreSQL piccolo, con backup): grandezza analoga, spesso superiore al calcolo;
Object storage: qualche centesimo per GB al mese, più il traffico in uscita — la voce che sorprende chi scarica spesso checkpoint grossi.
Un'installazione di questo tipo sta ampiamente sotto i 200 euro al mese. È 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 $/ora, cioè circa 350 $ al mese di calcolo continuo, più circa 14,20 $ al mese per i 200 GiB di disco SSD inclusi — intorno ai 364 $ mensili, senza contare l'object storage separato.
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 tier gratuito. AWS, Azure e Google espongono MLflow 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 minor version? Chi gestisce le migrazioni dello schema del database? Chi risponde quando un data scientist dice che la UI è lenta perché il database ha 40 milioni di righe di metriche? In un'organizzazione strutturata è mezza giornata al mese di un ingegnere di piattaforma; nelle prime settimane è molto 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
Scenario | Soluzione consigliata | Costo indicativo mensile | Perché |
|---|---|---|---|
Freelance, 1 persona, progetti sporadici | MLflow locale (SQLite + cartella) o tier gratuito ospitato | 0 € | Nessun bisogno di concorrenza né di accessi condivisi |
Team 2-5 persone, un cliente principale | Self-hosted su VM + PostgreSQL gestito + S3 | 100-200 € | Il costo per persona crolla subito sotto qualsiasi licenza |
Team 5-20 persone, più progetti, requisiti di audit | Self-hosted su Kubernetes con Helm chart ufficiale, RBAC attivo | 300-800 € + presidio | Servono isolamento fra workspace, ruoli, archiviazione tracce |
Azienda già su Databricks o su un cloud unico | MLflow gestito dal provider | Integrato nel consumo | Nessun server da presidiare, identità e permessi già risolti |
Volumi GenAI alti (milioni di tracce) | Self-hosted + trace archival su object storage | Variabile, dominato dallo storage | Il database va tenuto piccolo, le tracce vecchie su storage economico |
6. 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. Esiste 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 (3.13) sposta automaticamente le tracce più vecchie dal database verso object storage economico, mantenendole leggibili nell'interfaccia. Si configura in YAML con destinazione, policy di retention e intervallo di esecuzione. È la differenza fra un sistema che si mantiene e uno che va potato 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 gli agenti possono 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 MCP divergenti in sette repository.
MLflow 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 esiste 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.
Le integrazioni: oltre 100 strumenti, quattro 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.
Deployment: dove finisce il modello
Le destinazioni supportate ufficialmente: server locale con mlflow models serve, container Docker, Kubernetes, Amazon SageMaker, Azure ML (endpoint gestiti, ACI, AKS), Databricks Model Serving, Modal per il serverless con GPU on-demand. Via plugin della comunità: Ray Serve, TorchServe, 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.
7. Alternative a MLflow e confronto
Il mercato dell'experiment tracking si è consolidato parecchio, e la consolidazione ha un costo per chi compra.
La tabella
Piattaforma | Modello | Prezzo indicativo | Punto di forza | Quando sceglierla |
|---|---|---|---|---|
MLflow | Open source (Linux Foundation) + gestito da terzi | Gratuito, costi d'infrastruttura | Copertura ML + GenAI, nessun lock-in, standard di fatto | Team che vogliono controllo, o che crescono oltre le 3-4 persone |
Weights & Biases | SaaS commerciale | Free (5 postazioni, 5 GB); Pro da 60 $/mese; Enterprise a preventivo | Interfaccia e visualizzazioni superiori, collaborazione | Ricerca e deep learning con forte componente visuale |
Comet / Opik | SaaS + open source (Opik) | MLOps Pro 19 $/utente/mese; Opik Pro 19 $/mese (100k span); gratis per l'accademia | Buon rapporto prezzo/funzioni, Opik open source per l'osservabilità LLM | Team piccoli con budget definito, contesti accademici |
ClearML | Open source + tier commerciali | Tier gratuito, piani a pagamento da poche decine di dollari | Orchestrazione e gestione code/agenti oltre al tracking | Chi vuole anche schedulare il calcolo, non solo tracciarlo |
Kubeflow | Open source, nativo Kubernetes | Gratuito, costo operativo alto | Pipeline complete su Kubernetes | Organizzazioni con un team di piattaforma già dedicato |
SageMaker / Vertex AI / Azure ML | PaaS del cloud provider | A consumo, integrato nel conto cloud | Integrazione con identità, rete e sicurezza del cloud | Chi è già tutto dentro un solo cloud e non vuole uscirne |
Chiusa | — | — | Piattaforma dismessa il 4 marzo 2026 dopo l'acquisizione da parte di OpenAI |
Quando MLflow non è la scelta giusta
Va detto con onestà, perché la guida non serve a vendere niente:
Se siete una persona sola con due progetti l'anno, un tier gratuito gestito vi risparmia un server da mantenere.
Se il cuore del lavoro è la ricerca visuale — confronto di centinaia di run con dashboard elaborate, report condivisi con stakeholder — l'interfaccia di Weights & Biases resta più avanti.
Se 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.
Se non avete nessuno che sappia amministrare un database, self-hostare MLflow vi creerà un problema al posto di risolverne uno.
8. Strategie di crescita usando MLflow
Qui parliamo di come si costruisce valore attorno alla piattaforma, non di come si installa un pacchetto.
La sequenza di adozione che funziona
L'errore più comune è partire dall'infrastruttura. La sequenza che porta risultati è l'inversa: si parte dal valore percepito e si aggiunge struttura quando il dolore la giustifica.
Settimana 1 —
mlflow.autolog()nei notebook esistenti, tracking su SQLite locale. Zero infrastruttura, zero permessi da chiedere. Serve a far vedere la tabella dei run a qualcuno che decide.Settimana 2-3 — tracking server condiviso con PostgreSQL e S3. Da qui in poi gli esperimenti smettono di essere personali.
Mese 2 — Model Registry con alias. Il deploy comincia a leggere
@productioninvece di un percorso su disco.Mese 2-3 — CI che registra automaticamente il modello a ogni merge e blocca la promozione se una metrica peggiora.
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.
Mese 4 — dataset di valutazione versionati e scorer automatici in
pytest. La qualità diventa un test che fallisce, non un'opinione in riunione.Mese 5-6 — RBAC, workspace separati, trace archival, monitoraggio dei costi via AI Gateway.
In continuo — potatura: esperimenti morti archiviati, metriche inutili smesse di loggare, retention definita. Un tracking server non curato diventa rumore in 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 che vale la pena 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 a sistemi non deterministici. Senza, l'ottimizzazione di un agente LLM è un'attività basata sull'impressione di chi l'ha guardato per ultimo.
Il monitoraggio dei costi come leva, non come report
Il tracking di token e costi per traccia, unito al routing dell'AI Gateway, permette una cosa concreta: scoprire quale passo della catena consuma il 70% del budget e spostarlo su un modello più piccolo, misurando prima quanto peggiora la qualità con lo 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 paga da solo nella prima settimana.
9. Tendenze future: dove sta andando la piattaforma
Guardando la cadenza di rilascio degli ultimi dodici mesi, la direzione è leggibile.
Il baricentro si è spostato sugli agenti. Delle novità 2026 — multimodal tracing, 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 fa solo modelli tabellari vedrà meno novità utili, e non è un male: quella parte è matura.
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 ci aspettiamo strumenti APM tradizionali che leggono 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: la 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 conta 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; ci aspettiamo che diventi una componente centrale come il Model Registry.
La conformità diventerà un caso d'uso dichiarato. Con le scadenze AI Act 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 non facciamo: che MLflow diventi un AutoML. Non c'è nessun segnale in quella direzione, e l'ecosistema ha già chi lo fa meglio.
10. 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 (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 (mai su filesystem), artefatti su object storage separato, trasferimenti diretti tramite URL pre-firmati per evitare che il server faccia da proxy sui file grossi, logging solo dal rank 0 nel training distribuito e trace archival attivo se generate molte tracce GenAI. 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, run, 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 da quante persone siete e da chi avete. Sotto le tre persone, un tier gratuito o gestito evita di mantenere un server per niente. Fra cinque e venti persone il self-hosted vince quasi sempre sul costo, perché MLflow non si paga per postazione. Sopra, la variabile decisiva diventa se avete già un team di piattaforma: se sì, self-hosted su Kubernetes con l'Helm chart ufficiale; se no, il gestito costa meno di un incidente.
MLflow serve anche per le applicazioni LLM e gli agenti?
Serve soprattutto per quelle, ormai. Tracing compatibile con OpenTelemetry, oltre 50 metriche di valutazione, giudici LLM anche multimodali, prompt registry, AI Gateway con routing e controllo dei costi, MCP Registry per gli strumenti degli agenti: la maggior parte degli sviluppi del 2026 riguarda il mondo GenAI. Il supporto al ML 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, 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 una 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, lineage fra dati, codice e versione in produzione. Non è uno strumento di conformità e non basta da solo. Vale però un'osservazione pratica: gli obblighi sui sistemi ad alto rischio sono stati rinviati al 2 dicembre 2027 (Allegato III) e al 2 agosto 2028 (Allegato I), ma il lineage non si ricostruisce a posteriori — chi accende il tracking oggi arriverà a quelle scadenze con una storia, chi lo accende allora arriverà con un foglio bianco.
In sintesi
MLflow nel 2026 è due prodotti nello stesso server: un tracking di esperimenti maturo e noioso nel senso buono, 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. Nel mercato che ha appena visto sparire Neptune in tre mesi, è un argomento che pesa quanto una funzionalità.