Small LLM vs. Frontier Model: Was braucht Ihr KI-Feature wirklich?

Die meisten KI-Features in einem SaaS-Produkt brauchen kein Frontier Model. Ist die Aufgabe klar umgrenzt – ein Ticket klassifizieren, Felder aus einem Dokument extrahieren, eine E-Mail auf Basis vorhandener Fakten verfassen –, reicht ein kleines Modell mit striktem Prompt und Output-Validator in der Regel völlig aus, zu einem Bruchteil der Kosten pro Call. Frontier Models reservieren Sie für offenes Reasoning, lange mehrstufige Tool-Nutzung und überall dort, wo ein Fehler echtes Geld kostet.

Die richtige Frage ist nicht „Welches Modell ist das klügste?"

Gründer fragen uns oft, welches Modell das beste ist. Das ist die falsche Frage. Das beste Modell auf einem Leaderboard ist selten das beste Modell für ein Feature, das fünfzigtausend Mal im Monat in Ihrem Produkt läuft. Die richtige Frage lautet: Was ist das günstigste Modell, das mein Eval-Set mit der nötigen Genauigkeit besteht – bei den Guardrails, die ich mir leisten kann zu bauen?

Nehmen Sie das Ticket-Klassifikations-Beispiel vom Anfang dieses Beitrags und machen Sie es konkret. Bei fünfzigtausend Tickets im Monat werden der Leaderboard-Gewinner und ein destilliertes „Flash"-Modell die eindeutigen Tickets gleich einordnen. Der Unterschied zeigt sich bei den mehrdeutigen – und ein Validator, der das Tag gegen Ihre erlaubte Liste prüft und bei einem Fehler einen Retry auslöst, fängt einen guten Teil dessen ab, was das kleine Modell falsch macht. Ob der verbleibende Rest akzeptabel ist, lässt sich nur herausfinden, indem Sie fünfzig bis einige hundert echte Tickets aus Ihrem Eval-Set durch beide Modelle laufen lassen und die Ergebnisse vergleichen – mit dem Preis pro Call direkt daneben.

So betrachtet hört die Entscheidung auf, eine Wette auf Vendor-Marketing zu sein, und wird zu einer technischen Messung. Die Kategorie der kleinen Modelle hat sich schnell weiterentwickelt; die jüngste Welle von „Flash"- und Distillation-Releases mehrerer Labs bedeutet, dass ein Modell, das vor zwei Jahren State-of-the-Art gewesen wäre, heute sehr wenig pro Token kostet und auf einer einzelnen GPU läuft. Ob das für Sie ausreicht, hängt von vier Dingen ab.

Vier Fragen, die die Entscheidung treffen

1. Ist die Aufgabe klar umgrenzt?

Eine umgrenzte Aufgabe hat eine bekannte Input-Form, eine bekannte Output-Form und eine kleine Menge zulässiger Antworten. „Extrahiere Rechnungsnummer, Fälligkeitsdatum und Gesamtbetrag aus diesem PDF" ist umgrenzt. „Lies die letzten sechs E-Mails dieses Kunden und entscheide, was zu tun ist" nicht.

Kleine Modelle sind bei umgrenzten Aufgaben stark, weil der Prompt den Großteil der Intelligenz tragen kann: das Schema, die Regeln, drei ausgearbeitete Beispiele. Bei offenen Aufgaben nehmen sie ab, weil Improvisation gefragt ist – und genau das verschlechtert sich mit sinkender Parameterzahl.

2. Lässt sich der Output günstig prüfen?

Wenn eine deterministische Prüfung die meisten schlechten Outputs abfangen kann, können Sie ein kleineres Modell einsetzen und den Validator die schwere Arbeit erledigen lassen. JSON-Schema-Validierung, Regex auf Datumsangaben und Beträge, ein Abgleich mit Ihrer eigenen Datenbank, ein Längenlimit: Das kostet nichts pro Call und macht aus dem gelegentlichen Fehler eines Modells einen Retry statt einen Bug, den ein Kunde sieht. Wir haben dieses Muster in deterministischen Guardrails für die Zuverlässigkeit von KI-Features beschrieben.

Wenn der Output nur durch menschliches Lesen geprüft werden kann, muss das Modell von Anfang an öfter richtig liegen – das treibt Sie die Preisliste hinauf.

