Kimi K3 selbst hosten: VRAM, KV-Cache und Hardware

Voraussetzungen für das Self-Hosting von Kimi K3

Self-Hosting von Kimi K3 erfordert Platz für 2.8 Billionen Parameter. Moonshot hat die Open Weights im Format MXFP4 veröffentlicht. Das entspricht ungefähr einem halben Byte pro Gewicht. Allein die Weights benötigen damit etwa 1.4 TB, bevor auch nur ein Token für den Cache reserviert ist. Kein heute erhältlicher Accelerator kann diese Daten allein aufnehmen. K3 ist ein Multi-Node-Modell. Für einen einzelnen Server lautet die Antwort daher: nein.

Das ist das Ergebnis. Im Folgenden wird die Berechnung dahinter erläutert. Diese Berechnung können Sie bei der nächsten Version wiederverwenden. Mehrere Infrastruktur-Anbieter veröffentlichten in den Wochen nach der Ankündigung vom 17. July 2026 Bereitstellungsanleitungen für K3. Jede davon setzte voraus, dass bereits ein Cluster vorhanden ist. Diese Seite geht vom anderen Ende aus: Welche Kosten entstehen, was können Sie stattdessen ausführen, und woran erkennen Sie, welcher dieser beiden Fälle auf Sie zutrifft?

Die Gesamtzahl der Parameter und die Zahl der aktiven Parameter sind nicht identisch

K3 ist ein Mixture-of-Experts-Modell. MoE (Mixture of Experts) teilt das Netzwerk in viele Teilnetzwerke auf und lässt einen Router pro Token einige davon auswählen. Die Model Card nennt 2.8T Gesamtparameter und 104B aktivierte Parameter pro Token. Dabei werden 896 geroutete Experten verwendet, von denen für ein bestimmtes Token 16 aktiviert werden, verteilt auf 93 Layer.

Diese beiden Parameterzahlen beantworten unterschiedliche Fragen. Sie zu verwechseln, ist der häufigste Fehler in jedem Thread nach dem Muster „Kann ich das ausführen?“.

Die aktiven Parameter bestimmen den Rechenaufwand. Ein Token wird mit ungefähr 104B Parametern verarbeitet. Daher ähnelt der erwartete Durchsatz eher dem eines dichten 104B-Modells als dem eines 2.8T-Modells. Genau deshalb werden MoE-Modelle eingesetzt.

Die Gesamtzahl der Parameter bestimmt den Speicherbedarf. Der Router kann für jedes Token jeden Experten auswählen. Deshalb müssen alle Experten resident sein, bevor die erste Anfrage eintrifft. Sie können nicht 104B Parameter im VRAM halten und den Rest bei Bedarf nachladen. Das Nachladen müsste innerhalb von Mikrosekunden abgeschlossen sein, während eine PCIe-Verbindung nur einige Dutzend Gigabyte pro Sekunde übertragen kann. Versuche gibt es trotzdem. Werden Experten von NVMe gestreamt, sinkt die Ausgabe eines Modells, das eigentlich Dutzende Tokens pro Sekunde erzeugen sollte, auf ein Token alle paar Sekunden.

Die Berechnung ist daher vergleichsweise günstig, die Speicherung jedoch teuer. Dimensionieren Sie die Hardware anhand von 2.8T. Richten Sie Ihre Erwartungen an die Geschwindigkeit anhand von 104B aus.

Bytes pro Gewicht und woher die Terabytes kommen

Parameteranzahl mal Bytes pro Gewicht. Für die Gewichte ist das die vollständige Formel.

[
  {
    "label": "bf16",
    "bytes_per_weight": 2,
    "weights_tb": 5.6
  },
  {
    "label": "fp8",
    "bytes_per_weight": 1,
    "weights_tb": 2.8
  },
  {
    "label": "4-bit (MXFP4, as shipped)",
    "bytes_per_weight": 0.5,
    "weights_tb": 1.4
  },
  {
    "label": "2-bit",
    "bytes_per_weight": 0.25,
    "weights_tb": 0.7
  }
]

