Kimi K3.1 Pro: cena API i koszt 1000 zapytań

👁 123 przeczytań

W oficjalnym cenniku API model Kimi K3.1 Pro kosztuje 2 USD za milion tokenów wejściowych i 10 USD za milion wyjściowych (odczyt z 2026-10-23 z platform.kimi.ai). W hipotetycznym scenariuszu 1000 zapytań (każde po 1000 tokenów wejścia i 500 wyjścia) daje to 7 USD netto, czyli dokładnie tyle samo co Gemini Argon, dwa razy mniej niż Claude Opus 5.5 i pięć razy mniej niż GPT-6 Astra. W moich pojedynczych wywołaniach przez OpenRouter zauważyłem jednak istotny haczyk budżetowy: tokeny rozumowania są rozliczane według droższej stawki wyjściowej i potrafią wyczerpać cały limit max_tokens=1800, generując koszt bez zwrócenia końcowej odpowiedzi.

• Stawki bazowe Kimi K3.1 Pro: 2,00 USD / 1M tokenów wejściowych, 0,20 USD / 1M tokenów z pamięci podręcznej (cached input) oraz 10,00 USD / 1M tokenów wyjściowych.
• Wariant Highspeed: 4/20 USD za 1M tokenów wejścia/wyjścia, cache input 0,20 USD. W osobnym teście 10 zadań był 2,3x szybszy od Pro.
• Budżet na 1000 wywołań (kalkulacja 1M in + 0,5M out): 7,00 USD dla Kimi K3.1 Pro, podczas gdy Claude Opus 5.5 oraz Kimi Highspeed kosztują 14,00 USD, a GPT-6 Astra 35,00 USD.
• Główne ryzyko kosztowe: w zadaniach z polską korektą i wykrywaniem brakujących danych Kimi K3.1 Pro wygenerował po 1797 tokenów rozumowania, dobijając do limitu 1800 tokenów i kosztując ponad 0,018 USD za puste pole answer.

Oficjalny cennik API Kimi K3.1 Pro i wariantu Highspeed

To cennik API, nie przegląd abonamentów. Dostęp przez aplikację, Work i Code opisuję w głównym tekście o premierze.

Szersze omówienie samego modelu przygotowuję w głównym przeglądzie Kimi K3.1 Pro oraz w sekcji zbierającej wszystkie materiały o rodzinie Kimi. Na poziomie samego cennika z platform.kimi.ai producent różnicuje koszt w zależności od wybranego punktu końcowego:

Cached Input kosztuje 0,20 USD/1M w obu wariantach. Osobny test 10 zadań, z limitem 16000 tokenów i domyślnym rozumowaniem, dał 10/10 dla Pro i Highspeed: odpowiednio 76,0 s i 32,6 s. Highspeed działa jako endpoint Moonshot, mimo braku osobnego identyfikatora w katalogu modeli OpenRouter. To inny protokół niż moja próba sześciu zadań.

Symulacja budżetu: koszt 1000 zapytań na tle konkurencji

Aby porównać opłacalność poszczególnych modeli w powtarzalnych warunkach, zestawiłem stawki katalogowe dla hipotetycznego pakietu 1000 zapytań, w którym każde zapytanie przesyła dokładnie 1000 tokenów wejściowych i odbiera 500 tokenów wyjściowych. Podkreślam, że poniższe zestawienie to czysta kalkulacja matematyczna (łącznie 1 milion tokenów wejścia i 0,5 miliona tokenów wyjścia bez udziału pamięci podręcznej), a nie pomiar z faktycznej serii tysiąca wywołań.

W kalkulacji bardzo ważne jest założenie, że 500 tokenów wyjściowych obejmuje całość generacji po stronie modelu - czyli zarówno widoczną odpowiedź dla użytkownika, jak i wewnętrzne tokeny rozumowania (reasoning tokens). Zestawienie kosztów dla takiego wolumenu prezentuje poniższa tabela:

Rzeczywiste koszty w moich wywołaniach API: JSON i arytmetyka

Kalkulacje tabelaryczne zakładają stałą liczbę tokenów wyjściowych, jednak w rzeczywistym ruchu API modele różnią się gadatliwością oraz narzutem na wewnętrzne rozumowanie. Aby sprawdzić faktyczne obciążenie salda, wykonałem serię pojedynczych wywołań przez bramkę OpenRouter przy jednolitych parametrach: temperature=0.2, żądany niski wysiłek rozumowania (reasoning effort: low), limit max_tokens=1800 oraz tryb bez strumieniowania (non-stream). Zwrócony czas w sekundach to całkowity czas zegarowy (wall time) obejmujący opóźnienie sieciowe i fazę myślenia; ze względu na pojedynczą próbę (N=1) na zadanie nie wyliczam przedziałów ufności, czasu do pierwszego tokenu (TTFT) ani przepustowości w tokenach na sekundę.

