Kimi K3 для QA: что даёт новый флагман Moonshot и во сколько это обойдётся

16 июля Moonshot AI выкатил Kimi K3 — модель на 2.8 триллиона параметров с контекстом в миллион токенов и нативной мультимодальностью. Я несколько дней гонял её на своих QA-задачах: разбор упавших прогонов, генерация автотестов, анализ скриншотов с фермы. Пост про то, где K3 реально экономит время, где просто жрёт деньги, и почему локальные модели из прошлых постов никуда не деваются.

Сначала честное признание. После двух постов про локальные LLM для QA и выбор модели под своё железо писать обзор облачного флагмана за $15 за миллион выходных токенов — немного противоречиво. Но жизнь устроена сложнее, чем «локалка vs облако». Есть задачи, которые Qwen 3.5 9B на моём MacBook просто не тянет: лог прогона на 200 тысяч токенов, скриншот с видео, репозиторий целиком. Именно в эту нишу и целится K3. Разбираю по порядку: что выпустили, что заявляют, что я проверил руками и как это встроить в работу, не разорившись.

Что вообще выпустил Moonshot

Kimi K3 — это флагман нового поколения, а не очередная точечная доработка линейки K2. Скачок по параметрам почти трёхкратный: 2.8 триллиона против триллиона у K2.6 и K2.7 Code. Архитектура — mixture-of-experts: 896 экспертов, из которых на каждый токен активируются всего 16, то есть меньше двух процентов сети. Это стандартный трюк для экономии вычислений, но масштаб всё равно впечатляет: полные веса модели займут под квантизацию MXFP4 больше места, чем есть на любом потребительском железе. Забудьте про «подниму дома» — селф-хост этой модели это история про кластер из десятков ускорителей, хотя веса Moonshot обещает выложить до 27 июля.

Два архитектурных новшества, которые Moonshot называет главными: Kimi Delta Attention — гибридная линейная схема внимания, и Attention Residuals, меняющие то, как информация движется между слоями. По заявлению компании, это дало примерно 2.5-кратный рост эффективности масштабирования относительно K2. Проверить это независимо пока нельзя, но косвенное подтверждение есть: контекст вырос до миллиона токенов без пропорционального роста цены. Линейное внимание как раз про то, чтобы длинный контекст не стоил квадратично.

Главные цифры для практика:

Контекст: 1 048 576 токенов на вход, до 131 072 на выход (при желании выход можно поднять до миллиона). Это вчетверо больше, чем у K2.6/K2.7 с их 256K, и примерно 1600 страниц текста.
Модальности: на вход текст, изображения и видео. На выход — только текст. Для нас это значит: скриншоты из Appium Inspector, записи упавших прогонов, схемы экранов из Figma — всё можно скармливать напрямую.
Thinking: всегда включён, выключить нельзя. Параметр reasoning_effort пока принимает только значение max, другие уровни Moonshot обещает позже. Мыслительные токены тарифицируются как выходные — об этом ниже, потому что это больно.
API: OpenAI-совместимый, работает через platform.kimi.ai и OpenRouter. Есть официальные интеграции с Claude Code, Codex, Cline, RooCode, OpenCode, OpenClaw, Hermes Agent и собственным CLI Kimi Code.

Зачем практику вообще знать про устройство модели? Затем, что из архитектуры напрямую следуют два рабочих свойства. Первое: линейное внимание делает стоимость обработки контекста почти линейной от длины. Классический трансформер на миллионе токенов уперся бы в квадратичную стоимость — и миллионный контекст остался бы маркетинговой цифрой, которую никто не может себе позволить. Здесь же плоская тарификация на любой длине плюс автокэш говорят, что длинный контекст у K3 — это рабочий режим, а не демо. Второе: mixture-of-experts объясняет, почему модель с 2.8 триллиона параметров вообще отвечает за разумное время — на каждый токен считается малая часть сети. Плата за это — размер весов целиком. Даже в квантизации MXFP4 самостоятельный хостинг это кластер с сотнями гигабайт видеопамяти и инженер, который умеет готовить expert parallelism. Когда веса выложат, для 99 процентов команд это будет не «поднимем у себя», а «появится у провайдеров инференса и подешевеет».

