Отказоустойчивость AI: почему прод важнее демо

Распределённое обучение большой модели идёт часами и днями на десятках узлов.

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

Синхронный чекпоинтинг усугубляет проблему: каждое сохранение блокирует всех воркеров разом. NVRx на EKS сокращает потери от сбоя с часов простоя до минут - устранить сами сбои технически нельзя.

Это и есть TTU в чистом виде: ценность обучающей инфраструктуры не в пиковой скорости на здоровом кластере, а во времени возврата к полезной работе после отказа.

Красивый бенчмарк на демо-стенде ничего не говорит о том, что случится на 40-й час на 32 узлах.

Второй разбор - про агентов в healthcare и life sciences.

Модель попросили классифицировать миссенс-вариант TP53 по критериям ACMG/AMP.

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

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

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

Тот же принцип лежит в основе MCP: протокол работы с инструментом фиксируется снаружи модели, в структуре, которую можно проверить и версионировать, вместо того чтобы модель угадывала его сама.