Kimi объявила, что прекратит поддержку K2.5 в конце августа, пишет IT Home. Для бизнеса важнее не выход следующей модели, а срок жизни предыдущей: K2.5 представили только в январе, а теперь на перенос осталось несколько дней.
Этот случай закрепляет неприятное правило: модель нельзя считать стабильной частью архитектуры. Даже если она открытая, большая и еще недавно считалась самой умной в линейке.
Что именно отключают
Kimi K2.5 была первой триллионной мультимодальной моделью Moonshot AI. В январе компания открыла к ней доступ и одновременно перевела на K2.5 своего веб-ассистента: прежняя K2 в интерфейсе чата сменилась автоматически.
Модель позиционировалась как универсальная. Она принимала текст и изображения, работала в режимах с рассуждением и без него, поддерживала диалоги и Agent-задачи. Moonshot AI также заявляла о результатах уровня open-source state of the art в Agent-сценариях, программировании, работе с изображениями, видео и общих интеллектуальных задачах.
24 августа официальный аккаунт Kimi в Weibo сообщил, что в конце месяца K2.5 прекратит работу. Однако из пересказа IT Home непонятно, какие способы доступа будут отключены и что делать API-пользователям. Пересказ не описывает таблицу совместимости, новые тарифы или условия перенаправления существующих вызовов на другую модель.
Для продакшена это критичнее очередного числа параметров. Дата отключения уже есть, условий перехода, пока нет.
K3 выглядит преемником, но плана миграции пока нет
В июле Moonshot AI открыла Kimi K3. Это модель на 2,8 трлн параметров, построенная на Kimi Delta Attention и Attention Residuals. Она изначально поддерживает визуальное понимание и контекстное окно в 1 млн токенов.
K3 стоит первой включить в список кандидатов на замену, но считать ее совместимой с K2.5 преждевременно. В публикации IT Home она не названа рекомендованной заменой. Нет и сведений о совпадении API, режимов ответа, поддержки инструментов, задержки и стоимости. Размер модели сам по себе ничего не гарантирует: для продукта важны качество на его задачах, скорость и цена вызова.
Поэтому одной замены имени модели в конфиге недостаточно. Сначала нужно определить, где отключение K2.5 ударит по продукту: в чате, генерации кода, обработке изображений, Agent-цепочках или фоновых заданиях. Особое внимание, вызовам, спрятанным за внутренними алиасами: их легко пропустить до первого сбоя.
Проверять кандидатов следует на реальных запросах, где ошибка ведет к потерям: нарушает формат ответа, ломает вызов инструмента, увеличивает задержку или делает обработку слишком дорогой. Сценарии с изображениями, длинным контекстом и Agent-задачами нужно тестировать отдельно. Именно там различия между моделями чаще всего доходят до пользователя или останавливают автоматизацию.
Выиграет тот, у кого модель отделена от продукта
История K2.5 показывает цену прямой привязки приложения к одному поставщику. В январе модель автоматически заменила K2 в веб-интерфейсе, а через несколько месяцев ее саму выводят из эксплуатации. Для пользователя чата это может выглядеть обычным обновлением. В бизнес-системе смена модели способна изменить ответы, структуру вывода и поведение Agent-сценария.
Снизить этот риск помогает собственный слой между приложением и внешней моделью. Через него можно хранить шаблоны запросов, приводить ответы к внутреннему формату и перенаправлять трафик на другого провайдера. В случае K2.5 такой слой нужен не ради абстрактной гибкости: он позволяет заранее отправить часть запросов на K3 или другую модель, сравнить результаты и переключиться до отключения основного маршрута.
Если система работает на K2.5, ближайшие действия определяются конкретными пробелами в пересказе IT Home. Поскольку пересказ не уточняет, какие способы доступа затронет отключение, нужно найти все прямые и скрытые вызовы модели. Пока нет данных о совместимости, следует прогнать кандидатов на запросах, чувствительных к формату, инструментам и мультимодальности. Поскольку пересказ не приводит тарифы и показатели задержки, резервный маршрут нельзя утверждать без замеров фактической стоимости и времени ответа.
K3 разумно тестировать первой, но не единственной. Риск слепой миграции не обязательно в низком качестве новой модели. Достаточно, чтобы она иначе вернула JSON, медленнее обработала изображение или по-другому повела себя в Agent-цепочке, и продукт, рассчитанный на K2.5, начнет сбоить.
Главный маркер на ближайшие дни: опубликует ли Kimi официальную схему перехода с совместимым способом доступа, тарифами и судьбой существующих интеграций. Если такой схемы не будет, готовиться следует к жесткому отключению и переключению по собственному плану. Для новых продуктов вывод стоит закрепить в архитектурных требованиях: стабильным должен быть ваш интерфейс к моделям, потому что сами модели такими не будут.