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-скрипты

• выполнять действия одним или двумя SSH-вызовами

• иногда параллелить, но ограниченно

Kimi K2.5:

• активно использует 5–10 параллельных вызовов

• каждый шаг — отдельное действие

• агрегирует результаты по шагам

• при удалении ресурсов выполняет операции пакетно, с логами по каждому действию

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

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

Отдельно отмечу стоимость.

Все эксперименты, включая:

• развёртывание VM

• базы

• Docker-сервисы

• Kubernetes

• Ingress

• ArgoCD

• повторные попытки и исправления

• дополнительные проверки

обошлись в:

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

Модель активно кеширует input-токены, поведение в этом плане похоже на GPT-5.

Итоги

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

Плюсы:

• выполняет реальные инфраструктурные задачи

• хорошо работает с мультитулами

• адекватно реагирует на корректировки

• низкая стоимость экспериментов

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

• требует чуть более конкретного описания желаемого результата

• иногда выбирает архитектурные решения «в лоб»

• при этом способна перестраиваться по ходу выполнения

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

P.S.

Все эксперименты выполнялись в системе, разработанной нами.

Ссылки в статье и комментариях намеренно не оставляю — Хабр не место для рекламы.
Если интересно посмотреть или покрутить самостоятельно — информацию можно найти в профиле или написать мне в личные сообщения.