Billionen-LLMs selbst hosten: Aktivierung reicht nicht

Die bessere Entscheidung ist für die meisten Teams zunächst API oder ein zeitlich begrenztes Cluster: Wenige aktivierte Parameter senken hauptsächlich die Rechenarbeit pro Token, nicht automatisch den Speicherbedarf für die Modellgewichte. Ein langfristiges Selbsthosting von Billionen-Parameter-LLMs ist erst vertretbar, wenn Gewichtsspeicher, Quantisierungsformat, KV-Cache, Laufzeitreserven, Kommunikationspfad und stabile Zielauslastung nachweisbar zusammenpassen.

Dieser Beitrag richtet sich an Plattformingenieure, MLOps-Verantwortliche und AI-Agent-Teams, die wegen geringer Aktivierungsparameter ihre GPU-Budgetplanung für Kimi K3 oder DeepSeek V4 zu niedrig ansetzen. Er hilft außerdem dabei, gegenüber der Geschäftsleitung sauber zu erklären, warum geringere Rechenarbeit nicht automatisch ein kleines Deployment bedeutet.

Der erste Fehler: Aktivierungsparameter mit Gewichtsspeicher verwechseln

Bei einem Mixture-of-Experts-Modell werden pro Token nur ausgewählte Experten für die Berechnung herangezogen. Das beschreibt den Rechenpfad. Es beantwortet aber nicht die Frage, wo die übrigen Expertengewichte liegen.

Für eine belastbare Planung müssen mindestens vier Begriffe getrennt werden:

• Gesamtparameter: Alle Parameter des Modells einschließlich nicht ausgewählter Experten.
• Aktivierungsparameter: Die Parameter, die für einen konkreten Token an der Berechnung beteiligt sind.
• Gewichtsrückhaltung: Der Anteil der Modellgewichte, der beim Dienststart oder während der Ausführung im GPU- oder CPU-Speicher verfügbar sein muss.
• Rechenmenge pro Token: Die Arbeit, die der Router und die ausgewählten Experten für einen Token ausführen.

Die offiziellen Kimi-K3-Angaben zeigen die Größenordnung deutlich: Das Modell wird mit 2,8 Billionen Gesamtparametern, 104 Milliarden aktivierten Parametern, 896 Experten und 16 ausgewählten Experten pro Token beschrieben. Außerdem wird ein Kontextfenster von 1.048.576 Token angegeben. Diese Werte sind verschiedene Architekturfaktoren und dürfen nicht in eine einzige „benötigte Speichermenge“ umgedeutet werden. Kimi-K3-Modellkarte

Ein häufiger Fehlversuch sieht so aus:

Ein Team nimmt die 104 Milliarden aktivierten Parameter von Kimi K3, multipliziert sie mit einer angenommenen Bytezahl und plant daraus den gesamten GPU-Speicher. Der Start scheitert, weil die nicht aktivierten Expertengewichte trotzdem geladen oder zumindest adressierbar sein müssen.

Die korrekte Schlussfolgerung lautet deshalb:

• Aktivierungsparameter helfen bei der Abschätzung der Rechenarbeit.
• Gesamtparameter beeinflussen die Menge der dauerhaft vorzuhaltenden Gewichte.
• Kontextlänge, Parallelität und Antwortlänge bestimmen den zusätzlichen Laufzeitspeicher.
• Die konkrete Engine entscheidet, wie viel Speicher für Sharding, Puffer und Kernel benötigt wird.

Für DeepSeek V4 gilt dieselbe Trennung. Die offizielle Dokumentation führt DeepSeek-V4-Flash und DeepSeek-V4-Pro mit einem Kontextfenster von 1 Million Token und separaten Angaben zu Eingabe-, Ausgabe- und Parallelitätsgrenzen. Diese API-Eigenschaften belegen jedoch nicht automatisch, dass ein frei verfügbares, lokal ladbares Gewichtsarchiv mit identischer Konfiguration vorliegt. Für Selbsthosting müssen daher die offizielle Modellkarte, das Gewichtsrepository, die Lizenz und die unterstützte Engine getrennt geprüft werden. Offizielle DeepSeek-V4-Dokumentation

