Hetzner-native LLM-Cluster: Sichere, performante und kosteneffiziente Self-Host-Infrastruktur

Warum ein Hetzner-native Ansatz für LLM-Cluster Sinn macht

Bei der Entscheidung für eine Infrastruktur für große Sprachmodelle (LLMs) stehen CTOs und Lead Engineers vor einem Spannungsfeld: Kostenkontrolle, Datensouveränität und Skalierbarkeit. Hetzner kombiniert genau diese drei Eigenschaften auf eine Weise, die für viele europäische Unternehmen attraktiv ist. Anders als bei reinen Public-Cloud-Angeboten behalten Sie die physische Kontrolle über Ihre Infrastruktur, profitieren von klaren Preisstrukturen und vermeiden unerwünschte Datenweitergaben an Dritte.

Wir sehen Hetzner besonders dort als starke Option, wo regulatorische Anforderungen, lange Datenaufbewahrungsfristen oder strikte Auditanforderungen gelten — typische Herausforderungen in der Automobil- und Fertigungsindustrie. Aus Projekten mit STIHL, Mercedes Benz und Eberspächer kennen wir die Praxisanforderungen: nachvollziehbare Logs, tenant‑spezifische Isolation und die Möglichkeit, Infrastruktur schnell kosteneffizient zu skalieren.

Architekturübersicht: Vom Benutzer-Request zum Modell

Ein robustes, Hetzner-native AI-Backend besteht aus mehreren, klar getrennten Bausteinen. Diese Kombination liefert die Balance zwischen Performance, Kosten und Auditierbarkeit, die wir für Produktionssysteme empfehlen:

• API-Gateway & Auth – Exponiert Endpunkte und sorgt für Authentifizierung, Ratenbegrenzung und Audit-Header.
• Multi-Model-Router – Entscheidet dynamisch, welches Modell (lokal oder extern) für eine Anfrage verwendet wird.
• Model-Serving-Cluster – GPU- oder CPU-basierte Server, die die Modelle hosten (vLLM, Hugging Face Inference Server, Triton o.Ä.).
• Queueing & Orchestration – Asynchrone Verarbeitung für lange Inferenzläufe (Redis Streams, RabbitMQ oder Kafka).
• State & Metadata – PostgreSQL für Tenant-Metadaten, Audit-Logs und Konfigurationen.
• Object Storage – MinIO als S3-kompatible Lösung für Fine‑Tuning‑Daten, Embeddings und Artefakte.
• Cache & Locks – Redis für schnelle Vector‑Lookups, Rate-Limits und verteilte Locks.
• Observability & Security – Prometheus, Grafana, zentralisierte Logs und SIEM-Integration.

Visuell lässt sich der Datenfluss in drei Ebenen skizzieren: Ingress/API → Routing/Queueing → Model-Serving + Storage. Diese strikte Trennung sorgt dafür, dass jedes Element einzeln skaliert, auditiert und gesichert werden kann.

Kernkomponenten im Detail: Postgres, MinIO, Redis, Queueing und Multi-Model-Router

PostgreSQL: Das auditable Rückgrat

Postgres dient nicht nur als Metadatenbank, sondern als zentrale Quelle für Konfigurationen, Audit-Trails und Tenant-Isolation. Unsere Empfehlung ist eine hochverfügbare Postgres-Installation (Primary/Replica) mit WAL-Archiving und regelmäßigen Backups zu MinIO. In regulierten Umgebungen genügt es nicht, Logs nur temporär zu halten — deswegen konfigurieren wir Write-Once Audit-Tables und rollenbasierte Zugriffe, um Nachvollziehbarkeit zu garantieren.

MinIO: S3-kompatibles Object Storage on-premise

MinIO ist bei Hetzner-Deployments unser Standard für Objektspeicher. Es ist performant, skaliert horizontal und ermöglicht die Nutzung bekannter S3-Toolchains. Wir speichern Modelle, Checkpoints, Fine-Tuning-Daten und Embeddings in MinIO und verwenden objektbasierte IAM-Policies, um tenant-spezifische Zugriffskontrolle sicherzustellen.

Redis & Queueing: Echtzeit und asynchrone Workloads

Redis übernehmen wir für Caching, Embedding-Index‑Lookups (z.B. Faiss-ähnliche Strukturen), Rate-Limits und verteilte Locks. Für asynchrone Inferenz-Pipelines empfehlen wir Redis Streams oder RabbitMQ als Queueing-Layer. Dieser Ansatz erlaubt uns, Batch-Inferenzen und Hintergrundverarbeitung zu entkoppeln, was die Durchsatzkontrolle vereinfacht und SLOs stabil hält.