Отдельно отмечу запуск, потому что он показательный. Сначала утёкла промо-страница и селекторы модели в приложении, потом безмолвный тизер в X, потом Financial Times написала про раунд инвестиций с оценкой $31.5 млрд — и только потом, 16 июля, открылись доки и API. Технического блога и карточки модели на Hugging Face в день релиза не было. API выкатили раньше, чем paper trail. Пахнет спешкой под новостной цикл по фандрайзингу, и это стоит держать в голове, когда читаешь вендорские бенчмарки.

Что заявляет Moonshot — и почему я верю этому наполовину

Бенчмарковая таблица у K3 неприлично широкая: работа в крупных репозиториях, работа в терминале, восстановление программ по бинарному поведению, многочасовые инженерные задачи, пост-тренировка моделей, веб-ресерч, офисные задачи. Основные числа: DeepSWE 67.5, Terminal-Bench 2.1 — 88.3 (для сравнения, GPT-5.6 Sol — 88.8), ProgramBench — 77.8 процента raw pass rate, FrontierSWE — 81.2 доминирования, SWE Marathon — 42.0, BrowseComp — рекордные 91.2 процента.

Звучит как «убийца всего». Теперь почему я отношусь к этому с осторожностью — и это, кстати, чисто QA-шная история.

Модель никогда не работает сама по себе. Она работает внутри обвязки: агент решает, какой контекст ей показать, какие команды разрешить, как возвращать ошибки инструментов, когда обрезать историю, сколько попыток дать и когда остановиться. В таблице Moonshot результаты собраны в разных обвязках: где-то Kimi Code, где-то Claude Code, где-то Codex, где-то mini-SWE-agent. DeepSWE в их исполнении — 67.5 в Kimi Code и 67.3 в mini-SWE-agent, и второе число честнее, потому что сравнивает модели в одинаковых условиях. ProgramBench — это вообще raw pass rate по 248 тысячам поведенческих проверок, а не процент полностью решённых задач; полностью программы восстанавливают единицы моделей. FrontierSWE — результат, пересчитанный самим вендором, на публичном лидерборде K3 на момент написания поста вообще нет.

Мы же этим каждый день занимаемся: тест зелёный — а что он на самом деле проверял? Здесь то же самое. Бенчмарк, запущенный вендором в собственной обвязке с максимальными настройками мышления, — это не независимая проверка. Это демка. Демка впечатляющая, но демка.

Что из независимого уже есть. Frontend Code Arena поставила K3 на первое место с 1679 очками, выше Claude Fable 5 — и это слепые голосования разработчиков, скачок с 18-го места, которое занимал K2.6. BenchLM ставит модель четвёртой из двухсот по совокупности, с оговоркой, что покрыто только 54 бенчмарка из 320. Artificial Analysis подтверждает уровень «рядом с фронтиром», но фиксирует и обратную сторону: много выходных токенов, скорость ниже медианы, премиальная цена. Картина складывается такая: модель реально сильная, но «лучшая во всём» — пока маркетинг, а не факт.

Как я проверял: набор задач и правила игры

Чтобы это не был пересказ чужих таблиц, опишу, на чём гонял модель сам. Принцип тот же, что в обзоре локальных моделей: никаких синтетических «напиши змейку», только задачи из реальной работы.

Набор был такой:

Триаж упавшего регресса — полный лог ночного прогона с заранее известным мне раскладом падений. Проверяю, сколько модель найдёт, сколько пропустит и сколько выдумает.
Генерация Page Object по скриншоту и XML-дампу реального экрана из нашего мобильного приложения.
Автотест с нуля на pytest + Appium по текстовому описанию сценария.
Tool calling — связка с моим MCP для TestOps: выгрузка тест-кейсов, создание сущностей, многошаговые цепочки.
Веб-ресёрч — восстановление истории изменений цен нескольких AI-сервисов по первоисточникам.

