Kimi K3 lokal betreiben: Anleitung und wann nicht

Moonshot AI hat am 27. Juli die offenen Gewichte für Kimi K3 veröffentlicht, und der Download-Zähler auf Hugging Face nähert sich bereits der 100.000er-Marke. Das Verkaufsargument ist offensichtlich: ein Modell mit 2,8 Billionen Parametern, das Claude Opus 4.8 bei jedem von Moonshot veröffentlichten Benchmark geschlagen hat, und das Sie jetzt selbst hosten können.

Der Haken ist auch offensichtlich, sobald man sich die Zahlen ansieht. Die Inferenz mit voller Präzision benötigt 1,57 TB Speicherplatz. Selbst die veröffentlichten MXFP4-Gewichte sind ein Download von 594 GB. Dies ist ein Modell, das Sie besitzen können, aber „lokal“ bedeutet in diesem Maßstab etwas anderes als bei einem 8B Llama.

Dieser Leitfaden behandelt, was erforderlich ist, um K3 auf Ihrer eigenen Hardware auszuführen, was die Community auf Consumer-Geräten erreicht hat und wie Sie einen selbst gehosteten K3-Endpunkt mit Apidog in Ihren API-Workflow integrieren, sobald er in Betrieb ist.

Was Sie herunterladen

Zuerst zur Beschaffenheit der Sache. Wenn Sie den vollständigen Hintergrund wünschen, beginnen Sie mit Was ist Kimi K3?; die Kurzversion:

• 2.8T Gesamtparameter, 104B pro Token aktiviert. K3 ist ein Mixture-of-Experts-Modell mit 896 Experten. Jedes Token wird durch 16 ausgewählte Experten plus 2 geteilte weitergeleitet, sodass die Berechnung pro Token einen Bruchteil der Titelnummer ausmacht.
• 93 Schichten: 69 Kimi Delta Attention (KDA)-Schichten und 24 Gated MLA-Schichten. Das KDA-Design ist der Grund, warum das 1-Millionen-Token-Kontextfenster überhaupt nutzbar ist.
• Native Vision über einen MoonViT-V2-Encoder mit 401 Millionen Parametern. Die veröffentlichten Gewichte verarbeiten Text-, Bild- und Videoeingaben.
• MXFP4-Gewichte, MXFP8-Aktivierungen. Moonshot hat ein quantisierungsbewusstes Training durchgeführt, sodass die 4-Bit-Version das beabsichtigte Serving-Format ist, kein nachträglicher Einfall. Das bedeutet auch, dass die Gewichte darüber hinaus schlecht komprimieren; der Headroom für geringe Bitraten ist bereits ausgeschöpft.
• Nur Denkfunktion. K3 denkt immer nach, bevor es antwortet, mit geringem, hohem und maximalem Anstrengungsgrad. Es gibt keinen sofortigen Modus.

Die Gewichte sind hinter der Kimi K3-Lizenz im Hugging Face Repo geschützt. Akzeptieren Sie die Lizenz und ziehen Sie dann mit huggingface-cli. Bei einer 1-Gbit/s-Verbindung planen Sie etwa 80 bis 90 Minuten für die 594 GB ein.

Option 1: Datacenter-Klasse Serving mit vLLM oder SGLang

Moonshot empfiehlt drei Engines: vLLM, SGLang und TokenSpeed. Ihr Beitrag zum KDA-Prefill-Cache wurde zusammen mit den Gewichten in vLLM ausgeliefert, daher ist vLLM der Weg des geringsten Widerstands:

vllm serve moonshotai/Kimi-K3 \
  --tensor-parallel-size 8 \
  --max-model-len 131072

Anmerkungen aus der Praxis:

• Hardware. Moonshot hat auf H20-Clustern evaluiert. Realistisch benötigen Sie einen 8-GPU-Knoten mit Tensor-Parallelität als Untergrenze. Auf Hardware der B200-Klasse ist ein Durchsatz von über 100 Token/s erreichbar.
• Kontext. Das Modell unterstützt bis zu 1.048.576 Token, aber der KV-Cache bei vollem Kontext beträgt allein etwa 27 GB. Beginnen Sie bei 131K und erhöhen Sie ihn nur, wenn Ihre Arbeitslast dies erfordert.
• Sampling. Die Standardeinstellungen von Moonshot sind Temperatur 1.0 und Top-P 0.95. Für agentenbasierte Workloads halten Sie die Temperatur bei 1.0 und stellen Top-P auf 1.0.

Dies ist „lokal“ im Sinne der Datensouveränität: Ihre Infrastruktur, Ihre Protokolle, Ihre Compliance-Historie. Es ist nicht lokal im Sinne eines Laptops, und keine Quantisierung ändert dies für die interaktive Nutzung.

Option 2: GGUF-Quantisierungen auf einer großen Workstation

Unsloth hat GGUF-Konvertierungen für llama.cpp-Benutzer veröffentlicht, und ihre dynamischen Quantisierungen sind der einzig realistische Weg, K3 unter die offizielle Release-Größe zu schrumpfen:

Die Faustregel: Ihr RAM plus VRAM sollte ungefähr der Quantisierungsgröße entsprechen. Wenn Sie darunter liegen, läuft llama.cpp zwar immer noch durch Offloading, aber jedes fehlende Gigabyte kostet Sie Geschwindigkeit. Ein Mac Studio, der an eine 128-GB-Maschine gekettet ist, oder eine DGX Station liegen am praktischen unteren Ende.

