Skip to main content
Letzte Überprüfung: 2026-07-21
Kimi K3 ist das Spitzenmodell von Moonshot AI: 2.8 Billionen Gesamtparameter, etwa 50 Milliarden aktive Parameter pro Token dank des Stable LatentMoE-Routings (16 von insgesamt 896 Experten-Modulen), native Unterstützung für visuelle Eingaben sowie ein 1 Millionen Token umfassendes Kontextfenster. Moonshot brachte K3 am 17. 2026 Juli heraus – ein Modell für langfristiges Programmieren, Wissensarbeit und komplexes logisches Denken. Ein wichtiger Aspekt bei der lokalen Inferenz ist der Zeitplan: K3 ist derzeit über Kimis gehostete Produkte und API verfügbar; laut Moonshot werden die herunterladbaren Gewichte jedoch erst im Juli 27, 2026 zur Verfügung stehen. Die Modellbeschreibung, die Größe des Checkpoints, die Lizenzbedingungen, Laufzeit-Parameter sowie Anleitungen zur Reproduzierbarkeit der Selbst-Hosting-Installation sind bislang noch nicht öffentlich zugänglich.
Derzeit ist eine Selbst-Hosting-Deployment von Kimi K3 nicht möglich, da die Gewichte noch nicht freigegeben wurden. Kopieren Sie bitte keine spekulativen vllm serve-Befehle oder Community-Dateien mit der Bezeichnung K3 und gehen Sie nicht davon aus, dass es sich dabei um das offizielle Modell handelt. Warten Sie auf ein Repository, das von Moonshot bereitgestellt wird.

​
Was ist derzeit verfügbar?

Quelle: Ankündigungsbeitrag zu Kimi K3 sowie API-Leitfaden für Kimi K3.

​
Kimi K3 – ein kurzer Überblick

Moonshot hat bislang weder den technischen Bericht noch exakte Checkpoint-Dateien veröffentlicht. Alle Angaben zu Parametern, Speicherbedarf, Ausführungsbefehlen oder Leistungsdaten sind vorläufig, bis diese Unterlagen vorliegen.

​
Lässt sich Kimi K3 lokal ausführen?

No — not today. Kimi K3 is available now through Moonshot’s hosted API, but the downloadable weights have not shipped yet (promised by July 27, 2026). Even when the weights arrive, K3’s ~1.4 TB weight floor at 4-bit precision rules out every consumer and prosumer setup. Moonshot’s own recommendation is a supernode with 64 or more accelerators. Eight DGX Sparks pool 1 TB of unified memory and still fall 376 GB short. See the DGX Spark memory math for the full calculation.
Möchten Sie nicht auf die Gewichte warten? Erfahren Sie stattdessen welche Modelle sich anstelle von Kimi K3 eignen – die besten Programmier- und Allzweck-Modelle für Ihre Hardware, vom Strix Halo bis hin zu einem Cluster mit 4 Spark-Einheiten.

​
Kimi K3 – Hardware-Anforderungen

Keine Consumer- oder Prosumer-Setups können K3 verarbeiten. Bei exakt 4 Bit pro Parameter benötigen 2.8T Parameter allein für die Gewichte etwa 1.4 Terabyte – und das noch vor Mikro-Skalierung von Metadaten, Laufzeit-Puffern, Aktivierungen sowie Kontextzuständen. Zur Einordnung: Acht DGX Spark-Systeme bieten zusammen 1 Terabyte gemeinsamen Speicher, reichen jedoch immer noch um mindestens 376 Gigabyte unter die reine Speicheranforderung aus. NVIDIA dokumentiert Spark-Cluster bislang nur mit maximal vier Knoten; Moonshot empfiehlt stattdessen die Deployment von K3 auf einem Supernode mit 64 oder mehr Beschleunigern. Die vollständige Berechnung, die Cluster-Übersicht sowie Netzwerkbeschränkungen finden Sie im Dokument DGX Spark Memory Math.
Suchen Sie nach Modellen, die Sie noch heute herunterladen können? Vergleichen Sie alle aktuellen Kimi-Modelle; Kimi K2.6 sowie K2.7-Code stehen nun mit offenen Gewichten zur Verfügung und lassen sich auf Server-Hardware betreiben.

​
Warum die Architektur für die Selbst-Hosting-Deployment entscheidend ist

