Google Research lancia TimesFM-3, ma il suo miglior modello ha un vincolo commerciale

Google Research ha rilasciato TimesFM-3 il 31 agosto 2026, aggiungendo previsioni multivariate native a una famiglia di modelli in precedenza limitata alle previsioni su singole serie. Il modello da 330 milioni di parametri elabora più informazioni in un solo passaggio, incluse serie correlate, segnali storici ed eventi futuri già noti.

Il cambiamento è rilevante perché le previsioni reali raramente dipendono da una sola cronologia. La domanda nel retail risponde a promozioni e condizioni meteorologiche. Il consumo energetico segue temperatura, calendari e attività. Le metriche infrastrutturali si muovono insieme quando un servizio condiviso si interrompe.

Secondo Google, TimesFM-3 colma questa lacuna senza richiedere fine-tuning specifico per il compito. Tuttavia, il rilascio presenta un conflitto importante. Il codice rimane aperto con licenza Apache 2.0, mentre i nuovi pesi preaddestrati vietano l'uso commerciale e in produzione.

Il risultato è più di un semplice aggiornamento del modello. Google Research ha prodotto un'architettura generale di forecasting più solida, separando la sperimentazione pubblica dal deployment senza restrizioni. Ciò mette sotto pressione Chronos-2 di Amazon, la famiglia Toto di Datadog e i team che mantengono pipeline di forecasting specializzate.

Cosa ha cambiato Google Research in TimesFM-3

TimesFM-3 trasforma la famiglia TimesFM da un previsore per singole serie in un modello capace di ragionare su variabili connesse.

Google ha introdotto il TimesFM originale nel febbraio 2024. Quel modello utilizzava un transformer solo decoder, ossia prevedeva patch future di serie temporali a partire dalle patch precedenti. I suoi 200 milioni di parametri sono stati addestrati su 100 miliardi di punti temporali reali.

Il modello originale eseguiva previsioni zero-shot, vale a dire produceva predizioni su un dataset mai visto senza essere addestrato specificamente su quel dataset. Google ha riportato risultati competitivi rispetto ai metodi statistici e ai modelli di deep learning supervisionato nel suo paper sul modello di forecasting.

TimesFM-2.0 ha successivamente portato la dimensione del modello a 500 milioni di parametri. TimesFM-2.5 è tornato a 200 milioni, estendendo però il contesto supportato da 2.048 a 16.384 punti temporali. Ha inoltre aggiunto previsioni continue per quantili su orizzonti fino a 1.000 step.

Eppure, quei rilasci sono rimasti fondamentalmente univariati. Ogni previsione trattava principalmente una serie target come oggetto della predizione, anche quando regressori esterni erano disponibili attraverso un meccanismo separato.

TimesFM-3 cambia questo approccio. I suoi 330 milioni di parametri sono stati preaddestrati su oltre mille miliardi di punti temporali reali e sintetici. Il corpus di addestramento è più di dieci volte più grande di quello dichiarato per il primo modello.

Il modello accetta diversi tipi distinti di informazioni. Più target rappresentano serie correlate che gli utenti desiderano prevedere insieme. Le covariate passate forniscono variabili note solo fino al periodo di osservazione. Le covariate passato-futuro includono valori già noti lungo l'orizzonte di previsione.

Un retailer, per esempio, potrebbe prevedere congiuntamente la domanda di gelato, coni e sciroppo. Il traffico storico in negozio può fungere da covariata passata. Promozioni pianificate e previsioni meteo possono diventare covariate passato-futuro.

Questa configurazione consente al modello di usare connessioni che il forecasting univariato scarta. Un picco delle vendite diventa più facile da interpretare quando il modello vede che coincide con una promozione. Le variazioni della domanda tra prodotti correlati possono inoltre fornire evidenza di comportamenti condivisi.

Il rilascio ufficiale di TimesFM-3 afferma che il modello supporta sia previsioni puntuali sia previsioni per quantili per ogni target. Una previsione puntuale fornisce un singolo valore atteso. I quantili descrivono una gamma di possibili risultati e la relativa incertezza.

