Kimi K3: funkcje, benchmarki, API i 5 praktycznych przykładów

Wyścig otwartych modeli znów przyspieszył 16 lipca 2026 r., kiedy Moonshot AI udostępniło Kimi K3, model z 2,8 biliona parametrów, z oknem kontekstu 1 miliona tokenów i natywną obsługą vision. To największy otwarty model, jaki Moonshot wypuścił — znacznie większy od Kimi K2 — i pierwszy, który opisują jako wchodzący do klasy 3 bilionów parametrów.

Jeśli szukasz historii premiery, dogłębnej analizy architektury, wykresów benchmarków, porównań z Claude’em, GPT i innymi chińskimi laboratoriami oraz listy ograniczeń od Moonshot, nasz wpis na blogu o Kimi K3 omawia to wszystko. Ten tutorial to praktyczna część: jak uzyskać dostęp i jak model zachowuje się w użyciu. Przejdę przez pięć małych przykładów — cztery przez API, gdzie pokazuję rzeczywiste użycie tokenów i koszt, oraz dwa w aplikacji webowej kimi.com. Razem pokazują, jak K3 radzi sobie z:

• Wywoływaniem narzędzi i zwracaniem ścisłego JSON-a
• Ładowaniem definicji narzędzia w locie
• Obniżaniem kosztu długiego kontekstu dzięki automatycznemu cache’owaniu
• Odczytywaniem zrzutu ekranu i naprawą układu
• Budowaniem interaktywnego dashboardu z jednego promptu

Cztery przykłady API uruchomiono 17 lipca 2026 r. na modelu kimi-k3 i kosztowały około 11 centów przy zimnym starcie, a po włączeniu cache’u — kilka centów.

Jak uzyskać dostęp do Kimi K3

Najszybszy sposób, by wypróbować model, to kimi.com, gdzie aplikacja webowa i mobilne działają na Kimi K3 dla ogólnych zadań agentowych bez konfiguracji.

Do cięższych zadań, jak raporty i dashboardy, jest Kimi Work — aplikacja desktopowa.

Jeśli żyjesz w terminalu, Kimi Code to agent do kodowania, którego instalujesz z npm jako @moonshot-ai/kimi-code; model wybierasz komendą /model. Użycie K3 w Kimi Code wymaga płatnej subskrypcji, a pełne okno 1 miliona tokenów — wyższego planu.

Ten tutorial skupia się na surowym API i aplikacji webowej, ale agent terminalowy też jest, jeśli chcesz.

K3 nie zastępuje jednak swoich rodzeństwa. Poniższa tabela pokazuje, jak obecna linia jest podzielona.

Krótko mówiąc: K3 to model wyjściowy, gdy zadanie łączy kod, narzędzia, dokumenty i obrazy lub gdy naprawdę potrzebujesz okna 1 miliona tokenów. Do czystej generacji kodu, gdzie prędkość liczy się bardziej niż kontekst, kimi-k2.7-code nadal jest rozsądniejszym wyborem, więc nie zakładaj, że najnowszy model zawsze jest właściwy.

Konfiguracja API Kimi K3

API jest zgodne z OpenAI SDK, więc jeśli już z niego korzystałeś, prawie nic tu nie będzie nowe. Potrzebujesz Pythona 3.9 lub nowszego i klucza API.

Krok 1: Wygenerowanie klucza API

Najpierw zaloguj się do platformy Kimi i otwórz w konsoli stronę API Keys. Utwórz klucz, skopiuj go jednorazowo i przechowuj w bezpiecznym miejscu — nie zobaczysz go ponownie. Potrzebujesz też małego salda na koncie, aby wykonywać wywołania; na cały ten tutorial kilka dolarów w zupełności wystarczy.

Tworzenie klucza API Kimi K3. Obraz: autor.

Krok 2: Instalacja SDK

Następnie zainstaluj OpenAI SDK w swoim środowisku. Wystarczy jedno polecenie.

python -m pip install --upgrade "openai>=1.0"

