Kimi K3.1 Pro: Sparse-Zugriffe, keine kleinere Historie

Eine konkrete Änderung gegenüber K3

Mit Stand 5. November 2026 enthält Moonshots Repository Kimi-K3.1-Pro herunterladbare Gewichte in 96 Safetensors-Shards. Dieser Guide legt den Checkpoint auf d9e99b0792a5e93b78ea9bea62a68167e36ddd9e und den SGLang-Code auf 93e6b42d8afa99702547eeeb340986884c9616a3 fest. Es handelt sich um ein veröffentlichtes Modell, nicht um eine aus einer Ankündigung abgeleitete Architektur.¹²

Die relevante Änderung gegenüber unserem Kimi-K3-Architekturguide ist präzise: Die 24 Gated-MLA-Schichten verwenden jetzt DeepSeek Sparse Attention (DSA). Die 69 Kimi-Delta-Attention-Schichten (KDA) bleiben rekurrent. Sparse-Zugriffe auf globale Historie ergänzen rekurrente Zusammenfassungen; sie verwandeln den globalen Cache nicht in eine Zusammenfassung fester Größe.³² Für diesen Artikel wurden keine Modellinferenz, Qualitäts- oder Durchsatzbenchmarks ausgeführt.

Was ändert sich – und was nicht?

Die Residualbreite bleibt 7.168, bei 93 Schichten. Einsbasiert sind 4, 8, …, 92, 93 die globalen Schichten; die übrigen 69 verwenden KDA. Die Textkonfiguration behält KV-Latentrang 512, Query-Latentrang 1.536, 96 Haupt-Attention-Heads und 128 breite Value-Heads bei. Ebenfalls erhalten bleiben Block Attention Residuals mit Blockgröße 12 sowie LatentMoE mit Breite 3.584, 16 von 896 gerouteten Experts und zwei Shared Experts. Diese übernommenen Mechanismen erklärt der K3-Guide; DSA ersetzt nicht den MoE-Router.²

Der neue Indexer besitzt 32 Query-Heads mit Breite 128, einen gemeinsamen 128-breiten Index-Key je gespeicherter Position und ein Auswahlbudget von 2.048 Positionen. Das ist eine separate, günstigere Darstellung zur Positionsauswahl, nicht das komprimierte K/V der Haupt-Attention. Die gepinnte SGLang-Konfiguration verlangt ausdrücklich index_topk_freq = 1: Jede globale Schicht führt ihren eigenen Indexer aus. Schichtübergreifende Indexwiederverwendung anderer DSA-Modelle darf man nicht übertragen.⁴⁵

Eine Query durch den Indexer verfolgen

Bei $T$ Query-Positionen und $S$ zulässigen Cache-Positionen projiziert der Indexer den Query-Latent auf [T,32,128]. Eine andere Projektion bildet Residualzustände auf Keys der Form [S,128] ab, gefolgt von LayerNorm; eine weitere erzeugt aus dem Residualzustand jeder Query 32 Head-Gewichte. Der Scoring-Pfad berechnet Positionsscores und wählt danach bis zu 2.048 kausale Kandidaten je Query. Das resultierende Positions-ID-Array hat logisch die Form [T,2048]; ungültige Einträge und kurze Präfixe behandelt das Backend.⁵

Der Adapter ist entscheidend: K3.1 spezifiziert index_rope_dim = 0, LayerNorm statt RMSNorm für Index-Keys, FP32-Key-Normalisierung, keine Hadamard-Transformation und einen BF16-Head-Gate-Pfad. Das sind explizite Implementierungsentscheidungen, keine von DeepSeeks Indexer zu übernehmenden Standardannahmen. Indexer und Haupt-Attention sind außerdem vom Expert-Routing zu unterscheiden: Einer wählt Positionen, das andere FFNs.⁴

Die globale Haupt-Attention bleibt eine gegatete MLA-Implementierung mit skip_rope=True. NoPE bedeutet hier keine Rotationsoperation in diesem Pfad, nicht „alle Koordinaten der konfigurierten RoPE-Breite entfallen“. Der Konstruktor übergibt weiterhin eine 64 breite begleitende Key-Komponente neben dem 512 breiten Latent. Die RoPE-Breite null des Indexers ist eine separate Einstellung.⁶

Nach der Sparse Attention wendet SGLang vor der Ausgabeprojektion ein gelerntes, koordinatenweises Sigmoid-Ausgabegate an. Weder Indexer-Score noch Gate sind Wahrscheinlichkeiten dafür, dass ein abgerufener Fakt stimmt. KDA, globale Attention, Tiefenmischung und Expert-Routing behalten unterschiedliche Aufgaben und Zustände.

Die Mathematik der Sparse Attention und ihrer fehlenden Masse

$s_{tj}$ sei der gelernte Indexer-Score für Query $t$ und zulässige Position $j$. $I_t$ enthalte die bis zu 2.048 Positionen mit den höchsten Scores. Für einen Head der Haupt-Attention sei dessen anderer Attention-Logit $a_{tj}$. Der Sparse-Read ist ein auf $I_t$ beschränkter Softmax:

Diese Notation abstrahiert absorbierte MLA-Projektionen und Gleitkomma-Kernels. Sie behauptet nicht, dass die Laufzeit alle headspezifischen K/V materialisiert. Auswahlscores $s$ sind nicht die Haupt-Attention-Logits $a$. Ein hoher Indexer-Rang garantiert daher mathematisch keine hohe Haupt-Attention-Masse.

Eine illustrative Schranke macht diese Grenze deutlich. Logits und Values seien festgehalten; verglichen wird mit einem hypothetischen vollständigen Read. Ist $\epsilon$ die volle Softmax-Masse außerhalb von $I_t$, dann gilt:

