MoE-Modell selbst hosten oder API? Kosten-Balance 2026

Das Ergebnis zuerst: API gewinnt bei unsicherer Auslastung

Kimi K3 wird laut offizieller Modellkarte mit MXFP4-Gewichten und MXFP8-Aktivierungen ausgeliefert und für Engines wie vLLM und SGLang empfohlen. Das macht die Ausführung effizienter, ändert aber nichts an der Grundregel: Die aktiven Parameter eines MoE-Modells beschreiben nicht den vollständigen Speicherbedarf. (huggingface.co)

Für Teams mit niedriger oder stark schwankender Auslastung gewinnt deshalb die API. Für ein noch nicht validiertes Modell ist kurzfristig gemietete Rechenleistung die bessere Zwischenstufe. Langfristiges Self-Hosting lohnt sich erst, wenn die Gewichte, der Runtime-Stack, die Auslastung, die Datenschutzanforderungen und die Fehlerbehebung zuverlässig nachgewiesen sind.

Diese Entscheidung gilt für drei Gruppen:

• AI-Start-ups und Agent-Teams, die Modelle häufig wechseln und eine schnelle Rückfalloption benötigen.
• MLOps- und Infrastrukturteams, die Speicherbedarf, Runtime-Reserve und Cluster-Topologie prüfen müssen.
• Technische und kaufmännische Verantwortliche, die API, eigene Hardware und kurzfristige Mietkosten unter demselben Geschäftsvolumen vergleichen wollen.

Speicherbedarf statt Aktivierungszahl

Aktive Parameter sind keine Speicherformel

Bei einem MoE-Modell wird pro Token nur ein Teil der Experten berechnet. Das senkt den Rechenaufwand pro Token. Die nicht aktivierten Experten verschwinden jedoch nicht aus dem Modell. Für eine übliche Inferenz müssen die Gewichte, Metadaten und die für das Routing erforderlichen Komponenten weiterhin verfügbar sein.

Die Frage, ob die Zahl der aktiven Parameter den Bereitstellungsspeicher bestimmen kann, wird daher mit nein beantwortet. Sie kann eine grobe Rechenlast beschreiben. Für die Kapazitätsplanung reicht sie nicht.

Die belastbare Rechnung lautet:

Gesamter GPU-Speicherbedarf =
Gewichte
+ Quantisierungs- und Skalierungsmetadaten
+ Runtime-Arbeitsspeicher
+ KV-Cache
+ Kommunikationspuffer
+ Sicherheitsreserve

Dabei sind mindestens fünf Grenzen getrennt zu dokumentieren:

1. Laden: Die Dateien lassen sich vom Speicher in die Runtime einlesen.
2. Starten: Der Prozess initialisiert Modell, Kernel und Kommunikationsgruppen.
3. Generieren: Eine einzelne Anfrage erzeugt tatsächlich Tokens.
4. Skalieren: Mehrere parallele Anfragen bleiben innerhalb der Speichergrenzen.
5. Produktion: Spitzenlast, Wiederholungen, Monitoring und Fehlerfälle werden toleriert.

Ein Modell, das nur geladen werden kann, ist noch keine betriebsfähige Plattform.

Speicherbestandteil	Was geprüft wird	Typischer Planungsfehler
Gewichte	Tatsächliche Dateien, Format und Sharding	Aktivierte Parameter mit Gesamtgewicht verwechseln
Quantisierungsdaten	Skalierungsfaktoren, Blockmetadaten, Kernel	Nominale Bitbreite als exakten Speicherwert behandeln
Runtime-Arbeitsbereich	CUDA- oder ROCm-Puffer, temporäre Tensoren	Nur die Modell-Dateigröße kalkulieren
KV-Cache	Kontextlänge, Batch, parallele Sitzungen	Lange Agentenverläufe nicht einrechnen
Sicherheitsreserve	Startspitzen, Fragmentierung, Wiederanlauf	Mit 100 % belegtem Speicher planen

Kimi K3 ist ein gutes Beispiel für diese Abgrenzung. Die offizielle Modellkarte nennt native MXFP4-Gewichte und MXFP8-Aktivierungen. Daraus lässt sich ableiten, dass die Hardware- und Runtime-Unterstützung geprüft werden muss; ein einfacher „Parameter geteilt durch vier“-Ansatz wäre keine belastbare Produktionszahl. (huggingface.co)

