Kimi K2.5 на прикладном уровне: те же инфраструктурные эксперименты, что и для GPT-5.2 и Sonnet

· Новости

В предыдущих материалах я уже подробно показывал, как GPT-5.2 и Anthropic Sonnet справляются с задачами прикладного уровня — не в формате «дать совет», а в формате реально выполнить действия в инфраструктуре.

В этом посте — те же самые эксперименты, но с Kimi K2.5 (reasoning).

Ключевое: методология не менялась. Менялась только модель.

Методология

Условия намеренно жёсткие и одинаковые для всех моделей:

  • минимальный промпт;
  • без пошаговых инструкций;
  • без заранее подготовленных Terraform / Helm / YAML;
  • управление через CLI и SSH;
  • реальная облачная среда.

Цель экспериментов — проверить, способна ли модель самостоятельно выполнять прикладные задачи, а не просто описывать, как это сделать.

Все архитектурные ограничения и условия — те же, что и в экспериментах с GPT-5.2 и Sonnet.

Эксперимент №1: VM + management-база + WordPress в Docker (Яндекс Облако)

Условия:

  • одна VM;
  • management-база (PostgreSQL);
  • WordPress в Docker;
  • Яндекс Облако;
  • подключение и управление через CLI и SSH;
  • промпт — минимальный.

Результат

Kimi K2.5 задачу выполнил, но повёл себя заметно иначе, чем GPT-5.2 и Sonnet.

Отличие №1 — схема подключения базы

Kimi K2.5:

  • создал для базы внешний IP;
  • ограничил доступ через Security Groups по IP VM.

В предыдущих экспериментах:

  • база и приложение соединялись внутри VPC;
  • без выноса базы наружу.

Это не «ошибка», а архитектурный выбор. Для тестового стенда — допустимо; для продакшена — спорно. Важно, что модель приняла решение самостоятельно.

Отличие №2 — WordPress и PostgreSQL

WordPress «из коробки» PostgreSQL не поддерживает.

Поведение Kimi:

  • попытался использовать стандартную схему;
  • обнаружил ограничение;
  • запросил подтверждение на изменение архитектуры;
  • переделал базу на MySQL.

В предыдущих экспериментах:

  • GPT-5.2 и Sonnet добавляли PostgreSQL-плагин для WordPress.

Здесь Kimi выбрал более консервативный и совместимый путь: меньше нестандартных решений, больше предсказуемости.

Пароли намеренно не скрывались: к моменту публикации стенд был удалён.

Эксперимент №2: Managed Kubernetes в Яндекс Облаке + Ingress + ArgoCD

Условия:

  • management-кластер Kubernetes;
  • 3 worker-ноды;
  • установка: NGINX Ingress Controller и ArgoCD;
  • минимальный промпт;
  • всё через yc, kubectl, helm.

Развёртывание Kubernetes

Модель самостоятельно:

  • создала service accounts;
  • назначила роли;
  • разобралась с версиями Kubernetes;
  • обработала конфликты CIDR;
  • исправляла ошибки CLI без ручных подсказок.

Да, API Яндекс Облака Kimi «раскачивал» дольше, чем GPT-5.2, но в итоге кластер и ноды были доведены до состояния RUNNING.

ArgoCD и Ingress

Первоначально Kimi попытался:

  • повесить отдельный LoadBalancer на ArgoCD.

В Яндекс Облаке это быстро упёрлось в лимиты внешних IP.

После моей корректировки:

  • ArgoCD был переведён на Ingress;
  • лишний LoadBalancer убран;
  • доступ заработал корректно.

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

Мультитулы — сильная сторона Kimi K2.5

На прикладных задачах разница особенно заметна.

GPT-5.2 и Sonnet чаще:

  • генерируют большие shell-скрипты;
  • выполняют действия 1–2 SSH-вызовами;
  • иногда параллелят, но ограниченно.

Kimi K2.5 чаще:

  • активно использует 5–10 параллельных вызовов;
  • делает каждый шаг отдельным действием;
  • агрегирует результаты по шагам;
  • при удалении ресурсов выполняет операции пакетно с логами по каждому действию.

По ощущению это ближе к реальной автоматизации, чем подход «сгенерировать скрипт и исполнить целиком».

Стоимость экспериментов

Все эксперименты (VM, базы, Docker-сервисы, Kubernetes, Ingress, ArgoCD, повторные попытки/исправления/проверки) обошлись в:

81 рубль 77 копеек.

Отдельно отмечу: модель активно кеширует input-токены; по поведению это похоже на GPT-5. За счёт кеширования входящих токенов их расход был заметно меньше.

Итоги

Kimi K2.5 — рабочая модель для задач прикладного уровня.

Плюсы:

  • выполняет реальные инфраструктурные задачи;
  • хорошо работает с мультитулами;
  • адекватно реагирует на корректировки;
  • низкая стоимость экспериментов.

Особенности:

  • требует чуть более конкретного описания желаемого результата;
  • иногда выбирает архитектурные решения «в лоб»;
  • при этом умеет перестраиваться по ходу выполнения.

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

Открыть чат ExecAI

Ещё в блоге