Multi-Model-Router: Dynamisches Routing für Kosten und Performance

Der Multi-Model-Router ist das Herzstück für Flexibilität: Er bewertet Anfrageparameter (Kostenbudget, Latenzanforderung, Tenant‑Policy) und entscheidet, ob die Anfrage an ein großes lokales Modell, ein kleineres Edge-Modell oder eine externe SaaS-API weitergeleitet wird. So kombinieren wir das Beste aus beiden Welten: niedrige Kosten für Standardanfragen und höchste Qualität bei Bedarf.

Deployment: Wie wir Coolify bei Reruption nutzen

Für schnelle, reproduzierbare Deployments setzen wir bei Reruption auf Coolify. Coolify ermöglicht uns, Infrastrukturkomponenten als Templates zu definieren, Secrets sicher zu managen und CI/CD‑Pipelines für Modelle und Services aufzusetzen. Auf Hetzner lassen sich so in Tagen, nicht Wochen, komplette Stacks inkl. Networking, LB, Firewalls und Monitoring provisionieren.

Unsere typische Deployment-Strategie:

• Infrastructure-as-Code für Netzwerke und Firewalls.
• Coolify-Apps für API-Gateway, Router, Model-Server und Scheduler.
• Helm-Charts oder Docker-Compose für konsistente Umgebungspakete.
• Automatische Rollbacks und Canary-Deployments für Model-Rollouts.

Coolify beschleunigt nicht nur die Bereitstellung, sondern reduziert auch die Komplexität des Betriebs — eine Voraussetzung, wenn man die Verantwortung wie ein Co‑Founder (Co‑Preneur) übernimmt.

Beispiel-Stack: LLMs + APIs + Automation Nodes

Ein konkretes Beispiel für einen Produktions-Stack auf Hetzner sieht bei uns so aus:

• Frontend/API-Gateway: Nginx/Traefik + OAuth2 / mTLS
• Auth & Tenant-Service: Postgres, Keycloak
• Router-Service: Konfigurierbarer Multi-Model-Router (k8s Deployment)
• Model-Serving: Kombi aus GPU-Metal-Servern (vLLM/Triton) und CPU‑Skalierern (Llama.cpp)
• Storage: MinIO (erweiterbar), Backup -> Offsite-Archive
• Cache & Queue: Redis (Cluster) + Redis Streams für Workflows
• Automation Nodes: Kubernetes CronJobs oder Airflow für Fine-Tuning, Indexing, Retraining
• Observability: Prometheus, Grafana, Loki, SIEM-Integration

Workflow-Beispiel: Eine Nutzeranfrage erreicht das API-Gateway → Auth-Check → Router bewertet Budget & Latency → Anfrage in Redis Stream (falls asynchron) → Model-Server verarbeitet → Ergebnis + Audit-Log in Postgres ablegen → Artefakte in MinIO speichern. Jeder Schritt ist versioniert und auditierbar.

Kostenvergleich: SaaS vs. Self-Host (realistische Einschätzung)

Ein fairer Kostenvergleich muss Total Cost of Ownership (TCO) und Hidden Costs berücksichtigen: Direkte API-Gebühren, Datenexfiltrationsrisiko, Compliance-Aufwand, Personalkosten für Betrieb und Engineering.

Kurzmodell (monatlich, grobe Bandbreite für mittleren Produktionsbetrieb):

• SaaS-LLM (bei hoher Nutzung): 5.000–40.000 € (abhängig von Token‑Volumen und Anforderungen an Latenz/Qualität).
• Self-Host Hetzner (inkl. GPU-Server, Storage, Netzwerk, Monitoring): Einmalig PoC & Setup ~9.900 € (unser AI PoC-Angebot) + laufend 6.000–20.000 €/Monat für moderate Produktionslast. Bei Hochskalierung können GPU-Kosten entsprechend steigen.

Wichtig: Self-Host amortisiert sich je nach Nutzung schnell, wenn Sie konstante Lasten haben oder strikte Datenschutzanforderungen. SaaS ist attraktiv bei sehr unregelmäßiger Nutzung oder wenn Sie Time‑to‑Market über alles stellen. Unserer Erfahrung nach liegt der Break-even häufig im Bereich von wenigen Monaten bis einem Jahr, je nach Verbrauchsprofil.

Sicherheit, Compliance und Tenant-Isolation

