Случилось то, что должно было случиться: очередной громкий релиз открытой ИИ-модели, за которым тянется шлейф как громких обещаний, так и серьезных вопросов. Moonshot AI на этой неделе выкатила Kimi K2.7-Code — обновление своей знаменитой кодовой линейки K2, которое, по словам разработчиков, должно было решить проблему "переразмышления" (overthinking) и срезать до 30% затрат на так называемые thinking token'ы. В теории — музыка для ушей любого DevOps-инженера, который считает каждый цент инфраструктуры. Но как всегда, дьявол кроется в деталях, а точнее — в бенчмарках.
Что это вообще такое?
По данным издания VentureBeat, Kimi K2.7-Code базируется на той же архитектуре mixture-of-experts с триллионом параметров, что и ее предшественник K2.6. Модель уже доступна на HuggingFace под модифицированной лицензией MIT, а развернуть её можно через vLLM или SGLang. Ключевая особенность: она работает исключительно в режиме "размышления" (thinking mode) и не позволяет настраивать температуру — создатели жестко зафиксировали её на 1.0. Это значит, что команды, привыкшие тонко настраивать детерминированность вывода, получат стандартный "креативный" режим без права выбора.
Главное архитектурное новшество — это то, как модель генерирует низкоуровневый код. Если K2.6 предпочитала оборачивать существующие библиотеки и маршрутизировать через готовые фреймворки, то K2.7-Code пишет реализацию "с нуля". По словам Moonshot AI, это дает более надежную генерализацию под Rust, Go и Python, причем как для фронтенда, так и для девопс-задач или оптимизации производительности. Звучит круто, но давайте заглянем под капот.
Цифры, которые смущают
Компания рапортует о впечатляющих результатах на собственных бенчмарках: +21.8% на Kimi Code Bench v2, +11% на Program Bench и +31.5% на MLS Bench Lite. Проблема в том, что все три теста — внутренние разработки самой Moonshot AI. Модель даже не отправили на DeepSWE — независимый код-бенчмарк, который, в отличие от раздутого SWE-Bench Pro, дает разброс в 70 пунктов между моделями и считается гораздо более объективным сигналом для команд, настраивающих роутинг запросов. Как метко выразился разработчик Сугамаран Баласубраманиян: "Уважаемо, но каждая модель 'улучшается' на двузначные цифры в своем собственном тестовом наборе". И он прав.
Исследователь Эллиот Арледж не поленился прогнать K2.7-Code через публичный KernelBench-Hard, который заточен на оптимизацию GPU-ядер. Результаты он опубликовал на kernelbench.com. И картина там, мягко говоря, смешанная. В пяти из шести задач модель действительно написала "честные" Triton-кернелы, а не обертки библиотек. Но два из этих кернелов упали на собственных же багах. А по основному показателю (MoE-ядро) модель регрессировала с 0.222 до 0.157. "K2.7 стал честнее, но не способнее", — резюмировал Арледж, добавив, что "Fable, для справки, проходит каждый тест честно, если не проваливается". Это сильный удар по репутации.
Что это значит для бизнеса?
Если отбросить хайп, то заявленная экономия в 30% thinking-токенов — это та самая "быстрая победа", которую можно получить, просто подменив модель через OpenAI-совместимый API. Для команд, уже использующих K2.6 в продакшене, это фактически zero-risk интеграция: никаких изменений в архитектуре, только потенциальное снижение стоимости инференса на агентных воркфлоу. Именно эта метрика напрямую влияет на расходы.
Однако практический вопрос остается открытым: удержатся ли эти цифры на вашем конкретном распределении задач? Вполне возможно, что на типовых задачах по рефакторингу или написанию юнит-тестов модель покажет себя отлично, а вот на сложных GPU-оптимизациях — уже нет. Единственный разумный путь здесь — прогнать K2.7-Code на собственных рабочих нагрузках до того, как менять веса в шлюзах. Только так вы узнаете правду, а не красивые цифры из пресс-релиза.