Für DeepSeek V4 sollte dieselbe Rechnung verwendet werden. Die offizielle Transparenzseite führt DeepSeek V4 mit einem Veröffentlichungsdatum vom 24.04.2026 und verweist auf Modellkarte und technischen Bericht. Diese offiziellen Unterlagen sind gegenüber Community-Schätzungen maßgeblich. (deepseek.com)

Bei Qwen3.8 Max ist besondere Zurückhaltung erforderlich. Ohne offiziell geprüfte Modellablage, Konfigurationsdatei, Gewichtsliste, Lizenz und Deployment-Anleitung darf keine konkrete Speicher- oder Beschaffungsentscheidung daraus abgeleitet werden. Community-Beiträge sind ein Signal für Suchinteresse, aber kein Kapazitätsnachweis.

Laufzeit und Cluster-Topologie

Laden, Generieren und Skalieren sind verschiedene Prüfungen

Die nächste Hürde ist die Kompatibilität. Eine Datei kann verfügbar sein und trotzdem in der gewünschten Inferenzumgebung nicht korrekt laufen. Zu prüfen sind:

• unterstützte Modellarchitektur;
• Quantisierungsformat und passende Kernel;
• Version von Treibern, Runtime und Inferenzserver;
• CPU-Arbeitsspeicher für Laden und Offloading;
• Netzwerk zwischen den Beschleunigern;
• Verhalten bei langen Kontexten;
• Lizenz- und Datenschutzbedingungen.

Bei großen MoE-Modellen muss außerdem festgelegt werden, wie die Gewichte verteilt werden. Tensor Parallelism zerlegt Parameter über mehrere GPUs. Pipeline Parallelism verteilt Modellschichten. Expert Parallelism verteilt die Experten. Data Parallelism vervielfältigt eine Modellinstanz für zusätzliche Anfragen.

Die aktuelle vLLM-Dokumentation beschreibt diese Strategien getrennt und weist ausdrücklich darauf hin, dass Expert Parallelism für MoE-Modelle vorgesehen ist. (docs.vllm.ai)

Ein wichtiger Prüfwert lautet:

EP-Größe = TP-Größe × DP-Größe

Diese Beziehung ist in der offiziellen Deployment-Dokumentation beschrieben. Ein Beispiel mit TP = 2 und DP = 4 ergibt eine Expert-Parallel-Gruppe über 8 GPUs. Das ist keine universelle Empfehlung, zeigt aber, warum „eine GPU pro aktiver Expertengruppe“ als Planungslogik nicht ausreicht. (github.com)

In einer Mehrknoten-Umgebung kommen weitere Fehlerquellen hinzu:

• unterschiedliche lokale und globale Rangnummern;
• falsche Netzwerkadressen;
• fehlende Kommunikationsbibliotheken;
• inkompatible All-to-All-Pfade;
• kein Headless-Modus für Worker-Knoten;
• zu geringe Bandbreite zwischen den Geräten;
• fehlende Überwachung der Expert-Lastverteilung.

Die vLLM-Anleitung nennt für Expert Parallelism zusätzliche Komponenten und konkrete Konfigurationsschritte. Sie beschreibt auch, dass sekundäre Knoten ohne API-Server betrieben werden können und der erste Knoten die Anfragen koordiniert. (github.com)

Achtung: Wenn ein Startprotokoll nur „Model loaded“ meldet, ist die Kapazitätsprüfung nicht abgeschlossen. Erst ein Test mit realer Kontextlänge, parallelen Anfragen, Wiederholungen und kontrolliertem Neustart zeigt, ob die Konfiguration für den vorgesehenen Dienst ausreicht.

Effektive Auslastung statt nominaler Geschwindigkeit

Die relevante Einheit ist die erledigte Anfrage

Die Entscheidung, ab welcher täglichen Aufrufzahl Self-Hosting wirtschaftlich wird, lässt sich nicht mit einer festen Zahl beantworten. Die wirtschaftlich relevante Einheit ist die erfolgreich abgeschlossene Anfrage mit dem vereinbarten Antwortziel.

Ein Team sollte mindestens diese Werte aus einer echten Woche erfassen:

