On-Premises LLM für den Mittelstand: TCO und Break-even gegenüber Cloud-API

Viele CIOs im Mittelstand starten mit einer Cloud-API für Sprachmodelle, weil der Einstieg schnell und vermeintlich günstig ist. Spätestens wenn Konstruktion, Service und Backoffice täglich tausende Anfragen stellen, kippt die Rechnung. Dann stellt sich die Frage, ob ein eigenes, self hosted KI-Setup wirtschaftlich und organisatorisch sinnvoller ist.

Dieser Beitrag zeigt, ab welchem Punkt eine Cloud-API wirtschaftlich unattraktiv wird, wie Sie einen KI-Server selbst hosten, welche Hardware-Klassen für LLM-GPUs im Mittelstand realistisch sind und wie Sie TCO, SLA und Compliance sauber zusammenbringen. Die Perspektive ist bewusst pragmatisch: Sie sollen belastbare Entscheidungen treffen können, nicht nur Technologie-Trends bewerten.

Wann eine Cloud-API wirtschaftlich kippt

Cloud-APIs wirken zu Beginn attraktiv, weil keine Anfangsinvestition nötig ist und die Abrechnung nutzungsbasiert erfolgt. Für erste Prototypen und begrenzte Nutzergruppen ist das oft sinnvoll. Problematisch wird es, wenn sich LLM-Funktionen in Kernprozesse einschleifen und das Anfragevolumen stark wächst.

Ein typisches 200-Mitarbeiter-Setup mit produktiv genutzten LLM-Funktionen verursacht schnell etwa 14.400 Euro Cloud-API-Kosten pro Jahr. Diese Zahl ist kein Extremfall, sondern eine realistische Größenordnung bei mittlerem Nutzungsvolumen. Ab diesem Punkt verschiebt sich der Break-even deutlich in Richtung On-Premises-Betrieb, insbesondere wenn Sie von einem Pilot in Richtung flächendeckender Nutzung gehen.

Für viele mittelständische Unternehmen ist entscheidend, dass die Kostenkurve der Cloud-API nahezu linear mit dem Nutzungsvolumen steigt. Sobald Sie LLM-Funktionen in mehrere Abteilungen ausrollen, vervielfacht sich die Anzahl der Tokens und damit die Rechnung. Ein self hosted KI-Setup auf eigener Hardware verhält sich anders: Die Investition ist fix, die Grenzkosten pro zusätzlicher Anfrage sinken stark.

Hinzu kommt ein zweiter Effekt, der in Budgetrunden oft unterschätzt wird. Cloud-Kosten tauchen als operative Ausgaben auf, die jedes Jahr neu verhandelt werden. Hardware-Investitionen sind dagegen planbare Festkosten, die über mehrere Jahre abgeschrieben werden können. Für CFOs und CIOs, die Planungssicherheit schätzen, ist das ein gewichtiger Punkt.

Wann On-Premises wirtschaftlich wird

Sobald LLM-Funktionen in mehreren Kernprozessen genutzt werden, kippt die lineare Kostenkurve der Cloud-API. Ab mittlerem Volumen ist ein On-Premises-Setup mit fixen Hardware-Kosten in vielen Mittelstands-Szenarien günstiger und besser planbar.

Ein weiterer Aspekt ist die Kontrolle über Modellwahl und Datenflüsse. Wer auf eine externe Cloud-API setzt, akzeptiert nicht nur variable Kosten, sondern auch Abhängigkeiten bei Preisgestaltung, Rate-Limits und Funktionsumfang. Ein On-Premises LLM im Mittelstand reduziert dieses Vendor-Lock-in-Risiko deutlich, weil Sie Architektur und Betrieb selbst bestimmen.

Was Sie davon mitnehmen: Ein weiterer Aspekt ist die Kontrolle über Modellwahl und Datenflüsse.

Wovon die Hardware-Auswahl wirklich abhängt

Viele Diskussionen über LLM-Hardware drehen sich um einzelne Grafikkarten-Modelle oder Benchmarks. Für die TCO-Betrachtung im Mittelstand sind andere Fragen wichtiger. Entscheidend sind Nutzerzahlen, typische Prompt-Längen, Antwortzeiten und die gewünschte Verfügbarkeit. Erst daraus leitet sich ab, wie Sie Ihren KI-Server selbst hosten sollten.