Die Antwort auf die zentrale MoE-Speicherfrage ist damit eindeutig: Für die Gewichtsbasis zählen die zu ladenden Gesamtgewichte, nicht nur die aktivierten Parameter. Aktivierungsparameter werden anschließend für Rechenleistung, Expertenauswahl und Kommunikationslast herangezogen.

Der zweite Fehler: Vier Bit mit einer exakten Speichergarantie gleichsetzen

Für eine ideale Rechnung entsprechen vier Bit ungefähr einem halben Byte pro Parameter. Das ist nur eine theoretische Gewichts-Baseline. Daraus folgt noch keine belastbare GPU-Anforderung für einen produktiven Dienst.

Bei blockweiser Quantisierung kommen unter anderem folgende Speicherbestandteile hinzu:

• Skalierungswerte pro Block,
• zusätzliche Metadaten,
• nicht quantisierte Schichten,
• Embeddings und Ausgabeköpfe,
• Format- und Dateiverwaltung,
• temporäre Dekodier- oder Dequantisierungspuffer,
• Kopien während des Ladevorgangs,
• Engine-spezifische Arbeitsbereiche.

Die Hugging-Face-Dokumentation zu MXFP4 beschreibt MXFP4 als blockweise skalierendes Format und weist darauf hin, dass bestimmte Module von der Quantisierung ausgenommen werden können. Außerdem nennt sie Hardware- und Kernelvoraussetzungen für unterstützte MXFP4-Pfade.

Auch NVIDIA beschreibt bei quantisierten Formaten Blockgrößen, Skalendatentypen und unterschiedliche Regeln für MXFP8, INT4 und NVFP4. NVIDIA-Dokumentation zu quantisierten Datentypen Damit ist „FP4“ oder „MXFP4“ kein universeller Speicherfaktor, der auf jedes Modell, jede Engine und jede GPU identisch angewendet werden kann.

Für Kimi K3 wird in der veröffentlichten Modellkarte eine Konfiguration mit MXFP4-Gewichten und MXFP8-Aktivierungen genannt. Das ist ein konkreter Modellstand, aber keine Erlaubnis, die gesamte Modellgröße durch eine feste Zahl zu teilen und daraus einen Produktionsknoten abzuleiten.

Die praktische Regel lautet:

1. Zuerst die tatsächlich veröffentlichte Gewichtsdatei und Quantisierungskonfiguration prüfen.
2. Danach feststellen, welche Schichten von der Quantisierung ausgenommen sind.
3. Anschließend die Ladeweise der gewählten Engine testen.
4. Erst dann eine Speicherreserve für Laufzeit und Parallelität hinzufügen.

Eine einfache Speichergleichung bleibt nützlich, wenn ihre Grenzen klar markiert werden:

Gewichts-Baseline ≈ Gesamtparameter × effektive Bytes pro Parameter

Die effektive Bytezahl muss aus dem konkreten Format, den Metadaten und der Ladeweise abgeleitet werden. Sie darf nicht allein aus dem Namen des Quantisierungsformats stammen.

Modellvariable	Wofür sie verwendet wird	Was sie nicht beantwortet
Gesamtparameter	Abschätzung des potenziellen Gewichtsspeichers	Ob die Gewichte effizient verteilt werden können
Aktivierungsparameter	Rechenarbeit pro Token und Expertentraffic	Ob alle übrigen Gewichte geladen werden müssen
Kontextlänge	Dimensionierung des KV-Cache	Ob die Zielauslastung stabil bleibt
Anzahl paralleler Sequenzen	Laufzeit- und Cache-Planung	Ob die Kommunikation zwischen Knoten genügt
Quantisierungsformat	Reduktion der Gewichtsdaten	Ob jede Schicht und jede Engine das Format unterstützt

