Kimi K3: Komplettguide zu Moonshots 2.8T-Flaggschiff

Moonshot AI veröffentlichte Kimi K3 Mitte Juli 2026 in umgekehrter Reihenfolge: API-Dokumentation, Preisseite und eine funktionierende Modell-ID kimi-k3 erschienen vor jeder Benchmark-Tabelle, jedem Technikbeitrag und jeder Gewichtsveröffentlichung^[1]. Eine Woche lang füllten Leak-Diskussionen das Vakuum, und fast jede kursierende Version lag in mindestens einem Punkt falsch. Dieser Leitfaden stützt sich auf Moonshots eigene Dokumentation: was bestätigt ist, was absichtlich feststeht und was noch nicht veröffentlicht wurde.

Er hat außerdem einen klaren Blickwinkel: Wir stellen Kimi K3 über das reAPI-Gateway bereit. Daher geht es nicht nur darum, was das Modell ist, sondern wie Aufrufe tatsächlich funktionieren — welche Parameter Anfragen ablehnen lassen, wie das Caching die Rechnung bestimmt und welche Migrationsfallen auf K2.x-Code warten.

Kurzfassung

• Kimi K3 ist ein Flaggschiff mit 2.8 Billionen Parametern, aufgebaut auf Kimi Delta Attention, einem hybriden linearen Aufmerksamkeitsmechanismus, und Attention Residuals. Stable LatentMoE aktiviert pro Token 16 von 896 Experten^[1][3].
• Das Kontextfenster umfasst 1 048 576 Tokens bei einheitlichem Preis — ohne Langkontextstufe. Moonshots native API setzt das Ausgabelimit standardmäßig auf 131 072 Tokens und erlaubt Werte bis 1 048 576, sofern Eingabe plus Limit in das Fenster passen^[1][2][9].
• Reasoning ist immer aktiv. Der einzige Regler ist reasoning_effort mit drei Stufen (low / high / max, kein medium), standardmäßig max^[4].
• Sampling ist gesperrt: temperature 1.0, top_p 0.95, n 1 und beide Penalties 0. Andere Werte führen zu einem Fehler^[1].
• Moonshots veröffentlichter Preis beträgt $3.00 Input / $15.00 Output je 1M Tokens ($0.30 für Cache-Hit-Input). Bei reAPI läuft dasselbe Modell für $2.50 / $12.00 und liegt auf beiden Seiten darunter^[2][8].
• Vision ist nativ für Bild- und Videoeingaben, öffentliche Bild-URLs werden jedoch abgelehnt. Erlaubt sind base64 oder Referenzen auf hochgeladene Dateien^[5].

Kimi K3 auf einen Blick

Alle Angaben in dieser Tabelle stammen aus Moonshots API-Dokumentation, abgerufen am 26. Juli 2026:

Zwei Zahlen verdienen einen zweiten Blick. Mit 2.8T Parametern erreicht K3 eine Klasse, in der noch kein Open-Weight-Modell lag. Moonshot hat die Veröffentlichung der Gewichte zugesagt, womit es das erste Open-Source-Modell der 3-Billionen-Klasse wäre^[3]. Dazu kommt der Preis: Mit $3.00 / $15.00 kostet K3 drei- bis viermal so viel wie die K2-Reihe. Moonshot bepreist es als Frontier-Flaggschiff statt als günstige Option, die der Name Kimi bisher versprach, unterbietet aber geschlossene Frontier-Modelle weiterhin bei Input und Output.

Der Start: erst die API, später die Belege

Die Reihenfolge erklärt widersprüchliche Angaben, die noch kursieren. Kurz vor dem Start sahen Community-Tracker eine Promo-Seite auf Moonshots Plattform und Beta-Auswahlen in der Kimi-App. Die Leaks einigten sich auf „etwa 2.5T Parameter, 1M Kontext“. Das lag nahe, offiziell sind es aber 2.8T. Ein wortloses Teaser-Video vom offiziellen Moonshot-Konto folgte, dann überholte das Produkt den Pressezyklus: API-Dokumentation, Quickstart und Preisseite gingen am selben Tag online wie die ersten Finanzberichte zum Start^[1][2].

Diese Abfolge — API und Dokumentation vor Benchmarks und Gewichten — kehrt den Start der K2-Flaggschiffe um, die jeweils am ersten Tag einen vollständigen Technikbeitrag und offene Gewichte mitbrachten. Praktisch bedeutete das: In K3s erster Woche war die Dokumentation die einzige verlässliche Quelle, alles andere war Ableitung.

