Zum Hauptinhalt springen

Kimi K3 lokal betreiben: vLLM, DSpark & die echte Hardware-Rechnung

Experte

Moonshot hat Kimi K3 – ein Mixture-of-Experts-Modell mit 2,8 Billionen Parametern – am 27. Juli 2026 als Open-Source freigegeben. Innerhalb weniger Tage überschritt der r/LocalLLaMA-Thread über „das komplette K3, das zu Hause auf einem 16× DGX-Spark-Cluster läuft" 800 Upvotes. Die Kommentare waren eine Mischung aus Bewunderung und Panik: Niemand konnte sagen, ob das ein Stunt, ein echtes Rezept oder eine Hardware-Falle war.

Diese Seite ist das Rezept. Sie deckt den einzigen heute funktionierenden lokalen Serving-Pfad (vLLM) ab, den Speculative-Decoding-Trick (DSpark), der den Durchsatz erträglich macht, die tatsächlich benötigte Mindesthardware, die exakten Serve-Befehle, die Fallstricke, die Sie beim ersten Versuch beißen, und die Break-Even-Mathematik gegenüber dem einfachen Aufruf von Moonshots oder Runpods Hosted-Endpunkt. Zum Modell selbst – Architektur, Benchmarks, Preise – siehe Kimi K3: Das größte Open-Weight-Modell der Welt.

What you'll learn
  • Die minimale funktionsfähige Hardware für vollständiges K3 kennen (1× DGX-B300-Node oder 16× B200 – heute kein Pfad darunter)
  • DSpark in einem Absatz verstehen: Block-Diffusion-Drafting, ~3,14× Speedup, 7 spekulative Tokens pro Schritt
  • K3 mit vLLM in zwei Befehlen servieren – mit den Flags, die die meisten Guides vergessen
  • Der Prefill/Decode-Asymmetrie ins Gesicht sehen: 750 Tok/s beim Lesen vs. 21 Tok/s beim Schreiben auf einem 16× DGX-Spark-Cluster
  • Die Break-Even-Mathematik machen: wann Self-Hosting $0,95/M Hosted schlägt – und wann definitiv nicht

Die Ein-Absatz-Version​

Der einzige produktionsreife Serving-Stack für K3 ist heute vLLM, das am 27. Juli 2026 Day-0-Support hinzufügte, zusammen mit einem neuartigen Speculative-Decoder namens DSpark. Mindesthardware ist ein 8×-B300-Node (oder 16× B200); ein heroisches Community-Setup lässt das volle Modell zu Hause auf einem 16× DGX Spark (GB10)-Cluster laufen, für eine Materialrechnung von ~64k$+, und liefert etwa 21 Tok/s Decode und 750 Tok/s Prefill. Hosted-Inferenz (Runpod, Moonshots eigene API) kostet 0,95 $/M Input und 4 $/M Output – für fast jedes Team ist das die richtige Antwort, außer Sie brauchen die Gewichte spezifisch on-prem.

Schritt 1 – Die Sizing-Wand verstehen​

K3 hat 2,8 Billionen Parameter. Selbst in MXFP4-Gewichtsquantisierung (das Format, das Moonshot ausliefert) sitzen die rohen Gewichte bei rund ~1,4 TB VRAM-adressierbarem Speicher, bevor Sie KV-Cache allozieren. Diese Zahl entscheidet alles andere.

What you'll learn
  • Es gibt keinen Weg, das volle K3 auf einer einzelnen Consumer-GPU, einem Mac Studio oder einer Workstation mit ein paar H100 laufen zu lassen. Das Sizing ist stufenförmig, nicht glatt.
  • Der vLLM-Guide ist eindeutig: mindestens ein 8×-B300-Node (oder ein GB300 NVL72) ist erforderlich; 16× B200 wird ebenfalls unterstützt.
  • Quantisierte Community-Destillate (Q2/Q3 oder Expert-Pruned-Varianten) werden diese Schwelle mit der Zeit senken – doch ab August 2026 laufen alle funktionierenden Rezepte in voller MXFP4-Präzision auf Frontier-Rechenzentrums-Silizium.
