Kein Modell lebt ewig: LLM Lifecycle Management

Stand: 14.10.2026 12:00 Uhr

Ob Chatbot, AI Agent oder Voicebot: Die Anwendung läuft stabil, die Kunden sind zufrieden, die Kosten stimmen. Dann kommt die E-Mail vom Modellanbieter, dass das Sprachmodell dahinter in 60 Tagen abgeschaltet wird. Warum kündigen Anbieter ihre Modelle ab? Was bedeutet ein erzwungener Wechsel? Und vor allem: Wie macht man sich davon unabhängig?

Bei klassischer Software ist man daran gewöhnt, dass eine Version jahrelang läuft, solange man sie nicht anfasst. Bei Large Language Models (LLMs) ist das anders. Hier gibt der Anbieter den Lebenszyklus eines Modells vor – und der ist oft kürzer als der eines Kundenservice-Projekts.

Warum Modelle abgekündigt werden

Der wichtigste dafür Grund ist Rechenkapazität. Jedes LLM, das ein Anbieter weiter betreibt, belegt GPUs (Graphics Processing Units), die für neue Modelle fehlen. Anthropic sagt das offen: Alte Modelle werden zurückgezogen, um Kapazität für neue Releases zu schaffen. Hinzu kommt das Tempo der Entwicklung: Neue Modellgenerationen erscheinen inzwischen im Abstand weniger Monate. Sie sind meist schneller, günstiger im Betrieb und leistungsfähiger. Aus Sicht des Anbieters gibt es also wenig Grund, Kunden dauerhaft auf einer älteren Generation zu halten.
Seltener, aber auch möglich, sind Sicherheits- oder Compliance-Gründe. Microsoft behält sich zum Beispiel vor, ein Modell bei Sicherheitsproblemen mit verkürzter Frist abzuschalten. Zwischen Ankündigung und Abschaltung liegen je nach Anbieter zwei bis sechs Monate. Die Gesamtlebensdauer eines Modells beträgt also oft nur 12 bis 18 Monate.

Erzwungene Modellwechsel und die schwierige Suche nach Nachfolgern

Doch egal, wo die Gründe liegen, das Ergebnis für Anwender ist immer gleich: Ein Modell hat ein Ablaufdatum, und nach diesem Datum schlagen Anfragen schlicht fehl. Ein aktuelles Beispiel: Anthropic hat „Claude Sonnet 4.5“ am 30. September 2026 abgekündigt und wird es am 30. November 2026 abschalten. Das sind genau zwei Monate für Test, Anpassung und Rollout. Wichtig dabei: Bezieht man ein Modell über einen Hyperscaler statt direkt beim Hersteller, gilt der Zeitplan des Hyperscalers. Dasselbe Modell kann also bei zwei Anbietern völlig unterschiedliche Abschalttermine haben.
Das eigentliche Ärgernis für Unternehmen ist: Bis zur Abkündigung hat alles funktioniert, es gibt also keinen fachlichen Anlass für den Wechsel. Trotzdem entsteht Aufwand, und zwar an mehreren Stellen: Ein produktiver KI-Agent ist grob auf drei Kennwerte abgestimmt: Intelligenz, Preis und Latenz. Der vom Anbieter empfohlene Nachfolger trifft selten alle drei. Oft ist er leistungsfähiger, aber langsamer oder teurer oder beides. Besonders kritisch ist das bei Voicebots, denn jede zusätzliche Millisekunde bis zur ersten Antwort empfindet der Anrufer als Pause. Hinzu kommt die Frage, wo das Nachfolge-Modell betrieben wird. Neue Modelle starten bei den Hyperscalern meist zuerst als globales Deployment. Eine Verarbeitung ausschließlich in der EU folgt oft erst Monate später, manchmal gar nicht.

Angepasste Prompts und neues Testing

Prompts sind auf ein bestimmtes Modell abgestimmt. Ein neues Modell versteht dieselbe Anweisung anders, antwortet länger oder kürzer, wählt einen anderen Ton oder ruft Funktionen anders auf. In der Folge benötigt jeder Wechsel einen vollständigen Testzyklus: typische Gesprächsverläufe, Sonderfälle, Schnittstellen zu Backend-Systemen und die Abnahme durch den Fachbereich. Ändern sich Anbieter oder Region, kommen Datenschutzprüfung und Vertragsfragen hinzu. Wer gar nichts tut, wird zwar nicht immer einfach abgeschaltet, aber Azure beispielsweise stellt bestimmte Deployments zum Abschalttermin automatisch auf das Nachfolgemodell um. Die Anwendung läuft dann weiter, aber mit einem anderen Modell, das niemand getestet hat.

