Kimi K3: Funktioner, benchmarktester, API och 5 praktiska exempel

Kapplöpningen för öppna modeller tog fart igen den 16 juli 2026 när Moonshot AI lanserade Kimi K3, en modell med 2,8 biljoner parametrar, ett kontextfönster på 1 miljon token och inbyggd vision. Det är den största öppna modellen Moonshot har släppt, långt större än Kimi K2, och den första de beskriver som att den når klassen på 3 biljoner parametrar.

Om du vill ha lanseringshistoriken, den djupgående genomgången av arkitekturen, benchmarkdiagrammen, jämförelserna med Claude, GPT och andra kinesiska labb, samt Moonshots egen begränsningslista, täcker vårt blogginlägg om Kimi K3 allt detta. Den här guiden är den praktiska delen, inklusive hur du får tillgång till modellen och hur den beter sig när du använder den. Jag går igenom fem små exempel, fyra via API:t där jag visar faktisk tokenanvändning och kostnad, och två i webbappen på kimi.com. Tillsammans visar de hur K3 hanterar:

• Anropa verktyg och returnera strikt JSON
• Ladda en verktygsdefinition i farten
• Minska kostnaden för lång kontext med automatisk cache
• Läsa en skärmdump och fixa layouten
• Bygga en interaktiv instrumentpanel från en enda prompt

De fyra API-exemplen kördes den 17 juli 2026 mot kimi-k3-modellen och kostade omkring 11 cent vid kall körning, eller ett par cent när cache började gälla.

Så här får du tillgång till Kimi K3

Det snabbaste sättet att prova modellen är kimi.com, där webbappen och mobilapparna kör Kimi K3 för allmänna agentuppgifter utan konfiguration.

För tyngre arbete som rapporter och instrumentpaneler finns Kimi Work, en skrivbordsapp.

Om du lever i terminalen är Kimi Code en kodningsagent du installerar från npm som @moonshot-ai/kimi-code, och du väljer modell där med kommandot /model. Att använda K3 i Kimi Code kräver ett betalt medlemskap, och hela fönstret på 1 miljon token kräver en högre nivå.

Den här guiden fokuserar på det råa API:t och webbappen, men terminalagenten finns där om du vill ha den.

K3 ersätter dock inte sina syskon. Tabellen nedan visar hur den nuvarande uppställningen fördelas.

Den korta versionen är att K3 är modellen att börja med när ett jobb blandar kod, verktyg, dokument och bilder, eller när du verkligen behöver fönstret på 1 miljon token. För ren kodgenerering där hastighet är viktigare än kontext är kimi-k2.7-code fortfarande det mer rimliga valet, så utgå inte från att den senaste modellen alltid är rätt.

Konfigurera Kimi K3 API

API:t är kompatibelt med OpenAI:s SDK, så om du har använt det tidigare är nästan inget här nytt. Du behöver Python 3.9 eller senare och en API-nyckel.

Steg 1: Skapa en API-nyckel

Logga först in på Kimi-plattformen och öppna sidan API Keys i konsolen. Skapa en nyckel, kopiera den en gång och lagra den på ett säkert ställe, för du kommer inte att se den igen. Du behöver också ett litet saldo på kontot för att kunna göra anrop, och för hela den här guiden räcker några dollar gott.

Skapa en Kimi K3 API-nyckel. Bild: författaren.

Steg 2: Installera SDK:n

Installera sedan OpenAI:s SDK i din miljö. Ett enda kommando räcker.

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

Det hämtar klientbiblioteket som resten av exemplen använder, och det finns inget Kimi-specifikt att installera.

Steg 3: Lagra nyckeln och initiera klienten

Det är bättre att läsa in nyckeln från en miljövariabel än att klistra in den i koden. Sätt MOONSHOT_API_KEY i ditt skal eller en .env -fil, och peka sedan klienten mot Moonshots bas-URL.

import os
from openai import OpenAI

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

