Kimi API Preise und Abrechnung (2026): K2-Serie und langer Kontext

Die Kimi API wird nach Verbrauch abgerechnet, ein Abonnement gibt es nicht. Wer beim Preisvergleich nur auf „Kosten pro Million Token“ schaut, entscheidet leicht falsch: Maßgeblich für die Rechnung sind Modell, Kontextlänge, Cache-Trefferquote und Ausgabelänge. Die K2-Serie bietet 262.144 Token Kontext, K3 steigert das auf 1.048.576. Die lange Kontextfähigkeit ist ein Vorteil, bedeutet aber auch, dass sich auf der Input-Seite schneller Kosten ansammeln.

Dieser Artikel zerlegt die Abrechnungsstruktur der K2-Serie, die Kostentreiber bei langem Kontext, eine reproduzierbare Messmethode und die Reihenfolge der Kostensenkung, ohne konkrete Stückpreise festzuschreiben. Maßgeblich sind die offizielle Dokumentation und unsere Preisübersicht.

Hinweis: Moonshot und Kimi sind Marken des jeweiligen Rechteinhabers. Modellversionen, Kontextlängen und Abrechnungsregeln können sich ändern. Dieser Artikel beschreibt die übliche Situation im Oktober 2026; prüfen Sie vor dem Einkauf erneut die offiziellen Seiten.

1. Wie die K2-Serie aufgeteilt ist

Modell	Positionierung	Kontext	Geeignete Aufgaben	Kostenfokus
`kimi-k2.6`	Allzweck	262.144	Dialog, Extraktion, Kundenservice, Dokumentverarbeitung	Cache-Trefferquote
`kimi-k2.7-code`	Code	262.144	Codegenerierung, Repository-Fragen, Agenten	langer Input, viele Tool-Ergebnisse
`kimi-k2.7-code-highspeed`	Code, hohe Geschwindigkeit	262.144	Vervollständigung mit niedriger Latenz, interaktives Programmieren	Balance aus Stückpreis und Durchsatz
`kimi-k3`	Neue Generation	1.048.576	sehr lange Dokumente, komplexe mehrstufige Aufgaben	langer Kontext und Cache-Schreiben

Die Modelle werden weiterentwickelt; die K2-Serie kann künftig neue Versionen erhalten. Orientieren Sie sich beim Einkauf an der offiziellen Modellliste und der Preisübersicht und behandeln Sie die hier genannten Modellnamen nicht als dauerhafte Zusage.

Für Allzweckaufgaben ist der maximale Kontext nicht automatisch die richtige Wahl. Wird ein vollständiges Dokument in einen 1-Millionen-Kontext gelegt, summieren sich die Input-Kosten mit jeder Runde. Meist ist es günstiger, zuerst per Retrieval den Umfang zu verkleinern und das Modell nur die relevanten Ausschnitte lesen zu lassen. Bei Code-Aufgaben ist es umgekehrt: Repository-Struktur und Tool-Rückgaben müssen oft erhalten bleiben; dort zählen stabile Präfixe und eine hohe Cache-Trefferquote.

2. Die Rechnung besteht aus drei Teilen

Die K2-Serie rechnet drei Positionen ab: Input mit Cache-Treffer, Input ohne Cache-Treffer und Output. Bei K3 wird zusätzlich das Schreiben in den Cache getrennt nach zwei TTL-Stufen von 5 Minuten und 1 Stunde bepreist. Deshalb lässt sich nicht einfach ein Durchschnittspreis mit der Gesamt-Tokenzahl multiplizieren.

Abrechnungsposition	Wann sie entsteht	Kostenwirkung	Steuerungsmöglichkeit
Input ohne Cache-Treffer	erstmals auftretende Prompts, Dokumente, Tool-Ergebnisse	wächst linear mit dem Kontext	Retrieval, Zusammenfassung, Verlauf kürzen
Input mit Cache-Treffer	wiederholter System-Prompt, fester Präfix	meist deutlich niedriger als ein Fehlgriff	stabiler Präfix, feste Tool-Reihenfolge
Output-Token	vom Modell erzeugter Inhalt und Denkschritte	lange Ausgaben erhöhen die Rechnung	`max_completion_tokens` begrenzen
Cache-Schreiben (K3)	Schreiben eines Cache-Präfixes	Preis je TTL-Stufe	nur stabile, wiederverwendete Inhalte cachen