По каждой задаче фиксировал три вещи: качество результата (пришлось ли переписывать руками), стоимость запроса в токенах и время ожидания. Параллельно те же задачи прогонял через K2.7 Code — чтобы понимать, за что именно я доплачиваю втридорога. Ну и через локальную Qwen 3.5 9B там, где это было осмысленно, — как референс «бесплатно и приватно».

Кто ещё на этом ринге

Чтобы было с чем сравнивать, коротко про альтернативы на июль 2026 — только по QA-значимым параметрам.

Claude Fable 5. Главный конкурент по качеству рассуждений: на SWE-bench Verified у неё 95 процентов, и независимые трекеры долгих задач ставят её выше K3. В Terminal-Bench проигрывает K3 по заявленным цифрам (84.6 против 88.3), но её собственные бенчи тоже ждут независимой проверки. Дороже K3, контекст меньше. Если задача — глубокий дебаг одной сложной проблемы, Fable 5 остаётся эталоном.

GPT-5.5 / GPT-5.6 Sol. На Terminal-Bench 2.1 у Sol 88.8 — единственный, кто выше K3 в таблице Moonshot. По ощущениям обзорщиков, Sol быстрее в веб-ресёрче, но поверхностнее: проверяет меньше источников. Вход/выход — $5/$30, то есть заметно дороже K3 при сопоставимом классе задач.

DeepSeek V4 Pro. Чемпион по цене среди открытых: $1.74/$3.48, кэш-вход дешевле кимовского. Контекст 128K — после миллиона токенов ощущается тесно. Если ваши задачи влезают в 128K и не требуют зрения, DeepSeek остаётся разумной экономией.

K2.7 Code. Свой же младший брат, и для объёмной кодогенерации — лучший в семействе по цене результата. Moonshot его не убивает, и правильно делает: связка «K2.7 Code для рутины + K3 для сложного» выглядит осознанной стратегией вендора, а не случайностью.

Локальные модели. Без изменений из прошлых постов: приватность, нулевая цена запроса, работа без интернета. K3 на эту нишу не претендует — он о другом.

Экономика: считаем деньги, потому что они тут главное

Линейка Kimi всегда брала ценой. K2 на старте стоил $0.60 за миллион входных токенов. K3 ломает традицию: $3 за миллион входных при промахе кэша, $15 за миллион выходных. Это в 3-4 раза дороже K2.7 Code ($0.95/$4) и примерно вдвое дешевле закрытого фронтира: Claude Opus 4.8 стоит $5/$25, GPT-5.5 — $5/$30.

Но есть нюанс, который меняет всё, — автоматический кэш контекста. Если у вас стабильный длинный префикс (системный промпт, описание проекта, документация, конвенции кода), повторные запросы читают его по $0.30 за миллион вместо $3. Скидка 90%, и никаких cache ID и TTL настраивать не надо — платформа сама пытается попасть в кэш. По телеметрии OpenRouter за первые дни после релиза у K3 77.7 процента кэш-попаданий, и средневзвешенная цена входа вышла около $0.90 за миллион — втрое ниже прайса. Это превращает контекст в миллион токенов из демо-фичи в рабочий инструмент: загрузил корпус один раз, дальше долби его за десятую часть цены.

Вторая сторона медали — скорость и болтливость. Thinking всегда на максимуме, и это ощущается: по ранней телеметрии OpenRouter модель выдаёт около 28 токенов в секунду с четырьмя секундами до первого токена. Artificial Analysis фиксирует ещё и повышенный расход выходных токенов — модель думает долго и пишет много, а мысли тарифицируются по $15 за миллион. Для интерактивного цикла «поправил-запустил-поправил» это больно и по времени, и по деньгам. Для таких задач у Moonshot есть kimi-k2.7-code-highspeed: 180-260 токенов в секунду за $1.90/$8. K3 — это про глубину одного вызова, а не про количество вызовов в минуту.

