timestral

Timestral Adrien Petralia, Alexandre Gavaudan, Artjom Joosen, Etienne Goffinet, Richard Kurle, Yassine El Ouahidi, Yassir Bendou, Abdelaziz Bounhar, Abhijeet Somani, Aditi Kabra, Adrian Valente, Adrien Sadé, … arxiv.org [𝚌𝚜.𝙰𝙸] 💬Code: mistralai/timestral t.co

Timestral We introduce Timestral, a family of four time series foundation models for probabilistic forecasting, with 5M, 28M, 123M, and 209M parameters. Timestral sets a new state of the art on GIFT-Eval, TIME, and fev-bench, where Timestral-209M and Timestral-123M take the top two places on every metric. We achieve this with three ingredients: Decoupled Horizon Forecasting (DHF), which separates prediction tokens from the causally encoded context, so that longer horizons are trained without masking context and each observed value is both a forecast target and context for later forecasts; a covariate framework that natively supports known-future covariates within a causal architecture; and a two-stage pipeline that pretrains exclusively on a diverse, large-scale synthetic corpus before post-training on a mix of real and synthetic data with extended context. This report describes the model design and its benchmark results. Weights for all four models are available on Hugging Face and inference code on GitHub. Comments: Webpage: mistral.ai ; Weights: huggingface.co ; Code: mistralai/timestral

Mistral open-sourced Timestral, a time-series foundation model, with the pitch of zero-shot forecasting and no per-series training. If you run Prophet or ARIMA pipelines, run a benchmark pass before you assume it cannot replace them. mistralai/timestral

预测销量外包一次 3 万，这模型自己跑。Mistral 开源时序基础模型 Timestral：历史数据直接预测后续几十步，本地跑不出内网。 mistralai/timestral

Mistral just dropped a Time-Series AI model 🤖 ⭐ GitHub Repository: mistralai/timestral In this video, we explore timestral, an open-source project that mistral AI released Timestral, a family of time series foundation models supporting multivariate probabilistic forecasting and long contexts up to 32,768 steps.. #github #coding #opensource #programming #developer

