Machine Learning auf grossen Daten

Im Herbst 2025 prognostizierte die Datenabteilung eines Stuttgarter Energieversorgers den Stromverbrauch für 1.200 Quartiere im süddeutschen Raum, jeweils auf Stundenbasis und mit einem Horizont von zwei Wochen. Die Aufgabe klang trivial. Tausende historische Zeitreihen, gut strukturiert, mit klaren Mustern. Die ersten Versuche mit ARIMA pro Reihe lieferten stabile, aber mediocre Vorhersagen. Eine Datenanalystin schlug vor, ein einziges globales Modell auf allen Reihen zu trainieren, mit der Quartiers-ID als kategorialem Merkmal. Das Modell sollte die Ähnlichkeiten zwischen Quartieren ausnutzen, etwa zwischen mehreren Reihenhaussiedlungen mit ähnlichem Bewohnerprofil. Nach drei Wochen Implementierung lag die Prognosegenauigkeit um 23 Prozent besser als bei den lokalen ARIMA-Modellen. Trainingszeit: 40 Minuten auf einer einzelnen Maschine.

Diese Geschichte zeigt, warum maschinelles Lernen den vorherigen Schichten dieser Serie inhaltlich nahe steht und gleichzeitig technisch anders funktioniert. Die typischen Verarbeitungs-Engines aus Teil 3 sind hier nur bedingt einsetzbar. Apache Spark bringt mit MLlib zwar eine eigene Bibliothek mit, deren Funktionsumfang ist im Vergleich zum Python-Ökosystem aber begrenzt. Wer State-of-the-Art-Methoden anwenden möchte, landet in der Praxis nahezu immer in einer Python-Umgebung. Dieser Teil zeigt, welche Werkzeuge sich 2026 für Zeitreihenprognose etabliert haben, wie sich der Sprung in verteilte Trainingsläufe sauber gestaltet und wie sich der ML-Teil in die übrige Datenarchitektur einfügt.

Welche Werkzeuge dominieren die Zeitreihenprognose?

Die Open-Source-Bibliotheken aus dem Hause Nixtla haben sich in den letzten zwei Jahren zur faktischen Referenz für Zeitreihenprognose entwickelt. Drei Bausteine bilden zusammen einen geschlossenen Werkzeugkasten.

StatsForecast bündelt klassische statistische Modelle wie AutoARIMA, AutoETS, AutoCES, MSTL und Theta mit hochoptimiertem, in Numba kompiliertem Code ^[3]. Die Bibliothek ist auf Geschwindigkeit getrimmt und schafft auf einer modernen Maschine tausende ARIMA-Modelle pro Stunde, was vor wenigen Jahren noch eine Spark-Pipeline verlangte. Mit Version 2.0.3 vom 29. Oktober 2025 ist die 2er-Hauptlinie etabliert. Wer von R-Bibliotheken wie forecast oder fable kommt, findet in StatsForecast eine vertraute Auswahl an Modellen mit deutlich höherer Performance.

MLForecast verpackt Gradient-Boosting-Verfahren wie LightGBM oder XGBoost in eine Schnittstelle, die für Zeitreihen typische Aufgaben wie Lag-Berechnung und Cross-Validation übernimmt ^[4]. Wer schon einmal mit Scikit-learn gearbeitet hat, findet sich in MLForecast nach wenigen Stunden zurecht. Das Werkzeug ist 2026 die wahrscheinlich pragmatischste Wahl für globale Prognosemodelle in Produktion. Bei der Stuttgarter Energie-Pipeline aus der Eingangsgeschichte lief genau dieses Werkzeug.

NeuralForecast ergänzt das Bild um moderne Deep-Learning-Architekturen wie NHITS, NBEATS oder Temporal Fusion Transformer und seit den 3.x-Releases auch multivariate Modelle wie iTransformer und MLPMultivariate. Im April 2026 ist Version 3.1.7 aktuell, davor erschien 3.1.4 am 15. Januar 2026 ^[1]. Die Bibliothek hat sich vor allem in der Forschung etabliert und wird zunehmend auch in produktiven Pipelines eingesetzt, vor allem dort, wo viele Reihen mit komplexen saisonalen Mustern auftauchen.

