Open-Source-KI-Modelle vs. APIs: Wann sich lokaler Betrieb lohnt

Ein Sprachmodell lässt sich frei herunterladen. Damit scheint die Sache entschieden: Open-Source-KI-Modelle, volle Datenkontrolle und tiefere Kosten. Doch keine dieser drei Folgerungen ergibt sich allein aus einer verfügbaren Gewichtsdatei. Die Lizenz kann Nutzung und Weitergabe begrenzen, der Betrieb kann weiterhin bei einem Cloud-Anbieter liegen, und lokale Inferenz kann teurer werden als eine API.

Für Unternehmen ist das mehr als eine Begriffsfrage. Wer Open Source, Open Weights und Self-Hosting verwechselt, kalkuliert Lizenzrisiken, Datenflüsse und Betriebskosten auf der falschen Grundlage. Die sinnvolle Entscheidung fällt deshalb zwischen drei Betriebsmodellen: externe API, gehostetes Open-Weight-Modell oder selbst verantworteter Betrieb auf eigener oder gemieteter Infrastruktur. Erst danach zeigt sich, welche Kombination aus Kontrolle, Aufwand und Exit-Fähigkeit tatsächlich trägt.

Open-Source-KI-Modelle: vier Begriffe, die nicht dasselbe meinen

Der Ausgangspunkt ist eine saubere Trennung. Open Source AI im Sinn der OSAID 1.0 verlangt mehr als den Download einer Gewichtsdatei. Sie verlangt neben den Nutzungsfreiheiten Zugang zur bevorzugten Form für Änderungen und zu den dafür erforderlichen Informationen. Das ist kein Versprechen, dass sich ein Modell vollständig reproduzieren lässt. Open Weights bezeichnet dagegen nur den technischen Zustand, dass Modellparameter öffentlich verfügbar sind, unabhängig davon, welche Lizenzbedingungen daran hängen. Bei einem proprietären Modell begrenzt der Rechteinhaber Nutzung, Änderung oder Weitergabe durch eigene Lizenz- und Zugangskonditionen; eine API ist dafür ein häufiges, aber nicht das einzige Vertriebsmodell. Self-Hosting beziehungsweise lokaler Betrieb beschreibt schliesslich den Ort und die Verantwortung der Inferenz; über die Lizenz sagt der Betriebsort nichts aus.

Diese Eigenschaften liegen auf getrennten Achsen und lassen zahlreiche Kombinationen zu. OpenAI hat mit gpt-oss offene Gewichte veröffentlicht, obwohl das Unternehmen als Anbieter primär proprietäre APIs verkauft: Anbieteridentität und Modelllizenz sind nicht dieselbe Achse. Umgekehrt kann ein Unternehmen Gewichte oder Code unter einer Open-Source-Lizenz beziehen und sie trotzdem bei einem Hosting-Anbieter betreiben lassen. Das macht das gesamte KI-System noch nicht automatisch OSAID-konform. Wer in einer dieser vier Kategorien denkt, aber über eine andere entscheidet, verwechselt die Ebenen.

Die Lizenzlage gilt jeweils für eine konkrete Version und lässt sich nicht pauschal auf eine ganze Modellfamilie übertragen. Qwen3-235B-A22B steht laut offiziellem Repository unter Apache-2.0-Lizenz, die kommerzielle Nutzung, Modifikation und Redistribution unter Einhaltung ihrer Bedingungen erlaubt. Metas Llama 3.1 wird dagegen unter einer eigenen Community-Lizenz mit Nutzungsbedingungen veröffentlicht, die zum Beispiel bestimmte kommerzielle Einsatzfälle regeln. Das ist ein legitimes Lizenzmodell, aber keine OSI-Open-Source-Lizenz, und die Bedingungen für eine spätere Llama-Version lassen sich daraus nicht ableiten. Auch bei Google zeigt sich das Muster: Ältere Gemma-Bedingungen enthalten eigene Nutzungsrestriktionen, während Gemma 4 laut Google auf Apache 2.0 verweist. Wer "Gemma ist Apache 2.0" oder "Llama ist Open Source" als generelle Aussage trifft, überträgt eine Eigenschaft einer Version auf eine ganze Familie. Genau das verlangt die Prüfung pro Version und pro Deployment, nicht einmalig beim ersten Kennenlernen des Modellnamens.

