Offen, aber nicht leicht
Kimi K3 – das Modell hinter dem Agenten, Teil 6
Die gute Nachricht: Offene Gewichte versprechen Kontrolle. Die schlechtere: Kimi K3 passt nicht unter einen Entwicklerschreibtisch. Das 2,8-Billionen-Parameter-Modell stellt hohe Anforderungen an Speicher, Netz und Inferenzsoftware. Für viele Teams bleibt deshalb ein API der pragmatische Einstieg. Diese letzte Folge der Serie zu Kimi K3 vergleicht Betriebswege, zeigt einen .NET-Aufruf und formuliert Leitplanken für lange, werkzeuggestützte Läufe.
2,8 Billionen Parameter in Betrieb
K3 aktiviert pro Token rund 104 Milliarden von insgesamt 2,8 Billionen Parametern. Ein Router leitet jedes Token nur an 16 der 896 spezialisierten Experten sowie an die gemeinsam genutzten Experten weiter. Diese dünne Aktivierung senkt den Rechenaufwand erheblich. Sie bedeutet jedoch nicht, dass sich die übrigen Gewichte aus dem Speicher entfernen lassen: Bei einem anderen Token kann der Router andere Experten auswählen. Für den Betrieb muss daher der vollständige Parametersatz erreichbar bleiben.
Die aktuelle vLLM-Recipe veranschlagt für den MXFP4-Checkpoint mindestens 1.680 GByte Grafikspeicher. Dabei handelt es sich nicht um eine gemessene Dateigröße, sondern um eine vorläufige Schätzung: 2,8 Billionen Parameter mal 0,5 Byte pro Parameter zuzüglich 20 Prozent Reserve. Als Mindestkonfiguration nennt die Recipe acht Nvidia-GB300- oder acht AMD-MI350X/MI355X-Beschleuniger. Mehrere Knoten empfiehlt sie für produktiven Datenverkehr. Die Mindestkonfiguration zeigt damit vor allem, dass sich das Modell laden lässt. Für parallele Anfragen, Zwischenspeicher und ausreichenden Durchsatz braucht ein Produktionssystem zusätzliche Kapazität [vLLM].
Als Inferenz-Engines empfiehlt Moonshot vLLM, SGLang und TokenSpeed. Solche Laufzeiten verteilen die Modellgewichte auf mehrere Beschleuniger, bündeln Anfragen zu Batches, verwalten Zwischenspeicher und stellen ein API bereit [Hugging Face]. Die Expertengewichte, die den größten Teil des Modells ausmachen, liegen im vier Bit breiten MXFP4-Format vor. Für die Ein- und Ausgaben der Expertenberechnungen nutzt K3 MXFP8 mit acht Bit. Attention-Projektionen, Router und weitere Nicht-Experten-Komponenten behalten eine höhere Präzision. Das spart Speicher und Speicherbandbreite, bringt aber Rundungsfehler mit sich. Deshalb bezog Moonshot die Quantisierung bereits ab dem Supervised Fine-Tuning und anschließend auch im Reinforcement Learning ein. Das Modell konnte sich so während des Post-Trainings an die reduzierte Genauigkeit anpassen [Kimi Team].
Ein EAGLE-3-artiges Draft-Modell beschleunigt zusätzlich die Token-Ausgabe. Dieses kleinere Modell schlägt mehrere Folgetoken vor, die das vollständige K3-Modell anschließend gemeinsam prüft. Akzeptiert K3 mehrere Vorschläge, spart das entsprechend viele einzelne Decoding-Schritte. Bei einer Abweichung verwirft das System die nicht bestätigten Folgetoken und setzt mit dem Hauptmodell fort. Lossless Speculative Sampling erhält dabei die Ausgabeverteilung des Hauptmodells, die Beschleunigung soll also nicht durch eine geringere Modellqualität erkauft sein [Kimi Team].
Auch Kimi Delta Attention (KDA) zielt auf lange Kontexte. Klassische Attention speichert für jedes vorherige Token Schlüssel- und Wertvektoren im KV-Cache, dessen Speicherbedarf mit der Kontextlänge wächst. KDA verdichtet die bisherige Sequenz dagegen in einen rekurrent aktualisierten Zustand fester Größe. In jedem Block nutzen drei von vier Attention-Schichten dieses Verfahren. Die jeweils vierte Schicht arbeitet als Gated MLA und behält globale Attention bei, deren Cache wächst weiterhin mit dem Kontext. K3 beseitigt den längenabhängigen Speicherbedarf daher nicht vollständig, reduziert ihn aber deutlich [Kimi Team].
Die passende Runtime allein garantiert dennoch keine niedrigen Antwortzeiten. Bevor K3 das erste Ausgabetoken erzeugt, muss es zunächst alle noch nicht zwischengespeicherten Eingabetoken verarbeiten. Lange Präfixe erhöhen deshalb die Time-to-First-Token. Ein Treffer im Prefix-Cache kann diese Vorverarbeitung überspringen, während ein Cache-Miss bei mehreren Hunderttausend Tokens erheblichen Rechenaufwand verursacht. Moonshots Serving-Architektur leitet eine Sitzung daher bevorzugt an den Cluster weiter, der ihr Präfix bereits gespeichert hat [Kimi Team].
Expert Parallelism verteilt die MoE-Experten auf mehrere Beschleuniger. Nach der Auswahl eines Experten müssen die zugehörigen Token zu dessen GPU gelangen und die Ergebnisse anschließend zurückfließen. Diese All-to-all-Kommunikation verlangt schnelle Verbindungen wie NVLink oder RDMA. Andernfalls wartet die Rechenhardware auf den Datentransfer. Zusätzlich trennt Moonshot kurze Anfragen mit weniger als 2.000 Token und sehr lange Anfragen mit bis zu einer Million Token in eigene Ressourcenbudgets. Eine Welle langer Kontexte kann dadurch nicht sämtliche Kapazität belegen und die Antwortzeit kurzer Anfragen verschlechtern [Kimi Team].
API statt eigener GPU-Flotte
Über das offizielle API lässt sich K3 unter dem Modellnamen kimi-k3 ansprechen. Das Kontextfenster umfasst 1.048.576 Token. Eingabe, bisheriger Gesprächsverlauf, Tool-Deklarationen und erzeugte Ausgabe teilen sich diesen Raum. K3 arbeitet stets mit aktiviertem Denken, vollständig abschalten lässt es sich nicht. Der Parameter reasoning_effort steuert mit low, high oder max lediglich, wie viel Aufwand das Modell investiert. max bildet den Standardwert. Ein geringerer Wert kann bei einfachen Aufgaben die Latenz und den Tokenverbrauch reduzieren.
Stand August 2026 berechnet Moonshot 0,30 US-Dollar pro Million Cache-Hit-Token, 3 US-Dollar pro Million reguläre Eingabe-Token und 15 US-Dollar pro Million Ausgabe-Token. Cache-Hit-Token stammen aus einem bereits verarbeiteten Anfang des Prompts. Neue oder geänderte Eingabeteile zählen dagegen zum regulären Preis. Gerade bei langen Agentensitzungen fallen deshalb nicht nur die sichtbaren Antworten ins Gewicht, sondern auch wiederholt übertragene Gesprächsverläufe, Tool-Ergebnisse und Reasoning-Inhalte. Preise und Limits bleiben Momentaufnahmen. Ein Produktionssystem sollte sie konfigurierbar halten und Kostenberechnungen regelmäßig mit der aktuellen Preisseite abgleichen, statt Beträge im Programmcode festzuschreiben [Kimi K3 Pricing].
Das automatische Context Caching benötigt keine Cache-ID und keine manuelle Verwaltung der Lebensdauer. Das API sucht selbst nach wiederkehrenden Präfixen, also nach identischen Tokenfolgen am Anfang mehrerer Anfragen. Ein vorheriger Prompt kommt allerdings erst ab einer Länge von mehr als 256 Token für einen späteren Cache-Treffer infrage. Stabile Systemprompts, Wissensdokumente, Tool-Schemas und Repository-Snapshots gehören deshalb möglichst an den Anfang. Veränderliche Angaben wie Zeitstempel, aktuelle Nutzerfragen oder neue Arbeitsergebnisse sollten erst danach folgen. Ändert sich ein frühes Token, lässt sich der dahinterliegende Teil des Präfixes unter Umständen nicht mehr wiederverwenden [Context Caching Feature].
Ein Cache-Treffer spart Kosten und die erneute Vorverarbeitung des bereits bekannten Präfixes. Das kann insbesondere bei großen Codebasen oder langen Agentensitzungen die Time-to-First-Token verkürzen. Das Caching verkleinert den logischen Kontext jedoch nicht: Alle zwischengespeicherten Inhalte belegen weiterhin Platz im Kontextfenster und fließen in die Modellverarbeitung ein. Veraltete, widersprüchliche oder irrelevante Informationen können K3 daher trotz Cache-Treffer ablenken. Context Caching optimiert den wiederholten Zugriff, ersetzt aber keine Auswahl und Pflege des tatsächlich benötigten Kontexts [Context Caching Feature].
K3 beherrscht Tool-Aufrufe, JSON-Modus und strukturierte Ausgaben. Bei einem Tool-Aufruf liefert das Modell den Namen einer Funktion und deren Argumente. Erst die Anwendung führt die Funktion aus und gibt das Ergebnis an K3 zurück. Der JSON-Modus garantiert ein syntaktisch gültiges JSON-Objekt, legt aber keine bestimmten Felder fest. Strukturierte Ausgaben gehen demgegenüber weiter: Ein JSON-Schema definiert Feldnamen, Datentypen und Verschachtelungen, sodass nachgelagerte Programme das Ergebnis zuverlässiger verarbeiten können [Kimi K3 Pricing].
Bei Agenten mit Dutzenden oder Hunderten Werkzeugen sollte nicht jede Anfrage den vollständigen Werkzeugkatalog enthalten. Jede Deklaration verbraucht Kontext und vergrößert die Auswahl, aus der das Modell ein Werkzeug bestimmen muss. Moonshot empfiehlt deshalb, zunächst nur eine Suchfunktion wie search_tools sowie wenige häufig benötigte Werkzeuge bereitzustellen. Die Anwendung sucht damit passende Kandidaten und fügt anschließend nur deren vollständige Deklarationen in einer zusätzlichen Systemnachricht ein. tool_choice: "required" kann den ersten Suchaufruf erzwingen, danach erlaubt auto dem Modell wieder eine freie Entscheidung [API Tool Calling].
Dynamisch geladene Tool-Deklarationen gelten jeweils nur für die aktuelle Anfrage. Soll K3 ein Werkzeug in einem Folgeturn weiterhin aufrufen können, muss der Client dessen Deklaration erneut als Teil des Gesprächsverlaufs übertragen. Bleibt sie dort unverändert enthalten, kann zugleich der bisherige Präfix-Cache nutzbar bleiben. Entfernt oder verändert die Anwendung eine frühere Deklaration, steht das Werkzeug nicht mehr zur Verfügung und der geänderte Abschnitt kann einen Cache-Miss verursachen [API Tool Calling].
Minimaler Aufruf aus .NET
Ein simpler HttpClient vermeidet Abhängigkeit von einer bestimmten SDK-Version und nutzt, wie in Listing 1 gezeigt, das OpenAI-kompatible Chat-Completions-Format:
Listing 1: Aufruf von Kimi K3 (API) mittels HttpClient in .NET
using System.Net.Http.Headers;
using System.Net.Http.Json;
var key = Environment.GetEnvironmentVariable("MOONSHOT_API_KEY")
?? throw new InvalidOperationException("API key missing");
using var http = new HttpClient {
BaseAddress = new Uri("https://api.moonshot.ai/v1/")
};
http.DefaultRequestHeaders.Authorization =
new AuthenticationHeaderValue("Bearer", key);
var request = new {
model = "kimi-k3",
reasoning_effort = "high",
messages = new[] {
new { role = "user",
content = "Prüfe den Patch auf Race Conditions. Antworte als JSON." }
}
};
using var response = await http.PostAsJsonAsync("chat/completions", request);
response.EnsureSuccessStatusCode();
Console.WriteLine(await response.Content.ReadAsStringAsync()); Für einen produktiven Einsatz müssen Time-out, CancellationToken, gezielte Retries, Kostenmetriken und strukturierte Deserialisierung ergänzt sein. Schlüssel gehören in Secret Stores. Tool-Schleifen müssen die vollständige Assistant-Nachricht einschließlich reasoning_content und tool_calls in die Historie übernehmen [Hugging Face].
Lizenz und Datenpfad vor Architektur
Self-Hosting kontrolliert Runtime, Netzpfad und Protokolle, hebt die Lizenz aber nicht auf. Große Model-as-a-Service-Anbieter benötigen ab der Umsatzschwelle eine Vereinbarung, und sehr große Produkte trifft eine Pflicht zur Namensnennung. Open Weight legt zudem nicht automatisch Trainingsdaten und Trainingspipeline offen [Kimi K3 License] [Open Source AI].
Beim API-Betrieb verlassen Quelltext und Toolergebnisse die Infrastruktur. Vertrag, Speicherfristen, Standort und Trainingsnutzung bestimmen zulässige Daten. Retrieval-Regeln schließen Secrets, Kundendaten und irrelevante Dateien aus.
In der EU greifen je nach Rolle AI Act, Datenschutz, Urheberrecht und Branchenregeln. Für Anbieter von General-Purpose-AI-Modellen gelten besondere Pflichten. Anwender müssen vor allem Zweck, Datenfluss, Aufsicht und Softwarelieferkette klären. Open Weight schafft keine Compliance-Ausnahme [EUR-Lex].
Ein offenes Fundament, kein Selbstläufer
Kimi K3 verbindet offene Gewichte, native Multimodalität und Training für lange Tool-Schleifen. Benchmarks zeigen Stärken in Webentwicklung, Terminalarbeit und Orchestrierung, aber auch Lücken zu führenden proprietären Modellen. Kimi Code nutzt das Modell lokal, Agent Swarm skaliert geeignete Aufgaben parallel.
Der produktive Wert entsteht nicht durch maximale Autonomie. Er entsteht, wenn ein Team Aufgaben so formuliert, dass Maschinen sie prüfen können, Zugriffe technisch einschränkt und Ergebnisse wie jeden anderen Patch behandelt. Dann entwickelt sich K3 vom spektakulären Modell zu einem brauchbaren Baustein für langlaufende Engineering-Workflows.
