Prevedere le timeseries non è mai stato così semplice

AI predittiva

In industria il caso d’uso più diffuso è prevedere il comportamento futuro di qualcosa in base a quello che è successo nel passato: la curva di consumo in base alla produzione, il volume di materia prima necessaria, la potenza di picco, il comportamento vibrazionale in base al setpoint… La lista può diventare da sola un articolo a parte.

Per prevedere il futuro basandosi sulle serie temporali si utilizzano metodologie di forecasting, varie e specifiche per ogni tipologia di serie temporale.

Fino al 2023, pur essendo un approccio estremamente diffuso, ogni modello predittivo veniva addestrato from scratch – da capo – a partire dai dati disponibili. Questo significava che per ogni nuovo caso d’uso serviva un modello diverso, studiato ad hoc.

Modelli fondazionali per il timeseries forecasting

Ispirati dalla rivoluzione dei modelli fondazionali per il natural language processing , i team di ricerca hanno iniziato ad esplorare la fattibilità di modelli pre addestrati per prevedere il futuro.

Dal 2023 in due ondate successive si è quindi cominciato a rilasciare modelli fondazionali per le timeseries – ovvero modelli preaddestrati in grado di fare previsione multivariata senza essere addestrati da zero.

Dati

Come tutti i modelli fondazionali, anche questi sono allenati con volumi importanti di dati – in questo caso timeseries – di vario tipo. Il volume di dati dipende dal modello e non sempre è dichiarato, e gli ordini di grandezza, dove ci sono, vanno dalle decine di miliardi a oltre mille miliardi di punti temporali:

• Moirai (Salesforce): LOTSA, un archivio aperto con oltre 27 miliardi di osservazioni in nove domini.
• Toto (Datadog): un trilione, cioè mille miliardi, di punti nel primo rapporto tecnico, il 75% dei quali metriche anonime della piattaforma Datadog. Nel paper del 2025 il corpus è un mix di dati di osservabilità, dataset aperti e dati sintetici.
• Sundial (THUML): TimeBench, mille miliardi di punti, per lo più dati reali e sintetici.
• TimesFM-3 (Google): secondo una fonte secondaria oltre mille miliardi di punti. La model card elenca le componenti: il set di pre-addestramento di GIFT-Eval, visualizzazioni di pagine Wikimedia, query di Google Trends e dati sintetici.
• Timestral (Mistral): il volume non è dichiarato. Si sa che la maggior parte dei dati è sintetica e che il dettaglio arriverà con il rapporto tecnico.

I numeri non sono confrontabili tra loro, perché ogni caso conta i punti dato in modo diverso, ma moltissimi utilizzano un mix di dati reali e sintetici per garantire performance confrontabili in contesti differenti. I dati sintetici servono infatti a coprire comportamenti (trend, stagionalità, rumore, dipendenze tra variabili) che nei dati reali pubblici sono rari o mal rappresentati. Timestral, ad esempio, viene prima addestrato solo su dati sintetici e poi rifinito su un mix di reali e sintetici.

L’architettura del modello

Le architetture sono diverse, ma quasi tutte seguono la stessa ricetta di base: la serie viene tagliata in blocchi (patch) di passi consecutivi – un blocco diventa l’equivalente di una parola per il modello – e l’output è una distribuzione o un insieme di quantili, per rappresentare l’incertezza della previsione.

L’ultimo arrivato dei modelli fondazionali – la famiglia Timestral di Mistral – conta 209M di parametri ed è un transformer a patch con 24 livelli. Legge blocchi da 32 passi, insieme agli indicatori dei valori mancanti, e applica l’attenzione sia lungo il tempo sia tra le variabili. Mistral dichiara che l’architettura che ha scelto si differenzia per due aspetti diversi:

• Decoupled Horizon Forecasting (orizzonte di previsione disaccoppiato). Alcuni modelli recenti, durante l’addestramento, nascondono una parte della serie per farla indovinare. Timestral invece tiene la serie intera e aggiunge dei token di previsione: segnaposto appresi che leggono solo la storia che li precede e producono la previsione. Così ogni valore osservato serve sia come risposta da indovinare sia come informazione per le previsioni successive. I buchi veri nei dati restano riconoscibili come mancanti, perché non si confondono con i valori nascosti per l’addestramento.
• Attenzione consapevole delle covariate. Ogni serie in ingresso riceve un ruolo: variabile da prevedere, covariata nota solo fino a oggi (ad esempio la temperatura misurata) o covariata nota anche per il futuro (il calendario dei turni, le previsioni meteo). L’informazione passa solo dalle covariate verso la variabile da prevedere, mai al contrario. Il modello può quindi usare ciò che sa del futuro, come il piano di produzione, senza “sbirciare” il futuro della variabile che deve prevedere: sarebbe una copiatura, non una previsione.

Gli altri, a confronto.

Modello	Architettura	Come tratta più variabili	Uscita
Timestral (Mistral)	transformer a patch da 32 passi, token di previsione appresi	attenzione sul tempo e tra variabili, con ruoli per le covariate	21 quantili
TimesFM-3 (Google)	transformer “mixing” a 20 livelli, patch di contesto da 32 e di previsione da 64	attenzione tra variabili	quantili
Moirai (Salesforce)	encoder mascherato, patch di dimensione diversa a seconda della frequenza	la serie multivariata viene appiattita in un’unica sequenza	miscela di distribuzioni
Chronos (Amazon)	trasforma i valori in token di un vocabolario finito (4096) e usa un T5 encoder-decoder	la versione originale è univariata	distribuzione sui token
TiRex (NXAI)	rete ricorrente xLSTM invece dell’attenzione, con mascheramento di patch contigue in addestramento	TiRex-2 tratta anche più serie insieme	quantili
Sundial (THUML)	transformer con una funzione di perdita generativa (flow-matching), senza tokenizzazione	non indicato nelle fonti consultate	più previsioni possibili, campionate

Tra la prima e la seconda ondata cambia soprattutto il trattamento delle variabili. Una classificazione dei modelli di previsione mette Chronos-2, Moirai e Toto tra i modelli con attenzione sia sul tempo sia tra le variabili, mentre Chronos originale, TimesFM e Lag-Llama hanno solo l’attenzione sul tempo e TiRex è tra i pochi ricorrenti.

In un contesto in cui la correlazione tra variabili è tanto importante quanto la correlazione nel tempo – come per esempio in industria -, avere sistemi in grado di comprendere la modalità con cui sia il tempo sia l’interazione multivariata influenzano la previsione è estremamente importante.

Modelli piccoli e portabili

Rispetto ai modelli linguistici, che hanno miliardi di parametri, questi sono decisamente più piccoli. Per esempio:

• Timestral: da 5 a 209 milioni.
• TiRex: 35 milioni nella prima versione; TiRex-2 ha 82,5 milioni, di cui 38,4 attivi sulle serie singole (fonte secondaria).
• Chronos-2: 120 milioni, con una taglia da 28 milioni.
• TimesFM: 200 milioni la versione 2.5, 330 milioni la 3.
• t0-alpha: 102 milioni.
• Toto: 151 milioni nella prima versione aperta; Toto 2.0 va da 4 milioni a 2,5 miliardi.
• Lag-Llama: circa 2,5 milioni (scheda di terzi).

Modelli piccoli significa poche risorse necessarie per farli funzionare. Quindi, praticamente tutti possono girare su server con CPU, non per forza con cluster di GPU. Tempistiche e performance rispecchiano questa flessibilità:

• Per Timestral, Mistral dichiara 10 millisecondi (modello da 5M) e 140 millisecondi (209M) per una previsione a un giorno da tre settimane di storico a 15 minuti, su un server a 8 thread.
• Per TiRex-2 esiste un’immagine Docker per CPU, e Toto 2.0 ha la taglia da 4M pensata per l’edge, sempre secondo la fonte secondaria.
• Sundial dichiara previsioni in pochi millisecondi.
• La community ha portato TiRex, Chronos-2 e TimesFM 2.5 a girare direttamente nel browser, con file da circa 140 MB (TimesFM richiede circa 1 GB al primo uso).

