Отчёт о прогрессе · TechCon ML · 24.11.2025 — 08.09.2026

Инфраструктура Yandex Cloud TechCon ML

Флот вырос с двух машин до полноценной облачной платформы, пережил три реальных инфраструктурных инцидента и ни разу не стал узким местом для роста команды ИИ — потому что рос вместе с нагрузкой, а не вдогонку ей.

852
итерации разработки
непрерывно с 24.11.2025
288
дней в работе
с ростом флота 2 → 10 машин
3
инцидента поймано мониторингом
устранены до жалоб клиентов
18
архитектурных вех
не считая рутинных правок
Зачем это нужно

Один растущий фундамент под всю команду ИИ

У каждого продуктового направления команды ИИ — свои процессы, свои тесты, свой автоматический деплой. Но всё это работает на общей физической основе: виртуальных машинах, GPU-картах, сети и системе доставки изменений в Yandex Cloud. Когда объём работы команды ИИ растёт, эта основа обязана расти вместе с ней — иначе она либо не выдержит нагрузку и сломается в самый неподходящий момент, либо станет потолком, в который упрётся дальнейший рост.

На чём держится рост

Три опоры, без которых рост команды ИИ остановился бы

01

Стандартизация и надёжность под нагрузкой

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

02

Удобство для ИИ-агентов

Значительная часть разработки и эксплуатации сейчас ведётся ИИ-агентами, а не только людьми. Флот специально дооснащён механизмами, которых обычному человеку-оператору не требуется вовсе — устойчивый доступ без личного ключа, живая (не устаревающая) документация, автоматические защитные проверки прямо внутри агентской сессии.

03

Адаптация под меняющуюся ситуацию

Собственные конфигурации, сервисы, автоматика и CI/CD-процессы наращивались постепенно и по факту реальных потребностей — от простого автостопа простаивающей видеокарты до полноценной модели резервирования на нескольких GPU с автоматическим переключением при отказе.

Путь · этап 1

С нуля до проверенного автоскейлинга

24.11.2025 — 22.04.2026. Первые пять месяцев — фундамент: инфраструктура-как-код, первый механизм экономии, полная смена платформы разработки и первая крупная система, построенная и доказанная на практике

декабрьянварьфевральмартапрельСтарт: 2 машины24.11Первый автостоп GPU27.11Смена платформы разработки07.01Базовые автопроверки16.03Автоскейлинг доказан22.04
24.11.2025

Старт: инфраструктура как код

Первые коммиты — сборка образа для GPU-машины и базовая конфигурация в Yandex Cloud. Флот на тот момент — 2 машины: управляющий узел и одна GPU-машина.

27.11.2025

Первый механизм экономии

Автоматическая остановка GPU-машины при неактивности — самый первый инструмент контроля затрат, задавший паттерн, который потом воспроизводится весь год.

07.01.2026

Полная смена платформы разработки

Все сценарии автоматизации переписаны с Windows на Linux — не косметика, а смена операционной основы, на которой строится вся дальнейшая работа.

16.03.2026

Базовые автоматические проверки

Контроль здоровья сервисов, контроль бюджета облака, управление ключами доступа и проверки качества кода инфраструктуры (Terraform — язык, которым эта инфраструктура описана как код) собраны в единый конвейер.

22.03 — 22.04.2026

Автоскейлинг GPU построен и доказан

Месяц работы — от первого прототипа до системы, которая на реальных данных обработала 500 задач со скоростью 340 задач в минуту на одной видеокарте без единого сбоя. Система доказана на практике.

Как мы ловим сбои

Мониторинг и алертинг, которые ловят проблему раньше клиента

За время работы флот пережил три по-настоящему критических момента — и в каждом система наблюдения сработала быстрее, чем об этом успел бы узнать хоть один клиент нашего API. Ниже — три случая, когда защита сработала так, как должна.

17.03.2026

Управляющий сервер — обнаружено и восстановлено за ~2 часа

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

С этого момента — защита от случайного пересоздания критичных машин, снимки состояния каждый день.
25.05.2026

GPU-машина — восстановлена по отработанной процедуре

Общая видеокарта для двух сервисов ушла в нерабочее состояние — мониторинг зафиксировал это сразу, восстановление прошло по заранее подготовленному сценарию.

Пошаговая процедура восстановления закреплена и с тех пор применяется как стандарт для всего GPU-флота.
21.07.2026

Диск видеокарты — восстановлен из резервной копии

Одна из плановых инфраструктурных операций задела диск видеокарты — система резервного копирования позволила восстановить его без потери данных.

