Kimi K3: возможности, бенчмарки, API и 5 практических примеров

Гонка открытых моделей сделала новый виток 16 июля 2026 года, когда Moonshot AI выпустила Kimi K3 — модель с 2,8 трлн параметров, контекстным окном на 1 млн токенов и встроенным зрением. Это самая крупная открытая модель Moonshot, значительно превосходящая по размеру Kimi K2, и первая, которую они относят к классу моделей с 3 трлн параметрами.

Если вам нужна история запуска, разбор архитектуры, графики бенчмарков, сравнения с Claude, GPT и другими китайскими лабораториями, а также список ограничений от Moonshot, наш блог‑пост о Kimi K3 охватывает всё это. Это руководство — практическая сторона: как получить доступ и как модель ведёт себя в работе. Я пройду через пять небольших примеров, четыре — через API, где покажу фактический расход токенов и стоимость, и два — в веб‑приложении kimi.com. Вместе они показывают, как K3 справляется с:

• Вызовом инструментов и возвратом строгого JSON
• Динамической загрузкой определения инструмента
• Снижением стоимости длинного контекста за счёт автоматического кеширования
• Чтением скриншота и исправлением вёрстки
• Построением интерактивной панели из одного промпта

Четыре примера с API запускались 17 июля 2026 года на модели kimi-k3 и стоили около 11 центов при «холодном» запуске — или пару центов после срабатывания кеша.

Как получить доступ к Kimi K3

Самый быстрый способ попробовать модель — kimi.com — веб‑приложение и мобильные приложения запускают Kimi K3 для общих агентных задач без какой‑либо настройки.

Для более тяжёлых задач, таких как отчёты и дашборды, есть Kimi Work — настольное приложение.

Если вы живёте в терминале, Kimi Code — это кодовый агент, который устанавливается из npm как @moonshot-ai/kimi-code; модель там выбирается командой /model. Для использования K3 в Kimi Code требуется платная подписка, а полное окно в 1 млн токенов — более высокий тариф.

Это руководство сосредоточено на «сыром» API и веб‑приложении, но терминальный агент доступен, если он вам удобен.

Однако K3 не заменяет своих «собратьев». В таблице ниже показано, как распределяется текущая линейка.

Коротко говоря, K3 — это модель по умолчанию, когда задача сочетает код, инструменты, документы и изображения или когда действительно нужно окно на 1 млн токенов. Для чистой генерации кода, где важнее скорость, чем контекст, kimi-k2.7-code по‑прежнему более разумный выбор, так что не предполагайте, что новая модель всегда лучшая.

Настройка API Kimi K3

API совместим с SDK OpenAI, так что если вы уже работали с ним, почти ничего нового. Вам нужен Python 3.9 или новее и API‑ключ.

Шаг 1. Генерация API‑ключа

Сначала войдите в платформу Kimi и откройте в консоли страницу API Keys. Создайте ключ, один раз скопируйте его и сохраните в безопасном месте — повторно он не отображается. Для совершения вызовов на счёте также должен быть небольшой баланс — для всего этого руководства достаточно пары долларов.

Создание API‑ключа Kimi K3. Изображение автора.

Шаг 2. Установка SDK

Далее установите SDK OpenAI в своё окружение. Достаточно одной команды.

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

Это подтянет клиентскую библиотеку, которую используют остальные примеры; ничего специфичного для Kimi устанавливать не нужно.

Шаг 3. Хранение ключа и инициализация клиента

Лучше читать ключ из переменной окружения, чем вставлять его в код. Установите MOONSHOT_API_KEY в вашей оболочке или в файле .env и укажите для клиента базовый URL Moonshot.

import os
from openai import OpenAI

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

От стандартной настройки OpenAI отличаются только две вещи: base_url и имя модели — kimi-k3. С этим вы готовы делать вызовы.

Шаг 4. Первый вызов

Теперь первый запрос. Я попросил модель представить себя в одном предложении, и вышел честный маленький момент.

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)

Ответом был вежливый отказ гадать: модель сказала, что у неё нет достоверной информации о Kimi K3, так как она обучена до собственного релиза, и предложила обратиться к анонсам Moonshot. Полезное напоминание о том, что модель не знает о себе. Такой вызов API стоит примерно семь десятых цента. Обратите внимание на ограничение max_completion_tokens, которое я выставляю во всех примерах, чтобы сдержать болтливый вывод и не разогнать счёт.

Первый вывод API‑вызова Kimi K3. Изображение автора.

Пример 1. Потоковое рассуждение и финальный ответ

K3 всегда рассуждает, и API возвращает ход рассуждений по отдельному каналу от ответа. При потоковой передаче каждый фрагмент может содержать reasoning_content, финальный content или оба сразу, так что вы можете выводить «мышление» и ответ раздельно.

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)

Модель сначала «вслух» показала ход работы: узнала классическую задачу Cognitive Reflection Test, отметила интуитивно неверный ответ $0.10, затем провела алгебру до $0.05 за мяч и проверила, что $1.05 плюс $0.05 дают $1.10. Полезен именно разнос: в реальном приложении вы показываете пользователям content, а reasoning_content оставляете для логов, поскольку «сырые» рассуждения в продукте редко уместны. Этот вызов израсходовал 488 выходных токенов и стоил меньше цента.

Сначала рассуждения, затем финальный ответ. Изображение автора.

Пример 2. Вызов инструментов со структурированным выводом