Konkurrenz hat das Nixtla-Trio durchaus. Meta Prophet (vormals Facebook Prophet) bleibt populär, vor allem wegen der einfachen API, und wird unter Meta-Verantwortung weiter gepflegt (zuletzt mit Updates für Pandas 3.0 und NumPy 2.4 Anfang 2026). Die Genauigkeit ist aber in Benchmarks oft schwächer als bei MLForecast oder NeuralForecast. AutoGluon-Timeseries (aktuell 1.5.0 stabil, 1.5.1 in Entwicklung ^[11]) bietet eine sehr saubere AutoML-Erfahrung, in der mehrere Modelle gleichzeitig getestet und automatisch das beste ausgewählt wird. Es kombiniert StatsForecast-Modelle, GluonTS-Deep-Learning, LightGBM-Boosting und neuerdings auch das pretrainierte Foundation-Modell Chronos in einer Ensemble-Schicht. Wer sich nicht in Modellarchitekturen einarbeiten will, findet hier einen pragmatischen Einstieg. Pythonkenntnisse vorausgesetzt.

Eine ehrliche Wertung gehört dazu. Wer mit Zeitreihenprognose anfängt und keine spezifischen Anforderungen hat, sollte bei StatsForecast einsteigen. Die Modelle sind erklärbar, die Implementierung ist überschaubar, und in vielen Fällen liefern sie überraschend gute Ergebnisse. Wer mit einer Mehrzahl ähnlicher Reihen arbeitet (Filialumsatz, Energieverbrauch pro Haushalt, Wartungsintervalle pro Maschine), sollte MLForecast als zweites prüfen. NeuralForecast lohnt sich vor allem dort, wo die anderen Werkzeuge nicht mehr ausreichen.

Welche Rolle spielen Foundation-Modelle in der Zeitreihenprognose?

Eine Entwicklung verdient eine eigene kurze Sektion, weil sie 2026 sehr viel an Tempo aufgenommen hat. Pretrainierte Foundation-Modelle für Zeitreihen (analog zu LLMs in der Sprachverarbeitung) sind in den vergangenen 18 Monaten von einer Forschungs-Idee zu einem Produktionsstandard geworden. Chronos von Amazon, basierend auf der T5-Architektur, ist mit dem Chronos-2-Release im Oktober 2025 zur reifsten Option in dieser Klasse geworden, jetzt mit Unterstützung für univariate, multivariate und kovariaten-informierte Prognosen. Auf einer einzigen GPU schafft Chronos rund 300 Vorhersagen pro Sekunde ^[9]. TimesFM von Google ist seit 2024 in Googles Produktionsumgebungen im Einsatz und gilt als guter Kompromiss zwischen Geschwindigkeit und Genauigkeit. Moirai von Salesforce, Lag-Llama von ServiceNow und TimeGPT von Nixtla selbst (proprietär) ergänzen das Feld. Alle diese Modelle versprechen Zero-Shot-Forecasting, also brauchbare Vorhersagen ohne Training auf der konkreten Zeitreihe. Für viele Standardaufgaben liefern sie tatsächlich Ergebnisse, die mit gut getunten klassischen Modellen mithalten oder sie sogar schlagen. Für regulierte Anwendungen mit Erklärbarkeitsanforderungen bleibt der Reiz allerdings begrenzt, weil die internen Mechanismen ähnlich opak sind wie bei großen Sprachmodellen.

Wo liegt der Unterschied zwischen lokalen und globalen Modellen?

Ein zentraler Unterschied, den jede Datenfachkraft im Hinterkopf haben sollte, ist die Trennung zwischen lokalen und globalen Modellen. Ein lokales Modell wird pro Zeitreihe trainiert. Ein eigenes ARIMA-Modell pro Filiale, ein eigenes ETS-Modell pro Sensor. Ein globales Modell lernt aus allen Reihen gemeinsam und nutzt eine Reihen-Identifikation als zusätzliches Merkmal.

