Die Kimi K3 API kam mit einer ungewöhnlichen Kombination auf den Markt: Benchmark-Ergebnisse nahe an der Spitzenklasse, aggressive Preise und herunterladbare Gewichte. Moonshot AI veröffentlichte diese Gewichte am 27. Juli 2026, womit K3 das bislang größte offen verfügbare Modell ist und zum ersten Mal ein Modell dieser Größenordnung etwas, das Sie im Prinzip selbst betreiben könnten.

Für jeden, der bereits einen Frontier-Anbieter bezahlt, wirft das eine praktische statt einer philosophischen Frage auf. Gehört es in Ihren Stack, und was ändert sich tatsächlich, wenn Sie Traffic dorthin verlagern? Dieser Leitfaden behandelt die Preisrechnung, die Integrationsarbeit und die Stellen, an denen die Schlagzeilenwerte sich nicht in Produktivverhalten übersetzen.

Kurz gefasst: Kimi K3 berechnet rund 3 US-Dollar pro Million Input-Token ohne Cache-Treffer, 0,30 US-Dollar pro Million zwischengespeicherter Input-Token und 15 US-Dollar pro Million Output-Token, bei einem Kontextfenster von 1.048.576 Token. Die Schnittstelle ist zu den OpenAI- und Anthropic-Konventionen kompatibel, sodass die Umstellung einer Workload im Wesentlichen eine Änderung von Basis-URL und Modellname ist. Der Haken: Das Denken ist immer aktiv und steht standardmäßig auf maximalem Aufwand, wodurch Output-Token die dominierende Position auf Ihrer Rechnung werden, wenn Sie das nicht bewusst steuern.

Was Kimi K3 tatsächlich ist

Die Architektur ist hier relevant, weil sie sowohl die Preise als auch die Betriebsbeschränkungen erklärt.

K3 ist ein Sparse-Mixture-of-Experts-Modell mit 2,8 Billionen Gesamtparametern, von denen etwa 104 Milliarden pro Token aktiviert werden. Es besitzt 896 Experten und leitet jedes Token an 16 davon weiter. Dieses Verhältnis ist der Grund, warum ein Modell dieser Größe überhaupt ausgeliefert werden kann: Sie zahlen die Speicherkosten der vollen Parameterzahl, aber die Rechenkosten einer sehr viel kleineren.

Das Attention-Design ist der wirklich neuartige Teil. Moonshot baute K3 auf dem, was das Unternehmen Kimi Delta Attention nennt, einem linearen Attention-Mechanismus, der etwa im Verhältnis drei zu eins mit vollen Attention-Schichten verschränkt ist, unterstützt durch eine Technik namens Attention Residuals. Die linearen Schichten verarbeiten lokale Sequenzstruktur günstig, während die vollen Attention-Schichten den globalen Informationsfluss erhalten. Diese Kombination macht einen Millionen-Token-Kontext wirtschaftlich plausibel statt nur beworben.

Aus der Modellkarte folgen zwei Betriebsdetails. Die Gewichte werden in MXFP4 mit MXFP8-Aktivierungen ausgeliefert, und das Denken ist immer aktiviert, das heißt das Modell liefert bei jeder Anfrage ein Feld reasoning_content neben seiner Antwort. Sie können das Reasoning nicht abschalten. Sie können nur wählen, wie viel davon Sie kaufen.

Was die Kimi K3 API kostet

Die veröffentlichten Sätze sind übersichtlich, und die Lücke zwischen ihnen ist der Ort, an dem die interessanten Entscheidungen liegen.

Input ohne Cache-Treffer liegt bei etwa 3 US-Dollar pro Million Token. Zwischengespeicherter Input liegt bei etwa 0,30 US-Dollar, eine Reduktion um den Faktor zehn. Output liegt bei etwa 15 US-Dollar pro Million. Anders als bei manchen Anbietern gilt dieser Preis flach über das gesamte Kontextfenster, statt ab einer Schwelle zu steigen, was Arbeiten mit langem Kontext erheblich besser planbar macht.

