Eigenes LLM betreiben: Was es kostet, was es braucht — und wann es sich lohnt

„Wir betreiben unser eigenes LLM” klingt nach Unabhängigkeit. Technisch ist der Einstieg heute einfach: ein Rechner mit ausreichend Grafikspeicher, ein Werkzeug wie Ollama, dreißig Minuten Zeit. Die schwierige Frage kommt danach. Wer ein eigenes LLM betreiben will, kauft nicht nur Rechenleistung, sondern eine Betriebsaufgabe. Dieser Beitrag rechnet nach, was das kostet — und zeigt, warum die Rechnung für viele Unternehmen gar nicht die entscheidende Frage ist.

Inhalt

• Was Self-Hosting bei LLMs wirklich bedeutet
• Hardware: Wie viel GPU ein Modell braucht
• Europäische Alternativen zur eigenen Hardware
• Werkzeuge: Ollama, Open WebUI und vLLM
• Die Kostenrechnung: Self-Hosted gegen API
• Wenn die Rechnung gar nicht entscheidet
• Nicht alles oder nichts: Prozesse trennen
• Fazit: Erst die Datenfrage, dann die Rechnung
• Häufige Fragen zum eigenen LLM
• Quellen

Was Self-Hosting bei LLMs wirklich bedeutet

Selbst gehostete AI heißt: Das Modell läuft auf Hardware, über die das Unternehmen verfügt. Keine Anfrage verlässt die eigene Infrastruktur. Das ist der eine Teil.

Der andere Teil ist Betrieb. Ein LLM selbst zu hosten bedeutet, dauerhaft Verantwortung zu übernehmen — für Verfügbarkeit, Aktualisierung, Zugriffsrechte, Protokollierung und Sicherheit. Ein Modell zu starten dauert Minuten. Es produktiv zu halten, ist eine laufende Aufgabe.

Drei Dinge werden dabei regelmäßig unterschätzt. Erstens die Auslastung: Eine GPU kostet gleich viel, ob sie rechnet oder wartet. Zweitens das Tempo: Offene Modelle erscheinen im Wochenrhythmus, jede Aktualisierung will getestet werden. Drittens die Oberfläche — ein API-Endpunkt allein ist kein Arbeitswerkzeug für Mitarbeitende.

Wo ein Unternehmen bei AI heute steht, lässt sich in wenigen Minuten einordnen: über den kostenlosen Self-Check.

Hardware: Wie viel GPU ein Modell braucht

Die entscheidende Größe ist der Grafikspeicher, kurz VRAM. Eine belastbare Faustformel: Parameterzahl mal Bits pro Gewicht, geteilt durch acht, ergibt den Speicherbedarf in Gigabyte. Ein Modell mit 8 Milliarden Parametern in 4-Bit-Quantisierung braucht also grob 4 GB — plus Reserve für Kontext und Zwischenspeicher.

In der Praxis ergeben sich vier Klassen:

• 8–12 GB VRAM: Modelle mit 7–8 Milliarden Parametern, quantisiert. Genug für Textaufgaben, Zusammenfassungen, einfache Klassifikation.
• 24 GB VRAM: Modelle bis rund 30 Milliarden Parameter, quantisiert. Deutlich bessere Qualität, spürbar mehr Kontext.
• 48 GB VRAM: 70-Milliarden-Modelle in Quantisierung oder mehrere kleinere Modelle parallel.
• 80–96 GB VRAM: Produktivbetrieb mit großen Modellen und mehreren gleichzeitigen Nutzenden.

Quantisierung ist dabei der wichtigste Hebel. Sie reduziert die Genauigkeit der Modellgewichte und damit den Speicherbedarf — bei moderatem Qualitätsverlust. Ein 70B-Modell, das in voller Präzision zwei Spezial-GPUs belegt, läuft quantisiert auf einer.

