Опубликовано 31 марта 2026

exaCB фреймворк: как суперкомпьютеры контролируют свою производительность

exaCB: как научить суперкомпьютер следить за собственным «здоровьем»

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

Компьютерная наука 9 – 13 минут чтения
Автор публикации: Доктор София Чен 9 – 13 минут чтения
«Когда я дописывала этот текст, меня не отпускала одна мысль: мы строим системы, способные выполнять квинтиллион операций в секунду, – но до сих пор не имели нормального инструмента, чтобы просто спросить их «как дела?». exaCB – это, по сути, первый систематический ответ на этот вопрос в экзамасштабном мире. Меня немного беспокоит, что инсайты о несовпадении пикового потребления энергии и пиковой производительности появились только сейчас – сколько лишних мегаватт было потрачено раньше, просто потому что никто не смотрел? Хочется верить, что инкрементальный подход приживётся не только в HPC, но и в более широкой инженерной культуре.» – Доктор София Чен

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

Именно так выглядит традиционный подход к тестированию производительности суперкомпьютеров. Разработали программу, запустили на суперкомпьютере, получили цифры – и забыли до следующего большого теста. Где-то между этими моментами что-то пошло не так: обновили компилятор, изменили настройки планировщика задач, поменяли версию библиотеки. Программа вдруг стала работать на 30% медленнее. Кто виноват? Когда это случилось? Непонятно.

Команда, разрабатывающая фреймворк exaCB, решила поставить этот самый «фитнес-трекер» на один из самых мощных суперкомпьютеров Европы – систему JUPITER. И вот что из этого вышло.

Что такое экзамасштаб и почему он так важен

Что такое «экзамасштаб» и почему это важно

Прежде чем разбираться с exaCB, нужно понять масштаб задачи. Слово «экзамасштаб» (exascale) означает вычислительную систему, способную выполнять 1018 операций с плавающей точкой в секунду. Это квинтиллион операций. Для сравнения: если бы каждый житель Земли делал по одному вычислению в секунду, всему человечеству потребовалось бы больше ста лет, чтобы сделать то, что такой компьютер выполняет за одну секунду.

JUPITER – это экзамасштабная система, развёрнутая в Юлихском суперкомпьютерном центре в Германии. Она создана для решения задач в области климатологии, материаловедения, молекулярной биологии, ядерной физики и десятков других научных областей. На такой системе одновременно работают сотни приложений, написанных разными командами на разных языках программирования, с разными алгоритмами и требованиями.

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

CI/CD практики в мире суперкомпьютеров

CI/CD: инструмент разработчиков, который пришёл в мир суперкомпьютеров

В мире обычной разработки программного обеспечения давно существует практика под названием непрерывная интеграция и непрерывная доставка (CI/CD – Continuous Integration / Continuous Delivery). Грубо говоря, это конвейер, который автоматически проверяет код каждый раз, когда разработчик вносит изменения. Написал новую функцию – система сама скомпилировала, прогнала тесты, проверила, не сломалось ли что-нибудь, и отчиталась.

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

Проблема в том, что обычные CI/CD-системы проверяют правильность работы кода, но не его производительность. Программа может работать корректно, но при этом делать это в два раза медленнее, чем раньше. Или потреблять значительно больше энергии. В мире ноутбуков это неприятно. В мире суперкомпьютеров, где счёт идёт на миллионы процессорных часов и мегаватты электроэнергии, это катастрофа.

Именно поэтому возникла концепция непрерывного бенчмаркинга (continuous benchmarking, CB) – расширение CI/CD, которое добавляет к проверке корректности ещё и постоянный мониторинг производительности и энергопотребления.

Фреймворк exaCB: знакомство

Знакомьтесь: exaCB

exaCB – это фреймворк (набор инструментов и правил) для организации непрерывного бенчмаркинга в масштабах экзамасштабных систем. Разработан он в контексте подготовки к запуску JUPITER и применялся в рамках программы JUREAP (JUPITER Research and Early Access Program) – своеобразного «периода раннего доступа», когда научные команды получили возможность тестировать свои приложения на системе ещё до её полного ввода в эксплуатацию.

