Souveräne generative KI

Warum der RUN eines selbst gehosteten LLM strukturell nicht tragfähig ist

Analyse für IT-Leitungen

Es ist verlockend, für einen IT-Leiter, der die Isolation seiner kritischen Systeme im Blick hat, das eigene Hosting des oder der für Entwicklung oder Betrieb nützlichen LLMs zu erwägen. Wir betrachten hier den Einsatz von DeepSeek V4 Pro (MoE, Think, 1,6 T Parameter, 49 B aktiviert, 1 M Kontext). Die Versprechen sind verlockend: vollständige Datenkontrolle, Unabhängigkeit von API-Anbietern, unbegrenzte Anpassung. Doch hinter der Attraktivität von Bare-Metal verbirgt sich eine operative Realität, der sich nur wenige Organisationen stellen wollen. Eine Analyse.

Die wahren Kosten des RUN

Ein Modell mit 1,6 Billionen Parametern benötigt in INT4-Quantisierung rund 20 NVIDIA H100 GPUs, um zu laufen. Im Cloud-Leasing liegt der Einstiegspreis bei etwa 30 K€ pro Monat, also 360 K€ pro Jahr allein für Rechenleistung. Doch diese Zahl ist ein Trugbild.

Hinzu kommen die Personalkosten. Der Betrieb und die Überwachung eines Inferenz-Clusters dieser Größenordnung erfordern mindestens 1,5 bis 2 Vollzeitstellen spezialisierter MLOps-Ingenieure, also 150 bis 200 K€ pro Jahr inklusive Arbeitgeberkosten in Frankreich. Modell-Updates, Serving-Optimierung (vLLM, SGLang, TensorRT-LLM), Latenz-Monitoring, KV-Cache-Verwaltung und Rekonfigurationen bei Lastspitzen lassen sich nicht improvisieren.

Dazu kommen Netzwerkschicht, Perimeter-Sicherheit, Softwarelizenzen, NVMe-Speicher für Checkpoints und Backup. Der reale TCO liegt zwischen 550 und 650 K€ pro Jahr, für eine einzige Instanz, ohne Redundanz.

Ein architektonischer SPOF by design

Der kritischste Punkt: Das Modell ist über 20 GPUs im Tensor-Parallelismus verteilt. Fällt eine einzige GPU aus, steht der gesamte Dienst still. Es gibt keinen degradierten Modus. Es gibt kein partielles Failover. Ein Cluster aus 20 GPUs bietet mechanisch die 20-fache Ausfallfläche eines klassischen Servers.

Um einen minimalen Standard-SLA von 99,9 % für einen Enterprise-Produktionsdienst zu erreichen, muss die Infrastruktur verdoppelt werden: ein zweiter Cluster im Warm-Standby, also 60 K€/Monat GPU-Leasing und ein jährlicher TCO von über einer Million Euro. An diesem Punkt ist die Frage nicht mehr technisch, sondern strategisch: Rechtfertigt die erbrachte Leistung eine solche Investition?

Geplante Obsoleszenz als Grenze

Das Iterationstempo der Foundation-Modelle beschleunigt sich exponentiell. DeepSeek V3 erschien Anfang 2025, V4 wenige Monate später. Jede neue Generation macht die vorherige deutlich leistungsschwächer. Ein IT-Leiter, der sich für 3 Jahre GPU-Leasing für ein bestimmtes Modell bindet, investiert in einen Vermögenswert, dessen Nutzwert sich alle 6 bis 12 Monate halbiert.

Beim Hardwarekauf (Bare-Metal in Eigenregie, rund 300 bis 400 K€ für 8 H100) wird das Obsoleszenzrisiko zur Bilanzfalle: eine Aktivierung über 3 bis 5 Jahre für Hardware, deren technologische Relevanz die 18 Monate wahrscheinlich nicht übersteigt.

Ökonomische Rationalität gegen Kontrollinstinkt

Angesichts dieser Befunde zeigt die Nutzung manageter APIs, ob von DeepSeek, OpenAI, Anthropic oder aufstrebenden europäischen Anbietern, ein radikal anderes Profil.

Beim Volumen entsprechen 30 K€ monatlich für die DeepSeek-API etwa 8 bis 10 Millionen Anfragen pro Monat, also dem 5- bis 10-Fachen des im Self-Hosting erreichbaren Volumens. Die Elastizität ist nativ: kein Provisioning, keine präventive Überdimensionierung, keine GPUs, die um 3 Uhr morgens ungenutzt sind.

Beim SLA garantieren die großen API-Anbieter Uptimes von 99,9 % bis 99,95 % mit automatischem Failover, globalem Load Balancing und 24/7-Support. Ein Resilienzniveau, das keine Organisation intern mit vergleichbarem Budget reproduzieren kann.

Beim Unterhalt sind die Grenzkosten null: kein Patchen, keine Modellmigration, keine CUDA-Versionsverwaltung. Wenn DeepSeek V5 erscheint, erfolgt der Wechsel durch eine Parameteränderung in einem API-Aufruf.

Wie man die Risiken des API-Modells mindert

Seien wir ehrlich: Das API-Modell ist nicht risikofrei.

Die Datensouveränität ist die erste Sorge. Prompts und Antworten laufen über Server Dritter, möglicherweise außerhalb der europäischen Gerichtsbarkeit. Für sensible Daten (Gesundheit, Verteidigung, personenbezogene Daten im Sinne der DSGVO) ist das ein reales Hindernis. Doch es gibt Abhilfe: Einige Anbieter bieten dedizierte Bereitstellungen in der EU-Region (Scaleway AI, Azure OpenAI in Frankreich, OVHcloud AI Endpoints), und Ende-zu-Ende-Verschlüsselung in Kombination mit Vertragsklauseln (DPA, SCC) reduziert die rechtliche Exposition erheblich.

Die Anbieterabhängigkeit (Vendor Lock-in) ist das zweite Risiko. Doch das heutige Ökosystem ist strukturell wettbewerblich: Die APIs sind weitgehend kompatibel zwischen Anbietern (das OpenAI-Format ist De-facto-Standard geworden), und die Migration von einem Anbieter zum anderen dauert Stunden, nicht Monate. Das Lock-in einer selbst betriebenen GPU-Infrastruktur ist paradoxerweise weit restriktiver.

Die Tarifvariabilität ist das dritte Risiko. API-Preise können sich ändern. Doch sie sind seit 2023 nur gesunken, und zwar spektakulär (je nach Modell um den Faktor 10 bis 100). Der langfristige Markttrend spricht für den API-Nutzer, nicht für den Infrastrukturbetreiber.

Abwägung: das Entscheidungsraster des IT-Leiters

Das Selbsthosting eines LLM der Billionen-Klasse ist nur für wenige Organisationen rational: jene, die eine strikte regulatorische Vorgabe zur Datenlokalisierung, ein massives und konstantes Inferenzvolumen zur Rechtfertigung der Amortisation und ein bereits aufgestelltes, reifes MLOps-Team vereinen.

Für alle anderen (also die überwiegende Mehrheit der Unternehmen) bleibt das API-Modell im Jahr 2026 die tragfähigste, resilienteste und ökonomisch rationalste Wahl. Die Rolle des IT-Leiters ist nicht, die Infrastruktur der KI zu besitzen, sondern sicherzustellen, dass die KI der Unternehmensstrategie mit dem besten Verhältnis von Wert zu Risiko dient. Heute neigt sich dieses Verhältnis entschieden zur API-Seite.