Welche volumenstarken Aufgaben Sie einem kleinen Sprachmodell geben sollten

Was eine Aufgabe für ein kleines Modell geeignet macht

Belcak und Kollegen argumentieren in einem 2025 erstmals veröffentlichten Positionspapier, dass agentische Systeme viele Modellaufrufe machen, die wenige spezialisierte Aufgaben wiederholt und mit geringer Variation ausführen, und dass kleine Modelle dafür oft leistungsfähig genug und günstiger sind. Der Latenz-Leitfaden von OpenAI formuliert es praktisch: Klar definierte Aufgaben mit begrenztem Umfang sind gute Kandidaten für ein kleineres, eventuell feingetuntes Modell, offene Antworten eines Assistenten überlässt man besser einem größeren.

Übersetzt in Fragen zu Ihrer eigenen Arbeitslast:

• Ist die Ausgabe eingeschränkt? Eine Kategorie, ein JSON-Objekt mit bekannten Feldern oder ein Ja oder Nein ist einfacher als freier Text.
• Wiederholen sich die Eingaben in ihrer Struktur, etwa dasselbe Formular, dieselbe Ticketvorlage oder derselbe Dokumenttyp?
• Kann jemand sagen, ob eine Antwort richtig ist? Ohne überprüfbare Antwort lässt sich kein kleineres Modell testen.
• Braucht die Aufgabe Fakten, die nicht in der Eingabe stehen? Dann ist ein größeres Modell oder Retrieval die sicherere Wahl.
• Was kostet eine falsche Antwort, und gibt es einen Fallback oder eine prüfende Person?

Eine hypothetische Aufgabenliste prüfen

Angenommen, das Plattformteam eines Versicherers listet seine fünf volumenstärksten Modellaufrufe auf. Volumen und Einschätzungen sind hypothetisch und so formuliert, wie ein Team die Prüfung in einem Workshop ausfüllen könnte.

• Sortierung von E-Mails in 14 Warteschlangen, 40.000 pro Tag: eingeschränkte Ausgabe, gleichförmige Eingaben, Labels aus früherem Routing. Starker Kandidat.
• Feldextraktion aus Schadenformularen, 25.000 pro Tag: feste Felder, bekannte Vorlagen, korrigierte Werte im Schadensystem. Starker Kandidat.
• Zusammenfassungen von Schadenakten für Sachbearbeiter, 6.000 pro Tag: freier Text, lange Eingaben, Qualität wird von Menschen beurteilt. Schwacher Kandidat.
• Kundenfragen zu Policen, 3.000 pro Tag: hängt vom aktuellen Wortlaut der Bedingungen und von breiterem Schlussfolgern ab. Besser mit Retrieval und einem größeren Modell.
• Begründungen für Betrugsverdachtsmeldungen, 400 pro Tag: hohes Risiko, geringes Volumen. Selbst bei angenommenen 10 € pro 1.000 Aufrufen kosten 12.000 Aufrufe im Monat etwa 120 €, weit weniger als Aufbau, Evaluierung und Prüfung eines Modells. Ein eigenes Modell bräuchte eine Qualitätsbegründung, keine Kostenbegründung.

Zwei Kandidaten bleiben aus Kostensicht übrig. Das Team beginnt mit der E-Mail-Sortierung, weil ihre Labels sauberer sind und eine falsch zugeordnete E-Mail Minuten kostet und keine falsche Schadenentscheidung.

Erst testen, dann trainieren

Finden Sie heraus, wie weit ein kleines Modell ohne Fine-Tuning kommt. Lassen Sie ein oder zwei kleine gehostete oder Open-Weight-Modelle auf zurückgehaltenen Fällen der Aufgabe laufen, mit demselben Prompt und Parser wie das aktuelle Modell. Jedes der drei möglichen Ergebnisse zeigt den nächsten Schritt.

• Es erreicht das aktuelle Modell bereits: Wechseln Sie per Modell- und Promptänderung und lassen Sie das Training weg.
• Es kommt nahe heran, und die Fehler ballen sich in wenigen Kategorien: Gelabelte Beispiele können das Fehlende wahrscheinlich beibringen.
• Es liegt überall zurück: Die Aufgabe ist wahrscheinlich weniger eng, als sie schien. Prüfen Sie die Einordnung erneut.

Die Fine-Tuning-Dokumentation von OpenAI beschreibt einen weiteren Weg, der genauso mit einem Open-Weight-Modell funktioniert, das Sie in Ihrer eigenen Umgebung trainieren: den Prompt eines größeren Modells verbessern, bis es gut abschneidet, seine Ausgaben behalten, die Ihre Kriterien erfüllen, und damit ein kleineres Modell trainieren. Das hilft, wenn gelabelte Daten knapp sind, aber das kleine Modell übernimmt die Fehler des großen.

Die Wirtschaftlichkeit mit Ihrem eigenen Volumen rechnen

Kleinere gehostete Modelle sind pro Token oft günstiger, der Abstand hängt aber von Anbieter und Arbeitslast ab, und ein selbst betriebenes Modell kostet Geld, ob Anfragen kommen oder nicht. Vergleichen Sie die Monatskosten bei Ihrem Volumen: die aktuellen Kosten pro Anfrage mal Volumen gegenüber festen Serving-Kosten plus dem Aufwand für Daten, Training, Evaluierung und Monitoring.

Eine hypothetische Rechnung mit offengelegten Annahmen: Das aktuelle Modell kostet 3 € pro 1.000 sortierte E-Mails, 1,2 Millionen E-Mails pro Monat kosten also 3.600 €. Eine GPU zu angenommenen 1,50 € pro Stunde kostet im Dauerbetrieb etwa 1.100 € pro Monat, noch ohne den gehosteten Fallback für Lastspitzen. Die Differenz von rund 2.500 € pro Monat muss Engineering und Nachtraining bezahlen. Unter diesen Annahmen würde die GPU bei einem Zehntel des Volumens mehr kosten als das Modell, das sie ersetzt. Dann lohnt es sich, ein kleineres gehostetes Modell zu testen, sofern Preis, Ergebnisse auf Ihren zurückgehaltenen Fällen und Datenverarbeitung passen.

Manche Gründe stehen nicht auf der Rechnung: Antwortzeit und Daten, die auf Ihren eigenen Systemen bleiben müssen. Die Evaluierungshinweise von Hugging Face ergänzen, dass ein Modell, das auf eine GPU passt, viel einfacher zu betreiben ist als eines, das auf mehrere verteilt werden muss.

Wo kleine Modelle enttäuschen

Der typische Fehlschlag ist eine Aufgabe, die auf dem Papier enger ist als in der Produktion. E-Mail-Sortierung sieht nach 14 Labels aus, bis manche E-Mails zwei Anliegen enthalten, eine rechtliche Drohung im Nachsatz oder eine Sprache, mit der niemand gerechnet hat. Messen Sie diese Randfälle und leiten Sie sie an das größere Modell weiter, statt ihnen ein Label aufzuzwingen.

Der andere Fehlschlag ist Drift. Warteschlangen, Produkte und Richtlinien ändern sich, und ein kleines Modell, das auf den Labels des Vorjahres trainiert wurde, merkt das nicht. Legen Sie vor dem Start fest, wer es nachtrainiert und auf welches Signal hin.