Rechnen Sie einen realistischen Fall durch. Angenommen, ein Agent bearbeitet einen Support-Workflow mit einem System-Prompt und Wissensvorspann von 40.000 Token, ergänzt 2.000 Token Konversation und erzeugt 1.500 Token Antwort samt Reasoning. Kalt kostet diese Anfrage rund zwölfeinhalb Cent Input und gut zwei Cent Output. Warm, mit zwischengespeichertem 40.000-Token-Präfix, fällt der Input-Kostenanteil auf unter anderthalb Cent, während der Output unverändert bleibt. Bei zehntausend Anfragen pro Tag ist dieser Unterschied die gesamte Wirtschaftlichkeit des Features.

Daraus folgen zwei Lehren. Erstens: Strukturieren Sie Prompts so, dass das stabile Material vorne steht und sich nie ändert, denn Caching hilft nur einem Präfix, das identisch bleibt. Zweitens: Beobachten Sie die Output-Seite genau, da Reasoning-Token als Output abgerechnet werden und die Aufwandseinstellung standardmäßig auf Maximum steht. Unser Leitfaden zur Reduzierung von LLM-Latenz durch Caching behandelt die Präfix-Disziplin ausführlicher, und sie gilt hier nahezu unverändert.

Die Integration ist überwiegend eine Änderung der Basis-URL

Moonshot stellt K3 über eine Schnittstelle bereit, die sowohl zu den OpenAI- als auch zu den Anthropic-Konventionen kompatibel ist, was die Migration für die meisten Anwendungen wirklich klein macht. Richten Sie Ihren bestehenden Client auf den Moonshot-Endpunkt, setzen Sie die Modellkennung auf kimi-k3 und hinterlegen Sie die neuen Zugangsdaten. Code, der bereits eines der beiden Protokolle spricht, funktioniert meist unverändert.

Drei Unterschiede sollten Sie vor dem Ausliefern ausdrücklich behandeln.

Der erste ist reasoning_effort. K3 akzeptiert ein Feld auf oberster Ebene mit den Werten low, high oder max, und der Standard ist max. Diesen Standard bei einer Klassifizierungs- oder Extraktionsaufgabe stehen zu lassen bedeutet, für ausgedehntes Nachdenken bei Arbeit zu bezahlen, die keines brauchte. Setzen Sie ihn für Routineaufrufe auf low und reservieren Sie high oder max für die Anfragen, die davon wirklich profitieren.

Der zweite ist reasoning_content. Weil das Denken immer aktiv ist, tragen Antworten zusätzlich zur eigentlichen Antwort ein Reasoning-Feld. Ihr Parsing muss wissen, dass dieses Feld existiert, Ihr Logging muss entscheiden, ob es aufbewahrt wird, und Ihre Oberfläche sollte es keinesfalls versehentlich anzeigen.

Der dritte ist die übliche Disziplin, die für jeden Anbieter gilt. Halten Sie die Zugangsdaten serverseitig, setzen Sie den Aufruf hinter Ihren eigenen Proxy, damit Sie die Messung pro Nutzer und die Möglichkeit zum Anbieterwechsel behalten, und pinnen Sie die Modellkennung, statt einem beweglichen Alias zu folgen. Die Architektur, die wir für diese Schicht empfehlen, ist in unserem Leitfaden zur OpenAI-API-Integration beschrieben, und sie ist genau aus diesem Grund bewusst anbieterneutral.

Das Millionen-Token-Fenster, und wann man es ignoriert

Ein Fenster von 1.048.576 Token ist eine echte Fähigkeit, und es ist zugleich das Merkmal, das am ehesten falsch eingesetzt wird.