Wichtig ist der Unterschied zwischen „läuft” und „trägt”. Ein Modell auf dem Laptop antwortet für eine Person. Fünfzig gleichzeitige Anfragen sind eine andere Aufgabe. Dafür zählt nicht nur VRAM, sondern Durchsatz — die eigentliche Disziplin der LLM-Inferenz.

Die Frage ist nie, ob ein Modell läuft. Die Frage ist, ob der Betrieb trägt.

Europäische Alternativen zur eigenen Hardware

Wer keine Hardware kaufen will, mietet sie. Europäische Anbieter machen das ohne Umweg über US-Rechenzentren möglich — ein praktischer Baustein für digitale Souveränität.

Hetzner bietet mit dem GEX131 einen dedizierten GPU-Server mit 96 GB Grafikspeicher ab 889 € pro Monat, ohne Einrichtungsgebühr und in ISO-27001-zertifizierten Rechenzentren in Deutschland und Finnland (Quelle: Hetzner, 2025). OVHcloud stellt GPU-Instanzen stundenweise bereit, eine L40S mit 48 GB liegt bei rund 1,40 € pro Stunde (Quelle: OVHcloud Public Cloud GPU, 2026) — rechnerisch gut 1.000 € im Dauerbetrieb, aber günstig für zeitlich begrenzte Lasten.

Die drei realistischen Ausbaustufen im Überblick:

Szenario	Hardware / Cloud	Setup-Aufwand	Monatliche Kosten	Geeignet für
Klein	Vorhandene Workstation, 12–24 GB VRAM, Ollama	½–1 Tag	Strom und Wartung, keine Lizenzkosten	Tests, Prototypen, einzelne Fachbereiche
Mittel	Dedizierter GPU-Server, 96 GB VRAM (z. B. Hetzner GEX131)	2–5 Tage	ab 889 €	konstante interne Last, sensible Daten
Groß	Mehrere GPU-Server oder Cloud-GPUs mit Redundanz	mehrere Wochen	ab rund 2.000 € plus Betreuung	hohe Last, Ausfallsicherheit, SLA

Nicht in der Tabelle steht der größte Posten: die Zeit der eigenen Leute. Einrichtung, Absicherung, Monitoring und Aktualisierung binden Kapazität — dauerhaft, nicht einmalig.

Werkzeuge: Ollama, Open WebUI und vLLM

Drei Werkzeuge decken fast alle Fälle ab. Sie lösen unterschiedliche Probleme und ergänzen sich.

Werkzeug	Aufgabe	Stärke	Grenze
Ollama	Modelle lokal laden und ausführen	schnellster Einstieg, sehr einfache Bedienung	auf Durchsatz für viele Nutzende nicht ausgelegt
Open WebUI	Chat-Oberfläche mit Nutzerverwaltung	macht das Modell für Mitarbeitende nutzbar	ersetzt keine Governance
vLLM	Hochleistungs-Inferenzserver	hoher Durchsatz bei parallelen Anfragen	mehr Einrichtungs- und Betriebsaufwand

Der typische Weg: Ollama für den Machbarkeitsnachweis, Open WebUI als Arbeitsoberfläche, vLLM sobald mehrere Teams gleichzeitig zugreifen. Alle drei sprechen eine OpenAI-kompatible Schnittstelle. Ein Wechsel des Servers zwingt also nicht zum Umbau der Anwendungen — genau das reduziert Abhängigkeit.

Welche Modelle überhaupt infrage kommen, ordnet der Überblick zu Open Source LLMs ein.

Die Kostenrechnung: Self-Hosted gegen API

Jetzt die Zahlen. Ein GPU-Server kostet einen festen Betrag pro Monat, unabhängig von der Nutzung. Eine API kostet pro Token — wenig bei kleinem Volumen, viel bei großem. Irgendwo schneiden sich beide Linien.

