IBM Research hat Granite Time Series PatchTST-FM-r2 als offen verfügbares Foundation Model für Zero-Shot-Zeitreihenprognosen vorgestellt. Für Unternehmen ist daran weniger das Modelllabel entscheidend als die Aussicht, Nachfrage, Energieverbrauch, Kapazitäten oder Telemetrie zunächst ohne anwendungsfallspezifisches Training zu prognostizieren. Das kann die Eintrittskosten eines Piloten senken. Es ersetzt jedoch weder belastbare Daten noch einen Vergleich mit einfachen Baselines.
Bestätigt ist: Das Modell umfasst rund 385 Millionen Parameter, verarbeitet Kontexte bis 8.192 Zeitschritte und kombiniert Self-Attention mit zeitlicher Faltung. Es liefert Punkt- und probabilistische Prognosen, kann fehlende Werte imputieren und ist zusammen mit Gewichten, Architektur, Inferenzpipeline sowie Benchmark-Code verfügbar. IBM nennt Apache 2.0 und OpenMDW 1.0 als wählbare Lizenzen. Im dokumentierten GIFT-Eval-Vergleich liegt das Modell unter replizierbaren Zero-Shot-Modellen auf Rang zwei und unter den dort verglichenen permissiv kommerziell lizenzierten Modellen auf Rang eins.
Wo der Zero-Shot-Ansatz wirtschaftlich interessant wird
Eine nachvollziehbare Ableitung aus den bestätigten Eigenschaften ist: PatchTST-FM-r2 eignet sich besonders für eine frühe Machbarkeitsprüfung, wenn viele ähnliche Reihen vorliegen, aber für einzelne Reihen wenig Trainingshistorie oder wenig MLOps-Kapazität verfügbar ist. Beispiele sind Artikel-Nachfrage, Maschinen- oder Servertelemetrie, Energie-Lastgänge und operative Mengenplanung. Der Vorteil entsteht nicht automatisch durch eine bessere Kennzahl, sondern durch kürzere Einführungszeit und weniger Modellvarianten im Betrieb.
Nicht bestätigt ist dagegen, dass das Modell in einem konkreten DACH-Unternehmen genauer oder günstiger als vorhandene Verfahren arbeitet. Auch die offene Bereitstellung sagt noch nichts über Infrastrukturbedarf, Latenz, Datenlokalität oder interne Freigaben aus. Die Lizenzoption sollte zudem für den vorgesehenen Einsatz, die Verteilung abgeleiteter Artefakte und mögliche Modelländerungen rechtlich geprüft werden.
Entscheidungsrahmen: Vier Fragen vor dem Pilot
- Prozesswirkung: Welche Entscheidung ändert sich durch die Prognose, wer trifft sie und wie teuer sind Über- sowie Unterschätzungen?
- Datenreife: Sind Zeitstempel, Frequenzen, Ausfälle, Feiertage, Sortimentswechsel und externe Einflussgrößen ausreichend dokumentiert?
- Vergleichbarkeit: Werden bestehende Planung, naive Saison-Baseline und ein etabliertes statistisches Modell mit identischen Zeitfenstern und Kostenmetriken verglichen?
- Betriebsfähigkeit: Sind Laufzeit, Hardware, Monitoring, Versionswechsel, Datenresidenz und ein Rückfallpfad vorab geklärt?
Für die Auswahl des ersten Anwendungsfalls empfiehlt sich eine kleine Entscheidungsmatrix. Hoher Wert entsteht bei häufig wiederkehrenden Entscheidungen, messbaren Fehlkosten und ausreichend stabiler Historie. Ein schlechter Startpunkt sind Reihen, deren Zukunft überwiegend durch einmalige Managemententscheidungen, Kampagnen oder noch nicht erfasste Ereignisse bestimmt wird. Hier kann kein langer Kontext fehlende Kausalität ersetzen.
Die Erfolgsmetrik sollte direkt aus dem Prozess kommen. Im Einkauf kann das die Summe aus Fehlmengen, Abschriften und gebundenem Bestand sein; in der Kapazitätsplanung zählen Überstunden, Leerlauf oder verpasste Zusagen. Ein Modell kann bei einem technischen Durchschnittsfehler besser aussehen und dennoch teurere Entscheidungen auslösen. Deshalb bewertet der Pilot technische und wirtschaftliche Kennzahlen gemeinsam, getrennt nach relevanten Segmenten und Prognosehorizonten.
Ein vierstufiger Pilot ohne Produktionsrisiko
Stufe eins friert Ziel, Horizont und Messregeln ein. Das Team wählt einen abgegrenzten Prozess und definiert neben technischen Fehlermaßen eine betriebliche Kostenfunktion. Prognosen werden ausschließlich auf historischen, zeitlich sauberen Rücktests bewertet. So verhindert das Unternehmen, dass spätere Erkenntnisse unbemerkt in die Eingaben gelangen.
Stufe zwei prüft Daten und Modell im isolierten Modus. Dazu gehören unterschiedliche Kontextlängen, fehlende Werte und die vom Modell ausgegebenen Unsicherheitsbereiche. Parallel laufen naive und etablierte Baselines. Die Frage lautet nicht, ob Granite auf jeder Reihe gewinnt, sondern für welche Segmente es stabilen Zusatznutzen liefert und wo ein einfacheres Verfahren genügt.
Stufe drei ist ein Shadow-Betrieb: Das Modell erzeugt Prognosen im realen Takt, beeinflusst aber noch keine Bestellung, Schicht oder Kapazitätszusage. Das Team misst Laufzeit, Kosten, Ausfälle und Drift. Fachverantwortliche protokollieren, ob die Prognose rechtzeitig, verständlich und handlungsrelevant ankommt.
Stufe vier entscheidet über einen begrenzten produktiven Einsatz. Freigabe gibt es nur, wenn der betriebliche Nutzen die zusätzlichen Betriebs- und Kontrollkosten übersteigt, die Unsicherheitsintervalle kalibriert genug sind und der Rückfall auf das bisherige Verfahren getestet wurde. Andernfalls endet der Pilot bewusst oder bleibt auf geeignete Segmente beschränkt.
Für den späteren Betrieb braucht jede Prognose eine nachvollziehbare Version von Modell, Eingabedaten und Konfiguration. Ebenso wichtig sind Schwellen für ungewöhnliche Eingaben, verspätete Daten und sprunghafte Veränderungen. Wird eine Schwelle verletzt, darf der Prozess nicht stillschweigend weiterlaufen. Er wechselt auf die freigegebene Baseline oder verlangt eine fachliche Entscheidung. Dieser Rückfallpfad ist Teil des Produkts, nicht nur eine technische Notlösung.
Produktionsgates für Kosten, Risiko und Betrieb
- Qualitätsgate: reproduzierbarer Vorteil gegenüber vereinbarten Baselines auf mehreren Zeitfenstern
- Nutzengate: messbar geringere Fehlkosten oder deutlich weniger Modellpflege im Zielprozess
- Risikogate: dokumentierte Grenzen, Unsicherheitsanzeige und menschliche Freigabe bei kritischen Entscheidungen
- Betriebsgate: überwachte Datenqualität, versionierte Artefakte, definierte Latenz und getesteter Fallback
- Governance-Gate: Lizenz, Datenschutz, Informationssicherheit und Verantwortlichkeiten sind freigegeben
Der eigentliche Wert des offenen Modells liegt damit in der Prüfbarkeit: Unternehmen können Gewichte, Code und Benchmarkpfad untersuchen und einen eigenen Vergleich aufsetzen. Die sinnvolle Schlussfolgerung ist kein sofortiger Austausch vorhandener Prognosesysteme, sondern ein klar begrenzter Pilot. Wer Prozessmetrik, Baseline und Abbruchkriterien zuerst festlegt, kann die technische Offenheit in eine belastbare Investitionsentscheidung übersetzen.