Чтобы было от чего оттолкнуться, посчитаю свой типичный сценарий — разбор ночного регресса. Вход: стабильный префикс с описанием проекта примерно 40 тысяч токенов (после первого запроса он в кэше) плюс лог прогона на 200 тысяч токенов. Выход: разбор на 3-4 тысячи токенов плюс мышление, которое у K3 щедрое, — заложим ещё 10 тысяч reasoning-токенов. Итого один разбор: 240 тысяч входа, из которых 40 тысяч по $0.30 и 200 тысяч по $3, плюс 14 тысяч выхода по $15. Получается примерно $0.01 + $0.60 + $0.21 — около восьмидесяти центов за разбор. Двадцать рабочих дней — порядка $16 в месяц. Сопоставимо с парой часов инженерного времени, которые это экономит ежедневно. А вот если тот же запрос гонять на каждый пуш десять раз в день — уже $160-170 в месяц, и тут начинаются вопросы. Отсюда и правило: K3 на расписании и по эскалации, дешёвый классификатор впереди на каждый прогон.

Мой рабочий вывод по деньгам такой: K3 нельзя делать дефолтной моделью для всего. Это эскалация. Дешёвая модель делает рутину и классификацию, K3 получает двадцать процентов задач, где реально нужны мозги и длинный контекст. Классическая tiered-архитектура, и она отлично ложится на QA-процессы — покажу ниже.

Что это даёт QA: четыре сценария, где K3 действительно силён

1. Разбор падений на полном логе, а не на выжимке

Все, кто писал LLM-разборщики упавших тестов, знают боль: лог прогона на несколько тысяч строк не влезает в контекст. Приходится резать: грепать ERROR, отрезать стектрейсы, скармливать только окрестности падения. А потом удивляться, что модель не видит причину — потому что причина была в другом тесте, который три минуты назад оставил после себя грязное состояние, и мы его как раз вырезали.

С миллионом токенов эта проблема уходит. Мой типичный ночной регресс — это pytest-лог на 150-250 тысяч токенов плюс Appium server log плюс Allure-результаты по упавшим. Раньше я городил двухступенчатую схему: локальная модель фильтрует шум, облачная анализирует выжимку. Теперь можно скормить всё целиком одним запросом и задать вопрос: «какие из этих семи падений — продуктовые баги, какие — проблемы тестов, какие — окружение?» Это ровно та задача, где контекст решает, потому что корреляции между падениями видны только на полной картине.

Причём экономика с кэшем тут играет за нас: стабильный префикс (описание стенда, архитектуры тестового фреймворка, известных проблем) сидит в кэше за $0.30 за миллион, а сверху каждый раз докидывается только свежий лог.

2. Скриншоты и видео: наконец-то нормальный анализ UI

Нативная мультимодальность — второе, ради чего я вообще полез тестировать K3. У меня на ферме из двух Mac mini каждый падший тест оставляет скриншот и видеозапись. До этого я смотрел их глазами, потому что локальные vision-модели на сложных экранах мобильного приложения путаются безнадёжно.

Что умеет K3 на практике: по скриншоту экрана описать иерархию элементов и предложить локаторы, найти визуальное расхождение между макетом и вёрсткой, объяснить по кадру из видео, что приложение делало за секунду до падения. Для мобильной автоматизации это прямо в тему: половина моих падений — это «элемент не найден», и вопрос всегда один — элемент реально пропал или просто переехал/переименовался/попал под модалку. Модель, которая видит экран, отвечает на него заметно лучше модели, которая читает только XML-дамп.

Видео я пока тестировал осторожно: короткие ролики до минуты модель жуёт уверенно, на длинных записях прогонов я бы не закладывался. Но для «что произошло в эти 30 секунд» — работает.

3. Генерация и рефакторинг автотестов

Здесь у меня смешанные впечатления, и они совпадают с тем, что пишут независимые обзорщики: на сложных задачах K3 сильнее K2.7 Code, на рутинных — разницы почти нет, а счёт больше в разы.