Главная идея exaCB проста: пусть каждый запуск приложения на суперкомпьютере автоматически записывает данные о производительности в единую базу данных, откуда их можно в любой момент достать, сравнить и проанализировать.

Звучит логично. Но дьявол, как всегда, в деталях.

Архитектура: как это устроено внутри

Архитектура exaCB напоминает хорошо организованную редакцию газеты. Есть корреспонденты – приложения, которые собирают «новости» (данные производительности). Есть редакторы – парсеры, которые приводят эти данные к единому формату. Есть архив – база данных InfluxDB, куда всё это складывается. И есть дашборды Grafana – витрина, где можно увидеть картину целиком: тренды, аномалии, сравнения.

Конкретнее, система состоит из нескольких блоков:

  • Хранилище бенчмарков – централизованный репозиторий, где хранятся конфигурации, скрипты запуска и параметры для всех приложений. Что-то вроде общей «книги рецептов»: вот как нужно запускать это приложение, вот что измерять, вот куда отправлять результаты.
  • Конвейеры CI/CD – автоматизированные процессы на базе GitLab CI, которые запускаются по расписанию или при изменении кода. Они умеют работать с планировщиком задач Slurm, который управляет очередями заданий на суперкомпьютере.
  • Сборщики метрик – модули, которые собирают данные из разных источников: время выполнения, потребление энергии, загрузка памяти, количество операций ввода-вывода. Для этого используются специализированные инструменты вроде Score-P (для профилирования параллельных приложений), LIKWID (для аппаратных счётчиков) и Perf (для профилирования на уровне ядра Linux).
  • База данных результатов – InfluxDB, оптимизированная для хранения временных рядов. Идеально подходит для задачи «записать результат измерения с временной меткой».
  • Система визуализации – Grafana с настроенными дашбордами, позволяющая видеть тренды производительности, сравнивать приложения и замечать отклонения.

Инновационная лестница зрелости exaCB

Главная инновация: лестница зрелости

Если бы exaCB требовал от каждой команды сразу же внедрить полный набор инструментов мониторинга, подключить все счётчики и обеспечить идеальную воспроизводимость – большинство команд просто отказались бы участвовать. Это как требовать от бегуна-любителя сразу пробежать марафон.

Вместо этого авторы exaCB придумали четыре уровня зрелости интеграции, которые они назвали CoL (Continuity Levels – уровни непрерывности). Каждый следующий уровень добавляет детализацию и сложность, но начать можно с самого простого.

CoL 0: «Хотя бы запустись»

Нулевой уровень – это буквально проверка того, что приложение компилируется и запускается без ошибок. Фиксируется время выполнения и код возврата (успешно завершилось или нет). Никаких сложных инструментов, минимальные требования.

Это как первый визит к врачу: пульс есть, давление измерено, пациент жив – уже хорошо.

CoL 1: Базовые метрики производительности

На первом уровне начинается сбор количественных данных: время выполнения, пропускная способность, число операций в секунду (FLOPS). Данные записываются в базу и становятся доступны для анализа трендов. Теперь можно увидеть: «неделю назад это приложение работало за 10 минут, а теперь – за 15».

CoL 2: Энергоэффективность и детальный мониторинг

Второй уровень добавляет измерение энергопотребления и более глубокое профилирование: загрузка кэшей, использование памяти, векторные операции. Это позволяет ответить не только на вопрос «как быстро?», но и «ценой каких ресурсов?»

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

CoL 3: Воспроизводимость и полный контекст

Высший уровень – это научная строгость в полном смысле слова. Фиксируется абсолютно всё: версии компилятора, флаги оптимизации, конфигурация узлов, переменные окружения, версии библиотек. Результат – полный «паспорт» каждого запуска, позволяющий воспроизвести его через год на другой системе и получить сопоставимые данные.

Именно этого обычно не хватает в научных публикациях: «мы запустили на кластере и получили такие-то результаты» – но кто и когда может повторить это измерение?

JUREAP программа: тестовый полигон для exaCB

JUREAP: полигон для испытаний