Wenn die Gewichte passen, aber der Dienst trotzdem nicht startet

Ein erfolgreicher Gewichtsdownload beweist noch keinen erfolgreichen Inferenzdienst. Der Prozess kann nach dem Laden der Gewichte scheitern, weil der KV-Cache, Aktivierungspuffer oder Kommunikationsbereiche nicht mehr in den verfügbaren Speicher passen.

Der KV-Cache wächst mit mehreren Faktoren:

• Anzahl der gleichzeitig laufenden Sequenzen,
• Eingabelänge,
• generierter Ausgabelänge,
• Attention-Architektur,
• Datentyp des Caches,
• Cache-Management der Engine,
• Prefix- oder Prompt-Caching,
• Batch- und Scheduling-Strategie.

Ein Test mit kurzer Eingabe und einer einzelnen Antwort ist deshalb nur ein Starttest. Für ein Agent-System müssen auch lange Werkzeugketten, wiederholte Kontextübergaben und parallele Sitzungen simuliert werden. Bei Kimi K3 ist das besonders relevant, weil die Modellkarte ein Kontextfenster von 1.048.576 Token nennt. Das bedeutet nicht, dass ein Team dieses Maximum wirtschaftlich oder mit stabiler Latenz ausnutzen kann. Es bedeutet lediglich, dass die Laufzeitplanung den maximal unterstützten Kontext berücksichtigen muss.

Für DeepSeek V4 nennt die offizielle Dokumentation ebenfalls ein Kontextfenster von 1 Million Token. Zusätzlich werden unterschiedliche Parallelitätsgrenzen für Flash und Pro angegeben. Auch diese API-Grenzen sind kein Ersatz für eine lokale Speicher- und Durchsatzmessung. Sie zeigen aber, dass Kontext und Gleichzeitigkeit separat vom Parameterbegriff betrachtet werden müssen.

Erster Schritt: Die Last vor der Hardware festschreiben

Vor jedem Knotenvergleich müssen die folgenden Werte festgelegt werden:

• typische Eingabelänge,
• maximale Eingabelänge,
• typische Ausgabelänge,
• maximale Ausgabelänge,
• parallele Agent-Sitzungen,
• Werkzeugaufrufe pro Sitzung,
• Anteil wiederverwendeter Präfixe,
• Spitzenlast und Fehlerrate,
• akzeptable Zeit bis zum ersten Token,
• erforderlicher stabiler Token-Durchsatz.

Ohne diese Lastdefinition ist „passt in den Speicher“ eine unvollständige Aussage.

Zweiter Schritt: Startpfad und Spitzenwert getrennt messen

Beim Start können Gewichte vorübergehend mehrfach oder in Zwischenformaten vorliegen. Deshalb muss die Messung mindestens zwei Werte unterscheiden:

• Speicher beim Laden und Initialisieren,
• Speicher unter dem definierten Ziel-Workload.

Ein System, das nur den ruhigen Zustand nach dem Start betrachtet, kann beim ersten echten Batch ausfallen.

Dritter Schritt: Engine und Format gemeinsam testen

Die Modellkarte kann eine Engine empfehlen, während eine andere Engine zwar startet, aber wichtige Funktionen nicht unterstützt. Für Kimi K3 werden in der Modellkarte unter anderem vLLM, SGLang und TokenSpeed als empfohlene Inferenzpfade genannt. Das ist ein Hinweis auf den vorgesehenen Softwarepfad, aber keine Garantie für jede Version, GPU-Generation oder Parallelisierung.

Die offizielle vLLM-Dokumentation zur verteilten Bereitstellung von MoE-Modellen beschreibt, dass bei solchen Modellen Datenparallelität für Attention-Schichten und Experten- oder Tensorparallelität für Expertenschichten kombiniert werden können. Sie weist außerdem auf die notwendige Synchronisation der Expertenschichten während des Vorwärtslaufs hin. Damit wird deutlich, warum die Wahl der Parallelisierungsstrategie nicht nur eine Frage des verfügbaren Speichers ist.