TimesFM-3 produce nove quantili, dal 10° al 90° percentile. Questo è importante per decisioni in cui una sola previsione non basta. I team responsabili dell'inventario devono comprendere i rischi di esaurimento delle scorte e di sovrastoccaggio, non solo la domanda attesa.

Google afferma inoltre che il modello funziona in modalità univariata. Gli sviluppatori possono quindi testare il nuovo checkpoint sui carichi di lavoro esistenti basati su singole serie prima di costruire una pipeline dati multivariata completa.

Il rilascio è già disponibile tramite il repository pubblico di Google Research e un checkpoint Hugging Face. Google afferma che l'integrazione con BigQuery seguirà nelle prossime settimane, rendendo il 31 agosto la data dell'evento verificata alla base della rinnovata visibilità del repository.

Il trend su GitHub è quindi legato a un rilascio attuale, non a una riscoperta del progetto del 2024. TimesFM-3 è il modello più recente del repository e la nuova architettura multivariata è l'evento che sta attirando l'attenzione.

Perché il forecasting multivariato cambia la posta in gioco competitiva

Il cambiamento importante non riguarda soltanto una maggiore accuratezza. TimesFM-3 punta alle relazioni complesse che determinano se il forecasting funziona in produzione.

La maggior parte delle previsioni operative vive in sistemi connessi. Un magazzino non registra domanda indipendentemente da prezzi, promozioni, meteo, festività e inventario nelle vicinanze. Un data center non genera segnali isolati di CPU, memoria, traffico e latenza.

I modelli univariati semplificano queste relazioni. Possono rilevare stagionalità, tendenze e pattern ricorrenti nella cronologia di un singolo target. Tuttavia, non possono interpretare direttamente una promozione programmata, a meno che quell'informazione non entri tramite un altro meccanismo.

Il forecasting multivariato gestisce diverse serie congiuntamente. Può modellare come una variabile si muova insieme a un'altra e come i segnali esterni modifichino il target. Questo approccio è particolarmente utile quando tali relazioni ricorrono nel contesto storico.

L'esempio illustrativo di Google sul retail mostra il perché. Una previsione univariata estende il pattern storico delle vendite settimanali. Non può anticipare i giorni di promozione perché il calendario non compare nei valori passati del target.

TimesFM-3 riceve quel calendario come covariata futura nota. Il modello associa quindi le promozioni storiche alle variazioni delle vendite e applica quella relazione alle date pianificate. L'esempio di Google mostra un aumento delle vendite previsto di circa il 20 percento in ogni giorno di promozione.

Quella cifra è illustrativa, non prova che il modello produrrà la stessa previsione di incremento presso tutti i retailer. Gli effetti delle promozioni dipendono da prezzi, prodotti, clienti, tempistiche e qualità dei dati. L'esempio dimostra invece come le informazioni future entrino nella previsione.

Questa capacità esercita una pressione diretta su altri modelli foundation per serie temporali. La famiglia Chronos di Amazon ha contribuito a dimostrare che il preaddestramento in stile modello linguistico è un approccio praticabile al forecasting. Chronos-2 ha successivamente esteso la competizione a compiti multivariati e consapevoli delle covariate.

Anche la famiglia Toto di Datadog è rivolta al forecasting general-purpose, inclusi i carichi di lavoro multivariati. La famiglia Moirai di Salesforce e Tiny Time Mixers di IBM rappresentano altri tentativi di sostituire modelli separati e specifici per compito con sistemi preaddestrati riutilizzabili.

La competizione riguarda sempre più l'ampiezza del deployment. Un modello foundation che funziona solo su benchmark pubblici puliti offre valore limitato a un team operativo. Il sistema vincente deve gestire contesto aziendale irregolare, incertezza, relazioni variabili e costi di inferenza accettabili.

TimesFM-3 offre a Google una risposta credibile ai rivali che erano già andati oltre il forecasting univariato. Collega inoltre la ricerca a un canale di distribuzione esistente. Le precedenti capacità di TimesFM hanno raggiunto gli ambienti BigQuery, AlloyDB, Google Sheets e Vertex AI.

