1) Все так. Но дать срез времени все равно полезно, особенно в узком домене и собственно статья про это.
2) MMLU и MMLU-Pro это база, про них много написано, конечно их и некоторые кодинг бенчи нужно добавлять для оценки кибербезных LLM. HLE я к таким, кстати, не отношу, слишком специфичный там набор задач.
3) Да, CyberGym выглядит неплохо, отличное дополнение. Кстати не только Антропик, китайцы тоже не отстают https://z.ai/blog/glm-5.1
4) Все так! Есть даже отдельный бенчмарк про это https://metr.org/ . Именно поэтому сейчас многое упирается в harness engineering.
На одну таску дефолтно аллоцируется 1 cpu, поэтому число ядер на экзекьюторе в вашем кейсе может влиять только на то сколько тасок параллельно он исполняет внутри одной джобы.
И вот этот простой сводится к минимуму при параллельном запуске методов - почти в любой момент времени найдётся куда утилизировать временно освобождающиеся ядра.
Согласен, все так
Приложение запросило и получило 100 ядер, Yarn скорее всего не отдаст эти ядра ни при последовательном, ни при параллельном выполнении.
Легко отдаст если они будут простаивать. Другое дело, что возвращать их для жирного стейджа внутри таски - дополнительные накладные расходы, избежав которых в схеме с параллельным исполнением можно и получить тот самый профит.
Стоит отметить, что проведение экспериментов в высококонкурентной среде, коим является Hadoop-кластер, - это то ещё удовольствие. Каждый тестовый запуск не похож на предыдущий, т.к. постоянно кто-то ещё что-то считает. И мой i-ый тестовый запуск может получить ресурсов меньше/больше, чем i-1. Также скорость получения ресурсов неодинаковая: можно со старта получить 100 ядер, а можно эти 100 ядер добирать на протяжении долгого времени.
Для таких целей можно зафиксировать ресурсы за вашим приложением c помощью spark.executor.instances
Во-вторых, кажется, что для одной задачи прирост производительности от увеличения количества ядер не является линейным, а постепенно замедляется. Таким образом, большей эффективности получается добиться от параллельного запуска нескольких методов.
По умолчанию обычно одна таска = 1 ядро. Параллелизм на уровне экзекьютора зависит от параметров, которые вы указали в sparkConf.
В итоге подход с параллельным выполнением методов всегда превосходил последовательный. В самом худшем раскладе параллельное выполнение на 40% быстрее. В самом лучшем - когда сошлись все звёзды - получалось 3х-кратное превосходство. Если взять средние показатели для целевого времени расчёта признаков (раннее утро), то параллельный подход выигрывает примерно в 2 раза.
В статье Cloudera немножко не про то говорят: там основная мысль в том, что бОльшее число партиций даст возможность разбросать таски по бОльшему числу экзекьюторов. В вашем случае прирост скорее всего в том, что в жирных подтасках утилизация экзекьюторов неравномерная и RM скорее всего успевал их забирать под нужды других задач. То есть тут прирост скорее всего только в том, что вы забрали ресурсы кластера под свои задачи и остальные стали работать чуть медленнее :)
Вы уровнем OSI промахнулись. OFDM это физический уровень и в WiFi он, конечно, есть. А CSMA-CA просто обеспечивает проверку чистоты эфира, чтобы не словить помеху по всей полосе при передаче и это уровень канальный.
А я всё мечтаю добраться и сделать какой-то семантический анализ заголовков и содержания новостей Ленты, чтобы подтвердить или опровергнуть своё личное ощущение по поводу сильно упавшего качества её контента за последние годы.
Возможно стоило чуть по-другому оформить разбивку по рубрикам, т.к. субъективно она выглядит плохо читаемой.
Спасибо за системный и детализированный отчет о мероприятии. Особенно интересно читать о том, как комбинации известных методов анализа фомируют конечные бизнес-решения.
Спасибо за содержательный комментарий!
1) Все так. Но дать срез времени все равно полезно, особенно в узком домене и собственно статья про это.
2) MMLU и MMLU-Pro это база, про них много написано, конечно их и некоторые кодинг бенчи нужно добавлять для оценки кибербезных LLM. HLE я к таким, кстати, не отношу, слишком специфичный там набор задач.
3) Да, CyberGym выглядит неплохо, отличное дополнение. Кстати не только Антропик, китайцы тоже не отстают https://z.ai/blog/glm-5.1
4) Все так! Есть даже отдельный бенчмарк про это https://metr.org/ . Именно поэтому сейчас многое упирается в harness engineering.
Ждем :)
На одну таску дефолтно аллоцируется 1 cpu, поэтому число ядер на экзекьюторе в вашем кейсе может влиять только на то сколько тасок параллельно он исполняет внутри одной джобы.
Согласен, все так
Легко отдаст если они будут простаивать. Другое дело, что возвращать их для жирного стейджа внутри таски - дополнительные накладные расходы, избежав которых в схеме с параллельным исполнением можно и получить тот самый профит.
Для тестов можно просто поставить нужное число initialExecutors и он не будет добирать
Для таких целей можно зафиксировать ресурсы за вашим приложением c помощью spark.executor.instances
По умолчанию обычно одна таска = 1 ядро. Параллелизм на уровне экзекьютора зависит от параметров, которые вы указали в sparkConf.
В статье Cloudera немножко не про то говорят: там основная мысль в том, что бОльшее число партиций даст возможность разбросать таски по бОльшему числу экзекьюторов. В вашем случае прирост скорее всего в том, что в жирных подтасках утилизация экзекьюторов неравномерная и RM скорее всего успевал их забирать под нужды других задач. То есть тут прирост скорее всего только в том, что вы забрали ресурсы кластера под свои задачи и остальные стали работать чуть медленнее :)
Отличная статья, спасибо!
Очень круто! Спасибо!
Не совсем по теме, но близко была хорошая статья feriat с аналитикой по Медузе.
Возможно стоило чуть по-другому оформить разбивку по рубрикам, т.к. субъективно она выглядит плохо читаемой.
Спасибо за статью и датасет.
Есть ли у персональные лицензии?