Du kaufst ein neues Smartphone. Es ist leichter, hat einen schnelleren Prozessor – und kostet weniger als das Vorgängermodell. Du freust dich. Nach einer Woche merkst du: Der Akku hält nur halb so lang, die Kamera produziert unscharfe Fotos, und die Apps stürzen ab. Was wie ein Upgrade aussah, ist ein Rückschritt. Genau das passiert gerade in vielen Unternehmen mit KI-Modellen.
Waldek Mastykarz, Principal Developer Advocate bei Microsoft, hat das mit seinem Team untersucht. In einem Experiment verglichen sie zwei Modelle: Claude Sonnet 4.6, das ältere, und Claude Sonnet 5, das neuere. Die offiziellen Benchmarks des neuen Modells sind besser, der Preis pro Token ist niedriger – doch die Realität sieht anders aus. Die Ergebnisse: Ein Modell-Update garantiert keine besseren Ergebnisse. Oft ist es das Gegenteil.
Der Kern des Problems liegt in den Token-Kosten. Ein Token ist eine Einheit, die ein KI-Modell bei der Verarbeitung von Text liest oder schreibt – grob gesagt ein Wort oder ein Zeichen. Die Preisliste von Sonnet 5 wirkt auf den ersten Blick günstig: Der Input ist ein Drittel billiger als bei Sonnet 4.6, der Output ebenfalls. Aber die Rechnung geht nur auf, wenn die Anzahl der verbrauchten Tokens gleich bleibt. Und genau das tut sie nicht.
In den Tests – 150 Agentenaufgaben in 15 Szenarien – zeigte sich ein deutlicher Unterschied. Bei Architekturaufgaben verbrauchte Sonnet 5 im Median zwölfmal mehr Tokens als Sonnet 4.6. In einem Einzelfall sogar das 47-fache. Bei Code-Upgrades lag der Faktor bei zehn. Steigt die Token-Menge so stark, nützt der günstigere Preis pro Token nichts. Die Gesamtkosten pro Aufgabe explodieren. Bei Code-Upgrades kostete eine Ausführung mit dem neuen Modell durchschnittlich 2,01 Dollar, mit dem alten nur 0,55 Dollar. Das ist fast das Vierfache.
Auch die Qualität sinkt. In den Architekturszenarien – Aufgaben wie das Entwerfen einer IoT-Analytics-Architektur – erreichte Sonnet 4.6 in 90 Prozent der Fälle die geforderte Qualität im Sinne etablierter Patterns und Konventionen. Sonnet 5 schaffte nur 78 Prozent. Bei neun von zwölf Szenarien war das alte Modell besser oder gleich gut. Die Ergebnisse: Mehr Tokens, schlechtere Ausgabe. Kein Upgrade, sondern ein Downgrade.
Es gibt eine Ausnahme. Bei Code-Upgrade-Aufgaben – etwa der Migration eines SharePoint-Framework-Projekts – drehte sich das Blatt. Hier erfüllte Sonnet 5 die Aufgabe in 100 Prozent der Fälle, während Sonnet 4.6 nur bei 60 Prozent erfolgreich war. Das neue Modell folgte präzise den Anweisungen und suchte tiefer in der Dokumentation. In einem Lauf fraß es sogar 69 Millionen Tokens und entdeckte dabei undokumentierte Migrationsschritte. Aber solche Tiefe ist selten: Nur einer von fünf Läufen zeigte dieses Verhalten. Die Leistung ist real, aber nicht reproduzierbar.
Beide Modelle stoßen an eine gemeinsame Grenze: die Qualität des Inhalts, auf den sie zugreifen können. Bei Code-Upgrades lag die Konfigurationskorrektheit bei null Prozent – für beide Modelle. Keine der KI fand die versteckten Schritte für strukturelle Änderungen wie den Wechsel von gulp zu Heft oder von Legacy-ESLint zu Flat-Config. Die benötigten Informationen waren nirgendwo vollständig dokumentiert. Ein neues Modell kann keine Wunder wirken, wenn die Datenbasis Löcher hat. Eine Erkenntnis: Bevor du über ein Modell-Update nachdenkst, prüfe, ob deine Dokumentation vollständig ist.
Hinzu kommt ein weiteres Problem: die Varianz. Die Token-Kosten schwanken beim neuen Modell dramatisch. Bei einer einfachen Architekturaufgabe verbrauchte ein Lauf 16.000 Tokens, ein anderer 6,6 Millionen – bei exakt dem gleichen Prompt. Solche Ausreißer können das Budget eines ganzen Monats sprengen. Das alte Modell hingegen zeigte enge Cluster: Die meisten Läufe lagen zwischen 14.000 und 45.000 Tokens. Planungssicherheit bietet das neue Modell nicht.
Mastykarz‘ Studie zeigt: Ein Modell-Update ist eine Hypothese, die du für deine spezifische Aufgabe testen musst. Ethan Mollick spricht von der „zerklüfteten Grenze“ der KI-Fähigkeiten: Was auf den ersten Blick ähnlich schwer erscheint, kann auf unterschiedlichen Seiten der Grenze liegen. So auch bei Modell-Updates. Auf Code-Upgrades steigt die Erfolgsrate von 60 auf 100 Prozent, auf Architekturaufgaben sinkt die Qualität von 90 auf 78 Prozent. Du weißt nicht, auf welcher Seite deine Workloads landen, bis du sie misst.
Für Entscheider in Tech-Teams: Wenn du ein neues Modell empfiehlst oder bereitstellst, fang mit deinem Workload an. Für routinemäßige Architektur- und Designaufgaben mit gut dokumentierten Domänen liefert das ältere Modell oft gleich gute oder bessere Ergebnisse zu vergleichbaren Kosten. Für Aufgaben, die präzise Anweisungsbefolgung erfordern, hat das neue Modell einen Vorteil. Der Mix deiner Aufgaben bestimmt, welches Modell das bessere Standardmodell ist.
Wenn du im großen Maßstab arbeitest, spielt auch die Token-Varianz eine Rolle. Die engen Cluster des alten Modells machen die Budgetplanung berechenbar. Das neue Modell kann vom einen zum anderen Lauf um den Faktor 400 schwanken – ein Risiko.
Doch bevor du Zeit in die Evaluation verschiedener Modelle investierst, prüfe zuerst, ob dein Agent die Informationen hat, die er braucht. Mastykarz‘ Team beobachtete: Erweiterungen des Agenten (Extensions) erzeugen mehr Hebelwirkung pro Dollar als ein Modell-Upgrade, weil sie die Wissenslücke schließen, die beide Modelle gleichermaßen betrifft. Wenn deine Dokumentation Lücken hat, schließt sie kein Modell-Wechsel.
Miss zuerst, upgrade dann. Lass dich nicht von niedrigeren Preisen pro Token blenden. Die tatsächlichen Kosten und die Qualität hängen von deiner spezifischen Aufgabe ab. Ein neues Modell ist nicht per se ein Upgrade – es kann ein teurer Rückschritt sein. Nimm dir die Zeit, deine Workloads zu messen, bevor du den Wechsel vollziehst. Das schont Budget und Produktivität.
Quelle: developer.microsoft.com