Google ha riferito che TimesFM serviva già centinaia di milioni di query mensili tramite BigQuery e AlloyDB nel corso del 2025. Quel numero riguarda versioni precedenti del modello, non TimesFM-3, ma mostra un percorso consolidato dalla ricerca all'utilizzo regolare.

La distribuzione potrebbe contare quanto la posizione nei benchmark. Un modello di forecasting all'interno di un data warehouse consente agli analisti di lavorare vicino a dati aziendali governati. Evita di richiedere a ogni team di assemblare un servizio di inferenza separato prima di testare una previsione.

La pressione ricade anche sulle pipeline di forecasting specializzate. Molte organizzazioni addestrano ancora modelli diversi per prodotti, regioni o metriche differenti. Ogni modello richiede feature engineering, validazione, monitoraggio e manutenzione ripetuta.

Un generalista zero-shot cambia il punto di partenza. I team possono valutare un unico modello su molte serie prima di decidere dove l'addestramento specializzato resti utile. Questo non elimina i modelli personalizzati, ma alza lo standard che devono superare.

È anche per questo che l'espressione “no fine-tuning” richiede un'interpretazione attenta. Gli utenti devono comunque selezionare i target, preparare le covariate, prevenire leakage, scegliere gli orizzonti di previsione e valutare i costi aziendali. Il modello rimuove una fase di addestramento, non la disciplina di forecasting che la circonda.

Un modello a passaggio singolo riscrive il meccanismo di forecasting

TimesFM-3 combina l'attenzione tra serie con una decodifica a passaggio singolo, affrontando sia il contesto mancante sia l'accumulo degli errori.

Come le versioni precedenti di TimesFM, il modello raggruppa osservazioni adiacenti in patch di 32 step temporali. Una patch funziona come un token in un modello linguistico, comprimendo diversi valori continui in una rappresentazione interna.

Il patching riduce la lunghezza della sequenza e rende più semplici da elaborare le cronologie lunghe. Consente inoltre al transformer di operare su pattern locali ricorrenti invece di trattare ogni misurazione come un elemento non correlato.

TimesFM-3 organizza questi token lungo due dimensioni. Una dimensione rappresenta il tempo. L'altra rappresenta le diverse serie target e covariate incluse nella richiesta.

Il transformer alterna due operazioni di attenzione. L'attenzione temporale causale esamina le patch precedenti all'interno di una serie. “Causale” significa che il modello non può ispezionare valori futuri ignoti del target mentre formula una previsione.

L'attenzione completa sulle variabili opera tra serie nella stessa posizione temporale. Consente a un target di ricavare informazioni da altri target e dalle covariate. È così che un calendario promozionale può influenzare la previsione di vendita associata.

Le covariate passato-futuro ricevono uno speciale trattamento lookahead. Ogni token combina la propria patch corrente con patch future contenenti informazioni già note. Il modello può quindi vedere eventi programmati senza ricevere gli esiti futuri del target.

Questa distinzione è essenziale. Un calendario futuro delle festività è un input valido perché le date sono già note. Le vendite effettive di domani non sono un input valido perché rivelarle causerebbe leakage della risposta.

Google Research ha inoltre cambiato il processo di decodifica. I modelli TimesFM più vecchi generavano le patch di previsione in sequenza. Ogni patch prevista diventava contesto per produrre quella successiva.

La generazione sequenziale presenta due debolezze. Aumenta la latenza perché ogni step attende quello precedente. Inoltre, consente a un errore di previsione iniziale di influenzare ogni patch successiva.

TimesFM-3 utilizza invece il masking di patch contigue. Il sistema aggiunge segnaposto mascherati che coprono l'intero orizzonte di previsione, quindi predice quelle posizioni in un solo forward pass.

Le covariate future note rimangono visibili, mentre i valori target restano mascherati. L'attenzione temporale e sulle variabili alternata elabora il contesto combinato. Il modello completa l'orizzonte di previsione senza un ciclo di generazione iterativo.

