Wann ein kleineres KI-Modell genügt

Der Standardweg, 2026 eine KI-Funktion zu bauen, ist, das größte verfügbare Modell aufzurufen und weiterzumachen. Das funktioniert, ist schnell ausgeliefert und für einen wirklich offenen Assistenten die richtige Wahl. Für den weit häufigeren Fall, ein System, das mehrere tausend Mal am Tag eine eingehende Anfrage liest oder sechs Felder aus einer Rechnung extrahiert, zahlt es still zu viel für Fähigkeiten, die die Aufgabe nie nutzt.

Agentenarbeit wiederholt sich, und wiederholte Arbeit ist eng

Ein Agent im Produktivbetrieb führt selten ein weit ausgreifendes Gespräch. Er klassifiziert, extrahiert, leitet weiter, ruft ein Werkzeug mit strukturierten Argumenten auf oder entscheidet zwischen einer Handvoll nächster Schritte. Dieselbe Prompt-Form läuft immer wieder, nur mit anderem Inhalt.

Ein Team bei NVIDIA hat dieses Argument formal in Small Language Models are the Future of Agentic AI vorgebracht, erstmals veröffentlicht im Juni 2025 und im September überarbeitet. Ihre Arbeitsdefinition von klein ist ein Modell, das auf ein gängiges Endgerät passt und schnell genug antwortet, um nützlich zu sein, was Stand 2025 grob alles unter 10 Milliarden Parametern bedeutet.

Ihre wirtschaftliche Aussage ist die konkrete. Der Betrieb eines Modells mit 7 Milliarden Parametern ist 10- bis 30-mal günstiger als der eines Modells mit 70 bis 175 Milliarden Parametern, gemessen an Latenz, Energieverbrauch und Gleitkommaoperationen. Für einen Workflow, der ein paar hundert Mal im Monat aufgerufen wird, ist der Unterschied ein Rundungsfehler. Für einen, der ununterbrochen läuft, ist er der Unterschied zwischen einem System, das sich trägt, und einem, das es nicht tut.

Bei den Fähigkeiten verweisen sie auf Modelle wie Phi-2 mit 2,7 Milliarden Parametern, das bei Alltagslogik und Codegenerierung Werte erreicht, die mit Modellen seiner Generation mit 30 Milliarden Parametern vergleichbar sind. Kleiner heißt bei einer bestimmten Aufgabe nicht automatisch schwächer.

Feinabstimmung auf die Aufgabe verändert den Vergleich völlig

Das deutlichere Ergebnis zeigt sich, wenn ein kleines Modell gezielt auf die enge Aufgabe trainiert wird, die Sie brauchen.

Forschende haben facebook/opt-350m, ein Modell mit 350 Millionen Parametern, auf dem ToolBench-Datensatz für agentische Werkzeugaufrufe feinabgestimmt und eine Bestehensquote von 77,55 % gemeldet, gegenüber 26,00 % für ChatGPT mit Chain-of-Thought-Prompting bei rund 175 Milliarden Parametern. Das ist ein 500-mal kleineres Modell, das bei der Aufgabe, für die es trainiert wurde, etwa dreimal besser abschneidet.

Wenden Sie jetzt die Disziplin aus dem vorherigen Beitrag zur Evaluation auf diese Zahl an, denn sie verdient dieselbe Prüfung wie jedes Anbieterdiagramm.

Das feinabgestimmte Modell wurde auf ToolBench trainiert und auf ToolBench gemessen. Es kennt die Verteilung. Die Frontier-Vergleichsmodelle wurden auf dieser Verteilung nur gepromptet, nicht trainiert. Das kommt dem fairsten verfügbaren Vergleich für die Frage “kann ein kleines spezialisiertes Modell ein großes allgemeines bei einer spezialisierten Aufgabe schlagen” nahe. Es ist auch eine enge Aussage und sollte als solche gelesen werden. Ein Modell mit 350 Millionen Parametern übertrifft ein Frontier-Modell nicht allgemein, und nichts in der Studie behauptet das.

Was das Ergebnis stützt, ist der operative Punkt. Wenn Sie die Aufgabe eng genug definieren können, um Trainingsdaten dafür zu erstellen, konkurriert ein kleines, darauf trainiertes Modell mit einem großen, höflich gefragten Modell und schlägt es oft. Die Bedingung ist, die Definitionsarbeit zu leisten.

Die Entscheidungsregel

Die Frage ist nicht, welches Modell das beste ist. Sie lautet, ob Ihre Aufgabe spezifizierbar ist.

Wählen Sie ein kleines Modell, wenn die Aufgabe eine begrenzte Eingabe und eine prüfbare Ausgabe hat, Sie ein paar hundert gelabelte Beispiele zusammenstellen können, das Volumen hoch genug ist, dass Stückkosten zählen, Latenz von einem Nutzer oder einer Warteschlange gespürt wird oder die Daten Ihre Infrastruktur nicht verlassen dürfen. Dokumentextraktion, Lead-Scoring nach schriftlichen Regeln, Ticket-Routing, strukturierte Werkzeugaufrufe und Klassifikation gehören alle hierher.