K3 wurde quantisierungsbewusst trainiert und mit MXFP4-Gewichten sowie MXFP8-Aktivierungen veröffentlicht. Deshalb ist die 4-Bit-Zeile die relevante. Die darüberstehenden Zeilen dienen dem Vergleich: Mit bf16 würde dasselbe Modell 5.6 TB benötigen. MXFP4 speichert außerdem für jeden Block aus 32 Gewichten eine gemeinsame 8-Bit-Skalierung. Das erhöht den Bedarf um etwa 6 Prozent. Das veröffentlichte Repository liegt daher eher bei 1.5 TB als bei exakt 1.4 TB.

Damit entfällt der übliche Ausweg. Eine zusätzliche Quantisierung hilft hier nicht, weil der veröffentlichte Checkpoint bereits 4-Bit verwendet. Eine Reduzierung auf 2-Bit würde den Speicherbedarf der Gewichte auf 0.7 TB senken. Dafür würde Genauigkeit verloren gehen, die für diesen Checkpoint niemand gemessen hat. Der Bedarf läge weiterhin deutlich über dem einer einzelnen Karte.

Wie viele GPUs benötigt Kimi K3?

[
  {
    "config": "H100 80GB",
    "hbm_per_gpu_gb": 80,
    "gpus_for_weights": 18
  },
  {
    "config": "H200 141GB",
    "hbm_per_gpu_gb": 141,
    "gpus_for_weights": 10
  },
  {
    "config": "B200 192GB",
    "hbm_per_gpu_gb": 192,
    "gpus_for_weights": 8
  },
  {
    "config": "GB300 288GB",
    "hbm_per_gpu_gb": 288,
    "gpus_for_weights": 5
  }
]

Betrachten Sie diese Werte als Untergrenze, nicht als Zielwert. Sie berücksichtigen nur die Gewichte: keinen KV-Cache, keine Aktivierungspuffer, keine Fragmentierung des Allokators und keinen Spielraum für eine zweite gleichzeitig ausgeführte Anfrage. Außerdem wird eine parallele Aufteilung vorausgesetzt, bei der die Anteile gleichmäßig verteilt werden. Das ist bei 93 Layern und 896 Experten nicht immer möglich.

Die veröffentlichten Empfehlungen liegen deutlich über dieser Untergrenze. Im August 2026 empfiehlt Moonshot einen Supernode mit mindestens 64 Beschleunigern. Das SGLang-Kochbuch enthält eine H100-Konfiguration aus vier Nodes mit jeweils 8 GPUs, also 32 GPUs und insgesamt 2,560 GB Speicher. Dem steht eine Untergrenze von 18 Karten gegenüber. Diese Differenz ist kein unnötiger Aufwand. Sie wird für den KV-Cache, den Aktivierungsspeicher und den Spielraum benötigt, mit dem der Server viele Anfragen gleichzeitig bündeln kann. Selbst die günstigste Zeile, 5 Karten der GB300-Klasse, beschreibt ein System, das die meisten Anbieter nicht als einzelne SKU vermieten.

Der KV-Cache ist der Teil, der viele überrascht

Die Gewichte sind ein fixer Kostenfaktor. Der KV-Cache (Key-Value-Cache) ist das nicht: Er wächst mit der Kontextlänge und zusätzlich mit jedem gleichzeitig verbundenen Benutzer. Für gewöhnliche Attention lautet die Formel bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element. Anschließend multiplizieren Sie mit der Kontextlänge und der Anzahl gleichzeitiger Benutzer.

Hier ist ein durchgerechnetes Beispiel, und es ist nur ein Beispiel: 64 Layer, 8 KV-Heads, eine Head-Dimension von 128 und fp8. Das ergibt 2 64 8 128 1 = 131,072 Bytes, also 128 KiB pro Token.

[
  {
    "label": "8k context",
    "kv_gib_per_user": 1
  },
  {
    "label": "32k context",
    "kv_gib_per_user": 4
  },
  {
    "label": "128k context",
    "kv_gib_per_user": 16
  },
  {
    "label": "1M context",
    "kv_gib_per_user": 128
  }
]