Zadanie 1: Ekstrakcja struktury JSON

W pierwszym zadaniu (json) poleciłem modelom wyciągnięcie z krótkiego zdania („Anna zamówiła 3 notesy po 12,50 zł netto i 2 długopisy po 4 zł netto”) czystej tablicy JSON z polami nazwa, sztuki i cena_netto, bez znaczników markdown. Wszystkie trzy przetestowane modele zwróciły dokładnie oczekiwaną strukturę:

[{"nazwa":"notes","sztuki":3,"cena_netto":12.5},
 {"nazwa":"długopis","sztuki":2,"cena_netto":4}]

Zadanie 2: Kalkulacja arytmetyczna (rachunek z rabatem i VAT)

W drugim teście (rachunek) modele miały wyliczyć wartość zamówienia dla tego samego koszyka (3 notesy po 12,50 zł i 2 długopisy po 4,00 zł), uwzględniając 10% rabatu na całość netto oraz 23% podatku VAT, z zaokrągleniem do dwóch miejsc po przecinku. Wszystkie trzy modele bezbłędnie wyliczyły docelowe wartości: 40,95 zł netto po rabacie, 9,42 zł VAT oraz 50,37 zł brutto.

Kiedy niska cena za token nie chroni budżetu: problem rozumowania i limitu max_tokens

Pełny obraz zachowania kosztowego uzyskałem po zestawieniu wszystkich sześciu zadań z mojego protokołu testowego (poza json i rachunek były to: wyliczenie rozmiaru wag w pamięci pamiec, napisanie funkcji w Pythonie kod, wykrycie brakującej danej o marży brak oraz korekta błędów językowych polski). W żadnym wywołaniu nie zadziałała pamięć podręczna (cached_tokens: 0), więc wszystkie koszty odzwierciedlają pełne stawki bazowe.

Sytuacja odwróciła się dramatycznie w zadaniach brak (gdzie należało odpowiedzieć wyłącznie słowami BRAK DANYCH na pytanie o marżę nieobecną w notatce) oraz polski (korekta zdania do postaci: „W każdym razie tę książkę wziąć mogę jutro, bo na razie nie mam czasu.” - szerzej to zachowanie przeanalizuję w planowanym tekście Kimi K3.1 Pro po polsku). W obu tych prostych promptach Kimi K3.1 Pro wpadł w długą pętlę wewnętrznego rozumowania. Zużył 1797 tokenów rozumowania (i łącznie 1800 tokenów wyjściowych), uderzając w sztywny sufit max_tokens=1800.

W rezultacie wywołanie zakończyło się statusem finish_reason: "length" oraz wartością answer: null. Ważne rozróżnienie metodologiczne: pusta odpowiedź przy fladze length to techniczne ucięcie generacji na limicie długości, a nie halucynacja merytoryczna czy odpowiedź w złym języku (oddzielne próby diagnostyczne z limitem 6000 tokenów nie są tu wliczane, by zachować spójność protokołu 1800 tokenów). Z punktu widzenia portfela efekt jest jednak bolesny: za dwa nieukończone wywołania zapłaciłem łącznie 0,036658 USD (ponad 1,8 centa za każde), podczas gdy GPT-6 Astra rozwiązał oba zadania poprawnie za łączną kwotę 0,004290 USD (ponad 8-krotnie taniej). Przez te dwa ucięcia cały pakiet 6 zapytań okazał się w Kimi K3.1 Pro najdroższy z całej trójki (0,055802 USD).

Jak kontrolować koszty i walidować zużycie tokenów w kodzie

Aby uniknąć płacenia za ucięte odpowiedzi w środowisku produkcyjnym, przy integracji z Kimi K3.1 Pro warto wdrożyć prostą walidację obiektu usage zwracanego w odpowiedzi JSON. Poniższy przykład pokazuje strukturę danych zużycia, jaką otrzymałem z OpenRouter dla uciętego zadania brak:

{
  "finish": "length",
  "cost_usd": 0.018348,
  "usage": {
    "prompt_tokens": 174,
    "completion_tokens": 1800,
    "prompt_tokens_details": {"cached_tokens": 0},
    "completion_tokens_details": {"reasoning_tokens": 1797}
  }
}

Praktyczna procedura zabezpieczająca budżet API powinna obejmować trzy kroki:

1. Monitorowanie proporcji reasoning_tokens do completion_tokens: jeżeli udział tokenów rozumowania przekracza 80-90% przy prostych zadaniach klasyfikacyjnych, warto przetestować zmianę konstrukcji promptu lub jawne ograniczenie budżetu rozumowania w parametrach API, o ile dany dostawca (bezpośrednie API Moonshot lub router) udostępnia osobny parametr limitujący sam łańcuch myśli.
2. Alerty na finish_reason == "length": każde takie zdarzenie przy zadaniu wymagającym krótkiej odpowiedzi (np. JSON lub pojedyncza etykieta) oznacza czysty koszt bez wartości biznesowej. Automatyczny retry z tym samym limitem max_tokens jedynie podwoi stratę.
3. Maksymalizacja cached_tokens: przy stawce 0,20 USD za 1M tokenów z cache’u, grupowanie zapytań wokół wspólnego, statycznego prefiksu pozwala zredukować koszt wejścia dziesięciokrotnie.

Ograniczenia mojej analizy i zastrzeżenia cenowe

Przed podjęciem decyzji budżetowych na podstawie powyższych danych należy uwzględnić kilka istotnych ograniczeń metodologicznych:

• Migawka cenowa z jednego dnia: wszystkie stawki katalogowe oraz wyniki wywołań pochodzą z 2026-10-23 (strefa czasowa Europe/Warsaw). Dostawcy API regularnie modyfikują cenniki, a w przypadku modeli takich jak DeepSeek v4.1-flash-1017 mogą obowiązywać stawki zależne od pory dnia.
• Kwoty netto bez podatków: oficjalna dokumentacja Kimi AI wyraźnie zaznacza, że ceny nie zawierają obowiązujących podatków. Firmy i deweloperzy rozliczający się w Unii Europejskiej muszą uwzględnić odpowiednie przepisy podatkowe (np. VAT / mechanizm odwrotnego obciążenia).
• Pojedyncza próba (N=1) w testach API: opisane wywołania dla 6 zadań to pojedyncze przebiegi przez OpenRouter. Pokazują one realne mechanizmy rozliczania tokenów i zachowanie limitu max_tokens, ale nie stanowią statystycznego benchmarku wydajności.
• Brak weryfikacji darmowych limitów: w swojej analizie opieram się wyłącznie na twardych stawkach cennikowych i nie zakładam istnienia żadnych darmowych pakietów startowych (free quotas).

Najczęściej zadawane pytania (FAQ)

Ile kosztuje 1 milion tokenów w API Kimi K3.1 Pro?

Według oficjalnego cennika na platform.Kimi (stan na 2026-10-23) standardowy wariant Kimi K3.1 Pro kosztuje 2,00 USD za 1 milion tokenów wejściowych, 0,20 USD za 1 milion tokenów wejściowych pobieranych z pamięci podręcznej (cached input) oraz 10,00 USD za 1 milion tokenów wyjściowych (przed doliczeniem podatków).

Czy tokeny rozumowania (reasoning tokens) w Kimi K3.1 Pro są płatne?

Tak. Wszystkie tokeny wygenerowane w fazie wewnętrznego rozumowania są wliczane do puli completion_tokens i rozliczane według stawki wyjściowej (10 USD za 1M w wersji Pro). W moich wywołaniach przez OpenRouter tokeny rozumowania stanowiły od 62% (zadanie JSON) do nawet 99,8% (ucięte zadania z limitem 1800 tokenów) wszystkich tokenów wyjściowych.

Czy subskrypcja czatu Kimi obejmuje dostęp do API?

Nie. Dokumentacja na stronie platform.Kimi jednoznacznie wskazuje, że rozliczenia API funkcjonują całkowicie niezależnie od planów subskrypcyjnych aplikacji Kimi.

Dlaczego pojedyncze zapytanie do Kimi K3.1 Pro może kosztować więcej niż w Claude Opus 5.5?

Choć stawki katalogowe Kimi K3.1 Pro są o połowę niższe niż w Claude Opus 5.5, o końcowym koszcie decyduje liczba wygenerowanych tokenów. Jeśli w prostym zadaniu (np. ekstrakcji JSON lub korekcie zdania) Kimi zużyje kilkaset lub ponad tysiąc tokenów na wewnętrzne rozumowanie, a Opus odpowie bezpośrednio bez fazy rozumowania, łączny koszt wywołania w Kimi będzie wyższy.

Źródła

• Oficjalny blog Kimi - zapowiedź modelu Kimi K3.1 Pro i dostępności API (data odczytu: 2026-10-23)
• Platforma API Kimi AI - główny cennik tokenów Pro i Highspeed (data odczytu: 2026-10-23)
• Dokumentacja cennika czatu Kimi API - limity kontekstu i warunki podatkowe (data odczytu: 2026-10-23)
• Profil Moonshot AI na Hugging Face - weryfikacja dostępności wag modeli (data odczytu: 2026-10-23)

Materiały klastra: JSON przez API.

Link do Kimi jest partnerski: jeśli kupisz przez niego, serwis dostaje prowizję, a Ty płacisz tyle samo. Nie wpływa to na treść, także tam, gdzie piszę krytycznie.