„Bau eine SaaS" bedeutete früher, dass man etwas Dauerhaftes besaß. 2026 kann ein KI-Coding-Agent das Kernfunktionsset Ihrer App nachbauen, Ihre Landingpage neu stylen und Ihre Anzeigentexte an einem einzigen Nachmittag zurückentwickeln — siehe auch unseren Beitrag dazu, wie weit Coding-Agenten inzwischen sind. Die Oberfläche, der Onboarding-Flow, die Positionierung: All das lässt sich heute billig kopieren. Was sich nicht billig kopieren lässt, ist ein Modell, das Sie selbst mit eigenen Daten feingetunt haben und das ein allgemeines Frontier-Modell still und leise bei genau der einen Sache schlägt, die Ihr Geschäft tatsächlich braucht.
Das ist die Verschiebung, die Aufmerksamkeit verdient: fein abgestimmte Small Language Models (SLMs) — grob 0,5 bis 12 Milliarden Parameter — so zu monetarisieren, wie Sie ein SaaS-Produkt lizenzieren würden, statt (oder zusätzlich zu) einem weiteren Wrapper um die API von jemand anderem.
Warum der SaaS-Burggraben erodiert
Der klassische SaaS-Burggraben war nie wirklich der Code — es war die Zeit, die ein Wettbewerber brauchte, um ihn zu schreiben. Diese Zeit ist zusammengebrochen. Coding-Agenten können einen funktionierenden Klon der meisten CRUD-und-Dashboard-Produkte in Stunden statt Monaten aufsetzen, und sie sind genauso gut darin, die Marketingoberfläche zu kopieren: die Anzeigen-Hooks, den Aufbau der Landingpage, die Psychologie der Preisseite. Nichts davon erfordert, Ihren Quellcode zu stehlen — es reicht, sich Ihr Produkt anzusehen und einen Agenten zu bitten, dessen Form nachzubauen.
Was als echter Burggraben übrig bleibt, ist alles, was ein Wettbewerber nicht einfach von einem Agenten nachbauen lassen kann: proprietäre Daten, bereits verdiente Distribution, über Zeit aufgebautes Vertrauen — und zunehmend ein selbst trainiertes Modell, auf das ein generischer Klon schlicht keinen Zugriff hat.
Was sich wirklich geändert hat: Fine-Tuning wurde einfach
Fine-Tuning erforderte früher ein ML-Forschungsteam. Was sich 2026 geändert hat: Frontier-Modelle sind wirklich gut darin geworden, einen einzelnen Operator durch die gesamte Pipeline zu führen — nicht nur Fragen dazu zu beantworten, sondern die mechanische Arbeit selbst zu übernehmen. Modelle wie DeepSeek-V4-Pro (im August 2026 GA gegangen), GLM-5.3, Kimi K3 (die Veröffentlichung von Moonshot AI, eines der größten verfügbaren offenen Modelle) und GPT-6 Astra (OpenAIs aktuelles Flaggschiff) können Datensatzaufbereitung, LoRA-/QLoRA-Adapter-Setup, das Debuggen von Trainingsläufen und den Export des Ergebnisses nach GGUF (für lokale Inferenz im Stil von llama.cpp und Ollama) oder MLX (für Apple Silicon) kompetent übernehmen — die Deployment-Formate, die ein feingetuntes Modell außerhalb eines Forschungs-Notebooks überhaupt erst lauffähig machen.
Das ist der eigentliche Hebel. Nicht dass kleine Modelle plötzlich klüger geworden wären — sondern dass das Werkzeug, um sie zu spezialisieren, von einem mehrmonatigen Forschungsprojekt auf etwas zusammengeschrumpft ist, das eine technisch kompetente Person in wenigen Tagen erledigen kann, mit einem Frontier-Modell als Baupartner statt jeden Schritt von Hand zu machen.
Der Burggraben war nie „wir haben ein Sprachmodell". Jeder Wettbewerber hat Zugriff auf dieselben Frontier-APIs wie Sie. Der Burggraben ist ein Modell, trainiert auf Daten, die Ihr Wettbewerber nicht hat, bewertet an einer Messlatte, die er nicht erreicht hat, verpackt als etwas, das Sie vollständig selbst kontrollieren.
Warum ein feingetuntes SLM ein SoTA-Modell bei einer bestimmten Aufgabe schlagen kann
Ein Frontier-Modell ist darauf ausgelegt, bei fast allem gut zu sein, was bedeutet, dass seine Kapazität über eine enorme Bandbreite an Aufgaben verteilt ist, die es von Ihnen nie sehen wird. Ein kleines Modell, feingetunt auf ein paar hundert bis ein paar tausend sorgfältig kuratierte, aufgabenspezifische Beispiele, trägt diesen Overhead nicht — es muss nur bei der einen Aufgabe gut sein, für die Sie es trainiert haben, und kann das mit einem Bruchteil der Parameter erreichen.
Die Wirtschaftlichkeit bestätigt das. Schon die aktuellen offenen Frontier-Klasse-Modelle — DeepSeek-V4-Pro, GLM-5.3, Kimi K3 — laufen bereits zu etwa einem Fünftel bis einem Dreißigstel der Kosten pro Token geschlossener Frontier-APIs, bei weiterhin wettbewerbsfähigen allgemeinen Benchmarks. Ein kleines, für eine einzelne Aufgabe feingetuntes und selbst gehostetes Modell geht deutlich weiter: Kostensenkungen im Bereich von über 90 % und ein Vielfaches an Latenzverbesserung gegenüber einer allgemeinen Frontier-API werden für gut abgegrenzte Anwendungsfälle häufig berichtet, wobei die genauen Zahlen stark von der Aufgabe, dem Basismodell und der Disziplin bei der Evaluation abhängen. Es ist Ihr Modell, gehostet auf Ihrer eigenen Infrastruktur — keine geteilten Ratenlimits, keine überraschenden Preisänderungen, keine standardmäßige Übertragung von Kundendaten an die API eines Dritten.
Nicht sicher, welche Ihrer Workflows sich für Fine-Tuning eignen?
Der schwierige Teil ist nicht, einen LoRA-Job laufen zu lassen — es ist, die richtige Aufgabe auszuwählen, ein ehrliches Evaluationsset aufzubauen und zu wissen, wann sich ein Fine-Tuning tatsächlich lohnt, es zu pflegen. Genau diese Einschätzungsarbeit leisten wir mit unseren Kunden, bevor überhaupt ein Trainingslauf startet.
Beratung buchenDer Fahrplan: Von der Idee zum lizenzierbaren Modell
Schritt 1 — Eine enge, wiederholbare Aufgabe wählen. Klassifikation, strukturierte Extraktion, ein bestimmter Generierungsstil, ein klar abgegrenzter Domänen-Chat — kein offener Assistent. Fine-Tuning belohnt eine Aufgabe, deren Grenzen Sie tatsächlich definieren können.
Schritt 2 — Einen echten Datensatz kuratieren. Ein paar hundert bis ein paar tausend hochwertige, verifizierte Beispiele schlagen durchgehend einen schlampigen Scrape mit 100.000 Zeilen. Nutzen Sie ein Frontier-Modell, um Kandidaten-Beispiele zu generieren und zu bereinigen, und lassen Sie dann einen Menschen eine repräsentative Stichprobe prüfen, bevor irgendetwas ins Training geht.
Schritt 3 — Mit LoRA oder QLoRA auf einem kleinen Basismodell feintunen. Im Bereich von 0,5 bis 12 Milliarden Parametern zu bleiben, hält einen Trainingslauf günstig genug, um auf einer einzelnen GPU oder einer moderat dimensionierten gemieteten Instanz zu iterieren, statt einen Job im Rechenzentrumsmaßstab zu fahren.
Schritt 4 — Rigoros gegen die SoTA-Baseline evaluieren. Das ist der Schritt, den die meisten überspringen, und genau er sagt Ihnen, ob Sie etwas Verkaufbares haben. Bauen Sie ein zurückgehaltenes Testset auf, das das Modell nie gesehen hat, lassen Sie das Frontier-Modell und Ihr Fine-Tune nebeneinander laufen, und seien Sie ehrlich darüber, wo welches gewinnt.
Schritt 5 — Für echtes Deployment exportieren. GGUF für lokale Inferenz im Stil von llama.cpp und Ollama, MLX für Apple Silicon — die Formate, die es einem Kunden erlauben, das Modell tatsächlich auf eigener Hardware laufen zu lassen, statt einem gehosteten Endpunkt vertrauen zu müssen.
Schritt 6 — Wie Software lizenzieren. Pro Sitzplatz, nutzungsbasiert oder als Pauschalgebühr für eine private On-Premise-Installation — dieselben Verpackungsmuster, die SaaS bereits nutzt. Das Produkt besteht eben nur aus Modellgewichten und einem Evaluationsgerüst statt aus einer Web-App.
Wo das nicht funktioniert
Das ist kein pauschaler Ersatz für SaaS, und es so zu behandeln ist, woran diese Projekte scheitern. Ein paar ehrliche Vorbehalte:
Breite, offene Anwendungsfälle bevorzugen weiterhin Frontier-Modelle. Fine-Tuning glänzt bei engen, wiederholbaren Aufgaben mit einer klaren richtigen Antwort — nicht bei allgemeinem Schlussfolgern oder offenen Gesprächen, wo Breite der ganze Sinn ist.
Lizenzen der Basismodelle zählen. Selbst großzügig lizenzierte offene Modelle können Bedingungen für die kommerzielle Nutzung tragen. Prüfen Sie die Lizenz, bevor Sie ein Geschäft auf den Gewichten eines anderen aufbauen.
Modelle altern. Wenn sich Basismodelle verbessern, kann ein feingetunter Vorsprung schrumpfen oder verschwinden. Planen Sie regelmäßiges Nachtunen als Teil des Produkts ein, nicht als einmaligen Bau, den Sie nie wieder anfassen.
Der Engpass ist Datenqualität, nicht Rechenleistung. Ein Fine-Tune ist nur so gut wie das, was Sie hineingeben. Teams, die Schritt 2 oben überspringen und darauf setzen, dass der Fine-Tuning-Prozess einen schlampigen Datensatz repariert, sind vom Ergebnis durchweg enttäuscht.
Ein leiser, unterdiskutierter Trend
Es ist ein Muster, das in Fachkreisen häufiger auftaucht, als öffentlich darüber gesprochen wird: Operatoren, die im letzten Jahr still und leise Dutzende enger, aufgabenspezifischer Modelle feingetunt haben, mit erstaunlich wenig Veröffentlichtem im Verhältnis dazu, wie wirksam die Ergebnisse meist sind. Ein Teil davon ist die Fixierung des Feldes auf Frontier-Modell-Launches, die die Berichterstattung über die weniger glanzvolle Arbeit verdrängt, ein kleines Modell auf ein reales Geschäftsproblem zu spezialisieren. Ein Teil davon ist, dass ein funktionierendes Fine-Tune ein echter Wettbewerbsvorteil ist — und wer eines gebaut hat, hat wenig Anreiz, genau zu erklären, wie.
Der Instinkt dahinter hält aber stand: Für eine gut abgegrenzte, hochvolumige, spezifische Aufgabe schlägt ein maßgeschneidertes, feingetuntes SLM zunehmend einen generischen SaaS-Wrapper um eine Frontier-API — günstiger im Betrieb, schneller in der Antwort, und Ihre eigene Kontrolle statt gemietet aus den Ratenlimits eines anderen. Es ist kein Ersatz für jedes SaaS-Produkt, und es ist nicht kostenlos — die Datensatzarbeit und die Evaluationsdisziplin sind reale Kosten. Aber als Kategorie, die es 2026 ernsthaft zu erkunden lohnt, hat es sich die Aufmerksamkeit verdient. Wenn Sie das gegen die Kosten eines konventionelleren Baus abwägen, ist unser Überblick zu den tatsächlichen Kosten einer KI-Implementierung eine gute nächste Lektüre, und unsere Einschätzung zur Open-Source-KI-Tooling-Welle deckt die angrenzende Tooling-Verschiebung ab, die all das günstiger baubar macht.