--- title: "LLMs in der EU selbst hosten: Wann es sich rechnet" canonical: https://wavect.io/de/blog/self-hosting-llms-eu-cost/ language: de description: "Open-Weight-LLMs in der EU selbst hosten: die echten Kosten jenseits der GPU, der Token-Break-even gegen Hosted APIs und der vLLM-Produktions-Stack." image: "https://wavect.io/img/blog/headers/header_self-hosting-llms-eu-cost.png" --- [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 9 Min Lesezeit · 26. Juni 2026 [**Weiter**](/de/blog/open-weight-llm-comparison-2026/) # LLMs in der EU selbst hosten: Wann sich Open Weights wirklich rechnen TL;DR Open-Weight-LLMs selbst zu hosten wirkt günstig, weil man die GPU bepreist, nicht den Engineer, der sie am Leben hält. Eine H100 mietest du für rund $2-4/h auf EU-Clouds (Richtwert, prüfen), aber entscheidend sind Ops, Redundanz und ein Eval-Harness, der beweist, dass ein quantisiertes Modell die Qualität hält. Gegen eine günstige Open-Weight-API liegt der Break-even bei zweistelligen Millionen Tokens pro Tag auf einer ausgelasteten GPU, gegen eine teure Frontier-API weit niedriger. Datenresidenz kann Self-Hosting unabhängig von den Kosten erzwingen. Nach dem beschlossenen EU-AI-Act-Zeitplan gilt Artikel-50-Transparenz ab 2. August 2026, eigenständiges Hochrisiko ab 2. Dezember 2027 und produktintegriertes Hochrisiko ab 2. August 2028. Für die meisten frühen und mittleren Produkte ist eine EU-residente Hosted API günstiger und weniger Arbeit. Passende Leistung: [KI Enablement](/de/services/ai-enablement/) Auf dem Papier wirkt Self-Hosting eines Open-Weight- [LLM](/de/glossary/llm/) wie ein Selbstläufer. Miete eine GPU für ein paar Dollar pro Stunde, lass ein kostenloses Modell laufen, hör auf, pro Token zu zahlen. Die Kostenkurve wird flach, und der Stack gehört dir. So klingt der Pitch, und er stimmt zur Hälfte. Was er verschweigt, entscheidet darüber, ob du sparst oder unbemerkt 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](/de/services/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](/de/blog/reduce-llm-token-costs-2026/), 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](https://getdeploying.com/gpus/nvidia-h100) 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. Zählt man alles zusammen, ist die ehrliche Einordnung dieselbe wie in unserer Token-Kosten-Arbeit: Über den Break-even entscheidet die Entwicklerzeit, nicht der GPU-Rack-Preis. 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 so groß, dass genau hier der häufigste Self-Hosting-Fehler passiert. - 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](/de/blog/llm-api-costs-2026-architecture-shift/). | Kostentreiber | Hosted API | Self-hosted | Wer gewinnt, und wann | | --- | --- | --- | --- | | Token-Nutzung | Pro Token, skaliert linear | Flacher GPU-Preis, unabhängig von der Nutzung | Self-hosted bei hohem stetigem Volumen, API bei niedrigem oder stoßweisem | | Leerlauf | $0, wenn ungenutzt | Du zahlst die GPU rund um die Uhr | API, außer die GPU bleibt ausgelastet | | Ops und Wartung | Problem des Anbieters | Deine Engineers, laufend | API, fast immer | | Modell-Upgrades | Anbieter liefert sie | Du deployst und evaluierst neu | API | | Datenresidenz-Kontrolle | Hängt von Region und Vertrag ab | Volle Kontrolle auf deiner Infra | Self-hosted | | Latenz-Tuning | Vom Anbieter fixiert | Du besitzt es Ende zu Ende | Self-hosted, wenn du das Know-how hast | ![Kevin Riedl](/img/team/kevin.webp) "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](/de/blog/eu-data-residency-ai-apps-2026/). Darüber liegt eine regulatorische Schicht. Der [EU AI Act wird schrittweise wirksam](https://www.consilium.europa.eu/en/press/press-releases/2026/06/29/artificial-intelligence-council-gives-final-green-light-to-simplify-and-streamline-rules/). Pflichten für General-Purpose-KI-Modelle gelten bereits, Artikel-50-Transparenz ab 2. August 2026, Pflichten für eigenständige Hochrisiko-Systeme ab 2. Dezember 2027 und für produktintegrierte Hochrisiko-Systeme ab 2. August 2028. Die praktische Erkenntnis für ein EU-Team ist nicht nur ein Datum. Die Kontrolle darüber, wo dein Modell läuft, wird zu einem Governance-Asset, nicht nur zu einer Kostenposition, und Self-Hosting ist ein Weg, diese Kontrolle in der eigenen Hand zu behalten. Prüfe Klassifikation und Rolle gegen offizielle 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](https://docs.vllm.ai/en/latest/) 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. Die Latenz hat ihren eigenen Hebel: ein [geteilter KV Cache senkte die Time-to-first-token um rund das 14-Fache](/de/blog/shared-kv-cache-llm-inference-latency/) bei einem großen Modell, indem Serving-Prozesse sich gegenseitig den Cache wiederverwenden statt neu zu prefillen, ganz ohne neue Hardware. - 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](https://www.digitalapplied.com/blog/quantization-tradeoffs-4bit-8bit-fp8-performance-data). 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](/de/blog/open-weight-llm-comparison-2026/) durch. Wenn Smartphone- oder Laptop-Speicher das harte Limit ist, trennt unser [Bonsai-27B-Test](/de/blog/bonsai-27b-phone-local-ai-review/) die 3,9-GB-Schlagzeile vom echten Runtime-Speicher und der Aufgabenqualität. Modellgewichte sind nur ein Teil der Speicherrechnung: Wenn du Retrieval betreibst, hat der Embedding-Index seinen eigenen Bedarf, und unser Leitfaden zum [16x Schrumpfen des RAG-Vektorspeichers](/de/blog/rag-vector-memory-quantization/) zeigt, wie datenunabhängige Quantisierung ihn verkleinert. ## 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](/de/case-studies/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](/de/services/ai-enablement/) -Arbeit. ## Fazit Open-Weight-LLMs in der EU selbst zu hosten rechnet sich in zwei Situationen, und du solltest ehrlich sein, in welcher du steckst. Die erste ist stetiges hohes Volumen auf einer ausgelasteten GPU, wo die flachen Hardware-Kosten die Pro-Token-Preise schlagen, sobald du das volle operative Bild mitrechnest, nicht nur den Rack-Preis. Die zweite ist Datenresidenz, wo Inferenz auf der eigenen EU-Infrastruktur eine Governance-Entscheidung ist, die die Kosten komplett überschreiben kann. Außerhalb dieser zwei Fälle ist eine Hosted API, idealerweise eine EU-residente, meist günstiger und weit weniger Arbeit, und die meisten Teams greifen zu früh zu Self-Hosting, weil sie die GPU bepreisen und den Engineer vergessen. Die Zahlen hier sind Richtwerte, und GPU- wie Token-Märkte bewegen sich monatlich, also prüfe vor dem Commit, beweise jede Modell- und Quantisierungs-Wahl mit einem Eval, und behandle Self-Hosting als Entscheidung, in die du hineinwächst, nicht als eine, mit der du startest. ## Das könnte dich auch interessieren.. [**Open-Weight-LLM-Vergleich 2026** Llama, Qwen, DeepSeek und Mistral-Klasse-Modelle, verglichen an den Kriterien, die einen self-hosted Stack entscheiden.](/de/blog/open-weight-llm-comparison-2026/) [**AI Enablement vs eine generische KI-Beratung** Die eine reicht dir ein Strategie-Deck. Die andere liefert ein laufendes Setup auf deiner Infrastruktur, das dein Team besitzt.](/de/compare/ai-enablement-vs-generic-ai-consultancy/) Modelle und Infrastruktur ## In diesem Cluster weiterlesen - [OmniRoute KI-Routing: Setup und Produktions-Checkliste](/de/blog/omniroute-ai-routing-setup/) - [Gemini Robotics 2: Ganzkörpersteuerung und die Pilotentscheidung](/de/blog/gemini-robotics-2-whole-body-control/) - [pdf-inspector im Test: PDFs vor OCR lokal routen](/de/blog/pdf-inspector-ocr-routing/) - [Lokaler multimodaler KI-Coding-Assistent: Sprache, OCR und Datenschutz](/de/blog/local-multimodal-ai-coding-assistant/) - [DeepSeek V4 Flash 0731 auf einem KI-PC: Was funktioniert?](/de/blog/deepseek-v4-flash-0731-local-ai-pc/) Postfach, ohne Lärm ## Folge der Arbeit, die für dich zählt Du bekommst eine kurze E-Mail, wenn wir etwas Neues veröffentlichen. Folge dem ganzen Blog oder nur den Themen, die dich interessieren. [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 9 Min Lesezeit · 26. Juni 2026 [**Weiter**](/de/blog/open-weight-llm-comparison-2026/) Neue Beiträge per E-Mail × × Neue Beiträge per E-Mail Eine kurze E-Mail, wenn wir etwas veröffentlichen. Kostenlos, ohne Tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/self-hosting-llms-eu-cost/#webpage", "@type": "WebPage", "dateModified": "2026-07-07", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-07", "url": "https://wavect.io/de/blog/self-hosting-llms-eu-cost/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Open-Weight-LLMs selbst zu hosten wirkt günstig, weil man die GPU bepreist, nicht den Engineer, der sie am Leben hält. Eine H100 mietest du für rund $2-4/h auf EU-Clouds (Richtwert, prüfen), aber entscheidend sind Ops, Redundanz und ein Eval-Harness, der beweist, dass ein quantisiertes Modell die Qualität hält. Gegen eine günstige Open-Weight-API liegt der Break-even bei zweistelligen Millionen Tokens pro Tag auf einer ausgelasteten GPU, gegen eine teure Frontier-API weit niedriger. Datenresidenz kann Self-Hosting unabhängig von den Kosten erzwingen. Nach dem beschlossenen EU-AI-Act-Zeitplan gilt Artikel-50-Transparenz ab 2. August 2026, eigenständiges Hochrisiko ab 2. Dezember 2027 und produktintegriertes Hochrisiko ab 2. August 2028. Für die meisten frühen und mittleren Produkte ist eine EU-residente Hosted API günstiger und weniger Arbeit.", "articleBody": " Blog-Übersicht/AI und Agents/Modelle und Infrastruktur LLMs in der EU selbst hosten: Wann sich Open Weights wirklich rechnen TL;DR Open-Weight-LLMs selbst zu hosten wirkt günstig, weil man die GPU bepreist, nicht den Engineer, der sie am Leben hält. Eine H100 mietest du für rund $2-4/h auf EU-Clouds (Richtwert, prüfen), aber entscheidend sind Ops, Redundanz und ein Eval-Harness, der beweist, dass ein quantisiertes Modell die Qualität hält. Gegen eine günstige Open-Weight-API liegt der Break-even bei zweistelligen Millionen Tokens pro Tag auf einer ausgelasteten GPU, gegen eine teure Frontier-API weit niedriger. Datenresidenz kann Self-Hosting unabhängig von den Kosten erzwingen. Nach dem beschlossenen EU-AI-Act-Zeitplan gilt Artikel-50-Transparenz ab 2. August 2026, eigenständiges Hochrisiko ab 2. Dezember 2027 und produktintegriertes Hochrisiko ab 2. August 2028. Für die meisten frühen und mittleren Produkte ist eine EU-residente Hosted API günstiger und weniger Arbeit. Passende Leistung: KI Enablement Auf dem Papier wirkt Self-Hosting eines Open-Weight-LLM wie ein Selbstläufer. Miete eine GPU für ein paar Dollar pro Stunde, lass ein kostenloses Modell laufen, hör auf, pro Token zu zahlen. Die Kostenkurve wird flach, und der Stack gehört dir. So klingt der Pitch, und er stimmt zur Hälfte. Was er verschweigt, entscheidet darüber, ob du sparst oder unbemerkt 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. Zählt man alles zusammen, ist die ehrliche Einordnung dieselbe wie in unserer Token-Kosten-Arbeit: Über den Break-even entscheidet die Entwicklerzeit, nicht der GPU-Rack-Preis. 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 so groß, dass genau hier der häufigste Self-Hosting-Fehler passiert. 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", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-07-07", "datePublished": "2026-06-26", "description": "Open-Weight-LLMs selbst zu hosten wirkt günstig, weil man die GPU bepreist, nicht den Engineer, der sie am Leben hält. Eine H100 mietest du für rund $2-4/h auf EU-Clouds (Richtwert, prüfen), aber entscheidend sind Ops, Redundanz und ein Eval-Harness, der beweist, dass ein quantisiertes Modell die Qualität hält. Gegen eine günstige Open-Weight-API liegt der Break-even bei zweistelligen Millionen Tokens pro Tag auf einer ausgelasteten GPU, gegen eine teure Frontier-API weit niedriger. Datenresidenz kann Self-Hosting unabhängig von den Kosten erzwingen. Nach dem beschlossenen EU-AI-Act-Zeitplan gilt Artikel-50-Transparenz ab 2. August 2026, eigenständiges Hochrisiko ab 2. Dezember 2027 und produktintegriertes Hochrisiko ab 2. August 2028. Für die meisten frühen und mittleren Produkte ist eine EU-residente Hosted API günstiger und weniger Arbeit.", "headline": "LLMs in der EU selbst hosten: Wann sich Open Weights wirklich rechnen", "image": "https://wavect.io/img/blog/headers/header_self-hosting-llms-eu-cost.svg", "inLanguage": "de", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/self-hosting-llms-eu-cost/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/self-hosting-llms-eu-cost/", "wordCount": 2272 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/ai-agents/", "name": "AI und Agents", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/models-infrastructure/", "name": "Modelle und Infrastruktur", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/self-hosting-llms-eu-cost/", "name": "LLMs in der EU selbst hosten: Wann es sich rechnet | ", "position": 5 } ] } ```