Klassische Statistikverfahren sind fast immer lokal, Gradient Boosting und neuronale Netze typischerweise global. Beide Ansätze haben ihre Berechtigung. Lokale Modelle sind sehr gut darin, idiosynkratische Muster einzelner Reihen zu erfassen. Globale Modelle profitieren vom Wissenstransfer zwischen Reihen, die ähnliche Dynamiken aufweisen, und benötigen pro neue Reihe deutlich weniger Datenpunkte für eine brauchbare Prognose.

Die Eingangsgeschichte aus Stuttgart illustriert genau diesen Punkt. Lokale ARIMA-Modelle hatten Mühe mit Quartieren, für die nur 18 Monate Daten vorlagen. Das globale LightGBM-Modell konnte aus den Mustern älterer, ähnlicher Quartiere lernen und lieferte für die jungen Quartiere sofort tragfähige Prognosen. Solche Wissenstransfer-Effekte sind häufiger, als man denkt, und sie sind der eigentliche Grund, warum sich der Trend hin zu globalen Modellen in den letzten Jahren so klar durchgesetzt hat.

Wann passt welcher Ansatz? Drei Regeln helfen beim Sortieren. Erstens: Bei sehr unterschiedlichen Reihen mit eigenen Mustern (etwa Verkaufszahlen unterschiedlicher Produktkategorien) sind lokale Modelle oft besser. Zweitens: Bei vielen ähnlichen Reihen mit Wissenstransfer-Potenzial (Filialen, Quartiere, Sensoren) gewinnen globale Modelle fast immer. Drittens: Wenn Erklärbarkeit ein Muss ist (etwa für regulierte Branchen), bleiben lokale klassische Modelle die einfachere Wahl.

In der Praxis lohnt sich oft ein Hybridansatz. Ein globales Modell als Basis, das die meisten Reihen abdeckt, plus speziell trainierte lokale Modelle für Reihen mit deutlich abweichendem Verhalten. Diese Kombination liefert in vielen Fällen die beste Genauigkeit, ohne dass die Wartung explodiert. Wichtig ist, eine klare Schwelle zu definieren, ab der eine Reihe ein eigenes lokales Modell bekommt. Eine bewährte Regel: Wenn der Prognosefehler einer Reihe unter dem globalen Modell zwei Standardabweichungen über dem Mittelwert aller Reihen liegt, lohnt sich ein eigener Versuch.

Wie lassen sich die Trainingsläufe skalieren?

Solange die Daten in den Hauptspeicher einer einzelnen Maschine passen, ist der Werkzeugkasten unproblematisch. Spannend wird es, wenn Tausende oder Hunderttausende Zeitreihen gleichzeitig prognostiziert werden müssen oder die Trainingsdaten ohnehin nicht mehr auf einen Server passen. Hier gibt es mehrere etablierte Strategien.

Ray hat in den letzten Monaten einen wichtigen organisatorischen Schritt gemacht. Im September 2025 hat Anyscale Ray offiziell an die Linux Foundation gespendet und gleichzeitig in das PyTorch-Ecosystem aufgenommen, was die langfristige Stabilität des Frameworks deutlich erhöht ^[2]. Mit Train, Tune, Serve und RLlib bietet Ray eine vollständige Werkzeugpalette für verteiltes Trainieren, Hyperparameter-Tuning, Modell-Bereitstellung und Reinforcement Learning. Stand April 2026 ist 2.55.1 die aktuelle stabile Version, 2.56 ist in Entwicklung und wird die Pydantic-V1-Unterstützung beenden. Wer eine reine Python-Welt baut und Spark vermeiden will, hat mit Ray eine solide Basis ^[5].

