Что делать, если трансформер, выпущенный в production, не прошел нагрузочное тестирование?

Что делать, если трансформер не прошел нагрузочное тестирование?

Это кризисная ситуация в production. Вот пошаговый план действий.

Фаза 1: Немедленные действия (первые 30 минут)

Откатить модель немедленно — это критично. Потерять несколько часов дохода хуже, чем потерять лицо. Переключить traffic на старую версию и уведомить support команду.

Собрать информацию: какие метрики упали? Latency? Memory? CPU? Посмотреть логи на ошибки OOM, timeouts, crashes.

Фаза 2: Анализ (1-2 часа)

Типичные проблемы и решения:

Out of Memory:

• Уменьшить batch size (например, с 256 до 32)
• Использовать quantization (8-bit вместо 32-bit)
• Включить gradient checkpointing если fine-tuning
• Переключиться на дистиллированную модель (DistilBERT вместо BERT)

High Latency:

• Использовать dynamic batching для оптимизации обработки
• Конвертировать модель в ONNX для faster inference
• Использовать ONNX Runtime вместо PyTorch напрямую

High CPU Usage:

• Data loading или preprocessing bottleneck
• Решение: увеличить num_workers в DataLoader, использовать pin_memory

Фаза 3: Промежуточное решение (2-4 часа)

1. Уменьшить batch size еще больше
2. Включить caching для часто запрашиваемых примеров
3. Использовать mixed precision (автоматически половина точности)
4. Отключить data augmentation если она используется

Фаза 4: Root Cause Analysis

Провести post-mortem:

• Почему не был обнаружен при разработке?
• Какие метрики не мерили?
• Где сломался процесс?
• Как улучшить?

Фаза 5: Долгосрочные решения

1. Переделать архитектуру — использовать ensemble из маленькой и большой модели
2. Миграция на специализированное оборудование (TPU, AWS Trainium)
3. Дистилляция модели — обучить меньшую версию на знаниях полной
4. Использовать vLLM или TensorRT для оптимизации serving

Чеклист для предотвращения

Pre-deployment:

• Нагрузочное тестирование на production-подобном оборудовании
• P99 latency < требуемого
• Memory usage < 80% от доступной
• CPU < 70% (запас для spike)
• Мониторинг настроен
• Fallback модель готова

Post-deployment (первый день):

• Мониторинг включен
• On-call engineer готов
• Откатная процедура протестирована
• Алерты для аномалий

Ключевые выводы

1. Всегда иметь fallback — никогда не deploy без возможности откатиться
2. Нагрузочное тестирование на production-similar equipment
3. Постепенный rollout (5% → 25% → 100% traffic)
4. Мониторинг с первого момента — ловить проблемы в первые часы
5. Иметь несколько вариантов решения — дистилляция, кэширование, оптимизация

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