Angewandte KI August 2026 · 15 Min. Lesezeit

Frontier oder Open-Weight? Unternehmen wählen nicht das Modell, sondern das Risiko.

TL;DR

Frontier und Open-Weight sind nicht die entgegengesetzten Enden einer Skala. Frontier beschreibt ein Leistungsniveau, Open-Weight eine Art des Zugangs.
Starten Sie einen neuen, unsicheren oder anspruchsvollen Use Case auf einem Frontier-Modell über eine API und wählen Sie die günstigste Stufe, die Ihre eigenen Tests besteht.
Open-Weight lohnt sich bei stabiler und hoher Last, bei einer echten Anforderung, Daten lokal zu halten, oder im Offline-Betrieb. Eine GPU ist auch dann bezahlt, wenn sie nichts tut.
Das größte Cloud-Risiko ist kein Datenleck, sondern die Abhängigkeit. Die Absicherung ist nicht der eigene Server, sondern eigene Tests, Daten, Prompts und ein Ersatzmodell.

Im Juni 2026 musste Anthropic den Zugang zu seinen Modellen Claude Fable 5 und Mythos 5 innerhalb weniger Stunden sperren. Es war kein technischer Ausfall. Die Modelle waren erst drei Tage auf dem Markt, als das US-Handelsministerium eine Exportanordnung erließ, die jedem ausländischen Staatsangehörigen den Zugang untersagte – innerhalb wie außerhalb der USA. Da Anthropic Nutzende nicht in Echtzeit nach Staatsangehörigkeit filtern konnte, setzte das Unternehmen den Zugang für alle Kunden gleichzeitig aus, einschließlich AWS, Google Cloud und Microsoft Foundry. Am 30. Juni hob das Ministerium die Beschränkungen auf, einen Tag später war Fable 5 wieder verfügbar – nach insgesamt knapp drei Wochen.

Die Lehre daraus ist aus meiner Sicht nicht „Die Cloud ist gefährlich, kaufen wir eigene Grafikkarten“. Das wäre eine teure und übereilte Reaktion. Die eigentliche Lehre ist einfacher: Wenn ein kritischer Geschäftsprozess auf einem einzigen Modell steht, hat das Unternehmen keine KI-Strategie, sondern einen Single Point of Failure.

Im Herbst 2025 stellte Google die Entwicklungsumgebung Antigravity vor. Das Risiko zeigte sich hier nicht darin, dass ein Dienst von einem Tag auf den anderen verschwand, sondern darin, dass sich seine Wirtschaftlichkeit schrittweise veränderte. Anfangs boten die kostenpflichtigen Tarife sehr großzügige Limits: Man konnte mehrere anspruchsvolle agentische Aufgaben laufen lassen – also solche, bei denen das Modell mehrere Schritte selbstständig hintereinander ausführt – praktisch ohne spürbar an ein Kontingent zu stoßen. Im Dezember 2025 sank die Zahl der täglichen Anfragen in der kostenlosen Version von 250 auf 20. Im März 2026 baute Google dann sein gesamtes KI-Abo um: Es führte KI-Credits ein, die sich zukaufen lassen, und im kostenpflichtigen Pro-Tarif wurde das Kontingent bei den meisten Modellen nicht mehr alle fünf Stunden, sondern nur noch einmal pro Woche zurückgesetzt. Entwickler, die ihren Verbrauch damals selbst gemessen haben, berichteten, dass sie vor Januar mehr als 300 Millionen Eingabe-Token pro Woche verarbeiten konnten und anschließend bei knapp neun Millionen an eine Wochengrenze stießen. Das sind Schätzungen aus der Community, keine offiziellen Zahlen. Wesentlich ist: Die Tarifbeschreibung blieb dabei nahezu unverändert.

Aus Unternehmenssicht bleibt der Kern derselbe: Ein Produkt, das beim Kauf der Pauschale wirtschaftlich nahezu unbegrenzt war, kann sich nach einigen Monaten in einen Dienst mit deutlich geringerer Kapazität und zusätzlichen variablen Kosten verwandeln. Ohne jede Änderung am eigenen Workflow, am Vertrag oder an der Technologie.