In regulierten Branchen sind drei Aspekte entscheidend: Datensouveränität, Auditierbarkeit und Zugriffssteuerung. Auf Hetzner können wir physische Netztrennung, VPC‑Layer, dedizierte GPU‑Nodes und WORM-fähige Backups (Write Once Read Many) konfigurieren — alles Bausteine, um Compliance‑Anforderungen zu erfüllen.

Tenant-Isolation implementieren wir durch Namespaces in Kubernetes, getrennte MinIO-Buckets mit eigenen IAM-Policies, und Postgres-Schemas pro Tenant. Zusätzlich setzen wir mandatory logging hooks in der Router‑Pipeline, sodass jede Anfrage mit korrektem Audit-Kontext versehen wird. Security-Reviews und Pen‑Tests sind Teil jeder Produktionsfreigabe.

Lessons Learned aus regulierten Projekten

Aus unserer Arbeit mit STIHL, Mercedes Benz und Eberspächer haben sich einige wiederkehrende Erkenntnisse ergeben:

• Beginnen Sie mit klaren Datenklassen: Nicht alle Daten dürfen gleich verarbeitet werden. Klassifikation zu früh spart später viel Aufwand.
• Auditierbarkeit ist kein Add-on: Implementieren Sie Logging und Versionierung von Anfang an.
• Hybridbetrieb funktioniert am besten: Lokale Modelle für vertrauliche Daten, SaaS für seltene Spezialfälle.
• Operationalisierung kostet Zeit: Planen Sie 20–30% der Projektzeit für Observability, Security und Runbook-Erstellung ein.

Diese Lessons spiegeln unsere Co‑Preneur‑Philosophie: Wir übernehmen nicht nur Design, wir bauen und betreiben mit — bis der Stack zuverlässig in der P&L des Kunden läuft.

Roadmap: Von PoC zum stabilen Produktivbetrieb

Ein realistischer Implementierungsfahrplan in vier Phasen:

1. PoC (2–4 Wochen): Validierung eines Use-Cases, kleines Modell auf einer dedizierten Hetzner-VM, erste Integration mit Postgres/MinIO. (Unser AI PoC: 9.900 €.)
2. MVP (4–8 Wochen): Multi-Model-Router, Queueing, Basic Observability, Tenant-Isolation für Pilotkunden.
3. Produktion (8–12 Wochen): HA-Setups, Backup/DR, Skalierung, Security-Audit, SLA-Definitionen.
4. Optimierung & Automatisierung (laufend): Kostenoptimierung, Auto-Scaling-Regeln, Fine-Tuning-Pipelines und Retraining-Automation.

Wir empfehlen, frühzeitig Runbooks und Incident-Prozesse zu definieren. In regulierten Umgebungen sollten außerdem regelmäßige Compliance-Checks und Penetrationstests eingeplant werden.

Praxisbeispiele und Handlungsempfehlungen

Konkrete Empfehlungen, die Sie sofort umsetzen können:

• Starten Sie mit einem konkreten Use‑Case (z. B. Recruiting‑Chatbot, Dokumentensuche) und messen Sie Token‑/Query-Volumen vor dem Architekturentwurf.
• Nutzen Sie MinIO von Anfang an für Modellartefakte, um spätere Migrationen zu vermeiden.
• Implementieren Sie Multi-Model-Routing, damit Sie flexibel zwischen lokalen Modellen und externen APIs wechseln können.
• Planen Sie Observability mit Metriken, Traces und Logs — sonst bleibt Ihnen im Incident-Fall die einzig verfügbare Option: Ratenbasiertes Raten.

Fazit & Call to Action

Hetzner-native LLM-Cluster bieten eine leistungsfähige Mischung aus Kostenkontrolle, Datensouveränität und Skalierbarkeit. Mit einer klaren Architektur aus Postgres, MinIO, Redis, Queueing und einem Multi-Model-Router erreichen Unternehmen die nötige Balance zwischen Performance und Compliance. Coolify hilft uns, solche Stacks schnell und reproduzierbar auszurollen — ein entscheidender Vorteil für Unternehmen, die nicht nur proof-of-concept, sondern ein echtes Produkt in Produktion bringen wollen.

Wenn Sie überlegen, ob Self-Host auf Hetzner für Ihre LLM-Strategie passt, unterstützen wir Sie gern: Von einem fokussierten PoC (9.900 €) bis zur vollständigen Implementierung und Betrieb. Kontaktieren Sie uns, damit wir gemeinsam die richtige Architektur für Ihre Anforderungen entwerfen und in Ihrer Organisation verankern.