Mistral's Timestral is #1 by 0.003 MASE. I ran it — the model was not the variable. --- published: true description: Mistral released Timestral, four open-weight time-series models that top three benchmarks — by 0.003 MASE on their own table. I ran all three sizes against one-line baselines, on a known generator and on fresh Paris weather. With one summer of context the 209M lost to "repeat yesterday"; with three years it beat everything by a third — and the 20 MB model matched the 837 MB one. tags: ai, python, machinelearning, opensource series: receipts --- Same model, same fourteen days of Paris weather, same holdout. The only thing I changed between these two rows was how much history I handed it: Timestral-209M, context = one summer (158 days) MAE 6.489 80% band covered the truth 43% of the time Timestral-209M, context = three years (1,096 days) MAE 3.326 80% band covered the truth 64% of the time "repeat yesterday", no model at all MAE 5.636 With one summer in the window, Mistral's new state-of-the-art forecaster lost to a baseline that repeats the last value. With three Octobers in the window, it beat every baseline by a third. And the smallest model in the family — 20.8 MB on disk — landed within 0.03 of the 837 MB flagship. The variable that mattered was not the parameters. It was the context. Nothing on a leaderboard tells you that; a ninety-line script does, and it is below. The release, and the number behind "first" On October 15, Mistral shipped Timestral, its first family of time-series foundation models: four open-weight checkpoints at 5M, 28M, 123M, and 209M parameters, zero-shot forecasting with 21 quantiles, up to 32,768 steps of context, PyTorch on CPU or GPU, code on GitHub under Apache-2.0. The announcement is specific: it "ranks first on all three of the field's main public benchmarks, GIFT-Eval, TIME, and fev-bench," and, "Among pre-trained, zero-shot models, it ranks first across all five metrics." Also: "These results come from a single checkpoint, without ensembling." The Hacker News thread hit 601 points. The margins are on the model card, in Mistral's own table. I copied the first-place column and the second-place column and subtracted: | Benchmark | Metric | Timestral-209M | Runner-up (t0-gamma) | Margin | |---|---|---|---|---| | GIFT-Eval | MASE ↓ | 0.658 | 0.661 | 0.003 | | GIFT-Eval | CRPS ↓ | 0.446 | 0.452 | 0.006 | | TIME | MASE ↓ | 0.626 | 0.637 | 0.011 | | TIME | CRPS ↓ | 0.522 | 0.534 | 0.012 | | fev-bench | SQL skill ↑ | 50.39 | 49.42 | 0.97 | | fev-bench | MASE skill ↑ | 39.49 | 37.99 | 1.50 | Every row is a first place, and the announcement is right about every row. The first place on the headline benchmark is three thousandths of a MASE point. One HN commenter put it bluntly — "crazy how they make an improvement of 0.03 look like a 5x difference" — and the card's number is smaller than his. Another noted that "the blog post features an imaginary customer rather than an actual reference"; I read the page twice: no customer is named, the case study opens with "Consider an industrial plant with thousands of sensors across its equipment." None of this makes the model bad. It makes the table worth reading before the bar chart. And one line in the announcement decided what my test should look like: "The majority of the training data was synthetic." The models were pre-trained on generated processes — trends, seasonality, noise — then post-trained on a real-and-synthetic mix. A synthetic series is their home turf. The test the thread asked for Buried in the discussion was a protocol, from a commenter who clearly does this for a living: "To meaningfully test a forecasting model, use a data-generating process with a high signal-to-noise ratio where a classical method (empirical conditional distributions, i.e., counting) can capture most of the signal. Then check whether the model captures that signal too. If you only test on high-noise processes, any model looks" the same. So that is Test A. Test B is the opposite: a real series that did not exist when the models were uploaded — Paris daily maximum temperature from open-meteo, no API key, through yesterday. Test C is Test B with the context window pushed back three years. Three sizes (5M, 28M, 209M), CPU only, every forecast deterministic — I ran the whole script twice and diffed the outputs: byte-identical. Baselines are one line each: repeat the last value, the mean of the last seven, and for the seasonal series, repeat last week. Metrics: MAE, MASE (MAE scaled by the in-sample naive error, the same family of metric as the leaderboards), and how often the model's 10%–90% band actually contained the truth — which should be about 80% of the time if the uncertainty is honest. #!/usr/bin/env python3 """timestral_test.py — three tests a reader can rerun in minutes, no API key. Test A a series with a KNOWN generator (trend + weekly pattern + small noise). A counting method (seasonal naive) captures most of the signal. Does the foundation model capture it too? (protocol from the HN thread) Test B a REAL series nothing could have memorized: Paris daily max temperature, open-meteo archive, context May 1 -> Oct 5 2026, holdout Oct 6 -> Oct 19. Test C same series, same holdout, same models — three years of context instead of one summer. Only the history handed to the model changes. Run it: pip install "git+https://github.com/mistralai/timestral.git" python3 timestral_test.py # 5M + 28M + 209M, CPU """ import json import sys import urllib.request import numpy as np from timestral import TimestralForecaster MODELS = sys.argv[1:] or ["Timestral-5M", "Timestral-28M", "Timestral-209M"] H = {"A": 28, "B": 14} def mase(y, yhat, ctx, m): """MAE scaled by the in-sample seasonal-naive MAE (m = season length).""" return np.mean(np.abs(y - yhat)) / np.mean(np.abs(ctx[m:] - ctx[:-m])) def baselines(ctx, h, m): last = np.repeat(ctx[-1], h) mean7 = np.repeat(ctx[-7:].mean(), h) out = {"naive-last": last, "mean of last 7": mean7} if m > 1: # seasonal rows only when a season exists season = np.array([ctx[-m + (i % m)] for i in range(h)]) drift = (ctx[-1] - ctx[-1 - m]) / m # mean step over the last season out[f"seasonal-naive(m={m})"] = season out["seasonal-naive + drift"] = season + drift * (np.arange(h) + 1) return out def report(name, ctx, truth, m, models): h = len(truth) rows = {k: (v, None) for k, v in baselines(ctx, h, m).items()} for mdl in models: f = models[mdl].forecast(ctx, prediction_length=h) med = np.asarray(f.median).ravel() lo, hi = np.asarray(f.quantile(0.1)).ravel(), np.asarray(f.quantile(0.9)).ravel() rows[mdl] = (med, np.mean((truth >= lo) & (truth <= hi))) print(f"\n== {name} (context {len(ctx)} pts, horizon {h}, season m={m}) ==") print(f"{'method':<26}{'MAE':>8}{'MASE':>8}{'cov80':>8}") for k, (yhat, cov) in rows.items(): c = f"{cov:.2f}" if cov is not None else " -" print(f"{k:<26}{np.mean(np.abs(truth - yhat)):>8.3f}{mase(truth, yhat, ctx, m):>8.3f}{c:>8}") def main(): models = {n: TimestralForecaster.from_pretrained(f"mistralai/{n}", device="cpu") for n in MODELS} # Test A: known generator, high signal-to-noise rng = np.random.default_rng(7) n = 364 + H["A"] t = np.arange(n) dow = np.array([0.0, 2.0, 4.0, 8.0, 6.0, -4.0, -8.0]) y = 100 + 0.05 * t + dow[t % 7] + rng.normal(0, 1.0, n) report("TEST A known generator", y[:364], y[364:], 7, models) # Test B: real, fresh — Paris daily max temperature (ERA5 via open-meteo, no key) url = ("https://archive-api.open-meteo.com/v1/archive?latitude=48.85&longitude=2.35" "&start_date=2023-10-06&end_date=2026-10-19&daily=temperature_2m_max&timezone=UTC") d = json.load(urllib.request.urlopen(url))["daily"] temps = np.array(d["temperature_2m_max"], dtype=float) cut = d["time"].index("2026-10-06") short = d["time"].index("2026-05-01") print(f"\nopen-meteo: {len(temps)} days, {d['time'][0]} -> {d['time'][-1]}, holdout from {d['time'][cut]}") report("TEST B Paris daily max temp, 158-day context", temps[short:cut], temps[cut:], 1, models) # Test C: same series, same holdout, same models — three years of context instead of one summer report("TEST C Paris daily max temp, 3-year context", temps[:cut], temps[cut:], 1, models) if __name__ == "__main__": main() The output, verbatim: == TEST A known generator (context 364 pts, horizon 28, season m=7) == method MAE MASE cov80 naive-last 9.650 9.209 - mean of last 7 4.626 4.415 - seasonal-naive(m=7) 0.890 0.849 - seasonal-naive + drift 1.244 1.188 - Timestral-5M 0.896 0.855 0.64 Timestral-28M 0.862 0.823 0.64 Timestral-209M 0.851 0.812 0.68 open-meteo: 1110 days, 2023-10-06 -> 2026-10-19, holdout from 2026-10-06 == TEST B Paris daily max temp, 158-day context (context 158 pts, horizon 14, season m=1) == method MAE MASE cov80 naive-last 5.636 2.409 - mean of last 7 4.987 2.132 - Timestral-5M 5.785 2.473 0.43 Timestral-28M 6.540 2.796 0.43 Timestral-209M 6.489 2.774 0.43 == TEST C Paris daily max temp, 3-year context (context 1096 pts, horizon 14, season m=1) == method MAE MASE cov80 naive-last 5.636 2.678 - mean of last 7 4.987 2.370 - Timestral-5M 3.354 1.594 0.71 Timestral-28M 3.341 1.587 0.71 Timestral-209M 3.326 1.580 0.64 Test A — the known generator A year of daily data: a slow trend, a weekly pattern with a fixed shape, Gaussian noise one unit wide. The counting method — repeat last week — scores MASE 0.849, and the noise floor for this series is around 0.76, so there is not much room left to win. Timestral-5M ties the one-liner (0.855). The 209M takes 0.812, about four percent better, closing roughly a third of the remaining gap to the floor. The model captures the signal a human with a spreadsheet would capture. It does not transcend it. The quieter number is the coverage column. The 10%–90% band should contain the truth eight times in ten; it did so 64% to 68% of the time. On its own synthetic home turf, with noise that is literally Gaussian, the model's uncertainty is too narrow. That is not a knock on the point forecast. It is the number you would want before you wired the band into an alert. Test B — one summer of Paris Now the real series: 158 days of context, May 1 to October 5, forecast the next fourteen. Those fourteen days happened to be the moment Paris turned: 24.3 °C on the first day of the holdout, 12.4 °C on the last. The three Timestrals produced medians that went the other way — the 209M's path climbed from 23.7 to 24.9 °C across the two weeks, extrapolating the warm early-October spell upward. Every size lost to "repeat yesterday." The 80% band contained the truth on 6 of 14 days. Its lower edge never dropped below 18 °C; reality finished at 12. This is not a model being stupid. With 158 days of context, the series contains one rising-then-flat summer and no previous autumn. Nothing in the window says October falls. A univariate forecaster can only continue what the window shows it — and the window showed a warm week. Test C — three Octobers So I changed one thing: the context now starts in October 2023 — 1,096 days, two complete autumns inside the window — same holdout, same models, same baselines, same code path. The 209M's median now descends from 22.3 to 17.6 °C. MAE drops from 6.489 to 3.326 — a third better than the best baseline, which did not improve because baselines only look at the last few values anyway. Coverage rises from 43% to 64%; still under the 80% it should be, but the band's lower edge finally reaches 14 °C. And the family converges: 5M at 3.354, 28M at 3.341, 209M at 3.326. The checkpoint that is forty times smaller on disk forecasts this series as well as the flagship, once both see the seasons. On the leaderboard the gap between those two models is 0.047 MASE on GIFT-Eval; on fourteen days of weather with the right history, it is noise. !daigram stats The license line that is not in the announcement The announcement lists the license as "Modified MIT." The modification is in the LICENSE file on Hugging Face, clause 2, and it is one sentence: "You are not authorized to exercise any rights under this license if the global consolidated monthly revenue of your company (or that of your employer) exceeds $20 million (or its equivalent in another currency) for the preceding month." The next sentence refers to "This restriction in (b)" — there is no (b) in the license; the clauses are numbered 1 and 2. The code repository is Apache-2.0; the weights are not. One HN reader quoted the clause within hours; it does not appear anywhere on the announcement page. A revenue test no one can verify from the outside is the same control this series graded on QGIS: a rule enforced by the honesty of the person it restricts. That is not a complaint — most open-weight licenses are built this way — it is the rung. The sales address is in the same clause. What to steal - Run the one-line baseline first. Seasonal naive took one line and scored 0.849; the state-of-the-art model took 837 MB and scored 0.812. If your series is seasonal and clean, the gap you are paying for is four percent. - Read the margin column, not the bar. Every claim on the card is true. The headline margin is 0.003. Subtract the runner-up yourself; it takes a minute. - Check coverage before you ship the band. A point forecast that is 4% better and an 80% interval that is right 64% of the time are two different products. - The context is the model. One summer: the flagship lost to yesterday's temperature. Three years: the 20 MB model beat every baseline by a third. Before you shop for parameters, look at what you are feeding the window. Two honest limits Two series, one city, one fourteen-day holdout is an instrument, not a benchmark. GIFT-Eval aggregates hundreds of series; nothing here contradicts Mistral's table, and nothing here could. What the tests show is what an aggregate hides — the spread between one summer and three years on the same model — and the script is there so you can swap in your own series and see which case you are in. I used Timestral as a univariate, past-only forecaster — the simplest mode it supports. The model card lists known-future covariates and multivariate inputs; I fed it none, because the question was what the zero-shot model does with the series alone, and because that is how most first-time users will run it. A reader who hands it a weather forecast as a covariate is running a different test, and probably a better product. Your turn Three commands: pip install "git+https://github.com/mistralai/timestral.git", save the script, python3 timestral_test.py. The 5M downloads in seconds; the 209M is 837 MB. Then change two lines — the coordinates, or the URL to a series you actually care about — and post three numbers: the one-line baseline's MASE, the model's, and how often the 80% band held. If your series is like my summer, say so. If it is like my three years, say that. That is the forecasting review the leaderboard cannot write for you.