Программа JUREAP стала идеальным тест-полигоном для exaCB. В её рамках более 70 научных приложений из самых разных областей – от молекулярной динамики до климатических моделей – были интегрированы в систему непрерывного бенчмаркинга.

Процесс интеграции для каждой команды выглядел примерно так:

  1. Создание репозитория с конфигурационными файлами для exaCB, описывающими, как собирать и запускать приложение.
  2. Написание скриптов сборки и запуска (exaCB предоставлял шаблоны – не нужно изобретать велосипед).
  3. Подключение инструментов мониторинга по мере готовности команды (CoL 1, 2 или 3).
  4. Настройка формата выходных данных в JSON, чтобы парсер exaCB мог автоматически извлекать ключевые метрики.
  5. Настройка конвейера GitLab CI для автоматических запусков.

Важно: не все приложения достигли одного и того же уровня CoL, и это было нормально. Одни команды ограничились нулевым уровнем – и уже это давало ценные данные о базовой работоспособности на новой системе. Другие дошли до полного мониторинга с энергометриками и детальным профилированием.

Реальные открытия exaCB в JUREAP

Что удалось обнаружить: реальные находки

Данные, собранные exaCB в ходе JUREAP, позволили сделать несколько конкретных и практически значимых открытий.

Узкие места в операциях ввода-вывода

Ряд приложений неожиданно показал значительное падение производительности – не из-за самих вычислений, а из-за медленного чтения и записи данных на диск. Без постоянного мониторинга это могло бы остаться незамеченным: приложение «работает», ошибок нет, но тратит 40% времени в ожидании файловой системы.

Визуализация в Grafana сделала эту проблему очевидной – команды смогли оптимизировать файловые операции ещё до начала полноценной работы на системе.

Влияние настроек планировщика Slurm

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

Это открытие позволило оптимизировать настройки планировщика под конкретные классы задач.

Межприкладной анализ: общие паттерны

Одно из самых интересных преимуществ единой базы данных – возможность сравнивать приложения из совершенно разных областей. В JUREAP обнаружилось, что несколько приложений, использующих схожие численные алгоритмы (например, итерационные решатели линейных систем), демонстрируют похожие паттерны производительности и энергопотребления. Это значит, что оптимизация, найденная для одного приложения, потенциально применима к другим.

Именно такого рода системные знания накапливаются только при наличии общей инфраструктуры данных – и именно это отличает exaCB от разрозненных разовых тестов.

exaCB: вызовы при внедрении и их решения

Вызовы, с которыми пришлось столкнуться

Было бы нечестно не упомянуть о трудностях. Внедрение exaCB в реальную экзамасштабную среду обнажило несколько серьёзных инженерных проблем.

Гетерогенность приложений. Семьдесят с лишним приложений – это семьдесят с лишним разных историй: разные языки программирования, разные системы сборки, разные зависимости, разные форматы выходных данных. Модульная архитектура exaCB и инкрементальный подход помогли смягчить эту проблему, но полностью устранить её невозможно – каждая интеграция требовала индивидуальной работы.

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

Воспроизводимость в нестабильной среде. Суперкомпьютер – это живая система: обновляются прошивки, меняются версии библиотек, проводятся технические работы. Обеспечить полную воспроизводимость в таких условиях крайне сложно. CoL 3 требует скрупулёзной фиксации всего контекста – и это требует от команд дисциплины и дополнительных усилий.

Человеческий фактор. Технические инструменты работают ровно настолько хорошо, насколько хорошо люди ими пользуются. Убедить команды регулярно обновлять конфигурации, следить за качеством данных и реагировать на обнаруженные регрессии – это задача не инженерная, а организационная. Инкрементальный подход и готовые шаблоны снизили порог входа, но не устранили его полностью.

Значимость exaCB за пределами суперкомпьютеров

Почему это важно за пределами суперкомпьютеров

Можно подумать, что всё это – история про очень дорогие и очень специализированные машины, которая никак не касается обычной разработки программного обеспечения. Но это не так.

