Sari la conținutul principal

Kimi K3: caracteristici, benchmark-uri, API și 5 exemple practice

Află ce este Kimi K3, cum îl accesezi și cum gestionează raționamentul, tool-urile, contextul lung și viziunea în cinci exemple practice.
Actualizat 21 iul. 2026  · 12 min. citire

Explorează cu AI

Deschide în ChatGPTDeschide în ClaudeDeschide în Perplexity

Cursa modelelor open s-a mișcat din nou pe 16 iulie 2026, când Moonshot AI a lansat Kimi K3, un model cu 2,8 trilioane de parametri, o fereastră de context de 1 milion de tokeni și viziune nativă. Este cel mai mare model open livrat de Moonshot, mult peste Kimi K2 ca dimensiune, și primul pe care îl descriu ca atingând clasa de 3 trilioane de parametri.

Dacă vrei povestea lansării, detaliile arhitecturii, graficele de benchmark, comparațiile cu Claude, GPT și celelalte laboratoare chineze, plus lista de limitări oferită de Moonshot, articolul nostru despre Kimi K3 acoperă tot. Acest tutorial este partea practică: cum îl accesezi și cum se comportă în utilizare. Voi parcurge cinci exemple mici, patru prin API, unde arăt consum real de tokeni și cost, și două în aplicația web kimi.com. Împreună, ele arată cum gestionează K3:

  • Apelarea de tool-uri și returnarea de JSON strict
  • Încărcarea din mers a unei definiții de tool
  • Reducerea costului pe context lung cu caching automat
  • Citirea unui screenshot și corectarea layout-ului
  • Construirea unui dashboard interactiv dintr-un singur prompt

Cele patru exemple prin API au rulat pe 17 iulie 2026 pe modelul kimi-k3 și au costat aproximativ 11 cenți la prima execuție rece, sau câțiva cenți după ce a intrat în joc caching-ul.

Cum accesezi Kimi K3

Cea mai rapidă cale de a încerca modelul este kimi.com, unde aplicația web și cele mobile rulează Kimi K3 pentru sarcini generale de tip agent, fără setup.

Pentru lucru mai greu, ca rapoarte și dashboard-uri, există Kimi Work, o aplicație desktop.

Dacă trăiești în terminal, Kimi Code este un agent de cod pe care îl instalezi din npm ca @moonshot-ai/kimi-code, iar modelul îl alegi acolo cu comanda /model. Folosirea K3 în Kimi Code necesită un abonament plătit, iar fereastra completă de 1 milion de tokeni cere un nivel mai înalt.

Acest tutorial se concentrează pe API-ul brut și aplicația web, dar agentul de terminal este acolo dacă îl vrei.

Totuși, K3 nu își înlocuiește frații. Tabelul de mai jos arată cum se împarte lineup-ul actual.

Model

Fereastră de context

Cel mai potrivit pentru

kimi-k3

1.048.576 tokeni

Muncă flagship: cod pe termen lung, viziune, sarcini de cunoaștere

kimi-k2.7-code

262.144 tokeni

Coding dedicat, cu o opțiune high-speed mai rapidă

kimi-k2.6

262.144 tokeni

Chat general text, imagine și video

Pe scurt, K3 este modelul de pornire când o sarcină combină cod, tool-uri, documente și imagini sau când chiar ai nevoie de fereastra de 1 milion de tokeni. Pentru generare pură de cod unde viteza contează mai mult decât contextul, kimi-k2.7-code rămâne alegerea mai logică, așa că nu presupune că cel mai nou model este mereu cel potrivit.

Configurarea API-ului Kimi K3

API-ul este compatibil cu SDK-ul OpenAI, așa că, dacă l-ai mai folosit, aproape nimic de aici nu e nou. Ai nevoie de Python 3.9 sau mai nou și de o cheie API.

Pasul 1: Generarea unei chei API

Mai întâi, autentifică-te pe platforma Kimi și deschide pagina API Keys din consolă. Creează o cheie, copiaz-o o singură dată și păstreaz-o undeva în siguranță, pentru că nu o vei mai vedea. Ai nevoie și de un mic sold în cont pentru a face apeluri, iar pentru tot acest tutorial câțiva dolari sunt suficienți.

Pagina API keys din consola platformei Kimi, care arată butonul create API key.

Crearea unei chei API pentru Kimi K3. Imagine de Autor.

Pasul 2: Instalarea SDK-ului

Apoi, instalează SDK-ul OpenAI în mediul tău. O singură comandă rezolvă.

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

Aceasta aduce biblioteca client folosită în restul exemplelor și nu există nimic specific Kimi de instalat.

Pasul 3: Stocarea cheii și inițializarea clientului

E mai bine să citești cheia dintr-o variabilă de mediu decât să o lipești în cod. Setează MOONSHOT_API_KEY în shell-ul tău sau într-un fișier .env , apoi indică clientului baza de URL a Moonshot.