• Anfragen pro Stunde;
• Eingabe- und Ausgabetoken;
• Spitzenlast und Leerlaufzeiten;
• parallele Agentensitzungen;
• Zeit bis zum ersten Token;
• Zeit pro Ausgabetoken;
• Werkzeugaufrufe;
• abgebrochene Anfragen;
• Wiederholungen nach Fehlern;
• gewünschte Verfügbarkeit;
• maximale akzeptierte Wartezeit.

Ein leerer Benchmark mit idealer Batch-Größe ist für die Kostenrechnung ungeeignet. Er misst, was die Hardware unter Laborbedingungen leisten kann. Er misst nicht, wie viele produktive Aufgaben erfolgreich abgeschlossen werden.

Für ein Agent-Produkt sind Werkzeugaufrufe besonders wichtig. Eine einzelne Nutzeraktion kann mehrere Modellaufrufe, Planungsphasen, Funktionsaufrufe und Nachbearbeitung auslösen. Wird nur der erste API-Aufruf gezählt, wird die Vergleichsrechnung zu niedrig angesetzt.

Auch die Antwortqualität muss in die Messung einfließen. Eine günstige eigene Instanz, die bei langen Kontexten häufiger abbricht oder Agentenprotokolle nicht vollständig erhalten kann, erzeugt zusätzliche Wiederholungen. Damit steigt der effektive Tokenverbrauch, obwohl die sichtbare Anfragezahl gleich bleibt.

Die offizielle Kimi-K3-Dokumentation weist beispielsweise darauf hin, dass bei mehrstufigen Gesprächen und Werkzeugaufrufen die vollständige Denk- und Werkzeughistorie zurückgegeben werden muss. Das ist ein konkreter Integrationspunkt, der Speicher, Netzwerk und Anwendungscode beeinflusst. (huggingface.co)

Kostenmodell und Break-even

Drei Routen mit derselben Geschäftsleistung

Die Kosten dürfen nicht als GPU-Stundensatz gegen API-Preis verglichen werden. Verglichen werden muss dieselbe Leistung:

gleiches Modell
+ gleiche Eingabe- und Ausgabelänge
+ gleiche Parallelität
+ gleiche Latenzanforderung
+ gleiche Verfügbarkeit
+ gleiche Fehlerbehandlung

Die monatlichen Kosten einer eigenen Plattform können so strukturiert werden:

C_eigen =
GPU-Nutzung oder Abschreibung
+ Speicher
+ Datenübertragung
+ Strom und Rechenzentrumsbetrieb
+ Monitoring
+ Bereitschaft und Wiederherstellung
+ Engineering-Zeit
+ Reserve für ungenutzte Kapazität
+ Risikobudget

Die API-Kosten werden anders aufgebaut:

C_API =
Eingabetoken
+ Ausgabetoken
+ Reasoning- oder Spezialmodus
+ Werkzeugaufrufe
+ Caching-Regeln
+ fehlgeschlagene Wiederholungen
+ Daten- und Compliance-Aufwand

Für kurzfristig gemietete Rechenleistung kommt hinzu:

C_Miete =
belegte Mietdauer
+ Speicher- und Übertragungskosten
+ Einrichtungszeit
+ Testwiederholungen
+ nicht nutzbare Wartezeit

Die Gleichung für den Break-even lautet:

C_eigen = C_API

Praktisch wird daraus:

Anfragen_break-even =
Fixkosten der eigenen Plattform
/
(API-Kosten je Anfrage
- variable Eigenkosten je Anfrage)

Diese Formel funktioniert nur, wenn die Eingabe- und Ausgabelängen, Wiederholungen und Qualitätsziele identisch sind. Ein Team, das beim Self-Hosting einen kleineren Kontext oder eine niedrigere Antwortqualität akzeptiert, vergleicht keine identische Dienstleistung mehr.

Kostenfaktor	API	Kurzfristige Miete	Dauerhaftes Self-Hosting
Anfangsinvestition	niedrig	niedrig bis mittel	hoch
Wechsel des Modells	sehr einfach	gut testbar	teuer und langsam
Leerlaufkosten	gering	abhängig von Mietdauer	dauerhaft vorhanden
Datenschutzkontrolle	vertraglich prüfen	technisch konfigurierbar	am höchsten
Fehlersuche	begrenzte Kontrolle	eigene Verantwortung	vollständig eigene Verantwortung
Geeignet bei schwankender Last	meist gut	gut	meist schlecht
Geeignet bei stabiler Spitzenlast	abhängig vom Tarif	möglich	potenziell sinnvoll