Сложная задача из моей практики: длинный экран оформления заказа, который нужно было разбить на Page Object с атомарными переиспользуемыми методами. Я скормил K3 скриншот, XML-дамп и существующие page-объекты проекта как референс стиля. Модель не просто нагенерила класс — она сама предложила разбить экран на компоненты (секция адреса, секция оплаты, секция товара) и вынести повторяющиеся ожидания в базовые методы. K2.7 Code в аналогичной задаче писал плоский класс-простыню, который я потом рубил руками.

Рутинная задача: добавить десять типовых тестов на API по готовому шаблону. Тут K2.7 Code справляется так же хорошо, а стоит вчетверо дешевле и работает в разы быстрее. Вывод банальный, но его почему-то все игнорируют в первые дни после релиза: не надо гонять флагман на задачи, которые делает модель вчетверо дешевле.

И да, локаторы приходится править. Модель любит генерить XPath, хотя в нашем проекте приоритет — accessibility id, потом id, и только потом XPath. Лечится примерами в промпте, но не до конца.

4. MCP-интеграции и длинные агентные цепочки

K3 заточен под tool calling: function calling, строгий tool_choice (можно заставить модель обязательно вызвать инструмент на шаге, а не фантазировать), и новая фича — динамическая загрузка инструментов. Суть: вместо того чтобы пихать восемьдесят схем инструментов в каждый запрос, оркестратор подгружает описания инструментов прямо в середину диалога, когда они понадобились. Для агента с большим MCP-арсеналом (у меня это TestOps, Jira, Confluence, мой блог, codegraph) это экономия контекста и меньше путаницы в выборе инструмента.

Два технических грабля, о которые я ударился сразу, делюсь. Первое: в многошаговых цепочках вызовов нужно возвращать в контекст поле reasoning_content из ответа ассистента целиком. Если его обрезать (а многие прокси и самописные клиенты обрезают), tool calling начинает деградировать — модель теряет нить рассуждения между вызовами. Второе: встроенный web_search у Moonshot сейчас «в процессе обновления» и в доке прямо написано — не для продакшена. Если агенту нужен поиск, привозите свой инструмент.

Мои эксперименты: что получилось, что нет

Теперь конкретика без маркетинга. Четыре прогона на реальных задачах.

Эксперимент 1: триаж ночного регресса. Скормил лог прогона примерно на 180 тысяч токенов: семь падений, из которых я заранее знал расклад — два продуктовых бага, три проблемы тестов, одно окружение, один известный flaky. K3 разложил правильно шесть из семи, flaky опознал и даже указал на probable cause (гонка за shared-состоянием между воркерами xdist, что соответствовало действительности). Седьмым «нашёл» баг, которого не было — уверенно, со стектрейсом и объяснением. False positive на тридцать минут моей жизни. Урок старый как мир: вердикты модели — это повод посмотреть руками, а не истина. Формат «модель ставит диагноз, человек подтверждает» никто не отменял.

Эксперимент 2: POM со скриншота. Уже описанный выше кейс с экраном оформления заказа. Результат: рабочий каркас за один запрос, ручная доработка — локаторы и пара методов под нашу базовую обвязку ожиданий. Экономия против написания с нуля — примерно час. Не «за пять минут сгенерил всё», как в демках, но честный час жизни.

Эксперимент 3: автотест на pytest + Appium с нуля. По текстовому описанию сценария модель сгенерила тест, который запустился с первого раза. Но: нежные места стандартные — не хватило явных ожиданий, пара кликов по координатам вместо локаторов, setUp без очистки состояния. Мобильная автоматизация остаётся областью, где модель знает «как обычно делают», а не «как делаем мы». Примеры наших тестов в системном промпте снимают процентов семьдесят проблем, но не все.

Эксперимент 4: веб-ресерч. Попросил восстановить историю изменений цен нескольких AI-сервисов по первоисточникам со ссылками. Здесь K3, пожалуй, сильнее всего: длинная цепочка поисков, перекрёстная проверка противоречий, итог с источниками. Рекордный BrowseComp ощущается заслуженным. Для QA это применимо не каждый день, но для ресёрча инструментов и сравнения подходов — отлично.