Inferenza

Come per i modelli fondazionali di NLP, anche in questo caso i modelli pre addestrati possono essere utilizzati out of the box per fare previsione in base ai propri dati, senza un addestramento specifico di dominio.

Ovviamente non sempre la previsione su dati nuovi mai visti dal modello (quella chiamata zero-shot) funziona con performance sufficienti: se i dati sono particolarmente complessi o molto lontani dalla base dati dell’addestramento, potrebbe servire un affinamento del modello.

E come per i LLM, anche in questi casi è possibile fare fine tuning, ovvero rifinire il modello sui propri dati partendo dai pesi già addestrati. Le metodologie di fine tuning dipendono dall’accessibilità del modello stesso:

• Timestral: passa da Mistral Forge, la stessa pipeline di addestramento dei modelli linguistici di Mistral. Permette fine-tuning su dati proprietari, covariate specifiche del dominio e controllo sul mix di addestramento, anche con dati sintetici generati per il proprio settore. Può girare nell’infrastruttura del cliente, compresi ambienti isolati dalla rete. Sia il modello sia la pipeline sono prodotti commerciali, il modllo prevede uso libero fino ad un tetto di fatturato, e per la licenza il tetto di fatturato vale anche per i modelli derivati.
• Modelli con pesi aperti: il fine-tuning è documentato, ad esempio nel repository di TiRex, che ha una sezione dedicata. Lag-Llama è nato con questa idea: gli autori riportano che rifinito su piccole porzioni di dati nuovi supera gli approcci di deep learning precedenti.

Un buon compromesso è partire sempre da zero-shot, misurare l’errore sui propri dati e procedere con iterazioni successive di fine tuning via via più importante in base allo storico disponibile e alla performance necessaria. Se per le previsioni zero-shot non serve particolare storico, per il fine-tuning lo storico ritorna al centro della discussione: con poche settimane di dati il rischio è adattare il modello al rumore invece che al comportamento della macchina.

I modelli disponibili

Di modelli ce ne sono per ogni preferenza, con licenza commerciale, open weights o open source. Nella tabella di seguito una lista non esaustiva dei principali modelli disponibili ad ottobre 2026.

Modello (chi, paese)	Paper	Parametri	Esecuzione	Pesi e licenza
TimeGPT (Nixtla, USA)	Garza et al.	non dichiarati	API ospitata	commerciale, a pagamento via API
Lag-Llama (Mila e altri, Canada)	arXiv 2310.08278	circa 2,5M	leggero, CPU	Apache 2.0
TimesFM 2.5 e 3 (Google, USA)	arXiv 2310.10688	200M (2.5), 330M (3)	CPU e GPU	2.5: Apache 2.0. 3: solo non commerciale
Chronos-Bolt e Chronos-2 (Amazon, USA)	Chronos, Chronos-2	Chronos-2: 120M (anche 28M)	CPU e GPU	Apache 2.0
Moirai, Moirai-MoE, Moirai 2.0 (Salesforce, USA)	arXiv 2402.02592	non indicati nelle fonti consultate	CPU e GPU	CC-BY-NC-4.0, non commerciale
TiRex e TiRex-2 (NXAI, Austria)	TiRex, TiRex-2	35M (TiRex), 82,5M (TiRex-2)	CPU (Docker) e GPU	TiRex: licenza NXAI Community. TiRex-2: Apache 2.0
Toto e Toto 2.0 (Datadog, USA)	arXiv 2505.14766	151M (Toto), da 4M a 2,5 miliardi (2.0)	CPU e GPU; 4M pensato per l’edge	Apache 2.0
Sundial (THUML, Cina)	arXiv 2502.00816	128M (base)	previsioni in pochi millisecondi	Apache 2.0
t0-alpha e t0-gamma (The Forecasting Company, Francia)	rapporto citato da fonti terze, link non trovato	102M (alpha)	CPU e GPU	Apache 2.0; t0-gamma richiede di accettare i termini su Hugging Face
Timestral (Mistral, Francia)	rapporto tecnico annunciato, non ancora uscito	da 5M a 209M	CPU (10-140 ms dichiarati) o GPU	pesi scaricabili, Modified MIT con tetto di 20 milioni di dollari di fatturato mensile