Es verdient seinen Platz, wenn die Aufgabe wirklich Schlussfolgerungen über einen ganzen Korpus erfordert: einen Vertrag gegen jede frühere Fassung vergleichen, ein Verhalten durch ein gesamtes Repository verfolgen oder eine lange Agenten-Trajektorie abgleichen, bei der frühere Schritte zählen. In solchen Fällen schadet Retrieval aktiv, weil das relevante Fragment durch Beziehungen definiert wird, die der Retriever nicht sehen kann.

Es ist das falsche Werkzeug für Fragebeantwortung über eine Dokumentensammlung. Eine Million Token in jede Anfrage zu stopfen ist langsamer und weitaus teurer, als die vier relevanten Passagen zu holen, und die Genauigkeit bei präzisen Nachschlagevorgängen ist häufig schlechter statt besser. Die ehrliche Regel lautet: Großer Kontext ist für Probleme gedacht, bei denen Sie vorab nicht wissen können, welcher Teil relevant ist. Alles andere gehört weiterhin in eine Retrieval-Pipeline.

Die Benchmarks ehrlich lesen

K3 schneidet gut ab. Bei aggregierten Intelligenzindizes liegt es knapp hinter den führenden proprietären Frontier-Modellen und deutlich vor der vorherigen Generation, und es ist stark bei agentischen und terminalbasierten Coding-Bewertungen. Berichtete Zahlen umfassen Ergebnisse im hohen Achtzigerbereich bei Terminal-Bench 2.1 und im niedrigen Achtzigerbereich bei FrontierSWE.

Diese Zahlen verdienen einen Vorbehalt, der für jedes Modell gilt, nicht nur für dieses. Ergebnisse von Coding-Benchmarks hängen stark vom verwendeten Harness ab, und Vergleiche, die Harnesses mischen, können bei identischen Modellen um zehn bis fünfundzwanzig Punkte schwanken. Ein Ergebnis, das mit dem eigenen Agenten-Gerüst eines Anbieters erzeugt wurde, ist nicht direkt mit einem aus einem generischen Runner vergleichbar. Wenn eine Tabelle ein Modell vor einem anderen zeigt, prüfen Sie zuerst, ob beide gleich bewertet wurden.

Praktisch bedeutet das: Öffentliche Benchmarks taugen zur Vorauswahl und nicht zur Entscheidung. Bauen Sie ein kleines Bewertungsset aus Ihrem eigenen Traffic, lassen Sie die Kandidatenmodelle mit Ihren eigenen Prompts und Ihrem eigenen Gerüst hindurchlaufen und vergleichen Sie an der Arbeit, die Sie tatsächlich tun. Dreißig bis hundert repräsentative Fälle sagen mehr als jede Rangliste.

Wo es in einen Produktivstack passt

Das vernünftige Muster im Jahr 2026 ist Routing statt Gefolgschaft, und K3 fügt sich gut in dieses Muster.

Schicken Sie hochvolumige Routinearbeit an ein kleines, schnelles, günstiges Modell. Schicken Sie langfristige agentische Arbeit, Aufgaben über große Repositories und echtes Korpus-Reasoning an K3, wo Kontextfenster und agentische Leistung die Kosten rechtfertigen. Halten Sie ein proprietäres Frontier-Modell für die Minderheit von Anfragen bereit, bei denen Sie die beste verfügbare Antwort brauchen und der Preis nicht entscheidet.

Voraussetzung ist eine Abstraktionsschicht, mit der Sie Traffic zwischen Anbietern verschieben können, ohne Anwendungscode anzufassen. Teams, die den Client eines Anbieters quer durch ihre Codebasis fest verdrahten, stellen fest, dass ein Wechsel Wochen kostet, weshalb sie nie wechseln und die Ersparnis nie realisieren. Bauen Sie zuerst die Naht, dann wird die Modellwahl eine Konfigurationsentscheidung statt eines Projekts.

Eine weitere Überlegung spricht speziell für K3. Weil die Gewichte veröffentlicht sind, kann eine gegen die API gebaute Workload später auf Infrastruktur unter Ihrer Kontrolle umziehen, ohne die Anwendung neu zu schreiben. Das ist eine echte strategische Option, und sie wird in unserem Begleitbeitrag zum Self-Hosting von Kimi K3 behandelt.

