Chronos-forecasting: vortrainierte Zeitreihenmodelle ohne Training
Chronos: Pretrained Models for Time Series Forecasting
Auf einen Blick
- Was ist das?
- Das Paket liefert Zugriff auf die Chronos-Modellfamilie von Amazon Science. Es löst ein enges Problem: Prognosen für Zeitreihen, ohne ein eigenes Modell zu trainieren. Die wichtigsten Grenzen liegen nicht im Code, sondern in den Modellgewichten und der Datenverteilung.
- Für wen ist es gedacht?
- Sinnvoll ist das Paket für Teams, die schnell eine Baseline für univariate, multivariate oder kovariaten-gestützte Prognosen brauchen und dafür kein Modell trainieren wollen. Wer eigene Fehlermaße auf historischen Fenstern braucht oder sehr lange Kontexte verarbeitet, sollte zuerst mit fev die eigene Datenverteilung gegen die Modellgewichte prüfen.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 7 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem das Paket tatsächlich löst
Klassische Prognoseverfahren verlangen pro Zeitreihe ein eigenes Modell, Trainingsdaten in ausreichender Länge und eine erneute Anpassung, sobald sich das Verhalten der Reihe ändert. Chronos geht den umgekehrten Weg: Die Modelle sind vortrainiert und werden im Zero-Shot-Modus angewendet. Das Paket chronos-forecasting ist die Inferenzschnittstelle dazu, kein Trainingsframework. Es richtet sich an Data-Science-Teams, die eine belastbare Ausgangsprognose brauchen, bevor sie Aufwand in Feature-Engineering oder Modellwahl stecken. Der Nutzen ist am größten, wenn viele Reihen mit ähnlicher Struktur vorliegen und ein einziges Modell sie alle bedienen soll.
Wie die drei Modellgenerationen intern arbeiten
Die README beschreibt drei unterschiedliche Architekturen. Das ursprüngliche Chronos skaliert und quantisiert eine Zeitreihe zu einer Tokenfolge und trainiert ein Sprachmodell mit Cross-Entropy darauf; probabilistische Prognosen entstehen durch Sampling mehrerer Zukunftspfade. Chronos-Bolt zerlegt den Kontext stattdessen in Patches mehrerer Beobachtungen, schiebt sie durch einen Encoder und erzeugt mit dem Decoder direkt Quantilprognosen über mehrere Schritte, also direct multi-step forecasting. Chronos-2 erweitert das auf univariate, multivariate und kovariaten-gestützte Aufgaben. Diese Unterscheidung ist praktisch relevant: Sampling-basierte Prognosen liefern Verteilungen, aber jeder Aufruf kann anders ausfallen, während die direkte Quantilausgabe von Chronos-Bolt deterministisch ist. Wer reproduzierbare Werte in einem Report braucht, hat mit dem Patch-Verfahren weniger Streuung zwischen zwei Läufen.
Modellgrößen und die Wahl zwischen 9M und 710M
Die Modelltabelle listet zwölf Gewichte. Chronos-2 und die synthetische Variante kommen auf 120M Parameter, die kleine Variante auf 28M. Chronos-Bolt reicht von 9M bis 205M, die ursprüngliche T5-Reihe von 8M bis 710M. Die README nennt für Chronos-Bolt eine bis zu 250-fach höhere Geschwindigkeit und 20-fach geringeren Speicherbedarf gegenüber den Originalmodellen gleicher Größe, außerdem laut Release-Hinweis 5 Prozent niedrigeren Fehler. Solche Angaben stammen aus der Projektdokumentation und sind nicht auf die eigene Datenverteilung übertragbar. Für CPU-Inferenz ist chronos-bolt-tiny mit 9M Parametern der naheliegende Einstieg, für Genauigkeit ohne harte Latenzgrenze amazon/chronos-2 mit 120M.
Installation und der erste Prognoselauf
Der Einstieg ist ein einzelner pip-Befehl: pip install chronos-forecasting. Das README-Beispiel importiert pandas mit der Empfehlung pip install 'pandas[pyarrow]' und zieht die Klasse aus dem Paket. Die Modellgewichte liegen nicht im Paket, sondern auf Hugging Face; die README verlinkt die Sammlung unter huggingface.co/collections/amazon/chronos-models-65f1791d630a8d57cb718444. Beim ersten Aufruf werden sie von dort geladen, was ohne Netzwerkzugang fehlschlägt. Für den Produktivbetrieb verweist die Dokumentation auf zwei AWS-Wege: AutoGluon-Cloud mit Pandas-DataFrames als Ein- und Ausgabe sowie SageMaker JumpStart über das Notebook notebooks/deploy-chronos-to-amazon-sagemaker.ipynb. Beide setzen eine AWS-Umgebung voraus und sind kein Ersatz für lokale Inferenz.
Wo Zero-Shot an die Grenzen kommt
Das Paket trainiert nicht. Es passt keine Gewichte an die eigene Reihe an. Wenn eine Zeitreihe Strukturen enthält, die im Vortraining nicht vorkamen, etwa Sondereffekte, Brüche oder sehr spezifische Saisonalität, kann die Prognose schlechter ausfallen als ein simples saisonales Naivmodell. Die README nennt keinen Mechanismus, um das zu erkennen; sie liefert nur Inferenz. Ein weiterer Punkt: Die Paper-Links verweisen auf zwei verschiedene arXiv-Nummern, 2403.07815 für die ursprüngliche Arbeit und 2510.15821 für den Chronos-2-Report. Wer die Genauigkeitsbehauptungen prüfen will, muss beide lesen, und die README selbst quantifiziert die Überlegenheit nur über Benchmarks wie fev-bench und GIFT-Eval, nicht über anwendungsspezifische Daten.
fev als Gegenstück zu den Modellgewichten
Das Projekt pflegt mit fev ein eigenes Benchmark-Paket, das auf der Hugging-Face-datasets-Bibliothek aufsetzt und im Dezember 2024 veröffentlicht wurde. Das ist der ehrlichste Teil des Ökosystems: Statt den Nutzern zu versichern, die Modelle seien allgemein gut, wird ein Werkzeug mitgeliefert, mit dem sich das auf den eigenen Daten prüfen lässt. Der Unterschied zu einem generischen Evaluationsskript besteht darin, dass fev die Datensätze über dieselbe Bibliothek bezieht, aus der auch die Trainingsdaten stammen. Wer Chronos produktiv einsetzen will, sollte fev nicht als optionales Extra behandeln, sondern als vorgeschalteten Schritt.
Alternative: AutoGluon-TimeSeries mit eigenem Training
Der naheliegende Vergleich ist AutoGluon-TimeSeries, ebenfalls aus dem Amazon-Umfeld. Der Unterschied liegt im Ansatz, nicht im Ergebnis: AutoGluon trainiert pro Datensatz mehrere Modelle, darunter statistische Verfahren und Gradient Boosting, und wählt per Backtest das beste. Das kostet Trainingszeit und Speicher pro Reihe, liefert aber ein Modell, das die eigene Verteilung kennt. Chronos tauscht diesen Schritt gegen vortrainierte Gewichte und einen einzigen Inferenzaufruf. Bei vielen kurzen Reihen mit wenig Historie ist der Zero-Shot-Weg meist der einzige praktikable; bei einer einzelnen langen Reihe mit klarer Struktur kann ein trainiertes Modell die bessere Wahl sein.
Lizenz und Pflegeaufwand
Der Code steht unter Apache-2.0, das README zeigt das entsprechende Badge. Diese Lizenz erlaubt kommerzielle Nutzung und Modifikation, verlangt aber die Beibehaltung von Copyright-Hinweisen und Patenteinräumungen; eine Rechtsberatung ersetzt das nicht. Wichtig ist die Trennung: Die Lizenz gilt für das Repository, nicht automatisch für die Modellgewichte auf Hugging Face. Dort ist die Lizenz jedes Modells separat zu prüfen, bevor es in ein Produkt geht. Die Pflege sieht aktiv aus, mit Releases v2.3.0 im Juni, v2.3.1 im Juli und v2.3.2 im September 2026. Upgrade-Kosten entstehen vor allem durch neue Modellvarianten, die andere Eingabeformate für Kovariaten erwarten können; die README dokumentiert keinen Stabilitätsvertrag über Versionen hinweg.
Redaktionelles Fazit
Sinnvoll ist das Paket für Teams, die schnell eine Baseline für univariate, multivariate oder kovariaten-gestützte Prognosen brauchen und dafür kein Modell trainieren wollen. Wer eigene Fehlermaße auf historischen Fenstern braucht oder sehr lange Kontexte verarbeitet, sollte zuerst mit fev die eigene Datenverteilung gegen die Modellgewichte prüfen. Nach dem pip install chronos-forecasting und einem Lauf mit amazon/chronos-2 auf einem Ausschnitt der eigenen Reihe zeigt sich, ob die Zero-Shot-Güte für den Anwendungsfall reicht oder ob Fine-Tuning nötig wird.
Community-Notizen