Wählen Sie ein Frontier-Modell, wenn die Eingabe wirklich offen ist, die Arbeit Wissen verlangt, das Sie nicht aufzählen können, das Volumen so niedrig ist, dass die Kosten pro Aufruf Rauschen sind, oder Sie noch herausfinden, was die Aufgabe überhaupt ist. Frühe Erkundung ist Arbeit für ein Frontier-Modell, ebenso alles, was ein Mensch als Fließtext lesen wird.

Nutzen Sie beide, wenn sich die Arbeit sauber aufteilt. Das Positionspapier von NVIDIA plädiert genau deshalb für heterogene Systeme: den repetitiven Großteil an ein kleines Modell leiten und die wirklich neuen Fälle an ein großes eskalieren. Die meisten Produktivsysteme, die wir betreiben, haben diese Form, weil die meisten Arbeitslasten überwiegend Routine sind, mit einem Ausläufer, der es nicht ist.

Groß anfangen, dann auf Grundlage von Belegen verkleinern

Das kleine Modell zuerst zu wählen ist ein Fehler, weil Sie keine Aufgabe spezifizieren können, bei der Sie noch niemandem zugesehen haben. Die Reihenfolge, die funktioniert:

1. Mit einem Frontier-Modell bauen. Den Workflow korrekt hinbekommen und echten Eingaben aussetzen. Noch nichts optimieren.
2. Jeden Aufruf protokollieren. Eingaben, Ausgaben und die menschlichen Korrekturen. Daraus werden Trainings- und Evaluationsdaten, und das Sammeln kostet nichts, wenn Sie am ersten Tag beginnen.
3. Warten, bis sich die Aufgabe nicht mehr ändert. Ein Workflow, der noch überarbeitet wird, ist nicht bereit für die Spezialisierung. Ein bewegliches Ziel feinabzustimmen verschwendet die Arbeit doppelt.
4. Die zurückgehaltene Evaluation aufbauen. Echte Fälle von Hand labeln, auch die, über die Ihr Team streitet, und einen Teil ungesehen lassen.
5. Ein kleines Modell gegen diesen Satz testen. Besteht es die Messlatte, ändert sich die Kostenkurve um eine Größenordnung. Wenn nicht, haben Sie ein paar Tage verloren und eine Evaluation gewonnen, die Sie ohnehin brauchten.

Scheitert Schritt 5, war die Übung nicht umsonst. Der gelabelte Satz ist das, was Ihnen sagt, ob das System überhaupt funktioniert, mit welchem Modell auch immer.

Wo das kleine Modell nicht hingehört

Einiges davon lohnt sich klar zu sagen, weil das Kostenargument verführerisch ist.

Ein kleineres Modell kommt in der Regel schlechter mit Eingaben zurecht, die nichts ähneln, worauf es trainiert wurde, und der Produktivbetrieb erzeugt solche Eingaben zuverlässig. Es hat weniger Weltwissen, auf das es zurückgreifen kann, wenn der Prompt unterspezifiziert ist. Und ein Modell, das auf die Verteilung des letzten Quartals feinabgestimmt wurde, verschlechtert sich, wenn sich die Verteilung verschiebt, was bedeutet, dass jemand für das Nachtrainieren zuständig ist und jemand dafür, es zu bemerken.

Die Einsparungen bleiben real, und sie bleiben an Bedingungen geknüpft. Die Bedingung ist dieselbe wie immer: Sie messen es an Ihren eigenen Daten und messen weiter. Ein System, das niemand beobachtet, ist bei keiner Modellgröße günstig.

Wie wir das anwenden

Die Modellwahl findet innerhalb der Entwicklung statt, nachdem der Workflow verstanden ist. Jedes System in unserem Katalog für KI-Systeme wird als ein begrenzter Workflow mit einer schriftlichen Erfolgskennzahl zugeschnitten, die vor der Entwicklung vereinbart wird, und genau das ist die Spezifikation, die ein kleines Modell braucht. Unser Produktions-Retainer existiert, weil die Messung nicht beim Launch endet: Ausgaben werden monatlich gegen Ausgangswerte geprüft, und genau das fängt ein spezialisiertes Modell ab, das sich von einer sich bewegenden Aufgabe entfernt.

Wenn der Workflow noch entdeckt wird, bauen wir ihn auf einem Frontier-Modell und sagen das auch. Die Einsparungen sind später verfügbar, auf Grundlage von Belegen.

Quellen

• Small Language Models are the Future of Agentic AI, Belcak, Heinrich, Diao, Fu, Dong, Muralidharan, Lin und Molchanov: arxiv.org/abs/2506.02153
• Small Language Models for Efficient Agentic Tool Calling: Outperforming Large Models with Targeted Fine-tuning, Jhandi, Kazi, Subramanian und Sendas: arxiv.org/html/2512.15943v2