De enda två sakerna som skiljer från en standardinstallation av OpenAI är base_url och modellnamnet, som är kimi-k3. Med det på plats är du redo att göra ett anrop.

Steg 4: Gör ditt första anrop

Nu till en första förfrågan. Jag bad modellen att presentera sig själv, vilket blev ett ärligt litet ögonblick.

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)

Svaret var en artig vägran att gissa: modellen sa att den inte hade tillförlitlig information om Kimi K3, eftersom den tränats före sin egen lansering, och hänvisade mig i stället till Moonshots annonseringar. Det är en nyttig påminnelse om att en modell inte känner till sig själv. API-anropet jag just gjorde kostar ungefär sju tiondels cent. Notera gränsen max_completion_tokens som jag sätter på varje anrop i den här guiden för att hindra pratigt utdata från att dra upp notan.

Första API-anropets utdata från Kimi K3. Bild: författaren.

Exempel 1: Strömmande resonemang och slutligt svar

K3 resonerar alltid, och API:t returnerar det resonemanget på en separat kanal från svaret. När du strömmar kan varje del bära reasoning_content, slutligt content eller båda, så att du kan placera tänkandet och svaret separat.

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)

Modellen strömmade först sitt arbete: den kände igen slagträ-och-boll-frågan som det klassiska Cognitive Reflection Test, markerade det intuitivt felaktiga svaret 0,10 $, löste sedan algebran till att bollen kostar 0,05 $ och kontrollerade att 1,05 $ plus 0,05 $ blir 1,10 $. Uppdelningen är det användbara: i en riktig app visar du content för användare och behåller reasoning_content i loggarna, eftersom rått resonemang sällan är något man vill visa i produktion. Det här anropet använde 488 utgående token och kostade under en cent.

Strömmande resonemang följt av slutligt svar. Bild: författaren.

Exempel 2: Verktygsanrop med strukturerad utdata

Kimi K3 är modellen i uppställningen som stödjer tool_choice="required", vilket tvingar fram minst ett verktygsanrop under en vända. Det är användbart när du vill att modellen ska hämta data innan den svarar i stället för att gissa. Här gav jag den två fejkade verktyg, en prisuppslagning och en lagersökning, tvingade ett verktygsanrop, körde verktygen lokalt och bad sedan om resultatet som strikt JSON med hjälp av 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)})

Modellen anropade båda verktygen med rätt produktkod och returnerade sedan en ren ordersammanfattning som JSON: fem mekaniska tangentbord à 89 $, totalt 445 $, och en lagerflagga satt till true. Två detaljer får detta att fungera i praktiken. Du måste lägga till hela assistentmeddelandet tillbaka i konversationen innan du lägger till verktygsresultat, och du bör bara parsa content för JSON, aldrig resonemangsfältet. De två anropen kostade tillsammans under en cent.

Verktygsanrop och strukturerad JSON-utdata. Bild: författaren.

Exempel 3: Ladda verktyg dynamiskt

Om du har dussintals verktyg slösar det token och skräpar ner prompten att skicka alla deras definitioner vid varje begäran. Kimi K3 låter dig injicera en verktygsdefinition mitt i konversationen med ett system-meddelande som bär ett tools-fält och inget content. Verktyget blir tillgängligt från och med den punkten, vilket håller stora verktygskataloger borta från din cache:ade prefix tills ett verktyg faktiskt behövs.

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 plockade upp det nyss inlästa verktyget och anropade convert_currency med beloppet 100 och kursen 0,92, exakt som avsett. En sak att komma ihåg är att servern inte behåller den här definitionen åt dig, så du skickar om systemmeddelandet i senare förfrågningar om du vill att verktyget ska fortsätta vara tillgängligt. Detta var det billigaste anropet i uppsättningen med cirka två tiondels cent.

Anrop av ett dynamiskt inläst valutaverktyg. Bild: författaren.

Exempel 4: Sänka kostnaden för lång kontext med cache