To pobiera bibliotekę kliencką używaną w dalszych przykładach i nie ma nic specyficznego dla Kimi do instalacji.

Krok 3: Przechowywanie klucza i inicjalizacja klienta

Lepiej odczytywać klucz ze zmiennej środowiskowej niż wklejać go w kod. Ustaw MOONSHOT_API_KEY w swojej powłoce lub pliku .env , a następnie skieruj klienta na bazowy URL Moonshot.

import os
from openai import OpenAI

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

Dwie rzeczy różnią się od standardowej konfiguracji OpenAI: base_url oraz nazwa modelu, którą jest kimi-k3. Mając to, możesz wykonać wywołanie.

Krok 4: Wykonanie pierwszego wywołania

Czas na pierwsze żądanie. Poprosiłem model, by się przedstawił, co przerodziło się w mały szczery moment.

completion = client.chat.completions.create(
    model="kimi-k3",
    messages=[{"role": "user", "content": "Introduce Kimi K3 in one sentence."}],
    max_completion_tokens=800,
)
print(completion.choices[0].message.content)

Odpowiedź była uprzejmą odmową zgadywania: model stwierdził, że nie ma wiarygodnych informacji o Kimi K3, bo został wytrenowany przed własną premierą, i odesłał do ogłoszeń Moonshot. To przydatne przypomnienie, że model nie zna samego siebie. To wywołanie API kosztowało około siedem dziesiątych centa. Zwróć uwagę na limit max_completion_tokens — ustawiałem go w każdym wywołaniu w tym tutorialu, żeby zbyt gadatliwe odpowiedzi nie podbijały rachunku.

Pierwsze wywołanie API Kimi K3. Obraz: autor.

Przykład 1: Strumieniowanie rozumowania i finalnej odpowiedzi

K3 zawsze rozumuje, a API zwraca to rozumowanie w osobnym kanale niż odpowiedź. Przy strumieniowaniu każdy kawałek może zawierać reasoning_content, finalne content lub oba, więc możesz osobno umieścić myślenie i odpowiedź.

stream = client.chat.completions.create(
    model="kimi-k3",
    messages=[{"role": "user", "content": "A bat and a ball cost $1.10 together. The bat costs $1.00 more than the ball. How much is the ball?"}],
    max_completion_tokens=1200,
    stream=True,
    stream_options={"include_usage": True},
)

for chunk in stream:
    if not chunk.choices:
        continue
    delta = chunk.choices[0].delta
    reasoning = getattr(delta, "reasoning_content", None)
    if reasoning:
        print(reasoning, end="", flush=True)
    if delta.content:
        print(delta.content, end="", flush=True)

Model najpierw strumieniował tok rozumowania: rozpoznał zadanie kij-baseball i piłka jako klasyczny Cognitive Reflection Test, wskazał intuicyjnie błędną odpowiedź 0,10 $, potem rozwiązał algebrę do 0,05 $ za piłkę i sprawdził, że 1,05 $ plus 0,05 $ daje 1,10 $. Najważniejszy jest podział: w prawdziwej aplikacji pokazujesz użytkownikom content, a reasoning_content trzymasz do logów, bo surowe rozumowanie rzadko chcesz pokazywać w produkcji. To wywołanie zużyło 488 tokenów wyjścia i kosztowało poniżej centa.

Strumieniowanie rozumowania, potem odpowiedzi. Obraz: autor.

Przykład 2: Wywoływanie narzędzi ze strukturalnym wynikiem

Kimi K3 to model w linii, który obsługuje tool_choice="required", co wymusza co najmniej jedno wywołanie narzędzia w turze. Przydaje się, gdy chcesz, by model pobrał dane przed odpowiedzią zamiast zgadywać. Dałem mu dwa atrapy narzędzi — sprawdzanie ceny i stanu magazynu — wymusiłem wywołanie narzędzia, uruchomiłem narzędzia lokalnie, a następnie poprosiłem o wynik jako ścisły JSON przez response_format.