Hardware-ProfilRealistische NutzungCa. Capex / Opex
1× DGX B300 (8× B300)Produktion Self-Host, Einzelnode~59 $/h auf Runpod; Kaufpreis 6-stellig
16× B200Ältere Generation Self-Host~94 $/h auf Runpod
16× DGX Spark (GB10)-ClusterEnthusiast / Lab~64k–75k $ Capex + Switch + 2,3 kW Peak
Nichts darunter—Sie rufen die Hosted-API

Schritt 2 – DSpark, in einem Absatz​

DSpark ist ein Block-Diffusion-Speculative-Decoder, der zusammen mit K3 ausgeliefert wird und in vLLM nativ unterstützt wird. Statt einen spekulativen Token nach dem anderen zu entwerfen (wie MEDUSA oder EAGLE) verwendet DSpark ein 5-Schichten-Non-Causal-Attention-Rückgrat, um 7 Tokens in einem parallelen Durchgang zu entwerfen, und verifiziert sie dann blockweise gegen das K3-Ziel. Ein Low-Rank-Markov-Kopf modelliert Intra-Block-Abhängigkeit, und ein Confidence-Kopf sagt die Akzeptanz-Wahrscheinlichkeit voraus, damit der Scheduler entscheiden kann, wann Drafting sich lohnt.

Konkrete Zahlen aus dem vLLM-Blog:

  • Ohne DSpark: 118 Tok/s (TP16) bei Batch=1
  • Mit DSpark: 370 Tok/s (TP16) bei Batch=1 – ein 3,14× Speedup
  • Mittlere Akzeptanzlänge: 3,85 Tokens (über 14 Benchmarks), steigt auf 4,73 Tokens pro Schritt bei Code und fällt auf 2,61 bei kreativem Schreiben
  • Draft-Target-Kompatibilität: DSpark teilt K3s 576-Element-MLA-Latent pro Token, sodass Draft-Seiten mit dem Ziel-KV-Cache vereinheitlicht werden – kein separates Seitenformat, keine VRAM-Steuer für einen zweiten Cache

Die DSpark-Speculator-Gewichte liegen bei Inferact/Kimi-K3-DSpark auf Hugging Face; die vLLM-Flag --speculative-config zeigt auf dieses Modell.

Schritt 3 – K3 mit vLLM servieren​

Sie brauchen vLLM ≥ 0.11.1 (K3 landete in Day-0-Support in dieser Version). Zwei Befehle: einen ohne Spekulation (weniger bewegliche Teile, nützlich für einen Smoke-Test), einen mit DSpark (was Sie in Produktion tatsächlich wollen).

Smoke-Test – reines K3​

K3 ohne DSpark servieren (Baseline)

vllm serve moonshotai/Kimi-K3 \
--tensor-parallel-size 8 \
--enable-prefix-caching \
--trust-remote-code

Zwei Flags, die übersehen werden: --enable-prefix-caching ist in vLLM standardmäßig aus, und K3-Workloads (besonders agentic Coding) bauen auf Cache-Hits, um bezahlbar zu sein – lassen Sie das aus und Ihr erster Prompt wird bei jedem Turn neu verarbeitet. --trust-remote-code ist erforderlich, weil K3 Custom-Modell-Code (KDA-Attention, LatentMoE-Routing) ausliefert, der noch nicht in Stock-Transformers ist.

Produktion – K3 + DSpark​

K3 mit DSpark-Speculative-Decoding servieren

vllm serve moonshotai/Kimi-K3 \
--tensor-parallel-size 16 \
--enable-prefix-caching \
--trust-remote-code \
--speculative-config '{"method": "dspark", "model": "Inferact/Kimi-K3-DSpark", "num_speculative_tokens": 7, "attention_backend": "FLASHINFER_MLA", "draft_sample_method": "probabilistic", "rejection_sample_method": "block"}'

