Kimi K3 vs K2: что изменилось и стоит ли переходить

Как только вышел Kimi K3 от Moonshot, у большинства команд, уже работающих на K2 / K2.x, возникла одна и та же первая реакция: стоит ли переходить? Ответ — не «обновляться вслепую», а зависит от того, задействует ли ваш сценарий новые возможности K3 и потянете ли вы его более высокую цену вывода. Ниже мы раскладываем оба поколения по полочкам, а затем даём вердикт по каждому сценарию.

Оба поколения в одной таблице

Параметр	Kimi K2 / K2.x	Kimi K3
Окно контекста	256K токенов	1M (1 048 576) токенов
Зрение	Нет / внешнее	Нативное зрение (изображения + видео)
Рассуждения	K2-thinking как отдельная модель	Постоянные рассуждения, управляются через reasoning_effort
Архитектура	MoE, ~1T параметров	MoE 2.8T, 896 экспертов, активируется 16
Внимание	Стандартное MoE-внимание	KDA + Attention Residuals
Эффективность масштабирования	Базовый уровень	~2.5× относительно K2
Цена вывода (офиц. ориентир)	~¥8–16 / 1M	¥100 / 1M

В чём K3 действительно сильнее

Контекст вырос с 256K до 1M. Это самое наглядное обновление. Целая кодовая база среднего размера, полный длинный договор, десятки страниц PDF теперь помещаются в один запрос — больше не нужно мучительно нарезать данные и строить RAG. Разница особенно заметна для долгоживущих агентов, которые выполняют длинные цепочки вызовов инструментов и держат глубокую историю.

Нативное зрение становится полноправным гражданином. В эпоху K2 «увидеть» изображение означало по сути внешний OCR или вызов отдельной визуальной модели; K3 напрямую принимает изображения и видео, поэтому задачи вроде «свёрстать фронтенд по макету» или «поправить код по скриншоту игры / CAD» поддерживаются нативно. Учтите, что визуальный ввод должен идти массивом объектов через base64 или ссылку на файл ms:// — публичные URL изображений не поддерживаются.

Рассуждения включены по умолчанию. В K2 для глубокого мышления нужно было переключаться на специальную модель вроде kimi-k2-thinking; K3 встраивает рассуждения в основную модель и регулирует интенсивность через reasoning_effort (сейчас только max), так что сложные рассуждения и многошаговое планирование работают из коробки.

Эффективность новой архитектуры. MoE на 2.8T в паре с KDA (Kimi Delta Attention) + Attention Residuals даёт, по данным Moonshot, примерно 2.5× общей эффективности масштабирования относительно K2 — иначе говоря, тот же вычислительный бюджет тренирует / обслуживает выгоднее, и именно это даёт запас, чтобы поднять контекст до 1M.

Цена: вывод заметно дороже

K3 позиционируется как флагман, и цена у него флагманская. В официальном ориентировочном прайсе вывод доходит до ¥100 / 1M, а ввод — ¥20 при промахе кэша и ¥2 при попадании. На фоне вывода серии K2 за считаные юани разрыв в стоимости велик для чисто объёмных сценариев. Плюс в том, что K3 включает кэш контекста по умолчанию, поэтому длинные system prompt и фиксированные документы при повторных вызовах сжимают ввод до одной десятой — а значит долгоживущие агенты только выигрывают. Цены постоянно колеблются, поэтому перед заказом проверяйте актуальную ставку — цену в реальном времени по всей линейке Kimi на GetModel смотрите на странице цен.

Вердикт по сценариям: что выбрать

Оставайтесь на K2 / K2.x, если:

• Чисто объёмные, высококонкурентные общие задачи (классификация, извлечение, рерайт, поддержка), где предельный потолок возможностей не критичен — цена единицы у K2 куда ниже;
• Контекст редко превышает 256K, и зрение не нужно;
• Стоимость — жёсткое ограничение.

Переходите на K3, если:

• Нужно проглотить целую кодовую базу / сверхдлинный документ за раз, и 256K уже впритык;
• Есть потребности в коде по изображению / мультимодальности (фронтенд, игры, CAD, воспроизведение макетов);
• Вы запускаете долгоживущих агентов, которым нужны сильные рассуждения и стабильность на глубокой истории;
• Промпты сильно повторяются, так что скидки за кэш срабатывают и размывают флагманскую цену.

Прагматичный компромисс: держите один агрегирующий шлюз с подключёнными сразу K2 и K3 — дешёвые задачи на K2, сложные на K3, а переключение в коде — сменой лишь поля model. С агрегирующим интерфейсом вроде GetModel один ключ позволяет свободно распределять нагрузку между двумя поколениями, а заодно сравнить с GPT и Claude.

Ключевое при миграции (K2 → K3)

Если всё же обновляетесь, обойдите в коде три подводных камня:

• Уберите параметр thinking — K3 вместо него использует reasoning_effort (сейчас только max);
• Для многоходовых диалогов / вызовов инструментов возвращайте полное assistant message как есть — не оставляйте только content;
• Бюджет контекста вырос в 4 раза, но не заполняйте его вслепую — чем длиннее, тем дороже и медленнее.

Полный код интеграции, примеры curl / Python и разбор ошибок — в руководстве по подключению Kimi K3 API. Чтобы использовать K2, K3 и модели других вендоров из одной кодовой базы, проще всего начать с получения ключа в консоли GetModel.