Die zentrale Frage lautet somit nicht „Wie billig ist ein Token?“, sondern „Wie viele produktive, fehlerfreie Anfragen werden pro belegter Ressource erledigt?“

Modelle als Kalibrierpunkte

Kimi K3, DeepSeek V4 und Qwen3.8 Max

Die drei Modelle eignen sich als Prüfsteine für dieselbe Methode, nicht als Leistungsrangliste.

Kimi K3: Die offizielle Modellkarte nennt MXFP4 für Gewichte, MXFP8 für Aktivierungen und empfiehlt mehrere MoE-fähige Inferenzengines. Damit stehen Quantisierungsformat und Runtime-Kompatibilität im Vordergrund. Die korrekte Frage lautet nicht nur, ob der Speicher reicht, sondern ob der vorgesehene Kernel auf der gewählten Hardware stabil läuft. (huggingface.co)

DeepSeek V4: Die Veröffentlichung ist offiziell dokumentiert. Für eine Kostenrechnung müssen Modellkarte, technischer Bericht, Dateilisten und Deployment-Anleitung zusammengeführt werden. Ein Modellname allein liefert weder eine belastbare Speicherzahl noch eine Produktionskonfiguration. (deepseek.com)

Qwen3.8 Max: Solange die offiziellen Gewichte, die Modellkarte und die Dateiliste nicht geprüft sind, bleibt die Zeile im Planungsblatt offen. Ein Community-Post oder eine erwartete Veröffentlichung darf nicht in eine langfristige Miet- oder Kaufentscheidung umgewandelt werden.

Dadurch können Kimi K3 und DeepSeek V4 grundsätzlich mit derselben Formel verglichen werden. Die Variablen werden pro Modell mit eigenen Quellen gefüllt. Qwen3.8 Max erhält zunächst nur den Status „noch nicht verifiziert“. Das ist keine Lücke im Bericht, sondern eine bewusst gesetzte Abbruchbedingung.

Entscheidungsmatrix und Abbruchlinie

Die folgende Matrix hilft bei der Auswahl:

Bedingung	API	Kurzfristige Rechenmiete	Dauerhaftes Self-Hosting
Modellversion ändert sich häufig	bevorzugt	bevorzugt	ungeeignet
Gewichte noch nicht verifiziert	bevorzugt	nur für Test	nicht freigeben
Last ist niedrig oder unregelmäßig	bevorzugt	für Messung	meist unwirtschaftlich
Daten dürfen Plattform nicht verlassen	nur bei passendem Vertrag	technisch prüfen	bevorzugt
Stabiler Dauerbetrieb	möglich	Übergangslösung	möglich
Verteilte Inferenz ist bereits beherrscht	optional	gut für Vergleich	Voraussetzung
Fehlerbehebung rund um die Uhr möglich	nicht erforderlich	teilweise nötig	erforderlich
Physische Kontrolle über Infrastruktur nötig	begrenzt	höher	am höchsten

Die klare Abbruchlinie lautet:

• Kapazität nicht nachgewiesen: keine Hardware beschaffen.
• Runtime nicht kompatibel: keine Produktionsabnahme.
• Last nicht stabil: keine dauerhafte Eigenplattform.
• Fehlerwiederherstellung nicht beherrscht: nur Testumgebung, keine Produktionszusage.
• Modellgewichte noch in Bewegung: API oder flexibel kündbare Mietphase.
• DSGVO- oder Datenschutzanforderungen ungeklärt: zuerst Datenfluss, Auftragsverarbeitung und Zugriffsrechte prüfen.

Für Datenschutzprüfungen sollten Verantwortliche die Datenschutzinformationen von ProxyMac und die vertraglichen Rahmenbedingungen des gewählten Rechenanbieters in die interne Freigabe einbeziehen. Die konkrete rechtliche Bewertung bleibt eine Aufgabe der zuständigen Datenschutz- und Rechtsverantwortlichen.

Messplan für die nächsten sieben Tage

