Zeitreihen-Foundation-Models: Eigenes Training wird obsolet

Hier eine Behauptung, für die man vor fünf Jahren in jedem Forecasting-Team ausgelacht worden wäre: Bei den meisten Zeitreihenproblemen ist es inzwischen Zeitverschwendung, ein Modell mit den eigenen Daten zu trainieren. Ein Time-Series-Foundation-Model, trainiert auf Millionen von Reihen, die du nie zu Gesicht bekommst, aus Domänen, in denen du nicht arbeitest, schlägt deine sorgfältig getunte Pipeline vermutlich zero-shot, und zwar in der Zeit, die ein einziger Forward-Pass auf einer CPU braucht. Timestral von Mistral, diese Woche veröffentlicht in Größen von 5M bis 209M Parametern, ist der neueste und stärkste Beleg dafür, dass das Feld hier angekommen ist. Und ich glaube, viele Praktiker werden sich aus völlig nachvollziehbaren, meist aber falschen Gründen gegen diese Schlussfolgerung wehren.

Was ein Time-Series-Foundation-Model eigentlich ist

Der Vergleich mit LLMs ist hilfreich, aber nur, wenn man über die Oberfläche hinausgeht. Ein großes Sprachmodell wird auf einem riesigen Textkorpus vortrainiert, damit es auf Aufgaben und Formulierungen generalisieren kann, die es nie gesehen hat. Ein Time-Series-Foundation-Model (TSFM) macht dasselbe mit kontinuierlichen Signalen: Es wird auf einer massiven, vielfältigen Sammlung von Reihen vortrainiert, echten und synthetischen, sodass es die wiederkehrende Grammatik temporaler Daten lernt. Trends, Saisonalität, Regimewechsel, Mean Reversion, Rauschen in allen Varianten. Wenn du ihm deinen Sensor-Stream oder deine Verkaufshistorie gibst, lernt es nicht von null; es erkennt.

Dieses letzte Wort ist der ganze Trick, und es erklärt, was mich beim ersten Lesen irritiert hat: Wie kann ein Modell, das überwiegend auf synthetischen Daten trainiert wurde, Modelle schlagen, die mit echten Daten trainiert wurden? Weil die synthetischen Generatoren so gebaut sind, dass sie Prozesse mit kohärenter Dynamik erzeugen: realistische Kombinationen aus Trend, Saisonalität und Rauschen, dazu nichtlineare Abhängigkeiten zwischen Reihen. Das Modell lernt einen enormen Prior darüber, wie temporales Verhalten aussehen kann. Deine echte Zeitreihe, so eigenartig du sie auch findest, ist mit ziemlicher Sicherheit eine Neukombination von Mustern, die es schon millionenfach gesehen hat.

Das Trainingsrezept von Timestral macht das konkret. Zuerst großskaliges Vortraining auf rein synthetischen Daten mit einem Kontext von 8.192 Zeitschritten. Danach Post-Training auf einer Mischung aus echten und synthetischen Daten, wobei der Kontext auf 32.768 Schritte erweitert wird. Das Ziel ist ein Pinball-Loss über 21 Quantile. Das Modell gibt also keinen Punktschätzer aus, sondern eine vollständige Unsicherheitsverteilung. Du bekommst eine Prognose mit ehrlichen Fehlerbalken statt einer einzelnen, selbstbewussten Zahl.

Ein architektonisches Detail, das du dir für dein mentales Modell merken solltest: Timestral verwendet das, was Mistral „decoupled horizon forecasting“ nennt. Frühere kausale Decoder wie TimesFM maskieren die vorherzusagenden Werte. Das ist einfach, aber verschwenderisch, denn maskierte Werte werden als Kontext unsichtbar, sodass jede Prognose den Input für spätere Prognosen verschlechtert. Timestral behält die volle Historie in der Sequenz und fügt gelernte Forecast-Tokens hinzu, die diese Historie lesen. Jeder beobachtete Wert dient gleichzeitig als Trainingsziel und als Kontext. Das ist die Art kleiner struktureller Korrektur, die nicht dramatisch klingt und bei großer Skalierung enorm viel ausmacht.

