Gebaut für lange Läufe
Kimi K3 – das Modell hinter dem Agenten, Teil 1
Seit Ende Juli 2026 ist Kimi K3 verfügbar. Es ist das weltweit erste offene Modell, das in die 3T-Klasse einsortiert ist. Damit sind Modelle mit bis zu 3 Billionen (im englischen T von Trillion) Parametern gemeint. Bei Kimi K3 geraten allerdings drei Ebenen leicht durcheinander: Das Sprach- und Bildmodell erzeugt Entscheidungen, Text und Tool-Aufrufe. Kimi Code stellt als Agent-Harness Dateizugriff, Shell, Sitzungen und Sicherheitsabfragen bereit. Produkte wie Kimi Work ergänzen Desktop-Zugriff, Zeitpläne und große Agentengruppen. Die häufig genannte Zahl von bis zu 300 Sub-Agenten beschreibt daher keine fest eingebaute Modelleigenschaft von Kimi. Sie stammt aus Moonshots Agent-Swarm-Produkten und deren Entwicklung über Kimi K2.5 und K2.6. Das Modell K3 liefert inzwischen das leistungsfähigere Modell für solche Umgebungen [Kimi Team] [Hugging Face].
Drei Schichten statt eines Produkts
Moonshot bezeichnet K3 als 2,8-T-Parameter-Mixture-of-Experts-Modell (MoE-Modell) [Hugging Face]. Pro Token aktiviert der Router 16 von 896 spezialisierten Experten sowie zwei gemeinsam genutzte Experten. Insgesamt arbeiten dabei rund 104 Milliarden Parameter aktiv. Die große Gesamtzahl bestimmt vor allem Wissens- und Modellkapazität, während die kleinere aktive Teilmenge den Rechenaufwand pro Token begrenzt. Sie beseitigt allerdings nicht den Speicherbedarf für sämtliche Gewichte: Ein selbst gehosteter Server muss auch seltener gewählte Experten vorhalten [Kimi Team], sodass sich die Anforderungen an Hosting und Hardware nicht beliebig nach unten skalieren lassen.
Drei Wege für Informationen
K3 verarbeitet Informationen auf drei Ebenen: entlang langer Eingaben, über die aufeinanderfolgenden Modellschichten und über parallel arbeitende Modellbereiche. Für lange Eingaben kombiniert jeder Block drei Kimi-Delta-Attention-Schichten (KDA)-Schichten mit einer Gated-MLA-Schicht. Die KDA-Schichten fassen bisherige Informationen in einem kompakten Speicher fester Größe zusammen. Anders als ein klassischer Key-Value-Cache wächst dieser Speicher nicht mit jedem zusätzlichen Token. Die regelmäßig eingefügten MLA-Schichten behalten zugleich den gesamten Kontext im Blick und erkennen Beziehungen zwischen weit auseinanderliegenden Textstellen. Dieses Verhältnis von 3:1 soll lange Eingaben bezahlbarer machen, ohne globale Beziehungen vollständig aufzugeben [Kimi Team].
Attention Residuals, kurz AttnRes, verbessern den Informationsfluss durch die vielen Schichten des Modells. Bei klassischen Residualverbindungen fließen frühere Ergebnisse fortlaufend in den aktuellen Zustand ein. AttnRes kann dagegen gezielt auswählen, auf welche Ergebnisse vorheriger Blöcke eine Schicht zugreift. Stable LatentMoE optimiert die Arbeit der parallel spezialisierten Experten. Ein kompakter Zwischenraum senkt den Aufwand für die Auswahl geeigneter Experten. Quantile Balancing verteilt die zu verarbeitenden Token gleichmäßiger auf sie. Zusammen mit weiteren Änderungen am Training erreicht K3 laut Moonshot eine ungefähr 2,5-fach höhere „Scaling Efficiency“ als Kimi K2. K3 nutzt die eingesetzte Trainingsrechenleistung demnach effizienter und erzielt damit eine höhere Modellqualität. Die Angabe bedeutet nicht, dass K3 Token grundsätzlich 2,5-mal schneller verarbeitet [Kimi Team].
Der MoonViT-V2-Encoder bereitet Bilder und Videos so auf, dass K3 sie gemeinsam mit Text verarbeiten kann. Laut technischem Bericht trainierte Moonshot beide Datenarten von Beginn an zusammen. Die Bildverarbeitung kam also nicht erst später als Zusatz hinzu, sondern gehört zum Kern des Modells. Dadurch kann ein Agent Screenshots, Diagramme oder CAD-Darstellungen direkt auswerten und die gewonnenen Informationen in den nächsten Arbeitsschritt einbeziehen. Das eignet sich etwa für die Frontend-Entwicklung, die visuelle Fehlersuche und die Arbeit mit technischen Zeichnungen [Kimi Team].
Eine Million Token sind kein Gedächtnis
Das Kontextfenster umfasst 1.048.576 Token. KDA benötigt keine explizite Positionscodierung. Seine rekurrenten Gates tragen Positionsinformation implizit. Moonshot trainierte zunächst mit kürzeren Sequenzen und verlängerte den Kontext schrittweise bis auf eine Million Token. Ein großes Fenster erlaubt umfangreiche Repository-Ausschnitte, lange Tool-Protokolle und mehrere Iterationen in einer Sitzung. Es garantiert aber weder perfekte Erinnerung noch kluge Auswahl. Unwichtige Logs, mehrfach geladene Dateien und veraltete Annahmen können relevante Fakten verdrängen. Kimi Code komprimiert deshalb lange Sitzungen und hält Sub-Agenten-Kontexte getrennt [Kimi Code CLI Docs].
Offen gewichtet, aber nicht vollständig Open Source
Moonshot veröffentlicht Modellgewichte, Konfiguration und technische Dokumentation unter einer eigenen Kimi-K3-Lizenz. Sie erlaubt Nutzung, Veränderung, Weitergabe, Fine-Tuning und kommerzielle Produkte grundsätzlich. Zwei Klauseln verdienen Aufmerksamkeit: Betreiber eines „Model as a Service“ mit mehr als 20 Millionen US-Dollar Gesamtumsatz in zwölf Monaten benötigen für kommerzielle Nutzung eine separate Vereinbarung. Produkte mit mehr als 100 Millionen monatlich aktiven Nutzern oder mehr als 20 Millionen US-Dollar Monatsumsatz müssen „Kimi K3“ prominent anzeigen. Für interne Nutzung und offizielle beziehungsweise zertifizierte Dienste gelten Ausnahmen [Kimi-K3 License].
Der präzisere Begriff lautet daher „Open Weight“. Die Open Source Initiative verlangt für Open Source AI zusätzlich ausreichende Informationen über Trainingsdaten und den zur Erzeugung der Parameter nötigen Code. K3 legt viele Architektur- und Trainingsdetails offen, aber keine vollständig reproduzierbare Daten- und Trainingspipeline. „Offen lizenziert“ passt als Kurzform, „Open-Source-Modell“ bleibt definitionsabhängig, denn darüber lässt sich sicherlich diskutieren [Kimi-K3 License].
Erster API-Aufruf mit Python
Das gehostete API spricht ein OpenAI-kompatibles Protokoll und ist mit dem OpenAI SDK kompatibel. Das in Listing 1 gezeigte Minimalbeispiel übergibt den Schlüssel ausschließlich per Umgebungsvariable und fordert eine strukturierte Analyse an.
Listing 1: Zugriff auf Kimi K3 über das OpenAI SDK
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["MOONSHOT_API_KEY"],
base_url="https://api.moonshot.ai/v1",
)
response = client.chat.completions.create(
model="kimi-k3",
reasoning_effort="high",
messages=[{
"role": "user",
"content": "Analysiere diese Python-Funktion auf Randfälle und liefere JSON."
}],
)
print(response.choices[0].message.content) K3 arbeitet grundsätzlich im Reasoning-Modus: Vor seiner Antwort analysiert das Modell die Aufgabe in mehreren internen Schritten. Der Parameter reasoning_effort steuert, wie viel Rechenaufwand K3 dafür einsetzt. low eignet sich für überschaubare Aufgaben und kurze Reaktionszeiten, high für komplexere Analysen und max für besonders anspruchsvolle, mehrstufige Probleme. Ein höherer Wert erhöht allerdings meist Laufzeit und Tokenverbrauch.
In längeren Dialogen muss jede neue API-Anfrage die vorherige Assistant-Nachricht vollständig in der Gesprächshistorie enthalten. Dazu gehören neben dem sichtbaren Antworttext auch der reasoning_content und bereits erzeugte tool_calls. K3 greift auf diese Informationen zurück, um frühere Entscheidungen, Werkzeugaufrufe und Zwischenergebnisse korrekt fortzuführen. Speichert eine Anwendung nur den sichtbaren Text, fehlt ein Teil des vorgesehenen Gesprächskontexts. Das kann die weitere Bearbeitung inkonsistent machen und zu wiederholten oder unpassenden Arbeitsschritten führen [Kimi Platform].
Kimi K3 bildet damit kein fertiges autonomes Entwicklungsteam. Es liefert ein außergewöhnlich großes, multimodales und agentisch trainiertes Fundament. Erst ein Harness gibt ihm Dateien, Terminal und Prüfschleifen, und erst eine Orchestrierung erzeugt parallele Agenten. Klare Rechte und Abnahmekriterien machen anschließend daraus einen belastbaren Workflow.