Zerlegt man eine Anfrage, lautet die Kostenformel:

Kosten pro Anfrage =
  Input-Token ohne Treffer × Preis ohne Treffer
+ Input-Token mit Treffer × Trefferpreis
+ Output-Token × Output-Preis

Bei K3 kommt die Position für das Cache-Schreiben hinzu. Das usage-Feld der Antwort liefert prompt_tokens, completion_tokens und prompt_tokens_details; Cache-Treffer und Cache-Schreiben zählen beide zu prompt_tokens. Der nicht gecachte Anteil ergibt sich aus der Gesamtzahl minus dieser beiden Positionen.

3. Warum langer Kontext leicht teuer wird

Szenario	Typische Token-Struktur	Hauptkosten	Optimierungsrichtung
Fragen zu langen Dokumenten	großer Input, mittlerer Output	Dokument wird wiederholt übertragen	Retrieval plus Cache
Code-Repository-Agent	Input und Output gleichermaßen groß	Tool-Ergebnisse und Verlauf	Zusammenfassung, Kürzen, Cache
Mehrstufiger Kundenservice	Input wächst mit jeder Runde	Verlauf wird wiederholt	rollierende Zusammenfassung
Batch-Extraktion	mittlerer Input, kurzer Output	Dokument wird mehrfach gelesen	Batch-Verarbeitung plus kleines Modell

Die Unterschiede entstehen meist an fünf Stellen:

Input summiert sich über die Runden: Wird in jeder Runde der Volltext erneut übertragen, verdoppelt sich die Rechnung näherungsweise mit jeder Runde.
Cache-Trefferquote: Ein fester Präfix wird wiederverwendet; wechselnde Zeitstempel, Zufalls-IDs und dynamische Sortierung lassen den Cache verfallen.
Tool-Ausgaben: Eine Suche oder Codeausführung liefert ein ganzes Log, das in der nächsten Runde unverändert zurückgeht; die Kosten addieren sich.
Ausgabelänge: Offene Aufforderungen wie „analysiere ausführlich“ erzeugen leicht lange Ausgaben, und Output ist meist teurer als gecachter Input.
Falsche Modellwahl: Ein großes Modell für einfache Klassifikation oder wiederholte Fehlversuche mit einem ungeeigneten Modell erhöhen die Kosten.

4. Eine reproduzierbare Messung durchführen

Wählen Sie 20 bis 50 echte Aufgaben aus, die einfache, mittlere und komplexe Fälle abdecken, und definieren Sie klare Abnahmekriterien.
Quantifizieren Sie den Input zuerst mit einer Token-Schätzung, nicht anhand der Zeichenzahl.
Führen Sie dieselben Aufgaben mit kimi-k2.6 und dem Code-Modell aus und erfassen Sie Qualität, Latenz und Anzahl der Nacharbeitsschritte.
Lesen Sie aus dem usage-Feld der Antwort Input, Output, Cache-Treffer und Cache-Schreiben aus.
Vergleichen Sie die Kosten „pro erfolgreich abgeschlossener Aufgabe“ statt den Listenpreis pro Million Token.
Rechnen Sie Wiederholungen, fehlgeschlagene Anfragen und Cache-Schreiben in die Kosten pro Aufgabe ein.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MOONSHOT_API_KEY"],
    base_url="https://api.moonshot.cn/v1",
)

resp = client.chat.completions.create(
    model="kimi-k2.6",
    messages=[{"role": "user", "content": "Extrahiere aus diesem Vertrag JSON: …"}],
    max_completion_tokens=1024,
)

u = resp.usage
print("Input", u.prompt_tokens, "Output", u.completion_tokens)
print("Cache-Details", getattr(u, "prompt_tokens_details", None))

Bei Streaming-Aufrufen muss stream_options={"include_usage": True} gesetzt werden; die vollständige Nutzung wird erst im letzten Block zurückgegeben. Multiplizieren Sie Beträge mit den tatsächlichen Preisen aus Vertrag oder Preisübersicht und verwenden Sie keine Screenshots von vor einigen Monaten.

5. In welcher Reihenfolge die Kosten sinken