Kimi K3 — модель в линейке, поддерживающая tool_choice="required", что принудительно выполняет как минимум один вызов инструмента за ход. Это полезно, когда нужно, чтобы модель получала данные перед ответом, а не угадывала. Здесь я дал ей два фиктивных инструмента — поиск цены и проверку наличия — принудил вызов инструмента, локально выполнил инструменты и затем запросил результат в строгом JSON через 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)})

Модель вызвала оба инструмента с верным кодом товара, затем вернула чистое резюме заказа в JSON: пять механических клавиатур по $89 каждая, итог $445 и флаг наличия true. Два момента важны на практике. Нужно добавить в историю полный ответ ассистента перед тем, как добавлять результаты инструментов, и разбирать JSON только из поля content, никогда — из поля рассуждений. Пара вызовов в сумме стоила меньше цента.

Вызовы инструментов и структурированный JSON‑вывод. Изображение автора.

Пример 3. Динамическая загрузка инструментов

Если у вас десятки инструментов, отправка их определений в каждом запросе тратит токены и захламляет промпт. Kimi K3 позволяет ввести определение инструмента в середине диалога сообщением system с полем tools и без content. Инструмент становится доступен с этого момента, что удерживает крупные каталоги инструментов вне кешируемого префикса, пока инструмент действительно не понадобится.

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 подхватила только что загруженный инструмент и вызвала convert_currency со значениями amount = 100 и rate = 0.92 — ровно как задумано. Важно помнить, что сервер не хранит для вас это определение, поэтому, если инструмент должен оставаться доступным, вы повторно отправляете системное сообщение в последующих запросах. Это был самый дешёвый вызов — около двух десятых цента.

Вызов динамически загруженного инструмента конвертации валют. Изображение автора.

Пример 4. Снижение стоимости длинного контекста с кешированием

Тут окно на 1 млн токенов становится практичным. Кеширование контекста работает автоматически: не нужно управлять ID кеша и TTL. Вы отправляете большой префикс, сохраняете его побайтно идентичным в последующих запросах, и повторяющаяся часть тарифицируется по ставке cache‑hit вместо cache‑miss. Чтобы разница была заметнее, я использовал базу знаний примерно на 33 000 токенов и задал вопрос по ней.

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

В первый раз этот префикс не был в кеше, и запрос стоил около 9,9 цента за ~33 000 входных токенов. После того как префикс «увидели», тот же запрос попал в кеш по всем 32 512 токенам префикса и стоил примерно 1,1 цента — падение почти в девять раз. Причина — разница в цене: кешированный ввод стоит $0.30 за миллион токенов против $3.00 за некешированный. Особенность, с которой я столкнулся: запись в кеш асинхронная, поэтому попадание в кеш не видно при мгновенном повторном вызове; оно появляется в следующем запросе, так что запуск скрипта дважды с паузой в минуту показывает сначала промах, затем попадание.

Стоимость при промахе и попадании в кеш. Изображение автора.

Пример 5. Поиск проблем вёрстки на скриншоте

Зрение встроено в K3, и через API им удобно пользоваться, хотя он не принимает публичные URL изображений. Вы отправляете изображение как data URL в base64 и делаете content сообщения массивом объектов — одна часть для изображения и одна для текста. Я срендерил небольшой дашборд с несколькими умышленными багами вёрстки, сохранил скриншот и спросил у K3, что не так.

Дашборд с преднамеренными багами вёрстки. Изображение автора.

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 хорошо прочитала изображение. Она заметила карточку, которая расположена ниже строки и наезжает на соседнюю, бейдж, «припаркованный» поверх числа (она даже прочла закрытые 3 910 как 5 910 — баг, который выдал сам себя), неровный зазор перед последней карточкой, столбик, «кровоточащий» вверх в карточку, и тултип, перекрывающий столбики, и дала краткое CSS‑исправление для каждого — например, объединить карточки в одну сетку. Однако она пропустила почти невидимый низкоконтрастный подзаголовок, так что зрение лучше ловит то, что бросается в глаза, чем блеклые детали. Вызов стоил около двух центов.

Ограничения Kimi K3

Примеры с API прошли хорошо, но есть несколько шероховатостей, о которых стоит знать, чтобы не удивляться. С большинством из них я столкнулся напрямую.

• Пока доступно только reasoning_effort="max", так что «урезать» размышления ради экономии пока нельзя.

• Настройки сэмплирования фиксированы. Параметры вроде temperature, top_p и штрафы — заблокированы, поэтому их следует опускать в запросах вместо настройки.

• Вывод может быть длинным и дорогим. Ограничивайте max_completion_tokens, как в примерах, и валидируйте любые агентные циклы.

• Публичные URL изображений в API не поддерживаются, поэтому для зрения используйте base64 или загруженные файлы.

Ничего критичного, но это влияет на подход к использованию модели. Больше всего я бы следил за стоимостью вывода.

Заключение

В моих запусках выделились две вещи. Вызов инструментов и структурированный вывод не требовали повторов, а кеширование оказалось важнее, чем я ожидал: повторное использование длинного префикса делало большой запрос дешёвым при повторной отправке. Поэтому для анализа уровня репозитория, повторяющихся вызовов с длинным контекстом или мультимодальной инженерии K3 — разумный вариант по умолчанию; для быстрого недорогого чата или точной настройки сэмплирования проще взять меньшую модель. Детали об открытых весах и лицензии, на которые я ранее указывал, должны проясниться после релиза 27 июля.

Больше о паттернах из этих примеров — в нашем курсе Developing AI Systems with the OpenAI API, который охватывает вызов функций и подключение моделей к внешним инструментам на Python.