MLOps-Teams sollten deshalb nicht nur den Startbefehl speichern, sondern auch:

• Engine-Version,
• Treiberversion,
• CUDA- oder Metal-Umgebung,
• Quantisierungskonfiguration,
• Tensor- und Expert-Parallelität,
• maximale Cache-Größe,
• Abbruchmeldung bei Überlast.

Vierter Schritt: Fehlerpfade absichtlich auslösen

Ein produktionsnaher Test beendet sich nicht beim ersten erfolgreichen Chat. Er erhöht schrittweise Kontext und Parallelität, startet einen zweiten Prozess, trennt einen Knoten und wiederholt eine fehlgeschlagene Anfrage. Besonders bei Agent-Systemen müssen auch unvollständige Werkzeugantworten und Wiederholungen enthalten sein.

Mehr Knoten lösen den Speicherfehler, aber nicht automatisch das Durchsatzproblem

Die Addition des GPU-Speichers mehrerer Knoten ist keine Leistungsprognose. Bei Expert-Parallelität werden Token zwischen Experten und Knoten verschoben. Der Router entscheidet, welcher Expertenteil einen Token verarbeitet. Daraus entstehen Kommunikations- und Synchronisationskosten, die nicht aus der reinen Speichersumme hervorgehen.

Architekturentscheidung	Möglicher Vorteil	Neuer Engpass
Mehr Tensor-Parallelität	Größere Schichten können verteilt werden	Synchronisation bei Matrixoperationen
Expert-Parallelität	Expertengewichte lassen sich auf Knoten verteilen	Expert-Routing und All-to-All-Kommunikation
CPU- oder SSD-Offloading	Niedrigerer GPU-Bedarf	Übertragungszeit und ungleichmäßige Latenz
Größerer KV-Cache	Mehr parallele oder längere Sitzungen	Speicherwachstum und Scheduling-Druck
Mehr Replikate	Bessere Ausfallsicherheit und Spitzenlastabdeckung	Doppelte Gewichtsrückhaltung und höhere Betriebskosten

Die vLLM-Dokumentation beschreibt Expert-Parallelität als Verfahren, bei dem Experten auf mehrere Geräte verteilt werden. Die Token werden dabei über eine All-to-All-Kommunikation an die zuständigen Geräte geschickt und anschließend wieder zusammengeführt. vLLM-Dokumentation zur Expert-Parallelität Das ist ein technischer Grund dafür, dass mehr Knoten zwar den Speicherplatz erweitern, aber gleichzeitig neue Netzwerk- und Synchronisationsanforderungen schaffen.

Der gleiche Effekt zeigt sich beim Speicherzugriff. Ein Modell kann formal verteilt geladen werden, während der Dienst bei einer realistischen Agent-Last durch Netzwerklatenz, Speicherdurchsatz oder Synchronisationswartezeiten unbrauchbar wird.

Die Konsequenz ist eine klare Trennung:

• Startbarkeit: Der Prozess lädt und beantwortet mindestens eine Anfrage.
• Stabiler Durchsatz: Der Dienst hält die Zielrate über einen längeren Testzeitraum.
• Fehlererholung: Der Dienst kommt nach Knoten-, Prozess- oder Netzwerkfehlern kontrolliert zurück.
• Betriebsfähigkeit: Monitoring, Zugriffsschutz, Datenaufbewahrung und Zuständigkeiten sind geregelt.

Ein Selbsthosting-Vorhaben darf erst als belastbar gelten, wenn alle vier Ebenen nachgewiesen sind.

Die kurze Demo durch eine echte Agent-Last ersetzen

Der typische Fehlversuch entsteht in einer Notebook-Sitzung: Ein kurzer Prompt wird gesendet, eine Antwort kommt zurück, und die Hardware wird als geeignet eingestuft. Für ein AI-Agent-System ist das eine zu kleine Stichprobe.

