LLMs in der EU selbst hosten: Wann sich Open Weights wirklich rechnen

Auf dem Papier sieht Self-Hosting eines Open-Weight-LLM nach einem leichten Gewinn aus. Miete eine GPU für ein paar Dollar pro Stunde, lass ein kostenloses Modell laufen, hör auf, pro Token zu zahlen. Die Rechnung wird flach, und der Stack gehört dir. Das ist der Pitch, und er stimmt zur Hälfte. Was er auslässt, entscheidet darüber, ob du sparst oder still draufzahlst: Die GPU ist der günstige Teil. Teuer ist der Engineer, der den Inference-Server am Leben hält, der Eval-Harness, der beweist, dass ein quantisiertes Modell noch korrekt antwortet, und die Upgrade-Kadenz, die nicht endet, wenn zwei Monate später ein besseres Open-Modell erscheint.

Das ist eine Engineering- und Prozess-Perspektive, kein Vendor-Pitch. Die Zahlen unten sind Richtwerte aus öffentlichen 2026er-Trends, und du solltest sie vor einem Commit gegen aktuelle Angebote prüfen, denn GPU-Preise und Token-Preise bewegen sich beide Monat für Monat. Wir setzen interne KI auf Kunden-Infrastruktur im Rahmen unserer AI-Enablement-Arbeit auf, die Trade-offs hier sind also die, die wir mit Kunden tatsächlich abwägen, kein theoretisches Modell. Dieser Beitrag vertieft unser Token-Kosten-Playbook, das Self-Hosting nur streift, an genau der Frage, die alles entscheidet: Wann schlägt Inference im eigenen Haus eine Hosted API?

Was kostet Self-Hosting eines LLM wirklich, jenseits der GPU?

Die GPU-Position ist die, die alle zitieren, und sie ist heute wirklich günstig. Eine NVIDIA H100 mietest du für rund $2 bis $4 pro Stunde auf spezialisierten EU-Clouds, Hyperscaler liegen zwei- bis dreimal höher, EU-souveräne Anbieter um die $2-Marke (Richtwert, vor dem Commit prüfen). Lass eine reservierte H100 rund um die Uhr laufen, und du landest bei etwa $1.500 bis $3.000 pro Monat allein für die Hardware.

Diese Zahl ist real, und sie ist zugleich der kleinste Teil der Gesamtkosten. Was die Rechnung entscheidet, überspringt das Spreadsheet:

• Entwicklerzeit. Jemand muss den Inference-Server aufsetzen, Batch-Größen tunen, GPU-Treiber und CUDA-Versionen verwalten, Modell-Loading und Rollback handhaben und das Ganze am Laufen halten. Das ist kein einmaliges Setup. Es ist laufender Betrieb, und in der EU kostet ein kompetenter ML-Ops-Engineer pro Monat weit mehr als die GPU.
• Redundanz. Eine GPU ist ein Single Point of Failure. Produktion heißt meist mindestens zwei plus Failover-Plan, was die Hardware-Position grob verdoppelt und Load-Balancing-Arbeit hinzufügt.
• Eval und Qualitätssicherung. Ein self-hosted Modell ist deine Verantwortung, wenn es regrediert. Du brauchst einen Eval-Harness, der beweist, dass das Modell nach jeder Quantisierungs-Entscheidung und jedem Versions-Sprung die Qualität hält. Ohne ihn fliegst du blind.
• Upgrade-Kadenz. Open Weights bewegen sich schnell. Ein heute konkurrenzfähiges Modell ist in einem Quartal Mittelklasse. Aktuell zu bleiben ist wiederkehrende Engineering-Arbeit, keine Einmal-Installation.

Rechne es zusammen, und die ehrliche Einordnung ist dieselbe wie in unserer Token-Kosten-Arbeit: Der Break-even wird durch Entwicklerzeit bestimmt, nicht durch GPU-Rack-Preise. Das Modell ist günstig im Betrieb. Die Disziplin drumherum nicht.

Wo liegt der Break-even gegenüber einer Hosted API?

Es gibt keine einzelne Break-even-Zahl, denn sie hängt komplett davon ab, welche API du ersetzt. Die Spanne ist groß genug, dass das Falschliegen hier der häufigste Self-Hosting-Fehler ist.

• Gegen eine teure Frontier-API (Top-Tier von Claude, GPT oder Gemini) kann Self-Hosting auf einer reservierten GPU schon bei ein paar Millionen Tokens pro Tag Break-even erreichen, manchmal mit rund 2 bis 5 Millionen beziffert. Frontier-Output-Tokens sind teuer, also liegt die Latte niedrig.
• Gegen einen günstigen Open-Weight-API-Anbieter (Together, Fireworks, DeepInfra und Ähnliche) springt der Break-even drastisch hoch, häufig mit rund 50 Millionen Tokens pro Tag oder mehr genannt. Diese Anbieter fahren bereits optimierte Infrastruktur im großen Maßstab mit dünnen Margen, du konkurrierst also mit ihrer Skaleneffizienz, nicht mit ihrem Listenpreis.