Architektur: Kimi Delta Attention, LatentMoE, Attention Residuals

Die technisch interessanteste Zeile der Dokumentation lautet, K3 sei „auf Kimi Delta Attention, einem hybriden linearen Aufmerksamkeitsmechanismus, und Attention Residuals aufgebaut“^[3]. Das ist kein Marketing, sondern der Produktionseinsatz der Kimi Linear-Forschung, die Moonshot Ende 2025 veröffentlichte. Sie erklärt sowohl das 1M-Token-Fenster als auch den Einheitspreis, der es nutzbar macht^[6].

Kimi Delta Attention (KDA) ist ein linearer Aufmerksamkeitsmechanismus, eine Weiterentwicklung von Gated DeltaNet mit feinerem Gating. Bei Standard-Softmax-Attention wächst der Key-Value-Cache linear mit der Sequenzlänge, wodurch Millionen-Token-Kontexte extrem teuer werden. Lineare Attention hält stattdessen einen rekurrenten Zustand fester Größe. Der historische Preis war Qualität: Rein lineare Attention erinnert sich in langen Dokumenten schlechter an genaue Details.

Das hybride Layout löst diesen Kompromiss im Kimi-Linear-Paper: KDA- und Voll-Attention-Schichten wechseln im Verhältnis 3:1. Drei von vier Schichten verwenden den günstigen linearen Mechanismus, jede vierte behält exakte globale Attention. In den publizierten Ergebnissen übertraf diese Konfiguration Voll-Attention bei Qualitätsbenchmarks, senkte den KV-Cache-Speicher um bis zu 75% und decodierte bei 1M-Token-Kontexten bis zu 6x schneller^[6].

Stable LatentMoE bezeichnet die sparse Mixture-of-Experts-Konfiguration: 896 Experten, davon 16 pro Token aktiv^[3]. Diese Sparsity macht ein 2.8T-Modell überhaupt erst betreibbar, weil pro Token nur ein kleiner Teil der Gesamtparameter aktiv berechnet wird.

Attention Residuals ist die einzige Komponente ohne veröffentlichtes Paper; der Begriff erscheint erstmals in K3s Dokumentation. Bis ein Technikbericht vorliegt, kennen wir ehrlich gesagt nur den Namen, nicht den Mechanismus.

Praktisch zählt das, weil ein 1M-Token-Kontext nur mit tragfähiger Ökonomie nützt. Die meisten Anbieter sehr langer Kontexte erhöhen den Preis oder verschlechtern still die Leistung. K3s Dokumentation nennt keine Stufen: Ob 5,000 oder 900,000 Tokens, derselbe Tokenpreis gilt^[2]. Das ist nur sinnvoll, wenn die Grenzkosten langen Kontexts wirklich eingebrochen sind — genau dafür ist KDA gedacht. Die Architektur erklärt den Preis.

Was die API tatsächlich liefert

K3s API ist auf eine Weise strikt, die Teams bei der Migration von K2.x oder OpenAI-artigen Modellen überraschen wird. Das sind dokumentierte Einschränkungen, keine Beobachtungen^[1]:

• Reasoning ist immer aktiv. Einen Modus ohne Denken gibt es nicht. Moonshots FAQ beantwortet „Wie schalte ich die Gedankenkette aus?“ schlicht mit: gar nicht. reasoning_effort ist ein Top-Level-Feld mit low, high und max. medium fehlt, und standardmäßig läuft die teuerste Stufe max^[4].
• Sampling ist fest. temperature steht auf 1.0, top_p auf 0.95, n auf 1 und beide Penalty-Parameter auf 0. Andere Werte erzeugen einen Fehler, also sollten Anfragen sie weglassen. Wer Temperature je Aufgabe abstimmt, verliert diesen Hebel.
• Das Ausgabebudget muss neben der Eingabe in das Fenster passen. Moonshots native API verwendet für max_completion_tokens standardmäßig 131 072 und erlaubt bis zu 1 048 576. Überschreiten Eingabe plus Limit das Kontextfenster, antwortet sie mit invalid_request_error. Der größte Parameterwert garantiert keine finale Antwort mit einer Million Tokens. Setze das Limit ausdrücklich und reserviere Platz für Eingabe, Reasoning und Antwort^[9].
• Streaming trennt Reasoning und Antwort. Gestreamte Antworten senden reasoning_content-Deltas getrennt von content-Deltas, sodass UIs Denkspur und Endergebnis separat darstellen können.
• Preserved Thinking ist Pflicht. In Multi-Turn- und Tool-Schleifen muss die vollständige Assistant-Nachricht einschließlich reasoning_content und tool_calls unverändert in messages zurück. Nur content zu behalten, wie es viele OpenAI-förmige Implementierungen tun, verschlechtert das Modell unbemerkt.
• Vision hat scharfe Kanten. Bilder und Videos sind nativ möglich, öffentliche Bild-URLs nicht. Senden Sie base64-Data-URIs oder laden Sie Dateien hoch und referenzieren Sie deren ID^[5].
• Strukturierte Ausgabe ist erstklassig. Ein JSON Schema mit strict: true beschränkt das Feld der Endantwort, nicht das Reasoning in Prosa.