Auch OpenAI hatte eine eigene Variante des Problems. Dort zeigt sich dasselbe Risiko weniger in einer offiziellen Preisänderung als in der Unsicherheit darüber, welches Modell man in einem bestimmten Produkt tatsächlich bekommt. Nach dem Start von GPT-5.5 berichteten mehrere Codex-Nutzende von einer spürbaren Qualitätsverschlechterung bei denselben Programmieraufgaben wie zuvor. Es gab auch konkrete Berichte, wonach die Anwendung die Verarbeitung automatisch auf ein kleineres Modell umschaltete, obwohl GPT-5.5 High ausgewählt war. Das belegt, dass ein automatisches Umschalten auf ein anderes, meist kleineres Modell (Routing oder Fallback) vorkommen kann. Es belegt nicht, dass OpenAI absichtlich und flächendeckend GPT-5.4 mini als GPT-5.5 ausgegeben oder still Kosten gespart hätte.

Einen sehr ähnlichen Fall erlebte Anthropic. Nutzende von Claude Code berichteten von einer allmählichen Qualitätsverschlechterung und verdächtigten das Unternehmen, heimlich auf ältere Modelle umzuschalten oder das sogenannte „Reasoning-Budget“ zu kürzen – also die Zeit, die das Modell zum Nachdenken aufwendet, bevor es seine endgültige Antwort erzeugt. Anthropic veröffentlichte im April 2026 ein Postmortem, wonach sich weder das Modell noch die Inferenzschicht verändert hatten. Versagt hat die Produktschicht: Bei Opus 4.6 senkte das Unternehmen im März die voreingestellte Reasoning-Stufe in Claude Code von hoch auf mittel, um die Antwortzeiten zu verkürzen – ein Kompromiss, den es später selbst als falsch bezeichnete und zurücknahm. Bei Opus 4.6 und 4.7 kam ein Fehler hinzu, der den bisherigen Reasoning-Verlauf des Modells wiederholt löschte, sodass es vergesslich und repetitiv wirkte. Weil jede Änderung einen anderen Teil des Dienstes zu einer anderen Zeit traf, wirkte das Ganze wie eine breite, unvorhersehbare Verschlechterung.

Für Unternehmen ist die praktische Konsequenz wichtiger: Der Name eines Modells und seine Einstellungen in der Benutzeroberfläche sind nicht automatisch eine Garantie für eine unveränderte Leistung des gesamten Produkts. Routing, Limits, System-Prompts, verfügbare Tools und Produkt-Updates können das Verhalten verändern. Ein kritischer Prozess sollte sich deshalb nicht auf das Gefühl stützen, „dieses Modell funktioniert gut“, sondern auf regelmäßige automatisierte Tests, die anschlagen, wenn sich die Qualität des Dienstes verändert.

Genau deshalb beginnt die Debatte um Frontier oder Open-Weight so oft mit der falschen Frage. Statt nach dem allgemein besseren Modelltyp zu suchen, ist es nützlicher zu fragen, wo wir für Komfort bezahlen wollen, wo wir Kontrolle brauchen und welche operativen Risiken wir zu übernehmen bereit sind.

Ein Restaurant, ein Privatkoch und das Rezept

Ein Frontier-Modell können wir uns als Spitzenrestaurant vorstellen. Wir bestellen das Ergebnis, und der Anbieter kümmert sich um Küche, Personal, Zutaten, Hardware, Updates und den Mittagsansturm. In der Regel bekommen wir die höchste verfügbare Qualität, ohne eine eigene KI-Infrastruktur aufbauen zu müssen. Gleichzeitig akzeptieren wir aber Speisekarte, Preise und Regeln des Betreibers.

Ein Open-Weight-Modell ist eher ein erfahrener Privatkoch, den wir in unsere eigene Küche holen. Wir erhalten die trainierten Gewichte des Modells und können es auf eigener Hardware betreiben. Wir haben mehr Kontrolle über die Daten, die Konfiguration und den Zeitpunkt, zu dem wir das Modell aktualisieren. Küche, Strom, Sicherheit, Wartung und Kapazität in der Spitzenzeit liegen dann allerdings bei uns. Hinzu kommt, dass auch ein sehr fähiger Koch nicht zwangsläufig jedes Gericht auf demselben Niveau zubereiten kann. Und wenn zwanzig Gäste gleichzeitig hereinkommen, geht es nicht nur um das Können des Kochs – wir brauchen auch eine ausreichend große Küche und die Kapazität, sie zu bedienen.