Mistral shipped a time-series foundation model today. I measured its latency — and its confidence. Mistral released its first time-series foundation models this morning. The family is called Timestral: four sizes from 5M to 209M parameters, probabilistic forecasts with 21 quantiles, context up to 32,768 steps, and a launch post claiming first place among pretrained zero-shot models on all three public forecasting benchmarks — GIFT-Eval, TIME, and fev-bench. The claim I cared about was the CPU one. From the announcement: > On a standard server CPU with 8 threads, forecasting one day ahead from three weeks of 15-minute history takes 10 ms with the 5M model and 140 ms with the 209M model. The weights are public (Modified MIT; the inference code is Apache 2.0), so I downloaded two of the four models and ran them. The point forecasts are genuinely good. The confidence intervals are where it falls apart. First, the names check out Before running anything, I verified the parameter counts from the actual weight files on Hugging Face: model file size bytes/4 (fp32) name says Timestral-5M 20.8 MB 5.21M params 5M Timestral-28M 111.3 MB 27.82M params 28M Timestral-123M 490.4 MB 122.61M params 123M Timestral-209M 837.3 MB 209.32M params 209M Honest labeling. The 5M config also confirms the headline numbers: 21 quantile knots from 0.01 to 0.99, context length 32768, patch size 32. Latency: the 10 ms claim assumes 8 threads. I have 2. I reproduced the announcement's exact setup — 2,016 steps of context (three weeks at 15-minute intervals), 96 steps of horizon (one day) — on this machine, a 2-vCPU VM, with torch pinned to 2 threads. Seven runs each: model Mistral claim (8 threads) mine, median (2 threads) mine, min Timestral-5M 10 ms 52.4 ms 35.9 ms Timestral-28M ~28 ms (implied) 315.7 ms 179.9 ms The implied 28M figure comes from the post's other claim, that the 28M model is five times faster than the 209M. On my box the 28M is 6.0x slower than the 5M, and the 5M at 52 ms against a 10 ms claim with a quarter of the threads is roughly thread-count arithmetic, not a scandal: 10 ms x 4 = 40 ms is the right ballpark for what I measured. The lesson is just that "10 ms on CPU" means "10 ms on an 8-thread server CPU." On the 2-core box that actually resembles a lot of production sidecars, budget 50 ms for the small model and a third of a second for the 28M — per series. If you're forecasting ten thousand sensors, that multiplication is your capacity plan. Output shape, for the record: (1, 1, 96, 21) — 96 steps, 21 quantiles, as advertised. Accuracy: the median beats the dumb baseline by 37% For a quality check I used the series everyone uses: monthly airline passengers, 1949–1960. Hold out the last 24 months, feed the first 120, forecast zero-shot with the 5M model, and compare its median against the two baselines that embarrass most fancy forecasters: MAE (passengers, thousands) Timestral-5M median 44.93 seasonal naive 71.25 drift 91.62 The first six medians track reality closely (348 vs 360, 332 vs 342, 375 vs 406). A 5M-parameter model that has never seen this series beating seasonal naive by 37% on MAE is a real result, and it's the part of the launch I'd believe without the leaderboards. Calibration: every single median was too low Here is the part the launch post doesn't measure. Timestral sells probabilistic forecasts — "teams can see how wide the uncertainty is, set alert thresholds that reflect it." So I checked the 80% band, the interval between its 0.1 and 0.9 quantiles: 80% interval coverage, 24 months 4 of 24 = 16.7% first 12 months 25.0% last 12 months 8.3% median bias over 24 months -44.93 (== the MAE: all 24 medians were below actual) mean interval width 68.5, growing 36 -> 101 across the horizon quantile crossings 0 An 80% band that contains the truth 17% of the time is not an uncertainty estimate; it's decoration. The failure mode is instructive: airline passengers is a strongly trending series, the model's median lags the trend by a nearly constant amount, and while its intervals do widen with horizon (36 to 101), they widen more slowly than the bias accumulates. Coverage doesn't just start bad — it decays, 25% to 8%, the further out you forecast. The one structural promise that held perfectly is quantile monotonicity: zero crossings in 24 x 21 outputs, exactly as the architecture claims. Two caveats, stated plainly. This is one series, monthly, with an unusually clean trend — it is not GIFT-Eval, and Mistral's benchmark results are submitted to public leaderboards where anyone can check them. And a model pre-trained mostly on synthetic data (their post is upfront about this) may simply have seen fewer relentlessly compounding trends than the real world serves. But their own launch post motivates the model with capacity planning and risk thresholds, and those are exactly the use cases where a miscalibrated band is worse than no band: the point forecast tells you 348, the band tells you not to worry, and reality files 360, 342, 406 in a row, always on the same side. Verdict Believe the latency, with a thread-count asterisk. Believe the point forecasts — a 37% MAE win over seasonal naive, zero-shot, from the 5M model is not nothing. Do not set an alert threshold on the quantiles until you've measured coverage on your own series. That measurement takes eleven lines of code and, today, it was the difference between the launch post and the product. Sources: Mistral's announcement, the inference repo, weights on Hugging Face under mistralai/Timestral-*. All measurements mine, on a 2-vCPU VM, torch 2.9.1 CPU, 2 threads; I ran the 5M and 28M models, not the 123M or 209M.

