Über die Hälfte der großen IT-Unternehmen setzt bereits KI-Agenten ein, 21 % davon erst seit dem letzten Jahr. Laut NVIDIA-Analyse produktiver Agentensysteme wären 40 bis 70 % dieser Aufrufe durch spezialisierte Small Language Models ersetzbar – zu 10 bis 30-mal geringeren Kosten. Die meisten Unternehmen haben diese Rechnung noch nicht gemacht.
Über die Hälfte der großen IT-Unternehmen setzt inzwischen KI-Agenten ein, ein Fünftel davon erst seit dem vergangenen Jahr. Was in den seltensten Steuerungsrunden ankommt: Ein Großteil dieser Agenten-Aufrufe braucht gar kein Frontier-Modell.
NVIDIA hat drei produktive Agentensysteme – MetaGPT, Open Operator, Cradle – durchleuchtet und kommt auf 40 bis 70 % der Aufrufe, die ein spezialisiertes Small Language Model genauso gut erledigt, zu 10 bis 30-mal geringeren Betriebskosten. Das ist keine Nischenoptimierung. Das ist der Unterschied zwischen einem KI-Piloten, der ein Kostenzentrum bleibt, und einem, der sich rechnet.
Nichts Revolutionäres – und genau das ist der Punkt. SLMs sind Modelle mit typischerweise ein bis acht Milliarden Parametern, ein Bruchteil dessen, was aktuelle LLMs mit bis zu 400 Milliarden Parametern mitbringen. Sie sind keine kleineren Generalisten. Sie sind Spezialisten: gebaut für Extraktion, Klassifikation, Routing oder Zusammenfassung nach Vorlage – Aufgaben mit definiertem Input, definiertem Output, wenig Varianz.
Der Unterschied zu einem LLM liegt nicht in der Cleverness. Er liegt im Betriebsprofil: geringerer Infrastrukturbedarf, planbare Latenz, einfachere Versionierung. Für eine offene, schwer zerlegbare Aufgabe bleibt das LLM die richtige Wahl. Für alles andere ist die eigentliche Frage, warum dafür noch ein Generalmodell bezahlt wird.
Die Behauptung ist eine Sache. Die Zahlen dahinter eine andere:
SLMs sind kein abstraktes Effizienzthema. Sie lösen ein sehr konkretes Problem: Für die meisten wiederkehrenden Enterprise-Aufgaben bezahlt man aktuell Generalisten-Preise für Spezialisten-Arbeit.
Multi-Agent-Rollenmodelle – ein Extraktionsagent, ein Klassifikationsagent, ein Summarization-Agent, ein QA-Agent – klingen auf der Folie bestechend sauber. Das Problem ist nicht das Modell. Das Problem ist die Voraussetzung, die dabei stillschweigend übersprungen wird.
Eine Rolle lässt sich einem SLM nur dann sinnvoll zuweisen, wenn die Aufgabe dahinter bereits granular genug verstanden ist: definierter Input, definierter Output, definierte Fehlerklasse. Wer diesen Schritt auslässt und direkt in die Agentenarchitektur einsteigt, automatisiert nicht den Prozess. Er automatisiert die eigene Unklarheit über den Prozess – nur schneller, und mit mehreren Komponenten, die im Zweifelsfall gleichzeitig falsch liegen.
Erst wenn der Prozess zerlegt ist, wird die Modellfrage konkret beantwortbar. Zwei Beispiele, wie unterschiedlich diese Antwort ausfällt:
Ist Ihr Anwendungsfall bereits in Schritte mit definiertem Input und Output zerlegt? Wenn nicht, ist genau das die Hausaufgabe – nicht die Entscheidung zwischen SLM und LLM.
Welche Ihrer aktuellen Agenten-Aufrufe sind tatsächlich Routine? Die 40-bis-70-%-Zahl ist kein Branchendurchschnitt, den Sie automatisch erben – Sie müssen ihn für sich selbst messen.
Zwei bis drei Modelle nach Golden Set, P95-Latenz und Formatfehlerquote vergleichen. Erst wenn Qualität und Betrieb zusammenpassen, wird skaliert.
Containerisierung, API-Gateway, Observability – SLM-Einführung ist ein Servicethema, kein Modell-Thema. Wer das nachträglich klärt, klärt es unter Zeitdruck.
Können wir für unsere aktuellen Agenten-Workflows benennen, welcher Anteil der Aufrufe Routine ist – und welcher echte Offenheit braucht?
Haben wir die Prozessgranularität, um zu entscheiden, welches Modell zu welcher Teilaufgabe passt – oder bauen wir gerade einen Agenten, bevor wir den Prozess verstanden haben?
Zahlen wir aktuell Frontier-Preise für Aufgaben, die nachweislich in die 40-bis-70-%-Kategorie fallen, die ein SLM ebenso gut könnte?
Alle 14 Tage ein Deep Dive, der einordnet statt zu hypen. Kein Newsletter-Geplänkel, sondern Klartext für Entscheider:innen.