Защита от подобной ситуации теперь включена на весь GPU-флот + автоматическое восстановление сервисов после любого пересоздания машины.
Путь · этап 2

Рост нагрузки — рост дисциплины

21.05 — 08.09.2026. Пятнадцать с половиной недель — от единичной системы резервирования GPU до систематической, постоянно работающей дисциплины оптимизации всего флота

Архитектура
21 — 28.05 · Единая точка управления GPU
переписан оркестратор

Механизм распределения GPU-задач переписан заново под единую модель управления — вместе с полноценной архитектурной документацией.

Новый класс проверок
12 — 13.06 · Автоматическая сверка клиентских сигналов
целый новый класс проверок

Мы научились автоматически находить целый новый класс ошибок — расхождение между тем, что система сообщает интегратору (например время ожидания результата), и тем, что происходит по факту. Первое применение — сразу на новой видеокарте при подключении.

Переход
22 — 29.06 · Флот переходит под управление ИИ-агентов
Claude Code + правила коммитов

Репозиторий переходит на модель работы, где значительную часть разработки и эксплуатации ведут ИИ-агенты — с правилами, принудительно проверяемыми автоматически, раз нет штатной защиты веток для команды такого масштаба.

Адаптация
06 — 29.07 · Резервирование GPU усложняется в 4 шага
одна карта → сеть подстраховки

Модель резервирования видеокарт эволюционировала за месяц: сначала одна активная карта → добавлен второй воркер по требованию → автоматическое переключение при перегрузке → полное автоматическое резервирование при отказе.

Миграция
22 — 23.07 · CI переезжает на собственные мощности
устранён риск блокировки биллинга

Автоматические проверки полностью переведены на собственные вычислительные мощности команды вместо внешнего сервиса — заодно закрыт риск, найденный в мартовской утечке (сканирование секретов теперь обязательно для всей команды).

Аудит
05 — 06.08 · Целевая топология флота + системный аудит
~40 находок за 2 дня

Плановая структура флота впервые полностью описана кодом. В те же два дня — системная проверка всего флота нашла около 40 реальных скрытых проблем: от пропущенных хостов при смене паролей до открытого наружу доступа на боевой машине.

Рост
15 — 16.08 · Шестой продуктовый сервис в общем флоте
образовательная платформа

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

Инструмент
19.08 · Прогноз затрат на 30 дней вперёд
построен на живых ставках биллинга

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

Оптимизация
31.08 — 01.09 · Машины подогнаны под фактическую нагрузку
по 14 дням реальных измерений

Мощность двух вспомогательных машин пересмотрена не на глаз, а по двум неделям живых замеров загрузки процессора и памяти — размер ресурса теперь соответствует тому, что реально используется.

Финал
05 — 08.09 · Финальная волна оптимизации сети и CI
по 7 дням живых измерений

Убраны лишние точки выхода в интернет на вычислительных узлах CI, а параметры системного узла подогнаны под недельный замер фактической загрузки — та же дисциплина «решение по факту, не по памяти», применённая к сети и CI-мощностям.

Экономика флота

Флот растёт — расходы под контролем, а не пропорционально росту

Без автоматики флот стоил бы в разы дороже — и продолжал бы дорожать вместе с ростом нагрузки. С автоматикой стоимость под контролем несмотря на рост.

Гипотетически · без автоскейлинга
~400 000 ₽/мес
по нашим расчётам: только 4 видеокарты T4, работая круглосуточно без остановки, обходились бы команде в такую сумму — и это без учёта остальных машин флота
Фактически · сентябрь 2026
~112 000 ₽/мес
весь флот целиком — не только видеокарты, а все ~10 машин вместе — обходится дешевле, чем стоили бы одни только T4 без автоматики

Мы разработали собственный механизм сверки факта и ожидания — автоматически сравнивает, действительно ли карта выключается тогда, когда должна. Именно он нашёл резерв экономии на одной из карт:

До применения находки
2 055 ₽/сутки
фактическая стоимость одной видеокарты, работавшей без пауз
После применения
~500 ₽/сутки
экономия 46 646 ₽ в месяц на этой одной карте — без потери отзывчивости для клиентов

Ещё три похожие находки за тот же период — та же системная практика, не разовая акция: забытый резервный сетевой адрес (435 ₽/мес), избыточные отдельные внешние адреса на вычислительных узлах (670 ₽/мес), лишние резервные снимки дисков сверх необходимого минимума (3 181 ₽/мес).

Структура флота

Три уровня доверия, один общий вход