Dask ist die ältere und bekanntere Alternative, vor allem im Datenwissenschafts-Umfeld. Die Pandas/NumPy-Ähnlichkeit macht den Einstieg leicht, die Skalierung über mehrere Maschinen funktioniert ohne Umweg über die JVM. Dask folgt einer Date-basierten Versionierung, die latest 2026.3.0 stammt vom April 2026 und unterstützt bereits Python 3.14 ^[6][8]. Beide Frameworks lassen sich übrigens kombinieren. Dask kann auf Ray laufen und umgekehrt, was in der Praxis aber selten nötig ist.

Aus Stakeholder-Sicht lassen sich diese Optionen auf zwei Leitfragen reduzieren. Erstens, welche Datenmenge ist im Spiel und wo liegt die Grenze, ab der eine einzige Maschine nicht mehr ausreicht? Zweitens, wie viel Investition in einen verteilten Werkzeugkasten ist gerechtfertigt, wenn die Mehrzahl der Modelle ohnehin lokal pro Reihe trainiert werden kann? In vielen Organisationen lautet die ehrliche Antwort, dass eine gut ausgestattete Maschine mit Polars für die Datenvorbereitung und MLForecast für das Training erstaunlich weit trägt. Erst wenn dieser Pfad klar an seine Grenzen stößt, lohnt der Sprung in eine verteilte Architektur.

Hyperscaler-Dienste haben in diesem Bereich ihre eigene Berechtigung. Vertex AI, SageMaker, Azure ML und Databricks ML stellen verteilte Trainingsläufe als Service bereit, ohne dass eine Organisation einen eigenen Cluster betreiben muss. Daten verbleiben dabei im jeweiligen Cloud-Speicher, das Training läuft auf elastischen Compute-Knoten. Die Aufschläge dieser Dienste auf die reine Compute-Rechnung sind erheblich. SageMaker schlägt etwa 30 bis 40 Prozent auf die EC2-Preise auf, Vertex AI rund 20 bis 30 Prozent auf die Compute-Engine-Kosten. Für eine GPU-Instanz wie eine A100 80GB liegen die Stundensätze in Azure ML bei rund 3,67 USD, eine H100 80GB schlägt mit etwa 6,98 USD pro Stunde zu Buche. Für Organisationen, die ohnehin in einer Cloud verankert sind und keine eigene ML-Plattform bauen wollen, sind diese Dienste trotzdem eine pragmatische Wahl. Der Preis ist die übliche Plattform-Bindung. Wer einmal seine Modelle in Vertex AI gepflegt hat, kommt mit dem Gedanken eines Wechsels selten weit. Mid-sized Teams bewegen sich erfahrungsgemäß zwischen 1.000 und 7.000 USD pro Monat für die ML-Plattform, abhängig von Compute-Intensität und gewähltem Anbieter ^[10].

Wie sich ML in den restlichen Stack einfügt

Die Modellartefakte und ihre Vorhersagen sollten am Ende wieder in den Data Lake oder in eine analytische Datenbank zurückgeschrieben werden, damit Dashboards, Reports und nachgelagerte Anwendungen darauf zugreifen können. Diese Praxis klingt banal, wird aber häufig vernachlässigt. Wer Vorhersagen nur in einem Notebook produziert und sie nicht systematisch persistiert, verschenkt einen wesentlichen Teil ihres Wertes.

Eine bewährte Architektur sieht ungefähr so aus. Trainingsdaten kommen aus dem Lakehouse, idealerweise aus einer Iceberg- oder Delta-Tabelle. Das Training läuft in einer Python-Umgebung (auf einer einzigen starken Maschine oder in einem Ray-Cluster). Das fertige Modell wird in einer Modell-Registry abgelegt. MLflow ist hier der etablierte Standard, mit der jüngsten Version 3.11.1 vom 5. März 2026, die explizit auf GenAI-Workflows zugeschnitten ist und unter anderem automatische Issue-Erkennung sowie native OpenTelemetry-Unterstützung mitbringt. Alternativ kommt Feast für Feature-Stores in Frage, das seit 2025 ebenfalls Teil des PyTorch-Ecosystems ist ^[13]. Die Vorhersagen werden zurück in eine Tabelle geschrieben, entweder im Lakehouse oder direkt in einer ClickHouse-Instanz. Dashboards und Anwendungen lesen die Vorhersagen aus dieser Tabelle.