K3 ist keineswegs bloß eine größere Variante von K2. Vier wesentliche Änderungen sind für alle Interessenten relevant:
  • Kimi Delta Attention (KDA) – ein hybrides Design aus linearer Aufmerksamkeit, das die Vorverarbeitung von Millionen Token kostengünstiger macht. Dafür sind passende Kernel sowie spezifische Cache-Regeln nötig: Moonshot betont, dass herkömmliches Präfix-Caching nicht direkt mit KDA kompatibel ist; die zugehörigen vLLM-Optimierungen werden zusammen mit den Gewichten ausgeliefert. Ein Runtime-System, das lediglich die Gewichte lädt, ist folglich nicht automatisch K3-fähig.
  • Attention Residuals (AttnRes) – bestimmte Schichten greifen gezielt auf relevante Repräsentationen aus früheren Netzwerkschichten zurück, anstatt die Ausgaben aller Schichten mit festen Gewichten zu addieren. In der Publikation AttnRes paper von Moonshot wird eine stabilere Informationsweitergabe in tieferen Modellen nachgewiesen.
  • Stable LatentMoE — 16 of 896 experts route per token. Sparse activation cuts per-token compute, but it does not shrink the stored checkpoint: every expert must stay resident across the serving cluster, which makes fast interconnects a first-order requirement.
  • Native MXFP4 – das Training unter Berücksichtigung der Quantisierung startete bereits bei der überwachten Feinabstimmung; Ziel waren MXFP4-Gewichte sowie MXFP8-Aktivierungen. Dies ist das offizielle Deployment-Format, kein von der Community erstellter Quantisierungs-Standard; daher stellt die oben genannte 4-Bit-Angabe lediglich die Mindestanforderung dar.

​
Zu bewahrendes Verhalten der K3-API

Sollten Sie K3 derzeit über die API von Moonshot testen oder später ein eigenes Runtime-System validieren, sind folgende Protokoll-Details von Bedeutung:
  • K3 always reasons. Use the top-level reasoning_effort: "max"; do not send K2.x’s thinking parameter.
  • Bei Streaming-Antworten wird das eigentliche Denken in reasoning_content und die finale Antwort in content ausgegliedert.
  • Bei mehrstufigen Gesprächen sowie Werkzeugschleifen muss die vollständige Nachricht des Assistenten erneut gesendet werden, inklusive des erhaltenen Denkprozesses sowie der Werkzeugaufrufe. Allein das Senden von content kann zu Instabilitäten in nachfolgenden Schritten führen.
  • max_completion_tokens ist standardmäßig auf 131,072 eingestellt und kann bis zu einem Wert von 1,048,576 festgelegt werden.
  • Die Start-API regelt die Werte für die Stichprobenbildung. Moonshot empfiehlt, die Parameter temperature, top_p, n sowie Strafparameter wegzulassen, anstatt sie zu überschreiben.
  • Öffentliche Bild-URLs sind nicht zulässig. Stattdessen müssen Base64-Daten oder ein ms://<file-id>-Verweis übermittelt werden.
Das aktuelle Anfrageformat finden Sie im offiziellen K3 API-Leitfaden.

​
Verbinden Sie K3 nach Erhalt der Gewichte mit Tokios.

Tokios fungiert als lokaler Laufzeitumgebung; es lädt das Modell nicht herunter und ersetzt vLLM nicht. Sobald Moonshot sowie die Entwickler der Laufzeitumgebung einen unterstützten K3-Betriebsweg veröffentlichen:
1

Prüfen Sie die offiziellen Artefakte.

Stellen Sie sicher, dass das Repository von Moonshot verlinkt wird. Lesen Sie die Modellbeschreibung, Lizenz, Manifestdatei der Checkpoints, Liste der unterstützten Beschleuniger sowie die empfohlenen Parallelitätseinstellungen. Leiten Sie diese Angaben nicht allein aus K2 ab.
2

Betreiben Sie K3 auf dem unterstützten Cluster.

Befolgen Sie die vorgegebenen Anweisungen für vLLM oder andere Laufzeitumgebungen. Stellen Sie sicher, dass der lokale Server Streaming-Anfragen verarbeiten kann, reasoning_content beibehält und auf seinem eigenen /v1 API mehrstufige Werkzeugschleifen ausführt.
3

Verknüpfen Sie den Tokios-Connector

Installieren Sie den Connector auf einem Knoten, der Zugriff auf das Bereitstellungs-Endpunkt hat. Öffnen Sie im dashboard das Setup, wählen Sie Start pairing aus und verwenden Sie den einmalig gültigen TKS-XXXX-XXXX Anspruchs-Code.
4

Eine Deployment erstellen

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

Einen API-Schlüssel erstellen

Wechseln Sie in den Keys-Reiter und klicken Sie auf Create key. Kopieren Sie nun den sk-tok-…-Schlüssel – er wird nur ein einziges Mal angezeigt.
6

Vor der Freigabe des Endpunkts testen

Testen Sie mittels https://api.tokios.com das Streaming, lange Dialogverläufe, die Bildverarbeitung, strukturierte Ausgaben sowie Tool-Aufrufe. Nutzen Sie dazu einen speziellen sk-tok-…-API-Schlüssel und halten Sie den anfänglichen Kontext kurz, um den Speicherverbrauch zu prüfen.

​
Von überall aus aufrufen

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

