LLM Self-Hosting & On-Prem-Inferenz

Selbst-gehostete KI-Modelle sind 2026 für den Mittelstand technisch und wirtschaftlich erreichbar geworden. Was bleibt, ist die Architektur-Frage: welche Hardware, welches Modell, welcher Hoster — und ob der Betrieb intern oder extern getragen wird.

Wann sich Self-Hosting lohnt

Vier Treiber:

1. IP-Schutz. Source-Code, Konstruktionsdaten, klinische Daten oder Mandantenkommunikation dürfen das eigene Netzwerk nicht verlassen. Externe LLM-APIs können Anfragen — je nach Anbieter, Tarif und Region — außerhalb der EU verarbeiten.
2. Compliance. Branchenspezifische Regulierung — CRA, NIS2, ISO 27001, MDR, HIPAA — schränkt die Übermittlung sensibler Inhalte ein. Self-Hosting schafft eine prüfbare Datenfluss-Grenze.
3. Volumenökonomie. Ab bestimmten Token-Lasten wird der Eigenbetrieb wirtschaftlicher als API-Pricing. Die Schwelle hängt von Modell, Hardware-Klasse und Auslastung ab und ist Teil der Beratung.
4. Latenz. Workloads, die niedrige und vorhersagbare Antwortzeiten brauchen, profitieren von lokaler Inferenz ohne Netzlatenz.

Privacy by Construction

Alle Inferenz-Workloads laufen on-premises. Keine Cloud-GPU-Abhängigkeit. Authentifizierung über sicheren Schlüsselspeicher des Betriebssystems — keine Klartext-Keys im Repository, keine Vererbung an fremde Prozesse. Audit-Log auf Metadaten-Ebene; Prompt-Inhalte werden nicht persistiert.

Unsere Position: aus eigener Praxis

Creaminds betreibt eigene LLM-Infrastruktur für interne Workloads — Coding-Assistenz, Agents, die Infrastruktur dieser Website. Was wir intern täglich nutzen und erprobt haben, fließt direkt in die Beratung ein. Die Beratung geht über den eigenen Stack hinaus, sobald Kunden-Use-Cases andere Anforderungen mitbringen.

Was Creaminds liefert

• Workload-Analyse. Token-Volumen, Sensibilitäts-Klassifikation, Latenz-Anforderungen, Update-Frequenz.
• Modell-Auswahl. Empfehlung aus aktuellem Open-Weight-Spektrum (Mistral, Llama, GLM, Qwen u. a.), inklusive Fine-Tuning-Optionen für eigene Domäne.
• Hardware-Design. Auswahl der passenden Klasse — von Workstation- Hardware für Pilot-Projekte über Inferenz-NPUs für hohen Durchsatz bis Production-Server für volle Modellgrößen.
• Kapazitäts- und Beschaffungsplanung. Sizing gegen die reale Spitzenlast mit definierter Reserve, Phasen-Beschaffung und Lieferzeit-Strategie (siehe unten).
• Hoster-Empfehlung. Auswahl passender Infrastruktur-Anbieter aus EU-Bare-Metal, NPU-spezialisierten Anbietern oder Hyperscaler-EU- Regionen — je nach Risiko- und Kostenprofil.
• Migrations-Plan. Übergang vom bestehenden Cloud-LLM-Setup (Copilot, Claude, ChatGPT-Enterprise) inklusive Pilot-Phase und Parallel-Betrieb.

Wie wir dimensionieren und beschaffen

Zwei Fehler dominieren bei On-Prem-Inferenz-Projekten: zu knapp dimensionieren und in der falschen Reihenfolge beschaffen. Unser Vorgehen adressiert beide.

