← Alle Beiträge

Die Multi-Modell-Zukunft: Warum Spezialisten die Generalisten schlagen

Die Belege häufen sich, dass eng zugeschnittene, feinabgestimmte Modelle grosse Frontier-LLMs bei realen Aufgaben schlagen — zu einem Bruchteil der Kosten. Was das konkret bedeutet und wohin es führt.

Veröffentlicht am 19. April 2026 · Jonathan Frei & Claude

Mit jedem neuen Frontier-Modell kommt das implizite Versprechen: dieses hier kann alles. Mehr Parameter, grösserer Kontext, bessere Reasoning-Fähigkeiten — irgendwann ist die Ära des einen Modells für alle Aufgaben da.

In Kundenprojekten sehen wir etwas anderes. Für die meisten produktiven Aufgaben — diese E-Mail klassifizieren, dieses Feld extrahieren, die richtige Artikelnummer finden, dieses Ticket routen — schlägt ein sorgfältig trainiertes kleineres Modell das grösste Frontier-Modell. Günstiger, schneller und meistens genauer.

Die Belege verdichten sich

Eine aktuelle Arbeit von Bucher & Martini (arXiv:2406.08660) vergleicht feinabgestimmte BERT-basierte Modelle mit ChatGPT und Claude Opus im Zero-Shot-Einsatz bei einer Reihe von Textklassifikationsaufgaben — Sentiment, Zustimmung/Ablehnung, Emotionen, Parteipositionen — über News, Tweets und Reden hinweg. Ihr Fazit ist unmissverständlich:

We find that fine-tuning with application-specific training data achieves superior performance in all cases.

Nicht “vergleichbare Leistung”. Nicht “günstiger und gut genug”. Überlegen. In allen Fällen. Mit Modellen, die einen Bruchteil der Parameter haben und auf einem Bruchteil der Rechenleistung laufen.

Das passt zu dem, was wir im Alltag sehen. Ein kleines Modell, das auf den tatsächlichen Rechnungs-Routing-Entscheidungen eines Kunden feinabgestimmt wurde, schlägt ein Frontier-Modell im Zero-Shot zu einem Bruchteil der Inferenzkosten. Ein schlanker Klassifikator, der auf den vergangenen Tickets eines Support-Teams trainiert wurde, schlägt alles andere im Long Tail der Edge Cases — weil er sie gesehen hat, das Frontier-Modell aber nicht.

Warum Spezialisten produktiv gewinnen

Drei Gründe, keiner davon neu, alle wirken zusammen:

  1. Die Form der Aufgabe zählt mehr als die Grösse des Modells. Die meisten Automatisierungen im Unternehmen laufen auf eine überschaubare Zahl klar definierter Entscheidungen hinaus. Ein Modell, das auf diese Entscheidungsgrenzen trainiert ist, braucht keine Hunderte Milliarden Parameter Weltwissen, um sie richtig zu treffen.
  2. Token-Ökonomie. Frontier-Modelle rechnen pro Token ab und berechnen jeden Forward-Pass zum Flaggschiff-Tarif. Ein kleiner Spezialist auf einem günstigen Endpoint kann pro Entscheidung 50–100× weniger kosten — in der Skalierung ist das der Unterschied zwischen einer profitablen Automatisierung und einer, die sich nicht rechnet.
  3. Latenz und Vorhersagbarkeit. Eine 200-ms-Klassifikation hat eine ganz andere Produktform als eine 4-Sekunden-Chat-Antwort. Kleine Spezialisten passen in Echtzeit-Pipelines, in die Frontier-Modelle nicht hineinpassen.

Was das für Lambda-Kunden bedeutet

Wir verkaufen kein “LLM” — wir wählen das richtige Modell für jeden Schritt eines Workflows. Eine typische Automatisierung, die wir bauen, führt durch mehrere Modelle: einen Spezialisten für Extraktion, einen Generalisten für mehrdeutiges Reasoning, ein code-spezifisches Modell für SQL- oder Skript-Generierung, ein kleines Embedding-Modell für Retrieval. Unsere Aufgabe ist es, den optimalen Mix für eine konkrete Anwendung zu finden — und ihn laufend anzupassen, während die Frontier-Modelle besser werden und die Spezialisten aufholen.

Das ist der eigentliche Deal mit Multi-Modell-Architektur: Kunden zahlen für das günstigste Modell, das bei jedem Schritt gut genug ist — nicht einen pauschalen Aufpreis für das neueste Flaggschiff.

Der nächste Schritt: eigene Modelle beim Kunden

Wir sehen auch den Anfang einer tieferen Verschiebung. Kunden werden sich zunehmend bewusst, wie wertvoll ihre eigenen Daten tatsächlich sind — die historischen Rechnungsentscheidungen, die annotierten Support-Interaktionen, die jahrelang kategorisierten Dokumente. Heute liegt vieles davon entweder in Zero-Shot-Prompts (günstig für Prototypen, teuer im produktiven Einsatz und leakt operative Kontexte an Drittanbieter-APIs) oder wird gar nicht genutzt.

Der nächste Schritt ist, ein dediziertes kleines Modell auf diese Daten feinabzustimmen und auf der eigenen Infrastruktur zu betreiben. Drei Dinge ändern sich auf einmal:

  • Die Inferenzkosten sinken auf die Kosten der eigenen Hardware.
  • Die Daten bleiben innerhalb des eigenen Perimeters. Nichts aus dem Workflow verlässt das Haus.
  • Das entstehende Modell ist ein Moat (nachhaltiger Wettbewerbsvorteil). Nicht die Gewichte an sich — die konkreten Entscheidungsmuster, die es aus Jahren eigener Abläufe gelernt hat.

Für regulierte Branchen und datenintensive Geschäftsmodelle ist das kein “vielleicht irgendwann”. Das ist ein Thema der nächsten 12 Monate.

Multi-Modell ist kein Provisorium

Ein verbreitetes Framing lautet, Multi-Modell-Pipelines seien ein Übergangs-Hack, bis ein einziges Modell wirklich alles kann. Wir halten das für die falsche Richtung. Die grössten Frontier-Modelle werden weiter besser. Die kleinen Spezialisten auch. Der Qualitätsabstand bei engen Aufgaben wird schrumpfen — aber der Kosten- und Latenzabstand nicht, und der ist entscheidend für den produktiven Einsatz.

Lambda existiert, um in diesem Raum zu navigieren: das richtige Modell für die richtige Aufgabe wählen — und Kunden, die ihre Modelle selbst besitzen wollen, helfen, das richtig zu tun.