Testei o Timestral (Mistral) zero-shot na carga horária do ONS: previsão do dia seguinte em 28 dias Em 15/10 a Mistral lançou o Timestral, uma família de modelos de fundação para séries temporais (5M, 28M, 123M e 209M parâmetros), com previsão probabilística e inferência em CPU. No Hacker News teve bastante gente duvidando que esse tipo de modelo funcione em dado real, então fui testar com um dado público brasileiro antes de opinar. Contexto - Segundo a Mistral, o 209M fica em primeiro entre os modelos pré-treinados zero-shot no GIFT-Eval, no TIME e no fev-bench. A saída são 21 quantis por passo, com contexto de até 32.768 passos, e aceita covariáveis só do passado e covariáveis conhecidas no futuro. - O código de inferência é Apache 2.0. Os pesos usam uma "Modified MIT" com uma condição: "You are not authorized to exercise any rights under this license if the global consolidated monthly revenue of your company (or that of your employer) exceeds $20 million". Acima disso, só com licença comercial. O que eu rodei - Dado: ONS, Curva de Carga Horária (dados abertos), carga de energia em MWmed por hora, subsistemas N, NE, S e SE/CO, de 01/2025 a 17/10/2026. 15.720 horas, nenhuma faltando. - Modelos: Timestral-5M e Timestral-28M, sem treino nem ajuste. CPU com 8 threads, sem GPU. Não rodei o 123M nem o 209M por falta de memória na máquina. - Contexto de 16 semanas (2.688 h) antes de cada corte. Os 4 subsistemas como séries separadas. - D+1: 28 cortes à 0h, de 20/09 a 17/10, prevendo as 24 horas do dia. D+7: 4 cortes semanais, 168 horas. - Referências: dia anterior, mesmo horário da semana anterior e média das 4 últimas semanas no mesmo horário. - Métrica: MAPE por subsistema e janela, média simples. E a cobertura do intervalo de 80% (quantis 0,1 a 0,9). - Variante: feriado nacional como covariável conhecida no futuro, um 0 ou 1 por hora. Resultados (D+1, 28 dias x 4 subsistemas) - Timestral-28M: 2,42% (2,12% com a covariável de feriado) - Timestral-5M: 2,55% (2,53% com a covariável) - Média das 4 últimas semanas: 4,07% - Semana anterior: 4,41% - Dia anterior: 6,23% - Cobertura do intervalo de 80%: 80,4% no 28M e 81,1% no 5M. - Dia a dia contra a média de 4 semanas, o 28M ganhou em 26 de 28 dias (28 de 28 com a covariável). - No D+7, a diferença cai: 28M 3,41% (3,30% com covariável), 5M 3,69%, média de 4 semanas 4,07%. Onde errou - 12/10 (segunda, feriado): sem a covariável, o 28M previu dia útil e errou 11,43% na média dos 4 subsistemas. Com a covariável, 4,19%. No Sul foi de 18,6% para 4,5%. No Sudeste às 14h, o real foi 42.610 MWmed; sem o aviso ele previu 51.540, com o aviso, 41.918. Nesse dia, repetir o domingo anterior também errou 4,2%: sem a covariável, o modelo perdeu até para a referência mais simples. - No 5M a covariável não ajudou (10,9% sem, 11,2% com). No contexto de 16 semanas só havia um feriado, o 7/9. - 16/10: todos erraram entre 6,1% e 6,7%, modelo e referências. Não fui atrás do motivo. - Rodei o corte de 12/10 três vezes: saída idêntica nas três. O que isso é (e o que não é) - É um backtest meu, zero-shot, com dado público e referências ingênuas. Não é benchmark. - Não comparei com a carga programada do ONS, com um modelo ajustado (por exemplo, gradient boosting com calendário) nem com Chronos-2 ou TimesFM. - Não sei se dados do ONS entraram no treino do Timestral. A Mistral diz que o pós-treino usou uma mistura de dados reais e sintéticos. - O tempo que medi não é controlado: a máquina era compartilhada. O 28M levou cerca de 0,6 s por chamada (4 séries, 24 h de horizonte) sem covariável e cerca de 3 s com. Onde eu fico Como ponto de partida sem treino, foi bem melhor que as referências ingênuas, e informar o feriado fez diferença no 28M. Mas bater referência ingênua é o mínimo. O próximo teste justo seria contra a carga programada do ONS e contra um modelo ajustado com calendário. E, para quem trabalha em empresa grande, a licença dos pesos decide antes do MAPE. Links - Anúncio da Mistral: mistral.ai - Código: mistralai/timestral - Licença dos pesos: huggingface.co - ONS, Curva de Carga Horária: dados.ons.org.br - Discussão no HN: news.ycombinator.com Perguntas 1. Quem trabalha com previsão de demanda ou de carga: vocês já testaram algum modelo de fundação (Timestral, Chronos, TimesFM) contra o que roda em produção? 2. Para um teste justo aqui, qual referência vocês usariam: a carga programada do ONS, um gradient boosting com calendário ou outra? 3. Como vocês tratam feriado e ponte em previsão horária: covariável binária, tipo de dia ou série separada?

> Or are you stuck forever querying the Timestral server "We have published a GitHub repository so you can run Timestral on your own data." [1] mistralai/timestral

interesting. The github repo (mistralai/timestral ) says the license is Apache 2. Where does the 20M$ revenue limit comes from?