Эксперимент 5: многошаговый tool calling через MCP. Дал агенту на K3 задачу: выгрузить из TestOps тест-кейсы проекта, сопоставить их с упавшими тестами из лога и подготовить черновики баг-репортов по продуктовым падениям. Цепочка получилась на девять вызовов инструментов, и вот тут я в полной мере ощутил граблю с reasoning_content: пока мой клиент обрезал поле рассуждений, модель на четвёртом-пятом шаге начинала «забывать», зачем вообще вызвала инструмент, и переспрашивала параметры. После того как прокинул рассуждения в историю целиком, цепочка прошла от начала до конца без вмешательства. Два из трёх черновиков баг-репортов ушли в Jira почти без правок — я поправил только приоритеты. Для сравнения: K2.7 Code ту же цепочку дважды рвал на середине, теряя контекст задачи. Это, пожалуй, самая наглядная разница между «моделью для генерации кода» и «моделью для агентных сценариев».

И отдельный пункт про скорость, потому что он реально влияет на UX. 28 токенов в секунду — это когда ты наблюдаешь, как модель печатает, и успеваешь сходить за чаем на длинных ответах. Для разбора логов по расписанию — без разницы, крону всё равно. Для интерактивной работы в агенте — раздражает. Я поймал себя на том, что на простые вопросы переключаюсь обратно на быстрые модели просто чтобы не ждать. Это и есть тот самый tiered routing в действии, только не спроектированный, а выстраданный.

Промпт-паттерны, которые сработали

Несколько приёмов из этих экспериментов, которые заметно влияют на качество. Часть пересекается с моим постом про паттерны QA-агентов — здесь они же, но в привязке к K3.

Формат вердикта заранее, до данных. В запросе на разбор лога сначала описывается схема ответа: каждое падение — это категория (продукт / тест / окружение / не уверен), уверенность в процентах, ссылка на конкретные строки лога и предлагаемое действие. Без схемы модель пишет красивое эссе, из которого потом руками выковыриваешь суть. Со схемой на выходе структура, которую можно парсить и складывать в отчёт автоматически.

Просьба ссылаться на лог, а не пересказывать. Формулировка «цитируй номера строк и фрагменты, на которые опираешься» дисциплинирует модель и заодно даёт мне способ проверить вывод за секунды. Это же резко упрощает поиск галлюцинаций: ссылка на строку либо существует, либо нет.

Категория «не уверен» обязательна. Если её не дать, модель будет классифицировать всё — уверенно и красиво, включая случаи, где данных не хватает. Явное разрешение сомневаться выносит спорные падения в отдельную кучу для человека. Именно там и оказался тот false positive из эксперимента, когда я добавил эту категорию повторным запросом.

Контекст проекта в кэше, а не в каждом промпте. Конвенции по локаторам (accessibility id → id → XPath как последняя мера), структура page-объектов, список известных flaky-тестов, адреса стендов — всё это живёт в стабильном системном блоке. Модель перестаёт генерить XPath-простыни, а счёт за вход падает в десять раз.

Для скриншотов — сначала описание, потом выводы. Запрос «опиши, что видишь на экране, потом ответь на вопрос» работает заметно лучше, чем сразу «почему тест упал». Модель сначала заземляется на фактуру, и финальный ответ меньше фантазирует.

Риски и открытые вопросы

Чтобы картина была честной, перечислю то, что меня пока удерживает от более широкого внедрения.

Бенчмарки не верифицированы. Большинство громких цифр — от вендора, в его обвязке, на его настройках. Независимые лидерборды только подтягивают K3, и место модели на них может оказаться и выше, и ниже заявленного. Любые решения «переезжаем всем отделом» до независимых данных — преждевременны.

Весов пока нет. Обещание — до 27 июля, и от того, выйдут ли они и в каком виде, зависит появление модели у альтернативных провайдеров и на маркетплейсах инференса. Это может заметно изменить и цену, и доступность из РФ.