Die praktische Lesart für die meisten Teams: Wenn deine Alternative ein günstiger Hosted-Open-Weight-Endpoint ist, bleibt Hosted günstiger, bis du ernsthaftes, stetiges Volumen fährst. Stoßweiser Traffic macht Self-Hosting schlechter, denn du zahlst die GPU, egal ob sie ausgelastet oder leer läuft, während eine API nur das berechnet, was du nutzt. Der Break-even setzt eine GPU voraus, die du sinnvoll ausgelastet halten kannst. Behandle die Zahlen oben als Richtwerte und setze dein eigenes Token-Volumen, deinen GPU-Preis und deine Entwicklerkosten ein, bevor du entscheidest. Das breitere Bild der Kostenkurve behandeln wir in was günstige Tokens an deiner KI-Architektur ändern.

"Die meisten Teams hosten zu früh selbst. Sie bepreisen die GPU, nicht den Engineer, der sie am Leben halten muss, und ein paar Monate später wäre die Hosted API günstiger und weniger Arbeit gewesen."

Wann erzwingt Datenresidenz Self-Hosting, egal zu welchen Kosten?

Kosten sind nur eine Achse. Die andere ist Governance, und für manche EU-Workloads überschreibt sie die Rechnung komplett. Wenn du personenbezogene oder regulierte Daten verarbeitest und sie nicht an einen Nicht-EU-Endpoint senden darfst, ist der Kostenvergleich gegenstandslos. Die Frage ist nicht mehr "ist Self-Hosting günstiger", sondern "was ist die günstigste konforme Option".

Unter der DSGVO zählt, wo die Inferenz läuft und wo die Daten landen, nicht nur, wo die Daten ruhend gespeichert sind. Ein unterzeichneter Auftragsverarbeitungsvertrag, EU-Datenresidenz, Zweckbindung und eine dokumentierte Architektur, die genau zeigt, wo personenbezogene Daten verarbeitet werden, sind die Bausteine eines konformen Setups. Open Weights auf deiner eigenen EU-Infrastruktur selbst zu hosten gibt dir die geringste externe Subprozessor-Exposition, weil zur Inferenzzeit kein Dritter die Daten berührt. Es trägt zugleich die höchste operative Last, da Serving, Logging, Zugriffskontrolle und Rollback alle deine Verantwortung werden. Tiefer in die Residenz-Optionen gehen wir in EU-Datenresidenz für KI-Apps.

Darüber liegt eine regulatorische Schicht. Der EU AI Act wird schrittweise wirksam, und der Zeitplan ist vorläufig und weiter in Bewegung, behandle also jedes konkrete Datum als änderbar. Stand Mitte 2026 sind die Pflichten für General-Purpose-KI-Modelle bereits in Anwendung, breitere Hochrisiko-Pflichten wurden im Rahmen einer politischen Einigung vom Mai 2026 nach hinten geschoben, und die Durchsetzungsbefugnisse sollen über 2026 hinaus hochlaufen. Die praktische Erkenntnis für ein EU-Team ist kein Datum. Es ist, dass die Kontrolle darüber, wo dein Modell läuft, zu einem Governance-Asset wird, nicht nur zu einer Kostenposition, und Self-Hosting ist ein Weg, diese Kontrolle in der eigenen Hand zu behalten. Prüfe die aktuellen Pflichten gegen die offiziellen Quellen, bevor du eine Compliance-Aussage darauf aufbaust.

Wie sieht der Produktions-Stack aus, wenn du selbst hostest?

Wenn Volumen oder Compliance es für dich entschieden haben, ist der 2026er-Produktions-Stack gut etabliert, und er ist nicht dasselbe, womit du auf dem Laptop prototypisiert hast. Ein lokaler Single-Stream-Runner ist gut für Experimente und falsch für Produktion, weil er die GPU größtenteils leer laufen lässt.