Ein zentraler Punkt ist der Einstieg. Einstiegs-Hardware für Mittelstands-Setups ist bereits ab 2.400 Euro verfügbar. Das reicht nicht für ein globales Callcenter, wohl aber für ein internes Wissens-Chat-System mit begrenzter Nutzerzahl oder für erste produktive Piloten in einer Abteilung. Wer später skaliert, ergänzt weitere Knoten, anstatt die erste Investition zu verwerfen.

Für ein self hosted KI-Szenario im KMU-Umfeld sollten Sie drei Dimensionen sauber klären. Erstens, welche Modellklasse Sie einsetzen wollen, etwa kompaktere Modelle für einfache Assistenzaufgaben oder größere Modelle für komplexe Analysen. Zweitens, welche Antwortzeiten akzeptabel sind. Drittens, wie viele gleichzeitige Nutzer Sie bedienen müssen. Diese Parameter bestimmen, ob Sie mit einem einzelnen LLM-GPU-Server im Mittelstand starten können oder ob ein kleiner Cluster nötig ist.

Ein häufiger Fehler ist die Überdimensionierung aus Angst vor Engpässen. Das treibt die Investition in die Höhe, ohne den tatsächlichen Bedarf zu treffen. Sinnvoller ist ein schrittweiser Ausbau entlang klar definierter Service-Levels. Ein interner Wissens-Chat mit 50 Nutzern braucht andere Ressourcen als eine automatisierte Angebotsprüfung mit SLA-Verpflichtung gegenüber Kunden.

Was Sie davon mitnehmen: Ein häufiger Fehler ist die Überdimensionierung aus Angst vor Engpässen.

Modellgrößen, Tokens pro Sekunde und reale Antwortzeiten

Die Diskussion um Modellgrößen ist oft emotional aufgeladen. In der Praxis zählt, welche Antwortqualität Sie für Ihren Anwendungsfall benötigen und wie sich diese Qualität in Tokens pro Sekunde und Antwortzeiten übersetzen lässt. Ein LLM-Hardware-Kalkulator, der Nutzerzahlen, Kontextlängen und gewünschte Latenzen berücksichtigt, ist hier deutlich hilfreicher als generische Benchmark-Tabellen.

Ein wichtiger Referenzpunkt ist die Token-Rate pro GPU. VLLM erreicht etwa 85 Tokens pro Sekunde auf RTX-Klasse-Hardware bei 70B-Modellen. Diese Zahl zeigt, dass selbst sehr große Modelle auf gut konfigurierter Standard-Hardware im Mittelstand lauffähig sind, sofern die Architektur stimmt und das Scheduling sauber gelöst ist.

Für die Praxis bedeutet das: Wenn Sie ein großes Modell mit 70 Milliarden Parametern für interne Assistenzfunktionen einsetzen, können Sie mit einer modernen GPU bereits mehrere parallele Sessions mit akzeptablen Antwortzeiten bedienen. Für hochinteraktive Szenarien mit vielen gleichzeitigen Nutzern oder langen Kontexten planen Sie entsprechend mehr Reserven ein.

In der Architekturentscheidung spielt auch die Frage eine Rolle, ob Sie mehrere kleinere Modelle kombinieren oder ein großes Modell zentral betreiben. Ein ollama-vLLM-Vergleich im eigenen Lab-Setup kann helfen, die richtige Balance aus Flexibilität, Performance und Betriebsaufwand zu finden. Wichtig ist, dass Sie diese Tests mit realistischen Prompts und echten Nutzungsprofilen durchführen, nicht nur mit synthetischen Benchmarks.

Für CIOs ist wichtig, dass diese Dimensionierung nicht statisch ist. Sie können mit einem konservativen Setup starten und anhand realer Nutzungsdaten nachsteuern. sensified setzt hier auf eine Kombination aus Monitoring, Lastprofil-Analyse und iterativer Anpassung, um Über- oder Unterdimensionierung zu vermeiden.

Was Sie davon mitnehmen: Für CIOs ist wichtig, dass diese Dimensionierung nicht statisch ist.

Praxisbeispiel: On-Premises LLM im Maschinenbau