Ein minimaler llama.cpp-Aufruf, einschließlich des Vision-Projektors:

./llama.cpp/llama-cli \
    --model unsloth/Kimi-K3-GGUF/UD-IQ1_S/Kimi-K3-UD-IQ1_M-00001-of-00015.gguf \
    --mmproj unsloth/Kimi-K3-GGUF/mmproj-F16.gguf \
    --temp 1.0 \
    --top-p 0.95

Wenn Ihre Hardware darunter liegt, erzwingen Sie es nicht. Die Liste der besten lokalen LLMs von 2026 enthält offene Modelle, die in 24 bis 128 GB passen und in Echtzeit antworten; K3 mit 1 Bit auf unzureichendem RAM wird das nicht tun.

Das M1 Max Experiment: Ja, aber 16 Sekunden pro Token

Ein Hacker News Thread dokumentierte diese Woche, wie K3 auf einem 64 GB M1 Max lief, indem Gewichte von einer 2 TB SSD gestreamt wurden, anstatt sie im Speicher zu halten. Die Zahlen erklären sowohl, warum es funktioniert, als auch, warum man es nicht verwenden würde:

• K3 enthält grob 115 GB dichter Parameter, die jedes Token berührt, plus etwa 25 GB gerouteter Expertengewichte pro Token. Der dichte Teil allein übersteigt den RAM des Geräts, sodass die SSD zu einem Zeitlupen-Speicher wird.
• Ergebnis: etwa 16 Sekunden pro Token. Einige Konfigurationen meldeten über eine Minute pro Token. Das ist ein Absatz pro Stunde.
• Der Festplattendurchsatz ist das ganze Spiel. M1-Ära SSDs lesen viel langsamer als aktuelle Apple Silicon, und das Streamen von Experten über ein Netzwerk ist noch langsamer.

Als Beweis, dass MoE-Sparsity plus mmap ein 2,8T-Modell auf einem Laptop ausführen kann, ist es ein wirklich unterhaltsames Ergebnis. Als Möglichkeit, K3 zu nutzen, ist es keine. Wenn Sie K3-Antworten auf einem MacBook wünschen, sind die kostenlosen Tarife oder die gehostete API besser für Sie geeignet.

Einbinden Ihres lokalen K3 in einen API-Workflow

Ob Sie über vLLM oder den Servermodus von llama.cpp dienen, Sie erhalten am Ende dasselbe: einen OpenAI-kompatiblen HTTP-Endpunkt auf localhost. Von hier aus ist es eine API wie jede andere, und derselbe Workflow, den wir für das Testen lokaler LLMs als APIs verwenden, gilt:

1. Richten Sie Apidog auf den Endpunkt. Erstellen Sie eine Umgebung mit base_url auf http://localhost:8000/v1 (vLLMs Standard) und tauschen Sie sie später gegen Moonshots gehosteten Endpunkt aus. Dieselben Anfragen, zwei Backends, eine Variable.
2. Überprüfen Sie den Denk-Stream. K3 ist nur denkend, daher enthalten Antworten Begründungsinhalte vor der Antwort. Apidogs SSE-Debugging-Ansicht rendert den Stream, sobald er ankommt, was es viel einfacher macht, zu sehen, welche Änderungen die Anstrengungsgrade der Begründung bewirken.
3. Validieren Sie die Struktur, nicht die Stimmung. Fügen Sie automatisierte Tests hinzu, die das Antwortschema, die Latenzbudgets und die Token-Nutzungsfelder validieren, sodass ein Quantisierungswechsel oder ein Engine-Upgrade, das die Ausgabe verschlechtert, in einem fehlschlagenden Test anstelle eines Benutzerberichts angezeigt wird.
4. Simulieren Sie K3, während die GPUs beschäftigt sind. Ein 594 GB großes Modell braucht eine Weile zum Laden. Zeichnen Sie echte Antworten einmal auf, und lassen Sie dann einen Mock-Server diese zurückgeben, damit die Frontend-Arbeit nie auf die Inferenzbox warten muss. Laden Sie Apidog herunter, um dies kostenlos einzurichten; die Mock- und Testwerkzeuge funktionieren beide mit jedem OpenAI-kompatiblen Server.

Das Anforderungsformat selbst entspricht dem, was wir im Kimi K3 API-Leitfaden behandelt haben, sodass Tests, die für die gehostete API geschrieben wurden, direkt auf Ihre lokale Bereitstellung übertragen werden können.

Sollten Sie es also lokal ausführen?

Eine kurze Entscheidungstabelle:

Die ehrliche Zusammenfassung: K3s offene Gewichte sind wichtig, weil Sie ein Modell der Spitzenklasse auditieren, feinabstimmen und selbst hosten können, nicht weil die meisten Leute es tun sollten. Für Teams mit der entsprechenden Hardware funktioniert der vLLM-Pfad heute und liefert gute Leistungen. Für alle anderen zahlt sich die offene Veröffentlichung indirekt immer noch aus, durch günstigere gehostete Zugriffe und Drittanbieter, die um die Bereitstellung konkurrieren.

Auf welcher Seite dieser Tabelle Sie auch landen, der Endpunkt ist der Ort, an dem das Modell auf Ihren Code trifft. Testen Sie es wie ein solches: Schema-Prüfungen, Streaming-Inspektion und Mocks, die die Entwicklung am Laufen halten, während das Modell nachdenkt.