Open Source geht noch weiter. Es genügt nicht, einen fertigen Koch zu bekommen. Wir brauchen auch die Rezepte, den relevanten Code, Informationen über das Training und die Rechte, das System zu nutzen, zu untersuchen, zu verändern und zu teilen. In der KI werden diese Begriffe oft vermischt, aber nach der Definition der Open Source Initiative wird ein Modell nicht schon dadurch zu Open-Source-KI, dass sich seine Gewichte herunterladen lassen.

Wichtig ist: „Frontier“ und „Open-Weight“ sind nicht die entgegengesetzten Enden einer einzigen Skala. Frontier beschreibt ein Leistungsniveau. Open-Weight beschreibt eine Art des Zugangs. Ein Modell kann gleichzeitig sehr leistungsfähig und zum Download verfügbar sein. Mistral etwa bezeichnet Medium 3.5 als Modell der Frontier-Klasse und hat es zugleich mit offenen Gewichten veröffentlicht.

Zu den bekannten Frontier-Familien gehören Modelle von OpenAI, Anthropic, Google, xAI und Mistral. Zu den bekanntesten Open-Weight-Familien gehören Llama, Qwen, DeepSeek, Gemma und Mistral.

Der Abstand zwischen den besten geschlossenen und den besten offenen Modellen wird dabei kleiner. Neue Open-Weight-Modelle übertreffen ältere Frontier-Modelle häufig bei konkreten Aufgaben, etwa beim Programmieren oder in der Mathematik. Das heißt aber noch nicht, dass sie bei unklaren Anforderungen, langen agentischen Prozessen oder verlässlicher Tool-Nutzung besser sind.

Genau hier machen Unternehmen ihren ersten Fehler: Sie vergleichen zwei Modelle anhand eines einzigen Benchmarks und verwechseln das Ergebnis mit einer Architekturentscheidung. Ein öffentlicher Benchmark ist kein Geschäftsprozess. Ein Modell kann beim Programmieren hervorragend abschneiden und trotzdem regelmäßig daran scheitern, die Verträge eines bestimmten Unternehmens zu klassifizieren.

Mein Ausgangspunkt: ein neues Projekt auf einem Frontier-Modell starten

Für die meisten neuen KI-Projekte in Unternehmen würde ich heute mit einem Frontier-Modell über eine API beginnen – also über eine direkte technische Anbindung an den Dienst des Anbieters. Nicht weil die Cloud die ideologisch richtige Antwort ist, sondern weil wir am Anfang eines Projekts fast nichts über das wissen, was für die Wirtschaftlichkeit des Eigenbetriebs entscheidend ist.

Wir wissen nicht, wie viele Menschen die Lösung nutzen werden. Wir wissen nicht, wie lang die Eingaben sein werden, wie viele Schritte ein einzelner Prozess umfasst oder wie viele Fehler wir nach dem Rollout finden. Oft wissen wir nicht einmal, ob der Use Case seine ersten drei Monate übersteht. Hardware in dieser Phase zu kaufen bedeutet, Unsicherheit in Fixkosten zu verwandeln.

Eine API erlaubt es, schnell zu starten, den tatsächlichen Verbrauch zu messen und herauszufinden, welche Modellklasse wir wirklich brauchen. Sehr oft brauchen wir nicht das teuerste Modell am Markt. Der richtige Weg ist, das günstigste Modell zu finden, das unsere eigenen Tests zuverlässig besteht.

Der letzte Punkt ist entscheidend. Solange ein Unternehmen keine repräsentative Sammlung echter Fälle und keine klare Definition eines korrekten Ergebnisses hat, bleibt die Debatte über Modelle größtenteils Bauchgefühl.

Über die Kosten entscheidet nicht der Token-Preis, sondern die Auslastung

Stellen wir uns ein System vor, das eingehende Dokumente verarbeitet: Rechnungen, Korrespondenz, Verträge oder Serviceanfragen. Ein Dokument hat im Durchschnitt 2.000 Eingabe- und 500 Ausgabe-Token. Das Ergebnis muss nicht sofort vorliegen; wir können die Dokumente in eine Warteschlange stellen und schrittweise abarbeiten.