Drei Betriebsmodelle statt einer binären Wahl

Die eigentliche Unternehmensentscheidung fällt zwischen drei Betriebsmodellen.

Externe API bedeutet, ein Modell über den Dienst eines Anbieters zu nutzen, ohne eigene Inferenz-Infrastruktur zu betreiben. Der Anbieter übernimmt Skalierung, Verfügbarkeit und Modellpflege; die Organisation zahlt gemäss Tarif und schickt Anfragen an fremde Server.

Gehostetes Open-Weight-Modell bedeutet, ein Modell mit offenen Gewichten zu verwenden, dessen Inferenz aber ein Drittanbieter betreibt, etwa ein spezialisierter Cloud-Inferenz-Dienst. Die Organisation kann Modell und Anbieter getrennt auswählen, muss die konkrete Lizenz aber weiterhin prüfen. Hardware, Monitoring und Patches liegen je nach Vertrag weitgehend beim Hosting-Anbieter. Die Datenflüsse gehen dabei weiterhin an einen externen Betreiber, auch wenn die Gewichte verfügbar sind.

Self-Hosting bedeutet, ein Modell auf eigener oder gemieteter Hardware unter eigener Kontrolle laufen zu lassen. Auf eigener Infrastruktur bleiben Datenflüsse und Betriebsverantwortung weitgehend in der Organisation. Bei gemieteter Cloud-Hardware bleibt dagegen ein Infrastrukturbetreiber beteiligt; Verantwortung, Zugriffsmöglichkeiten und technische Pflichten sind zwischen den Parteien verteilt. Praktische Details zu Frameworks und Betriebsanforderungen für diesen Weg fasst der Überblick zu lokalen Inferenz-Stacks zusammen.

Diese drei Modelle stehen orthogonal zur Modelllizenz. Ein Unternehmen kann ein Apache-2.0-Modell extern hosten lassen oder ein proprietäres Modell theoretisch selbst betreiben, wenn der Anbieter das erlaubt. Die Entscheidung, wer die Inferenz ausführt, ist damit eine eigenständige Frage, die getrennt von der Lizenzfrage beantwortet werden muss.

Datenkontrolle ist kein Freibrief

Ein häufiger Kurzschluss lautet: lokal betrieben, also datenschutzkonform. Das ist falsch. Lokaler Betrieb kann externe Datenübermittlung reduzieren, weil Anfragen nicht mehr an Server eines Drittanbieters gehen. Das ist ein technischer Effekt, kein rechtlicher Freispruch. Das Schweizer Datenschutzgesetz gilt laut EDÖB auch für den Einsatz von KI-Systemen, unabhängig davon, ob das Modell lokal oder extern läuft. Die DSGVO knüpft ihre Anforderungen an Rechtsgrundlage, Auftragsverarbeitung, Drittlandübermittlung und gegebenenfalls eine Datenschutz-Folgenabschätzung an die konkrete Verarbeitung, nicht an das Label eines Modells.

Wer sensible Daten über eine externe API durch einen Auftragsverarbeiter verarbeitet, braucht eine tragfähige vertragliche Grundlage und muss klären, ob und wie Eingaben weiterverwendet werden. Wer dieselben Daten lokal verarbeitet, muss trotzdem Zugriffskontrollen, Protokollierung, Löschkonzepte und eine saubere Rechtsgrundlage vorweisen. Ein schlecht abgesicherter lokaler Server mit offenen Zugriffsrechten ist kein besseres Datenschutzergebnis als eine sauber vertraglich geregelte API, nur weil kein Datenpaket eine Landesgrenze überquert.

