Moonshot AI выпустила Kimi K2.7-Code и сразу зашла с понятным для команд аргументом: модель должна тратить на 30% меньше thinking-токенов, чем K2.6. Для тех, кто уже гоняет кодовые LLM через шлюзы и считает стоимость агентных сценариев не в презентациях, а в счетах за инференс, новость выглядит полезной. Проблема в том, что с качеством все не так однозначно: по данным VentureBeat, практики уже начали публично спорить с тем, как Moonshot измеряет прогресс модели.
Kimi K2.7-Code — это открытое обновление линейки K2 для программирования. Модель построена на той же mixture-of-experts-архитектуре примерно триллионного масштаба, что и K2.6, и подключается через OpenAI-совместимый API. Для рынка это важная деталь: если компания уже интегрировала K2.6 в production-маршрутизацию, переход на новую версию не требует переделывать весь контур. Веса выложены на Hugging Face, лицензия указана как Modified MIT, а развернуть модель можно через vLLM или SGLang.
Главное обещание Moonshot звучит так: новая версия меньше «переобдумывает» задачу и поэтому работает экономнее. Компания утверждает, что Kimi K2.7-Code сокращает расход thinking-токенов на 30% относительно K2.6. Для команд, которые строят агентные пайплайны с длинными цепочками рассуждений, это не косметика. Если цифра подтвердится на реальных задачах, можно снизить стоимость инференса без миграции на другую модельную линейку и без пересборки API-обвязки. На этом месте любой инженер обычно достает калькулятор, а не фанфары.
Есть и технические нюансы, которые не всем понравятся. K2.7-Code работает только в thinking-режиме и не поддерживает настройку temperature: Moonshot зафиксировала ее на уровне 1.0. Это означает, что у команд не будет привычного рычага для управления детерминированностью ответов. Для части задач это терпимо, особенно если модель используется как один из маршрутов внутри более крупного gateway. Но если компания любит тонко подкручивать поведение моделей под разные классы задач, ограничение выглядит не мелочью, а архитектурной особенностью, с которой придется жить.
Moonshot также утверждает, что K2.7-Code по-другому пишет низкоуровневый код. Если K2.6, по описанию компании, чаще собирала решения из существующих библиотек и знакомых фреймворков, то новая версия чаще пишет реализацию сама. Отсюда и заявка на лучшее обобщение в Rust, Go и Python, а также на задачах фронтенда, DevOps и оптимизации производительности. В собственных тестах Moonshot результат выглядит бодро: плюс 21,8% на Kimi Code Bench v2, плюс 11% на Program Bench и плюс 31,5% на MLS Bench Lite.
И вот здесь начинается самое интересное. Все три упомянутых бенчмарка — внутренние тесты самой Moonshot. На независимый DeepSWE модель, как пишет VentureBeat, пока не отправляли. Для рынка корпоративной маршрутизации это важный пробел: DeepSWE считается более «разводящим» модели сигналом, чем SWE-Bench Pro, потому что дает больший разброс результатов и лучше показывает, кто действительно решает задачи, а кто красиво выглядит в усредненной таблице. Для компаний, которые раздают кодовые запросы между несколькими LLM и настраивают веса маршрутизации, разница между «сильна в собственном тестовом наборе» и «держится на независимом бенчмарке» вполне денежная.
Снаружи корпоративной презентации картина уже сложнее. Исследователь Elliot Arledge прогнал K2.7-Code, K2.6 и Claude Fable 5 через KernelBench-Hard — публичный тест на оптимизацию GPU-ядер — и опубликовал логи. Его вывод звучит жестко, но по делу: новая модель «честнее, но не способнее». По пяти из шести задач K2.7-Code действительно писала настоящие Triton-ядра там, где K2.6 раньше обходилась обертками над библиотеками. Но две такие реализации упали из-за собственных ошибок модели. Более того, в задаче с MoE kernel оценка ухудшилась: с 0,222 у K2.6 до 0,157 у K2.7-Code. Иными словами, модель стала меньше хитрить за счет обвязки, но это еще не значит, что она стабильно лучше пишет рабочий код.
Еще одну публичную претензию сформулировал разработчик Sugumaran Balasubramaniyan, который собирал model-task-router для платформы Hermes Agent и использовал DeepSWE как опорный сигнал. Он прямо поставил под вопрос выбор бенчмарков Moonshot. Его аргумент неприятный, но знакомый любому, кто видел рынок LLM последние два года: почти каждая модель внезапно показывает двузначный рост, если измерять ее на собственном наборе тестов. Balasubramaniyan напомнил, что K2.6 набирала 24% на DeepSWE и делила этот уровень с GPT-5.4-mini, и задал очевидный вопрос: покажет ли Kimi K2.7-Code такой же прогресс на том же независимом тесте? Он добавил, что готов маршрутизировать coding-задачи на новую модель, если независимые цифры это подтвердят. То есть рынок не отвергает релиз, а требует нормальной верификации, и это, пожалуй, самый здоровый сценарий.
Для русскоязычных команд практический вывод довольно приземленный. Если у вас уже есть K2.6 в проде, новый релиз выглядит как относительно безопасный кандидат на A/B-тест в тех же gateway-контурах: API совместим, инфраструктурный порог входа низкий, а потенциальная экономия на thinking-токенах слишком заметная, чтобы ее игнорировать. Но менять веса маршрутизации только по пресс-релизу Moonshot — плохая инженерная привычка. В кодовых моделях сейчас важен не красивый график «плюс 31,5%», а то, как часто модель реально доводит задачу до рабочего состояния на вашем наборе репозиториев, тестов и CI-ограничений.
Главный вопрос после релиза звучит не «быстрее ли стала Kimi», а «где заканчивается экономия и начинается маркетинг». Если Moonshot выведет K2.7-Code на независимые бенчмарки и цифры не развалятся, у рынка появится сильный open-source-кандидат для production-маршрутизации кодовых задач. Если нет, модель останется хорошей историей про снижение token burn, но не про доказанный рост качества. Первоисточник: .