Diese Trennung hat zwei wichtige Vorteile. Erstens wird das Training reproduzierbar, weil Daten, Modell und Vorhersage versioniert vorliegen. Zweitens entkoppelt sie das Training-Tooling vom Anwendungs-Tooling. Wer das Modell morgen mit einer anderen Bibliothek neu trainiert, muss die Anwendungen nicht anfassen, solange das Output-Schema gleich bleibt.

Feature-Stores verdienen in dieser Schicht eine kurze Erwähnung. Feast, in der Branche das prominenteste Open-Source-Werkzeug, sorgt dafür, dass dieselben abgeleiteten Merkmale (Feature Engineering) sowohl beim Training als auch zur Inferenz konsistent verfügbar sind. Wer einmal das Problem hatte, dass ein Modell im Test gut funktioniert hat, in Produktion aber merkwürdig schwächelt, kennt die typische Ursache: leicht abweichende Feature-Berechnungen zwischen Trainings- und Inferenz-Pipeline. Ein Feature-Store löst dieses Problem strukturell, ist aber zusätzliche Komplexität, die nicht jedes Projekt braucht.

Ein Hinweis zur DACH-Realität gehört dazu. Viele Mittelständler in Deutschland scheitern bei ML-Projekten nicht an der Modellqualität, sondern an der mangelnden Persistenz und Reproduzierbarkeit. Ein Modell, das in einem Notebook entstanden und auf dem Laptop einer einzelnen Person trainiert worden ist, lässt sich nach drei Wochen nicht mehr zuverlässig nachbauen. Wer ML produktiv bringen will, sollte deshalb ab Tag eins in MLflow oder ein vergleichbares Tracking-Werkzeug investieren ^[7].

Ein zweiter wiederkehrender Stolperstein ist das Monitoring nach dem Deployment. Modelle altern. Was im Mai 2025 hervorragende Vorhersagen lieferte, kann im April 2026 systematisch danebenliegen, weil sich die zugrundeliegenden Datenmuster verschoben haben. Energiepreise nach einem geopolitischen Schock, Konsumverhalten nach einer Pandemie, Wartungsbedarf nach einer Generationswechsel der Maschinen. Eine Plattform, die ML produktiv betreibt, braucht ein laufendes Monitoring der Modellgenauigkeit gegen tatsächliche Beobachtungen. Bei der Eingangsgeschichte aus Stuttgart wird das globale Modell genau aus diesem Grund alle vier Wochen neu trainiert, mit den jüngsten 24 Monaten als Trainingsdaten.

Konkrete Werkzeuge für dieses Monitoring sind Evidently AI mit über hundert eingebauten Drift-Tests und einer offenen Python-Bibliothek, das seit Anfang 2025 ebenfalls als Open-Source-Projekt unter Apache 2.0 verfügbare WhyLabs für integrierte Observability inklusive SOC-2-Type-2- und HIPAA-Compliance ^[12], sowie einfache Eigenentwicklungen, die Vorhersagen und tatsächliche Werte in einer Tabelle gegenüberstellen und einen Alarm auslösen, wenn die Abweichung über einen Schwellenwert steigt. Welcher Ansatz richtig ist, hängt von Datenmenge und Team-Größe ab. Für kleine Setups reicht häufig die Eigenentwicklung. Für komplexe Plattformen lohnt sich ein dediziertes Werkzeug.

Was das Zusammenspiel als Leitprinzip bedeutet