• Sizing gegen die Spitze, nicht den Durchschnitt. AI-Coding-Werkzeuge erzeugen Burst-Last — agentische Schleifen und Tab-Completions kommen in Wellen. Wir dimensionieren gegen die Spitzenlast und legen eine definierte Reserve ein, die kurzfristige Bursts und organisches Nutzer-Wachstum trägt, ohne kurzfristige Nachbeschaffung.
• Pilot parallel zur Produktion beschaffen. Produktions-Hardware hat Monate Lieferzeit. Wer sequenziell bestellt, verliert diese Zeit. Ein schnell beschaffbarer Pilot liefert sofort Validierung, während die Produktions-Hardware parallel heranreift — die lange Lieferzeit liegt nicht auf dem kritischen Pfad.
• Der Pilot bleibt im Betrieb. Nach dem Produktiv-Start wird die Pilot-Hardware nicht weggeworfen, sondern dauerhafte Dev-/Staging-Umgebung, Modell-Evaluations-Plattform und Cold-Standby für Wartungsfenster. Diese Re-Use-Planung ist Teil der Wirtschaftlichkeits-Rechnung von Anfang an.
• Interconnect als Auswahlkriterium. Große Modelle, die den Speicher einer GPU überschreiten, brauchen Tensor-Parallelität — und damit NVLink/NVSwitch statt einer PCIe-only-Topologie. Für die Produktions-Klasse ist das ein Auswahlkriterium, kein Nice-to-have.
• Single-Node-Trade-off offen kommuniziert. Ein Start mit einem Produktions-Knoten hält den CapEx minimal, bringt aber einen Single-Point-of-Failure mit sich. Wir benennen das und sichern es ab — über Cold-Standby, angekündigte Wartungsfenster und Vendor-SLA — statt es zu verschweigen.

Ein zentraler Wirtschaftlichkeits-Hebel der Plattform ist Prefix-Cache-Sharing: der gemeinsame Kontext einer Coding-Anfrage (System-Prompt, Codebase-Subgraph, Tool-Definitionen) wird einmal berechnet und über alle Entwickler-Sessions wiederverwendet — statt für jede Anfrage neu. Das ist auf modernen GPUs der größte einzelne Kostenhebel.

Operations-Modell

Zwei typische Konfigurationen, je nach Kunden-Setup:

• Dokumentierte Übergabe. Creaminds übergibt den lauffähigen Stack vollständig dokumentiert an Kunden-IT oder einen Operations-Partner. Wartung, Updates, SLA liegen beim Kunden.
• Managed Service. Creaminds übernimmt Betrieb, Updates, Monitoring nach Vereinbarung. Diese Variante setzt einen klar definierten Service-Level voraus und wird einzelfallabhängig kalkuliert.

Welches Modell für den Einzelfall passt, wird im Kundengespräch festgelegt.

Hardware-Landschaft 2026

Drei Klassen, drei Use-Cases:

Klasse	Beispiele	Geeignet für
Workstation	NVIDIA DGX Spark, Apple Silicon Mac Studio	Prototyp, Pilot, kleine Teams
Inferenz-NPU	Rebellions REBEL-Quad, FuriosaAI RNGD	hoher Token-Durchsatz, niedriges Power-Budget
Production-Server	NVIDIA H200/B200, AMD MI300X	volle Modellgrößen, hohe Parallelität

Modell-Landschaft 2026

Die Beratung deckt das Open-Weight-Spektrum ab — Generalisten, Coding-Spezialisten und domänenspezifische Modelle. Auswahl und gegebenenfalls Fine-Tuning erfolgen nach Workload-Anforderung.

Hosting-Geografien

Die Wahl des Hosting-Standorts wird im Kundengespräch entschieden. Maßgeblich sind Compliance-Bindung, Datenklassifikation und Workload-Größe. Creaminds berät zu EU-Bare-Metal-Anbietern, NPU-spezialisierten Cloud-Anbietern, Hyperscaler-EU-Regionen und Co-Location-Modellen.

Für wen

Mittelständler, die sensible Daten verarbeiten und AI-Assistenz produktiv einsetzen wollen, ohne Daten an externe Provider abzugeben. Typische Anlässe: Roll-out von AI-Coding-Tools im Entwicklerteam, Compliance-Anforderungen (DSGVO, branchenspezifische Geheimhaltung), unkalkulierbare Cloud-API-Kosten.

Vorgehensmodell

1. Workload-Analyse und Sensibilitäts-Mapping
2. Modell-Empfehlung und Hardware-Klasse
3. Kapazitäts-Sizing mit Reserve und Beschaffungs-/Lieferzeit-Strategie
4. Hoster-Auswahl mit Vertragsverhandlungs-Begleitung
5. Deployment-Plan und Migrationspfad
6. Übergabe an Kunden-IT, Operations-Partner oder als Managed Service

Kontakt

Beratungsgespräch anfragen