Wenn ein lokaler Server ein Dokument im Schnitt in fünf Sekunden verarbeitet, liegt die theoretische Obergrenze bei 17.280 Dokumenten pro Tag. Das entspricht 34,56 Millionen Eingabe- und 8,64 Millionen Ausgabe-Token. Nach der Preisliste von OpenAI, wie sie im Juli 2026 gilt, kostet dieses Volumen bei den Sätzen für kurzen Kontext – also bei kürzeren Eingaben – rund 43 US-Dollar pro Tag (etwa 37 Euro) mit GPT-5.6 Luna und 108 US-Dollar (etwa 93 Euro) mit GPT-5.6 Terra. Preislisten ändern sich, aber der Punkt bleibt: Bei stabil hohem Volumen beginnt die API-Rechnung, monatlich in die Tausende zu gehen.

Eine RTX 5090 hat 32 GB Speicher und eine maximale GPU-Leistungsaufnahme von 575 W. Zieht der gesamte Server unter Last rund 750 bis 900 W, kostet der Dauerbetrieb bei einem Strompreis von 0,18 Euro pro kWh etwa 3 bis 4 Euro pro Tag – Kühlung nicht eingerechnet.

Auf den ersten Blick sieht die Amortisation eines eigenen Servers hervorragend aus. Dieser Vergleich trägt aber nur, wenn der Server die meiste Zeit ausgelastet ist, das lokale Modell die erforderliche Qualität erreicht und wir keine Ersatzlösung, keine Wartung und keine zusätzliche Person für den Betrieb brauchen.

Ändern wir das Volumen auf 1.000 Dokumente pro Tag, sinkt die Cloud-Rechnung auf wenige Dollar. Dann lässt sich der Kauf eines Servers deutlich schwerer begründen. Nicht wegen des Preises eines lokalen Tokens, sondern weil eine GPU auch dann bezahlt ist, wenn sie nichts tut.

Wirtschaftlich sinnvoll ist Open-Weight deshalb vor allem bei stabiler, hoher und vorhersehbarer Last, die wir laufend abarbeiten können. Typische Beispiele sind Datenextraktion, Klassifizierung, Zusammenfassung, das Maskieren sensibler Daten oder andere wiederkehrende Dokumentenprozesse.

Ein unternehmensweiter Assistent ist das umgekehrte Problem

Ein unternehmensweiter Chatbot oder Agent sieht auf dem Papier ähnlich aus, wirtschaftlich ist er aber ein anderes Produkt. Um zwei Uhr nachts nutzt ihn kaum jemand. Um zehn Uhr morgens können zehn, fünfzig oder zweihundert Anfragen gleichzeitig eintreffen. Und Nutzende wollen keine Antwort in vier Stunden; sie erwarten die erste Reaktion in Sekunden.

Bei eigener Hardware müssen wir die Kapazität für die Spitze einkaufen. Das bedeutet, für Leistung zu zahlen, die den größten Teil des Tages ungenutzt bleibt. Lange Dokumente und mehr parallele Zugriffe verbrauchen zudem nicht nur Zeit, sondern auch Speicher. Eine einzelne Karte, die eine anspruchsvolle Anfrage bequem bewältigt, wird bei zehn gleichzeitigen Anfragen womöglich zu langsam.

Die Cloud hat bei dieser Art von Last einen natürlichen Vorteil. Der Anbieter teilt einen großen Hardware-Pool auf viele Kunden auf, und ein Unternehmen muss keinen eigenen Cluster nur für die Spitze am Montagmorgen kaufen.

Interaktive Assistenten, unvorhersehbare agentische Prozesse und komplexe Aufgaben mit geringem oder unsicherem Volumen würde ich deshalb auf Frontier-Modellen starten. Open-Weight würde ich erst erwägen, wenn wir echte Daten zu Nutzung, Antwortzeiten und Qualität haben.

Sensible Daten: weniger Panik, konkretere Fragen

Aus meiner Sicht überschätzen Unternehmen das Risiko von Cloud-Modellen manchmal. In den seriösen Business- und API-Angeboten der großen Anbieter ist es Standard, dass Eingaben und Ausgaben von Kunden ohne Zustimmung nicht zum Training von Basismodellen verwendet werden. Das gilt beispielsweise für die OpenAI API, die Claude API, Google Cloud und für Modelle, die über Azure bereitgestellt werden.

Das heißt nicht, dass sich die Datenfrage mit „Sie trainieren nicht darauf“ abschließen lässt. Zu klären sind Speicherdauer, Verarbeitungsort, Unterauftragsverarbeiter, Logging, angebundene Tools und Vertragsbedingungen. Eine öffentliche Chat-Anwendung und eine Unternehmens-API sind nicht dasselbe Produkt.

