Mistral-Modell Timestral läuft auf CPUs und nutzt Modified-MIT-Lizenz mit Umsatzgrenze
Mit Timestral bringt Mistral ein Modell, das ohne teure GPUs auf klassischen CPUs betrieben werden kann. Die angepasste MIT-Lizenz erlaubt die kommerzielle Nutzung nur bis zu monatlichen Umsätzen von 20 Millionen Dollar.
Mistrals neues Modell schreibt kein einziges Wort. Timestral, veröffentlicht am 15. Oktober 2026, liest eine Spalte von Zahlen und sagt voraus, wohin sie sich wahrscheinlich als Nächstes bewegen werden, mit einem Unsicherheitsbereich um die Schätzung herum. Mistral sagt, seine größte Version mit 209M Parametern belege "auf allen drei wichtigsten öffentlichen Benchmarks des Bereichs den ersten Platz" und dass sie "zur Inferenz keine GPU benötigt" (Mistral).
Wenn Sie Kapazitätsplanung, Kostenprognosen oder Anomalie-Warnungen auf Basis einer Metrik-Tabelle betreiben, ist das eine nützliche Veröffentlichung. Dann öffnen Sie die Lizenz. Die Gewichte werden unter dem ausgeliefert, was Mistral eine Modified-MIT-Lizenz nennt, und die Modifikation ist eine Umsatzgrenze: Wenn der weltweite Monatsumsatz Ihres Unternehmens im Vormonat über 20 Millionen Dollar lag, ist eine Nutzung nicht autorisiert.
Timestral ist eine Familie von vier Zeitreihen-Foundation-Modellen, die sich eine Architektur und Trainingsrezeptur teilen (Mistral). "Foundation-Modell" bedeutet hier Zero-Shot: Man übergibt ihm die Historie, und es prognostiziert, ohne vorher auf den eigenen Daten trainiert zu werden. Das GitHub-README listet die Checkpoints auf:
Die Modellkarte des 209M-Modells gibt die Form des Ganzen wieder. Es liest bis zu 32.768 vergangene Schritte und prognostiziert bis zu 1.024 Schritte pro Forward-Pass. Jede Prognose umfasst 21 Quantile von 0,01 bis 0,99, was jedem Schritt ein Band wahrscheinlicher Werte verleiht. Es nimmt eine oder mehrere Zeitreihen gleichzeitig entgegen, dazu Kovariaten, die entweder nur für die Vergangenheit bekannt sind oder bis in die Zukunft bekannt sind (Feiertage, geplante Aktionen, ein terminiertes Deployment). Fehlende Werte werden als NaN eingegeben.
Auf einem Server-CPA mit 8 Threads berichtet Mistral für die Prognose eines Tages im Voraus aus drei Wochen 15-Minuten-Historie 10 ms für das 5M-Modell und 140 ms für das 209M, wobei das 28M-Modell fünfmal schneller ist als das 209M (Mistral). Mistrals Dokumentation listet Timestral 1.0 als "Public Preview" und nennt keinen API-Preis, daher lädt man es derzeit herunter und betreibt es selbst.
Jede Zahl im Folgenden stammt von Mistral. Auf der Modellkarte heißt es, ein Technical Report sei "in Kürze verfügbar", und bis er erscheint, kann man die Methode nicht überprüfen.
Auf der Vergleichstabelle der Modellkarte erzielt Timestral-209M ein MASE von 0,658 auf GIFT-Eval, gegenüber 0,661 für t0-gamma, 0,667 für TimesFM-3 und 0,698 für Chronos-2 (niedriger ist besser). Beim SQL Skill Score von fev-bench erreicht es 50,39, gegenüber 49,42 für t0-gamma und 47,28 für Chronos-2 (höher ist besser). Es führt jede Zeile an, aber die Abstände zum Zweitplatzierten sind gering (Modellkarte).
Die kleineren Modelle sind für die meisten Teams der interessantere Teil. Das 28M-Modell erzielt 0,678 auf GIFT-Eval MASE und 0,638 auf TIME MASE, beide vor Chronos-2 mit 0,698 und 0,662, wenn auch hinter t0-gamma und TimesFM-3 auf GIFT-Eval und eine Haarbreite hinter t0-gammas 0,637 auf TIME (Modellkarte). Mistral beschreibt Chronos-2 als etwa viermal größer (Mistral).
Mistral sagt, die Ergebnisse stammen von einem einzelnen Checkpoint ohne Ensembling, eingereicht bei den GIFT-Eval- und TIME-Leaderboards, und dass die meisten Trainingsdaten synthetisch seien, sodass "nichts, was wir backtesten, während des Pre-Trainings gesehen wurde" (Mistral). Das adressiert Leakage, die übliche Sorge bei Forecasting-Benchmarks. Der Technical Report muss das noch belegen.
Timestral liefert ein Band aus 21 Quantilen pro Schritt, und Mistral sagt, dafür wird keine GPU benötigt.
Der Inferenz-Code ist Apache 2.0. Die Gewichte nicht. Das README sagt, sie würden "separat auf dem Hugging Face Hub unter einer Modified-MIT-Lizenz vertrieben", und in genau dieser Lizenz liegt der Haken.
Die Gewährung liest sich wie MIT: Nutzung, Kopieren, Modifizieren, Zusammenführen, Veröffentlichen, Verbreiten, Unterlizenzieren und Verkaufen. Dann fügt die Lizenzdatei hinzu, dass man "nicht berechtigt ist, Rechte unter dieser Lizenz auszuüben, wenn der weltweit konsolidierte Monatsumsatz Ihres Unternehmens" (oder Ihres Arbeitgebers) "20 Millionen Dollar (oder den Gegenwert in einer anderen Währung) im Vormonat übersteigt." Die Einschränkung gilt für das Modell "sowie alle Derivate, Modifikationen oder kombinierten Werke." Unternehmen oberhalb der Grenze können bei Mistral eine kommerzielle Lizenz anfragen, die nach alleinigem Ermessen gewährt werden kann, oder Mistrals gehostete Dienste nutzen. Die Lizenz des 5M-Modells enthält dieselbe Grenze von 20 Millionen Dollar, ein kleinerer Checkpoint ist also kein Weg daran vorbei.
Wie sich das auswirkt, so meine Lesart (ich bin kein Anwalt):
Mistrals Ankündigung bewirbt Timestral für On-Prem-, VPC- und Air-Gapped-Deployments (Mistral). Liest man das neben der Umsatzgrenze: Die Großunternehmen, die am ehesten Air-Gapped-Forecasting benötigen, liegen oft über 20 Millionen Dollar pro Monat und bräuchten also die kommerzielle Lizenz. Das ist meine Lesart der beiden Dokumente, nicht etwas, das Mistral gesagt hat.
Die Gewichte sind frei nutzbar, bis der Monatsumsatz Ihres Unternehmens die 20 Millionen Dollar übersteigt.
Wenn Sie unter der Grenze liegen, ist das Ausprobieren schnell erledigt. Das Paket ist nicht auf PyPI. Das README installiert es von GitHub und verlangt Python 3.10+ und torch 2.4+:
pip install git+https://github.com/mistralai/timestral.git Hier eine Variante des README-Quickstarts für die Kapazitätsplanung. Sie nimmt stündliche Anfragezahlen an und prognostiziert die nächsten 168 Stunden mit dem 28M-Modell:
import numpy as np from timestral import TimestralForecaster # Ein Wert pro Zeile: Anfragen pro Stunde, älteste zuerst. history = np. loadtxt ( " requests_per_hour.txt " ) model = TimestralForecaster. from_pretrained ( " mistralai/Timestral-28M " ) week = model. forecast ( history, prediction_length = 168 ) p50 = week. median p90 = week. quantile ( 0.9 ) print ( " peak p50: ", p50. max ()) print ( " peak p90: ", p90. max ()) Dimensionieren Sie Server nach dem p90, nicht nach dem Median. Die tatsächliche Last liegt in der Hälfte der Fälle über dem Median.
Ein paar Optionen aus dem README sollte man kennen, bevor man das in einen Job einbaut. from_pretrained nimmt ein Revision-Argument entgegen, sodass man einen Commit fixieren kann, solange sich das Modell in der Public Preview befindet. local_files_only=True (oder HF_HUB_OFFLINE=1) sorgt dafür, dass nur aus dem lokalen Cache gelesen wird, was auf einem abgeschotteten Rechner sinnvoll ist. Bekannte zukünftige Ereignisse gehen in known_covariates ein, mit der Form (B, C_known, T + prediction_length), und eine Zeile nur aus 0en und 1en wird als Indikator behandelt, so würde man etwa einen Launch-Tag markieren.
Das README ist bezüglich der Grenzen offen. Kontext über 32.768 Schritte hinaus wird abgeschnitten, wobei die neuesten erhalten bleiben. Horizonte über 1.024 Schritte werden blockweise prognostiziert, und "der Median jedes Blocks wird als Kontext zurückgespeist", sodass das ferne Ende einer langen Prognose auf früheren Schätzungen aufbaut. Kovariaten beeinflussen die Prognose, werden aber selbst nie prognostiziert. Das Projekt akzeptiert keine Pull Requests; Issues werden "nach bestem Bemühen" bearbeitet (README).
Ich habe Timestral selbst nicht ausgeführt, daher kann ich nicht sagen, wie es auf Ihren Metriken abschneidet. Der faire Test ist aber günstig: Backtesten Sie es auf einem Monat Ihrer eigenen Historie gegen das, was Sie derzeit nutzen, und prüfen Sie dann, ob Ihr Unternehmen unter der Grenze von 20 Millionen Dollar liegt, bevor jemand darauf aufbaut.
Würde eine Umsatzgrenze auf "MIT"-Gewichten Sie davon abhalten, ein Modell bei der Arbeit einzuführen, oder erscheint Ihnen eine kostenlose Stufe für kleinere Unternehmen als fairer Kompromiss? Schreiben Sie es in die Kommentare.
Forecasting der Last ist nur die Hälfte der Kapazitätsplanung. Die andere Hälfte besteht darin zu wissen, was man mit der Zahl anfangen soll: wo zu cachen ist, wann zu sharden ist, wie viel Puffer ein p90 kaufen sollte. Der System Design Pocket Guide: Fundamentals behandelt diese Bausteine in einem kurzen, praxisnahen Format.
Ich baue außerdem Hermes IDE, eine freie, quelloffene IDE, die Claude Code, Codex und andere Coding-Agents nebeneinander ausführt, wobei jede Aufgabe ihren eigenen Branch und Worktree erhalten kann, auf macOS, Windows und Linux. Markieren Sie es auf GitHub mit einem Stern, wenn das nützlich klingt.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Mistral's new model doesn't write a single word. Timestral, released on October 15, 2026, reads a column of numbers and tells you where it is likely to go next, with a range around the guess. Mistral says its largest version, at 209M parameters, "ranks first on all three of the field's main public benchmarks," and that it "does not need a GPU at inference" ( Mistral ).
If you run capacity planning, cost forecasts or anomaly alerts off a metrics table, that is a useful release. Then you open the license. The weights ship under what Mistral calls a Modified MIT license, and the modification is a revenue cap: if your company's global monthly revenue went past $20 million in the preceding month, you are not authorized to use it.
Timestral is a family of four time-series foundation models that share one architecture and training recipe ( Mistral ). "Foundation model" here means zero-shot: you hand it history and it forecasts, with no training on your data first. The GitHub README lists the checkpoints:
The 209M model card gives the shape of the thing. It reads up to 32,768 past steps and forecasts up to 1,024 steps per forward pass. Every forecast is 21 quantiles, from 0.01 to 0.99, which gives each step a band of likely values. It takes one series or several at once, plus covariates that are either known only for the past or known into the future (holidays, planned promotions, a scheduled deploy). Missing values go in as NaN.
On a server CPU with 8 threads, forecasting one day ahead from three weeks of 15-minute history, Mistral reports 10 ms for the 5M model and 140 ms for the 209M, with the 28M five times faster than the 209M ( Mistral ). Mistral's docs list Timestral 1.0 as a "Public Preview" and name no API price, so for now you download it and run it yourself.
Every number below comes from Mistral. The model card says a tech report is "coming soon," and until it lands you can't check the method.
On the card's comparison table, Timestral-209M scores a MASE of 0.658 on GIFT-Eval, against 0.661 for t0-gamma, 0.667 for TimesFM-3 and 0.698 for Chronos-2 (lower is better). On fev-bench 's SQL skill score it posts 50.39, against 49.42 for t0-gamma and 47.28 for Chronos-2 (higher is better). It leads every row, but the margins over the runner-up are small ( model card ).
The smaller models are the more interesting part for most teams. The 28M scores 0.678 on GIFT-Eval MASE and 0.638 on TIME MASE, both ahead of Chronos-2's 0.698 and 0.662, though behind t0-gamma and TimesFM-3 on GIFT-Eval and a hair behind t0-gamma's 0.637 on TIME ( model card ). Mistral describes Chronos-2 as about four times larger ( Mistral ).
Mistral says the results come from a single checkpoint with no ensembling, submitted to the GIFT-Eval and TIME leaderboards, and that most training data is synthetic, so "nothing we backtest was seen during pre-training" ( Mistral ). That addresses leakage, the usual worry with forecasting benchmarks. The tech report still has to back it.
Timestral returns a band of 21 quantiles per step, and Mistral says it needs no GPU to do it.
The inference code is Apache 2.0. The weights are not. The README says they are "distributed separately on the Hugging Face Hub under a Modified MIT license," and that license is where the catch sits.
The grant reads like MIT: use, copy, modify, merge, publish, distribute, sublicense and sell. Then the license file adds that you are "not authorized to exercise any rights under this license if the global consolidated monthly revenue of your company" (or your employer's) "exceeds $20 million (or its equivalent in another currency) for the preceding month." The restriction covers the model "and any derivatives, modifications, or combined works." Companies above the line can ask Mistral for a commercial license, which it may grant at its sole discretion, or use Mistral's hosted services. The 5M model's license carries the same $20 million cap, so a smaller checkpoint isn't a way around it.
How that plays out, as I read it (I'm not a lawyer):
Mistral's announcement pitches Timestral for on-prem, VPC and air-gapped deployment ( Mistral ). Read that next to the cap. The large enterprises most likely to want air-gapped forecasting are often the ones above $20 million a month, so they need the commercial license. That's my reading of the two documents, not something Mistral has said.
The weights are free to use until your company's monthly revenue crosses $20 million.
If you're under the line, trying it is short. The package isn't on PyPI. The README installs it from GitHub and asks for Python 3.10+ and torch 2.4+:
pip install git+https://github.com/mistralai/timestral.git Enter fullscreen mode Exit fullscreen mode Here's a capacity-planning version of the README's quickstart. It takes hourly request counts and forecasts the next 168 hours with the 28M model:
import numpy as np from timestral import TimestralForecaster # One value per line: requests per hour, oldest first. history = np. loadtxt ( " requests_per_hour.txt " ) model = TimestralForecaster. from_pretrained ( " mistralai/Timestral-28M " ) week = model. forecast ( history, prediction_length = 168 ) p50 = week. median p90 = week. quantile ( 0.9 ) print ( " peak p50: ", p50. max ()) print ( " peak p90: ", p90. max ()) Enter fullscreen mode Exit fullscreen mode Size servers for the p90, not the median. Actual load lands above the median half the time.
A few options from the README are worth knowing before you put this in a job. from_pretrained takes a revision argument, so pin a commit while the model is in public preview. local_files_only=True (or HF_HUB_OFFLINE=1 ) makes it read only from the local cache, which suits a locked-down box. Known future events go in known_covariates, shaped (B, C_known, T + prediction_length), and a row of only 0s and 1s is treated as an indicator, which is how you'd flag a launch day.
The README is direct about the limits. Context above 32,768 steps is cut, keeping the most recent. Horizons past 1,024 steps are forecast block by block, and "each block's median is fed back as context," so the far end of a long forecast is built on earlier guesses. Covariates condition the forecast and are never forecast themselves. The project doesn't accept pull requests; issues are handled "on a best-effort basis" ( README ).
I haven't run Timestral myself, so I can't tell you how it does on your metrics. The fair test is cheap, though: backtest it on a month of your own history against whatever you use now, then check whether your company sits under the $20 million line before anyone builds on it.
Would a revenue cap on "MIT" weights stop you from adopting a model at work, or does a free tier for smaller companies seem like a fair trade? Tell me in the comments.
Forecasting load is only half of capacity planning. The other half is knowing what to do with the number: where to cache, when to shard, how much headroom a p90 should buy you. The System Design Pocket Guide: Fundamentals covers those building blocks in a short, practical format.
I also build Hermes IDE, a free, source-available IDE that runs Claude Code, Codex and other coding agents side by side, where each task can get its own branch and worktree, on macOS, Windows and Linux. Star it on GitHub if that sounds useful.