Der Beweis verwendet nur, dass behaltene und verworfene Reads konvexe Kombinationen beschränkter Values sind. Kleine verworfene Masse kann also den lokalen Read-Fehler eines Heads begrenzen. Die Schranke sagt nichts darüber, ob dieser Indexer die Masse tatsächlich behält. Sie begrenzt auch nicht die endgültige Tokenverteilung nach Ausgabeprojektion, Residualmischung und späteren Schichten und vergleicht keine unabhängig trainierten Checkpoints. Ein empirischer Wert für $\epsilon$ wurde hier nicht gemessen.

Warum Top-2048 keinen 2048-Token-Cache bedeutet

An der konfigurierten Kontextgrenze von 1.048.576 Tokens entsprechen 2.048 Positionen 1/512 beziehungsweise 0,1953125 % dieser Länge. Das ist ein arithmetischer Vergleich der abschließenden Auswahlbreite, keine 512-fache End-to-End-Beschleunigung. Index-Scoring und Top-k arbeiten weiterhin über die zulässige Historie; deren Keys müssen für eine andere zukünftige Query verfügbar bleiben. Präfix-Prefill, Rekurrenz, MoE-Datenverkehr und Kernel-Scheduling kommen hinzu.²⁵

Ein transparentes Referenzbudget zeigt den Unterschied. Angenommen, eine Anfrage speichert pro globaler Schicht und Position eine MLA-Darstellung mit 512+64 Elementen sowie einen Index-Key mit 128 Elementen, alles in BF16. Dann gilt:

Diese hypothetischen Nutzdaten ergeben 33 KiB/Token beziehungsweise 33 GiB bei voller konfigurierter Länge. Das ist keine gemessene oder universelle Laufzeitallokation: Index-/MLA-Quantisierung, Skalenmetadaten, Padding, Sharding, Replikation, Offload und Seitenallokation verändern den physischen Speicher. Entscheidend ist die Abhängigkeit von $S$, nicht der konkrete Datentyp. Rekurrenz-/Faltungszustände der KDA, Präfix-Checkpoints, Gewichte und Workspaces kommen hinzu. Siehe den Guide zur KV-Cache-Dimensionierung.

Den gemeinsam genutzten 512 breiten Latent darf man nicht mit allen 96 Haupt-Heads multiplizieren, als wären es gewöhnliche unabhängige headspezifische KV-Vektoren. Umgekehrt bedeuten MXFP4-Expert-Gewichte keinen Vier-Bit-Cache. In der Quantisierungskonfiguration steht kv_cache_scheme = null; Gewichts- und Cache-Präzision sind getrennte Entscheidungen.²⁶

Was ein Deployment validieren muss

Der Checkpoint nimmt Attention, Shared Experts, Vision/Projector und mehrere weitere Projektionen von seiner MXFP4-Gewichtsgruppe aus. Die aktive Parameterzahl ist nicht die residente Checkpoint-Größe. Engine festlegen und prüfen, ob der Loader KimiK31ForConditionalGeneration instanziiert, die verschachtelte DSA-Konfiguration liest und Indexer-Parameter lädt. Das gepinnte SGLang-Modell prüft explizit auf fehlende Indexer-Gewichte; ein stillschweigend verwendeter dichter K3-Pfad würde diese Architektur nicht reproduzieren.²⁶

Das offizielle vLLM-Rezept unterscheidet Basis-Serving von optionalen DCP-, Cache-Präzisions- und Speculative-Decoding-Konfigurationen. Sein Durchsatzmodus mit synthetischer Akzeptanz überspringt echte Verifikation und ist ausdrücklich ungeeignet für Nutzer-Serving oder Genauigkeitsevaluation. Das ist eine Benchmark-Abkürzung, keine gültige Decoder-Einstellung. Laut Rezept wurde für die optionale NVFP4-MLA-Cache-Variante außerdem keine Langkontextgenauigkeit gemessen. Keine der beiden Optionen darf als qualitätserhaltender Standard dargestellt werden.⁷

Hier werden keine Durchsatzwerte übernommen. Für eine Deployment-Evaluation Hardware, Parallelität, Präzision, Ein-/Ausgabelängen und Qualitätskriterien konstant halten. Indexer-Zeit getrennt von Sparse Attention, Peak-Speicher, Prefill-Latenz, Decode-Latenz sowie Langkontext-Retrieval-/Agent-Erfolg messen. Bei Wiederverwendung von KDA- und globalen Caches alle Zustände an derselben Präfixgrenze speichern. Eine Million Tokens Kontextlimit garantiert keinen Recall.

Praktische Konsequenz

K3.1 Pro ist ein Evaluationskandidat, wenn langlebige Agentensitzungen das Lesen einer großen globalen Historie teuer machen, während rekurrente Schichten kompakte Kontextmischung liefern. Das ist eine aus dem Mechanismus abgeleitete, zu prüfende Hypothese, keine Empfehlung anhand eines Launch-Scores. Weder alle Expert-Gewichte noch alte Cache-Einträge verschwinden dadurch.

Anders als bei Step-5s Sparse GQA ist die behaltene globale Darstellung hier MLA-komprimiert und mit KDA kombiniert. Gegenüber DeepSeek V4.1 Flash darf man nicht dieselbe Kompressions- oder Indexwiederverwendungsstrategie annehmen. Die nützliche Erkenntnis: Auswahlarbeit, ausgewählte Reads, gespeicherte Historie und Approximationsqualität getrennt dimensionieren.

Primärquellen