Ebenso gilt: Eine On-Premise-Lösung ist nicht von sich aus sicher – sie verlagert nur die Verantwortung. Das Unternehmen muss sich selbst um Zugriffsrechte, Updates, Backups, Monitoring, Bibliotheken und Personal kümmern.

Ein lokales Modell ist dann Pflicht, wenn die Daten eine bestimmte Umgebung wirklich nicht verlassen dürfen, wenn ein Vertrag oder eine Vorschrift es verlangt, wenn das System ohne Internet funktionieren muss oder wenn die lokale Verarbeitung Teil des Produktwerts ist. Nicht dann, wenn „die Cloud gefährlich wirkt“.

Das größte Cloud-Risiko ist die Abhängigkeit

Der Fall Fable 5 war ein extremes, aber sehr klares Beispiel. Das Modell verschwand nicht wegen eines technischen Defekts, sondern weil sich eine externe Regel geändert hatte.

Ich widerspreche deshalb der Auffassung, Vendor-Lock-in lasse sich durch eine einfache Änderung der API-Adresse lösen. Code lässt sich relativ schnell umschreiben. Das Verhalten eines Modells nicht. Ein anderes Modell interpretiert den Prompt anders, nutzt Tools anders, lehnt andere Anfragen ab und macht andere Fehler. Echtes Lock-in steckt nicht nur im Code, sondern im Prozess, den wir auf ein konkretes Verhalten abgestimmt haben.

Die Absicherung dagegen muss nicht der eigene Server sein. Sie besteht darin, Tests, Daten, Prompts und Geschäftslogik selbst zu kontrollieren. Ein kritischer Prozess sollte ein Ersatzmodell haben, und das Unternehmen sollte wissen, was passiert, wenn sich Preis, Limit oder Verfügbarkeit des Dienstes ändern.

Bei einem Open-Weight-Modell haben wir mehr Kontrolle über die Version. Wenn ein konkretes Modell für uns funktioniert, ändert es niemand von einem Tag auf den anderen. Das heißt nicht, dass wir ohne Abhängigkeiten wären. Wir sind weiter abhängig von Hardware, Treibern, der Inferenz-Software, die das Modell ausführt, von Sicherheitsupdates und von den Menschen, die das System kennen.

Offene Gewichte sind kein Blankoscheck

Ein weiteres übersehenes Thema sind Lizenzen und die Herkunft eines Modells. Open-Weight bedeutet nicht automatisch Apache 2.0 und nicht unbegrenzte kommerzielle Nutzung. Manche Modelle erlauben einen breiten Einsatz, andere enthalten eigene Einschränkungen – für große Nutzer, für die Weiterverbreitung oder für das Angebot des Modells als Dienst.

Für die Unternehmensführung folgt daraus ein praktischer Rat: Die Lizenz eines Modells verdient dieselbe Prüfung wie die Lizenz jeder anderen kritischen Software. Ebenso müssen wir wissen, woher das Modell kommt, welche Dokumentation es dazu gibt und ob wir ihm in unserer Lieferkette vertrauen können.

Ein europäischer Server ist noch keine europäische Souveränität

Viele Frontier-Anbieter bieten inzwischen europäische Datenregionen an. OpenAI erlaubt berechtigten API-Kunden beispielsweise, Daten in Europa verarbeiten und speichern zu lassen. Der physische Standort eines Servers ist aber nicht dasselbe wie die Jurisdiktion des Anbieters. Der CLOUD Act, das US-Gesetz über den behördlichen Zugriff auf Daten, erfasst Daten, die ein Unternehmen in seinem Besitz oder unter seiner Kontrolle hat – unabhängig davon, wo sie physisch gespeichert sind.

Gleichzeitig würde ich AI Act, NIS2 und DORA nicht als generelle Anweisung lesen, Modelle on-premise zu betreiben. Ihre praktische Botschaft an das Management lautet eher: Verschaffen Sie sich einen Überblick über die Risiken, prüfen Sie Ihre Anbieter, dokumentieren Sie Ihre Entscheidungen und bereiten Sie sich auf den Ausfall eines kritischen Dienstes vor. DORA verlangt von Finanzunternehmen etwa ausdrücklich, das IKT-Drittparteienrisiko als Teil des gesamten IKT-Risikomanagements zu steuern.