Für das Anwaltsgeheimnis gilt ein zusätzlicher berufsrechtlicher Prüfbedarf. Die KI-Leitlinien des Schweizerischen Anwaltsverbands verlangen, Berufsgeheimnis, Mandanteninteressen und Schutzmassnahmen auch beim KI-Einsatz zu wahren. Der physische Standort des Servers beantwortet diese Fragen nicht allein. Eine Kanzlei muss deshalb bei einem lokalen Modell ebenso Zugriffsschutz, Löschung und Verantwortlichkeiten prüfen wie bei einer externen API. Der ausführlichere Rahmen steht im aktualisierten Artikel zu KI im Recht für Anwälte und Kanzleien. Lokaler Betrieb verändert die Datenflüsse. Er ersetzt nicht die Pflicht, diese Flüsse zu dokumentieren, zu sichern und rechtlich zu begründen.

TCO: mehr Variablen als eine Break-even-Zahl

Die Kostenfrage lässt sich nicht auf einen einzigen Schwellenwert reduzieren, ab dem sich Self-Hosting "lohnt". Wer eine solche Zahl verspricht, ignoriert, wie viele Variablen tatsächlich einfliessen.

Auf der API-Seite sind Preise häufig nutzungsabhängig, können aber auch Mindestabnahmen, Kapazitätsbuchungen oder Tarifstufen enthalten. Anbieter passen Preise an, ändern Modelle oder deprecaten Versionen. Die Organisation spart einen Grossteil der Inferenz-Infrastruktur, trägt jedoch weiterhin Aufwand für Integration, Evaluation, Monitoring, Governance und Störungsbehandlung sowie ein Abhängigkeitsrisiko. Auf der Self-Hosting-Seite stehen dem Infrastrukturkosten für Hardware oder Cloud-GPU-Miete, Energiekosten im Dauerbetrieb, Personalaufwand für Betrieb und Sicherheitspatches, die tatsächliche Auslastung der Hardware über die Zeit, Verfügbarkeitsanforderungen, der Aufwand für Modell-Updates und nicht zuletzt der Aufwand für eine aufgabenspezifische Evaluation gegenüber.

Für die Gesamtkosten werden diese Positionen addiert, ihre einzelnen Verläufe sind aber verschieden: Manche sind fix, andere variabel, stufenweise oder bei Lastspitzen nichtlinear. Eine GPU, die nachts ungenutzt bleibt, verursacht Fixkosten ohne Gegenwert. Ein Team ohne DevOps-Erfahrung zahlt den Personalaufwand doppelt, weil Fehlkonfigurationen Ausfälle produzieren. Und eine Evaluation, die nur allgemeine Benchmarks statt der eigenen Aufgabenstellung prüft, liefert ein Kostenmodell, das mit der Realität wenig zu tun hat. Es gibt keine universelle Euro- oder Frankenschwelle, ab der sich lokaler Betrieb automatisch auszahlt.

Eine belastbare Rechnung beginnt mit einem festen Betrachtungszeitraum und dem tatsächlich beobachteten Anfragevolumen. Auf der API-Seite stehen die erwarteten Nutzungskosten. Auf der lokalen Seite stehen Abschreibung oder Cloud-Miete, Energie, Personal und Rufbereitschaft, Redundanz, Monitoring, Updates und Evaluation. Für beide Varianten müssen dieselbe Mindestqualität, Latenz, Verfügbarkeit und Spitzenlast gelten. Weil die Auslastung selten sicher vorhersehbar ist, gehören mindestens ein niedriges, ein realistisches und ein hohes Nutzungsszenario in die Rechnung. Self-Hosting lohnt sich wirtschaftlich erst dann, wenn es diese Anforderungen erfüllt und seine Gesamtkosten samt Risikopuffer über den gewählten Zeitraum unter der API-Alternative liegen.

Was proprietäre APIs zusätzlich mitbringen

Proprietäre Modelle sind an dieser Stelle keine Verlierer der Debatte, sie lösen ein anderes Problem. Je nach Anbieter und Tarif bündeln APIs ein Sprachmodell mit Produktbestandteilen wie Toolaufrufen, Multimodalität, Rate-Limiting, Monitoring, Support oder vertraglich geregelter Verfügbarkeit in Form eines Service Level Agreement. Diese Bestandteile gehören beim Self-Hosting eines Open-Weight-Modells nicht automatisch dazu; sie müssen selbst gebaut oder eingekauft werden.