Lassen Sie die Integration sauber bauen

Mecanik baut produktionsreife Sprachmodell-Integrationen über Anbieter hinweg als Teil unserer KI-Integrationsleistungen . Wir übernehmen Proxy- und Routing-Schicht, Struktur des Prompt-Cachings, Aufwandsabstimmung, Bewertungs-Harness und die Kostenkontrollen, die verhindern, dass aus einem vielversprechenden Feature eine unvorhersehbare Rechnung wird.

Wenn Sie einen Wechsel zu Kimi K3 von einem bestehenden Anbieter abwägen, lassen wir Ihren eigenen Traffic durch beide laufen und zeigen Ihnen den Qualitäts- und Kostenunterschied, bevor Sie sich festlegen. Für das größere kaufmännische Bild legt unser Leitfaden zu KI-Integrationskosten dar, wie Aufbau- und Betriebsbudgets realistisch aussehen. Die vollständigen Modellspezifikationen sind auf der Kimi K3 Modellkarte veröffentlicht.

Siehe auch: KI-Agentur vs. Inhouse: KI-Einführung in Großbritannien 2026 , Claude API vs. OpenAI API: Vergleich für Entwickler , DeepSeek R1 vs. OpenAI o3-mini: Welche API ist die beste? , Existiert echte KI? Die Mythen und Realität entwirren .

Häufig gestellte Fragen

Wie viel kostet die Kimi K3 API? Die veröffentlichten Preise liegen bei etwa 3 US-Dollar pro Million Input-Token ohne Cache-Treffer, 0,30 US-Dollar pro Million zwischengespeicherter Input-Token und 15 US-Dollar pro Million Output-Token, flach über das gesamte Kontextfenster. Da Reasoning-Token als Output abgerechnet werden und der Aufwand standardmäßig auf Maximum steht, dominiert meist der Output die Kosten.

Ist die Kimi K3 API mit OpenAI-Client-Bibliotheken kompatibel? Ja. Moonshot stellt eine Schnittstelle bereit, die zu den OpenAI- und Anthropic-Konventionen kompatibel ist, sodass die meisten Anwendungen durch Ändern von Basis-URL, Modellkennung und Zugangsdaten migrieren. Planen Sie etwas Zeit für das Feld zum Reasoning-Aufwand und den zusätzlichen Reasoning-Inhalt ein, der bei jeder Antwort zurückkommt.

Kann ich das Reasoning in Kimi K3 abschalten? Nein. Das Denken ist immer aktiviert und jede Antwort enthält ein Feld mit Reasoning-Inhalt. Die Tiefe steuern Sie über die Einstellung des Reasoning-Aufwands, die low, high oder max akzeptiert und standardmäßig auf max steht. Setzen Sie sie bei Routineaufgaben also ausdrücklich, um nicht für unnötiges Nachdenken zu bezahlen.

Sollte ich den Millionen-Token-Kontext statt Retrieval nutzen? Nur wenn die Aufgabe wirklich Schlussfolgerungen über einen ganzen Korpus verlangt, etwa das Verfolgen eines Verhaltens durch ein komplettes Repository. Für Fragebeantwortung über eine Dokumentensammlung bleibt Retrieval schneller, günstiger und oft genauer, als bei jeder Anfrage das Kontextfenster zu füllen.

Wie verlässlich sind die veröffentlichten Benchmark-Werte von Kimi K3? Die Werte sind echt, aber vom Harness abhängig. Coding-Bewertungen können je nach eingesetztem Agenten-Gerüst um zehn bis fünfundzwanzig Punkte schwanken, sodass Ergebnisse aus dem eigenen Harness eines Anbieters nicht direkt mit generischen Runnern vergleichbar sind. Prüfen Sie an Ihren eigenen Aufgaben, bevor Sie entscheiden.