In einem Sondermaschinenbau-Unternehmen mit 380 Mitarbeitenden wuchsen die LLM-Nutzungszahlen innerhalb weniger Monate stark an. Konstruktion und Service nutzten ein Cloud-basiertes System zur Angebotskalkulation, Stücklistenprüfung und Service-Dokumentation. Das API-Volumen stieg mit jedem neuen Projekt, die Cloud-Kosten skalierten überproportional und wurden zum Dauerthema in den Budgetrunden.

Gemeinsam mit sensified entschied sich der CIO für ein KI-Projekt mit klarer Zielsetzung: Aufbau eines On-Premises LLM-Stacks im eigenen Rechenzentrum, DSGVO-konform und TISAX®-kompatibel. In der Discovery-Phase wurden Nutzungsprofile und SLA-Anforderungen aus Konstruktion und Service erhoben, anschließend entstand ein Design mit einem zentralen LLM-GPU-Server und einem Fallback-Knoten. In der Build-Phase implementierte sensified eine Multi-LLM-Umgebung mit RAG-Funktionalität, angebunden an vorhandene Systeme. Der Betrieb wurde zunächst durch sensified begleitet, anschließend mit vollständiger Code-Übergabe an das interne IT-Team übergeben.

Das Ergebnis war klar messbar. Über einen Zeitraum von 36 Monaten lag die TCO des On-Premises-Setups gegenüber der bisherigen Cloud-API um etwa 32 Prozent niedriger. Gleichzeitig gewann das Unternehmen Souveränität über seine Konstruktions- und Servicedaten, ohne Kompromisse bei DSGVO und TISAX einzugehen. Die Fachbereiche bemerkten den Wechsel vor allem durch stabilere Antwortzeiten und weniger Rate-Limit-Probleme.

Was Sie davon mitnehmen: Das Ergebnis war klar messbar.

Praxisbeispiel: On-Premises LLM im Banking

Eine Privatbank mit 240 Mitarbeitenden wollte LLM-Funktionen für Kreditprüfung, interne Wissenssuche und regulatorische Auswertungen nutzen. Die BaFin-Anforderungen und interne Richtlinien schlossen jedoch ein Routing sensibler Daten über US-basierte Hyperscaler-Plattformen faktisch aus. Eine klassische Cloud-API war damit keine Option, obwohl die Fachbereiche bereits konkrete Use Cases vorbereitet hatten.

In diesem Umfeld setzte die Bank auf die KI-Plattform von sensified als gemanagte On-Premises-Lösung. Die Plattform wurde im eigenen Rechenzentrum installiert, mit strikter Trennung der Datenebenen und Protokollierung aller Modellaufrufe. DSGVO, DORA und BAIT-Vorgaben wurden in der Architektur und im Betriebskonzept verankert, inklusive Audit-Trails und Rollenmodellen. Innerhalb von sechs Wochen war das On-Premises-Sizing abgeschlossen, die Plattform produktiv und die Compliance-Ampel stand auf Grün.

Die Bank konnte damit mehrere LLM-gestützte Anwendungen parallel betreiben, ohne regulatorische Grauzonen zu betreten. Die Kostenstruktur war transparent, da Hardware und Plattformbetrieb klar kalkuliert wurden. Für den CIO war besonders wichtig, dass die Lösung ohne Vendor-Lock-in auskam und bei Bedarf um weitere Modelle und Anwendungsfälle erweitert werden konnte.

Was Sie davon mitnehmen: Die Bank konnte damit mehrere LLM-gestützte Anwendungen parallel betreiben, ohne regulatorische Grauzonen zu betreten.

Praxisbeispiel: On-Premises LLM im Handel

Ein Filialhändler mit 460 Mitarbeitenden nutzte LLM-Funktionen für Sortimentsplanung, Filialkommunikation und Marketingtexte. Die Lastprofile waren stark saisonal geprägt, etwa vor Feiertagen und Aktionswochen. In diesen Spitzenzeiten explodierten die Cloud-API-Kosten, während in ruhigeren Phasen viel ungenutztes Budget übrig blieb. Für den CFO war das Cloud-Budget kaum planbar.

Gemeinsam mit sensified entschied sich das Unternehmen für ein KI-Result-Modell. sensified betrieb eine On-Premises LLM-Infrastruktur im Rechenzentrum des Händlers, über die definierte Outputs wie geprüfte Produktbeschreibungen oder freigegebene Aktionsflyer zu einem Stückpreis geliefert wurden. Die Hardware war als Festkostenblock kalkuliert, die Nutzung orientierte sich an klar definierten Ergebnissen. DSGVO-Anforderungen wurden durch den ausschließlichen Betrieb in der EU und die Trennung von Trainings- und Inferenzdaten erfüllt.

