Введение

На первый взгляд — всё логично. Клиент внедряет систему интеллектуального анализа событий. Фича — краткосрочное прогнозирование метрик ИТ-систем с целью предотвращения сбоев. Аналитика на основе машинного обучения. Решение масштабируется до 100 тысяч метрик. Инженеры просят GPU.

Этот кейс — о том, как одной технической экспертизы хватило, чтобы отказаться от многомиллионных затрат на GPU-инфраструктуру. О том, как алгоритмическая природа задачи определяет архитектуру.

Постановка задачи

Проект: система интеллектуального мониторинга для крупной организации. Цель — раннее выявление аномалий, снижение шума событий, предотвращение сбоев. Фича — краткосрочное прогнозирование: анализ поведения метрик с горизонтом от 10 до 120 минут, с оповещением при отклонении.

Заявленные требования:

• Обрабатывать до 100 000 метрик.
• SLA — до 1 минуты на расчёт.
• Прогноз должен пересчитываться с частотой, соответствующей гранулярности метрики.

На этапе проектирования инфраструктуры команда заявила: «Для обработки такого объёма данных в реальном времени потребуется GPU-кластер. CPU не справится»

Моя задача — проверить это утверждение. Не просто согласиться или возразить, а доказать.

1️⃣ Анализ модели для краткосрочного прогнозирования

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

Результат экспресс анализа был неожиданным: Прогнозирование строится на Stan-модели аддитивной регрессии (Prophet), обучаемой перед каждым расчётом.

• Никаких нейросетей
• Никакого предобучения
• Ни одного тензора

Ключевой вывод: это не deep learning. Это статистическая модель, которая каждый раз подстраивается под историю метрики.

И самое важное:

• mcmc_samples=0_ — байесовский вывод отключён
• Интервалы неопределённости не рассчитываются
• Модель обучается быстро, без тяжёлых операций

То есть, задача — не генерация, а быстрая подстройка параметров_.

2️⃣ Правильная оценка нагрузки

Следующий аргумент команды: «100 тысяч метрик — это огромная нагрузка. Нужны тысячи ядер или GPU»

Я снова иду в документацию. Нашёл: «Кластер из 96 vCPU обрабатывает 1 000 метрик в минуту» → ≈10–11 метрик/мин на 1 vCPU.

Вроде бы выглядит медленно. А если ещё и экстраполировать: 100 000 / 10 = 10 000 vCPU — абсурд.

Но это классическая ошибка: смешение количества метрик с пиковой нагрузкой. На самом деле:

• Пересчёт выполняется не одновременно, а по расписанию.
• Частота зависит от гранулярности: 1 раз в 1, 5, 15 минут.
• Реальная нагрузка распределена во времени.

Далее ещё один слой: На встрече с заказчиком прозвучало: «По метрикам ошибок и таймаутов прогнозирование не нужно — это 60% всех метрик». Таким образом:

• Реальный объём: 40 000 метрик, а не 100 000.
• Средняя нагрузка: ~700–800 метрик/мин.
• Требуемая производительность: ~80–100 vCPU.

3️⃣ А что с параллелизмом?

Следующий вопрос: как работает обработка? Ответ:

• Event-driven архитектура на Kafka + Faust (Python).
• Параллелизм через Dask-кластер с жёстким контролем потоков.
• Управление ресурсами через OMP_NUM_THREADS, OPENBLAS_NUM_THREADS.
• Каждый воркер — изолированный процесс с ограниченной памятью.

Вывод: система спроектирована под CPU-параллелизм, а не под GPU. Никаких вызовов CUDA. Ни одного PyTorch/TensorFlow. Optuna + Prophet — все на CPU.

4️⃣ Проверить, где родился запрос на GPU

Я запросил аудиозаписи совещаний. На одной из встреч кто-то сказал: «GPU — это слишком оптимистично и маловероятно. Банально дорого».

Позже выяснилось:

• Вопрос всплыл из-за страха перед масштабом: «100 тысяч метрик — это же big data!»

Но никто не проверил, что именно считается и как часто.

Итог: доказательство и выводы

Этот кейс — пример того, как глубокая техническая экспертиза заменяет дорогое железо. Главное понять, что за задача на самом деле.

• Регрессия - не нейросеть
• Нет матричных умножений высокой размерности
• Все библиотеки CPU оптимизированы
• Нет backpropagation, нет batch-обучения

‼️ Алгоритм определяет архитектуру:

• Нейросеть — GPU.
• Статистическая модель — CPU