import os
from openai import OpenAI

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

Singurele două lucruri care diferă față de o configurare standard OpenAI sunt base_url și numele modelului, care este kimi-k3. Cu asta la locul ei, ești gata să faci un apel.

Pasul 4: Primul tău apel

Acum, pentru prima cerere. I-am cerut modelului să se prezinte într-o propoziție, ceea ce s-a transformat într-un mic moment onest.

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)

Răspunsul a fost un refuz politicos de a ghici: modelul a spus că nu are informații fiabile despre Kimi K3, deoarece a fost antrenat înainte de propria lansare, și m-a îndrumat către anunțurile Moonshot. Este un reminder util că un model nu știe despre el însuși. Apelul API tocmai făcut a costat aproximativ șapte zecimi de cent. Observă plafonul max_completion_tokens , pe care l-am setat la fiecare apel în acest tutorial ca să împiedic ieșirea prea vorbăreață să umfle nota de plată.

Output în terminal unde Kimi K3 spune că nu are informații fiabile despre sine.

Primul output al apelului API pentru Kimi K3. Imagine de Autor.

Exemplul 1: Streaming al raționamentului și răspunsul final

K3 raționează mereu, iar API-ul returnează acel raționament pe un canal separat de răspuns. Când faci streaming, fiecare bucățică poate conține reasoning_content, content final sau ambele, astfel încât să poți afișa separat gândirea și răspunsul.

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)

Modelul a făcut mai întâi streaming cu modul în care a lucrat: a recunoscut problema bâtă-minge ca testul clasic de reflecție cognitivă, a semnalat răspunsul intuitiv greșit de 0,10 $, apoi a lucrat algebric până la faptul că mingea costă 0,05 $ și a verificat că 1,05 $ plus 0,05 $ fac 1,10 $. Separarea e partea utilă: într-o aplicație reală, afișezi content utilizatorilor și păstrezi reasoning_content pentru loguri, deoarece arătarea raționamentului brut în producție e rar ceea ce îți dorești. Acest apel a folosit 488 tokeni de ieșire și a costat sub un cent.

Terminalul arată Kimi K3 făcând streaming cu raționamentul pas cu pas și apoi răspunsul final că mingea costă cinci cenți.

Streaming al raționamentului, apoi răspunsul final. Imagine de Autor.

Exemplul 2: Apelare de tool-uri cu output structurat

Kimi K3 este modelul din lineup care suportă tool_choice="required", care forțează cel puțin un apel de tool într-o tură. Asta e util când vrei ca modelul să aducă date înainte de a răspunde, în loc să ghicească. Aici i-am dat două tool-uri mock, o interogare de preț și o verificare de stoc, am forțat un apel de tool, am rulat tool-urile local și apoi am cerut rezultatul ca JSON strict folosind 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)})

Modelul a apelat ambele tool-uri cu codul de produs corect, apoi a returnat un sumar de comandă curat ca JSON: cinci tastaturi mecanice la 89 $ fiecare, un total de 445 $ și un steag de stoc setat pe true. Două detalii fac asta să funcționeze în practică. Trebuie să adaugi în conversație întregul mesaj al asistentului înainte de a adăuga rezultatele tool-urilor și ar trebui să parsezi doar content pentru JSON, niciodată câmpul de raționament. Perechea de apeluri a costat împreună sub un cent.

Terminal care arată două apeluri de tool urmate de un sumar de comandă JSON structurat, totalizând patru sute patruzeci și cinci de dolari

Apeluri de tool și output JSON structurat. Imagine de Autor.

Exemplul 3: Încărcarea dinamică a tool-urilor

Dacă ai zeci de tool-uri, trimiterea tuturor definițiilor la fiecare cerere irosește tokeni și aglomerează promptul. Kimi K3 îți permite să inserezi o definiție de tool la mijlocul conversației cu un mesaj system care poartă un câmp tools și nu are content. Tool-ul devine disponibil de atunci înainte, ceea ce ține cataloagele mari de tool-uri în afara prefixului tău cache-uit până când un tool chiar e necesar.

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 a preluat tool-ul proaspăt încărcat și a apelat convert_currency cu suma 100 și rata 0,92, exact cum intenționat. Un lucru de reținut este că serverul nu reține această definiție pentru tine, așa că retrimiți mesajul de sistem în cererile ulterioare dacă vrei ca tool-ul să rămână disponibil. Acesta a fost cel mai ieftin apel din set, aproximativ două zecimi de cent.

Terminal arătând Kimi K3 apelând un tool de conversie valutară încărcat dinamic, cu sumă și rată.

Apelarea unui tool valutar încărcat dinamic. Imagine de Autor.

Exemplul 4: Reducerea costului pe context lung cu caching