Thinking нельзя приглушить. Пока reasoning_effort принимает только max, вы платите за глубокое размышление даже там, где хватило бы поверхностного. Когда Moonshot докатит уровни пониже, экономика рутинных задач на K3 может измениться.

Дата-резидентность. Для корпоративных проектов это главный вопрос: трафик идёт к китайскому вендору. Даже с заявлением «не обучаемся на ваших данных» решение принимает ИБ, а не инженер.

Скорость и болтливость. Медленная генерация и объёмные рассуждения — это и UX-проблема, и строка в счёте. Если ваш сценарий — интерактивный агент, который должен отвечать за секунды, K3 в текущем виде не подходит по скорости.

Когда K3 не нужен

Честный список задач, где я пробовал K3 и вернулся к прежним инструментам:

Рутинная генерация по шаблону. Типовые API-тесты, чек-листы по форме, boilerplate. Qwen 3.5 9B локально или K2.7 Code в облаке делают то же самое дешевле и быстрее.
Классификация и роутинг. «Продуктовый баг или тестовый» на коротком стектрейсе — задача для дешёвой быстрой модели. Гонять туда флагмана с миллионным контекстом — как ездить на самосвале за хлебом.
Всё, что под NDA и корпоративной политикой. Запросы уходят на серверы Moonshot. Компания заявляет, что API-трафик не используется для обучения, но для многих корпоративных контекстов решает не это заявление, а политика ИБ и дата-резидентность. Проверьте у своих безопасников до того, как заливать туда логи с внутренними адресами и тестовыми кредами. Вот здесь локальные модели из моих прошлых постов остаются единственным вариантом, и K3 это никак не меняет.
Высокочастотные циклы в CI. Если разбор запускается на каждый пуш, счёт за месяц вас не обрадует. K3 — это расписание, эскалация, сложные случаи. Не конвейер.

Как подключить и что учесть

Технически всё просто, потому что API OpenAI-совместимый. Минимальная конфигурация для агента или скрипта:

BASE_URL=https://api.kimi.com/v1 (или OpenRouter — https://openrouter.ai/api/v1 с моделью moonshotai/kimi-k3), ключ с platform.kimi.ai, модель kimi-k3. Для OpenCode, Claude Code, Hermes Agent и прочих есть готовые гайды у Moonshot — по сути, прописать base_url, ключ и имя модели.

Из неочевидного, что стоит сделать сразу:

Стабильный системный префикс. Соберите описание проекта, конвенции, примеры тестов в один неизменный кусок в начале контекста и не трогайте его между запросами. Это включает кэш и режет стоимость входа в десять раз. Любое изменение префикса — промах кэша и полный прайс.
Прокидывайте reasoning_content. Если пишете свой цикл с tool calling, возвращайте поле рассуждений из ответа модели обратно в историю. Иначе многошаговые цепочки деградируют.
Бюджет на мысли. Thinking-токены считаются как выходные по $15 за миллион. На задачах «проанализируй большой лог» мыслей может быть больше, чем самого ответа. Закладывайте это в оценку стоимости прогона, а не удивляйтесь счету.
Свой поиск вместо встроенного. web_search у Moonshot сейчас не для прода — подключайте свой MCP или API поиска.

Как это выглядит в связке с CI у меня сейчас. Ночной регресс отрабатывает на ферме, утром крон-джоб забирает артефакты: pytest-лог, Appium-лог, Allure-результаты. Первым слоем идёт дешёвая модель — она классифицирует падения на «продукт / тест / окружение» и отрезает явный шум вроде известных flaky. Если всё чисто или падения тривиальны — на этом конец, отчёт уходит в канал. Если классификатор не уверен или падений много и они коррелируют — пачка уходит на K3 одним большим запросом со стабильным префиксом проекта в кэше. На выходе — разбор с вердиктами и черновики баг-репортов, которые я утром просматриваю за кофе и подтверждаю. Ключевое: человек в этой схеме не выписан наружу, он стоит на подтверждении. Модель экономит мне час-полтора в день, а не принимает решения за меня — иначе false positive из эксперимента выше превратился бы в ложный баг-репорт разработчику.