Der neue Tool-Calling-Stack

Zwei Fähigkeiten debütieren mit K3. Beide lösen dasselbe Problem: Agenten mit großen Tool-Beständen verbrauchen zu viel Kontext für Definitionen^[1].

tool_choice: "required" erzwingt mindestens einen Tool-Aufruf in einem Turn. So antwortet der Agent nicht aus dem Gedächtnis, wenn er etwas nachschlagen sollte. K2-Modelle lehnen diesen Wert ab, K3 akzeptiert ihn.

Dynamisches Laden von Tools ist neuartiger: Platzieren Sie mitten im Gespräch eine vollständige Tool-Definition in einer system-Nachricht, mit tools und ohne content. Ab dort ist das Tool verfügbar. Statt jeder Anfrage 80 Schemata voranzustellen, fügt der Orchestrator Tools erst in der passenden Workflowphase hinzu. Wichtig: Der Server speichert ein dynamisch geladenes Tool nicht. Bleibt die Systemnachricht nicht im Verlauf, verschwindet es im nächsten Turn.

Eine Warnung der Dokumentation ist wichtig: Moonshots integriertes web_search wird derzeit aktualisiert und ist für Produktion nicht empfohlen. Agenten sollten ihre eigene Suche mitbringen.

Automatisches Kontext-Caching

K3s Caching benötigt keine Cache-IDs, TTL-Verwaltung oder Zusatzparameter. Bleibt ein langer Präfix stabil, versucht die Plattform automatisch einen Cache Hit, der $0.30 je 1M Tokens statt $3.00 kostet^[1]. Das sind 90% Rabatt auf wiederholten Kontext und der Unterschied zwischen einer Demo und einem brauchbaren 1M-Fenster: Korpus einmal als stabilen Präfix laden, dann zum Zehntelpreis wiederholt abfragen.

Zwei Bedingungen entscheiden über den Treffer. Die Prompt-Tokens der vorherigen Anfrage müssen über 256 liegen; darunter wird nichts gecacht. Außerdem darf sich reasoning_effort nicht ändern: Ein Wechsel im Gespräch macht den Präfix-Cache ungültig^[4]. Legen Sie die Stufe vorher fest.

Frühe Drittanbietertelemetrie spricht dafür: OpenRouters Live-Statistik für K3 zeigte über den gesamten Traffic eine Cache-Hit-Rate über 75%, wodurch der gewichtete durchschnittliche Inputpreis deutlich unter ein Drittel des Listenpreises fiel^[7].

Preise: bewusster Bruch mit der Sparstrategie

Jede frühere Kimi-Version konkurrierte vor allem über Kosten. K3 tut das nicht. Hier steht es gegenüber der eigenen Familie und Frontier-Konkurrenz, jeweils je 1M Tokens und mit Cache-Miss-Input:

Die Positionierung ist klar: K3 kostet drei- bis viermal so viel wie die eigenen Geschwister und 40–50% weniger als geschlossene Frontier-Modelle. Moonshot setzt darauf, dass 1M-Token-Kontext, native Videoeingabe und Frontier-Fähigkeit eine Premiumstufe in der Open-Weight-Welt rechtfertigen.

Geschwindigkeit ist das ehrliche Sternchen. Frühe Telemetrie zeigt K3 mit ungefähr 28 Tokens pro Sekunde und etwa vier Sekunden bis zum ersten Token^[7]. Für ein stets raisonnierendes Modell dieser Größe ist das plausibel, aber langsam. K3 ist für Tiefe pro Aufruf gebaut, nicht für Aufrufe pro Minute; latenzkritische Interaktionen brauchen ein anderes Modell.