Questo design non autoregressivo, cioè non produce l'orizzonte un pezzo alla volta, è centrale nella dichiarazione di Google sulle prestazioni. Orizzonti più lunghi non richiedono più un numero proporzionalmente maggiore di cicli di decodifica.

Il meccanismo cambia anche ciò che gli utenti dovrebbero misurare. La latenza grezza del modello diventa importante, ma lo sono anche l’uso della memoria e la scalabilità su molte variabili. La previsione congiunta può inserire più serie in ogni richiesta, aumentando la quantità di calcolo dell’attenzione.

Il repository TimesFM pubblico include esempi per input univariati di lunghezza variabile e array multivariati. Mostra inoltre input separati per covariate disponibili solo nel passato e covariate disponibili nel passato e nel futuro.

Questi esempi evidenziano un requisito pratico. Gli utenti devono allineare ogni target e covariata a una cronologia coerente. Osservazioni mancanti, ritardi nella reportistica e frequenze non corrispondenti possono compromettere il risultato prima ancora che inizi l’inferenza.

Si consideri un carico di lavoro di osservabilità. L’utilizzo della CPU potrebbe arrivare ogni minuto, i dati di fatturazione ogni ora e gli indicatori di deployment solo al momento dei rilasci. Combinarli richiede decisioni sul ricampionamento e sui valori mancanti.

I casi d’uso in ambito sanitario e finanziario aggiungono vincoli più rigorosi. I team devono stabilire se una variabile esterna sarebbe stata davvero disponibile al momento della previsione. In caso contrario, un benchmark può sembrare accurato perché ha utilizzato accidentalmente informazioni future.

Spiegare TimesFM semplicemente come un transformer più grande manca il punto essenziale. Le sue dimensioni sono aumentate solo modestamente rispetto a TimesFM-2.5, mentre il corpus di preaddestramento si è esteso oltre un trilione di punti. Il cambiamento più profondo riguarda il modo in cui l’architettura rappresenta le relazioni e produce l’orizzonte.

Questo design rende il modello Google TimesFM più rilevante per la pianificazione operativa. Rende però anche più difficile la valutazione. Il successo dipende ora dal fatto che le relazioni fornite siano reali, stabili, correttamente temporizzate e utili per la decisione.

I benchmark non risolvono la questione della produzione

Google riporta risultati al primo posto in tre benchmark pubblici, ma le licenze e la validazione indipendente limitano ciò che gli adottanti possono concludere oggi.

Google ha valutato TimesFM-3 su GIFT-Eval, FEV-Bench e TIME. Queste suite coprono dataset, attività di previsione, orizzonti e impostazioni di valutazione diversi.

L’azienda riferisce che TimesFM-3 si è classificato al primo posto tra i foundation model preaddestrati sia per le previsioni puntuali sia per quelle probabilistiche. Afferma inoltre che il modello ha guidato FEV-Bench su 100 attività reali e il benchmark TIME su 98 attività provenienti da 50 domini.

GIFT-Eval offre un altro ampio test della previsione zero-shot. Google afferma che TimesFM-3 si è classificato al primo posto tra i foundation model inclusi in quel confronto.

Secondo quanto riportato, il modello è rimasto competitivo nella modalità univariata, in cui non poteva sfruttare covariate né informazioni tra serie. L’abilitazione della modalità multivariata completa ha ulteriormente migliorato la sua posizione media.

Sono segnali significativi perché verificano se un unico modello preaddestrato può trasferirsi tra dataset diversi. Confrontano inoltre TimesFM-3 con sistemi recenti, tra cui Chronos-2, Toto 2.0 e TimesFM-2.5.

Tuttavia, la posizione media comprime molti risultati in un solo numero. Non rivela se il modello vince sulle serie, sugli orizzonti e sui costi d’errore rilevanti per una particolare organizzazione.

Un pianificatore della grande distribuzione potrebbe preoccuparsi soprattutto degli errori prima dei picchi festivi. Un ingegnere della capacità potrebbe preoccuparsi di non rilevare eventi di traffico estremo. Un team finanziario può attribuire più valore a un’incertezza calibrata che a un piccolo miglioramento medio.