Ещё одна дата, которую стоит занести в календарь тем, кто сидит на старых моделях Moonshot: 31 августа 2026 года платформа окончательно закрывает kimi-k2.5 и всю линейку moonshot-v1. Новым пользователям их уже не дают. Если у вас в конфигах остались старые имена моделей — время мигрировать на K2.6/K2.7 Code или K3.

Шпаргалка: какая модель под какую QA-задачу

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

Разбор ночного регресса, большие логи, корреляции между падениями — K3. Контекст в миллион токенов здесь не маркетинг, а основная фича. Кэшируйте префикс проекта.
Триаж коротких стектрейсов, классификация «продукт/тест/окружение» — дешёвая модель: локальная Qwen 3.5 9B или K2.6/K2.7. K3 здесь перебор и по цене, и по скорости.
Генерация типовых автотестов по шаблону — K2.7 Code. Четверть цены K3, в разы быстрее, качество на шаблонных задачах сопоставимое.
Сложный рефакторинг тестовой архитектуры, POM для длинных экранов — K3. Разница с K2.7 Code видна именно на задачах, где надо удерживать в голове весь экран и весь проект одновременно.
Анализ скриншотов и видео с фермы — K3. У дешёвых облачных альтернатив зрение слабее, у локальных — тем более. Локаторы всё равно проверяйте руками.
Агентные цепочки с MCP (TestOps, Jira, Confluence) — K3, но с обязательным прокидыванием reasoning_content и явным tool_choice на критичных шагах.
Всё под NDA и политикой ИБ — только локальные модели. Этот пункт не обсуждается, и никакой бенчмарк его не отменяет.
Интерактивная работа, где важна скорость ответа — kimi-k2.7-code-highspeed или другая быстрая модель. 28 токенов в секунду у K3 убивают интерактив.

Общий принцип один: цена ошибки модели должна быть соизмерима с ценой её вызова. Генерить шаблонный тест флагманом — жечь деньги. Разбирать странное падение, которое съело бы полдня, дешёвой моделью — жечь время.

Выводы

K3 — первая модель за долгое время, которая заставила меня пересмотреть схему «локалка для всего, облако по остаточному принципу». Не потому что она «лучшая во всём» — независимых подтверждений этому пока нет, и вендорские таблицы я бы на стенд не тащил. А потому что миллион токенов контекста плюс нормальное зрение плюс рабочий tool calling закрывают класс задач, который раньше не закрывался вообще: полный разбор регресса, анализ экрана с фермы, ресёрч с источниками.

Моя итоговая схема на сегодня выглядит так. Локальные модели — приватное, рутинное, высокочастотное. K2.7 Code — объёмная кодогенерация, где важна цена и скорость. K3 — еженедельный разбор регрессов, сложные рефакторинги тестовой архитектуры, скриншоты и видео, всё, где нужен длинный контекст. Дешёвая модель впереди как классификатор-роутер, K3 только по эскалации. Счёт при такой схеме выходит вменяемым, а качество разборов заметно выросло — особенно там, где падения коррелируют между собой и их надо видеть все сразу.

Осталось дождаться двух вещей: независимых лидербордов (BenchLM обещает добить покрытие, Artificial Analysis уже собирает свои прогоны) и открытых весов, обещанных к 27 июля. Веса домой я тащить не буду — 2.8 триллиона параметров это не про Mac mini, — но для индустрии это важный сигнал: открытые модели перестали быть вторым сортом. А нам, QA, от этого только плюс: чем плотнее конкуренция наверху, тем дешевле и лучше инструменты, которыми мы разбираем свои ночные регрессы.

Если тестировали K3 на своих задачах — особенно на мобильной автоматизации, где у меня выборка пока маленькая, — делитесь в комментариях. Интересны реальные цифры по стоимости прогонов, а не бенчмарки.