Die Entscheidung zwischen Self-Hosting und API ist die folgenreichste Infrastrukturentscheidung in der Enterprise-KI — und die am häufigsten auf unvollständiger Datenlage getroffene. Sie fällt selten in einem Business Case. Sie fällt in einem Meeting, in dem jemand sagt „unsere Daten dürfen das Haus nicht verlassen" — und damit eine Architektur festlegt, deren Kosten niemand im Raum sauber durchgerechnet hat.
DSGVO, Branchenaufsicht und ein berechtigtes Unbehagen gegenüber US-Hyperscalern drängen DACH-Unternehmen Richtung Eigenbetrieb. Der Reflex ist nachvollziehbar. Aber Datensouveränität ist ein Architekturziel, kein Kostenmodell. Wer beides verwechselt, kauft GPU-Cluster, die einen Bruchteil der Zeit ausgelastet sind, und nennt das Kontrolle. Diese Analyse trennt die beiden Fragen — und rechnet die zweite ehrlich durch.
Die API-Kostenstruktur
API-Inferenz ist in den letzten zwei Jahren dramatisch billiger geworden. Der Preis pro Token für ein gegebenes Qualitätsniveau ist im Quartalsrhythmus gefallen, weil Anbieter Modelle effizienter machen und sich gegenseitig unterbieten. Wichtiger als der absolute Preis ist die Bewegungsrichtung: Wer heute eine fünfjährige Self-Hosting-Amortisation gegen den aktuellen API-Preis rechnet, vergleicht eine fixe Investition gegen einen Wert, der über die Laufzeit weiter sinkt.
Die Struktur ist simpel und ehrlich: Sie zahlen pro Input- und Output-Token, getrennt bepreist, und die Kosten skalieren linear mit dem Volumen. Doppeltes Volumen, doppelte Rechnung — keine Sprungkosten, keine Leerlaufkosten. Für einen typischen Mittelstands-Workload — interne Wissensrecherche, Dokumentenverarbeitung, ein paar produktive Assistenzfunktionen — bewegt sich das bei einem Mittelklasse-Modell im niedrigen vierstelligen Euro-Bereich pro Monat. Ein durchgängig genutztes Frontier-Modell auf demselben Volumen liegt ein Vielfaches darüber. Beides sind Betriebskosten, keine Investitionen.
Der eigentliche Wert der API ist nicht der Preis, sondern die Abwesenheit von allem anderen. Keine GPU-Beschaffung in einem angespannten Markt, kein Kapazitäts-Engineering, keine Bereitschaftsrotation, keine Migration, wenn das nächste Modell erscheint. Eine Codezeile wechselt die Modellversion. Die Skalierung von einer auf hundert Millionen Token pro Tag erfordert keine einzige Infrastrukturänderung. Diese Optionalität hat in einer Phase, in der sich die Modelllandschaft alle paar Monate verschiebt, einen eigenen, oft unterschätzten Wert.
Die Self-Hosting-Kostenstruktur
Self-Hosting-Kosten sind frontlastig, nicht-linear und in fast jedem Business Case, den wir sehen, zu niedrig angesetzt. Der Fehler ist selten die Hardware. Der Fehler ist alles, was um die Hardware herum nötig ist, damit sie zuverlässig läuft.
Die Hardware ist der kleinere Teil. Eine NVIDIA H100 kostet 2026 im Direktkauf grob 25.000 bis 40.000 US-Dollar je nach Variante; ein produktionstauglicher 8-GPU-HGX-Server liegt regelmäßig jenseits von 250.000 und reicht bei DGX-Konfigurationen über 350.000 US-Dollar (IntuitionLabs, Cloud-GPU-Preisindizes 2026). Der gängigere Weg ist Miete: Eine H100 kostet bei spezialisierten GPU-Cloud-Anbietern rund 2 bis 3 US-Dollar pro Stunde, bei den großen Hyperscalern dagegen ein Mehrfaches — AWS um die 7, Azure um die 12 US-Dollar pro Stunde (Spheron, GetDeploying, Thunder Compute, 2026). Allein dieser Spread entscheidet einen Business Case mit, bevor die erste Inferenz läuft.
Auslastung ist der Hebel, über den niemand sprechen will. Eine gekaufte oder dauerhaft gemietete GPU kostet rund um die Uhr — ob sie rechnet oder nicht. Die API kostet nur, wenn Sie sie aufrufen. Damit Eigenbetrieb günstiger wird, muss die GPU einen hohen Anteil der Zeit produktiv ausgelastet sein. Genau das ist bei typischen Mittelstands-Workloads die Ausnahme: Last folgt Bürozeiten, schwankt über den Tag und konzentriert sich auf wenige Stunden. Eine zu 15 Prozent ausgelastete H100 ist nicht 15 Prozent so teuer — sie kostet voll und arbeitet selten.
Der Betrieb ist eine Dauerverpflichtung, kein Projekt. Ein produktives LLM-Deployment braucht Monitoring, Inferenz-Optimierung, Sicherheits-Patches, Fehlersuche und einen Plan für den Tag, an dem die GPU ausfällt. Das ist Arbeit, die nie endet — und sie setzt Skills voraus, die der DACH-Markt knapp und teuer bepreist. Wer ML-Infrastructure-Engineers neu einstellen muss, rechnet mit sechsstelligen Jahresgehältern pro Person und Besetzungszeiten von mehreren Monaten. Diese Personalkosten gehören in die Rechnung — sie sind oft der größte Posten und tauchen im Hardware-Vergleich nie auf.
Modellpflege fällt auf Sie zurück. Erscheint ein besseres offenes Modell, müssen Sie es selbst evaluieren, integrieren, testen und ausrollen — inklusive der Pipeline-Anpassungen drumherum. In der API erbt dieselbe Verbesserung Ihr System praktisch zum Nulltarif. Über eine mehrjährige Laufzeit ist das kein Detail, sondern ein struktureller Vorteil der API-Seite.
Die Break-Even-Frage
Die ehrliche Antwort lautet: Es gibt keine universelle Token-Schwelle, ab der Self-Hosting gewinnt. Jede Zahl, die ohne Ihre Auslastung, Ihre Modellgröße und Ihre Personalsituation genannt wird, ist Marketing. Der Break-Even ist eine Funktion aus drei Variablen, und alle drei sind unternehmensspezifisch.
Die belastbare Heuristik ist eine andere: Self-Hosting lohnt sich, wenn der Workload groß, gleichmäßig und vorhersehbar ist — hohe, konstante Last, die eine GPU dauerhaft füllt; ein Modell, das Sie nicht ständig wechseln; und ein Team, das den Betrieb ohnehin stemmt. Sobald eine dieser Bedingungen fehlt, kippt die Rechnung zugunsten der API. Bei den meisten Mittelständlern, die wir begleiten, ist die Last weder konstant noch hoch genug, um die Fixkosten und den Betriebsaufwand zu schlagen — und dann ist API-Inferenz schlicht günstiger, nicht nur einfacher.
Das heißt nicht, dass Eigenbetrieb nie sinnvoll ist. Es heißt, dass er ein Volumen- und Auslastungsspiel ist, kein Souveränitätsspiel. Wer Self-Hosting mit Datenschutz begründet statt mit Auslastung, optimiert die falsche Größe.
Die DACH-spezifischen Faktoren
Drei Faktoren verschieben die Kalkulation im DACH-Raum gegenüber jedem US-Rechenbeispiel — und alle drei verteuern die Self-Hosting-Seite zusätzlich.
Energie ist hier ein eigener Kostenblock. Deutschlands Industriestrompreise gehören zu den höchsten Europas und liegen deutlich über denen vergleichbarer Standorte (IEA, Clean Energy Wire, 2026). Der ab Januar 2026 eingeführte, EU-beihilferechtlich genehmigte Industriestrompreis entlastet zwar energieintensive Branchen wie Stahl, Chemie und Glas — er ist aber sektorgebunden und deckt nur einen Teil des Verbrauchs (Gleiss Lutz, 2026). Für den typischen Mittelständler, der GPUs betreiben will, gilt der reguläre Gewerbetarif. Ein 8-GPU-Server zieht im Dauerbetrieb mehrere Kilowatt rund um die Uhr — ein Posten, der im API-Modell schlicht nicht existiert.
Die Regulierung verteuert eigenes Eisen weiter. Nach dem Energieeffizienzgesetz (EnEfG) müssen Rechenzentren mit nicht-redundanter Anschlussleistung ab 300 kW seit 2024 mindestens 50 Prozent ihres Strombedarfs aus Erneuerbaren decken — ab Januar 2027 zu 100 Prozent — und bis 2030 einen PUE-Wert von höchstens 1,3 erreichen (§ 11 EnEfG; gesetze-im-internet.de). Wer eigene Kapazität in dieser Größenordnung aufbaut, erbt diese Pflichten und ihre Beschaffungs- und Compliance-Komplexität. Wer API nutzt, lässt sie beim Anbieter.
Datensouveränität gibt es auch ohne eigenes Rechenzentrum. Das stärkste Self-Hosting-Argument lautet „keine Daten an US-Server". Es übersieht, dass die großen Anbieter EU-residente Endpunkte betreiben — Azure West Europe, AWS Frankfurt, EU-Inferenz von Anthropic und anderen — die die meisten Data-Residency-Anforderungen erfüllen, ohne dass Sie eine einzige GPU kaufen. Der EU AI Act schreibt kein On-Premise-Hosting vor; er verlangt dokumentierte Daten-Governance, Risikoklassifizierung und Transparenz. Das ist eine Vertrags- und Prozessfrage, keine Hardwarefrage. Echte On-Premise-Pflicht entsteht erst in eng umrissenen Fällen — und die sollten Sie benennen können, bevor Sie sie als Architekturprinzip behandeln.
Die hybride Architektur ist die Default-Antwort
Für die meisten DACH-Mittelständler ist die kosteneffektivste Architektur nicht „API gegen Self-Hosting", sondern beides — bewusst getrennt. API als Standard für Entwicklung, Experimentierung und alle Workloads mit schwankendem oder moderatem Volumen, weil dort die Optionalität und die Null-Leerlaufkosten gewinnen. Eigenbetrieb gezielt nur für den einen Workload, der nachweislich groß, konstant und ausgelastet genug ist, um die Fixkosten zu schlagen — oder wenn eine echte regulatorische Vorgabe, keine Präferenz, On-Premise-Verarbeitung erzwingt.
Der teure Fehler ist nicht, sich für die falsche Seite zu entscheiden. Der teure Fehler ist, die Entscheidung pauschal und einmalig für das ganze Unternehmen zu treffen, statt sie pro Workload datenbasiert zu fällen. Inferenz-Ökonomie ist kein Glaubenssatz. Sie ist eine Rechnung — und die lässt sich mit Ihren echten Volumina, Ihrer echten Auslastung und Ihren echten Personalkosten in wenigen Stunden aufstellen.
Ein Fit Call rechnet Ihre Inferenz-Ökonomie konkret durch — Break-Even pro Workload, Volumen, Auslastung und regulatorische Randbedingungen — bevor Sie Kapital in Infrastruktur binden, die einen Bruchteil der Zeit arbeitet.
Referenzen: IntuitionLabs, „NVIDIA AI GPU Prices: H100 & H200 Cost Guide", 2026; Spheron, „GPU Cloud Pricing 2026"; GetDeploying, „H100 Cloud Pricing: Compare 45+ Providers", 2026; Thunder Compute, „NVIDIA H100 Pricing (June 2026)", 2026; IEA, „Electricity 2026 — Prices"; Clean Energy Wire, „Germany set to introduce industrial electricity price by beginning of 2026"; Gleiss Lutz, „Germany cuts costs for electricity-intensive companies from 1 January 2026", 2026; Energieeffizienzgesetz (EnEfG), § 11, gesetze-im-internet.de; EU AI Act (Verordnung (EU) 2024/1689).