Zum Hauptinhalt springen
Zuletzt überprüft: 2026-10-14
Kimi K3 ist das Frontier-Modell von Moonshot AI: 2.8 Billionen Gesamtparameter, 104 Milliarden aktive pro Token über Stable LatentMoE-Routing (16 aktive + 2 geteilte Experten bei 896 insgesamt), native visuelle Eingabe über MoonViT-V2 und ein Kontextfenster mit 1 Million Token. Moonshot hat K3 am 17. Juli 2026 für langfristiges Coding, Wissensarbeit und Reasoning veröffentlicht und die herunterladbaren Gewichte am 27.–28. Juli 2026 auf HuggingFace bereitgestellt (1.1M+ Downloads). Die Gewichte, die Modellkarte und die Lizenz sind öffentlich. Sie können K3 heute auf einem ausreichend großen Cluster selbst betreiben und es mit Tokios verbinden.
Kimi K3-Gewichte sind auf HuggingFace verfügbar. Das Repository hat 1.1M+ Downloads. Sie können K3 mit vLLM auf einem Cluster mit 64+ Beschleunigern selbst betreiben und es mit Tokios verbinden.

Was ist verfügbar?

Quelle: Kimi K3 Launch-Post und Kimi K3 API-Leitfaden.

Kimi K3 im Überblick

Moonshot hat den technischen Bericht, die Checkpoint-Dateien und die Modellkarte zusammen mit der Gewichtsveröffentlichung publiziert. Lesen Sie die Modellkarte für die vollständige Spezifikation und Lizenzbedingungen.

Können Sie Kimi K3 lokal ausführen?

Ja — wenn Sie einen ausreichend großen Cluster haben. Die Gewichte sind auf HuggingFace verfügbar, aber K3s ~1.4 TB Gewichtsbasis bei 4-Bit-Präzision schließt jedes Consumer- und Prosumer-Setup aus. Moonshots eigene Empfehlung ist ein Supernode mit 64 oder mehr Beschleunigern. Acht DGX Sparks bündeln 1 TB vereinheitlichten Speicher und liegen immer noch 376 GB darunter. Siehe die DGX Spark-Speicherberechnung für die vollständige Berechnung. vLLM ist das offiziell unterstützte Serving-Backend. Sie können auch Docker Model Runner oder Transformers mit trust_remote_code verwenden.
K3 benötigt 64+ Beschleuniger. Siehe was Sie statt Kimi K3 ausführen sollten für das beste Coding- und Allgemeinmodell für Ihre genaue Hardware, vom Strix Halo bis zu einem 4-Spark-Cluster.

Kimi K3 Hardware-Anforderungen

Kein Consumer- oder Prosumer-Setup fasst K3. Bei exakt 4 Bit pro Parameter benötigen 2.8T Parameter etwa 1.4 TB allein für die Gewichte — vor Microscaling-Metadaten, Laufzeit-Puffern, Aktivierungen und Kontextzustand. Zum Vergleich: Acht DGX Sparks bündeln 1 TB vereinheitlichten Speicher und liegen immer noch mindestens 376 GB unter der reinen Gewichtsbasis, NVIDIA dokumentiert Spark-Cluster derzeit nur bis zu vier Knoten, und Moonshot empfiehlt, K3 auf einem Supernode mit 64 oder mehr Beschleunigern zu betreiben. Siehe die DGX Spark-Speicherberechnung für die vollständige Berechnung, Cluster-Tabelle und Netzwerk-Einschränkungen.

K3 lokal betreiben

Der offiziell unterstützte Serving-Pfad ist vLLM. Docker Model Runner und HuggingFace Transformers (mit trust_remote_code) funktionieren ebenfalls.
K3 benötigt KDA-bewusste Kernel und Cache-Semantiken. Eine Laufzeit, die nur die Gewichte lädt, ist nicht automatisch K3-kompatibel. Verwenden Sie vLLM mit KDA-Unterstützung oder eines der anderen verifizierten Backends.

Warum die Architektur für das Self-Hosting wichtig ist

