Kimi K3 ist ein veröffentlichtes multimodales Modell mit offenen Gewichten, kein bloßer Architekturvorschlag. Moonshot veröffentlichte im Juli und August 2026 die Gewichte, die Model Card, die Checkpoint-Konfiguration und den Technical Report. Die Model Card dokumentiert API-Zugang und Deployment-Anleitungen. Dieser Artikel behandelt den veröffentlichten Checkpoint moonshotai/Kimi-K3; die Leistungsangaben des Teams sind keine unabhängigen Serving-Messungen.123
Drei Achsen sind wichtig: Kimi Delta Attention (KDA) komprimiert den Tokenverlauf in einen rekurrenten Zustand. Periodisch eingesetzte Gated Multi-head Latent Attention (MLA) erhält globalen Zugriff auf Token. Attention Residuals (AttnRes) wählen Informationen aus früheren Schichten. Stable LatentMoE verteilt den Feedforward-Pfad sparse auf Experten. Keiner dieser Mechanismen ist eine gelernte N-Gram-Tabelle: Der Artikel zu Qwen3.8-Flash-Next erklärt diese andere Art von Parameterspeicher.3
Aufbau des Checkpoints
| Teil | Veröffentlichter Wert | Bedeutung |
|---|---|---|
| Backbone | 93 Attention-Schichten, Hidden-Dimension 7.168; insgesamt 2,8 Billionen und pro Token 104 Mrd. aktivierte Parameter | Aktive Berechnung und gespeicherte Gewichte brauchen unterschiedliche Budgets.1 |
| Sequenz-Mixer | 69 KDA- und 24 Gated-MLA-Schichten | Schichten 1–92 folgen dem Muster drei KDA, dann eine MLA; Schicht 93 ist eine zusätzliche MLA-Schicht.32 |
| Gerouteter Feedforward-Pfad | Latent-Dimension 3.584; 896 geroutete Experten, 16 pro Token gewählt, dazu zwei gemeinsame Experten in voller Breite | Das Routing schickt einen Vektor mit halber Hidden-Dimension an die ausgewählten Experten.13 |
| Schicht-Mixer | Block AttnRes mit zwölf Schichten pro Block | Acht vollständige bzw. teilweise gefüllte Schichtblöcke; das Embedding ist eine weitere Quelle.32 |
| Bildpfad | MoonViT-V2 mit 27 Schichten und rund 401 Mio. Parametern | Visuelle Merkmale werden in den gemeinsamen Sprach-Backbone projiziert.31 |
| Kontext | max_position_embeddings: 1048576 | Eine unterstützte Kontextobergrenze, keine Zusage für günstige Anfragen mit einer Million Token.2 |
Die Konfiguration markiert eine anfängliche dichte Feedforward-Schicht (first_k_dense_replace: 1). Die 93 Attention-Stellen teilen sich trotzdem in 69 KDA und 24 MLA. Der rekurrente KDA-Zustand, die MLA-KV-Einträge pro Token und die früheren Schichtrepräsentationen von AttnRes sind drei verschiedene Laufzeitzustände.23
Sequenz-Mixing: KDA-Zustand und globale MLA
Für einen KDA-Head definiert der Report Query- und Key-Vektoren der Dimension , Value-Vektoren der Dimension und eine rekurrente Matrix . Bei jedem Token schwächt ein Retentionsvektor den alten Zustand kanalweise ab. Ein skalares Schreib-Gate wendet danach eine Delta-Rule-Korrektur an, bevor die Query liest. Deshalb muss eine KDA-Schicht nicht für jedes vorherige Token einen KV-Vektor speichern. Die veröffentlichte Konfiguration nennt 96 Heads der Dimension 128 und eine kurze Faltung der Breite 4 für die KDA-Projektionen. Die Zustandsgröße hängt nicht von der Sequenzlänge ab; dieser endliche Zustand bietet aber keinen exakten, uneingeschränkten Direktzugriff auf jedes alte Token.32
Beim Prefill verarbeitet KDA Token innerhalb eines Chunks parallel und reicht den rekurrenten Zustand zwischen Chunks weiter. Die kausale Matrix innerhalb des Chunks enthält die Diagonale, weil jede Position den Zustand nach ihrer eigenen Aktualisierung liest. Der Zahlenbereich ist wichtig: Der veröffentlichte Log-Decay ist durch begrenzt. Dadurch liegt der Retentionsfaktor eines Schritts über . Bei einer Kachel mit 16 Token bleibt der kumulative Log-Decay über . Laut Report können dadurch die diagonalen und die übrigen Kacheln Tensor-Core-Matrixmultiplikationen statt eines expliziten Verfahrens für Positionspaare nutzen. Das begrenzt den Zahlenbereich für den Kernel, nicht den Informationsverlust über eine Million Token.32
Jede vierte Schicht bis Schicht 92 sowie nochmals Schicht 93 nutzt Gated MLA. MLA speichert eine komprimierte Tokenrepräsentation statt vollständiger Head-spezifischer Keys und Values; der Checkpoint setzt den KV-Latent-Rang auf 512. Anders als bei Kimi K2 nutzt der MLA-Pfad laut K3-Report NoPE: Auf seine Queries und Keys wird keine explizite Positionskodierung angewandt. Die KDA-Schichten dazwischen liefern positionsabhängiges Mixing. KDA und MLA besitzen jeweils eingabeabhängige Output-Gates; diese wirken auf die Ausgabe des jeweiligen Attention-Pfads und sind vom MoE-Router zu unterscheiden.32
Die Kombination benötigt somit keinen konstanten Speicher pro Anfrage: 69 KDA-Zustände bleiben von der Kontextlänge unabhängig, während 24 MLA-Caches mit dem behaltenen Kontext wachsen. Für Prefix-Reuse müssen KDA-Zustand und MLA-KV am gleichen Tokenübergang wiederhergestellt werden. Der Report beschreibt einen gemeinsamen Page-Pool und nur vereinzelt gespeicherte KDA-Checkpoints; Letztere begrenzen, welche Präfixe ohne Neuberechnung wiederverwendbar sind. Der VRAM-Leitfaden behandelt Gewichts- und KV-Budgets allgemein.3
Mixing über Schichten: Block Attention Residuals
Bei gewöhnlicher Residual-Addition werden frühere Schichten in einem fortlaufenden Vektor weitergereicht. AttnRes bewertet stattdessen frühere Repräsentationen mit einer gelernten, schichtspezifischen Query, normalisiert jeden Kandidaten vor der Bewertung mit RMSNorm und normiert die Gewichte per Softmax über die Tiefe, für jedes Token. Die vollständige Form müsste alle Schichtausgaben halten. K3 nutzt Block AttnRes: Ausgaben innerhalb eines Zwölf-Schichten-Blocks werden summiert. Spätere Schichten greifen auf die Zusammenfassungen abgeschlossener Blöcke, das Embedding und die bisherige Summe des aktuellen Blocks zu. Der Report nennt acht Schichtblöcke und neun Quellen einschließlich Embedding.32
Das ist Attention über Schichten, nicht über frühere Tokenpositionen. Die Blockform reduziert die Zahl gespeicherter Tiefen-Zusammenfassungen von der Größenordnung auf , wobei die Schichtzahl und die Blockzahl ist. Die Teilsumme des aktuellen Blocks und die normalen Inferenzaktivierungen werden weiterhin benötigt. Der sequenzabhängige MLA-KV-Cache entfällt dadurch nicht.3
Mixing über Kanäle: 16-von-896 Stable LatentMoE
Für einen Hidden-Vektor projiziert der geroutete Pfad zunächst auf . Ein Sigmoid-Router wählt 16 von 896 Expertennetzen. Ihre Ausgaben werden mit Router-Gewichten multipliziert und in der Latent-Dimension summiert. Auf RMSNorm folgt eine Rückprojektion auf Dimension 7.168. Zwei gemeinsame Experten verarbeiten den Eingabevektor direkt in voller Breite; ihre Ausgaben werden zum gerouteten Pfad addiert. Die dokumentierte Intermediate-Dimension pro Experte beträgt 3.072. Die Auswahl hängt vom Token ab. „104 Mrd. aktivierte Parameter“ bedeutet nicht, dass die übrigen Gewichte beim Serving fehlen dürfen.312
Die Feedforward-Aktivierung SiTU-GLU begrenzt beide multiplizierten Zweige sanft durch skalierte tanh-Funktionen. Die veröffentlichten Grenzparameter sind 4 und 25; vor nachfolgenden Projektionen ist das elementweise Produkt damit auf den Betrag 100 beschränkt. Quantile Balancing passt während des Trainings die Bias-Werte für die Expertenwahl anhand der Batch-Auslastung an; laut Report sind die Bias-Werte bei der Inferenz eingefroren. Der Router nutzt sie zur Auswahl, gewichtet die Ausgaben aber mit den ursprünglichen Sigmoid-Scores. Das sind konkrete Regeln für Stabilisierung und Routing, kein Beleg für gleichmäßigen Expertenverkehr bei jeder einzelnen Serving-Anfrage.32
Gewichte, Multimodalität und Betriebsgrenzen
Die Model Card nennt natives, quantisierungsbewusst trainiertes MXFP4 für Gewichte / MXFP8 für Aktivierungen. Die veröffentlichte config.json ist genauer: Eine compressed-tensors-Gruppe adressiert bestimmte Linear-Gewichte in MXFP4 mit Gruppengröße 32. Ausschlussregeln nehmen unter anderem Attention, gemeinsame Experten, den Sprachmodell-Head, den Vision-Tower, den Multimodal-Projektor und weitere Projektionen aus. Deshalb ist „2,8 Billionen Parameter × vier Bit“ keine belastbare Schätzung der Checkpoint- oder Gerätespeichergröße. Die Quantisierungskonfiguration legt auch keinen universellen Aktivierungsdatentyp für jeden Runtime-Kernel fest.12
MoonViT-V2 kodiert visuelle Eingaben; danach führt ein MLP-Projektor sie dem Sprach-Backbone zu. Der Report behandelt Bilder und Videos. Die Modellübersicht in der Model Card nennt Text und Bilder, ihre Einleitung erwähnt auch Videos. Ob ein bestimmtes Videoeingabeformat funktioniert, hängt vom veröffentlichten Prozessor und der Serving-Schnittstelle ab. Ein allgemeines Text/Bild-Beispiel belegt nicht jeden Videopfad.31
Moonshot stellt Modellgewichte bereit und empfiehlt vLLM, SGLang und TokenSpeed für das Deployment; die Model Card dokumentiert außerdem die kimi-k3-API. Eine reale Installation muss trotzdem alle Expertengewichte, Tensoren in verschiedenen Präzisionen, 24 mit dem Kontext wachsende MLA-Caches, KDA-Zustände und -Checkpoints sowie MoE-Kommunikation einplanen. Die Benchmark- und Skalierungseffizienz-Zahlen des Teams gelten für dessen eigene Testbedingungen und sind keine Durchsatzgarantie. Zum Vergleich beschreibt der Artikel zur DeepSeek-V4.1-Flash-Architektur andere Entscheidungen für Speicherung und Replay.13
Quellen
Footnotes
-
Moonshot AI, offizielle Kimi-K3-Model-Card und Deployment-Anleitung. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8
-
Moonshot AI, veröffentlichte Kimi-K3-
config.json. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 -
Kimi Team, Kimi K3: Open Frontier Intelligence, arXiv:2607.24653v2, 7. August 2026. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17