Vor einer langfristigen Entscheidung genügt eine kurze, sauber dokumentierte Messphase. Sie sollte nicht nur einen erfolgreichen Start zeigen. Für die Auswahl der Testumgebung können Verantwortliche zunächst die technischen Hinweise im ProxyMac-Hilfebereich prüfen und anschließend die Umgebung anhand des folgenden Ablaufs dokumentieren.

1. Modellstand festhalten: Repository, Commit, Dateiliste, Lizenz und Konfiguration unverändert archivieren.
2. Speichergrenzen erfassen: Gewichtsspeicher, Runtime-Spitzen, KV-Cache und Speicherfragmentierung getrennt protokollieren.
3. Reale Anfrageklassen bilden: kurze Antworten, lange Agentenläufe, Werkzeugaufrufe und parallele Sitzungen aufnehmen.
4. Spitzenlast wiederholen: nicht nur den Durchschnitt testen, sondern die höchste erwartete Parallelität mehrfach ausführen.
5. Fehler provozieren: Worker-Neustart, Netzwerkunterbrechung, abgebrochene Anfrage und erneuten Modellstart prüfen.
6. Effektiven Durchsatz berechnen: nur erfolgreiche Antworten und tatsächlich erzeugte Tokens in die Produktivkennzahl einbeziehen.
7. Kosten einsetzen: Mietdauer, Speicher, Übertragung, Engineering-Zeit und Leerlauf in die Break-even-Formel übernehmen.
8. Rückfalloption testen: prüfen, ob der Dienst innerhalb des Zielzeitraums wieder auf API oder eine alternative Mietkonfiguration wechseln kann.

Vor dem Start sollten Zugangskontrolle, Schlüsselverwaltung, Datenlöschung und Protokollierung festgelegt werden. Die Betriebsdokumentation muss außerdem festhalten, wer einen Worker neu startet, wie ein fehlerhafter Knoten aus dem Cluster entfernt wird und wann auf die API zurückgeschaltet wird.

Was im aktuellen Setup oft übersehen wird

Ein bestehender API-Betrieb ist nicht automatisch die schlechteste Lösung. Er hat aber typische Nachteile:

• variable Kosten erschweren die Budgetplanung;
• Datenfluss und Auftragsverarbeitung müssen vertraglich geprüft werden;
• Modelländerungen des Anbieters können Verhalten und Qualität beeinflussen;
• Rate Limits oder Dienstunterbrechungen liegen außerhalb der eigenen Kontrolle.

Eine eigene Plattform löst diese Punkte nicht kostenlos. Sie verschiebt sie in die Verantwortung des Teams:

• GPU-Kapazität bleibt auch in Leerlaufzeiten gebunden;
• Modellwechsel erfordern neue Tests und oft neue Sharding-Strategien;
• Treiber, Kernel und Kommunikationsbibliotheken können den Start blockieren;
• Monitoring, Wiederherstellung und Bereitschaft verursachen laufende Arbeitskosten.

Deshalb ist kurzfristige Miete häufig der sachlich beste Mittelweg: Sie liefert reale Messwerte unter kontrollierten Bedingungen, ohne dass ein noch instabiles Modell sofort in eine langfristige Infrastrukturentscheidung mündet.

Für ein Team, das bereits über eine eigene Lösung nachdenkt, ist der wichtigste Vergleich nicht „API gegen GPU“. Es ist variable Fremdkosten gegen dauerhaft gebundene Kapazität plus Eigenverantwortung. Wenn die Last noch nicht regelmäßig genug ist, bleiben API und Mietumgebung flexibler. Wenn sensible Daten, stabile Spitzenlast und ein belastbares MLOps-Team zusammenkommen, kann Self-Hosting den höheren Kontrollgrad rechtfertigen.

Wer heute ein wechselndes MoE-Modell direkt auf eigener Infrastruktur festschreibt, bindet Kapital, bevor Speicherbedarf, Runtime und Auslastung bewiesen sind. Eine flexible Rechenmiete von ProxyMac ist für diese Prüfphase meist die bessere Ausgangslage: Das Team kann echte Startlogs, Kapazitätsgrenzen und Wiederherstellungszeiten erfassen, ohne sofort eine dauerhaft überdimensionierte Umgebung zu übernehmen. Nach einer Woche realer Anfrageprotokolle lässt sich entscheiden, ob die API genügt, eine weitere Mietphase sinnvoll ist oder Self-Hosting tatsächlich den Break-even erreicht.