• Inference-Engine: vLLM. vLLMs Continuous Batching und PagedAttention lassen eine einzelne GPU viele gleichzeitige Requests bei weit höherem Gesamt-Durchsatz bedienen als ein naives Single-Stream-Setup. Öffentliche 2026er-Benchmarks setzen es bei rund dem Acht- bis Neunfachen der Gesamt-Tokens eines simplen Runners auf derselben H100 bei derselben Quantisierung an. Durchsatz, nicht Einzel-Request-Tempo, macht die GPU-Ökonomie tragfähig, denn er hält die Karte ausgelastet. SGLang und TensorRT-LLM sind glaubwürdige Alternativen derselben Klasse.
• Quantisierte Open Weights. Du fährst fast immer ein quantisiertes Modell, nicht volle Präzision, um ein nützliches Modell auf eine GPU zu bekommen und mehr Parallelität zu bedienen. Auf H100-Klasse-Hardware hält FP8 nahe an der Voll-Präzisions-Qualität bei rund halbem Speicher. Wo du kleiner werden musst, ist AWQ 4-Bit meist das stärkste der 4-Bit-Formate bei echten Aufgaben (öffentliche Vergleiche setzen es bei Qualitätserhalt im hohen 90er-Bereich an), GPTQ knapp dahinter. Der Haken: 4-Bit-Quantisierung kann bei hartem Reasoning und Mathematik spürbar abfallen, während sie bei Summarization, Klassifikation und Extraktion in Ordnung bleibt. Genau deshalb ist der Eval unten nicht optional.
• Das Modell selbst. Llama, Qwen, DeepSeek und Mistral-Klasse-Open-Weights sind die üblichen Kandidaten. Die Auswahl ist eine eigene Entscheidung, und wir arbeiten sie in unserem Open-Weight-Modellvergleich durch.

Woher weißt du, dass der günstigere Pfad die Qualität gehalten hat?

Das ist der Teil, den Teams überspringen und dann bereuen. Jede Wahl in einem self-hosted Stack, das Modell, die Quantisierung, die Batch-Settings, kann still die Qualität senken, und ein günstigerer Pfad, der leise schlechter antwortet, ist das teuerste Ergebnis von allen. Die einzige ehrliche Verteidigung ist ein Eval-Harness, der deine tatsächlichen Aufgaben bewertet, nicht einen öffentlichen Benchmark.

Hier sind wir bewusst bescheiden. Gute Evals zu bauen und zu pflegen ist schwerer, als den Inference-Server aufzusetzen, und der größte Teil der laufenden Engineering-Kosten von Self-Hosting steckt hier, nicht in der GPU. Du brauchst ein repräsentatives Aufgabenset, eine Bewertungsmethode, der du traust, und ein Gate, das vor jeder Modell- oder Quantisierungs-Änderung läuft. Ohne es kannst du nicht sagen, ob dein FP8-Wechsel dich zwei Genauigkeitspunkte auf den Fällen gekostet hat, die zählen. Es ist dieselbe Disziplin, die wir in produktiver KI-Arbeit wie Twinsoft AI anwenden: Die Modellwahl ist nur auf einem Eval sicher, der beweist, dass sie die Latte gehalten hat.

Solltest du also selbst hosten? Eine Entscheidungs-Checkliste.

Geh diese Fragen der Reihe nach durch. Lautet die ehrliche Antwort auf die ersten beiden nein, nimm standardmäßig eine Hosted API und greif die Frage später wieder auf.

1. Erzwingt Datenresidenz deine Hand? Wenn du die Daten rechtlich nicht an einen Nicht-EU-Endpoint senden darfst und keine konforme EU-gehostete API passt, kann Self-Hosting die günstigste konforme Option sein, unabhängig von der Token-Rechnung. Das allein kann es entscheiden.
2. Ist dein Volumen hoch und stetig? Gegen eine günstige Open-Weight-API musst du meist zweistellige Millionen Tokens pro Tag auf einer ausgelasteten GPU fahren, bevor Self-Hosting gewinnt. Stoßweises oder niedriges Volumen spricht für die API.
3. Hast du die Ops-Kapazität? Self-Hosting ist wiederkehrende Engineering-Arbeit: Treiber, Redundanz, Upgrades, Monitoring. Kann dein Team das nicht übernehmen, ohne Produktarbeit liegen zu lassen, verdampfen die GPU-Einsparungen.
4. Kannst du Qualität mit Evals beweisen? Wenn du nicht messen kannst, ob ein quantisiertes Open-Modell deine Qualitätslatte hält, bist du nicht bereit, dich in Produktion darauf zu verlassen.
5. Hast du das Gesamtbild bepreist? GPU plus Redundanz plus Entwicklerzeit plus Eval-Pflege, gegen die All-in-API-Kosten. Vergleiche Summen, nicht die GPU-Position gegen die Token-Position.

Für die meisten frühen und mittleren Produkte lautet die Antwort weiterhin: bleib bei einer Hosted API, und wähle eine EU-residente, wenn Residenz zählt. Self-hosten, wenn Volumen oder Compliance die Frage erzwingen, nicht vorher. Wenn du Hilfe willst, diesen Vergleich auf deinen eigenen Zahlen und deiner Infrastruktur zu fahren, ist genau das der Sinn unserer AI-Enablement-Arbeit.