Noch eine Produktnotiz: Moonshot räumt die Modellpalette auf. Die alte moonshot-v1-Serie und ältere K2.x-Varianten sind für neue Nutzer geschlossen, die vollständige Abschaltung ist für Ende August 2026 angekündigt. Moonshot will alle auf K3 bringen.

Migration von K2.x: praktische Checkliste

Wer heute K2.6 oder K2.7-Code betreibt, hat wenig, aber echte Arbeit:

1. Modell-ID auf kimi-k3 ändern; die API bleibt OpenAI-kompatibel.
2. Den Parameter thinking durch reasoning_effort auf oberster Ebene ersetzen. Das K2-Objekt thinking gehört nicht zu K3 und erzeugt einen Fehler.
3. Sampling-Parameter entfernen. temperature, top_p und Penalty-Einstellungen gehören nicht in K3-Anfragen; sie sind serverseitig fest und andere Werte werden abgelehnt.
4. Effort bewusst wählen. Standard ist max, die teuerste Stufe, und Reasoning-Tokens zählen als Output. Bei einfacheren Aufgaben high oder low nutzen und im Gespräch nicht wechseln, weil sonst der Cache verfällt.
5. Kostenmodelle neu prüfen. Output-Tokens kosten nach Liste 3.75x so viel wie bei K2.6, und permanentes Reasoning erhöht die Menge. Automatisches Caching hilft: stabiler Präfix zuerst, variabler Suffix zuletzt.
6. Visionseingabe umbauen, falls bisher öffentliche Bild-URLs verwendet wurden. K3 akzeptiert nur base64 oder hochgeladene Dateireferenzen^[5].
7. Assistant-Nachrichten vollständig zurückgeben, einschließlich reasoning_content und tool_calls, in jeder Multi-Turn-Schleife.

Für wen K3 heute geeignet ist

Nach dem bestätigten Stand passt K3 zu lang laufenden Aufgaben, bei denen Qualität je Auftrag wichtiger ist als Kosten je Token: mehrstündige Coding-Agenten in großen Repositories, Million-Token-Dokumentkorpora mit wiederholt abgefragtem Cache-Präfix und multimodale Reasoning-Aufgaben mit Bildern, Video und Code in einem Kontext.

Falsch ist es für latenzkritische interaktive Produkte — 28 Tokens/sec sind ein anderes Werkzeug für einen anderen Job —, für Pipelines mit einstellbarem Sampling, weil alles gesperrt ist, und für reine Kostenoptimierung. Dafür gibt es günstigere Stufen.

Kimi K3 über reAPI ausführen

K3 ist auf dem reAPI-Gateway als OpenAI-kompatibler Drop-in-Endpoint verfügbar: Base URL auf https://api.reapi.ai/v1 setzen, Gateway-Key als Bearer-Token senden und Modellstring kimi-k3 verwenden. Das vorhandene openai SDK funktioniert unverändert.

curl https://api.reapi.ai/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k3",
    "messages": [
      { "role": "user", "content": "Refactor this module and add tests." }
    ],
    "reasoning_effort": "high",
    "stream": true
  }'

Zwei Gründe, K3 über reAPI statt direkt zu routen:

• Preis. reAPI berechnet für K3 $2.50 Input / $12.00 Output je 1M Tokens, in beiden Richtungen unter Moonshots veröffentlichtem Preis und beim Output ein volles Fünftel günstiger^[8]. Bei permanentem Reasoning, das Outputmengen erhöht, zählt vor allem der Outputpreis.
• Ein Schlüssel, viele Modelle. Derselbe Gateway-Key erreicht Claude, GPT, Gemini, DeepSeek, GLM und die Kimi-Reihe. K3 wird damit zur Routingentscheidung statt zur Anbieterbindung und kann in dieselbe Fallback- und Lastverteilungslogik wie andere Modelle.

Die vollständige Oberfläche — feste Parameter, Cache-Bedingungen, Vision-Format und Fehlerkatalog — steht in unserer Kimi-K3-API-Dokumentation; aktuelle Preise zeigt die Modellseite.

FAQ

Ist Kimi K3 Open Source?

Moonshot beschreibt K3 als Open-Source-Veröffentlichung und hat offene Gewichte zugesagt. Damit wäre es das erste offene Modell der 3-Billionen-Parameter-Klasse^[3]. Aktuell steht die Veröffentlichung kurz bevor, der primäre Zugang bleibt aber die API.

Kann ich K3s Reasoning abschalten oder reduzieren?