Zero-shot-Prognosen: Warum sie deine Pipeline pro Reihe schlagen

Das stärkste Argument für TSFMs ist nicht die Benchmark-Rangliste, sondern die Form realer Forecasting-Arbeit. Kaum jemand prognostiziert eine einzelne Reihe. Du prognostizierst zehntausend. Ein Händler prognostiziert die Nachfrage pro SKU und Filiale. Ein Plattform-Team prognostiziert die Latenz pro Service und Region. Eine Industrieanlage hat Tausende Sensoren über Hunderte Anlagen verteilt. Die klassischen Optionen sind alle schlecht: ein ARIMA pro Reihe anpassen und zusehen, wie die meisten scheitern, weil jede Reihe nur wenig Historie hat, oder ein globales Gradient-Boosting-Modell trainieren und in Feature Engineering und Skalenunterschieden zwischen den Reihen versinken.

Ein TSFM umgeht dieses Dilemma. Ein Checkpoint, kein Fitting pro Reihe, und das reihenübergreifende Wissen ist bereits im Vortraining verankert, statt allein aus deinen Daten herausgearbeitet werden zu müssen. Deshalb sind Praktiker, die Forecasting tatsächlich im großen Maßstab betreiben, oft die am wenigsten skeptischen Befürworter dieser Modelle. Die Alternative ist nicht ein eleganter, handgetunter Ansatz, sondern ein Haufen AutoARIMA-Jobs, die stundenlang laufen und bei den seltsamen fünf Prozent der Reihen, die am meisten zählen, stillschweigend kaputtgehen.

Der Effizienzaspekt hat mich am meisten überrascht. Timestrals größtes Modell hat 209 Mio. Parameter, winzig nach LLM-Maßstäben, und braucht zur Inferenz keine GPU. Auf einem handelsüblichen 8-Thread-Serverprozessor dauert eine Prognose für einen Tag voraus, basierend auf drei Wochen 15-Minuten-Daten, 10 ms mit dem 5M-Modell und 140 ms mit dem 209M-Modell. Das 123M-Modell liegt beim Benchmark-Score innerhalb von 0,2 % des großen Modells, bei drei Vierteln der Latenz. Das spiegelt, was bei Sprachmodellen passiert ist, wo sich das Interessante zu kleinen, schnellen Stufen verlagert hat, dieselbe Dynamik, über die ich in unserem Artikel über Flash-Tier-LLMs geschrieben habe: Das Frontier-Modell bekommt die Schlagzeilen, das kleine effiziente Modell betreibt das Geschäft.

Und die Wirtschaftlichkeit potenziert sich. Zehntausend Reihen mal eine tägliche Prognose mit jeweils zehn Millisekunden bedeuten: Deine gesamte Forecasting-Last passt in eine Mittagspause auf einer unscheinbaren CPU-Kiste. Keine GPU-Cluster, kein verteilter Trainingsjob, keine MLOps-Heldentaten. Vor fünf Jahren dauerte es Monate, ein brauchbares Forecasting-Modell zu bauen und auszuliefern. Heute ist es ein Nachmittag, und ein großer Teil davon ist Datenaufbereitung, nicht Modellierung.

Kovariaten sind das eigentliche Feature und der eigentliche Haken

Hier gebe ich den Skeptikern recht, denn die schärfste Kritik an TSFMs stimmt: Bei vielen Problemen ist die Historie der Zielreihe nur ein Teil der Information. Wenn du Stromnachfrage modellierst, sind Wetterprognose, Feiertagskalender und Preisplan keine Würze für die Prognose, sondern sie sind die Prognose. Ein Modell, das deine sorgfältig kuratierten Kovariaten als sanfte Qualitätsverbesserung behandelt, wird dich genau dann blamieren, wenn sich das Regime ändert, und genau dann brauchst du es.