Transparenz: bei Anbietern unterschiedlich, gegenüber Kunden Pflicht

Wie gut Anbieter über Abkündigungen informieren, ist sehr unterschiedlich. Manche veröffentlichen Abschalttermine schon beim Release und bieten sie sogar per API an. Andere nennen nur vorläufige Daten nach dem Muster „nicht vor“ oder benennen das Nachfolgemodell erst wenige Monate vor der Abschaltung. Dazu kommen Stolpersteine im Detail: Benachrichtigungen gehen oft nur an den Inhaber des jeweiligen Cloud-Kontos. Bei Azure bedeutet der API-Status „Deprecated“, dass ein Modell bereits abgeschaltet ist - aber laut Dokumentation läuft es noch. Wer also mehrere Anbieter nutzt, muss jeden einzelnen ständig im Blick behalten.

Gute Kundenkommunikation ist Teil des Produkts

Für Unternehmen, die KI im Kundenservice einsetzen, ist es daher vor allem wichtig, rechtzeitig zu wissen, was kommt. Gute Kommunikation beantwortet Fragen wie diese frühzeitig:

• Welches Modell ist betroffen, und ab wann?

• Welcher Nachfolger ist geplant, und wie hat er im Test abgeschnitten?

• Was ändert sich bei Kosten, Latenz und Datenverarbeitung?

• Welche Schritte stehen an, und wer macht was?

Der Ausweg: Open-Weight-Modelle

Das Problem der Abkündigung und ihrer Folgen entsteht, weil ohne eigenes Zutun über den Lebenszyklus eines LLMs entschieden wird. Anders ist die Situation bei so genannten Open-Weight-Modellen. Dadurch, dass die Modelle auf einer eigenen oder gemieteten Infrastruktur betrieben werden, laufen sie so lange, wie sie gebraucht werden.
Das passt zu einem Thema: Die Digitale Souveränität steht ganz oben auf der Agenda. VIER ordnet KI-Services deswegen in einem eigenen Souveränitätsmodell ein. Auf Level 3, „EU-souverän“, laufen Modelle auf europäischer Infrastruktur, entweder von VIER selbst betrieben oder von einem europäischen Anbieter. Die Daten verlassen die EU nicht und bleiben unter europäischer Kontrolle.

Neben der vollständigen Kontrolle über die Daten hat Level 3 einen angenehmen Nebeneffekt: Ein Modellwechsel ist keine Pflicht mehr. Ein Modell, das heute getestet und freigegeben ist, läuft auch in zwei Jahren noch zuverlässig, wenn der Kunde das möchte. Und selbst wenn ein europäischer Hosting-Partner ein Modell einmal nicht mehr anbietet, lässt sich genau dasselbe Modell bei einem anderen Betreiber weiterhin nutzen, weil die Gewichte frei sind. Freilich: Auch ein selbst betriebenes LLM braucht Pflege, etwa Sicherheitsupdates der Laufzeitumgebung und ausreichend GPU-Kapazität. Den Zeitpunkt für einen Modellwechsel bestimmt dann aber nicht mehr der Anbieter, sondern der Kunde!

Fazit: Wechseln, wenn es sich lohnt, nicht, weil man muss

Grundsächlich gilt, dass Modellwechsel nicht von vornherein schlecht sind. Wenn ein neues Modell deutlich schneller antwortet, spürbar günstiger ist oder Aufgaben löst, an denen das alte Modell bisher scheitert, kann sich der Umstieg ganz klar lohnen. Umgekehrt gilt: Erledigt ein Modell seinen Job zuverlässig, ist das Argument „neu“ kein wirkliches Argument. Dann muss im Einzelfall abgewogen werden, ob der Nutzen den Aufwand und das Risiko eines Wechsels rechtfertigt. Gutes LLM Lifecycle Management bedeutet genau daher das: Den Überblick darüber zu behalten, welche Modelle im Einsatz sind, wie lange sie noch laufen, eine möglichst frühe, ehrliche Kommunikation mit den Kunden und eine Architektur, in der der Kunde selbst entscheidet, wann ein Wechsel sinnvoll ist.