Europäische Modelle sollte man deshalb weder nach dem Pass auswählen noch automatisch abschreiben. Mistral ist eine echte Alternative, kommerziell und als offene Gewichte. An die absolute Spitze der amerikanischen geschlossenen Modelle reichen die Modelle von Mistral nicht ganz heran, aber der Abstand ist heute kleiner, als die meisten Unternehmen denken – und für die überwiegende Mehrheit betrieblicher Aufgaben ist ihre Leistung völlig ausreichend. Europäische Herkunft ist relevant, wenn sie ein konkretes rechtliches, betriebliches oder strategisches Risiko senkt, nicht als Ersatz für Qualität.

Wie wir in der Praxis entscheiden

Bei INSYNAPS haben wir zum Beispiel für das Projekt AI Anonymizer ein Open-Weight-Modell gewählt. Der Kern der Lösung: Das sensible Dokument bleibt auf einem lokalen Server. Das Modell identifiziert sensible Daten und ersetzt sie durch eine Maske oder einen Platzhalterwert, damit die veränderte Version weiterverarbeitet werden kann.

Rechtlich handelt es sich dabei eher um Pseudonymisierung als um echte Anonymisierung. Pseudonymisierte Daten sind weiterhin personenbezogene Daten, aber das Risiko ihrer Verarbeitung ist geringer.

Der lokale Betrieb ist hier keine Kostenoptimierung. Er ist Teil des Produktversprechens.

Für eine Krankenversicherung verarbeiten wir die Korrespondenz mit Vollstreckungsorganen. Dort haben wir umgekehrt ein kleineres Frontier-Modell gewählt. Die Aufgabe ist recht vorhersehbar, und heutige Open-Weight-Modelle würden sie wahrscheinlich bewältigen. Die Lösung entstand jedoch zu einer Zeit, in der der Qualitätsunterschied größer war. Das ist eine gute Erinnerung daran, dass eine Entscheidung, die im ursprünglichen Entwurf richtig war, zwei Jahre später nicht zwangsläufig die günstigste ist.

Bei einem Projekt für ein Bauunternehmen sind wir bei Frontier-Modellen geblieben. Die Aufgaben umfassen uneindeutige Klassifizierung, die Extraktion der wesentlichen Informationen und den Vergleich von Anforderungen. Das Volumen ist dabei relativ gering. Lokale Infrastruktur für eine kleine Zahl anspruchsvoller Fälle zu kaufen und zu betreiben, wäre teurer und wahrscheinlich auch schlechter.

Drei Projekte, drei richtige Architekturen. Genau deshalb ergibt eine einzige unternehmensweite Antwort für alle Use Cases keinen Sinn.

Hybrid ist nicht das Ziel. Es ist das Ergebnis von Messungen

Ein hybrider Ansatz klingt modern: einfache Aufgaben lokal, komplizierte auf Frontier-Modellen und die Cloud als Versicherung gegen Überlast. In vielen Unternehmen wird das die richtige Zielarchitektur sein. Der automatische Ausgangspunkt sollte es aber nicht sein, denn zwei Umgebungen, Routing und Monitoring bringen eigene Komplexität mit sich.

Ich würde mit einem Modell beginnen, Qualität, Volumen und Fehler messen und erst danach die einzelnen Aufgabentypen aufteilen. Wenn wir feststellen, dass 80 % der Anfragen einfache, wiederkehrende Klassifizierungsaufgaben sind, verschieben wir diese auf ein günstigeres oder lokales Modell. Die komplizierten Fälle bleiben auf Frontier-Modellen.

Genauso vorsichtig wäre ich beim Fine-Tuning, also dem nachträglichen Weitertrainieren eines Modells. Für die meisten Unternehmen sollte es nicht der erste Schritt sein. Zuerst brauchen wir gute Tests, den richtigen Kontext, eine solide Suche in internen Daten und einen klaren Prozess. Fine-Tuning lohnt sich bei einer engen, stabilen Aufgabe mit hohem Volumen, etwa wenn wir damit ein großes Modell durch ein kleineres ersetzen können. Ein Modell zu trainieren, bevor wir seine Fehler zuverlässig messen können, ist nur eine teurere Art des Ratens.

Was Unternehmen nach dem Pilotprojekt wirklich überrascht