first = client.chat.completions.create(
    model="kimi-k3",
    messages=messages,
    tools=TOOLS,
    tool_choice="required",
    max_completion_tokens=2500,
)
assistant_message = first.choices[0].message
messages.append(assistant_message)

for tool_call in assistant_message.tool_calls or []:
    args = json.loads(tool_call.function.arguments)
    messages.append({"role": "tool", "tool_call_id": tool_call.id, "content": run_tool(tool_call.function.name, args)})

Model wywołał oba narzędzia z właściwym kodem produktu, a potem zwrócił czyste podsumowanie zamówienia jako JSON: pięć klawiatur mechanicznych po 89 $ każda, suma 445 $, i flaga stanu magazynu ustawiona na true. Dwa szczegóły są kluczowe w praktyce. Musisz dodać pełną wiadomość asystenta z powrotem do rozmowy przed dołączeniem wyników narzędzi, a JSON parsować tylko z content, nigdy z pola rozumowania. Para wywołań łącznie kosztowała poniżej centa.

Wywołania narzędzi i strukturalny JSON w odpowiedzi. Obraz: autor.

Przykład 3: Dynamiczne ładowanie narzędzi

Jeśli masz dziesiątki narzędzi, wysyłanie ich definicji przy każdym żądaniu marnuje tokeny i zaśmieca prompt. Kimi K3 pozwala wstrzyknąć definicję narzędzia w środku rozmowy poprzez wiadomość system zawierającą pole tools i bez content. Narzędzie od tego momentu jest dostępne, co trzyma duże katalogi narzędzi poza cache’owanym prefiksem, dopóki faktycznie nie będą potrzebne.

messages = [
    {"role": "user", "content": "Convert 100 US dollars to euros at a rate of 0.92."},
    {"role": "system", "tools": [{
        "type": "function",
        "function": {
            "name": "convert_currency",
            "description": "Convert an amount from one currency to another",
            "parameters": {
                "type": "object",
                "properties": {"amount": {"type": "number"}, "rate": {"type": "number"}},
                "required": ["amount", "rate"],
            },
        },
    }]},
]
completion = client.chat.completions.create(model="kimi-k3", messages=messages)
print(completion.choices[0].message.tool_calls)

K3 podchwycił świeżo załadowane narzędzie i wywołał convert_currency z kwotą 100 i kursem 0,92 — dokładnie jak zamierzono. Pamiętaj tylko, że serwer nie przechowuje za ciebie tej definicji, więc jeśli chcesz, by narzędzie pozostało dostępne, wysyłasz wiadomość system w kolejnych żądaniach. To było najtańsze wywołanie z zestawu — około dwóch dziesiątych centa.

Wywołanie dynamicznie załadowanego narzędzia walutowego. Obraz: autor.

Przykład 4: Obniżanie kosztu długiego kontekstu dzięki cache’owi

Tu okno 1 miliona tokenów staje się praktyczne. Cache kontekstu działa automatycznie — bez ID cache’a i bez TTL do zarządzania. Wysyłasz duży prefiks, utrzymujesz go bajt-w-bajt identycznym w kolejnych żądaniach, a powtarzana część jest rozliczana po stawce cache-hit zamiast cache-miss. Żeby różnica była widoczna, użyłem bazy wiedzy ok. 33 000 tokenów i zadałem o nią pytanie.

knowledge = Path("knowledge_base.md").read_text(encoding="utf-8")
completion = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {"role": "system", "content": knowledge},
        {"role": "user", "content": "What is the rated payload of the Atlas robot?"},
    ],
    max_completion_tokens=600,
)

Za pierwszym razem żaden fragment prefiksu nie był w cache’u i żądanie kosztowało ok. 9,9 centa za około 33 000 tokenów wejścia. Po zapisaniu prefiksu, to samo żądanie trafiło w cache na wszystkich 32 512 tokenach prefiksu i kosztowało ok. 1,1 centa — niemal dziewięciokrotny spadek. Powodem jest różnica cen: wejście z cache’a to 0,30 $ za milion tokenów vs 3,00 $ bez cache’a. Jedna osobliwość: zapisy do cache’a są asynchroniczne, więc trafienie nie pojawia się przy natychmiastowym kolejnym wywołaniu. Pojawia się później, więc uruchomienie skryptu dwa razy w odstępie minuty pokaże najpierw miss, potem hit.