Ein Benutzer mit einem Kontext von 128k benötigt 16 GiB. Ein Benutzer mit dem vollständigen Kontext von einer Million benötigt 128 GiB. Das ist mehr, als jede einzelne Karte für eine einzige Unterhaltung aufnehmen kann.

K3 verwendet keine gewöhnliche Attention. Genau deshalb ist der letzte Wert relevant. Die 93 Layer bestehen aus 69 KDA-Layern (Kimi Delta Attention) und 24 Gated-MLA-Layern (Multi-Head Latent Attention). KDA verwendet einen rekurrenten Zustand mit fester Größe statt eines Caches, der mit jedem Token wächst. MLA komprimiert Key und Value in einen einzelnen Latent-Vektor mit niedrigem Rang. Dadurch liegen die tatsächlichen Kosten pro Token deutlich unter denen des durchgerechneten Beispiels. Moonshot hat die Dimensionen des Latent-Vektors nicht veröffentlicht. Deshalb nenne ich für K3 keinen Wert pro Benutzer. Messen Sie stattdessen Ihre Umgebung: Starten Sie den Server mit einem kleinen --max-model-len, überwachen Sie den Speicher mit nvidia-smi und erhöhen Sie das Limit, bis die Allokation fehlschlägt.

Die grundsätzliche Vorgehensweise bleibt auch bei der nächsten Version gültig. Wenn ein Modell einen Kontext von einer Million Tokens angibt, aber nichts über sein Attention-Design sagt, sollten Sie davon ausgehen, dass der Cache die begrenzende Ressource ist, bis das Gegenteil nachgewiesen wurde.

Tier 1: Cluster stundenweise mieten

Dies ist die einzige Tier, auf der K3 selbst ausgeführt wird. Sie kaufen die Hardware nicht. Sie mieten sie für die benötigten Stunden und stoppen sie anschließend.

[
  {
    "label": "1 GPU, always on",
    "gpu_hours": 720,
    "usd_cost": "1,800"
  },
  {
    "label": "8 GPUs, 4 hours a day",
    "gpu_hours": 960,
    "usd_cost": "2,400"
  },
  {
    "label": "8 GPUs, always on",
    "gpu_hours": 5760,
    "usd_cost": "14,400"
  },
  {
    "label": "32 GPUs, always on",
    "gpu_hours": 23040,
    "usd_cost": "57,600"
  }
]

Der Preis ist eine Annahme und kein Angebot. Die Listenpreise für On-Demand-Beschleuniger in Rechenzentren lagen bis 2026 ungefähr zwischen 2 und 5 USD pro GPU-Stunde. Reservierte Kapazität ist günstiger. Verwenden Sie den tatsächlichen Preis Ihres Providers und führen Sie die Multiplikation erneut aus: GPUs mal Stunden mal Preis. Die Grafik soll das Verhältnis zeigen. Ein 8-GPU-Knoten, der täglich vier Stunden betrieben wird, kostet 2,400 USD pro Monat. Eine für SGLang ausgelegte Konfiguration mit 32 GPUs kostet im Dauerbetrieb 57,600 USD.

Beide gängigen Server veröffentlichen auf der Modellkarte einen Startbefehl.

pip install vllm
vllm serve "moonshotai/Kimi-K3"

pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000

Keiner der beiden unveränderten Befehle wird auf einem echten Cluster ausgeführt. Fügen Sie die zu Ihrer Hardware passenden Parallelismus-Flags hinzu: SGLang verwendet --tp-size für Tensor-Parallelismus und --ep-size für Expert-Parallelismus. Das Produkt aus beiden Werten muss der tatsächlich verfügbaren GPU-Anzahl entsprechen.

Prüfen Sie, ob der Server gestartet ist, bevor Sie echten Netzwerkverkehr senden:

curl http://127.0.0.1:30000/v1/models

Ein funktionierender Server antwortet mit einem JSON-Objekt, das die Modell-ID auflistet. Connection refused bedeutet, dass der Prozess noch Gewichte lädt oder bereits beendet wurde. Lesen Sie daher das Server-Log, bevor Sie den Versuch wiederholen.