Die Rechnung mit belegten Preisen: Ein dedizierter GPU-Server liegt bei 889 € im Monat (Quelle: Hetzner, 2025). Eine Frontier-API wie Claude Sonnet kostet regulär 3 $ je Million Eingabe- und 15 $ je Million Ausgabe-Tokens (Quelle: Anthropic, 2026) — bei einem Verhältnis von drei zu eins rund 6 $ je Million Tokens gemischt. Eine gehostete Open-Model-API liegt deutlich darunter: Qwen3 235B kostet bei Together AI 0,20 $ Eingabe und 0,60 $ Ausgabe je Million Tokens (Quelle: Together AI, 2026), gemischt rund 0,30 $.

Ein Hinweis zur Haltbarkeit solcher Rechnungen: Bis zum 31.08.2026 galt für Sonnet ein Einführungspreis von 2 $ und 10 $ — damit lag der Break-even noch bei rund 222 Millionen Tokens. Der Wechsel auf den Regulärpreis hat ihn um ein Drittel gesenkt. Wer eine solche Rechnung aufstellt, hinterlegt deshalb besser das Datum als die Zahl.

Für Präsentationen:SVGPNG

Das Ergebnis ist unbequem. Der Break-even gegenüber der Frontier-API liegt bei rund 148 Millionen Tokens pro Monat — etwa 4,9 Millionen Tokens am Tag oder grob 2.500 umfangreiche Anfragen täglich. Das erreichen wenige Mittelständler. Gegen eine gehostete Open-Model-API rechnet sich der eigene Server praktisch nie, weil die Anbieter ihre GPUs über viele Kunden auslasten.

Nicht eingerechnet sind Betriebsaufwand, Bereitschaft und Ausfallsicherheit. Wer diese Posten ehrlich ansetzt, verschiebt den Break-even weiter nach rechts. Wie sich Token-Kosten grundsätzlich senken lassen, zeigt der Beitrag zu token-smarter Architektur.

Die Konsequenz: Self-Hosting ist selten eine Kostenentscheidung. Es ist eine Kontrollentscheidung.

Wenn die Rechnung gar nicht entscheidet

Bis hierher liest sich der Beitrag wie ein Argument gegen den eigenen Server. Für einen erheblichen Teil der Unternehmen ist die Rechnung aber gar nicht die entscheidende Frage.

Das Statistische Bundesamt hat Unternehmen ohne AI-Einsatz nach ihren Gründen gefragt. 58 Prozent nennen unklare Rechtsfolgen, 53 Prozent Bedenken beim Datenschutz und der Privatsphäre (Quelle: Destatis, 2024). Hohe Kosten stehen mit 28 Prozent weit dahinter. Der Engpass ist nicht der Preis. Der Engpass ist Vertrauen.

Dahinter stehen drei sehr reale Lagen:

• Regulierung. Banken, Versicherer, Gesundheitswesen, Verteidigungszulieferer. Wo Aufsicht mitliest, ist der Datenweg Teil der Zulassung — nicht eine Frage der Bequemlichkeit.
• Wertvolle Entwicklungsdaten. Im Maschinenbau steckt der Unterschied zum Wettbewerb in Konstruktionsdaten, Messreihen und Fehlerhistorien. Diese Daten in eine intransparente Cloud zu geben, ist eine strategische Entscheidung, keine IT-Entscheidung.
• Eigentümerwille. In inhabergeführten Unternehmen entscheidet oft schlicht, dass die Daten das Haus nicht verlassen. Ob das Risiko objektiv oder empfunden ist, ändert nichts an der Wirkung.

Für diese Unternehmen lautet die Alternative nicht „eigenes LLM oder API”. Sie lautet eigenes LLM oder gar keine AI. Und dann ist ein Break-even bei 148 Millionen Tokens die falsche Kennzahl. Die richtige Frage ist, was es kostet, weiter nichts zu tun.

Wer die Cloud ausschließt, vergleicht nicht Server gegen API. Er vergleicht eigenen Betrieb gegen Stillstand.