Acesta este exemplul în care fereastra de 1 milion de tokeni devine practică. Caching-ul de context este automat, fără ID de cache și fără time-to-live de gestionat. Trimiți un prefix mare, îl păstrezi identic byte-cu-byte la cererile ulterioare, iar partea repetată este taxată la rata de cache-hit în loc de cache-miss. Ca să fac diferența vizibilă, am folosit o bază de cunoștințe de ~33.000 de tokeni și am pus o întrebare despre ea.

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,
)

Prima dată când am trimis acel prefix, nimic nu era în cache, iar cererea a costat aproximativ 9,9 cenți pentru circa 33.000 de tokeni de input. După ce prefixul a fost văzut, aceeași cerere a lovit cache-ul pe toți cei 32.512 tokeni de prefix și a costat aproximativ 1,1 cenți, aproape o scădere de nouă ori. Motivul este diferența de preț: input-ul cache-uit este 0,30 $ per milion de tokeni versus 3,00 $ pentru necachuit. O particularitate la care am ajuns este că scrierile în cache sunt asincrone, deci hit-ul nu apare la un apel imediat unul după altul. Apare la o cerere ulterioară, așa că rularea scriptului de două ori la un minut distanță arată întâi miss, apoi hit.

Două rulări în terminal ale scriptului de caching, arătând un cache miss aproape de zece cenți și un cache hit aproape de un cent.

Cost cache miss versus cache hit. Imagine de Autor.

Exemplul 5: Identificarea bug-urilor de layout într-un screenshot

Viziunea este nativă în K3, iar API-ul este o cale curată de a o folosi, deși nu acceptă un URL public de imagine. Trimiți imaginea ca un URL de date base64 și faci ca content al mesajului să fie un array de obiecte, o parte pentru imagine și una pentru text. Am randat un mic dashboard cu câteva bug-uri de layout deliberate, am salvat un screenshot și am întrebat K3 ce e în neregulă.

Un screenshot de dashboard cu un card nealiniat, un badge așezat pe un număr și o bară care iese din grafic.

Dashboard-ul cu bug-uri deliberate de layout. Imagine de 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 a citit bine imaginea. A prins cardul care stă mai jos decât rândul și se suprapune peste vecin, badge-ul parcat peste un număr (chiar a citit greșit 3.910 acoperit ca 5.910, ceea ce este bug-ul care se confirmă), spațiul inegal înainte de ultimul card, bara care sângerează în sus în cardul de deasupra și tooltip-ul care stă peste bare, și a dat câte un mic fix CSS pentru fiecare, cum ar fi mutarea cardurilor într-un singur grid. Totuși, a sărit peste subtitlul aproape invizibil, cu contrast scăzut, deci viziunea prinde ce sare în ochi mai mult decât detaliul abia vizibil. Apelul a costat aproximativ doi cenți.

Limitări Kimi K3

Exemplele prin API au mers bine, dar merită menționate câteva asperități, ca să nu te ia prin surprindere. M-am lovit de majoritatea direct.

  • Deocamdată este disponibil doar reasoning_effort="max", deci nu poți reduce gândirea ca să economisești bani încă.

  • Setările de sampling sunt fixe. Valori precum temperature, top_p și penalizările sunt blocate, așa că omite-le din cereri în loc să le reglezi.

  • Output-ul poate deveni lung și scump. Pune un plafon la max_completion_tokens, ca în exemple, și validează orice buclă de agent.

  • URL-urile publice de imagine nu sunt suportate prin API, deci planifică base64 sau fișiere încărcate pentru viziune acolo.

Niciuna dintre acestea nu este un blocker, dar îți modelează modul de utilizare a modelului. Costul pe output este cel pe care l-aș urmări cel mai atent.

Concluzie

În rulările mele, două lucruri au ieșit în evidență. Apelarea de tool-uri și output-ul structurat nu au avut nevoie de retry-uri, iar caching-ul a contat mai mult decât mă așteptam, deoarece refolosirea aceluiași prefix lung a făcut ieftină retrimiterea unei cereri mari. Așadar, pentru analiză la nivel de repository, apeluri repetate pe context lung sau inginerie multimodală, K3 este un default rezonabil; pentru chat rapid și ieftin sau control fin al sampling-ului, un model mai mic e alegerea mai ușoară. Detaliile despre greutăți open și licență, pe care le-am semnalat mai devreme, ar trebui să fie mai clare după lansarea din 27 iulie.

Pentru mai mult context despre tiparele folosite în aceste exemple, cursul nostru Developing AI Systems with the OpenAI API acoperă function calling și conectarea modelelor la tool-uri externe în Python.

Subiecte

Învață cu DataCamp

track

Inginer AI asociat pentru dezvoltatori

26 oră
Învață cum să integrezi AI în aplicații software folosind API-uri și biblioteci open-source. Începe-ți astăzi călătoria spre a deveni Inginer AI!
Vezi detaliiRight Arrow
Începeți Cursul
Vezi mai multRight Arrow