3. Was kostet ein falsches Ergebnis?

Ein falsch getaggtes Support-Ticket kostet einen Agenten zehn Sekunden. Eine falsche Dosierungsangabe in einem Healthcare-Tool oder eine falsche Rückerstattungsentscheidung in einem E-Commerce-Agenten kostet erheblich mehr. Bepreisen Sie den Fehler, nicht den Call. Wo der Fehler günstig ist, optimieren Sie auf Kosten pro Call. Wo er teuer ist, ist der Token-Aufpreis des Frontier Models im Vergleich zum Risiko vernachlässigbar – und Sie sollten unabhängig vom Modell einen menschlichen Review-Schritt einbauen.

4. Passt der Input, und braucht es Gedächtnis?

Kleine Modelle haben typischerweise einen kürzeren nutzbaren Kontext und verlieren sich schneller in langen Dokumenten. Wenn Ihr Feature einen 200-seitigen Vertrag im Blick halten oder den Zustand über einen zwanzigstufigen Workflow hinweg tragen muss, müssen Sie entweder aggressiv chunken (mehr Engineering) oder für ein Modell zahlen, das den Überblick behält. Mehrstufige agentische Arbeit mit Tools ist der klarste Fall für Frontier Models – und es lohnt sich, Agents vs. Workflows zu lesen, bevor Sie davon ausgehen, den Agenten überhaupt zu benötigen.

Wofür ein kleines Modell wirklich taugt: unser Outreach-Engine

Unser eigenes Outbound-Tool ist ein konkretes Beispiel. Es crawlt die Website jedes Prospects mit einer selbst gehosteten Firecrawl-Instanz, übergibt den Seitentext an ein lokales Modell und verfasst pro Unternehmen eine maßgeschneiderte E-Mail. Die Aufgabe ist umgrenzt: Der Input sind einige Seiten Text, der Output ist eine kurze E-Mail nach unserer Vorlage und in unserem Ton – und ein Validator lehnt alles ab, was zu lang ist, ein Produkt erwähnt, das wir nicht anbieten, oder keinen Fakt von der Website zitiert.

Was uns überraschte: Ein einziger Call, der „Fakten extrahieren und E-Mail verfassen" kombiniert, schlug eine mehrstufige Chain (extrahieren, dann planen, dann schreiben) sowohl bei Kosten als auch bei Qualität – sogar mit dem kleineren Modell. Weniger Hops bedeuteten weniger Stellen, an denen das Modell vom Quelltext abdriften konnte. Den allgemeinen Fall haben wir in Single Call vs. Agent Chains beschrieben. Die Botschaft für Käufer: Ein gut eingeschränktes kleines Modell plus Validator war das richtige Werkzeug; ein Frontier Model hätte Kosten hinzugefügt, ohne die Reply-Rate zu verbessern.

Wann Sie für ein Frontier Model zahlen sollten

Seien Sie ehrlich bei den Fällen, in denen billig teuer wird. Der oben beschriebene Outreach-Engine kommt aus einem einzigen Grund mit einem kleinen Modell aus: Es gibt einen einzigen Hop – Seitentext rein, E-Mail raus –, mit einem Validator dahinter. Entfällt eine dieser Bedingungen, ändert sich das Bild.

• Offenes Reasoning über unstrukturierten Input. Triage, die Urteilsvermögen erfordert, keine Regeln. Alles, wo die Anweisungen lauten: „Verwenden Sie Ihr Ermessen." Unser Validator kann eine E-Mail ablehnen, die keinen Fakt von der Website zitiert; er kann nicht beurteilen, ob das Modell den richtigen Fakt gewählt hat – und wenn genau dieses Urteil das ganze Feature ausmacht, wollen Sie das stärkere Modell.
• Mehrstufige Tool-Nutzung. Agents, die mehrere APIs aufrufen, Ergebnisse interpretieren und den nächsten Schritt entscheiden. Sobald unsere Aufgabe zu „Website crawlen, relevante Seiten identifizieren, CRM prüfen, dann schreiben" würde, müsste das kleine Modell den Zustand über Hops hinwegtragen – genau dort, wo es den Faden verliert.
• Geringes Volumen, hoher Wert pro Call. Läuft das Feature einige hundert Mal im Monat und wird jedes Ergebnis von einer erfahrenen Person geprüft, ist der Kostenunterschied vernachlässigbar. Kaufen Sie Genauigkeit.
• Code-Generierung und komplexe Transformationen. Die Qualitätslücke ist hier nach wie vor groß.
• Die erste Version, bevor Sie Evals haben. Es ist oft günstiger, mit einem starken Modell zu launchen, echten Traffic zu sammeln, aus diesem Traffic ein Eval-Set mit fünfzig bis einigen hundert echten Beispielen zu bauen – und dann dort downzugraden, wo die Evals es erlauben.