Das num_speculative_tokens: 7 passt zur trainierten Blockgröße des DSpark-Speculators – nicht senken, sonst verschwenden Sie den ganzen Sinn des Block-Diffusion-Draftings. attention_backend: FLASHINFER_MLA ist erforderlich, damit der MLA-native Draft Cache-Seiten mit dem Ziel teilt. Wenn Sie deterministisches Sampling wollen, schalten Sie draft_sample_method auf "greedy" und setzen Temperature=0 client-seitig.

Schritt 4 – Die Prefill/Decode-Asymmetrie, vor der niemand warnt​

Hier sind die tatsächlichen Zahlen, die ein Community-Betreiber vom Betrieb des vollen K3 auf 16× DGX Spark (GB10) mit aktiviertem DSpark gepostet hat, mit MikroTik CRS804-4DDQ-Networking und 4×400→4×100 Gb Breakout-Kabeln bei 2,3 kW Peak:

WorkloadDurchsatzPeak
Prefill @ 4k Kontext655 Tok/s8.288 Tok/s
Decode @ 4k Kontext21,7 Tok/s37 Tok/s
Prefill @ 16k Kontext759 Tok/s21.457 Tok/s
Decode @ 16k Kontext25,4 Tok/s38 Tok/s

Lesen ist 30–40× schneller als Schreiben. Praktisch heißt das:

  • Long-Context-Q&A über große Code-Repos oder Research-Korpora funktioniert wunderbar – Sie nehmen den Korpus mit fast einer Million Tokens pro Minute Wall-Time auf.
  • Long-Form-Generierung, streaming Assistants, Chat-artige UIs fühlen sich langsam an – 25 Tok/s sind erträglich, aber deutlich hinter einem Hosted-Sonnet/Fable-Klasse-Modell.
  • Agentic-Loops, in denen das Modell lange Tool-Call-Ketten produziert, verstärken den Decode-Flaschenhals. Erwägen Sie knappere Reasoning-Stile und strukturierte Outputs.
  • Batching hilft Decode mehr als Prefill – der Durchsatz pro GPU-Sekunde steigt scharf, wenn gleichzeitige Requests steigen (der vLLM-Blog meldet 2K+ Tokens pro GPU-Sekunde bei hoher Concurrency).

Schritt 5 – Die fünf Gotchas aus den Ops-Threads der ersten Woche​

Guided walkthrough1 of 5
  1. Jeder Serving-Guide außer dem vLLM-Blog vergisst das. Ohne --enable-prefix-caching wird K3s 90%+-Real-World-Cache-Hit-Rate zu 0%, und jeder Turn verarbeitet den vollen Prompt neu. Kosten und Latenz explodieren beide. Einmal setzen, für immer.

Schritt 6 – Sollten Sie überhaupt self-hosten?​

Für die meisten Teams ist die ehrliche Antwort Nein. Machen Sie die Break-Even-Mathematik pro Ihre Workload:

PfadKostenWann er gewinnt
Moonshot-API3,00 $/M in, 0,30 $/M Cache-Hit, 15 $/M outPrototyping, geringes Volumen, nicht sensible Daten
Runpod Hosted K30,95 $/M in, 4 $/M outStetiges mittleres Volumen, brauchen OpenAI-kompatiblen Endpunkt, egal wo Compute läuft
Runpod 8× B300 stündlich59,12 $/hStoßweise Läufe, Kontrolle über Serving-Config gewünscht, immer noch kein Capex
Eigene Hardware80k–500k $+ CapexStrikte Datenresidenz, 24/7-Sättigung, oder Sie bauen ein konkurrierendes Inferenz-Produkt

