Il 31 agosto 2026 Google Research ha pubblicato TimesFM-3, la terza generazione del suo modello fondazionale per le serie storiche. Detta in modo brutale: è un modello che guarda i numeri della vostra azienda — vendite per referenza, consumi di energia, chiamate al call center, traffico su un sito — e produce la previsione dei prossimi giorni o mesi senza essere mai stato addestrato su quei dati. Nessun training, nessuna calibrazione, nessun data scientist che passa tre settimane a scegliere gli iperparametri.
È la stessa idea che ha reso utili i modelli linguistici, applicata a un problema molto più noioso e molto più redditizio: prevedere la domanda. E come per gli LLM, la parte interessante non è la demo, è il conto economico che ci sta sotto.
Il problema che TimesFM prova a togliere di mezzo
Nella pratica aziendale il forecasting funziona quasi sempre così: si prende una libreria statistica — ARIMA, ETS, Prophet — e si costruisce un modello per ogni serie. Un'azienda con 40.000 referenze in 300 punti vendita non ha una previsione: ne ha milioni. Ognuna con la sua stagionalità, i suoi outlier, il suo storico bucato, il suo ricalcolo notturno.
Quel modello va scelto, tarato, monitorato e ritarato quando la serie cambia comportamento. Il costo non è la CPU: è il tempo delle persone e la manutenzione perpetua. È il motivo per cui in moltissime aziende il forecast "ufficiale" è ancora una media mobile corretta a mano da chi conosce il mercato.
L'approccio foundation model ribalta l'impostazione. Un unico modello viene pre-addestrato una volta sola su una quantità enorme di serie storiche eterogenee — TimesFM-3 su oltre mille miliardi di punti temporali, reali e sintetici — e impara le regolarità generiche del tempo: trend, stagionalità multiple, picchi, ritorni alla media. Poi, davanti a una serie che non ha mai visto, produce la previsione al primo colpo. In gergo, zero-shot.
Non è una promessa teorica: nei confronti su dataset eterogenei i modelli fondazionali battono regolarmente le baseline statistiche non tarate, con miglioramenti dell'ordine del 15% di errore medio su dataset di vendite a bassa frequenza. Il vantaggio non è solo l'accuratezza — è che quell'accuratezza arriva senza il lavoro di taratura.
Cosa cambia nella versione 3
TimesFM esisteva già: la 1.0 è del 2024, la 2.5 di settembre 2025 aveva ridotto i parametri a 200 milioni e allungato il contesto a 16.000 punti. La 3.0 introduce quattro cose che contano davvero.
Multivariato nativo
Fino alla 2.5, il modello prevedeva una serie alla volta. Se le vendite del prodotto A e del prodotto B si muovono insieme — cannibalizzazione, effetto sostituzione, stessa promozione — quell'informazione andava persa o ricostruita a mano fuori dal modello.
TimesFM-3 è il primo della famiglia addestrato nativamente sul multivariato: prevede più serie che coevolvono contemporaneamente, catturando le dipendenze fra loro. Architetturalmente lo fa alternando due tipi di attenzione — una causale sul tempo (guarda il passato di ogni serie) e una piena fra le variate (guarda tutte le serie nello stesso istante). Il modello vede la matrice, non la riga.
Covariate, incluse quelle che conoscete già
Il modello distingue tre ruoli semantici: i target da prevedere, le covariate solo-passate e le covariate passato-e-futuro. Quest'ultima categoria è quella che in azienda fa la differenza: il calendario delle promozioni, il listino prezzi già deciso, le festività, le previsioni meteo, il piano media. Sono cose che si sanno in anticipo, e un forecast che le ignora parte handicappato.
Per gestirle TimesFM-3 usa una strategia di lookahead: ogni blocco temporale viene concatenato ai blocchi futuri della covariata, in modo che il modello possa "sbirciare" i segnali noti in avanti. Nella 2.5 le covariate si potevano aggiungere solo con una regressione esterna appiccicata sopra; qui sono parte del modello.
Decodifica in un colpo solo
I predecessori generavano la previsione autoregressivamente: un pezzo alla volta, riusando l'output come input. Preciso, ma lento e soggetto ad accumulo dell'errore sugli orizzonti lunghi.
TimesFM-3 genera l'intero orizzonte in un singolo passaggio in avanti, aggiungendo in coda al contesto dei segnaposto mascherati che il modello riempie tutti insieme. Meno latenza, meno deriva, e — dettaglio non banale per chi deve girare migliaia di serie ogni notte — un costo di inferenza prevedibile.
Le dimensioni
330 milioni di parametri: 20 livelli, dimensione 1280, 16 teste di attenzione, blocchi da 32 passi in ingresso e 64 in uscita. Contesto fino a 16.000 punti, orizzonte fino a 1.000 passi, e per ogni passo nove quantili (dal 10° al 90° percentile) oltre alla previsione puntuale.
Per capirsi: è un modello più piccolo di quasi tutti gli LLM che girano oggi su un laptop. Non serve un cluster.
I numeri, e quanto fidarsi
Google dichiara il primo posto su tutti e tre i benchmark di riferimento del settore:
- GIFT-Eval — 23 dataset, oltre 144.000 serie e 177 milioni di punti su sette domini applicativi e dieci frequenze di campionamento, per 97 task complessivi. TimesFM-3 è primo fra tutti i modelli fondazionali.
- fev-bench — primo assoluto su 100 task di previsione reali.
- TIME — primo assoluto su 50 dataset di dominio e 98 task di valutazione.
Il dato più solido è che il primato vale sia sulle metriche puntuali sia su quelle probabilistiche: il modello non azzecca solo il numero centrale, ma anche la forma dell'incertezza attorno.
Una dose di scetticismo però è d'obbligo, per due motivi. Il primo è che i benchmark li ha scelti e girati chi ha costruito il modello, e verifiche indipendenti su questa versione ancora non ce ne sono. Il secondo è che il campo si muove a una velocità che rende le classifiche deperibili: Chronos-2 di Amazon (fino a 710 milioni di parametri, integrato in SageMaker e AutoGluon), Moirai-2 di Salesforce e TiRex stanno tutti nella stessa fascia, e in alcuni confronti pubblicati poche settimane fa erano loro in testa. Il vantaggio dichiarato da TimesFM-3 è reale ma non è un abisso.
I vantaggi concreti, in ordine di quanto pesano
1. Sparisce il ciclo di training e taratura. È il vantaggio economico principale, e non riguarda l'accuratezza: riguarda le persone. Non serve un modello per SKU, non serve rifare il tuning ogni trimestre, non serve un team ML per andare in produzione. Serve una pipeline di dati pulita.
2. Le dipendenze fra serie diventano gratuite. Prevedere insieme prodotti correlati, negozi della stessa area o linee di produzione dello stesso stabilimento è esattamente il caso in cui un modello univariato lascia soldi sul tavolo.
3. Quello che sapete già entra nella previsione. Le covariate passato-e-futuro sono il modo per far sapere al modello che la settimana prossima c'è il Black Friday, o che il prezzo è già stato tagliato del 20%. Nei sistemi classici questa è la parte che si finisce sempre per correggere a mano.
4. L'incertezza arriva inclusa nel prezzo. I nove quantili non sono un vezzo statistico: sono ciò che permette di dimensionare le scorte di sicurezza, la capacità produttiva o i turni sulla base di un rischio dichiarato invece che di un numero secco. Un forecast puntuale senza intervallo è, in pratica, inutilizzabile per decidere.
5. Una sola pipeline per tutto. Un modello, un endpoint, un formato di input. Chi ha gestito una flotta di migliaia di modelli statistici sa quanto valga.
6. Gira su hardware normale. 330 milioni di parametri stanno comodamente su una singola GPU, e girano anche su CPU accettando una latenza più alta.
Cosa serve davvero per usarlo
Qui la lista è più corta di quanto ci si aspetti, ma ogni voce va presa sul serio.
I dati
È il vero requisito. Serve uno storico regolare e allineato: stessa frequenza di campionamento, buchi gestiti esplicitamente, timestamp coerenti. Il modello tollera contesti di lunghezze diverse — si possono passare serie da 72 e da 100 punti nello stesso batch — ma non inventa segnale dove non c'è: su una serie con sei mesi di storia e un cambio di codice prodotto a metà, nessun modello fondazionale fa miracoli.
Se si vogliono usare le covariate note nel futuro, va costruito il pezzo più fastidioso: il calendario del futuro. Promozioni, listini, festività, chiusure, campagne — allineati passo per passo sull'orizzonte di previsione. È lavoro di data engineering, non di machine learning, ed è dove si spende il tempo vero.
Il software
Il pacchetto si installa da PyPI con pip install timesfm[torch]; il checkpoint è su Hugging Face come google/timesfm-3.0-pytorch. Si istanzia un TimesFM3Evaluator indicando il percorso del checkpoint, la dimensione del batch per core e il dispositivo, poi si chiama la previsione passando gli array NumPy: monodimensionali per l'univariato, bidimensionali (numero_variate, lunghezza_contesto) per il multivariato, più gli array delle covariate. Si specifica l'orizzonte, si chiede o meno il ritorno dei quantili, e si ottengono previsione e distribuzione. Il backend di riferimento è PyTorch.
Chi arriva da un mondo SQL può saltare tutto questo: BigQuery ML espone TimesFM dietro la funzione AI.FORECAST, senza creare né addestrare alcun modello, e la stessa cosa è disponibile in Connected Sheets e come endpoint containerizzato su Vertex Model Garden. Attenzione però: quelle integrazioni oggi servono TimesFM 2.5, non la 3.0.
L'hardware
La documentazione consiglia almeno 16 GB di RAM. Una GPU accelera parecchio — si parla di millisecondi contro frazioni di secondo per previsione — ma non è un prerequisito assoluto per volumi contenuti. Per un batch notturno su qualche migliaio di serie, una singola GPU di fascia media è più che sufficiente.
Le competenze
Non serve un team di ricerca. Serve qualcuno che sappia mettere in piedi una pipeline dati affidabile e — più importante — qualcuno che sappia valutare il risultato: backtest onesti su periodi trattenuti, confronto con la baseline che avete già oggi, metriche concordate prima di iniziare. Il rischio maggiore di questi modelli non è che siano imprecisi, è che siano impressionanti in demo e mai misurati sul serio.
Il vincolo che cambia tutto: la licenza
E qui arriva la parte che va letta prima di aprire il progetto in azienda.
Il codice di TimesFM è Apache-2.0. I pesi fino alla versione 2.5 sono Apache-2.0. I pesi della 3.0 no: sono distribuiti sotto una licenza separata, la timesfm-non-commercial-license-v1.0, che li limita a uso non commerciale e non di produzione. Il repository lo scrive a chiare lettere: l'uso commerciale o in produzione dei pesi pre-addestrati di default non è permesso.
Tradotto: potete studiarlo, confrontarlo con quello che avete, scriverci un paper, farci un proof of concept interno. Non potete metterlo dietro l'API che decide i vostri riordini. Come ha titolato The New Stack, «non potete usarlo al lavoro (per ora)». Quel «per ora» è anche nel testo di Google — «for the time being» — e lascia intendere che la restrizione sia temporanea, ma finché resta lì è una restrizione a tutti gli effetti.
La conseguenza pratica è che TimesFM 2.5 resta l'unico checkpoint Google utilizzabile in produzione, ed è anche quello che alimenta BigQuery, Sheets e Vertex. Chi ha bisogno di andare in produzione oggi con un modello fondazionale multivariato e con licenza permissiva guarda altrove — e Chronos-2 di Amazon, con la sua integrazione AWS e una comunità più larga, è lì apposta.
Quando ha senso, e quando no
Ha senso se avete molte serie eterogenee (migliaia di referenze, punti vendita, sensori, contatori), poco tempo, nessun team dedicato al forecasting, e un processo decisionale che beneficia di intervalli di confidenza. È il caso classico del retail, della logistica, dell'energia, della manutenzione predittiva, del capacity planning IT.
Ha meno senso se avete poche serie molto stabili e anni di storico: lì un ARIMA o un Prophet ben tarati restano competitivi, costano meno, si spiegano a un consiglio di amministrazione e rispondono in tempi che un transformer non raggiunge. La spiegabilità, in certi settori regolati, non è un dettaglio estetico.
E vale la pena dirlo esplicitamente perché la domanda arriva sempre: non è una macchina per prevedere i mercati finanziari. Sui prezzi degli asset i test disponibili mostrano risultati altalenanti e nessun vantaggio strutturale — il che è esattamente ciò che ci si aspetta da serie il cui segnale prevedibile viene arbitrato via in tempo reale.
Cosa farei
Se dovessi consigliare un'azienda oggi, l'ordine sarebbe questo. Primo: misurare la baseline attuale, seriamente, perché senza quel numero tutto il resto è narrativa. Secondo: provare TimesFM 2.5 via AI.FORECAST su BigQuery, che costa poche ore di lavoro, è licenziato per la produzione e dà subito l'ordine di grandezza del guadagno possibile. Terzo: usare TimesFM-3 come termine di paragone in laboratorio, per capire quanto valgono, sui vostri dati, il multivariato nativo e le covariate future — e tenere quel numero pronto per il giorno in cui la licenza cambierà.
Perché la notizia vera di questo rilascio non è il primo posto in classifica. È che il forecasting sta smettendo di essere un progetto e sta diventando una chiamata di funzione. Il collo di bottiglia si sta spostando dove è sempre stato davvero: nella qualità dei dati che gli si dà in pasto, e nella capacità di decidere qualcosa di diverso una volta ottenuta la previsione.