A IBM publicou no dia 9 de setembro de 2026 o Granite Time Series PatchTST-FM-r2, sucessor do PatchTST-FM-r1. O anúncio foi feito no blog da Hugging Face pela equipe da IBM Research e o modelo já está disponível no Hub com pesos abertos, código de inferência e scripts para reproduzir os números do benchmark. É um foundation model de séries temporais de aproximadamente 385 milhões de parâmetros, distribuído sob dupla licença (Apache 2.0 e OpenMDW 1.0), o que permite uso comercial sem as restrições típicas de licenças de pesquisa.
Segundo a própria IBM, o modelo é hoje o mais bem colocado, dentro da categoria de modelos zero-shot replicáveis com licença comercial permissiva, no GIFT-Eval. Ficou em segundo lugar geral entre modelos zero-shot replicáveis nessa mesma categoria. Vou explicar o que isso significa na prática, como a arquitetura mudou em relação ao r1, e mostrar como rodar previsão nos seus próprios dados.
O que é o GIFT-Eval e por que a categoria importa
Antes de falar do modelo, precisa entender contra o que ele foi medido. O GIFT-Eval é um benchmark de forecasting geral que abrange 23 datasets, mais de 144 mil séries temporais e 177 milhões de pontos, cobrindo sete domínios, dez frequências, entradas multivariadas e horizontes de previsão de curto a longo prazo. Combinando datasets, frequências e horizontes, o GIFT-Eval oferece 97 tarefas distintas de benchmarking.
O ponto sutil, e que a IBM enfatiza, é a distinção entre “zero-shot” e “pretrained”. No GIFT-Eval, alguns modelos são categorizados como pretrained porque podem ter incluído partes de treino dos datasets de avaliação no próprio corpus de pretreino. Isso vaza informação e ajuda os números. Zero-shot significa que o modelo nunca viu aqueles datasets. É a categoria mais honesta quando o objetivo é medir generalização.
Nas duas métricas principais (CRPS, que mede a qualidade da previsão probabilística, e MASE, que mede o erro escalado por uma baseline sazonal), o PatchTST-FM-r2 aparece em segundo lugar na categoria zero-shot replicável. A IBM reporta CRPS geométrico médio de 0,467 e MASE geométrico médio de 0,6846. Quando o comparativo é ampliado para incluir modelos pretrained, ele ainda fica em terceiro para CRPS e quarto para MASE, superando Chronos-2, Timer-S1 e variantes do Toto.
Um detalhe honesto sobre esse ranking
Ranking em benchmark é uma foto. O post da IBM data de 9 de setembro de 2026 e o próprio GIFT-Eval recebe submissões novas continuamente. Quando você ler isso, a ordem pode ter mudado. O que importa mais é entender o mecanismo, porque isso não muda.
Como a arquitetura mudou do r1 para o r2
O r2 mantém a ideia central da família PatchTST: quebrar a série temporal em pedaços (patches) e tratar cada patch como um token, algo análogo ao que o Vision Transformer faz com imagens. A mudança grande está no bloco interno.
Da camada transformer para a camada conformer
No r1, cada bloco era um transformer padrão: multi-head self-attention seguido de uma feed-forward network. No r2, o bloco virou um conformer. O conformer é uma arquitetura que veio do reconhecimento de fala. A ideia é combinar o melhor dos dois mundos: features globais extraídas pelo transformer e features locais aprendidas pelo módulo de convolução.
Estruturalmente, o Conformer é composto por duas camadas feed-forward em estilo macaron com conexões residuais de meio passo, envolvendo os módulos de multi-head self-attention e de convolução. Traduzindo: sanduíche com meia FFN em cima, atenção no meio, convolução depois, e meia FFN embaixo. Cada metade contribui com meio residual, por isso o nome macaron.
Por que isso ajuda uma série temporal? Atenção é boa para relações de longo alcance mas tem viés fraco para estrutura local. Convolução é o oposto. As camadas multi-head self-attention usam atenção com produto escalado para capturar variações globais na sequência, e como a convolução captura informação local, aumentar as camadas de transformer com camadas de convolução melhora o desempenho. Em séries temporais, você tem sazonalidade curta (o padrão das últimas horas) e tendência longa (o comportamento das últimas semanas). Cada mecanismo cobre um lado.
A IBM inclusive mostra um gráfico de padrões de atenção no dataset ETTh1: no transformer puro, a atenção se concentra perto da diagonal (relações locais). No conformer, a atenção espalha para longe da diagonal, porque a convolução já cobre o curto alcance e libera a atenção para focar no longo. É uma consequência arquitetural bem legível.
Outros detalhes que a IBM lista
- Os blocos conformer no backbone alternam kernels de convolução de tamanhos 3 e 5, em um padrão repetitivo {5, 5, 3, 3}.
- Patches com 50% de sobreposição, ponderados por uma janela de Hamming, e previsão por overlap-and-add para suavizar as bordas entre patches. Isso ataca um problema conhecido de modelos de patches: descontinuidade entre os pedaços na hora de reconstruir a previsão.
- Normalização adicional para estabilidade.
- Expansão de 20 para 30 blocos.
- Aproximadamente 385M parâmetros, contexto de até 8.192 passos, e uma cabeça de predição que emite 99 quantis.
Os 99 quantis são o que dá a previsão probabilística. Em vez de cuspir um único número para cada passo futuro, o modelo estima a distribuição inteira, o que permite construir intervalos de confiança sem hipótese gaussiana.
Dados de treino e por que a licença importa
A IBM documenta o corpus de pretreino em quatro fontes: datasets selecionados do GiftEvalPretrain, dados sintéticos baseados em KernelSynth com kernels periódicos modificados, um corpus TSMixup gerado pela abordagem do Chronos mas restrito a datasets fora do conjunto de avaliação do GIFT-Eval, e cerca de 500 mil sequências sintéticas CauKer de comprimento 4.096.
A parte importante é a ausência dos datasets de teste do GIFT-Eval no treino. Isso é o que torna o resultado zero-shot legítimo. Muitos foundation models de séries temporais falham nessa disciplina.
Sobre licença: o modelo é dual-licensed sob Apache 2.0 e OpenMDW 1.0. O usuário escolhe qual usar. A OpenMDW é uma licença da Linux Foundation projetada especificamente para modelos e materiais associados (pesos, código, documentação tratados como uma unidade). Para uso comercial, na prática, Apache 2.0 já resolve. A OpenMDW é útil quando você quer um único framework legal cobrindo pesos, dados e código juntos.
Rodando o modelo em Python
O caminho mais curto para testar. Instala o pacote:
pip install "granite-tsfm>=0.3.9"E carrega o modelo direto do Hub:
import pandas as pd
from tsfm_public import PatchTSTFMForPrediction, TimeSeriesForecastingPipeline
# Baixa os pesos
model = PatchTSTFMForPrediction.from_pretrained(
"ibm-granite/granite-timeseries-patchtst-fm-r2"
)
# Dados de exemplo (ETTh1, um dataset padrao de referencia)
df = pd.read_csv(
"https://raw.githubusercontent.com/zhouhaoyi/ETDataset/main/ETT-small/ETTh1.csv",
parse_dates=["date"],
)
# Monta o pipeline: 512 passos de historico, 64 passos de previsao
pipe = TimeSeriesForecastingPipeline(
model=model,
id_columns=[],
timestamp_column="date",
target_columns=["HUFL"],
max_context_length=model.config.context_length,
context_length=512,
prediction_length=64,
impute_method=None,
quantile_levels=[0.1, 0.5, 0.9],
explode_forecasts=True,
freq="1h",
)
# Gera a previsao usando apenas os ultimos 512 pontos
forecast = pipe(df.iloc[-512:])Repare no que não tem aqui: nenhum treino, nenhum fine-tuning, nenhuma definição de features. Você passa a série, define quantos passos de histórico e quantos passos de previsão, e o modelo devolve os quantis pedidos. Neste exemplo, os quantis 0,1, 0,5 e 0,9 dão a banda de 80% de confiança e a mediana.
Para seus próprios dados, o formato mínimo é uma coluna de timestamp e uma coluna alvo. Se a série for multivariada, você lista as colunas em target_columns. O freq="1h" indica frequência horária. Ajuste conforme sua granularidade.
Onde isso quebra
Umas coisas que não estão no marketing mas dá para deduzir da documentação e da experiência geral com foundation models de séries temporais:
- Custo de inferência. 385M parâmetros é grande para forecasting. Se você tem milhões de séries curtas para prever (varejo com SKU-loja, por exemplo), o custo por inferência importa. Modelos menores da mesma família Granite (TTM, TSPulse) provavelmente serão mais eficientes para esse cenário. A IBM não publicou benchmarks de latência no post de anúncio.
- Contexto de 8.192 passos. É bastante, mas atenção tem custo quadrático. Contexto longo é caro. Nem sempre você precisa de todo esse histórico, e alimentar contexto irrelevante pode inclusive piorar a previsão.
- Frequência regular. O modelo assume amostragem regular. Séries com timestamps irregulares (eventos, cliques) precisam de reamostragem ou imputação antes.
- Séries com regime shift. Zero-shot brilha quando a estrutura da série se assemelha ao que existe no corpus de pretreino. Séries com mudança de regime abrupta (novo lançamento, política nova, ruptura estrutural) continuam sendo casos difíceis. Nesses casos, fine-tuning ou modelos clássicos com features de domínio podem ganhar.
- Um foundation model não substitui feature engineering em todos os casos. Se você tem covariáveis fortes (preço, promoção, feriado), um modelo que consuma essas covariáveis explicitamente pode superar zero-shot puro. O PatchTST-FM-r2 é primariamente univariado no seu uso mais simples.
O que ainda não dá para afirmar
Alguns pontos honestos que a documentação pública não fecha:
- A IBM não publicou benchmarks de latência e memória em CPUs comuns. Para deploy fora de GPU, isso é decisivo, e sem números independentes não dá para dimensionar custo de produção.
- A comparação com TimesFM-3 (primeiro colocado zero-shot no momento do anúncio) precisa ser vista com contexto: modelos evoluem rápido, e a ordem no leaderboard vai mudar. O relevante é a ordem de grandeza, não o pódio.
- Benchmarks independentes de terceiros fora do GIFT-Eval ainda não apareceram no volume que dá confiança estatística.
- A integração com Confluent Cloud via Apache Flink foi anunciada em programa de Early Access com modelos anteriores da família (PatchTST-FM-r1, FlowState-r1.1, TTM-r3, TSPulse). O r2 ainda não aparece listado nesse programa na documentação publicada até agora.
Como testar isso você mesmo
Um caminho pequeno para experimentar em algo que você entenda:
- Pega uma série sua com pelo menos 1.000 pontos e frequência regular. Consumo de CPU de um servidor, tráfego de um endpoint, temperatura de um sensor, o que for.
- Separa os últimos N pontos como validação (por exemplo, os últimos 168 se for horária: uma semana).
- Roda o pipeline acima usando o histórico anterior à validação como contexto e pede previsão do mesmo tamanho da validação.
- Compara a mediana (quantil 0,5) com o real usando MAE ou MAPE. Compara também a cobertura: dos pontos reais, quantos caíram dentro da banda 0,1 a 0,9? Se caírem cerca de 80%, a calibração probabilística está boa.
- Como baseline, roda um Prophet ou um
SeasonalNaivena mesma tarefa. Se o zero-shot não vencer as baselines, ou seu problema tem estrutura muito específica, ou você precisa alimentar mais contexto, ou é hora de considerar fine-tuning.
Esse ciclo curto responde a pergunta que interessa: no seu problema, um foundation model zero-shot já é bom o suficiente para substituir o pipeline atual, ou é só mais uma ferramenta na caixa? A resposta honesta quase sempre é “depende do seu problema”, e agora existe um jeito barato de descobrir.