Le colonne sull’esecuzione e sulla licenza riportano solo quanto dichiarato dai fornitori o trovato nelle schede dei modelli (Hugging Face, GitHub). Dove la scheda non lo dice, la voce è generica. Le licenze vanno sempre verificate sulla scheda del checkpoint che si intende usare.

Chi fa meglio?

In base ai risultati sui benchmark pubblicati da Mistral sulla pagina ufficiale di Timestral, Mistral dichiara il primo posto su tre classifiche pubbliche. Ma anche Google aveva dichiarato il primo posto sugli stessi tre benchmark con TimesFM-3, a fine agosto: come sempre nel settore dell’AI, la gloria sfiorisce in fretta.

I benchmark per valutare la performance sulla previsione di rimeseries sono principalmente tre:

• GIFT-Eval (Salesforce, 2024): oltre 140.000 serie temporali in sette domini e dieci frequenze, con previsioni brevi e lunghe, univariate e multivariate. Include un insieme di pre-addestramento senza sovrapposizioni con il test, di circa 230 miliardi di punti.
• TIME: introdotto da un paper di febbraio 2026, con classifica su Hugging Face.
• fev-bench: del 2025, ospitato dal team AutoGluon, lo stesso ecosistema di Chronos.

Le metriche sono sostanzialmente due. MASE misura l’errore sul valore centrale rispetto a un previsore di riferimento semplice: più basso è meglio, e sotto 1 si batte il riferimento.

CRPS (o la variante SQL nel fev-bench) misura la qualità dell’intera distribuzione prevista, quindi anche dell’incertezza.

Perché interessa all’industria

Uno stabilimento è un luogo pieno di serie temporali: temperature, pressioni, vibrazioni, consumi, stati macchina. Prevederle serve a pianificare manutenzione, scorte di ricambi ed energia. Lo scenario che Mistral stessa descrive si basa su cinque scenari, utili ciascuno a un ruolo diverso.

1. Variabili correlate tra loro (manutenzione, processo). Vibrazione, temperatura e pressione di una pompa non variano in modo indipendente, per prevedere correttamente l’aumento di pressione è necessario correlarlo con le altre variabili – come sempre.
2. Previsione con incertezza (responsabile di produzione, manutenzione). Al posto di un valore unico, il modello restituisce 21 quantili. Si possono fissare soglie di allerta che tengono conto di quanto la previsione è incerta e pianificare gli interventi sul rischio invece che su un singolo valore puntuale.
3. Covariate note nel futuro (produzione, energy manager). Piano di produzione, fermi programmati, previsioni meteo: se il carico sale perché è in calendario, il modello lo mette in conto e il picco non viene letto come anomalia. Per l’efficienza energetica, ad esempio, significa poter prevedere i consumi insieme al piano di lavoro. Questo significa poter usare i piani e le previsioni come input per valutazioni più precise.
4. Covariate categoriche. Giorno della settimana o stato della macchina (in produzione, ferma, in manutenzione, magari come input dallo scheduler) entrano come categorie, senza forzarle in una scala numerica che non hanno.
5. Poco storico, nessuna GPU. Essendo possibile utilizzare ogni modello in zero-shot, si può provare anche dove i dati accumulati sono pochi, e su una CPU di un server già presente in azienda.

Prevedere il futuro con pochi dati

Grazie ai modelli fondazionali per le timeseries si supera la barriera all’ingresso più grande nelle industrie, soprattutto per chi non ha molti dati perchè magari ha installato il MES da poco tempo: già dalle prime settimane si possono fare previsioni, senza attendere un volume importante. Poi c’è sempre tempo per affinare con nuovi dati sufficientemente rappresentativi

Essendo modelli piccoli e spesso open-weights, questi modelli si possono installare su un server già presente in stabilimento. I dati di impianto non escono dall’azienda e non serve né un datacenter né un contratto cloud.