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.

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 Enter fullscreen mode Exit fullscreen mode 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.

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 Enter fullscreen mode Exit fullscreen mode 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.

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 Enter fullscreen mode Exit fullscreen mode 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.

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 Enter fullscreen mode Exit fullscreen mode 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.

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.

Expand Joel Maniego Joel Maniego Joel Maniego Follow Alone we can do so little; together we can do so much. Location Philippines Joined Sep 22, 2026 • Oct 20 Dropdown menu Copy link Hide That was a good and valuable judgement.