Beim Decode des 16×-GB10-Clusters von ~21 Tok/s produziert ein Node ~76k Output-Tok/h. Zu Runpod-K3-Hosted-Preisen sind das 0,30 $ Output-Tokens pro Stunde. Um eine 59 $/h-Hosted-Rate zu schlagen, bräuchten Sie einen Durchsatz näher an ~15M Output-Tokens/h bei hohem Batch und nahe 100% Utilization – erreichbar mit Concurrency, aber nur wenn Sie tatsächlich diese Nachfrage haben. Darunter gewinnt Hosted um eine Größenordnung.

Die korrekten Gründe, K3 in 2026 self-zu-hosten:

  • Datenresidenz / regulatorisch – die Prompts und Completions dürfen Ihre VPC nicht verlassen.
  • Kontinuierliche Sättigung – Sie haben eine Flotte von Agenten, die 24/7 läuft, und Cache-Hit-Preise tun trotzdem weh.
  • Modell-Modifikation – Sie trainieren einen Custom-DSpark-Speculator, machen LoRA-Finetunes auf die MoE-Experten oder experimentieren mit Routing-Änderungen.
  • Lernwert – ein Lab oder ein Team, das speziell verstehen will, wie Frontier-MoE-Serving auf dem Metall funktioniert.

Wenn nichts davon zutrifft, rufen Sie die API und lenken die gesparte Engineering-Zeit in bessere Prompts, bessere Evals und besseres Context Engineering.

Schritt 7 – Ein minimaler Python-Client für den gewählten Pfad​

vLLM exponiert einen OpenAI-kompatiblen Endpunkt, sodass derselbe Client gegen Ihr eigenes Rack, Runpods Hosted-K3 oder Moonshots API funktioniert.

Rufen Sie Ihren K3-Endpunkt mit dem OpenAI-Python-SDK

from openai import OpenAI

client = OpenAI(
  base_url="http://localhost:8000/v1",   # or Runpod / Moonshot base URL
  api_key="EMPTY",                        # self-hosted vLLM ignores keys
)

resp = client.chat.completions.create(
  model="moonshotai/Kimi-K3",
  messages=[
      {"role": "system", "content": "You are a terse coding assistant."},
      {"role": "user",   "content": "Explain DSpark speculative decoding in three bullets."},
  ],
  max_tokens=8192,
  temperature=0.2,
)

print(resp.choices[0].message.content)

Flashcards – die Zahlen, die Sie im Schlaf kennen sollten​

Noch keine Karten — füge welche hinzu, um zu lernen. 🃏

Quiz​

Check yourself

0/4
  1. Sie entwerfen ein internes Tool, mit dem Analysten mit einem 200k-Token-Research-Korpus chatten. Latenz des ersten Tokens ist wichtig, Per-User-Token-Volumen ist niedrig. Sollten Sie K3 selbst hosten?
  2. Welche vLLM-Flag-Kombination ist am sichersten für einen ersten Produktions-K3-Serve?
  3. DSpark draftet 7 Tokens in einem parallelen Durchgang. Wie viele davon werden in der Praxis typischerweise pro Schritt von K3 akzeptiert?
  4. Sie stellen 16× DGX-Spark-Boxen auf Ihren Schreibtisch. Welches Durchsatzprofil sollten Sie den Nutzern ansagen?

Wann Sie stattdessen einen Hosted-Pfad wählen sollten​

  • Prototyping und Demos – Moonshots API oder Runpod nutzen. Latenz und Preise sind beide fine.
  • Kostensensibles hohes Volumen – Moonshots 0,30 $/M-Cache-Hit-Input-Preis ist unschlagbar, wenn Ihre Workload tatsächlich cached.
  • Agentic Coding mit Claude Code oder einer anderen Harness – K3 via AI-Gateway (LiteLLM / OpenRouter / Portkey) einbinden und Modelle wechseln, ohne die Harness zu ändern.
  • Modellvergleichs-Arbeit – siehe Modell wählen und Kimi K3 für Claude-Nutzer, wann K3 die richtige Wahl ist vs. bei Anthropic zu bleiben.

Quellen & weiterführend​