Dieser letzte Punkt ist entscheidend. Mit einem Frontier Model zu starten und schrittweise zu wechseln ist eine fundierte Entscheidung auf Basis eines Eval-Sets. Mit einem kleinen Modell zu starten und in der Produktion festzustellen, dass es nicht ausreicht, bedeutet: Prompts und Guardrails unter Druck neu schreiben – ohne Eval-Set, das Ihnen sagt, wann Sie fertig sind.

Wie die Modellwahl Ihr Angebot verändert

Gründer erwarten, dass das kleine Modell das Projekt günstiger in der Umsetzung macht. Das tut es meist nicht. Die Buildkosten stecken im Prompt-Design, im Validator, im Eval-Set, in der Retry-und-Fallback-Logik und in der Integration in Ihr Produkt. Diese Arbeit ist dieselbe, egal welches Modell dahintersteckt. Wenn überhaupt, braucht ein kleines Modell eine dickere Validierungsschicht – das ist etwas mehr Engineering, nicht weniger.

Was sich ändert, sind die laufenden Kosten. Die Preise pro Call zwischen einem Frontier Model und einem kleinen gehosteten Modell unterscheiden sich um ein Vielfaches – und über ein Jahr echten Traffic kann dieser Unterschied das ursprüngliche Build-Budget übersteigen. Lassen Sie sich eine Hochrechnung für drei Volumenszenarien zeigen, bevor Sie unterschreiben; unser Leitfaden zur LLM-Kostenoptimierung listet die wichtigsten Stellschrauben jenseits der Modellwahl auf – etwa Caching und Prompt-Länge.

Das Selbst-Hosten eines kleinen Modells ist eine separate Entscheidung. Tools wie vLLM und Ollama machen es technisch einfach, aber es rechnet sich nur bei gleichmäßigem Volumen oder wenn Data-Residency-Anforderungen es erzwingen. Bei typischen Early-Stage-Volumina gewinnt ein günstiges gehostetes API-Modell, sobald man den Engineering-Aufwand einrechnet.

Die clevere Absicherung: den Schalter bauen, nicht die Wette eingehen

Wie auch immer Sie entscheiden – lassen Sie es nicht in den Code einbetonieren. Bestehen Sie auf drei Dingen im Briefing:

• Modell hinter einem einzigen Config-Wert. Der Wechsel von einem Frontier Model zu einem kleinen Modell oder zwischen Providern sollte ein Deployment sein, kein Sprint.
• Ein Eval-Set, das mit dem Feature ausgeliefert wird. Fünfzig bis einige hundert echte Beispiele mit erwarteten Outputs, die vor jeder Modelländerung durchlaufen werden. Ohne das ist „Ist das günstigere Modell gut genug?" eine Vermutung. Wir argumentieren, dass das in den Vertrag gehört, in Evals in KI-Vendor-Verträgen.
• Ein Fallback-Pfad. Schlägt das kleine Modell die Validierung zweimal fehl, eskaliert dieser einzelne Call zum stärkeren Modell, statt den User scheitern zu lassen. Das gibt Ihnen die Kostenstruktur des kleinen Modells mit der Worst-Case-Qualität des Frontier Models.

So gestaltet wird die Modellfrage zu einem Regler, den Sie drehen, wenn Traffic und Erkenntnisse hereinkommen – statt zu einer einmaligen Entscheidung ohne Datenbasis.

Wenn Sie ein KI-Feature planen und eine direkte Einschätzung möchten, welche Modell-Tier es benötigt und was der Betrieb kosten wird, sprechen Sie uns an.