Eigenes LLM oder API: was der Mittelstand wirklich braucht

Die Frage "eigenes Modell oder API" kommt in fast jedem Erstgespräch, meistens aus einem berechtigten Impuls: Wer ein System baut, das im Unternehmen bleiben soll, will nicht von einem einzelnen externen Anbieter abhängen. Der Impuls ist richtig, die daraus abgeleitete Lösung meistens nicht. "Eigenes Modell" bedeutet in der Praxis: eigene Server, eigene Kapazitätsplanung, eigenes Team, das Modell-Updates einspielt. Das ist eine andere Investition, als die meisten Teams im Kopf haben, wenn sie nach Unabhängigkeit fragen.

Die falsche Frage zuerst

Viele Gespräche starten bei "welches Modell" statt bei "wo laufen unsere Daten und wer kann sie sehen". Das ist die eigentlich entscheidende Frage, und sie lässt sich sowohl mit einer API als auch mit einem selbst gehosteten Modell beantworten. Ein API-Anbieter, der vertraglich zusichert, Daten nicht zum Training zu verwenden und sie nach einer definierten Frist zu löschen, kann strengere Vorgaben erfüllen als ein selbst gehostetes System, das ein internes Team pflegt, ohne dieselbe Sorgfalt bei Logs und Zugriffsrechten.

Die zweite falsche Annahme ist, ein eigenes Modell wäre automatisch günstiger, weil keine Rechnung pro Token mehr anfällt. Server laufen auch dann Kosten, wenn niemand sie anfragt, ein API-Zugang kostet nur bei tatsächlicher Nutzung. Wer Anfragen nur unregelmäßig über den Tag verteilt braucht, etwa für Support-Antworten, zahlt bei einem eigenen Server für Kapazität, die die meiste Zeit ungenutzt bleibt.

Was "eigenes LLM" konkret bedeutet

Zwischen "wir nutzen eine API" und "wir hosten unser eigenes Modell" liegt technisch eine Menge. Eine API bedeutet: ein Anbieter wie Anthropic oder OpenAI betreibt das Modell, ihr schickt Anfragen und bezahlt pro genutztem Token. Ein selbst gehostetes Modell bedeutet: ihr ladet ein offenes Modell, etwa aus der Llama- oder Mistral-Familie, auf eigene oder gemietete Server, und seid für Betrieb, Skalierung und Sicherheit selbst verantwortlich. Es gibt eine Zwischenstufe, gehostete Instanzen offener Modelle bei einem Cloud-Anbieter, die einen Teil des Betriebsaufwands abnimmt, aber nicht die Modellwahl.

Wichtig ist außerdem der Unterschied zwischen einem offenen Modell und einem frei verwendbaren. Ein Anbieter kann die Modellgewichte veröffentlichen und trotzdem in der Lizenz einschränken, wofür sie kommerziell genutzt werden dürfen, etwa ab welcher Nutzerzahl eine gesonderte Vereinbarung nötig wird. Wer ein offenes Modell selbst hostet, sollte die Lizenzbedingungen genauso sorgfältig lesen wie einen API-Vertrag, denn "offen" ist kein Synonym für "uneingeschränkt nutzbar".

• API bei einem Anbieter: kein eigener Betrieb, Abrechnung nach Nutzung, aktuelle Modelle ohne eigenes Update-Management
• Offenes Modell, selbst gehostet: volle Kontrolle über Infrastruktur und Daten, aber eigenes Team für Betrieb, Skalierung und Sicherheitsupdates nötig
• Offenes Modell bei einem Cloud-Anbieter gehostet: Mittelweg, der Betrieb abnimmt, aber nicht die Verantwortung für Konfiguration und Zugriffsrechte

Wann API die richtige Antwort ist

In den Projekten, an denen wir arbeiten, ist das der Normalfall: ein E-Commerce-Team mit einem Marketing- oder Support-Prozess, der ein Sprachmodell für einen klar umrissenen Schritt braucht, etwa Antwortvorschläge oder Textvarianten. Für diesen Fall ist eine API fast immer die richtige Wahl, weil das eigentliche Projekt der Prozess drumherum ist, die Knowledge Base, die Anbindung an Shopify, die Freigabe-Logik, nicht das Sprachmodell selbst. Ein Team, das zusätzlich noch Server für ein Modell betreiben muss, bindet Kapazität an der falschen Stelle.

Ein zweiter Vorteil, der in der Diskussion oft untergeht: API-Anbieter aktualisieren ihre Modelle laufend, ohne dass jemand im Team ein Update einspielen muss. Ein selbst gehostetes Modell bleibt dagegen auf dem Stand, auf dem es installiert wurde, bis jemand aktiv ein neues herunterlädt, testet und austauscht. Für ein Team ohne eigenes ML-Ops-Personal ist das ein laufender Aufwand, der bei einer API schlicht entfällt.

Wann Self-Hosting sich tatsächlich lohnt

Es gibt echte Gründe für ein selbst gehostetes Modell, sie treffen im Mittelstand nur selten alle gleichzeitig zu. Der häufigste legitime Grund ist eine strikte Vorgabe zur Datenresidenz, etwa wenn Daten aus regulatorischen Gründen ein bestimmtes Rechenzentrum nicht verlassen dürfen und kein API-Anbieter diese Garantie in der benötigten Form gibt. Der zweite ist Volumen: Bei einer Anfragenmenge, die in die Millionen pro Tag geht, kann sich eigener Betrieb wirtschaftlich rechnen. Die meisten Mittelstandsprojekte, die wir sehen, liegen weit darunter.

1. Regulatorisch verpflichtende Datenresidenz, die kein API-Anbieter erfüllt
2. Anfragenvolumen, bei dem die Rechnung pro Token teurer wird als eigener Serverbetrieb
3. Ein spezialisiertes, fein nachtrainiertes Modell, das kein Standardmodell einer API abdeckt
4. Ein internes Team, das den Betrieb bereits für andere Systeme leistet und die Kapazität hat

Was wir bei unseren eigenen Projekten tatsächlich einsetzen

In keinem der Systeme, die wir bisher für Kunden gebaut haben, hosten wir ein eigenes Sprachmodell. Sowohl der Support-Agent bei Essential Bag als auch die Text- und Konfigurationsschritte im SNOCKS-System laufen über API-Zugänge zu gehosteten Modellen. Das ist keine ideologische Entscheidung, sondern eine, die sich aus der Rechnung ergibt: Der Betriebsaufwand für ein eigenes Modell hätte in keinem der Fälle den Nutzen gerechtfertigt, den das Projekt tatsächlich brauchte.

Das kann sich mit der Zeit ändern, gerade wenn ein Kunde über mehrere Marken und Länder hinweg ein Volumen erreicht, bei dem sich die Rechnung anders stellt als am Anfang. Deshalb bauen wir Prompts, Knowledge Base und Freigabelogik von Anfang an so, dass sie nicht an ein einzelnes Modell oder einen einzelnen Anbieter gebunden sind. Der Wechsel des Modells im Hintergrund sollte eine Konfigurationsänderung sein, kein Neubau des Systems.

• LLM
• API
• Mittelstand
• AI-Infrastruktur