Die Hardware-Investition amortisierte sich in diesem Szenario in elf Monaten. Spitzenlasten konnten ohne Kostensprung abgefangen werden, da die Infrastruktur auf die saisonalen Peaks ausgelegt war. Für den CFO entstand eine deutlich stabilere Kostenbasis, während die Fachbereiche von kürzeren Durchlaufzeiten und höherer Verfügbarkeit der LLM-Funktionen profitierten.

On-Premises lohnt sich in klar umrissenen Szenarien

Wo Volumen, Compliance-Anforderungen oder saisonale Spitzen klar definiert sind, ermöglicht ein On-Premises LLM eine präzise kalkulierbare Kostenstruktur und reduziert Abhängigkeiten von externen Plattformen deutlich.

Was Sie davon mitnehmen: Wo Volumen, Compliance-Anforderungen oder saisonale Spitzen klar definiert sind, ermöglicht ein On-Premises LLM eine präzise kalkulierbare Kostenstruktur und reduziert Abhängigkeiten von externen Plattformen deutlich.

Die TCO-Rechnung über 36 Monate

Für eine fundierte Entscheidung zwischen Cloud-API und On-Premises-Betrieb reicht ein Monatsvergleich nicht aus. Sinnvoll ist eine TCO-Betrachtung über mindestens 36 Monate, die Hardware, Betrieb, Wartung und gegebenenfalls Lizenzen berücksichtigt. Nur so erkennen Sie, ob ein self hosted KI-Setup im KMU-Umfeld tatsächlich günstiger ist.

In der Praxis hat sich ein dreistufiges Vorgehen bewährt. Zunächst erfassen Sie das aktuelle oder erwartete Nutzungsvolumen in Tokens, Anfragen und gleichzeitigen Sessions. Anschließend kalkulieren Sie die Cloud-API-Kosten auf dieser Basis und projizieren sie über drei Jahre, inklusive realistischer Wachstumsannahmen. Parallel dazu planen Sie ein On-Premises-Setup mit Investitionskosten, Energiekosten und Personalaufwand.

sensified nutzt hierfür einen internen LLM-Hardware-Kalkulator, der Nutzerzahlen, SLA-Anforderungen und Modellklassen kombiniert. Auf dieser Basis entstehen Szenarien, die zeigen, ab welchem Volumen der Break-even erreicht ist. In vielen Mittelstands-Setups mit 200 bis 500 Mitarbeitenden liegt dieser Punkt deutlich früher, als CIOs zunächst vermuten.

Ein weiterer Vorteil der 36-Monats-Perspektive ist die bessere Planbarkeit von Erweiterungen. Wenn Sie wissen, dass ein zweiter GPU-Server im zweiten Jahr nötig wird, können Sie diese Investition frühzeitig in die Budgetplanung aufnehmen. Für CFOs entsteht damit ein klarer Pfad von der Pilotphase zur flächendeckenden Nutzung, ohne Überraschungen bei den Kosten.

Was Sie davon mitnehmen: Ein weiterer Vorteil der 36-Monats-Perspektive ist die bessere Planbarkeit von Erweiterungen.

SLA-orientierte Dimensionierung statt Bauchgefühl

Die Frage, wie groß ein On-Premises LLM-Setup sein muss, wird in vielen Projekten aus dem Bauch heraus beantwortet. Das führt entweder zu Engpässen oder zu unnötig hohen Investitionen. Sinnvoller ist eine Dimensionierung entlang klar definierter Service-Level-Agreements, die Fachbereiche und IT gemeinsam festlegen.

Ein SLA-orientierter Ansatz beginnt mit der Definition, welche Antwortzeiten für welche Nutzergruppen akzeptabel sind. Ein interner Wissens-Chat für die Verwaltung verträgt andere Latenzen als ein LLM-gestützter Angebotskonfigurator im Vertrieb. Aus diesen Anforderungen leiten Sie ab, wie viele Tokens pro Sekunde Sie bereitstellen müssen und wie viele parallele Sessions unterstützt werden sollen.