Zuerst den Cache einrichten: System-Prompt, Tool-Definitionen und Wissenspräfix fixieren und mit cached_tokens prüfen, ob wirklich Treffer entstehen.
Dann den Input verringern: Retrieval liefert nur relevante Ausschnitte, Verläufe werden zusammengefasst; die gesamte Wissensbasis gehört nicht in den Kontext.
Output begrenzen: Ein sinnvolles max_completion_tokens setzen, JSON oder feste Felder verlangen und Höflichkeitsfloskeln reduzieren.
Modell-Routing einführen: Allzweckaufgaben mit kimi-k2.6, Code-Aufgaben mit der K2.7-Code-Version, sehr lange Materialien erst mit K3.
Lange Anfragen streamen: Streaming ändert den Stückpreis nicht direkt, reduziert aber Wiederholungen durch Zeitüberschreitungen und Verbindungsabbrüche.
Überwachen und alarmieren: Verbrauch nach Projekt, Modell und Szenario betrachten, Budgetgrenzen setzen und wöchentlich die Rangliste der Verbraucher prüfen.

Kehren Sie die Reihenfolge nicht um. Zuerst Cache und Input-Governance, dann der Wechsel zu einem günstigeren Modell; sonst werden nur falsche Antworten billiger.

6. Budget und Rechnung verwalten

Ein Key pro Projekt und ein Tagesbudget pro Projekt, damit ein Geschäftsbereich nicht das gesamte Kontingent aufbraucht.
Monatlich nach Projekt, Modell und Szenario abstimmen und die am schnellsten wachsenden Aufrufe identifizieren.
Cache-Trefferquote, Wiederholungsversuche und durchschnittliche Ausgabelänge separat erfassen; sonst lässt sich der Optimierungserfolg nicht belegen.
Teams, die in chinesischen Yuan zahlen und Rechnungen benötigen, können über ein inländisches AI-Gateway eine einheitliche Rechnung für mehrere Modelle erhalten; Preise und Rechnungsregeln entnehmen Sie der Preisübersicht.

Häufige Fragen

Ist K2 oder K3 wirtschaftlicher?

Das hängt von der Aufgabe ab. Die K2-Serie bietet 262.144 Token Kontext und deckt die meisten Dokument- und Code-Szenarien ab; K3 hat einen größeren Kontext und eignet sich für sehr lange Materialien. Vergleichen Sie die Gesamtkosten pro erfolgreich abgeschlossener Aufgabe, nicht nur den Stückpreis.

Wie viel spart der Cache?

Das hängt von der Wiederverwendung des Präfixes und der Trefferquote ab. Gecachter Input ist meist deutlich günstiger als nicht gecachter, und ein Treffer verlängert zudem die Gültigkeit des Caches. Ändert sich der Präfix bei jeder Anfrage oder ist er zu kurz, entsteht kein Treffer.

Ist Streaming günstiger?

Der Stückpreis ändert sich dadurch nicht direkt. Der Nutzen liegt darin, versteckte Kosten durch Zeitüberschreitungen, Verbindungsabbrüche und Wiederholungen bei langen Anfragen zu reduzieren.

Warum ist die Rechnung höher als geschätzt?

Häufig vergessene Posten sind Verlauf, Tool-Rückgaben, vollständige Dokumente, Wiederholungen, lange Ausgaben und Cache-Fehlgriffe. Gleichen Sie die Request-Logs anhand des usage-Feldes ab, um die Abweichung zu lokalisieren.

Wie können Teams in China in Yuan abrechnen?

Über ein AI-Gateway mit Aufladung in Yuan und Rechnungsstellung lässt sich Kimi nutzen und die Rechnung über mehrere Modelle vereinheitlichen. Verfügbare Modelle, Preise und Rechnungsregeln entnehmen Sie der Preisübersicht.

Nächste Schritte

Erstellen Sie zunächst im ZSQH AI Gateway einen Test-Key, führen Sie mit kimi-k2.6 und dem Code-Modell jeweils eine Charge echter Aufgaben aus und erfassen Sie Token, Cache-Treffer und Qualität. Danach legen Sie das Hauptmodell fest. Modellverfügbarkeit und Preise entnehmen Sie der Preisübersicht.