Die These in einem Satz: Die Wahl zwischen Open-Source-KI und geschlossener API entscheidet sich fast nie da, wo man denkt. Es ist kein Grundsatzkampf zwischen „Freiheit“ und „Lock-in“. Es ist eine Ingenieursentscheidung mit zwei Uhren —Kosten bei Skalierung und Datensensibilität— und für die allermeisten Unternehmen ist die richtige Antwort am ersten Tag nicht die ideologische. Dieser Artikel handelt davon, wann es wirklich zählt und wann es, ehrlich gesagt, egal ist.
Open-Source-KI vs. geschlossene API im Unternehmen: Die meisten stellen die Frage verkehrt herum
Das Gespräch kommt fast immer schon vergiftet an. Jemand aus dem Team hat gelesen, dass Llama, Mistral oder DeepSeek offene Modelle sind, dass man sie herunterladen und „zu Hause“ laufen lassen kann, und plötzlich ist die Frage nicht mehr „Was braucht mein Geschäft?“, sondern „Sind wir die Sorte, die von OpenAI abhängt, oder die Sorte, die selbst hostet?“. Das ist keine technische Entscheidung: Das ist Identität. Und Identitätsentscheidungen verteidigt man mit Stolz, nicht mit Daten.
Die nützliche Frage ist viel langweiliger: Was gibt dir jede Option für das konkrete Problem, das du lösen willst, und was kostet dich jede —an Geld, an Zeit deines Teams, an Risiko? So gestellt, fällt die Fahne von allein und das zeigt sich, was wirklich entscheidet: das Volumen, mit dem du das Modell aufrufst, und wie heikel die Daten sind, die du ihm gibst.
Was dir jede Option wirklich gibt (ohne die Fahne)
Geschlossene API: Tempo und null Wartung
Eine geschlossene API —OpenAI, Anthropic, Google— ist ein Netzwerkaufruf. Du stellst keine GPUs bereit, patchst keine Treiber, sorgst dich nicht, dass das Modell um 3 Uhr nachts umkippt. Du zahlst pro Token, startest in Minuten, und der Anbieter verbessert das Modell darunter, ohne dass du etwas anfasst. Im Gegenzug verlassen die Daten deinen Perimeter Richtung seines (mit Vertrag dazwischen), ein anderer legt den Stückkosten fest, und du hängst an seiner Roadmap und seiner Preispolitik. Du kaufst Tempo und Ruhe; du mietest die Kontrolle.
Open Source: Kontrolle und Kosten bei Skalierung, gegen Klempnerei
Ein offenes Modell, das du selbst betreibst —in deiner Cloud oder auf deiner Hardware— gibt dir das Gegenteil: Die Daten bewegen sich nicht von dort, wo du es sagst, die Kosten pro Million Token bei hohem Volumen können einbrechen, und niemand mottet dir das Modell überraschend ein. Der Preis dafür: Die Infrastruktur ist jetzt deine. Das Modell zu servieren, zu skalieren, zu überwachen, zu aktualisieren und zu reagieren, wenn es kaputtgeht, ist der Job deines Teams, für immer. Es ist nicht „billiger“: Du tauschst eine Anbieterrechnung gegen eine Ingenieursgehaltsliste. Für wen Volumen und Personal hat, lohnt es sich; für wen nicht, ist es ein Fass ohne Boden.
| Achse | Geschlossene API | Open Source (selbst gehostet) |
|---|---|---|
| Start | Minuten | Wochen Setup |
| Wo die Daten leben | Beim Anbieter (mit Vertrag) | Wo du entscheidest |
| Kosten | Pro Token, Anbieter legt fest | Fix (Infra + Team), günstig bei Skalierung |
| Wartung | Null, verbessert sich selbst | Deine, für immer |
| Kontrolle / Lock-in | Wenig Kontrolle, hoher Lock-in | Hohe Kontrolle, kein Lock-in |
| Für wen es sich lohnt | Fast alle am Anfang | Hohes Volumen oder sensible Daten |
Warum für 90% der Mittelständler die Antwort lautet: mit geschlossener API starten
Das ist weder Faulheit noch feiger Pragmatismus: Es ist Arithmetik. Die meisten KI-Projekte eines Mittelständlers sterben nicht, weil das falsche Modell gewählt wurde, sondern weil sie nie in Produktion kamen. Und alles, was den Weg in die Produktion verlängert, erhöht die Sterbewahrscheinlichkeit. Ein offenes Modell selbst zu hosten fügt von vornherein ein ganzes Infrastrukturprojekt hinzu, bevor du überhaupt validiert hast, dass die Idee funktioniert. Das heißt, die Kosten pro Token von etwas zu optimieren, von dem du noch nicht weißt, ob du es nutzen wirst.
- Dein Volumen ist am Anfang niedrig. Die Token-Ersparnis von Open Source rechnet sich erst ab viel Traffic. Mit wenigen Aufrufen am Tag kostet deine eigene Infrastruktur mehr als die API, nicht weniger.
- Du hast —und willst— kein MLOps-Team. Ein Modell mit Hochverfügbarkeit in Produktion zu servieren ist ein Handwerk. Hast du es nicht im Haus, zahlst du, was du an Token sparst, in Einstellungen oder Ausfällen.
- Das offene Modell von heute ist nicht dein Vorteil. Dein Unterschied ist nicht, welche Gewichte du betreibst, sondern dein Prozess und deine Daten. Mit einer API zu starten lässt dich dich darauf konzentrieren statt auf GPU-Treiber.
- Später migrieren ist billig; am Start falschliegen ist teuer. Wenn du die App vom Anbieter entkoppelt baust, ist der Wechsel von geschlossener API zum eigenen Modell später eine Konfigurationsänderung, kein Neuschreiben.
Der vernünftige Zug: mit einer geschlossenen API starten, validieren, dass der Fall in deinem Betrieb funktioniert, und die Tür offenlassen, um auf Open Source herunterzugehen, sobald die Zahlen es verlangen. Ist das Projekt ernst und soll wachsen, ist genau diese Architektur —entkoppelt, mit Model-Routing und den Daten unter deiner Kontrolle— das, was wir in Enterprise-KI-Infrastruktur bauen: nicht, um dich an einen Anbieter zu binden, sondern damit du ihn schmerzlos tauschen kannst.
Wann es Sinn ergibt, auf Open Source herunterzugehen
Die Regel lautet nicht „nie Open Source“. Sie lautet „Open Source, wenn ein echter Auslöser es rechtfertigt“, nicht, wenn der Stolz es verlangt. Das sind die Auslöser, die die Waage wirklich kippen:
- Die Daten dürfen deinen Perimeter nicht verlassen. Gesundheit, Banken, Recht, Betriebsgeheimnis: Wenn die Daten per Vertrag oder Regulierung keinen Drittserver berühren dürfen, ist Selbst-Hosting keine Vorliebe mehr, sondern eine Anforderung. Bevor du davon ausgehst, dass das dein Fall ist, kläre mit einer Nutzungsrichtlinie für ChatGPT und externe Modelle im Unternehmen, was raus darf und was nicht; oft sind die sensiblen Daten ein kleiner Bruchteil und der Rest läuft bestens per API.
- Das Volumen ist groß und beständig. Wenn du das Modell stabil Millionen Mal im Monat aufrufst, fangen die Token-Kosten der API an wehzutun und dein eigenes Modell amortisiert sich. Hier begünstigt die Arithmetik sehr wohl Open Source —sofern du schon jemanden hast, der es betreibt—.
- Du musst das Modell mit deinem Wissen feinjustieren. Verlangt dein Fall ein auf deine Domäne und deine Daten spezialisiertes Modell, hilft die Kontrolle über die Gewichte. Aber Vorsicht: Vor dem Fine-Tuning ist die echte Lösung fast immer Retrieval über deine Information, was wir in den Agenten mit deiner eigenen Information trainieren aufdröseln.
- Latenz oder Offline. Brauchst du lokale Antwort, ohne Netz, oder garantierte Mindestlatenz, muss das Modell nah an dem leben, wo es benutzt wird. Da hilft keine geschlossene API.
Die Kosten, die dir niemand nennt: Warten ist nicht gratis
Der klassische Fehler beim Vergleichen ist, nur auf den Preis pro Token zu schauen und zu schließen, Open Source sei „gratis“. Ist es nicht. Ein selbst gehostetes Modell hat Kosten, die auf keinem Tarif auftauchen: Jemand muss es hochverfügbar servieren, aufpassen, dass es nicht degradiert, es aktualisieren, wenn eine bessere Version kommt, und in Rufbereitschaft sein, wenn es umkippt. Diese Kosten sind eine Gehaltsliste, keine Rechnungszeile, und sie sind wiederkehrend. Die geschlossene API versteckt diese Kosten im Token-Preis; Open Source reicht sie ganz an dein Team weiter.
Deshalb ist der ehrliche Vergleich nicht „teure API gegen billiges Open Source“. Er lautet „variable Kosten, die du nicht steuerst, gegen fixe Kosten, die du steuerst“. Bei niedrigem oder mittlerem Volumen gewinnt fast immer das Variable. Bei hohem Volumen mit dediziertem Team das Fixe. Dieselbe Grundlogik, die Kaufen von Bauen bei jedem KI-Baustein trennt, die wir schon in KI-Agenten kaufen oder bauen verteidigt haben.
Was du am Montag tust
- Starte mit einer geschlossenen API und validiere, dass der Fall in deinem echten Betrieb funktioniert, nicht in einer Demo. Die Token-Kosten davor zu optimieren heißt, etwas zu optimieren, das nicht existiert.
- Entkopple ab dem ersten Tag. Baue die App so, dass der Modellanbieter Konfiguration ist, keine Verdrahtung. So kostet ein späterer Wechsel einen Nachmittag, kein Quartal.
- Markiere deine Auslöser. Schreib schwarz auf weiß, welche Daten nicht raus dürfen und ab welchem Volumen die Rechnung wehtun würde. An dem Tag, an dem einer eintritt, hast du dein Signal, auf Open Source herunterzugehen —und nur an dem Tag—.