Timestrals Antwort ist die kovariatenbewusste Attention, und das Design ist prinzipientreuer, als es klingt. Jede Eingabereihe bekommt eine Rolle: Ziel, reine Vergangenheits-Kovariate oder bekannte Zukunfts-Kovariate. Bekannte Zukunfts-Kovariaten wie Produktionspläne, geplante Abschaltungen und Wetterprognosen sind über das gesamte Fenster sichtbar, während Ziele kausal bleiben und Information nur von den Kovariaten zu den Zielen fließt. Diese letzte Einschränkung ist die wichtige: Sie erlaubt dem Modell, auf die geplante Lastzunahme der nächsten Woche zu konditionieren, ohne die eigene Zukunft der Zielreihe in die Prognose einsickern zu lassen. Datenleckage über Kovariaten gehört zu den klassischen stillen Fehlerquellen in Forecasting-Systemen, und die Informationsrichtung in die Attention-Maske zu kodieren, ist eine saubere Art, das zu verhindern.

Kategorische Kovariaten werden ebenfalls sauber behandelt: Ein Maschinenzustand wie läuft, Leerlauf oder in Wartung wird als Kategorie eingespeist und nicht in eine willkürliche Ganzzahl gepresst, die eine erfundene Reihenfolge erzwingt. Wer schon einmal zugesehen hat, wie ein Baummodell lernt, dass „Zustand 3“ irgendwie größer ist als „Zustand 2“, wird das zu schätzen wissen.

Aber beachte, was das in der Praxis bedeutet: Die Qualität eines TSFM-Einsatzes wird jetzt durch die Qualität deiner Kovariaten-Pipelines begrenzt, nicht durch dein Modell. Ist dein Wetterfeed veraltet, fehlen im Feiertagskalender regionale Feiertage und hat niemand den Wartungsplan in ein maschinenlesbares Format gebracht, kann das Modell dich nicht retten. Die Modellierung ist zur Massenware geworden, die Datentechnik nicht. Plane deinen Aufwand entsprechend.

Benchmarks und warum du auf deinem eigenen Signal testen solltest

Auf den drei wichtigsten öffentlichen Benchmarks, GIFT-Eval, TIME und fev-bench, belegt Timestrals 209M-Modell unter den vortrainierten Zero-shot-Modellen den ersten Platz, mit einem einzigen Checkpoint und ohne Ensembling. Das 28M-Modell soll Chronos-2 schlagen, das etwa viermal so groß ist. Das sind wirklich starke Ergebnisse, und dass jede Modellgröße der Familie auf der Pareto-Front von Genauigkeit gegen Größe liegt, deutet darauf hin, dass das Rezept und nicht nur die Skalierung die Arbeit macht.

Nun die nötigen Einschränkungen. Forecasting-Benchmarks haben ein tiefes methodisches Problem: Viele Reihen darin sind hochverrauscht und signalarm, sodass nahezu jedes vernünftige Modell ungefähr gleich abschneidet, weil es kaum Signal gibt, das man erfassen könnte. Mittelt man Scores über Hunderte solcher Reihen, werden echte Unterschiede auf winzige Abstände zusammengedrückt. So entstehen Marketingcharts, in denen eine Verbesserung um 0,03 wie eine fünffache Lücke aussieht. Das ist eine konkrete Ausprägung eines allgemeinen Übels, über das wir schon geschrieben haben: Benchmarks verfehlen systematisch die Arbeit, auf die es ankommt, und Forecasting-Benchmarks verfehlen sie auf eine besonders messbare Weise.