Die Rechnung von oben behält trotzdem ihren Wert. Sie beziffert, was Kontrolle kostet. Das ist eine faire Grundlage für eine bewusste Entscheidung — und deutlich belastbarer als das Bauchgefühl, Self-Hosting sei „schon irgendwie teurer”.

Nicht alles oder nichts: Prozesse trennen

Die zweite Fehlannahme ist die Ganz-oder-gar-nicht-Logik. Kaum ein Unternehmen hat ausschließlich schützenswerte Daten.

Wer Konstruktionsdaten nicht herausgibt, kann trotzdem Stellenanzeigen, Marketingtexte, Übersetzungen oder Protokolle mit einem externen Modell bearbeiten. Diese Vorgänge enthalten keine Geschäftsgeheimnisse. Sie an einen eigenen Server zu binden, verschenkt Qualität und Geld — die großen Modelle sind hier schlicht besser und billiger.

Genau in diese Richtung bewegt sich der Markt. Deloitte hat im Dezember 2025 515 Verantwortliche in Unternehmen ab 500 Millionen Dollar Umsatz befragt. Das Ergebnis ist kein Entweder-oder, sondern ein Drei-Ebenen-Modell: Public Cloud für Training und Experimente, eigene Infrastruktur für planbare Inferenz in hohem Volumen, Edge für zeitkritische Entscheidungen (Quelle: Deloitte, 2026). Die binäre Frage Cloud gegen On-Premise gilt dort als überholt.

Praktisch heißt das: Die Daten werden nach Schutzbedarf sortiert, nicht die Technik nach Weltanschauung. Drei Klassen genügen meist.

Klasse	Beispiele	Sinnvoller Weg
Streng vertraulich	Konstruktionsdaten, Patientendaten, Verträge, Preiskalkulation	eigenes Modell im Haus oder in kontrollierter EU-Umgebung
Intern	Protokolle, Reports, interne Kommunikation	EU-gehostetes Modell mit AVV, keine Trainingsfreigabe
Unkritisch	Marketingtexte, Übersetzungen, Recherche, Stellenanzeigen	Frontier-API, dort wo Qualität und Preis am besten sind

Diese Sortierung ist Arbeit — und sie ist der eigentliche Hebel. Sie verlangt, dass jemand Datenklassen definiert, Workflows zuordnet und die Regel durchsetzt, wenn im Alltag jemand etwas in das falsche Fenster kopiert. Ohne diese Ebene entsteht genau das, was Verbote erzeugen: Schatten-AI.

Das ist keine einmalige Aufgabe, sondern laufender Betrieb. Wer mehrere Modelle parallel nutzt, braucht eine Schicht darüber, die entscheidet, welche Aufgabe an welches Modell geht, und die den Verbrauch sichtbar macht. Genau dafür bauen wir bei Kunden den Operations Layer — er macht die Sortierung von oben zu einer Regel im System statt zu einer Bitte an die Belegschaft.

Fazit: Erst die Datenfrage, dann die Rechnung

Die Reihenfolge entscheidet. Wer mit der Kostenrechnung beginnt, landet fast immer bei der API — und übersieht, dass für einen Teil der Unternehmen die Cloud gar nicht zur Wahl steht.

Drei Fragen, in dieser Reihenfolge:

1. Welche Daten dürfen das Haus nicht verlassen? Diese Frage kommt zuerst und wird nach Datenklassen beantwortet, nicht pauschal. Sie entscheidet, welcher Anteil der Arbeit überhaupt für eine externe API infrage kommt.
2. Gibt es Menschen für den Betrieb? Ohne benannte Verantwortung und Zeitbudget wird aus dem eigenen Server ein Projekt ohne Betreuung. Diese Frage hat schon mehr Vorhaben beendet als jede Kostenrechnung.
3. Ist die Last hoch und gleichmäßig? Erst jetzt lohnt die Rechnung von oben. Sie beziffert, was die Kontrolle kostet — und ob sich der eigene Server auch wirtschaftlich trägt.