Damit schließt sich der Kreis dieser Serie. Wenn man die einzelnen Bausteine zusammensetzt, entsteht ein Bild, das in den meisten modernen Datenplattformen wiederzufinden ist. Ganz unten liegt ein S3-kompatibler Object Storage, sei es bei einem Hyperscaler, bei Hetzner oder selbst betrieben mit SeaweedFS, Garage oder RustFS. Eine Web-Oberfläche wie Filestash macht den Bestand für Menschen zugänglich, ohne zur primären Datenschnittstelle zu werden. Auf dem Object Storage liegen die Rohdaten, möglichst früh nach der Aufnahme bereits in Parquet konvertiert. Tabellenformate wie Iceberg oder Delta Lake heben dieses Verzeichnis auf eine Tabellenabstraktion mit Transaktionen, Schema-Evolution und Time Travel. Verarbeitungs-Engines wie Spark, Polars oder DuckDB lesen aus dieser Schicht, bereiten die Daten auf und schreiben sie zurück. Wo interaktive Antwortzeiten gefragt sind, übernimmt eine analytische Datenbank wie ClickHouse oder BigQuery. Spezialaufgaben wie Zeitreihenprognose finden in der Python-Welt mit den Nixtla-Bibliotheken statt, eingebettet in eine Skalierungsstrategie, die zur Größenordnung der Datenmenge passt.

Die zentrale Botschaft dieser Architektur ist die Trennung von Anliegen. Speicher, Format, Tabelle, Engine, analytische Datenbank und ML sind jeweils eigenständige Komponenten, die über offene Standards miteinander sprechen. Ein einzelner Baustein kann ausgetauscht werden, ohne dass die anderen mitziehen müssen. Ein Wechsel von einem Cloud-Anbieter zum nächsten oder von einer Engine zur nächsten bleibt überschaubar, weil S3, Parquet und SQL die gemeinsamen Brücken bilden.

Das ist der eigentliche Grund, warum sich dieser Stack durchgesetzt hat. Er gibt den Organisationen, die ihn nutzen, eine Verhandlungsposition zurück, die in geschlossenen Datenarchitekturen schwer zu erlangen ist. Wer eine Datenplattform aufbaut, sollte 2026 weniger über die Auswahl einzelner Werkzeuge nachdenken und mehr über die Trennung der Schichten. Genau dort liegt der Hebel für eine Architektur, die auch im Jahr 2030 noch tragfähig sein wird.

Fazit und Ausblick

Drei Punkte halte ich nach allem, was diese Serie an Werkzeugen aufgereiht hat, für die wichtigsten. Erstens: Anfangen mit den einfachsten Bausteinen. Hetzner Object Storage, Parquet-Dateien, DuckDB für Abfragen, Polars für Transformationen. Diese vier Werkzeuge tragen erstaunlich weit, kosten wenig im Betrieb und sind in einer Woche eingerichtet.

Zweitens: Erst skalieren, wenn die Last es verlangt. Spark, ClickHouse, ein Polaris-Katalog und ein Iceberg-Setup sind hervorragende Werkzeuge, aber jedes davon bringt Komplexität mit. Wer zu früh in alle Schichten gleichzeitig investiert, baut sich eine Plattform, die schwerer zu warten ist als die Probleme, die sie lösen soll.

Drittens: Trennung der Schichten als nicht verhandelbares Prinzip. Wer Speicher, Format, Engine und analytische Datenbank in einer monolithischen Lösung zusammenführen lässt, gewinnt kurzfristig Bequemlichkeit und verliert langfristig Flexibilität. Eine offene Architektur ist zu Beginn aufwändiger, zahlt sich aber bei jeder einzelnen Umstellung der nächsten Jahre aus. Wer einmal eine Datenplattform durch eine größere Migration begleitet hat, kennt den Unterschied zwischen einer offenen und einer geschlossenen Architektur sehr genau.

Eine letzte Beobachtung gehört dazu. Datenarchitektur ist 2026 weniger ein technisches Problem als ein organisatorisches. Die Werkzeuge sind reif, die Standards sind etabliert, die Open-Source-Landschaft ist tragfähig. Was viele Plattformen scheitern lässt, sind unklare Verantwortlichkeiten, fehlende Datenmodellierung und das Beharren auf Bequemlichkeit statt Trennung. Wer eine Plattform aufbaut, sollte deshalb mindestens so viel Zeit in das organisatorische Setup stecken wie in die Toolwahl. Klare Zuständigkeiten für Schemata, Datenqualität und Pipeline-Betrieb sind die unterschätzten Erfolgsfaktoren.