​
Hinweise zur Inbetriebnahme

  • Die Gewichte, Modellbeschreibung, Lizenz, technische Dokumentation, Prüfsummen-Liste sowie Anweisungen zur Selbst-Hosting-Installation stehen noch aus.
  • Die Benchmark-Ergebnisse zu K3 stammen von Moonshot. Eine unabhängige Nachprüfung ist erst nach Veröffentlichung der Gewichte sowie der Evaluations-Setups möglich.
  • Moonshot weist darauf hin, dass der Verlust der gespeicherten Reasoning-Historie oder der Wechsel einer bestehenden Sitzung eines anderen Modells auf K3 zu instabilen Ausgaben führen kann.
  • K3 wurde speziell für lange und komplexe Aufgaben trainiert; bei vagen Anweisungen reagiert es mitunter übermäßig proaktiv. Definieren Sie daher klare Grenzen im System-Prompt oder in AGENTS.md.
  • Die Angabe zur Token-Obergrenze von 1M ist ein Maximum, kein Zielwert. Lange Kontexte verlängern die Vorverarbeitungszeit, erhöhen den Speicherbedarf für Caches sowie die Inferenzkosten.

​
Häufig gestellte Fragen

At its native MXFP4 precision (4 bits per parameter), K3’s 2.8T parameters need about 1.4 TB for weights alone — before block scales, runtime buffers, activations, and KV cache. That is roughly 11 DGX Sparks at their 128 GB each, just for the raw weight floor. In practice you need 14-16 Sparks minimum for a hypothetical distributed serving stack, and NVIDIA only documents Spark clusters up to 4 nodes.
Praktisch nicht. Acht DGX Spark-Systeme bieten insgesamt 1 Terabyte gemeinsamen Speicher – das reicht jedoch um 376 GB nicht aus, um alle Gewichte zu speichern. Die maximal dokumentierte Spark-Topologie umfasst 4 Knoten (512 GB Gesamtspeicher); Moonshot zielt bei K3 auf Supernodes mit mindestens 64 Beschleunigern ab. Für derzeit verfügbare Spark-Skalierungsmodelle siehe DGX Spark-Modellkompatibilität.
Moonshot kündigt an, dass die herunterladbaren Gewichte für K3 im Juli 27, 2026 veröffentlicht werden; bislang liegen weder Lizenztext noch Modellbeschreibung noch Checkpoint-Dateien vor. Erst nach dieser Veröffentlichung ist die Bezeichnung „Open Source“ zutreffend. Kimi K2.6 sowie K2.7-Code sind derzeit bereits mit offenen Gewichten verfügbar – siehe dazu Kimi-Modellfamilie.
Heute lässt sich das Modell mittels Moonshots gehosteter API unter Verwendung der Upstream-Modell-ID kimi-k3 nutzen. Nachdem die Modellgewichte verfügbar sind, können Sie den Checkpoint auf einem kompatiblen Cluster bereitstellen (voraussichtlich vLLM mit KDA-Cache-Unterstützung) und anschließend dessen OpenAI-kompatiblen /v1-Endpunkt aufrufen. Mit Tokios lässt sich dieser lokale Endpunkt mittels spezifischer API-Schlüssel absichern – siehe dazu oben Connect K3 with Tokios.
1,048,576 Token (1M insgesamt). Der Wert des Parameters max_completion_tokens ist standardmäßig auf 131,072 gesetzt und kann bis zur vollen Kontextbreite erhöht werden. Längere Kontexte verlängern die Vorverarbeitungszeit, erhöhen den Speicherbedarf für Caches sowie die Kosten für die Inferenz – 1M stellt lediglich ein Maximum dar, kein angestrebter Wert.
K3 ist ein Mixture-of-Experts-Modell, das über 4 zentrale Neuerungen verfügt: Stable LatentMoE (pro Token werden 16 von insgesamt 896 Experten aktiviert, wobei etwa 50B Experten tatsächlich aktiv sind), Kimi Delta Attention (eine hybride lineare Aufmerksamkeitsmethode zur effizienten Verarbeitung von Millionen von Tokens), Attention Residuals (eine tiefenbasierte Informationsweiterleitung) sowie native MXFP4 (ein Quantisierungsbewusstes Training ab dem SFT-Schritt). Diese Merkmale sind nicht ohne Weiteres mit herkömmlichen Transformer-Systemen kompatibel; insbesondere erfordert KDA passende Kernel sowie spezifische Cache-Semantiken.

Kimi K3 auf DGX Spark

Detaillierte Berechnungen zum Speicherbedarf, Cluster-Anforderungen sowie Belege zur Implementierung.

Kimi-Modelle

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

Alternativen zu K3

Das optimale Modell für Programmierung und allgemeine Aufgaben – passend für Hardware von Strix Halo bis hin zu einem 4-Spark-Cluster.

Modell-Bereitstellung und Skalierung

Lesen Sie sich zunächst über Tensor-, Pipeline- sowie Experten-Parallelismus auf, bevor Sie eine Cluster-Deployment im großen Maßstab planen.

Schnellstart

Verknüpfen Sie einen Connector mit einem lokalen Modell und registrieren Sie dieses, das derzeit verfügbar ist.