Pexon Consulting | 9 Min. Lesezeit | 30.08.2026
TL;DR
Self-Hosted LLM-Kosten werden von Idle-GPUs und fehlendem Sharing getrieben. Sizing, Quantisierung und Betrieb entscheiden gegen die API. Eine L4 für 7B-Inferenz liegt grob bei 450-550 EUR/Monat on-demand; eine A100-80GB für 70B-quantisiert bei 3.000-3.800 EUR. Ohne Auslastung und Day-2-Betrieb gewinnt die API.
Die Rechnung, die Teams vergessen
GPU LLM Kubernetes-Sizing entscheidet über Idle-Kosten. Ohne klare GPU LLM Kubernetes-Monatsrechnung bleibt nur die API-Zeile im Board.
Die erste Cloud-GPU-Rechnung trifft selten den Plan. Gebucht wird eine A100 „für Llama“, geliefert wird eine Monatszeile mit Idle-Stunden, Persistent Disk, Egress und Engineer-Zeit für Treiber, CUDA und Queue-Timeouts. Der Token-Preis der API war vorher die einzige Zahl im Board-Deck. Danach fehlen drei Blöcke.
Idle schlägt Listenpreis. On-demand rechnet die GPU, solange die Instanz läuft, nicht solange Token fließen. Eine A100-40GB bei rund 3,67 USD/Stunde (GCP a2-highgpu-1g, Stand 28.08.2026) kostet bei 24/7-Betrieb grob 2.700 USD im Monat, auch wenn die Auslastung nachts bei 5 Prozent liegt. Spot senkt den Stundensatz, aber Produktions-Inferenz mit SLA verträgt Preemption selten.
Engineer-Zeit ist Teil der TCO. GPU Operator, Node-Labels, Quota, Image-Pulls, Modell-Updates und Observability sind kein Nebenprojekt. Wer nur Hardware gegen API-Token rechnet, unterschätzt den Break-even um Wochen.
Modell-Updates ändern die Rechnung. Neue Gewichte, längerer Kontext, anderes Quantisierungsformat: VRAM-Bedarf springt. Ohne Sizing-Matrix und Sharing (MIG, Multi-LoRA, gemeinsamer vLLM-Pool) entsteht schnell eine zweite GPU „für Team B“.
Kurz: GPU-Kosten LLM sind kein Stundensatz, sondern Auslastung × Kapazität × Betrieb. Die technische Serving-Schicht beschreiben wir in vLLM produktiv deployen. Hier geht es um die Monatsrechnung davor.
Sizing-Matrix: Modellklasse × GPU × Quantisierung
Sizing startet bei VRAM, nicht bei Markennamen. Faustregeln für Inferenz (Richtwerte, kein Labor-Benchmark):
Quantisierung spart VRAM und damit GPU-Klasse, nicht magisch Token-Qualität. INT8/AWQ hält viele Chat- und RAG-Lasten akzeptabel; für kritische Extraktion oder Reasoning lohnt ein A/B gegen FP16. Wer 70B unquantisiert auf eine einzelne L4 plant, plant falsch.
Sharing ist der zweite Hebel. Eine dedizierte A100 pro Team bei 20 Prozent Last ist teurer als ein gemeinsamer vLLM-Endpoint mit Queue, Rate-Limits und Modell-Routing. MIG (Multi-Instance GPU) teilt große Ampere/Hopper-Karten in isolierte Profile; sinnvoll, wenn mehrere kleine Modelle parallel laufen und Isolation gefordert ist. Für viele SaaS-Teams reicht zuerst ein Shared-Pool mit klaren SLOs.
Cloud vs Own: Hyperscaler-On-Demand ist teurer als Neocloud oder eigene Hardware, aber Quota, Region und Enterprise-Vertrag zählen. Die Monatsrechnung unten nutzt bewusst Hyperscaler-Listenpreise als Obergrenze für den Board-Vergleich.
Monatsrechnung: Cloud-GPU-Referenz (Stand 2026-08-28)
Quellen für Stundensätze (On-Demand, US-Regionen, gerundet): Thunder Compute GCP GPU Guide (Last reviewed 28.08.2026) und Thunder Compute H100 Pricing (August 2026). Monat = 730 Stunden (24/7). EUR-Spanne mit FX ca. 0,92 USD/EUR, ohne Storage/Egress/Reserved/Spot. Keine Cent-Genauigkeit.
Was die Tabelle bewusst weglässt: Spot (oft 60-90 Prozent günstiger, aber unterbrechbar), 1-/3-Jahres-Commitments, Persistent Disk, Egress, Managed-Zuschläge (Vertex u. ä.), Engineer-Stunden und Multi-GPU-Networking. Mit 40 Prozent Auslastung ohne Autoscaling verdoppeln sich die effektiven Kosten pro Token gegenüber der Spaltenlogik „730 Stunden voll genutzt“.
Break-even gegen API (Orientierung): Bei niedrigem, spitzenartigem Volumen gewinnt die API. Self-Host wird attraktiv bei hoher, vorhersehbarer Last, Datenschutz (keine Prompt-Abgabe), oder wenn mehrere Teams dieselbe GPU teilen. Die Entscheidung ist Auslastung + Compliance, nicht nur Listenpreis.
Für Lab-Setups ohne Kubernetes-Cluster reicht manchmal ein einzelner Host mit Ollama; produktiv und auditfest ist das ein anderes Betriebsmodell. Einstieg: Private AI mit Ollama und Open WebUI.
Was Pexon konkret macht
Wir verkaufen keinen GPU-Rechner als Produkt. Wir betreiben die offene KI-Schicht auf eurem Cluster und machen die Kosten steuerbar.
- Last und Modellklasse klären (Token/Tag, Peak, Latenz, Datenklassifizierung).
- Sizing-Matrix gegen VRAM und Quantisierungsoptionen legen.
- Serving mit vLLM (oder vergleichbarem Open-Stack) statt ad-hoc-Container.
- Sharing-Design: gemeinsamer Pool, optional MIG, Rate-Limits, Team-Quotas.
- GPU-Betrieb auf Kubernetes: Operator, Node-Pools, Observability, Kosten-Tags.
- Nachweis-Paket: wer darf welches Modell, welche Region, welche Logs (Bankqualität-Winkel).
- Festpreis-Pfad vom Scan zum Managed-Betrieb der KI-Plattform.
Kauf-Claim bleibt Betrieb in Bankqualität. KI auf Kubernetes (vLLM, LiteLLM, GPU) ist der Differenzierer, nicht der Ersatz für Day-2. Details: Hub KI-Plattform-Betrieb (siehe Nächster Schritt).
Was das nicht ist
Das ist keine Preisgarantie und kein Cloud-Resellerrechner. Listenpreise ändern sich regional und wöchentlich; Spot und Reservierungen verschieben die Spanne stark. Wir liefern keine Cent-genaue Forecast-Excel und keine Empfehlung „kauft immer H100“.
Das ist auch keine generische KI-Beratung ohne Cluster-Betrieb. Wir rechnen Sizing, damit ihr nicht blind Hardware bucht, und betreiben danach die Plattform so, dass Idle, Sharing und Nachweis halten. Wer nur einen einmaligen Architektur-Workshop sucht, ist hier falsch. Wer eine Monatsrechnung braucht, die Board und Platform Lead gemeinsam lesen können, ist richtig.
FAQ
Wann ist Self-Host günstiger als die API?
Wenn die GPU über den Monat ausreichend ausgelastet ist, die Last planbar bleibt und Datenschutz oder Latenz gegen Public-API sprechen. Bei spitzenartigem Traffic ohne Sharing bleibt die API oft günstiger, selbst wenn der Stundensatz der GPU „billig“ wirkt.
Welche GPU für welches Modell?
7B: typisch 1× L4. 13B: A100-40 oder zwei kleinere Karten. 70B: quantisiert oft 1× A100-80; unquantisiert Multi-GPU oder H100-Klasse. Immer VRAM und Batch-Größe prüfen, nicht nur Parametertafel.
Was spart Quantisierung wirklich?
Vor allem die GPU-Klasse (eine statt zwei Karten, L4 statt A100). Qualitätsverlust ist use-case-abhängig. Für Board-Zahlen: Quantisierung ist ein Kapazitätshebel, kein Freifahrtschein für Qualität.
Welche versteckten Kosten hat Kubernetes-Betrieb?
GPU Operator und Treiber, Image-Registry, Persistent Volumes für Gewichte, Observability, On-Call/Servicezeit, Egress beim Modell-Pull, Idle ohne Autoscaling, Engineer-Zeit für Upgrades. Die Cloud-Zeile „GPU“ ist selten die volle TCO.
Reicht Spot für produktive Inferenz?
Selten als alleinige Strategie. Spot eignet sich für Batch, Offline-Jobs und Experimente. Für synchrone User-Facing-Inferenz mit SLO eher on-demand, Reserved oder eigene Kapazität plus klarer Overflow zur API.
Brauchen wir Kubernetes für die erste Private LLM?
Nicht zwingend für einen POC auf einem Host. Sobald mehrere Teams, GPU-Sharing, Nachweise und Day-2 gefordert sind, zahlt sich ein Cluster mit offener Serving-Schicht aus. Genau dafür existiert der Hub KI-Plattform-Betrieb.
Wie aktuell sind die Monatszahlen?
Stundensätze referenzieren öffentliche Cloud-GPU-Vergleiche mit Stand 28.08.2026 (Thunder Compute / Hyperscaler-Anker). Vor Budgetfreigabe immer Region und aktuelle Listenseite des Providers prüfen.
Nächster Schritt
Self-Hosted LLM-Kosten steuern sich über Sizing, Quantisierung, Sharing und Betrieb, nicht über den teuersten Chip. Wir betreiben euren Kubernetes-Cluster in Bankqualität und die KI-Plattform darauf auf offenen Standards: nachweisbar, festpreisig, gehört euch.
- KI-Plattform-Betrieb Hub (AI-Readiness-Scan-Pfad, 990 EUR)
- Technik-Vertiefung: vLLM produktiv deployen (siehe Link oben)
