
Docker Compose auf dem VPS: Webserver, Datenbank & Reverse Proxy richtig betreiben
Praxisnaher Guide für Docker Compose auf dem VPS: Webserver, Datenbank, Reverse Proxy, TLS, Backups, Updates und Sicherheit richtig planen und betreiben.
Die KI-Infrastrukturlandschaft hat sich in den letzten 18 Monaten dramatisch verändert. Wo 2024 noch dedizierte H100-Cluster als Nonplusultra galten, bieten RTX-5090-Karten und günstigere Cloud-Tarife heute völlig neue Rechengrundlagen. Gleichzeitig sind Open-Source-Modelle wie Llama 4, Mistral Large 3 und DeepSeek V4 fast auf dem Niveau proprietärer Modelle – aber zu einem Bruchteil der API-Kosten.
Hinzu kommen regulatorische Veränderungen: Der EU AI Act ist 2026 vollständig anwendbar, und viele Unternehmen müssen nachweisen, wo ihre Daten verarbeitet werden. Eine eigene GPU kann hier Compliance-Vorteile bieten, erfordert aber Investitionen in Auditing, Monitoring und physische Sicherheit.
Die zentrale Frage ist nicht mehr "Cloud oder On-Premise?", sondern "Welches Modell für welchen Workload?". Hybride Architekturen, die API und eigene GPU kombinieren, gewinnen 2026 massiv an Bedeutung.
Laut einer aktuellen Erhebung von Gartner setzen 62 % der mittelständischen Unternehmen in Deutschland mittlerweile auf Multi-Provider-Strategien – ein Trend, der durch die Flexibilität von Aggregatoren wie OpenRouter befeuert wird.
OpenRouter fungiert als API-Aggregator und bündelt über 200 Modelle verschiedener Anbieter unter einer einheitlichen Schnittstelle. Die Abrechnung erfolgt pay-per-use, basierend auf Input- und Output-Token. Ein zentraler Vorteil: Failover-Mechanismen leiten Anfragen automatisch auf alternative Modelle um, falls ein Anbieter ausfällt.
Das Preismodell ist transparent: OpenRouter addiert eine kleine Marge (typisch 5 %) auf die Provider-Kosten. Für 2026 zeigen sich folgende typische Preisspannen:
| Modell-Klasse | Input $/1M Tokens | Output $/1M Tokens | Beispiel-Modelle |
|---|---|---|---|
| Klein (≤8B) | 0,05 – 0,20 | 0,10 – 0,40 | Llama 4 8B, Mistral 7B |
| Mittel (8B–70B) | 0,30 – 0,90 | 0,60 – 1,80 | Mixtral 8x22B, Llama 4 70B |
| Groß (70B–405B) | 1,20 – 3,50 | 2,40 – 7,00 | DeepSeek V4, Llama 4 405B |
| Frontier-Modelle | 3,00 – 8,00 | 12,00 – 30,00 | GPT-5, Claude 4 Opus |
Ein typischer API-Aufruf via OpenRouter sieht in Python so aus:
from openai import OpenAI
client = OpenAI(
base_url="https://openrouter.ai/api/v1",
api_key="sk-or-v1-..."
)
response = client.chat.completions.create(
model="meta-llama/llama-4-70b-instruct",
messages=[
{"role": "user", "content": "Erkläre mir Quantencomputing in 3 Sätzen."}
],
extra_headers={
"HTTP-Referer": "https://hostazar.com",
"X-Title": "HostAzar Demo"
}
)
print(response.choices[0].message.content)
print(f"Tokens: {response.usage.total_tokens}")
Die Vorteile liegen auf der Hand: keine Vorabinvestition, sofortige Skalierbarkeit, Zugang zu neuesten Modellen ohne Hardware-Upgrades und einfache Integration in bestehende Anwendungen. Die Nachteile: laufende Kosten, Abhängigkeit von Provider-Verfügbarkeit und potenzielle Datenschutzbedenken bei sensiblen Inhalten.
Der Betrieb einer eigenen GPU-Infrastruktur bedeutet weit mehr als nur den Kauf einer Grafikkarte. Die Total Cost of Ownership (TCO) umfasst Hardware, Strom, Kühlung, Colocation oder Hosting, Netzwerk, Wartung und Personal. Für 2026 haben sich die Anschaffungspreise durch neue Generationen teilweise stabilisiert, sind aber für Top-Modelle weiterhin hoch.
Eine typische On-Premise-Konfiguration für mittelgroße LLM-Inferenz:
| GPU-Modell | VRAM | Anschaffung 2026 | Strom (kW) | Geeignet für |
|---|---|---|---|---|
| RTX 5090 | 32 GB | 2.800 € | 0,575 | Modelle bis 32B quantisiert |
| RTX 6000 Ada | 48 GB | 7.500 € | 0,300 | Modelle bis 70B quantisiert |
| H100 SXM | 80 GB | 28.000 € | 0,700 | 70B+ FP8, Multi-GPU |
| H200 | 141 GB | 35.000 € | 0,700 | 405B quantisiert, Frontier |
| B200 Blackwell | 192 GB | 42.000 € | 1,000 | Frontier-Training + Inferenz |
Die jährlichen Betriebskosten pro GPU bei 24/7-Dauerlast in einem deutschen Rechenzentrum mit 0,32 €/kWh:
Für ein produktives Setup mit 2x H100 in einem deutschen Colocation-Rechenzentrum ergibt sich so eine TCO von rund 95.000 – 110.000 € im ersten Jahr und 75.000 – 90.000 € in Folgejahren.
Um API-Kosten mit GPU-Betrieb fair zu vergleichen, müssen wir Token-Durchsatz pro GPU und Stunde berechnen. Ein H100 mit 80 GB VRAM kann bei einem 70B-Modell in FP8 ungefähr 3.500 Output-Tokens/s oder etwa 12,6 Millionen Tokens pro Stunde liefern. Unter Berücksichtigung von Real-World-Auslastung (60 %) sinkt dieser Wert auf rund 7,5 Mio. Tokens/h.
| Szenario | GPU-Kosten / 1M Tokens | OpenRouter (Groß) / 1M Tokens | OpenRouter (Mittel) / 1M Tokens |
|---|---|---|---|
| 1x H100, 24/7, 60 % Auslastung | 0,52 – 0,78 € | 2,40 – 7,00 € | 0,60 – 1,80 € |
| 2x H100, 24/7, 70 % Auslastung | 0,42 – 0,62 € | 2,40 – 7,00 € | 0,60 – 1,80 € |
| 1x RTX 5090, 24/7, 50 % Auslastung | 0,18 – 0,28 € | nicht möglich (zu klein) | 0,60 – 1,80 € |
| Burst (Spot-API) | nicht möglich | 1,80 – 5,50 € | 0,45 – 1,40 € |
Die Rechnung zeigt: Bei hoher Auslastung und großen Modellen ist eine eigene GPU wirtschaftlich klar überlegen. Bei kleinen Modellen oder geringem Volumen bleibt die API günstiger und flexibler.
Wichtig ist die Betrachtung des Mixed-Use-Cases: Viele Anwendungen benötigen sowohl kleine Modelle für Klassifikation als auch große Modelle für komplexe Reasoning-Aufgaben. Hier kann eine Kombination beider Welten die optimale Lösung sein.
Die zentrale Frage für jeden CTO lautet: Bei welchem monatlichen Token-Volumen wechselt die wirtschaftlichste Option von API zu eigener GPU? Wir berechnen den Break-Even-Punkt für ein 70B-Modell auf einer 2x H100-Installation.
Annahmen:
Berechnung:
break_even_tokens = 85_000 / 1.20 # = 70.833 Mio. Tokens / Jahr
break_even_per_month = 70_833 / 12 # = 5.903 Mio. Tokens / Monat
print(f"Break-Even: {break_even_per_month:.0f} Mio. Tokens / Monat")
# Output: Break-Even: 5.903 Mio. Tokens / Monat
Das bedeutet: Erst ab etwa 5,9 Milliarden Tokens pro Monat ist eine eigene 2x H100-Installation günstiger als die OpenRouter-API für ein 70B-Modell. Bei einem mittelgroßen SaaS-Unternehmen mit 100.000 aktiven Nutzern, die täglich 2.000 Tokens generieren, liegt das Volumen bei rund 6 Mrd. Tokens/Monat – also genau im Break-Even-Bereich.
Für kleinere Modelle (z. B. Llama 4 8B) verschiebt sich der Break-Even deutlich nach oben, da die API-Token hier günstiger sind und die GPU schlechter ausgelastet wird. Bei Frontier-Modellen wie GPT-5 oder Claude 4 Opus verschiebt er sich stark nach unten, da hier die API extrem teuer ist.
Ein oft unterschätzter Faktor ist die Lastverteilung über die Zeit. Die meisten Anwendungen haben kein konstantes Traffic-Profil: Tagsüber Peaks, nachts wenig Last. Eine eigene GPU skaliert nicht elastisch – sie kostet immer gleich viel, unabhängig von der Auslastung.
Die OpenRouter-API skaliert hingegen in Sekunden von 0 auf Millionen Requests pro Minute. Für Anwendungen mit unvorhersehbaren Lastspitzen – etwa Chat-Bots nach Produktlaunches, virale Marketing-Kampagnen oder saisonale E-Commerce-Anfragen – ist die API oft die einzige wirtschaftlich tragbare Lösung.
Eine bewährte Architektur kombiniert beide Welten:
Diese Hybrid-Strategie minimiert TCO und maximiert gleichzeitig die Verfügbarkeit. Sie erfordert allerdings eine intelligente Routing-Logik im Anwendungscode.
Sowohl API als auch GPU haben versteckte Kosten, die in oberflächlichen Kostenvergleichen oft fehlen. Wer diese ignoriert, erlebt böse Überraschungen im ersten Betriebsjahr.
Versteckte Kosten der OpenRouter-API:

Praxisnaher Guide für Docker Compose auf dem VPS: Webserver, Datenbank, Reverse Proxy, TLS, Backups, Updates und Sicherheit richtig planen und betreiben.