Der häufigste Fehler am ersten Tag ist eine Runtime, die älter als das Modell ist. K3 wurde mit KDA und einer neuen MoE-Schicht veröffentlicht, die in den stabilen vLLM- und SGLang-Releases zum Start noch nicht enthalten waren. Das äußert sich darin, dass der Server während des Starts mit einer Zeile der Form Model architectures [...] are not supported for now beendet wird. Keine Konfigurationsänderung behebt diesen Fehler, weil der Code zum Ausführen dieser Schichten in Ihrem Build fehlt. Installieren Sie die auf der Modellkarte angegebene Nightly-Version oder warten Sie auf das Release, das diese Unterstützung enthält.

Ein Kostenpunkt wird häufig übersehen. Die Abrechnung beginnt, sobald die Instanz startet, und nicht erst, wenn das Modell bereit ist. Ein Download von 1.5 TB mit 1 GB/s dauert ungefähr 25 Minuten Clusterzeit, bevor das erste Token erzeugt wird. Speichern Sie die Gewichte auf einem Volume, das die Lebensdauer der Instanz übersteht. Beim zweiten Start ist der Server dadurch innerhalb weniger Minuten bereit.

Tier 2: Ein kleineres Modell auf einem Beschleuniger ausführen

In dieser Stufe führen Sie K3 nicht aus. Sagen Sie sich das vor dem Start ausdrücklich, denn die meisten Diskussionen über „K3 lokal ausführen“ enden hier, ohne das anzuerkennen.

Für die passende Modellgröße gilt dieselbe Formel in kleinerem Maßstab: Die Anzahl der Parameter multipliziert mit den Bytes pro Gewicht, plus KV-Cache, plus etwa 2 GB Laufzeit-Overhead, muss in den VRAM passen. Bei 4-Bit entspricht das ungefähr einem halben Byte pro Parameter. Daraus ergeben sich passende Kombinationen:

• 16-GB-Karte: ein 7B-Modell mit 4-Bit und ausreichend Platz für einen langen Kontext
• 24-GB-Karte: ein 14B-Modell mit 4-Bit
• 48-GB-Karte: ein 32B-Modell mit 4-Bit
• 80-GB-Karte: ein 70B-Modell mit 4-Bit oder ein MoE-Modell der 30B-Klasse mit 8-Bit

Ollama ist der kürzeste Weg zu einem funktionierenden Server auf einem VPS mit angeschlossenem GPU-Beschleuniger:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ollama run lädt das Modell bei der ersten Verwendung herunter und zeigt anschließend eine Eingabeaufforderung an. Ein nicht vorhandener Tag führt zu Error: model "..." not found. Übernehmen Sie die Tags daher von der Bibliotheksseite, statt sie aus dem Gedächtnis einzugeben. Die vollständige Anleitung einschließlich der systemd-Unit und des Fernzugriffs finden Sie unter Ollama auf einem VPS ausführen.

llama.cpp bietet Ihnen mehr Kontrolle über Quantisierung und Offload:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080

-ngl 99 fordert an, jede Schicht auf der GPU auszuführen. Prüfen Sie das Ladeprotokoll. Es zeigt an, wie viele Schichten ausgelagert wurden. Schichten, die in den Systemspeicher ausgelagert werden, laufen mit der Bandbreite des RAM statt mit der Bandbreite des HBM. Sobald das Modell nicht mehr vollständig in den Speicher passt, sinkt die Generierungsgeschwindigkeit daher um eine Größenordnung. Die Unterschiede zwischen den beiden Tools werden unter Ollama und llama.cpp im direkten Vergleich erläutert.

Tier 3: gehostete API, selbst gehostete Orchestrierung

[
  {
    "label": "Input, cache hit",
    "usd_per_million_tokens": "0.30"
  },
  {
    "label": "Input, cache miss",
    "usd_per_million_tokens": "3.00"
  },
  {
    "label": "Output",
    "usd_per_million_tokens": "15.00"
  }
]

Der Endpunkt ist mit OpenAI kompatibel. Ein vorhandener Client funktioniert daher, sobald Sie die Basis-URL ändern.

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'