Auf dieser Basis lässt sich die Hardware-Ausstattung präzise planen. Wenn Sie wissen, dass ein bestimmtes Setup mit vLLM etwa 85 Tokens pro Sekunde auf RTX-Klasse-Hardware liefert, können Sie berechnen, wie viele GPUs für Ihre Ziel-SLAs nötig sind. Das Ergebnis ist eine belastbare Dimensionierung, die weder unter- noch übertrieben ist.

Für den laufenden Betrieb ist ein strukturiertes Monitoring entscheidend. Nur wenn Sie Auslastung, Antwortzeiten und Fehlerraten kontinuierlich messen, können Sie frühzeitig erkennen, wann eine Erweiterung sinnvoll ist. sensified verankert diese Mechanismen standardmäßig in KI-Projekten und auf der KI-Plattform, damit CIOs nicht im Blindflug entscheiden müssen.

Was Sie davon mitnehmen: Für den laufenden Betrieb ist ein strukturiertes Monitoring entscheidend.

Compliance, Souveränität und Schrems-II-Risiken

Neben Kosten und Performance spielt die regulatorische Seite eine zentrale Rolle. Für viele Mittelständler ist ein On-Premises LLM auch deshalb attraktiv, weil sich damit DSGVO-Anforderungen und branchenspezifische Vorgaben besser kontrollieren lassen. Daten bleiben im eigenen Rechenzentrum oder in einer EU-gehosteten Umgebung, die unter der direkten Kontrolle des Unternehmens steht.

Die Schrems-II-Rechtsprechung hat die Nutzung von Cloud-Diensten mit Datenübertragung in Drittländer deutlich komplizierter gemacht. Wer sensible Kunden-, Mitarbeiter- oder Produktionsdaten über externe Plattformen verarbeitet, muss umfangreiche vertragliche und technische Schutzmaßnahmen nachweisen. Ein on premise LLM mit DSGVO-konformer Architektur reduziert diese Risiken, weil keine personenbezogenen Daten das eigene Kontrollgebiet verlassen.

Hinzu kommt der EU AI Act, der je nach Risikoklasse der Anwendung zusätzliche Anforderungen an Transparenz, Monitoring und Dokumentation stellt. Ein On-Premises-Setup erleichtert die Umsetzung dieser Vorgaben, weil Sie Zugriff auf alle relevanten Logs, Modelle und Konfigurationen haben. Für TISAX-pflichtige Unternehmen oder Institute unter DORA und BAIT ist diese Transparenz oft ein entscheidender Vorteil.

sensified legt in allen drei Modellen, KI-Projekt, KI-Plattform und KI-Result, Wert auf auditierbare Architekturen. Das umfasst nachvollziehbare Datenflüsse, Protokollierung von Modellentscheidungen und klare Verantwortlichkeiten im Betrieb. Anstatt nur Strategiepapiere zu liefern, setzt sensified produktive Systeme um, die Compliance-Anforderungen technisch verankern.

Was Sie davon mitnehmen: sensified legt in allen drei Modellen, KI-Projekt, KI-Plattform und KI-Result, Wert auf auditierbare Architekturen.

Nächste Schritte

Wenn Sie prüfen möchten, ob ein On-Premises LLM für Ihr Unternehmen wirtschaftlich und regulatorisch sinnvoll ist, sollten Sie zunächst Ihr aktuelles oder geplantes Nutzungsvolumen erfassen und grob gegen die erwarteten Cloud-API-Kosten spiegeln. Auf dieser Basis lässt sich schnell erkennen, ob sich eine detaillierte TCO-Analyse über 36 Monate lohnt.

Im nächsten Schritt empfiehlt sich ein strukturiertes KI-Projekt mit sensified, in dem Nutzungsprofile, SLA-Anforderungen und Compliance-Vorgaben gemeinsam aufgenommen und in ein konkretes Architektur- und Hardware-Design übersetzt werden. So entsteht innerhalb weniger Wochen ein belastbarer Plan, ob ein self hosted KI-Setup, eine gemanagte KI-Plattform oder ein KI-Result-Modell für Sie der beste Weg ist.

Wenn Sie diesen Weg gehen möchten, ist ein unverbindliches Strategiegespräch der sinnvollste Einstieg, um Ihre Ausgangslage, mögliche Break-even-Szenarien und die nächsten konkreten Schritte zu klären.