Proprietäre Modelle sind dadurch nicht grundsätzlich leistungsfähiger als offen lizenzierte Alternativen. Der Vergleich zwischen einer API und einem selbst gehosteten Modell ist selten ein reiner Modellvergleich. Gegenüber stehen ein fertiges Produkt mit Supportversprechen und eine selbst zusammengesetzte Betriebslösung. Wer nur die Modellqualität vergleicht und die fehlenden Produktbestandteile beim Self-Hosting ignoriert, unterschätzt den tatsächlichen Aufwand auf der offenen Seite. Wer umgekehrt annimmt, ein proprietäres Modell sei allein wegen des SLA einem offenen Modell technisch überlegen, verwechselt Produktarchitektur mit Modellfähigkeit.

Exit-Fähigkeit braucht mehr als eine Gewichtsdatei

Ein Argument für Open-Source-KI-Modelle lautet regelmässig: Es gibt eine Exit-Option, falls der Anbieter die Bedingungen ändert. Das stimmt nur bedingt. Eine Exit-Option verlangt mehr als frei verfügbare Gewichte. Sie verlangt einen funktionierenden Datenexport aus dem bisherigen System, einen Inferenzstack, der das alternative Modell tatsächlich laufen lassen kann, eine eigene Evaluation, die zeigt, dass der Wechsel keinen unbemerkten Qualitätsverlust produziert, und die organisatorische Fähigkeit, einen Modellwechsel überhaupt durchzuführen.

Ein Unternehmen, das nie getestet hat, ein alternatives Modell produktionsnah zu betreiben, besitzt keine reale Exit-Option, selbst wenn theoretisch ein passendes Open-Weight-Modell existiert. Ein produktionsnah getesteter lokaler Stack kann die Verhandlungsposition gegenüber einem API-Anbieter verbessern, wenn er die benötigte Funktion, Qualität und Wirtschaftlichkeit rechtzeitig erreicht. Er muss nicht jede Aufgabe übernehmen. Als Exit-Option taugt er aber erst, wenn der Wechsel unter realistischen Bedingungen erprobt wurde.

Ein Entscheidungspfad statt einer Ranking-Tabelle

Für Unternehmen und Kanzleien lässt sich daraus ein Prüfpfad ableiten, der ohne Modellranking auskommt. Zuerst die Datenfrage klären: Werden personenbezogene, vertrauliche oder berufsgeheimnisgeschützte Daten verarbeitet, und wenn ja, unter welcher Rechtsgrundlage, mit welcher Dokumentation und mit welchen technischen Schutzmassnahmen, unabhängig vom gewählten Betriebsmodell? Danach die Nutzungsfrage: Wie hoch und wie planbar ist das Volumen, und würde eine API-Rechnung bei diesem Volumen strukturell unattraktiv? Anschliessend die Betriebsfrage: Existiert die Kapazität, ein Modell selbst zu betreiben, zu patchen und zu überwachen, oder wäre ein gehostetes Open-Weight-Modell der realistischere Mittelweg zwischen Lizenzfreiheit und Betriebslast? Und schliesslich die Produktfrage: Werden Toolintegration, Multimodalität oder ein vertraglich abgesichertes SLA benötigt, die ein selbst betriebenes Modell erst noch nachbauen müsste?

Diese vier Fragen ergeben selten dieselbe Antwort für dieselbe Organisation. Ein Unternehmen kann für Massendokumentenverarbeitung ein selbst gehostetes Apache-2.0-Modell wählen und für punktuelle, komplexe Analysen parallel eine proprietäre API nutzen. Diese Kombination folgt daraus, dass Lizenz, Datenkontrolle, Kosten und Produktfähigkeit vier getrennte Variablen sind, die selten in dieselbe Richtung zeigen.

Fazit

Vor der Modellauswahl braucht es vier getrennte Gates: die Lizenz der konkreten Version, den tatsächlichen Datenfluss, die Gesamtkosten im gewählten Zeitraum und die benötigten Produktbestandteile. Erst danach lässt sich entscheiden, ob eine externe API, gehostete offene Gewichte, Self-Hosting oder eine Kombination trägt. Wer eines dieser Gates überspringt, verschiebt den Preis lediglich in Recht, Betrieb oder spätere Migration.