Ein gültiger Schlüssel liefert ein JSON-Objekt mit einem choices-Array. Ein 401 bedeutet, dass der Schlüssel falsch ist oder das Präfix Bearer fehlt. Ein Fehler wegen eines nicht gefundenen Modells bedeutet meistens, dass sich die ID geändert hat, weil Anbieter IDs zwischen Checkpoints ausmustern.

Nun zur Gewinnschwelle mit dem oben angenommenen Mietpreis. Ein dauerhaft aktiver Knoten mit 8 GPUs kostet 14,400 USD pro Monat. Bei 15.00 USD pro 1 Million Ausgabetokens kauft derselbe Betrag über die API etwa 960 Millionen Ausgabetokens. Damit sich der Betrieb nach Kosten lohnt, müssen Sie pro Monat fast 1 Milliarde Ausgabetokens erzeugen, also ungefähr 30 Millionen pro Tag. Außerdem muss der Cluster durchgehend ausgelastet sein, weil ungenutzte GPUs genauso abgerechnet werden wie ausgelastete GPUs. Prompt-intensive Agent-Workloads verschieben diese Grenze noch weiter: Wiederholter Kontext wird zum Cache-Hit-Preis von 0.30 USD pro 1 Million Tokens abgerechnet und nicht zum Cache-Miss-Preis von 3.00 USD.

In dieser Stufe hosten Sie alles rund um das Modell selbst: ein Gateway, das den API-Schlüssel verwahrt, damit er nie einen Client erreicht, Logs für Anfragen und Antworten, Wiederholungen, Ratenbegrenzungen und Budgets pro Benutzer. Das läuft auf einem kleinen VPS ganz ohne GPU. Dieselbe Aufteilung gilt für geschlossene Gewichte. Claude selbst zu hosten ist auf Modellebene nicht möglich; Sie besitzen nur die Orchestrierung.

Welche Serving-Stacks zu welcher Ebene gehören

Server der Klassen vLLM und SGLang gehören zu Ebene 1. Sie sind dafür ausgelegt, viele Anfragen gleichzeitig zu bedienen, mit Continuous Batching und einem paginierten KV-Cache sowie Tensor- und Expert-Parallelismus über mehrere Nodes hinweg. Sie setzen Beschleuniger in Rechenzentren und eine schnelle Verbindung zwischen ihnen voraus. Auf einer einzelnen Consumer-GPU sind sie aufwendiger zu installieren und bieten Ihnen nur wenige Vorteile, die Sie tatsächlich bemerken würden.

llama.cpp und Ollama gehören zu Ebene 2. Sie zielen auf eine einzelne Maschine, GGUF-Quantisierung, CPU-Offload, wenn das Modell nicht in den GPU-Speicher passt, und eine geringe Parallelität. llama.cpp kann ein sehr großes MoE technisch laden, indem die meisten Layer im Arbeitsspeicher des Systems gehalten werden. Bei einem 2.8T-Modell dauert die Verarbeitung auf diesem Weg mehrere Sekunden pro Token. Damit ist lediglich nachgewiesen, dass die Datei geparst werden kann. Es handelt sich nicht um einen Dienst, den Sie Benutzern bereitstellen können. Der vollständige Vergleich steht unter Ollama im Vergleich zu vLLM. Das ändert sich durch das Modell nicht: Entscheidend ist immer, ob Sie viele Benutzer auf gemeinsam genutzter Hardware bedienen oder einen Benutzer auf Ihrer eigenen Hardware.

Die vier Zahlen, die diesen Prüfpunkt überdauern

1. Die Gesamtzahl der Parameter multipliziert mit der Byte-Anzahl pro Gewicht ergibt den unteren Speicherbedarf. Darunter läuft nichts, und kein Quantisierungstrick verändert ihn wesentlich, sobald das Release bereits 4-bit verwendet.
2. Die aktiven Parameter bestimmen die Durchsatzklasse. Ein 2.8T-MoE-Modell mit 104B aktiven Parametern rechnet wie ein 104B-Modell.
3. Der KV-Cache pro Token multipliziert mit der Kontextlänge und der Anzahl gleichzeitiger Anfragen ergibt die Kosten, die weiter wachsen, nachdem Sie den Speicher für die Gewichte bereits bezahlt haben.
4. Tokens pro Sekunde und Dollar ist die einzige Zahl, die eine Leistungsklasse festlegt. Alles darüber fließt in diese Zahl ein.