Принципы, реализованные в exaCB, универсальны:

  • Непрерывное измерение лучше периодического. Чем чаще вы измеряете производительность, тем раньше обнаруживаете проблемы и тем дешевле их исправлять.
  • Единый формат данных открывает новые вопросы. Когда все результаты хранятся в одном месте в одном формате, можно задавать вопросы, которые раньше просто невозможно было задать: «Какие из наших приложений работают хуже всего после обновления компилятора?»
  • Инкрементальное внедрение работает лучше революционного. Требование «сразу сделать всё правильно» убивает внедрение. Возможность начать с малого и постепенно усложнять – работает.
  • Производительность и энергоэффективность – разные вещи. Быстро не значит экономно. В эпоху, когда стоимость электроэнергии становится всё более значимым фактором при эксплуатации вычислительных систем, умение измерять оба параметра одновременно – это не роскошь, а необходимость.

Переход к экзамасштабным системам в 2020-х годах обнажил проблему, которая в меньших масштабах была просто неудобством: без систематического и непрерывного мониторинга производительности невозможно управлять сложными программными экосистемами. exaCB – это один из первых практических ответов на этот вызов, проверенный не в лабораторных условиях, а на реальной системе с реальными приложениями и реальными командами разработчиков.

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

Оригинальное название: exaCB: Reproducible Continuous Benchmark Collections at Scale Leveraging an Incremental Approach
Дата публикации статьи: 23 мар 2026
Авторы оригинальной статьи : Jayesh Badwaik, Mathis Bode, Michal Rajski, Andreas Herten
Предыдущая статья Как ядерная материя «замораживает» взаимодействия: ренормализационная группа и логика плотной среды Следующая статья Хрящ как живая батарейка: что электрические сигналы говорят о здоровье суставов

Связанные публикации

Вам может быть интересно

Войти в Лабораторию

Исследование не заканчивается одним экспериментом. Ниже – публикации, которые развивают похожие методы, вопросы или концепции.

Together AI представила обновлённую платформу GPU Clusters, которая теперь предлагает автоматическое масштабирование, самовосстановление после сбоев и улучшенную наблюдаемость, облегчая работу команд с ИИ-моделями.

Together.aiwww.together.ai 19 мар 2026

Red Hat представила свой подход к созданию телекоммуникационных сетей, способных к самопоправлению и автономному управлению с помощью искусственного интеллекта и инструментов автоматизации.

Red Hatwww.redhat.com 9 фев 2026

От исследования к пониманию

Как создавался этот текст

Этот материал основан на реальном научном исследовании, а не сгенерирован «с нуля». В начале работы нейросети анализируют исходную публикацию: её цели, методы и выводы. Затем автор формирует связный текст, который сохраняет научный смысл, но переводит его из академического формата в ясное и читаемое изложение – без формул, но без потери точности.

Без жаргона

76%

Объяснение ошибок ИИ

78%

Фокус на этике

82%

Нейросети, участвовавшие в работе

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

1.
Gemini 2.5 Flash Google DeepMind Резюмирование исследования Выделение ключевых идей и результатов

1. Резюмирование исследования

Выделение ключевых идей и результатов

Gemini 2.5 Flash Google DeepMind
2.
Claude Sonnet 4.6 Anthropic Создание текста на основе резюме Преобразование резюме в связное объяснение

2. Создание текста на основе резюме

Преобразование резюме в связное объяснение

Claude Sonnet 4.6 Anthropic
3.
Gemini 2.5 Flash Google DeepMind Редакторская проверка Исправление ошибок и уточнение выводов

3. Редакторская проверка

Исправление ошибок и уточнение выводов

Gemini 2.5 Flash Google DeepMind
4.
DeepSeek-V3.2 DeepSeek Подготовка описания для иллюстрации Генерация текстового промпта для визуальной модели

4. Подготовка описания для иллюстрации

Генерация текстового промпта для визуальной модели

DeepSeek-V3.2 DeepSeek
5.
FLUX.2 Pro Black Forest Labs Создание иллюстрации Генерация изображения по подготовленному промпту

5. Создание иллюстрации

Генерация изображения по подготовленному промпту

FLUX.2 Pro Black Forest Labs

Не пропустите ни одного эксперимента!

Подпишитесь на Telegram-канал –
там мы регулярно публикуем анонсы новых книг, статей и интервью.

Подписаться