Der bessere Test, und einen, den du selbst durchführen kannst, besteht darin, Evaluationsreihen mit bekanntem, hohem Signal-Rausch-Verhältnis zu konstruieren, bei denen eine einfache Methode wie empirische bedingte Verteilungen den größten Teil des Signals erfassen kann, und zu prüfen, ob das Foundation Model es ebenfalls erfasst. Dann erhöhst du das Rauschniveau schrittweise und beobachtest, wo die Leistung nachlässt. Ein Modell, das auf verrauschten Benchmarks nach SOTA aussieht, in sauberen Regimen aber offensichtliches Signal liegen lässt, sagt dir etwas, das die Rangliste nicht verrät.

Auf verrauschten Daten sehen alle Modelle gleich aus. Sie trennen sich erst, wenn es echtes Signal gibt, also teste dort, wo das Signal ist.

Wo klassische Methoden noch gewinnen

Meine eingangs aufgestellte Behauptung braucht ehrliche Grenzen, also hier sind sie. Es gibt echte Fälle, in denen du nicht zu einem Foundation Model greifen solltest.

• Du brauchst die Gleichungen, nicht nur die Ausgaben. Wenn du Netzbetreiber oder Regelungstechniker bist, brauchst du oft ein interpretierbares dynamisches Modell mit Parametern von physikalischer Bedeutung, die du nachvollziehen, stresstesten und einem Regulierer vorlegen kannst. Ein TSFM ist eine Blackbox: y = F(x, params) ohne lesbare Struktur. Ein gefittetes State-Space- oder SINDy-artiges Modell gibt dir etwas, das ein neuronales Netz nie liefern wird.
• Du hast eine kritische Reihe mit reicher, langer Historie und starker Domänenstruktur. Eine einzelne, gut verstandene Reihe, etwa die nationale Stromlast mit jahrzehntelangen Daten, belohnt ein maßgeschneidertes Modell mit Domänenwissen. Zero-shot-Allgemeingültigkeit ist verschenkt, wenn du nur ein Problem hast und darin tiefe Expertise besitzt.
• Deine Kovariaten dominieren und die Zusammenhänge sind stabil und bekannt. Eine lineare Regression auf den richtigen Features ist transparent, debugbar und, wenn die Physik des Problems wirklich linear ist, unschlagbar. Zahle keine Komplexitätssteuer ohne Gewinn.
• Du musst die Abhängigkeit vollständig beherrschen. Timestral wird unter einer modifizierten MIT-Lizenz mit Einschränkungen ausgeliefert. Wenn deine Prognosen tragende Infrastruktur sind, etwa Day-ahead-Energiemärkte, musst du gründlich abwägen, ob du von einem Server eines Anbieters oder einer Lizenz abhängig werden willst, die du nicht vollständig kontrollierst. Open-Weight-Alternativen und Eigenentwicklungen existieren genau für diesen Fall.
• Du hast strenge Anforderungen an Backtesting-Hygiene. Bei einem vortrainierten Modell kannst du nie vollständig sicher sein, dass dein Backtest-Zeitraum nicht im Trainingskorpus war, es sei denn, der Anbieter gibt dir Kontrolle über die Trainingsmischung. Mistral bietet das über seine Forge-Pipeline an, aber prüfe es, statt es anzunehmen.

Das Muster ist klar: Das Foundation Model gewinnt bei Breite, Geschwindigkeit und dünnen Daten; es verliert bei Interpretierbarkeit, Tiefe bei Einzelreihen und Abhängigkeitsrisiko. Das ist eine wirklich nützliche Entscheidungsregel und deutlich schärfer als das übliche „es kommt darauf an“.

Die Architekturfrage, die alle überspringen