Der Test sollte mindestens diese Phasen enthalten:

1. Baseline: Modellstart ohne Nutzerlast, inklusive Ladezeit und Leerlaufspeicher.
2. Einzelsitzung: Typischer Prompt mit realer Werkzeugkette.
3. Langer Kontext: Repräsentativer Verlauf mit Dokumenten, Werkzeugresultaten und Zwischenentscheidungen.
4. Parallellast: Mehrere Sitzungen mit gemischten Eingabe- und Ausgabelängen.
5. Spitzenlast: Kurzer Zeitraum mit der erwarteten Höchstzahl gleichzeitiger Aufgaben.
6. Fehlerwiederholung: Erzwungener Timeout, abgebrochener Werkzeugaufruf und erneuter Versuch.
7. Erholung: Neustart eines Workers oder Ausfall eines Knotens, sofern die Topologie dies vorsieht.

Aufgezeichnet werden sollten mindestens:

• Zeit bis zum ersten Token,
• stabiler Token-Durchsatz,
• maximaler GPU- und Arbeitsspeicher,
• Anzahl verworfener oder abgebrochener Anfragen,
• Kommunikationsauslastung,
• Wiederanlaufzeit,
• Datenverlust oder unvollständige Agent-Zustände.

Für Datenschutz und Nachvollziehbarkeit müssen Testdaten außerdem kontrolliert werden. Personenbezogene Inhalte gehören nicht ungeschützt in einen externen Testcluster. Bei Nutzung eines Dienstes sollten Aufbewahrung, Zugriff und Auftragsverarbeitung geprüft werden. Die Datenschutzhinweise von ProxyMac sind dafür ein möglicher Ausgangspunkt, ersetzen aber keine eigene Prüfung der gesamten Modell- und Protokollkette.

Die klare Abbruchlinie für das Selbsthosting

Ein Team sollte das Projekt stoppen oder auf API beziehungsweise zeitlich begrenzte Cluster zurückfallen, sobald eine der folgenden Bedingungen erfüllt ist:

• Die Gewichte passen nur ohne den für die Ziel-Parallelität erforderlichen KV-Cache.
• Der Start gelingt nur mit einer nicht dokumentierten oder nicht reproduzierbaren Community-Konfiguration.
• Die realistische Agent-Last überschreitet den Speicher, obwohl der Einzelprompt funktioniert.
• Mehr Knoten reduzieren zwar den Speicherdruck, erreichen aber nicht den erforderlichen stabilen Durchsatz.
• Die Fehlererholung ist nicht messbar oder hängt von manuellen Eingriffen einer Einzelperson ab.
• Lizenz, Datenhaltung oder Verantwortlichkeit sind für den geplanten Einsatz nicht geklärt.
• Die Auslastung ist so niedrig, dass ein dauerhaft reservierter Cluster überwiegend ungenutzt bleibt.
• Das Team kann die Modell-, Engine- und Treiberversionen nicht gemeinsam reproduzieren.

Die wichtigste Abbruchregel lautet:

Keine vollständige Speicherbilanz + kein stabiler Ziel-Workload
= kein langfristiger Selbsthosting-Entscheid

Eine API ist nicht automatisch die schlechtere technische Lösung. Sie kann für schwankende Last, frühe Produktvalidierung und seltene Agent-Aufgaben wirtschaftlich und operativ sinnvoller sein. Ein zeitlich begrenztes Cluster eignet sich, wenn die reale Last zunächst gemessen werden muss, aber keine dauerhafte Infrastrukturentscheidung gerechtfertigt ist.

Für eine nachvollziehbare Abnahme kann folgende Checkliste verwendet werden:

• [ ] Offizielle Modellkarte, Gewichtsquelle und Lizenz wurden geprüft.
• [ ] Gesamtparameter und Aktivierungsparameter wurden getrennt dokumentiert.
• [ ] Quantisierungsformat, Blockskalierung und ausgenommene Schichten sind bekannt.
• [ ] Ladepeak und Leerlaufspeicher wurden separat gemessen.
• [ ] KV-Cache wurde für Zielkontext und Zielparallelität dimensioniert.
• [ ] Engine-, Treiber- und Laufzeitversion sind reproduzierbar festgehalten.
• [ ] Einzelsitzung, lange Sitzung und parallele Agent-Last wurden getestet.
• [ ] Zeit bis zum ersten Token und stabiler Durchsatz wurden getrennt erfasst.
• [ ] Knoten-, Prozess- und Netzwerkfehler wurden mindestens einmal simuliert.
• [ ] Datenschutz, Protokollierung, Zugriff und Lizenzverantwortung sind geklärt.
• [ ] Eine Rückfalloption auf API oder zeitlich begrenzte Infrastruktur ist vorbereitet.

Wer diese Punkte nicht abhaken kann, sollte nicht aus dem niedrigen Aktivierungswert eine kleine Zielplattform ableiten.

Selbsthosting, API oder ProxyMac: Welche Lösung passt zur Situation?

Für eine kurzfristige Validierung ist die aktuelle Alternative oft ein API-Zugang: kein Gewichtsmanagement, keine Expert-Verteilung und kein eigener Wiederanlaufbetrieb. Die Nachteile liegen in variablen Nutzungskosten, Anbieterabhängigkeit, möglichen Rate-Limits und geringerer Kontrolle über Laufzeit und Datenpfad.

Ein eigenes Multi-Node-Cluster bietet dagegen Kontrolle über Modellversion, Netzwerk und Ausführungsumgebung. Es bindet aber Kapital, benötigt dauerhaftes MLOps-Know-how und muss auch außerhalb der eigentlichen Inferenz betrieben werden. Bei unregelmäßiger Agent-Last werden reservierte Ressourcen schnell zum Leerlaufposten.

ProxyMac ist in diesem Entscheidungsraum vor allem als kontrollierte Mac-Umgebung für Entwicklungs-, Steuerungs- und Validierungsaufgaben interessant. Die Gewichtsschicht eines Billionen-Parameter-Modells sollte dabei nicht mit der Mac-Steuerung verwechselt werden: Für schwere Modellgewichte bleibt ein geeigneter GPU-Cluster oder ein API-Dienst erforderlich. Ein Mac kann als Kontrollinstanz für Workflows, Tests, Zugriffslogik und Entwicklerwerkzeuge sinnvoll sein, während die Gewichte in einer dafür ausgelegten Umgebung laufen.

Vor einer solchen Trennung sollten Teams die Zugriffswege, Protokollierung und Zuständigkeiten prüfen. Hinweise zur Nutzung und zum technischen Ablauf finden sich in der ProxyMac-Hilfe. Für automatisierte Abläufe kann zusätzlich die ProxyMac-Konsole relevant sein.

Der entscheidende Unterschied zur vorschnellen Eigenanschaffung ist die Umkehrung der Reihenfolge: Nicht zuerst Hardware kaufen und danach eine Last suchen, sondern zuerst Modellversion, Lastprofil und Speicherpfad beweisen. Wenn dieser Nachweis fehlt, ist eine zeitlich begrenzte Clusterprüfung oder API-Nutzung die vernünftigere Zwischenstufe. Wenn eine Mac-Arbeitsumgebung für die Steuerung, Entwicklung oder reproduzierbare Tests gebraucht wird, kann das Mieten über ProxyMac den Einstieg vereinfachen, ohne die Kosten und die Verantwortung eines dauerhaft reservierten Eigenclusters zu übernehmen.

Weiterlesen

• Kimi K3 nach einer Woche: Wann lohnt sich Self-Hosting wirklich?
• LLM per API oder lokal betreiben: Entscheidungshilfe für Kosten und Infrastruktur