Diese Serie hat die wichtigsten Bausteine moderner Datenarchitekturen vorgestellt. Wer sie in einer realen Plattform zusammensetzt, bekommt am Ende kein perfektes System, sondern ein wartbares. Genau das ist 2026 das wertvollste Versprechen, das eine Datenarchitektur einlösen kann.

Bleibt die Frage, was als nächstes kommt. Drei Entwicklungen sind aus meiner Sicht in den nächsten 18 Monaten besonders relevant. Erstens, die Konvergenz von Lakehouse und OLAP-Datenbank. Werkzeuge wie DuckLake und ClickHouse-Iceberg-Integration deuten an, dass die Grenze zwischen den Schichten weicher wird. Zweitens, die Reife der vendor-neutralen Kataloge. Apache Polaris hat 2026 das Tempo angezogen und könnte die offene Standardisierung der Katalog-Schicht entscheidend voranbringen. Drittens, die zunehmende Verschmelzung von Datenpipeline und ML-Pipeline. Werkzeuge wie Feast, MLflow und Ray Train wachsen sichtbar zusammen, was die Entwicklung produktiver ML-Plattformen deutlich vereinfachen dürfte.

Quellen

^[1] Nixtla NeuralForecast 3.1.7 auf PyPI, Stand April 2026 (https://pypi.org/project/neuralforecast/, https://github.com/Nixtla/neuralforecast/releases)

^[2] Ray spendet an Linux Foundation und PyTorch Ecosystem, Herbst 2025 (https://www.infoq.com/news/2025/10/pytorch-conf-ray-monarch/, https://pytorch.org/projects/ray/)

^[3] Nixtla StatsForecast 2.0.3 vom 29. Oktober 2025 (https://github.com/Nixtla/statsforecast/releases, https://nixtlaverse.nixtla.io/statsforecast/)

^[4] Nixtla MLForecast GitHub Repository, Stand April 2026 (https://github.com/Nixtla/mlforecast)

^[5] Ray 2.55.x Documentation und 2.56-Roadmap, Stand April 2026 (https://docs.ray.io/en/latest/)

^[6] Dask 2026.3.0 Distributed Computing Library (https://distributed.dask.org/en/latest/, https://pypi.org/project/dask/)

^[7] MLflow 3.11.1 Release vom 5. März 2026 (https://mlflow.org/releases/3.11.1/, https://mlflow.org/)

^[8] Vergleich Spark vs. Ray vs. Dask, Onehouse 2025 (https://www.onehouse.ai/blog/apache-spark-vs-ray-vs-dask-comparing-data-science-machine-learning-engines)

^[9] Time Series Foundation Models 2026 (Chronos, TimesFM, Moirai, TimeGPT), MachineLearningMastery (https://machinelearningmastery.com/the-2026-time-series-toolkit-5-foundation-models-for-autonomous-forecasting/)

^[10] Hyperscaler-ML-Plattformen Pricing 2026 (Vertex AI, SageMaker, Azure ML), TechTarget und Spendark (https://www.techtarget.com/searchenterpriseai/tip/Compare-Google-Vertex-AI-vs-Amazon-SageMaker-vs-Azure-ML, https://spendark.com/blog/machine-learning-cloud-cost/)

^[11] AutoGluon TimeSeries 1.5.0/1.5.1 mit Chronos-Integration, Stand April 2026 (https://auto.gluon.ai/stable/tutorials/timeseries/index.html, https://aws.amazon.com/blogs/machine-learning/easy-and-accurate-forecasting-with-autogluon-timeseries/)

^[12] WhyLabs Open-Source Apache 2.0 seit Januar 2025, plus Evidently AI Vergleich (https://github.com/evidentlyai/evidently, https://www.evidentlyai.com/)

^[13] Feast Joins the PyTorch Ecosystem (https://pytorch.org/blog/feast-joins-the-pytorch-ecosystem/, https://feast.dev/)