Det här exemplet är där fönstret på 1 miljon token blir praktiskt. Kontextcache är automatisk, utan cache-ID och utan TTL att hantera. Du skickar ett stort prefix, håller det byte-för-byte identiskt i senare förfrågningar, och den upprepade delen debiteras till cache-träfffpriset i stället för cache-misspriset. För att göra skillnaden synlig använde jag en kunskapsbas på cirka 33 000 token och ställde en fråga om den.

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

Första gången jag skickade det prefixet var inget av det cache:at, och förfrågan kostade cirka 9,9 cent för ungefär 33 000 inkommande token. Efter att prefixet hade setts träffade samma förfrågan cachen på alla 32 512 prefextoken och kostade ungefär 1,1 cent, nära en niofaldig minskning. Anledningen är prisskillnaden: cache:ad indata kostar 0,30 $ per miljon token jämfört med 3,00 $ för icke-cache:ad. En egenhet jag stötte på är att cache-skrivningar är asynkrona, så träffen syns inte på ett omedelbart rygg-mot-rygg-anrop. Den landar på en senare förfrågan, så att köra skriptet två gånger med en minuts mellanrum visar först miss och sedan träff.

Cache-miss jämfört med cache-träffkostnad. Bild: författaren.

Exempel 5: Hitta layoutbuggar i en skärmdump

Vision är inbyggt i K3, och API:t är ett rent sätt att använda det, även om det inte tar en offentlig bild-URL. Du skickar bilden som en base64-data-URL och gör meddelandets content till en array av objekt, en del för bilden och en för texten. Jag renderade en liten instrumentpanel med några avsiktliga layoutbuggar, sparade en skärmdump och bad K3 säga vad som var fel.

Instrumentpanelen med avsiktliga layoutbuggar. Bild: författaren.

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 läste bilden väl. Den upptäckte kortet som ligger lägre än raden och överlappar sin granne, emblemet som ligger ovanpå en siffra (den misstolkade till och med den täckta 3 910 som 5 910, vilket är felet som bevisar sig självt), den ojämna glipan före det sista kortet, stapeln som blöder upp i kortet ovanför, och verktygstipset som ligger över staplarna, och den gav en kort CSS-fix för varje, som att flytta korten in i ett gemensamt rutnät. Däremot hoppade den över den nästan osynliga lågkontrast-underrubriken, så vision fångar det som sticker ut för ögat mer än svag detalj. Anropet kostade cirka två cent.

Begränsningar i Kimi K3

API-exemplen gick bra, men några skavanker är värda att nämna så att du inte blir överraskad. Jag stötte på de flesta av dessa själv.

• Endast reasoning_effort="max" finns tillgängligt just nu, så du kan inte dra ner tänkandet för att spara pengar ännu.

• Samplinginställningarna är låsta. Värden som temperature, top_p och straffen är låsta, så utelämna dem i begäranden i stället för att finjustera dem.

• Utdata kan bli långa och dyra. Begränsa max_completion_tokens, som i exemplen, och validera alla agentloopar.

• Offentliga bild-URL:er stöds inte via API:t, så planera för base64 eller uppladdade filer för vision där.

Inget av detta är avgörande hinder, men det påverkar hur du använder modellen. Utdatakostnaden är den jag skulle hålla mest koll på.

Slutsats

I mina körningar stack två saker ut. Verktygsanropen och den strukturerade utdatan krävde inga omförsök, och cache hade större betydelse än jag väntat mig, eftersom återanvändning av samma långa prefix gjorde en stor begäran billig att skicka igen. Så för analys i arkivskala, upprepade långkontext-anrop eller multimodal ingenjörskonst är K3 ett rimligt standardval; för snabb, billig chatt eller exakt styrning av sampling är en mindre modell det enklare valet. Detaljerna om öppna vikter och licens, som jag nämnde tidigare, bör vara tydligare efter lanseringen den 27 juli.

För mer bakgrund om mönstren som dessa exempel använder täcker vår kurs Utveckla AI-system med OpenAI API funktionsanrop och att koppla modeller till externa verktyg i Python.