Учить что либо на более 10 нодах сложно. Уже начинает влиять топология кластера, падает MFU, отваливаются ноды и так далее, на лету выкидывать ноды из обучения сложно. Скорость интернета внутри датацентра одинаковая только в теории.
В целом любое массивное обучение на сотнях и тысячах нод это очень сложно, затратно и инженерно.

В первые вижу в паблике подробный блогпост про оптимизацию network level для обучения на 4к h100.

Блогпост

Навеяно мыслями после прочтения этой статьи 👆

Если вы при исследовании сайта натыкаетесь на минифицированные фрагменты JavaScript, созданные результатом работы таких инструментов, как Webpack или Vite, вы можете их «unminify»-нуть с помощью сервисов, например, beautifier.io. После этого их можно прогнать через Semgrep.

Это даёт весьма полезные и интересные результаты, особенно при black или grey box тестировании. Однако после процедуры «unminify» вы можете получить JS-файл размером в несколько мегабайт. При анализе таких файлов Semgrep может выдавать ошибки из-за ограничений на размер файла и времени выполнения правил.

Чтобы обойти эти ограничения, необходимо указать три параметра при запуске Semgrep:

1. --max-target-bytes=0 
   Устанавливает максимальный размер файла для
сканирования Semgrep, например, 1.5MB.
   Любые файлы, превышающие этот размер,
будут проигнорированы.
   Нулевое или отрицательное значение
отключает этот фильтр. 
   По умолчанию: 1 000 000 байт.

2. --timeout-threshold 0 
   Задаёт максимальное количество правил,
   которые могут истечь по времени при обработке файла,
   прежде чем файл будет пропущен.
   Если установить значение 0, лимит отсутствует.
   По умолчанию: 3 правила.

3. --timeout 0 
   Устанавливает максимальное время в секундах для
выполнения одного правила на отдельном файле.
   Если установить значение 0, лимит времени отсутствует. 
   По умолчанию: 5.0 секунд.

В итоге команда запуска Semgrep будет выглядеть следующим образом:

semgrep scan --config auto . --sarif-output results.sarif --max-target-bytes=5MB --timeout-threshold 0 --timeout 0

В данном примере экспортируем результаты в формате SARIF💡 с помощью параметра --sarif-output  для удобства дальнейшего анализа, используя Visual Studio Code и один из следующих плагинов:

- SARIF Viewer от Microsoft
- SARIF Explorer от Trail of Bits

💡 SARIF (Static Analysis Results Interchange Format) — это открытый стандарт для обмена результатами статического анализа кода. Он разработан для облегчения интеграции различных инструментов статического анализа с системами управления кодом и процессами разработки.

Получаем вот такую красоту 👇

Gitlabcis: анализ GitLab на соответствие CIS

Всем привет!

Недавно GitLab представили собственную разработку – Gitlabcis.

Как нетрудно понять из названия он используется для того, чтобы проверять корректность конфигураций GitLab на соответствие одноименному CIS Benchmark.

Просто устанавливается, легко конфигурируется и быстро работает!

Из возможностей хотелось бы отметить:
🍭 Выдача результатов содержит Reason, в которой указано, почему настройка (не) соответствует требованиям
🍭 Есть возможность получения рекомендаций о том, как и что можно поправить (вплоть до «откройте XXX, выберите YYY и нажмите ZZZ)

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

Больше подробностей, как обычно, в repo проекта и в официальной документации. А если вам хочется узнать roadmap развития утилиты, то он есть в статье из поста 😊

OpenDiLoCo: An Open-Source Framework for Globally Distributed Low-Communication Training

Обучение multidatacenter сеток все еще большая и сложная штука, для начала стоит понимать что
- скорость интернета не однородна
- на больших расстояниях могут копится ошибки
- пропускная способность сети может быть недостаточной

собственно большой папир и репа про то как учить в ОЧЕНЬ распределенном сетапе
блогпост от авторов имплементации