Eines, was die TSFM-Welle geklärt hat und mehr Aufmerksamkeit verdient: Transformer funktionieren auf kontinuierlichen Signalen gut, und das Tokenisierungsproblem war weniger beängstigend als erwartet. Der Trick ist Patching. Statt jeden Zeitschritt als Token zu behandeln, was die Sequenzlänge explodieren lässt, oder rohe Gleitkommazahlen naiv einzubetten, zerlegst du die Reihe in Patches und bettest diese ein. Die Patch-Länge wird zu einem einstellbaren Regler, der Auflösung gegen Kontext abwägt, genau wie die Vokabulargröße bei einem LLM. Wenn du die Debatte über State-Space-Modelle versus Transformer verfolgt hast, ist bemerkenswert, dass die bisher erfolgreichen TSFMs überwiegend auf Attention basieren. Die langreichweitige Struktur temporaler Daten scheint gut zu Attention zu passen, sobald die Eingaberepräsentation feststeht.

Die synthetic-first-Datenstrategie verdient ebenso Anerkennung als Beitrag. Der Großteil der Trainingsdaten von Timestral wurde erzeugt, nicht gesammelt: zuerst univariate Prozesse mit kohärenter Dynamik, dann ein multivariater Synthesizer, der nichtlineare Abhängigkeiten zwischen ihnen schichtet. Das umgeht elegant das Datenproblem, das den Zeitreihen-ML seit jeher plagt: Es gibt kein Common Crawl für Sensordaten, und was existiert, ist abgeschottet, proprietär und uneinheitlich formatiert. Wenn synthetische Daten mit den richtigen induktiven Verzerrungen so gut übertragbar sind, verändert das die Ökonomie des ganzen Teilgebiets. Du musst nicht die Telemetrie der Welt horten; du brauchst gute Generatoren.

Vom Forecast zum System

Die interessanteste langfristige Folge ist nicht das Modell selbst, sondern das, was es nachgelagert ermöglicht. Ein günstiger, probabilistischer, multivariater Prognostiker, der kontinuierlich auf deinen Metriken läuft, ist ein Anomaliedetektor mit ehrlicher Unsicherheit: Statt zu alarmieren, wenn ein Wert eine statische Schwelle überschreitet, alarmierst du, wenn die Realität außerhalb der vorhergesagten Quantile liegt. Das bedeutet Alarme, die Saisonalität und geplante Ereignisse berücksichtigen. Eine geplante Lasterhöhung ist erwartet und wird nicht als Überraschung markiert. Allein das würde einen deprimierend großen Teil des Pager-Lärms in den meisten Organisationen beseitigen.

Setzt du einen LLM-Agenten obendrauf, bekommst du den Workflow, den Mistral skizziert: Das numerische Modell meldet eine Anomalie an einer Pumpe, ein Agent vergleicht die Signale mit Embeddings früherer Ausfälle, startet eine Ursachenanalyse über Wartungsprotokolle und Bedienernotizen und übergibt dem Anlagenleiter eine Diagnose mit Belegen statt eines nackten Alarms. Ob du genau diese Vision kaufst oder nicht, die Richtung stimmt. Es ist dasselbe Muster, das wir bei Constrained Decoding für Entscheidungsmodelle gesehen haben: Das schnelle, spezialisierte Modell bleibt für das, was es gut kann, im Loop, und das allgemeine Modell orchestriert drumherum.

Hier also mein Fazit. Maßgeschneidertes Forecasting ist nicht tot, es wurde vom Standard zum Spezialwerkzeug herabgestuft. Wenn du eine einzelne Reihe, tiefes Domänenwissen und den Bedarf an interpretierbarer Dynamik hast, fitte weiter deine State-Space-Modelle und schlaf gut. Wenn du aber Tausende Reihen hast, wenig Historie pro Reihe und ein Team aus drei Leuten, hat sich die Beweislast umgedreht: Du brauchst jetzt einen Grund, nicht mit einem Foundation Model anzufangen. Teste es auf deinen eigenen Daten mit hohem Signal, binde deine Kovariaten sauber ein, prüfe die Lizenz gegen deine Risikotoleranz und investiere dann die gesparten Monate in die Datenaufbereitung, denn dort wurden Forecasting-Projekte schon immer gewonnen oder verloren.