Koszt cache miss vs cache hit. Obraz: autor.

Przykład 5: Wychwytywanie błędów układu na zrzucie ekranu

Vision jest natywne w K3, a API to czysty sposób, by z niego korzystać, choć nie przyjmie publicznego URL-a obrazu. Wysyłasz obraz jako data URL base64 i czynisz content wiadomości tablicą obiektów: jedna część to obraz, druga to tekst. Wyrenderowałem mały dashboard z kilkoma celowymi błędami układu, zapisałem zrzut i poprosiłem K3 o wskazanie, co jest nie tak.

Dashboard z celowymi błędami układu. Obraz: autor.

import base64
from pathlib import Path

image_data = base64.b64encode(Path("broken_dashboard.png").read_bytes()).decode()
completion = client.chat.completions.create(
    model="kimi-k3",
    messages=[{
        "role": "user",
        "content": [
            {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{image_data}"}},
            {"type": "text", "text": "List the layout and alignment problems you can see, and give a short CSS fix for each."},
        ],
    }],
    max_completion_tokens=3500,
)
print(completion.choices[0].message.content)

K3 dobrze odczytał obraz. Wychwycił kartę, która siedzi niżej niż rząd i zachodzi na sąsiadkę, plakietkę ustawioną na wierzchu liczby (nawet błędnie odczytał zasłonięte 3 910 jako 5 910 — błąd sam się ujawnia), nierówną przerwę przed ostatnią kartą, słupek wylewający się do karty powyżej i dymek narzędzia siedzący nad słupkami; podał też krótką poprawkę CSS dla każdego, np. przeniesienie kart do jednej siatki. Pominął jednak niemal niewidoczny napis o niskim kontraście, więc vision wyłapuje to, co rzuca się w oczy bardziej niż słabe detale. Wywołanie kosztowało około dwa centy.

Ograniczenia Kimi K3

Przykłady API wypadły dobrze, ale warto nazwać kilka zadziorów, żeby cię nie zaskoczyły. Większość z nich napotkałem bezpośrednio.

• Dostępne jest tylko reasoning_effort="max", więc na razie nie możesz ograniczyć rozumowania, by oszczędzić pieniądze.

• Ustawienia próbkowania są stałe. Wartości takie jak temperature, top_p i kary są zablokowane, więc pomiń je w żądaniach zamiast je dostrajać.

• Wyjście bywa długie i drogie. Ogranicz max_completion_tokens, jak w przykładach, i waliduj każdą pętlę agenta.

• Publiczne URL-e obrazów nie są obsługiwane przez API, więc do vision licz na base64 lub przesyłane pliki.

Żadne z nich nie jest dealbreakerem, ale wpływają na sposób użycia modelu. Najbardziej pilnowałbym kosztu wyjścia.

Wnioski

W moich uruchomieniach wyróżniły się dwie rzeczy. Wywoływanie narzędzi i strukturalne wyjście nie wymagały ponowień, a cache okazał się ważniejszy, niż się spodziewałem, bo ponowne użycie tego samego długiego prefiksu sprawiło, że duże żądanie było tanie do wysłania ponownie. Więc do analiz w skali repozytorium, powtarzalnych wywołań z długim kontekstem czy inżynierii multimodalnej K3 jest rozsądnym domyślnym wyborem; do szybkiego, taniego czatu lub precyzyjnej kontroli próbkowania łatwiejszy będzie mniejszy model. Szczegóły o otwartych wagach i licencji, o których wspomniałem wcześniej, powinny się wyjaśnić po wydaniu 27 lipca.

Więcej tła o wzorcach użytych w tych przykładach znajdziesz w naszym kursie Developing AI Systems with the OpenAI API, który obejmuje wywoływanie funkcji i łączenie modeli z zewnętrznymi narzędziami w Pythonie.