Abschalten lässt es sich nicht. Reduzieren können Sie es über reasoning_effort mit low, high und max; max ist Standard^[4]. low ist genau für Fälle gedacht, in denen das Reasoning mehr kostet, als die Antwort wert ist.

Kostet der 1M-Kontext extra?

Nein. Der Tokenpreis bleibt unabhängig von der Länge gleich; ein 900K-Token-Prompt hat dieselbe Rate wie ein 9K-Prompt^[2]. Direkt bei Moonshot fällt Cache-Hit-Input auf $0.30 je 1M Tokens.

Warum meldet meine K3-Anfrage einen Temperature-Fehler?

temperature, top_p, n und beide Penalty-Parameter sind serverseitig fixiert. Andere Werte erzeugen einen Fehler statt einer Überschreibung^[1]. Entfernen Sie sie. Dasselbe gilt für das K2-Objekt thinking; verwenden Sie reasoning_effort auf oberster Ebene.

Kann ich K3 in Claude Code, Codex oder Cline nutzen?

Ja. Die API ist OpenAI-kompatibel, also funktioniert jedes Tool mit eigener Base URL und eigenem Key, darunter Claude Code, Codex, Cline, RooCode und OpenCode. Richten Sie es mit Gateway-Key auf https://api.reapi.ai/v1 und die ID kimi-k3.

Wie schneidet K3 gegen Claude Opus 4.8 oder GPT-5.5 in Benchmarks ab?

Moonshot hat bislang keine offizielle Evaluationstabelle für K3 veröffentlicht: kein SWE-Bench, kein Terminal-Bench, nichts unabhängig Prüfbares. Konkrete Social-Media-Zahlen bleiben unbestätigt, bis Benchmark-Tabelle und Technikbericht erscheinen.

Quellen

1. Moonshot AI. Kimi K3 Quickstart — offizielle API-Dokumentation: Modell-ID, fixes Sampling, Outputlimits, Tools und Caching. Abgerufen im Juli 2026 von platform.kimi.ai/docs/guide/kimi-k3-quickstart
2. Moonshot AI. Kimi-K3-Preise — $3.00 / $15.00 je 1M Tokens, $0.30 Cache-Hit-Input, keine Kontextstufen. Abgerufen im Juli 2026 von platform.kimi.ai/docs/pricing/chat-k3
3. Moonshot AI. Modellübersicht — 2.8T Parameter, Kimi Delta Attention + Attention Residuals, Stable LatentMoE (16 von 896 Experten), Open-Source-Zusage. Abgerufen im Juli 2026 von platform.kimi.ai/docs/api/models-overview
4. Moonshot AI. reasoning_effort verwenden — drei Stufen (low / high / max), max als Standard, Cacheverlust beim Wechsel. Abgerufen im Juli 2026 von platform.kimi.ai/docs/guide/use-reasoning-effort
5. Moonshot AI. Kimi-Visionmodelle verwenden — Bild und Video, base64 und Dateien, keine öffentlichen URLs. Abgerufen im Juli 2026 von platform.kimi.ai/docs/guide/use-kimi-vision-model
6. Moonshot AI. Kimi Linear: An Expressive, Efficient Attention Architecture (arXiv:2510.26692) — KDA, hybrides 3:1-Layout, KV-Cache und Decodierung. Abgerufen im Juli 2026 von arxiv.org/abs/2510.26692
7. OpenRouter. MoonshotAI: Kimi K3 — Live-Telemetrie zu Cache, gewichteten Inputpreisen, Durchsatz und TTFT. Abgerufen im Juli 2026 von openrouter.ai/moonshotai/kimi-k3
8. reAPI. Kimi K3 — Modellseite, API-Dokumentation und aktuelle Preise. Abgerufen im Juli 2026 von reapi.ai/docs/kimi-k3
9. Moonshot AI. Chat Completions API — output cap and input-plus-cap validation. Retrieved September 8, 2026 from platform.kimi.ai/docs/api/chat

Mehr zum Thema

• reAPI. Kimi-K3-API-Dokumentation. reapi.ai/docs/kimi-k3
• reAPI. Kimi-K3-Modellseite — aktuelle Preise. reapi.ai/models/kimi-k3
• reAPI. Was ist Claude Opus 4.8? Anthropics neues Modell erklärt. reapi.ai/blog/what-is-claude-opus-4-8
• reAPI. Was ist reAPI? reapi.ai/blog/what-is-reapi