K3 ist nicht einfach ein größerer K2-Checkpoint. Fünf Änderungen sind für alle relevant, die es betreiben wollen:
  • Kimi Delta Attention (KDA) — ein hybrides Linear-Attention-Design, das die Vorverarbeitung von Millionen Token günstiger macht. Es benötigt passende Kernel und Cache-Semantiken: Moonshot sagt, dass herkömmliches Prefix-Caching nicht sauber auf KDA abbildet und dass sein vLLM-Prefill-Cache-Beitrag mit den Gewichten ausgeliefert wird. Eine Laufzeit, die nur die Gewichte lädt, ist nicht automatisch K3-kompatibel.
  • Attention Residuals (AttnRes) — Schichten, die gezielt nützliche Repräsentationen aus früherer Tiefe abrufen, statt die Ausgabe jeder Schicht mit festem Gewicht zu addieren. Moonshots AttnRes-Paper berichtet von stabilerem Informationsfluss in tieferen Modellen.
  • Stable LatentMoE — 16 aktive + 2 geteilte Experten werden pro Token über 896 insgesamt geroutet. Sparse-Aktivierung reduziert den Compute-Aufwand pro Token, aber sie verkleinert den gespeicherten Checkpoint nicht: jeder Experte muss im Serving-Cluster präsent bleiben, was schnelle Interconnects zu einer Anforderung erster Ordnung macht.
  • MoonViT-V2 — ein 401M-Parameter-Vision-Encoder, der Text-, Bild- und Videoeingaben nativ verarbeitet.
  • Natives MXFP4 — das Quantisierungs-bewusste Training lief ab der Supervised-Feinabstimmungs-Phase und zielte auf MXFP4-Gewichte und MXFP8-Aktivierungen ab. Dies ist das vorgesehene Serving-Format, kein Community-Quant — die 4-Bit-Angabe oben ist also eine Basis, kein Kompromiss.

K3-API-Verhalten, das Sie beibehalten sollten

Wenn Sie K3 über Moonshots API testen oder ein selbst betriebenes Laufzeitsystem validieren, sind diese Protokoll-Details wichtig:
  • K3 reasoning immer. Verwenden Sie das Top-Level-reasoning_effort: "max"; senden Sie nicht K2.x’s thinking-Parameter.
  • Streaming-Antworten trennen das Reasoning in reasoning_content und die finale Antwort in content.
  • Für Multi-Turn-Gespräche und Tool-Schleifen müssen Sie die vollständige Assistentennachricht wiedergeben, einschließlich des aufbewahrten Reasonings und der Tool-Call-Felder. Nur content zurückzugeben kann spätere Turns destabilisieren.
  • max_completion_tokens ist standardmäßig 131,072 und kann bis zu 1,048,576 gesetzt werden.
  • Die Launch-API fixiert die Sampling-Werte. Moonshot empfiehlt, dass Sie temperature, top_p, n und Penalty-Parameter weglassen statt sie zu überschreiben.
  • Öffentliche Bild-URLs werden nicht akzeptiert. Senden Sie Base64-Daten oder eine ms://<file-id>-Referenz.
Siehe den offiziellen K3 API-Leitfaden für das aktuelle Anfrage-Schema.

K3 mit Tokios verbinden

Tokios sitzt nach einer lokalen Laufzeit. Es lädt das Modell nicht herunter und ersetzt vLLM nicht. Betreiben Sie K3 auf einem unterstützten Cluster und verbinden Sie es mit Tokios:
1

Die offiziellen Artefakte prüfen

Bestätigen Sie, dass das Repository moonshotai/Kimi-K3 ist. Lesen Sie die Modellkarte, Lizenz, Checkpoint-Manifest, unterstützte Beschleunigerliste und empfohlenen Parallelisierungseinstellungen.
2

K3 auf dem unterstützten Cluster betreiben

Führen Sie vllm serve "moonshotai/Kimi-K3" aus oder folgen Sie den Anweisungen für Docker Model Runner / Transformers. Bestätigen Sie, dass der lokale Server eine Streaming-Anfrage abschließen, reasoning_content beibehalten und eine Multi-Turn-Tool-Schleife über seine eigene /v1-API ausführen kann.
3

Den Tokios-Connector koppeln

Installieren Sie den Connector auf einem Knoten, der den Serving-Endpunkt erreichen kann. Öffnen Sie im dashboard Setup, wählen Sie Start pairing und verwenden Sie den einmaligen TKS-XXXX-XXXX Pairing-Code.
Windows
macOS
Linux
Dann approve Sie das Gerät auf dem Tab Setup oder Connectors.
4

Ein Deployment registrieren

Richten Sie den Connector auf die OpenAI-kompatible /v1-Basis-URL des Clusters aus. Registrieren Sie die Upstream-Modell-ID unter einem öffentlichen Deployment-Namen wie kimi-k3-tunnel.
5

Einen API-Schlüssel erstellen

Klicken Sie im Tab Keys auf Create key. Kopieren Sie den sk-tok-…-Schlüssel jetzt — er wird nur einmal angezeigt.
6

Vor dem Freigeben des Endpunkts testen

Testen Sie Streaming, lange Turns, Vision, strukturierte Ausgabe und Tool-Calls über https://api.tokios.com. Verwenden Sie einen dedizierten sk-tok-…-API-Schlüssel und halten Sie den initialen Kontext kurz, während Sie den Speicherverbrauch validieren.

Von überall aus aufrufen

Sobald dieser Pfad verifiziert ist, rufen Clients Ihren Deployment-Namen statt der Upstream-Modell-ID auf:

Hinweise zum Launch

  • K3-Benchmark-Ergebnisse sind von Moonshot berichtet. Unabhängige Reproduktion erfordert das Evaluations-Setup.
  • Moonshot warnt, dass der Verlust des aufbewahrten Reasoning-Verlaufs oder das Umstellen einer bestehenden Sitzung eines anderen Modells auf K3 die Ausgabe instabil machen kann.
  • K3 ist für lange, schwierige Aufgaben trainiert und kann bei mehrdeutigen Anweisungen zu proaktiv handeln. Setzen Sie explizite Grenzen in Ihrem System-Prompt oder AGENTS.md.
  • Ein 1M-Token-Limit ist ein Maximum, kein Ziel. Lange Kontexte erhöhen Prefill-Zeit, Cache-Speicher und Inferenzkosten.
  • Die Kimi K3-Lizenz ist eigens — lesen Sie die Modellkarte für die Bedingungen vor dem Production-Einsatz.

FAQ

Bei seiner nativen MXFP4-Präzision (4 Bit pro Parameter) benötigen K3s 2.8T Parameter etwa 1.4 TB allein für die Gewichte — vor Block-Skalen, Laufzeit-Puffern, Aktivierungen und KV-Cache. Das sind ungefähr 11 DGX Sparks bei je 128 GB, nur für die reine Gewichtsbasis. Praktisch benötigen Sie mindestens 14-16 Sparks für einen hypothetischen verteilten Serving-Stack, und NVIDIA dokumentiert Spark-Cluster nur bis zu 4 Knoten.
Nicht praktisch. Acht DGX Sparks geben Ihnen 1 TB vereinheitlichten Speicher — 376 GB unter der Gewichtsbasis. NVIDIAs dokumentierte Spark-Topologie endet bei 4 Knoten (512 GB), und Moonshot zielt mit K3 auf Supernodes mit 64 oder mehr Beschleunigern. Für Modelle im Spark-Maßstab heute siehe DGX Spark Modellkompatibilität.
Die Gewichte sind auf HuggingFace unter einer eigenen „Kimi K3 License” verfügbar — nicht MIT oder Apache. Lesen Sie die Modellkarte für die vollständigen Lizenzbedingungen vor dem Deployment. Kimi K2.6 und K2.7-Code sind ebenfalls Open-Weight — siehe die Kimi-Modellfamilie.
Betreiben Sie den Checkpoint auf einem unterstützten Cluster mit 64+ Beschleunigern. Der offiziell unterstützte Pfad ist vllm serve "moonshotai/Kimi-K3". Docker Model Runner und Transformers mit trust_remote_code funktionieren ebenfalls. Tokios kann diesen lokalen Endpunkt mit begrenzten API-Schlüsseln absichern — siehe K3 mit Tokios verbinden oben. Sie können auch Moonshots gehostete API mit der Modell-ID kimi-k3 aufrufen.
1,048,576 Token (1M). Der Parameter max_completion_tokens ist standardmäßig 131,072 und kann bis zum vollen Kontextfenster gesetzt werden. Lange Kontexte erhöhen Prefill-Zeit, Cache-Speicher und Inferenzkosten — 1M ist ein Maximum, kein Ziel.
K3 ist ein Mixture-of-Experts-Modell mit 93 Schichten (69 KDA + 24 Gated MLA), Hidden Dim 7168, 96 Attention-Heads und 4 Schlüsselinnovationen: Stable LatentMoE (16 aktive + 2 geteilte Experten pro Token über 896 insgesamt, 104B aktiv), Kimi Delta Attention (hybride Linear-Attention für effiziente Million-Token-Prefill), Attention Residuals (Tiefen-weises Informations-Routing), MoonViT-V2 (401M-Parameter-Vision-Encoder für Text + Bild + Video) und natives MXFP4 (Quantisierungs-bewusstes Training ab SFT). Diese sind nicht direkt kompatibel mit Standard-Transformer-Serving — insbesondere KDA benötigt passende Kernel und Cache-Semantiken.

Kimi K3 auf DGX Spark

Die vollständige Speicherberechnung, Cluster-Einschränkungen und Launch-Evidenztabelle.

Kimi-Modelle

Vergleichen Sie K3 mit den herunterladbaren K2.6 und K2.7-Code und betreiben Sie Kimi heute selbst.

Was statt K3 ausführen

Das beste Coding- und Allgemeinmodell für Ihre Hardware, vom Strix Halo bis zu einem 4-Spark-Cluster.

Modell-Serving und Skalierung

Verstehen Sie Tensor-, Pipeline- und Experten-Parallelismus bevor Sie einen Frontier-Cluster planen.

Schnellstart

Koppeln Sie einen Connector und registrieren Sie ein lokales Modell, das heute verfügbar ist.