I benchmark pubblici possono inoltre differire dai dati di produzione. Le serie aziendali includono esaurimenti di scorte, cambiamenti di policy, lacune nella reportistica, lanci di prodotti e shock una tantum. Le relazioni apprese dalla storia possono fallire quando queste condizioni cambiano.

L’aspetto più rilevante per gli scettici riguarda l’accesso. Il codice sorgente del repository è distribuito con licenza Apache 2.0 e i pesi del modello fino a TimesFM-2.5 mantengono tale licenza. I pesi di TimesFM-3 utilizzano una licenza non commerciale separata.

Questa licenza limita i pesi preaddestrati predefiniti di TimesFM-3 a usi non commerciali e non di produzione. Un’azienda può studiare l’architettura ed eseguire esperimenti consentiti, ma non può presumere che il checkpoint scaricato sia distribuibile in un flusso di lavoro che genera ricavi.

Ciò crea un netto divario tra disponibilità tecnica e disponibilità operativa. Il modello è pubblico, ma il suo percorso di produzione più immediato rimane sotto il controllo di Google.

Il repository avverte inoltre che la sua versione aperta non è un prodotto Google ufficialmente supportato. Gli sviluppatori dovrebbero quindi distinguere tra codice accessibile alla community e un servizio con impegni di supporto enterprise.

L’integrazione con BigQuery potrebbe risolvere parte della questione del deployment. Google afferma che tale integrazione arriverà nelle settimane successive al rilascio. Ne saranno rilevanti i termini, la disponibilità geografica, le quote, gli input supportati e il comportamento in produzione.

Il supporto per le versioni precedenti di TimesFM esiste già tramite la funzione AI.FORECAST di BigQuery. Questa interfaccia riduce la barriera per gli utenti SQL, ma il supporto per TimesFM-3 dovrà essere verificato dopo il suo rollout.

Il rilascio non dispone inoltre del tipo di evidenza indipendente in produzione che si accumula nel tempo. Gli utenti pubblici hanno avuto solo pochi giorni per testare il comportamento multivariato, i requisiti di memoria, le modalità di errore e la sensibilità alle scelte delle covariate.

Anche la cifra di un trilione di punti per l’addestramento indicata da Google lascia interrogativi senza risposta. Il rilascio descrive una miscela di serie temporali reali e sintetiche, ma non fornisce un inventario completo del corpus. Gli utenti non possono valutare pienamente la copertura dei domini basandosi soltanto sulla scala.

Il modello iniziale utilizzava dati di Google Trends e visualizzazioni di pagine Wikipedia tra le sue fonti pubbliche. Questi dataset contengono pattern temporali utili, ma non si può presumere una somiglianza tra tali pattern e le operazioni interne di un’azienda.

Anche le previsioni quantili richiedono validazione. Produrre nove stime di incertezza non garantisce che i relativi intervalli siano calibrati in un nuovo dominio. I team dovrebbero verificare con quale frequenza gli esiti effettivi rientrano in ciascun intervallo previsto.

Il test pratico è quindi comparativo. Le organizzazioni dovrebbero confrontare TimesFM-3 con TimesFM-2.5, Chronos-2, Toto, baseline statistiche e i loro attuali modelli di produzione usando le stesse suddivisioni basate sul tempo.

Dovrebbero inoltre valutare le decisioni generate da ciascuna previsione. Un piccolo vantaggio statistico può avere scarso valore se l’inferenza è più difficile, le covariate sono inaffidabili o la licenza blocca il deployment.

I benchmark di Google sostengono una valutazione seria. Non giustificano la sostituzione di un sistema di produzione senza test locali, salvaguardie operative e chiari diritti d’uso.

Cosa osservare dopo il rilascio di Google Research

Tre segnali determineranno se TimesFM-3 diventerà un livello di previsione ampiamente utilizzato o rimarrà un influente checkpoint di ricerca.

Il primo segnale è la promessa integrazione con BigQuery. La disponibilità tramite SQL offrirebbe agli analisti un percorso diretto verso previsioni multivariate vicine ai dati già presenti nel data warehouse.