Wenden Sie diese vier Werte auf jedes Release an. Dann erhalten Sie die richtige Antwort, bevor Sie eine Herstellerdokumentation öffnen. Datieren Sie anschließend jede notierte Zahl. Preise und Listen der unterstützten Architekturen änderten sich beide innerhalb der zwei Wochen nach dem Start von K3. Jede Zahl auf dieser Seite wurde im Juli 2026 veröffentlicht.

FAQ

Kann ich Kimi K3 auf einer einzelnen GPU ausführen?

Nein. Die Gewichte sind bei der von Moonshot ausgelieferten MXFP4-Präzision etwa 1.4 TB groß, und der größte einzelne verfügbare Beschleuniger bietet 288 GB. Ein MoE-Modell kann seine inaktiven Experten nicht mit einer nutzbaren Geschwindigkeit von der Festplatte nachladen, weil der Router für jedes Token jeden Experten auswählen kann und ein PCIe-Abruf deutlich länger dauert, als das Token-Zeitbudget erlaubt. Die kleinste sinnvolle K3-Bereitstellung ist ein Node mit mehreren GPUs. Veröffentlichten Rezepten zufolge werden 32 Beschleuniger oder mehr verwendet.

Wie viel VRAM benötigt Kimi K3?

Planen Sie allein für die Gewichte zunächst 1.4 TB ein. Das entspricht 18 H100-Karten mit 80 GB oder 5 Karten der GB300-Klasse. Hinzu kommen der KV-Cache und der Speicher für Aktivierungen. Im August 2026 empfiehlt Moonshot 64 oder mehr Beschleuniger. Das SGLang-Kochbuch veröffentlicht außerdem eine H100-Konfiguration mit 32 GPUs und insgesamt 2,560 GB. Betrachten Sie die Größe der Gewichte daher als Untergrenze und nicht als ausreichende Dimensionierung.

Passt Kimi K3 durch Quantisierung auf einen Node?

Nicht sinnvoll. Der veröffentlichte Checkpoint ist bereits ein 4-Bit-Modell mit quantisierungsbewusstem Training. Die einfache Einsparung wurde daher bereits umgesetzt. Eine weitere Halbierung auf 2 Bit reduziert die Gewichte auf 0.7 TB. Das ist weiterhin mehr als doppelt so viel wie der größte verfügbare Beschleuniger. Die Genauigkeitsverluste von 2 Bit wurden für dieses Modell außerdem nicht gemessen.

Ist das Mieten von GPUs günstiger als die Kimi-K3-API?

Nur bei einem hohen und gleichmäßigen Volumen. Bei angenommenen Kosten von 2.50 USD pro GPU-Stunde kostet ein dauerhaft betriebener Node mit 8 GPUs 14,400 USD pro Monat. Für denselben Betrag erhalten Sie zum veröffentlichten Preis von 15.00 USD pro Million ungefähr 960 Millionen Ausgabetoken. Zusätzlich bezahlen Sie Leerlaufzeiten, das Herunterladen der Gewichte und die Person, die den Cluster betreibt. Mieten Sie GPUs für Spitzenlasten stundenweise. Vergleichen Sie die Kosten anhand Ihres tatsächlich gemessenen Tokenvolumens und nicht anhand einer Schätzung.

Was bedeutet eine Anzahl von 104B aktiven Parametern für die Geschwindigkeit?

Das bedeutet, dass pro Token dieselbe Rechenmenge wie bei einem 104B-Modell anfällt. Der Durchsatz liegt daher in dieser Größenordnung und nicht in der Größenordnung von 2.8T. Für den Speicherbedarf sagt diese Zahl nichts aus: Alle 2.8T Parameter bleiben im Speicher, weil der Router für jedes Token jeden Experten aufrufen kann. Verwenden Sie die Anzahl der aktiven Parameter zur Schätzung der Tokens pro Sekunde und die Gesamtzahl der Parameter zur Dimensionierung des VRAM.