Der pragmatische Weg beginnt klein: die Daten in drei Klassen sortieren, für die unkritische Klasse sofort ein starkes externes Modell nutzen, für die geschützte Klasse ein offenes Modell auf vorhandener Hardware testen. Nach drei Monaten gemessener Nutzung steht die Rechnung auf Daten statt auf Annahmen.

So gehört die Frage in einen dauerhaften AI-Betrieb — als Teil von AI Operations, nicht als einmalige Grundsatzentscheidung.

Häufige Fragen zum eigenen LLM

Was kostet es, ein eigenes LLM zu betreiben?

Für erste Tests auf vorhandener Hardware entstehen kaum Kosten außer Strom und Zeit. Ein dedizierter GPU-Server mit 96 GB Grafikspeicher beginnt bei 889 € pro Monat (Quelle: Hetzner, 2025). Dazu kommt der Betriebsaufwand im eigenen Team, der in fast jeder Rechnung fehlt.

Welche Hardware braucht ein LLM mindestens?

Für quantisierte Modelle mit 7 bis 8 Milliarden Parametern genügen 8 bis 12 GB VRAM. Für 70-Milliarden-Modelle in Quantisierung sind rund 48 GB nötig. Der Speicherbedarf ergibt sich näherungsweise aus Parameterzahl mal Bits pro Gewicht geteilt durch acht.

Ist Ollama für den produktiven Einsatz geeignet?

Für einzelne Nutzende und Prototypen ja. Bei vielen parallelen Anfragen stößt Ollama an Grenzen — dann ist vLLM die passende Wahl. Beide bieten eine OpenAI-kompatible Schnittstelle, der Wechsel ist deshalb überschaubar.

Ist Self-Hosting günstiger als eine API?

In den meisten Fällen nicht. Der Break-even gegenüber einer Frontier-API liegt bei rund 148 Millionen Tokens im Monat, gegenüber günstigen Open-Model-APIs meist gar nicht. Der Grund für Self-Hosting ist Datenkontrolle, nicht der Preis.

Wir dürfen unsere Daten nicht in die Cloud geben. Bleibt uns nur der eigene Server?

Für die schützenswerten Daten ja. Für den Rest nicht. Kaum ein Unternehmen arbeitet ausschließlich mit vertraulichen Inhalten — Marketingtexte, Übersetzungen oder Recherche lassen sich meist ohne Bedenken extern verarbeiten. Sinnvoll ist deshalb eine Sortierung nach Datenklassen statt einer pauschalen Entscheidung für eine Seite.

Warum nutzen so viele Unternehmen gar keine AI?

Nicht wegen der Kosten. 58 Prozent der Unternehmen ohne AI-Einsatz nennen unklare Rechtsfolgen, 53 Prozent Datenschutzbedenken — hohe Kosten stehen mit 28 Prozent weit dahinter (Quelle: Destatis, 2024). Für diese Unternehmen ist ein kontrollierter eigener Betrieb oft der einzige Weg, überhaupt zu starten.

Wie lässt sich die Entscheidung sauber vorbereiten?

Mit einer Messung statt einer Schätzung: tatsächliches Token-Volumen, Datenschutzanforderungen und verfügbare Betriebskapazität. Wir ordnen das im kostenlosen Diagnose-Call ein.

Quellen

• Destatis: Gründe gegen die Nutzung von Technologien der künstlichen Intelligenz, 2024
• Deloitte: Enterprise AI Infrastructure Survey — A 2028 Outlook, 2026
• Hetzner: GEX131 GPU-Server mit NVIDIA RTX PRO 6000 Blackwell Max-Q, 2025
• Hetzner: Dedicated GPU-Line, 2026
• OVHcloud: L40S Cloud GPU Instance, 2026
• Anthropic: Claude API Pricing, 2026
• Together AI: Pricing for Open Models, 2026
• Ollama: Dokumentation und Modellbibliothek, 2026
• Open WebUI: Projektdokumentation, 2026
• vLLM: Projektdokumentation, 2026