I dettagli dell’implementazione riveleranno quanta parte di TimesFM-3 raggiungerà gli utenti gestiti. Gli acquirenti dovrebbero cercare un supporto che copra più target, covariate storiche, covariate future note, output quantili e orizzonti di previsione realistici.

Anche i termini di prezzo sono importanti, sebbene la valutazione iniziale debba concentrarsi sull’adeguatezza al carico di lavoro piuttosto che sul costo dichiarato. Latenza, quote, disponibilità regionale e controlli di governance dei dati determineranno se i team potranno usare il servizio ripetutamente.

Un ampio supporto BigQuery rafforzerebbe la posizione di Google perché trasformerebbe un rilascio di ricerca in un’infrastruttura accessibile. Un’integrazione ritardata o limitata lascerebbe spazio a rivali e fornitori indipendenti di forecasting.

Il secondo segnale è la riproduzione indipendente dei benchmark. Ricercatori e professionisti devono confermare la classifica riportata con dataset fissi, regole di valutazione identiche e condizioni di calcolo comparabili.

Un’attenzione particolare dovrebbe essere riservata alle attività multivariate in cui sono disponibili covariate future utili. Questi casi testano l’affermazione centrale di TimesFM-3, anziché le sue prestazioni univariate retrocompatibili.

I valutatori dovrebbero inoltre pubblicare risultati a livello di attività, non solo classifiche medie. Questo dettaglio mostrerà dove TimesFM-3 incontra difficoltà e se i suoi vantaggi si concentrano in domini o orizzonti specifici.

Test che coinvolgono valori mancanti, cambiamenti di regime, covariate rumorose e un elevato numero di serie correlate offrirebbero maggiore rilevanza per la produzione. Potrebbero indebolire il caso di Google se le prestazioni dipendono da input insolitamente puliti.

Il terzo segnale è lo status commerciale dei pesi preaddestrati. Una licenza più ampia consentirebbe a più organizzazioni di distribuire il checkpoint tramite la propria infrastruttura. Restrizioni continue spingerebbero l’adozione commerciale verso i servizi Google gestiti.

Questa scelta influenza la mappa competitiva. Chronos-2, Toto, Moirai e modelli di forecasting più piccoli possono guadagnare terreno quando le loro condizioni di accesso si adattano meglio ai requisiti di deployment privato.

Gli sviluppatori dovrebbero esaminare la licenza del modello prima di costruire un prodotto attorno al checkpoint. La disponibilità pubblica non prevale sulle restrizioni dichiarate.

I team possono comunque usare il rilascio per porre domande tecniche migliori. Le informazioni tra serie migliorano l’accuratezza dopo rigorosi controlli contro la fuga di informazioni? Gli eventi futuri noti producono cambiamenti sensati? Le previsioni quantili sono calibrate durante periodi insoliti?

Una valutazione utile dovrebbe preservare un set di validazione basato sul tempo, confrontare baseline semplici e calcolare costi specifici per la decisione. I team dovrebbero documentare quali covariate erano realmente note in ogni punto di previsione storico.

Dovrebbero inoltre mantenere il modello credibile più semplice. Se una baseline stagionale offre prestazioni simili, il foundation model aggiunge complessità senza benefici sufficienti. Se TimesFM-3 vince in modo costante, fornisce evidenza a favore di un diverso flusso di lavoro per le previsioni.

Google Research ha sostenuto che i modelli di forecasting generali dovrebbero comprendere variabili connesse e generare orizzonti completi in modo efficiente. Non ha ancora chiarito quanto apertamente i suoi pesi più potenti arriveranno in produzione.

I prossimi mesi mostreranno se disponibilità gestita, risultati indipendenti e licenze convergeranno. Fino ad allora, TimesFM-3 va trattato come un rilascio architetturale significativo e un candidato al deployment attentamente delimitato.

Per gli sviluppatori e i team dati, l’azione immediata è semplice: scegliere un problema di previsione rilevante, costruire una valutazione sicura rispetto alla fuga di informazioni e testare il modello contro il sistema che già prende decisioni. TimesFM-3 migliora il risultato che la vostra organizzazione valuta realmente?