Am häufigsten sind es nicht die Kosten, sondern die Zahl der Fehler. Wir testen das Pilotprojekt an fünfzig sauberen Fällen; im Produktivbetrieb kommen fünftausend unsaubere. Selbst eine Fehlerquote von 1 % bedeutet fünfzig fehlerhafte Fälle. Ein gutes Testset und ein Prozess für die menschliche Kontrolle sind deshalb oft eine wertvollere Investition als der Wechsel zur nächsten Modellgeneration.

Die zweite Überraschung sind die tatsächlichen Kosten einer einzelnen Aufgabe. Bei Modellen mit erweitertem Reasoning werden auch die internen Reasoning-Token abgerechnet, die in der endgültigen Antwort nie sichtbar werden. Ein Agent kann das Modell zudem mehrfach aufrufen, bezahlte Tools nutzen, eigene Fehler korrigieren und den Kontext erneut lesen. Wir messen die Kosten deshalb nicht an einer einzelnen Antwort im Chat, sondern am gesamten abgeschlossenen Geschäftsprozess.

Fünf Fragen, die sich das Management stellen sollte

Vor einer Entscheidung würde ich nicht nach einer Liste der besten Modelle fragen. Ich würde fragen:

Welche Qualität ist tatsächlich erforderlich, und was kostet ein Fehler?
Ist die Last stabil, oder haben wir kurze, unvorhersehbare Spitzen?
Müssen die Daten lokal bleiben, oder genügt uns ein sauber konfigurierter Cloud-Dienst für Unternehmen?
Haben wir die Menschen und die Infrastruktur, um ein Modell rund um die Uhr zu betreiben?
Was tun wir, wenn sich das Modell, der Preis oder die Bedingungen des Dienstes ändern?

Wenn Sie auf diese Fragen keine Antworten haben, ist es noch nicht an der Zeit, Hardware zu kaufen oder einen langfristigen Cloud-Vertrag zu unterschreiben. Es ist Zeit zu messen.

Eine Empfehlung zum Schluss

Meine praktische Empfehlung ist einfach: Starten Sie einen neuen, unsicheren oder anspruchsvollen Use Case auf einem Frontier-Modell. Wählen Sie die günstigste Stufe, die Ihre eigenen Tests besteht. Messen Sie die Kosten eines abgeschlossenen Falls, die Zeit der Mitarbeitenden und die Kosten von Fehlern, nicht nur die Zahl der Token.

Setzen Sie ein Open-Weight-Modell dort ein, wo Sie einen konkreten Grund haben: stabile und hohe Last, eine echte Anforderung, Daten lokal zu halten, der Bedarf an Offline-Betrieb, vorhandene Infrastruktur oder die strategische Notwendigkeit, eine unveränderte Modellversion unter eigener Kontrolle zu halten.

Und auch wenn heute alles in der Cloud läuft: Fangen Sie an, mit Open-Weight-Modellen zu experimentieren, bevor Sie sie dringend brauchen. Nicht mit einem großen Hardwarekauf, sondern mit einer kleinen Testumgebung und Ihren eigenen Daten.

In den nächsten 12 bis 24 Monaten dürften Open-Weight-Modelle weiter stärker und kleiner werden. Der Preis eines einzelnen API-Tokens muss nicht steigen; der Wettbewerb dürfte ihn eher nach unten drücken. Die Gesamtrechnung von Unternehmen kann dennoch steigen, weil agentische Systeme mehr Zwischenschritte ausführen, mehr Tools nutzen und einen größeren Teil der Arbeit übernehmen. Das wertvollste Gut eines Unternehmens wird deshalb nicht der Modellname in seiner Architektur sein. Es wird die Fähigkeit sein, schnell herauszufinden, ob ein neues Modell die konkrete Arbeit dieses Unternehmens besser, sicherer und günstiger erledigt.

Ein Unternehmen sollte keine GPUs kaufen, weil ihm die Token-Rechnung Angst macht. Und es sollte nicht in der Cloud bleiben, nur weil das bequem ist. Zuerst muss es wissen, was ein korrektes Ergebnis ist, welchen Wert es hat und was passiert, wenn der Dienst morgen verschwindet. Erst dann ist die Wahl des Modells eine Managemententscheidung und keine technologische Wette.

Stanislav Gabčo & INSYNAPS

Verwandt

Eine ähnliche Herausforderung in Ihrem Unternehmen?

Erzählen Sie uns von Ihrem Workflow. Wir sagen Ihnen ehrlich, ob KI sinnvoll ist – auch dann, wenn die Antwort „Nein“ lautet.