ОБЩАЯ ОБЛАЧНАЯ СЕТЬ — ПОЛНЫЙ АНСАМБЛЬ ФЛОТА
ОСНОВНЫЕ СЕРВИСЫ (5 машин)
Узел мониторинга
вход + мониторинг + бастион доступа
Прод-приложения
боевые CPU-приложения
Управление GPU
очередь GPU-задач без публичного адреса
pub-showcase-dev-01
витрина для разработки
Обучение
образовательная платформа
ВИДЕОКАРТЫ T4 — ВКЛЮЧАЮТСЯ И ВЫКЛЮЧАЮТСЯ ПО НАГРУЗКЕ (4 карты)
GPU-нода 1
боевая, основная
GPU-нода 2
боевая, резервная
GPU-нода 3
разработка
GPU-нода 4
научный контур
ОТДЕЛЬНО ОТ ОСНОВНОЙ СЕТИ (2 объекта)
Зона автоматических проверок
кластер, исполняет проверки кода перед выкладкой — от 1 до 10 временных узлов, без публичного адреса
ext-vm-01
изолированная машина для внешних коллег — отдельная сеть, без маршрута к боевому контуру

Всего ~10 постоянно объявленных машин + временный кластер проверок. Деление — не по «прод/дев» на уровне сети, а по уровню доверия: зона автоматических проверок и изолированная машина для внешних коллег не имеют маршрута к боевому контуру, даже находясь в общей облачной инфраструктуре.

Почему так, а не проще

Видеокарты отдельно от боевых сервисов

GPU-машину можно пересоздать, перезагрузить или добавить новую, не трогая сервисы, которые от неё не зависят. Именно поэтому потеря диска одной карты в июле не задела остальной флот.

Проверки кода — в изолированной зоне

Код, ещё не прошедший проверку, исполняется отдельно от боевого контура и без публичного адреса. Проблема на этом узле не даёт прямого пути к боевым данным и клиентскому трафику.

Доступ внешних коллег — в отдельной сети

Машина для работы с людьми вне команды физически не имеет маршрута к боевому контуру. Ошибка или инцидент на ней не может дотянуться до продуктовых сервисов, даже случайно.

Карты включаются и выключаются сами

Видеокарта поднимается за секунды под задачу и гасится, когда работы нет — без потери отзывчивости для клиента и без часов простоя вхолостую. Отсюда и разница в стоимости выше.

Глубокая интеграция с облаком

Продуманное использование платформы Yandex Cloud

Флот использует возможности платформы целенаправленно, не ограничиваясь базовой арендой виртуальных машин:

Автоскейлинг — напрямую через API облака
собственный клиент к Compute API Yandex Cloud, не сторонняя надстройка
полный контроль над логикой включения/выключения
Проверки кода — на managed-кластере Kubernetes
собственные вычислительные мощности вместо внешнего сервиса
от 1 до 10 узлов по нагрузке автоматически
Затраты — из первых рук, не на глаз
прогноз стоимости строится на живых ставках биллинга платформы
решения об оптимизации — на реальных цифрах
Опора 2 — подробнее

Флот, спроектированный для ИИ-агентов, а не только для людей

Часть решений ниже вообще не имела бы смысла для человека-оператора — они закрывают ограничения, которые есть только у ИИ-агента.

Живая документация вместо памяти
актуальные инструкции по флоту рассылаются автоматически каждый день
агент больше не работает по устаревшему адресу машины
Доступ к флоту без личного ключа
у агентской сессии нет и не может быть личного ключа доступа
работа не останавливается из-за отсутствия ключа
Защита прямо внутри рабочей сессии
механическая проверка, а не текстовое правило, которое можно не заметить
найдено и закрыто после реального случая
Автоматизация выкладки изменений

От риска «выкатили и не проверили» — к автоматическому откату

Единый механизм выкладки изменений в бой — со встроенной проверкой здоровья и автоматическим откатом при сбое — сейчас использует часть продуктовых сервисов команды; остальные ведут собственный путь выкладки с той же целью, но без общего инструмента. Постепенный перевод оставшихся сервисов на единый механизм продолжается.

Куда движемся дальше

Текущее состояние полностью устраивает — движемся дальше по пути совершенствования

Дальнейшая оптимизация флота

Продолжаем искать и устранять похожие скрытые издержки тем же системным методом, что уже показал результат.

Более глубокая совместимость с ИИ-агентами

Развиваем системы, удобные и совместимые с работой ИИ-агентов, — это направление становится только важнее по мере роста их доли в разработке и эксплуатации.

Устойчивость к внешним сбоям

Повышаем стабильность и живучесть флота на случай внешних инцидентов — чтобы восстановление после сбоя облачного провайдера или сети было таким же быстрым и предсказуемым, как уже отработанное восстановление внутри самого флота.