Ein eigenes Modell auf der eigenen Infrastruktur zu betreiben, statt eine fremde Schnittstelle anzurufen, ist der ultimative „ich hänge von keinem Anbieter ab”-Schritt. Und genau deshalb ist er verführerisch — gerade für jemanden, der Datenhoheit ernst nimmt. Aber bevor du Hardware kaufst, eine ehrliche Ansage: Du entfernst die Kosten nicht, du verschiebst sie. Weg von der Abrechnung pro Anfrage, hin zu GPUs, Betrieb und Know-how.
Wie beim selbst gehosteten n8n ist das ein Tausch von Datenhoheit gegen Eigenverantwortung — nur schwerer, weil GPUs im Spiel sind. Diese Seite zeigt, wann sich der Tausch lohnt und wann er ein Geldgrab wird.
Warum man es überhaupt erwägt
Es gibt eine Handvoll echter Gründe. Der stärkste ist Datenhoheit: Sensible Daten — Patientenakten, Verträge, Personaldaten — verlassen deine Kontrolle nie, kein Dritter sieht die Anfragen. In regulierten Bereichen ist das oft kein Wunsch, sondern eine Vorgabe. Das ist der Grund, der allein schon trägt.
Daneben stehen schwächere: Kosten bei wirklich hohem, stetigem Volumen, bei dem die Rechnung gegen die Bezahl-pro-Anfrage kippt. Unabhängigkeit — keine Limits, kein Ausfall einer fremden Schnittstelle, kein Modell, das dir unter den Füßen abgekündigt wird. Und tiefe Anpassung über Feinabstimmung am eigenen Modell. Welcher dieser Gründe bei dir wirklich greift, entscheidet alles Weitere.
Du entfernst die Kosten nicht, du verschiebst sie
Der häufigste Denkfehler: „Open-Weight ist kostenlos, also spare ich die API-Gebühren.” Das Modell selbst kostet nichts, der Betrieb sehr wohl. GPUs sind teuer, ob gekauft oder gemietet, und ein Modell mit vernünftiger Antwortzeit zu bedienen braucht Hardware, die ausgelastet sein will. Die Kosten wandern von der Abrechnung pro Anfrage hin zu Infrastruktur, Betrieb und Fachwissen.
Der Spareffekt gegen die API gilt nur bei echtem, stetigem Volumen mit guter Auslastung. Hast du stoßweise oder geringe Last, ist die API um Längen billiger — du würdest teure GPUs bezahlen, die die meiste Zeit Däumchen drehen. Wer „spart, indem er selbst hostet” sagt, ohne diese Rechnung gemacht zu haben, spart meist nicht.
Die Fähigkeitslücke ehrlich einschätzen
Open-Weight-Modelle haben gewaltig aufgeholt und sind für die allermeisten Geschäftsaufgaben mehr als gut genug. Aber an der absoluten Spitze, bei den härtesten Schlussfolgerungs-Aufgaben, liegen meist noch die gehosteten, geschlossenen Modelle vorn. Du tauschst also unter Umständen ein Stück Spitzenfähigkeit gegen Kontrolle.
Die ehrliche Frage ist deshalb: Braucht deine Aufgabe wirklich das Allerbeste, oder reicht ein gutes Modell? Für die meisten Mittelstand-Anwendungen — Texte aufbereiten, Dokumente einordnen, ein Archiv beantworten — reicht ein gutes Open-Weight-Modell locker. Nur wo es auf die letzte Stufe an Denkleistung ankommt, ist der Verzicht spürbar. Das misst du an deinem Prüfsatz, nicht am Bauchgefühl.
Wie ich das angehe
Datenhoheit, bewiesenes Volumen oder tiefe Anpassung. Gibt es keinen davon, bleibst du bei der Schnittstelle — Selbsthosten aus Prinzip ist ein Geldgrab.
Nicht das größte. Ein kleines, passendes Modell schlägt ein großes, allgemeines auf deiner konkreten Aufgabe — und läuft auf bezahlbarer Hardware.
Das Modell verkleinern, mit etwas Qualitätsverlust, um es schnell und günstig zu bedienen. Der entscheidende Hebel, um Hardware-Kosten zu drücken.
Ein Serving-Aufbau, der die Anfragen schnell genug beantwortet — für Ernsthaftes etwa vLLM, für Kleines und Lokales Ollama.
Verfügbarkeit, Updates, Sicherheit des Endpunkts. Das gehört jetzt dir, samt der Abende, an denen etwas nicht läuft.
Wo es kippt
Selbst hosten aus Prinzip. Der größte Fehler. Ohne harten Treiber ist die API schneller startklar, billiger und fähiger. Fang dort an und wechsle nur, wenn ein konkreter Grund es rechtfertigt.
Das GPU-Geldgrab. Bei geringer oder stoßweiser Last bezahlst du Hardware, die nichts tut. Der Spareffekt kommt nur bei echtem, stetigem Volumen.
Die Fähigkeitslücke bei den harten Fällen. Braucht deine Aufgabe Spitzen-Denkleistung, ist der Verzicht spürbar. Erst am Prüfsatz messen, dann entscheiden.
Die Betriebslast. Du besitzt jetzt Verfügbarkeit, Updates und Sicherheit. Das ist eine laufende Aufgabe, kein einmaliges Aufsetzen.
Zu groß dimensioniert. Das größte Modell zu nehmen, weil es am besten klingt, treibt die Hardware-Kosten ins Absurde. Das kleinste, das besteht, gewinnt.
Was es kostet — und woran
In Summe: GPUs zum Kaufen oder Mieten, plus Betrieb, plus das Fachwissen, das alles am Laufen zu halten. Der Spareffekt gegen die API tritt erst bei echtem, stetigem Volumen ein. Bei Datenhoheit als Treiber rechnest du anders — da ist der Eigenbetrieb kein Sparmodell, sondern der Preis dafür, dass die Daten bei dir bleiben. Das ist ein Wert, keine Einsparung, und genau so solltest du ihn begründen.
Wer dir Selbsthosten als generell günstiger verkauft, hat die Auslastung nicht gerechnet. Die ehrliche Begründung ist fast immer Datenhoheit — und die ist es oft wert.
Wo du die Finger weglässt
Aus Ideologie hosten. Kein Anbieter-Unabhängigkeits-Gefühl rechtfertigt das Geldgrab ohne konkreten Treiber. API zuerst.
Das größte Modell nehmen. Mehr Modell als nötig ist mehr Hardware als nötig. Das kleinste, das deinen Prüfsatz besteht.
Den Betrieb unterschätzen. Verfügbarkeit und Sicherheit eines Modell-Endpunkts sind echte Arbeit. Wer das nicht leisten kann oder will, bleibt besser bei der Schnittstelle.
Selbst zu hosten ist Datenhoheit gegen Eigenverantwortung. Es lohnt sich, wenn die Daten zwingend bei dir bleiben müssen — selten allein, weil es billiger wäre.
Wie ein ehrlicher Einstieg aussieht
Benenne zuerst deinen Treiber. Ist es Datenhoheit, prototype das kleinste Open-Weight-Modell, das deinen Prüfsatz für eine abgegrenzte Aufgabe besteht — auf gemieteter GPU, nicht auf gekaufter. Miss drei Dinge: Reicht die Fähigkeit? Was kostet es wirklich, Betrieb eingerechnet? Und kannst du den Betrieb tragen? Erst wenn das steht, denkst du an eigene Hardware. Gibt es keinen harten Treiber, bleib auf der API und sichere stattdessen dort den Datenschutz vertraglich ab.
Worauf du achtest, wenn dir das jemand baut
- Gibt es einen konkreten Treiber — Datenhoheit, bewiesenes Volumen —, oder ist es Ideologie? Letzteres ist das Warnsignal.
- Wird das kleinste Modell genommen, das den Prüfsatz besteht, oder das größte „zur Sicherheit”?
- Ist man ehrlich über die Fähigkeitslücke bei den härtesten Aufgaben?
- Gibt es einen echten Plan für Betrieb und Sicherheit des Endpunkts?
- Wird die wahre Kostenrechnung gezeigt — inklusive Betrieb und Auslastung —, nicht nur „kein API-Preis”?
Die Entscheidung kommt vor der Hardware. Diese Liste sagt dir, ob Selbsthosten bei dir Sinn ergibt — und bewahrt dich vorm Geldgrab:
Selbst hosten — ja oder nein? (vor jeder Hardware-Entscheidung)
1. GIBT ES EINEN HARTEN TREIBER?
- Datenhoheit: Müssen die Daten zwingend bei dir bleiben (reguliert/sensibel)? -> starker Grund.
- Kosten: Hast du BEWIESEN hohes, stetiges Volumen, bei dem die Rechnung gegen die API kippt? -> Grund.
- Anpassung: Brauchst du tiefe Feinabstimmung, die nur am eigenen Modell geht? -> Grund.
Kein harter Treiber -> bleib bei der API. Selbst hosten aus Prinzip ist ein Geldgrab.
2. RICHTIG DIMENSIONIEREN: das KLEINSTE Modell, das deinen Prüfsatz für DEINE Aufgabe besteht,
nicht das größte. Quantisieren, um auf bezahlbare Hardware zu passen.
3. EHRLICHE KOSTEN: GPUs (kaufen/mieten) + Betrieb + Know-how. Der Spareffekt gilt nur bei echtem,
stetigem Volumen mit guter Auslastung.
4. BETRIEB: Verfügbarkeit, Updates, Sicherheit des Endpunkts — ab jetzt deine Aufgabe.Bei dir dürfen sensible Daten nicht zu einem Anbieter, oder du hast Volumen, bei dem sich Eigenbetrieb rechnen könnte? Dann reden wir ehrlich über deinen Treiber — und ob ein kleines, selbst betriebenes Modell trägt oder ob die API mit den richtigen Vorkehrungen der klügere Weg ist.