Bestätigt bzw. noch ausstehend
Diese Unterscheidung ist von Bedeutung. K3 wird zwar als offenes Modell bezeichnet, doch das Versprechen einer zukünftigen Veröffentlichung der Gewichte unterscheidet sich von der Möglichkeit, diese bereits heute herunterzuladen.
Was sich gegenüber Kimi K2 geändert hat
K3 vergrößert die Größe im Vergleich zu K2 von 1 Billionen auf 2.8 Billionen Parametern, erweitert die Kontextlänge von 256K auf 1M Tokens und ändert die Architektur in vier wesentlichen Punkten.Kimi Delta Attention ermöglicht die Verarbeitung langer Sequenzen
Kimi Delta Attention (KDA) ist ein Mechanismus zur linearen Aufmerksamkeit innerhalb der Kimi Linear-Familie. Hybrid-Architekturen mit linearer Aufmerksamkeit verzichten darauf, in jeder Schicht die vollständige quadratische Aufmerksamkeit anzuwenden. Dies ist besonders wichtig bei langen Eingaben, wenn der Server zunächst einen umfangreichen Prompt einliest, bevor der erste Token generiert wird. KDA ist nicht bloß ein Parameter zur Geschwindigkeitssteigerung; es erfordert passende Kernel sowie spezifische Cache-Eigenschaften. Moonshot betont, dass herkömmliche Präfix-Caching-Verfahren nicht direkt mit KDA kompatibel sind und dass der vLLM-Beitrag zum Prefill-Cache zusammen mit den Gewichten ausgeliefert wird. Folglich ist eine Runtime, die beliebige Transformer-Gewichte laden kann, nicht automatisch für K3 geeignet.Attention Residuals leiten Informationen über die Tiefe der Netzwerkschichten hinweg weiter
Bei herkömmlichen PreNorm-Residual-Verbindungen werden Schichtausgaben stets mit festen Gewichten addiert. Attention Residuals ermöglichen es einer Schicht hingegen, auf vorherige Repräsentationen zu reagieren und zu entscheiden, welche davon erneut genutzt werden sollen. In der Forschungsarbeit zu Attention Residuals wird eine spezielle Blockvariante vorgestellt, die den Speicherbedarf sowie den Kommunikationsaufwand im Pipeline-Prozess reduziert, ohne den erzielten Nutzen erheblich zu mindern. Dies stellt eine tiefenbezogene Weiterleitung dar, die sich von der Token-Aufmerksamkeit unterscheidet. KDA bestimmt, wie sich Token-Positionen gegenseitig beeinflussen; AttnRes hingegen entscheidet, welche Repräsentationen früherer Schichten weiterhin von Nutzen sind.Stable LatentMoE erhöht die Sparsität der Modellaktivierung
K3 setzt Stable LatentMoE ein und verteilt die Verarbeitung auf 16 von insgesamt 896 Experten-Modulen. Durch diese sparsame Aktivierung verringert sich die Rechenlast pro Token im Vergleich zu einem dichten 2.8T-Modell. Allerdings wird dadurch der Speicherbedarf der gesamten Checkpoints nicht auf die Größe der aktiven Experten reduziert; alle Module müssen weiterhin im Cluster vorhanden sein. Bei dieser Skalierung beeinflussen die Platzierung der Experten sowie das Lastgleichgewicht die Gesamtleistung des Modells. Moonshot erwähnt zudem das Konzept der Quantil-Balance sowie ein vollständig ausgewogenes Verfahren für paralleles Training von Experten-Modulen; konkrete Implementierungsdetails fehlen jedoch noch im technischen Bericht.QAT erfolgt bereits vor der Deployment-Phase
Laut Angaben von Moonshot wurde das Quantisierungs-optimierte Training ab der Phase des überwachten Fein-Tunings angewandt; dabei kamen Gewichte vom Typ MXFP4 sowie Aktivierungen vom Typ MXFP8 zum Einsatz. Es handelt sich dabei nicht um eine nachträglich angewandte Quantisierung. Das Modell wurde gezielt so trainiert, dass es mit der für den Einsatz vorgesehenen Genauigkeit zurechtkommt. MXFP4 speichert Werte mit einer Genauigkeit von 4 Bit sowie zusätzliche Block-Skalierungsdaten. Die unten angegebene 4-Bit-Berechnung stellt lediglich eine untere Grenze dar und ist keine exakte Vorhersage für das Checkpoint-Verhalten.Berechnung des Speicherbedarfs bei DGX Spark
NVIDIA gibt an, dass jeder DGX Spark über 128 GB an LPDDR5x-Unified-Speicher verfügt; sowohl GPU als auch CPU nutzen diesen gemeinsamen Speicherpool. Es handelt sich dabei nicht um 128 GB für Gewichte zuzüglich separater System-RAM-Mengen. Bei exakt vier Bit pro Parameter:- Die Skalierungsparameter des MXFP4-Blocks sowie Metadaten zu Tensoren
- Laufzeit-Allokationen und Kommunikationspuffer
- Aktivierungswerte sowie temporäre Arbeitsspeicherbereiche
- Der erforderliche KV-Zustand bzw. der rekurrente Zustand für den gewählten Kontext
- Der Zustand des Vision-Encoders bei multimodalen Anfragen
- Der Speicherbedarf des DGX OS sowie der Dienstprozesse
Die Tabelle mit der Anzahl der verwendeten Spark-Einheiten
Warum die Gesamtspeicherkapazität allein nicht ausreicht
Selbst ein hypothetisches 16-Spark-Cluster müsste sich mit drei praktischen Problemen auseinandersetzen.Die unterstützte Topologie endet bei vier Knoten
NVIDIAs aktuelle Anleitung für Multi-Node-Deployments umfasst bis zu vier DGX Spark-Knoten. Damit lässt sich ein Cluster mit 512 GB für Modelle mit bis zu etwa 700B Parametern betreiben. K3 verfügt über viermal so viele Parameter. NVIDIA stellt Beispiele für zwei-, drei- und vierknotige Ring- sowie Switch-Architekturen bereit, jedoch keine Konfigurationen mit 14 oder 16 Knoten für K3.Die Inferenz von LLMs erfolgt kontinuierlich synchronisiert
Jeder Spark verfügt über 273 GB/s lokale Speicherbandbreite sowie eine 200 GbE ConnectX-7-Netzwerkschnittstelle. Ein 200-Gigabit-Link transportiert maximal 25 GB/s vor Protokoll-Overhead – ein Wert, der deutlich unter der lokalen Speicherbandbreite liegt. Bei verteilter LLM-Inferenz werden Schichten nacheinander verarbeitet und Zwischenergebnisse ständig ausgetauscht. NVIDIA weist explizit darauf hin, dass diese feingranulare Kommunikation die Skalierbarkeit bei mehr Knoten verringert. Mehr Knoten erhöhen zwar die Kapazität, verlängern jedoch die Wartezeit pro generiertem Token aufgrund des größeren Kommunikationsnetzes.K3 zielt auf einen Superknoten ab
Moonshot empfiehlt einen 64-Plus-Beschleuniger-Superknoten, damit parallele Verarbeitungen in einem großen Kommunikationsbereich mit hoher Bandbreite durchgeführt werden können. Diese Empfehlung betrifft Durchsatz und Topologie, nicht bloß die Frage, ob die Datei gerade noch hineinpasst. Ein Spark bleibt nützlich für die Entwicklung von Clients, Prompt-Logik, Tool-Schemata sowie kleineren lokalen Modellen. Er ist jedoch nicht die zielgerichtete Inferenzplattform für K3.So interpretiert man Moonshots Benchmark-Tabelle
Moonshot verzeichnet bei Coding-, Agenten- und Reasoning-Aufgaben sowie bei Bildverarbeitung starke Startwerte. Einige repräsentative K3-Ergebnisse (max) lauten:
Es handelt sich um vom Hersteller gemeldete Ergebnisse, keine unabhängig verifizierten Daten. Auch die Fußnoten von Moonshot weisen darauf hin, dass die Modelle nicht stets mit demselben Testaufbau bewertet wurden: K3 nutzt möglicherweise Kimi Code, ein anderes Modell wiederum Claude Code; GPT-Modelle setzen Codex ein. Die Qualität des Testaufbaus, Richtlinien zu Werkzeugen, die Kompression von Kontextinformationen sowie das Verhalten bei Fehlern beeinflussen die Ergebnisse erheblich.
Im Grunde lässt sich festhalten: K3 scheint leistungsfähig genug zu sein, um ernsthaft getestet zu werden; doch die vorliegenden Daten belegen nicht, dass es unter Ihren Bedingungen ähnliche Ergebnisse erzielt. Warten Sie auf die Modellgewichte, konkrete Prompt-Vorgaben, Details zum Testaufbau sowie unabhängige Bewertungen.
Das Verhalten der API entspricht nicht exakt K2
K3 ist mittlerweile alskimi-k3 über Moonshots OpenAI-kompatibles Chat Completions API verfügbar; dennoch stellt es keine direkte K2-Konfiguration dar: Der Denkmodus bleibt stets aktiv, reasoning_effort ersetzt den Parameter thinking, bei Streaming werden reasoning_content und content getrennt verarbeitet; außerdem muss bei mehrfacher Nutzung die vollständige Nachrichtenhistorie des Assistenten erhalten bleiben. Auf der Kimi K3-Modellseite finden Sie eine vollständige Auflistung aller Protokollanforderungen, die Sie bei API-Tests oder der Validierung einer eigenen Infrastruktur beachten müssen.
Bekannte Einschränkungen zum Startzeitpunkt
Moonshot nennt drei konkrete Einschränkungen:- Abhängigkeit von der Historie. K3 erfordert eine unveränderte Denkhistorie; fehlerhafte Wiederholungen oder ein Wechsel des Modells während einer Sitzung können zu instabilen Ergebnissen führen.
- Übermäßige Eigeninitiative. Bei komplexen Aufgaben mit Unklarheiten trifft das Modell mitunter unerwartete Entscheidungen. Setzen Sie daher explizite Genehmigungen, Abbruchbedingungen sowie Grenzen für Änderungen ein.
- Noch bestehende Unterschiede in der Nutzererfahrung. Laut Moonshot hinkt K3 selbst bei vergleichbaren Einzelwerten den leistungsstärksten kommerziellen Modellen in puncto Gesamtnutzererfahrung nach.
AGENTS.md klare Grenzen, verlangen Sie Bestätigungen für zerstörerische oder externe Aktionen und prüfen Sie zunächst die Verwaltung von Kontextinformationen, bevor Sie längere autonome Ausführungen zulassen.
Was Sie bis zur Veröffentlichung der Modellgewichte tun können
Warten Sie zunächst auf die von Moonshot bereitgestellten Artefakte – nicht auf ähnlich benannte Community-Repositories – und berechnen Sie anschließend erneut anhand des tatsächlichen Checkpoint-Manifests, bevor Sie etwas erwerben. Auf der Kimi K3-Modellseite finden Sie den detaillierten Plan zur Vorbereitung: die Überprüfung der offiziellen Artefakte, deren Bereitstellung auf einem unterstützten Cluster sowie die Einrichtung der Deployment-Verbindung über Tokios. In der Zwischenzeit enthält der Artikel Was Sie stattdessen von Kimi K3 nutzen können das derzeit beste Modell für Ihre Hardware.Primärquellen
- Kimi K3: Offene Frontier-Intelligenz – Start, Architektur, Benchmarks, Verfügbarkeit und Einschränkungen
- Kimi K3-API-Leitfaden – aktuelle Upstream-Modell-ID, Anfrageverhalten, Bildverarbeitung, Werkzeuge sowie Kontextgrenzen
- Forschungsarbeit zu Attention-Residuals – Konzept des Tiefen-Routings sowie Skalierungsexperimente
- Hardware-Übersicht zu DGX Spark – 128 GB gemeinsam nutzbarer Speicher, 273 GB/s Bandbreite sowie ConnectX-7
- NVIDIA-Anleitung zur Skalierung mit vier Spark-Systemen – unterstützte Anzahl an Knoten, 700B Positionierung sowie Kommunikationsgrenzen
Kimi K3
Verfolgen Sie die Verfügbarkeit von K3, die Hardware-Anforderungen sowie den Weg über Tokios, sobald die offiziellen Gewichte veröffentlicht werden.
Kimi-Modelle
Vergleichen Sie K3 mit den herunterladbaren Modellen K2.6 und K2.7-Code, die Sie heute selbst hosten können.
Was Sie statt K3 ausführen sollten
Der optimale Codier- und Allzweck-Modelltyp für Ihre Hardware – samt ausführlichen Anleitungen zur Deployment-Installation.
DGX Spark
Laden Sie Modelle, die zu Spark kompatibel sind, und stellen Sie anschließend einen privaten Tokios-Endpunkt bereit.
Modell-Bereitstellung und Skalierung
Tensor-, Pipeline- sowie Experten-Parallelismus – die zentralen Begriffe hinter den Anforderungen an Supernode-Konfigurationen.
Häufig gestellte Fragen
Wie viel VRAM benötigt Kimi K3?
Wie viel VRAM benötigt Kimi K3?
Etwa 1.4 Terabyte bei nativer MXFP4-Auflösung (4 Bit pro Parameter, insgesamt 2.8 Billionen Parameter), ohne Berücksichtigung von Block-Skalierungen, Laufzeit-Puffern, Aktivierungen sowie KV-Cache. In der Praxis erfordert ein Bereitstellungssystem deutlich mehr Speicherplatz; Moonshot empfiehlt daher mindestens 64 Beschleuniger in einer Supernode-Konfiguration.
Wie viele DGX Spark-Systeme werden für Kimi K3 benötigt?
Wie viele DGX Spark-Systeme werden für Kimi K3 benötigt?
Mindestens 11 Spark-Systeme reichen aus, um die erforderliche Speichermenge von 1.4 Terabyte zu erreichen (11 mal 128 GB ergibt 1,408 GB). Doch dabei bleibt kein Puffer für Betriebssystem, CUDA-Overhead, KV-Cache oder Inferenz-Zustände übrig. Eine realistische Schätzung liegt bei 14 bis 16 Spark-Systemen. Allerdings dokumentiert NVIDIA nur Spark-Cluster bis zu 4 Knoten (Gesamtspeicher: 512 GB); eine offiziell unterstützte K3-on-Spark-Topologie existiert nicht.
Warum passen MoE-Modelle wie K3 nicht in geringeren Speicher, obwohl nur 16 Experten aktiv werden?
Warum passen MoE-Modelle wie K3 nicht in geringeren Speicher, obwohl nur 16 Experten aktiv werden?
Die sparsame Aktivierung bei MoE-Modellen reduziert zwar die Rechenlast pro Token, nicht aber die Größe der gespeicherten Checkpoints. Alle 896 Expertengewichte müssen im gesamten Bereitstellungssystem verfügbar bleiben. Die aktiven Parameter in Höhe von etwa 50B Billionen bestimmen die Inferenzgeschwindigkeit (FLOPs pro Token); die Gesamtzahl der Parameter von 2.8 Billionen hingegen bestimmt den benötigten Speicherplatz.
Welche Hardware ist tatsächlich in der Lage, Kimi K3 auszuführen?
Welche Hardware ist tatsächlich in der Lage, Kimi K3 auszuführen?
Moonshot empfiehlt einen Supernode mit 64 oder mehr Beschleunigern – ein System mit hoher Bandbreite, in dem parallele Berechnungen optimal funktionieren. Consumer-GPUs (24 GB), prosumer-eigene Unified-Memory-Systeme (128 bis 192 GB) sowie sogar Spark-Cluster mit 4 Knoten (512 GB) erfüllen die Anforderungen von K3 bei weitem nicht.
Wann werden die Gewichte von Kimi K3 verfügbar sein?
Wann werden die Gewichte von Kimi K3 verfügbar sein?
Moonshot hat zugesagt, die herunterladbaren Gewichte im Juli 27, 2026 bereitzustellen. Die Lizenzbedingungen, das Modell-Dokument, das Manifest der Checkpoints sowie die Anleitungen zur Selbst-Hosting-Installation wurden bislang nicht veröffentlicht. vLLM bestätigte, dass es von Moonshot einen Beitrag zum KDA-Präfix-Caching erhalten hat; dieser soll am Tag 0 zusammen mit der offiziellen Veröffentlichung ausgeliefert werden.