AMD ROCm Непрерывная интеграция

В этом документе описывается реализация системы непрерывной интеграции (CI) AMD ROCm. Он охватывает рабочий процесс GitHub Actions, пул исполнителей, контейнеры Docker, конфигурации Bazel, фильтры тегов, блокировку GPU и взаимосвязь между исходным проектом и форком ROCm/xla .

Данная конфигурация включает два различных пути:

1. Рабочий процесс ROCm CI ( .github/workflows/rocm_ci.yml ): Запускает физические тесты XLA и JAX на самостоятельно размещенном графическом процессоре AMD Instinct.
2. ROCm CI только для компиляции ( .github/workflows/ci.yml ): Собирает XLA с использованием герметичного набора инструментов ROCm на стандартном Linux x86-сервере без графического процессора.

Эти пути обеспечивают как проверку во время выполнения на оборудовании, так и надежность компиляции при каждом коммите.

Триггеры и параллельное выполнение

rocm_ci.yml работает на:

• pull_request against main (задание jax дополнительно привязано к github.base_ref == 'main' ).
• workflow_dispatch (manual).

Путь ROCm, выполняемый только в режиме компиляции и расположенный в ci.yml запускается при тех же событиях pull_request , что и остальная часть матрицы CI, а также после отправки запроса.

Оба рабочих процесса используют общую группу параллельного выполнения, ключом которой является рабочий процесс + ссылка на заголовок, поэтому новая отправка изменений в запрос на слияние отменяет все выполняющиеся в этом запросе на слияние запуски, но не отменяет запуски в main :

concurrency:
  group: ${ { github.workflow } }-${ { github.head_ref || github.ref } }
  cancel-in-progress: ${ { github.ref != 'main' } }

Права доступа ограничены contents: read . Запись и загрузка артефактов запрещены.

Конфигурация исполнителя и контейнера

Пул бегунов

Для выполнения заданий ROCm используется саморазмещенный раннер GitHub Actions с меткой linux-x86-64-1gpu-amd . Это хост на базе Linux x86_64 с одной подключенной видеокартой AMD Instinct, в настоящее время ориентированный на gfx950 . Метка указывает на принадлежащий AMD парк раннеров RBE, где выполняются сборка и тесты. Состояние этого кластера можно отслеживать на этой панели мониторинга.

Образ Docker

Задания выполняются в контейнере Docker. Образ Docker предоставлен компанией AMD и создан на основе официальных образов сборки TensorFlow.

Основные моменты:

• --device=/dev/kfd и --device=/dev/dri предоставляют контейнеру доступ к драйверу ядра AMD GPU Fusion и узлам рендеринга DRI. Без них контейнер не сможет увидеть графический процессор.
• --group-add video добавляет пользователя контейнера в группу video , что является общепринятой практикой в ​​Ubuntu для пользователей, имеющих доступ к узлам с графическими процессорами.
• --ipc=host и --shm-size=64G необходимы, поскольку коллективные процессы HIP/ROCm (RCCL) и несколько путей выполнения потоков используют общую память для межпроцессного взаимодействия на одном узле.
• --cap-add=SYS_PTRACE и --security-opt=seccomp=unconfined позволяют тестовым исполняемым файлам, инструментированным для проверки работоспособности санитайзера, подключать отладчики и обходить фильтры seccomp, которые блокируют вызовы санитайзера во время выполнения.
• --tmpfs /root/.cache/bazel:rw,exec,size=80g помещает дисковый кэш Bazel в оперативную память. exec обязателен, поскольку Bazel запускает исполняемые файлы bazel-out непосредственно из кэша.
• Два файла ci-cert.* смонтированные из каталога /data на хосте, содержат клиентский TLS-сертификат и закрытый ключ, используемые для аутентификации в удаленном кластере сборки EngFlow.

Топология заданий

rocm_ci.yml определены три задачи:

После завершения работы rocm-config jax и xla запускаются параллельно.

Задача xla не привязана к параметру github.base_ref == 'main' ; задача jax привязана. Это означает, что набор задач JAX запускается только для запросов на слияние, ориентированных на main , в то время как набор задач XLA запускается для любого запроса на слияние плюс workflow_dispatch .

timeout-minutes устанавливается на уровне задания, при этом значение timeout-minutes: 60 (XLA с одним графическим процессором, JAX) или 80 (XLA с набором заданий для ЦП) на каждом этапе тестирования.

задание XLA CI

Последовательность шагов

1. Ознакомьтесь с репозиторием openxla/xla в разделе PR.
2. Загрузите скрипт драйвера, поддерживаемый AMD ( execute_ci_build_upstream.sh ), из форка ROCm/xla .
3. Выводит информацию о процессоре ( lscpu ) и графическом процессоре ( rocminfo ) для отладки.
4. Запустите этапы тестирования (на одном графическом процессоре и на центральном процессоре), используя загруженный скрипт.

Что означают --config=ci_single_gpu и --config=ci_rocm_cpu

Эти параметры определены в build_tools/rocm/rocm_xla.bazelrc . Тест для одной видеокарты использует параллельный вспомогательный модуль для GPU, повторяет попытки запуска тестов три раза и выполняет тесты в изолированном режиме. Тест для ЦП использует локальный параллелизм шириной 200 и обертку санитайзера:

build:ci_single_gpu --run_under=//build_tools/rocm:parallel_gpu_execute
build:ci_single_gpu --flaky_test_attempts=3

build:ci_rocm_cpu --run_under=//build_tools/rocm:sanitizer_wrapper
build:ci_rocm_cpu --local_test_jobs=200
build:ci_rocm_cpu --strategy=TestRunner=local

Третий параметр конфигурации, ci_multi_gpu , присутствует в файле bazelrc, но в настоящее время не запускается из rocm_ci.yml — он используется автономной вспомогательной программой run_xla_multi_gpu.sh на хостах с ≥4 графическими процессорами.

Фильтрация по тегам

execute_ci_build_upstream.sh (в форке ROCm/xla ) формирует список фильтров тегов, используя вспомогательную функцию build_tools/rocm/rocm_tag_filters.sh . Устаревшая встроенная оболочка build_tools/rocm/run_xla_ci_build.sh демонстрирует тот же шаблон:

TAG_FILTERS=$($SCRIPT_DIR/rocm_tag_filters.sh)
for arg in "$@"; do
    if [[ "$arg" == "--config=ci_multi_gpu" ]]; then
        TAG_FILTERS="${TAG_FILTERS},requires-gpu-rocm,requires-gpu-amd,multi_gpu"
    fi
    if [[ "$arg" == "--config=ci_single_gpu" ]]; then
        TAG_FILTERS="${TAG_FILTERS},requires-gpu-rocm,requires-gpu-amd,-multi_gpu"
    fi
    if [[ "$arg" == "--config=ci_rocm_cpu" ]]; then
        TAG_FILTERS="${TAG_FILTERS},gpu,-requires-gpu-rocm,-requires-gpu-amd"
    fi
done

Базовый список из rocm_tag_filters.sh содержит пункты, которые ROCm CI никогда не должен пытаться выполнить:

-no_gpu
-requires-gpu-intel
-requires-gpu-nvidia
-requires-gpu-cuda
-cuda-only
-oneapi-only
-requires-gpu-sm60
-requires-gpu-sm60-only
-requires-gpu-sm70
-requires-gpu-sm70-only
-requires-gpu-sm80
-requires-gpu-sm80-only
-requires-gpu-sm86
-requires-gpu-sm86-only
-requires-gpu-sm89
-requires-gpu-sm89-only
-requires-gpu-sm90
-requires-gpu-sm90-only
-skip_rocprofiler_sdk
-no_oss
-oss_excluded
-oss_serial

Добавление параметров для каждой конфигурации затем сужает набор:

Тесты, исключенные по названию.

Для выполнения коллективных операций, распространения шардинга и распределенного PJRT требуется несколько графических процессоров AMD, и они исключаются из запусков на одном графическом процессоре. Эти операции должны выполняться на выделенном хосте с несколькими графическими процессорами.

Задание JAX CI

Задание JAX выполняется в том же контейнере, но с другим скриптом драйвера, предоставляемым самим JAX:

./ci/run_bazel_test_rocm_rbe.sh \
  --override_repository=xla="${GITHUB_WORKSPACE}" \
  --override_module=xla="${GITHUB_WORKSPACE}" \
  --config=single_gpu \
  --//jax:build_jaxlib=wheel \
  --//jax:build_jax=true \
  --local_test_jobs=1 \
  --action_env=JAX_ENABLE_X64=0 \
  --repo_env=HERMETIC_PYTHON_VERSION=3.14 \
  --repo_env=TF_ROCM_RBE_DOCKER_IMAGE="${DOCKER_IMAGE}"

Подробности о флаге:

• --override_repository=xla=... и --override_module=xla=... перенаправляют зависимость xla в JAX на встроенный репозиторий запроса на слияние. Без них задание JAX будет компилироваться с использованием закрепленного коммита XLA, записанного в файле WORKSPACE/MODULE.bazel, что сводит на нет смысл запуска JAX из запроса на слияние XLA.
• --//jax:build_jaxlib=wheel и --//jax:build_jax=true собирают jaxlib как артефакт wheel и пересобирают сам jax из исходного кода — именно так JAX в настоящее время инициализирует расширение C++ для тестов.
• HERMETIC_PYTHON_VERSION=3.14 герметично выбирает цепочку инструментов Python (сборка воспроизводится независимо от используемой версии Python на хост-системе).
• --local_test_jobs=1 позволяет снизить конкуренцию за ресурсы графического процессора; при наличии только одного графического процессора AMD на исполнителе нет смысла запускать тесты JAX параллельно.
• JAX_ENABLE_X64=0 соответствует стандартной конфигурации тестирования команды JAX для быстрой непрерывной интеграции.
• Тот же самый TF_ROCM_RBE_DOCKER_IMAGE передается дальше, чтобы любой удаленный рабочий процесс, который сборка арендует у EngFlow, использовал один и тот же образ ROCm.

Удаленное выполнение сборки (EngFlow)

ROCm CI использует кластер удалённой сборки EngFlow ( grpcs://wardite.cluster.engflow.com ) как для удалённого кэширования, так и для удалённого выполнения. Конфигурация находится в build_tools/rocm/rocm_xla.bazelrc .

Аутентификация в этом кластере осуществляется с помощью смонтированных сертификатов ( /data/ci-cert.crt , /data/ci-cert.key ).

Основные параметры конфигурации:

• REMOTE_GPU_TESTING=1 : Включает оптимизацию удаленного выполнения (например, ограниченный доступ к файловой системе).
• @local_config_rocm//rocm:linux_x64 : Указывает платформу, предполагая установку ROCm на системном уровне на рабочих узлах для разрешения репозитория @local_config_rocm .

Существует также конфигурация rocm_rbe_dynamic , которая выполняет сборку локально, но тестируется с использованием динамического планировщика Bazel (выполняя каждое тестовое действие одновременно локально и удаленно, выбирая то, которое завершится первым):

build:rocm_rbe_dynamic --config=rocm_rbe
build:rocm_rbe_dynamic --spawn_strategy=local
test:rocm_rbe_dynamic --experimental_spawn_scheduler
test:rocm_rbe_dynamic --strategy=TestRunner=dynamic
test:rocm_rbe_dynamic --dynamic_mode=default
test:rocm_rbe_dynamic --dynamic_local_strategy=worker,standalone,local
test:rocm_rbe_dynamic --dynamic_remote_strategy=remote
test:rocm_rbe_dynamic --experimental_local_execution_delay=1000
test:rocm_rbe_dynamic --local_resources=cpu=HOST_CPUS*0.5

В шаге XLA для одной видеокарты в rocm_ci.yml используется, по сути, этот подход: --internal_spawn_scheduler --strategy=TestRunner=dynamic передается непосредственно в командной строке поверх --config=rocm_rbe .

Третий «общий» конфигурационный файл, rocm_ci , загружается следующим образом:

# rocm_xla_ci.bazelrc
try-import /usertools/rocm.bazelrc
try-import %workspace%/build_tools/rocm/rocm_xla.bazelrc

Файл /usertools/rocm.bazelrc предоставляется образом Docker, собранным AMD (он кодирует пути установки ROCm на хосте); встроенный в дерево образ bazelrc накладывается поверх него. Таким образом, --config=rocm_ci означает «использовать встроенный в образ набор инструментов ROCm плюс встроенные в дерево конфигурации XLA».

Блокировка графического процессора

Когда на хосте AMD запускается тест графического процессора, Bazel вызывает его с помощью --run_under=//build_tools/rocm:parallel_gpu_execute . Скрипт ( build_tools/rocm/parallel_gpu_execute.sh ) выполняет три действия:

1. Чтобы узнать, сколько видеокарт на самом деле есть у бегуна, вызовите rocminfo и подсчитайте количество строк в строке Name: *gfx* .

   ROCMINFO=$(find -L "${TEST_SRCDIR:-.}" -name "rocminfo" -path "*/bin/rocminfo" | head -n 1)
   TF_GPU_COUNT=$($ROCMINFO | grep "Name: *gfx*" | wc -l)
   

   rocminfo добавляется в исполняемые файлы действия через data = ["//tensorflow/third_party/rocm/google:rocminfo"] в целевом объекте Bazel в build_tools/rocm/BUILD , поэтому его можно обнаружить внутри песочницы удаленного выполнения.

2. Если TF_GPU_COUNT == 0 (например, в пуле RBE по умолчанию, в котором нет GPU), скрипт просто exec "$@" — тест всё равно запускается, но без какой-либо изоляции для каждого GPU. Ожидается, что тесты, действительно требующие GPU, будут завершаться с ошибкой; эта ветка существует для того, чтобы тесты с меткой GPU, которые фактически могут выполняться на CPU, всё равно запускались на дешёвых рабочих процессах.

3. В противном случае, получите слот на основе flock , по одному на каждую пару (gpu, slot_within_gpu) , и экспортируйте CUDA_VISIBLE_DEVICES и HIP_VISIBLE_DEVICES в этот индекс GPU на время проведения теста:

   for j in `seq 0 $((TF_TESTS_PER_GPU-1))`; do
     for i in `seq 0 $((TF_GPU_COUNT-1))`; do
       exec {lock_fd}>/var/lock/gpulock${i}_${j} || exit 1
       if flock -n "$lock_fd"; then
         (
           export CUDA_VISIBLE_DEVICES=$i
           export HIP_VISIBLE_DEVICES=$i
           "$TEST_BINARY" "$@"
         )
         …
       fi
     done
   done
   

Заполнение слотов происходит последовательно на всех графических процессорах (например, сначала слот 0 на всех графических процессорах, затем слот 1), чтобы минимизировать конкуренцию за память перед её переподпиской.

Практически идентичная копия находится в build_tools/ci/parallel_gpu_execute.sh , это ориентированная на CUDA версия, используемая заданиями NVIDIA. Основное различие заключается в том, что версия ROCm фактически обращается к rocminfo во время выполнения, тогда как версия CUDA по умолчанию доверяет TF_GPU_COUNT=4 .

Второй вспомогательный скрипт, //build_tools/rocm:sanitizer_wrapper , используется ci_rocm_cpu и ci_multi_gpu . Это небольшой сгенерированный скрипт оболочки ( echo '#!/bin/bash' > $@; echo 'exec "$$@"' >> $@ ), единственная задача которого — объявить списки игнорируемых элементов санитайзера в качестве исполняемых файлов, чтобы изменения в этих списках игнорирования заставляли соответствующие тестовые действия перезапускаться.

Независимые помощники

Три скрипта в build_tools/rocm/ предназначены для ручного запуска на локальной машине AMD и следуют тем же правилам, что и CI:

• run_xla.sh — тест XLA на одной видеокарте. Определяет количество видеокарт с помощью rocm-smi , вычисляет N_TEST_JOBS = TF_GPU_COUNT * TF_TESTS_PER_GPU , извлекает идентификатор gfx* из rocminfo для установки TF_ROCM_AMDGPU_TARGETS и запускает bazel test --config=rocm_ci --config=xla_sgpu … с аналогичным алгоритмом фильтрации тегов, как в CI (хотя они немного отличаются в деталях реализации). Использует --run_under=//build_tools/ci:parallel_gpu_execute (обертка в стиле CUDA).
• run_xla_multi_gpu.sh — многопроцессорный тест XLA. Требует TF_GPU_COUNT ≥ 4 , в противном случае завершается без уведомления. Использует --config=xla_mgpu , устанавливает NCCL_MAX_NCHANNELS=1 и, что примечательно, не проходит --run_under=//build_tools/ci:parallel_gpu_execute — коллективные тесты должны видеть все графические процессоры одновременно, поэтому привязка каждого графического процессора к отдельному тесту приведет к их сбою.
• run_xla_ci_build.sh — это устаревшая версия скрипта, который CI теперь получает из ROCm/xla . Полезен в качестве документации по тому, как аргументы --config=… сопоставляются с фильтрами тегов.

Эти три функции предназначены для разработчиков AMD, воспроизводящих поведение CI локально.

ROCm CI только для компиляции

Вне зависимости от используемого GPU-сервера, .github/workflows/ci.yml запускает задачу XLA Linux x86 GPU ROCm на стандартном Linux x86-сервере без GPU и без установленной системы ROCm. Это обеспечивает надежность компиляции для всех запросов на слияние независимо от доступности GPU-сервера.

Для выполнения этой задачи используются следующие ресурсы и контейнер:

{
  pool: "linux-x86-n2-16",
  container: "us-docker.pkg.dev/ml-oss-artifacts-published/ml-public-container/ml-build:latest",
  name: "XLA Linux x86 GPU ROCm",
  repo: "openxla/xla",
}

Одна запись в матрице; нет --device=/dev/kfd ; нет томов сертификатов AMD. Задание отправляется в build_tools/ci/build.py , который является драйвером конфигурации как данных, используемым для каждой второй записи в матрице CI:

- run: |
    "$GITHUB_WORKSPACE"/openxla/xla/build_tools/ci/build.py \
      --build="${ { matrix.job_info.name } }_github_actions"

Сборка XLA_LINUX_X86_GPU_ROCM_GITHUB_ACTIONS определена в build_tools/ci/build.py следующим образом:

Build(
    type_=BuildType.XLA_LINUX_X86_GPU_ROCM_GITHUB_ACTIONS,
    repo="openxla/xla",
    configs=("warnings", "rbe_linux_cpu", "rocm_clang_hermetic"),
    target_patterns=_XLA_DEFAULT_TARGET_PATTERNS,
    build_tag_filters=rocm_tag_filter,
    test_tag_filters=rocm_tag_filter,
    options={**_DEFAULT_BAZEL_OPTIONS, "//xla/tsl:ci_build": True},
    subcommand="build",
)

Детали конфигурации:

• subcommand="build" — тесты не запускаются.
• configs=("warnings", "rbe_linux_cpu", "rocm_clang_hermetic") — сборка использует пул RBE для ЦП (рабочие процессы на ГП не требуются) и конфигурацию rocm_clang_hermetic , которая подключает герметичный набор инструментов ROCm + Clang, а не зависит от наличия /opt/rocm .
• Параметр rocm_tag_filter повторяет набор фильтров времени выполнения, используемый в файле rocm_ci.yml , плюс явное включение параметра "gpu" , поскольку скрипт rocm_tag_filters.sh не находится в области видимости build.py .

build.py это всего лишь фабрика, использующая конфигурацию в качестве данных: он генерирует три команды Bazel для каждой сборки — dry-run ( --nobuild ) retry, real build и bazel analyze-profile profile.json.gz :

def commands(self) -> List[List[str]]:
    cmds = []
    cmds.extend(self.extra_setup_commands)
    if not (macos_build or windows_build):
      cmds.append(retry(self.bazel_command(subcommand="build",
                                           extra_options=("--nobuild",))))
    cmds.append(self.bazel_command(subcommand=self.subcommand))
    cmds.append(["bazel", "analyze-profile", "profile.json.gz"])
    return cmds

Шаблон "пробный запуск - затем сборка" позволяет повторять попытки при временных ошибках загрузки пакетов без пересборки.

На этом этапе гарантируется обнаружение регрессий компиляции даже в случае недоступности средств выполнения на графических процессорах.

Поддержка дезинфицирующих средств

build_tools/rocm/rocm_xla.bazelrc также объявляет конфигурации ASan и TSan:

build:tsan --strip=never
build:tsan --copt -fsanitize=thread
build:tsan --copt -g
build:tsan --copt -fno-omit-frame-pointer
build:tsan --linkopt -fsanitize=thread
build:tsan --linkopt -g
build:tsan --//build_tools/rocm:sanitizer=tsan
build:tsan --test_env=TSAN_OPTIONS=suppressions=build_tools/rocm/tsan_ignore_list.txt:…
build:tsan --run_under=//build_tools/rocm:sanitizer_wrapper

build:asan --test_env=ASAN_OPTIONS=suppressions=build_tools/rocm/asan_ignore_list.txt:use_sigaltstack=0
build:asan --test_env=LSAN_OPTIONS=suppressions=build_tools/rocm/lsan_ignore_list.txt:use_sigaltstack=0
build:asan --//build_tools/rocm:sanitizer=asan
build:asan --run_under=//build_tools/rocm:sanitizer_wrapper

Строковый флаг //build_tools/rocm:sanitizer используется функцией select({"asan": [...], "tsan": [...]}) в группе файлов sanitizer_wrapper для добавления соответствующего файла подавления в исполняемые файлы тестового действия.

В настоящее время файл rocm_ci.yml не использует эти параметры конфигурации; они доступны для произвольных вызовов и для последующих конвейеров обработки.

Последовательность выполнения

Типичный пример запроса на слияние, попавшего на openxla/xla :

PR commit
   │
   ├─► .github/workflows/ci.yml ───────────────► matrix of CPU/GPU/ROCm builds
   │       │
   │       └─► XLA Linux x86 GPU ROCm
   │             └─► build_tools/ci/build.py
   │                   └─► bazel build (nobuild → real)
   │                         configs: warnings + rbe_linux_cpu +
   │                                  rocm_clang_hermetic
   │                         tag filter: rocm_tag_filter (compile-only)
   │
   └─► .github/workflows/rocm_ci.yml ──────────► AMD GPU runner
           │
           ├─► rocm-config: pin Docker image digest
           │
           ├─► jax (1 GPU)
           │     └─► jax/ci/run_bazel_test_rocm_rbe.sh
           │           └─► bazel test --config=single_gpu …
           │                 override_module=xla=<this PR>
           │                 EngFlow RBE
           │
           └─► xla (1 GPU)
                 ├─► wget execute_ci_build_upstream.sh from ROCm/xla
                 ├─► bazel test --config=rocm_ci --config=rocm_rbe
                 │                --config=ci_single_gpu
                 │       (dynamic scheduling, parallel_gpu_execute lock,
                 │        flock per CUDA_VISIBLE_DEVICES, 3 retries)
                 └─► bazel test --config=rocm_ci --config=rocm_rbe
                                --config=ci_rocm_cpu
                         (200-way local, sanitizer_wrapper, no GPU
                          required but exercises GPU-tagged tests on CPU)

Если что-нибудь не поможет:

• Bazel выводит ссылку EngFlow ( <a href="https://wardite.cluster.engflow.com/invocation/">https://wardite.cluster.engflow.com/invocation/</a><UUID> ); это каноническое место для просмотра журналов действий, попаданий в кэш и стандартного вывода для каждого теста.
• Данные профилирования сохраняются в файл /tf/pkg/profile.json.gz (этот путь жестко задан в скриптах AMD; контейнер --tmpfs плюс каталог /tf/pkg — это место, куда Bazel записывает данные о времени выполнения для bazel analyze-profile ).
• Вывод команд lscpu и rocminfo находится в начале каждого лога задания, и этого часто достаточно, чтобы определить, "действительно ли графический процессор виден контейнеру".

Техническое обслуживание и обновления

Типичные правки и где их вносить:

Изменение в файле build.py должно сопровождаться перегенерацией build_tools/ci/golden_commands.txt (в файле readme объясняется, как это сделать: PYTHONDONTWRITEBYTECODE=1 python3 build.py --dump_commands > golden_commands.txt ). «Золотые» команды — это документация, а не требование соблюдения правил — CI не сравнивает их с рецензируемыми версиями, — но рецензенты читают их, чтобы увидеть реализованные командные строки.

Ссылки

• Рабочие процессы: .github/workflows/rocm_ci.yml , .github/workflows/ci.yml
• Специфические для ROCm скрипты и bazelrc: build_tools/rocm/
• Общий драйвер CI: build_tools/ci/build.py
• Вспомогательная функция для фильтрации тегов: build_tools/rocm/rocm_tag_filters.sh
• Вспомогательные функции для блокировки графического процессора: build_tools/rocm/parallel_gpu_execute.sh , build_tools/ci/parallel_gpu_execute.sh
• Списки игнорирования Sanitizer: build_tools/rocm/{asan,lsan,tsan}_ignore_list.txt
• Скрипт драйвера upstream-fork (внешний): ROCm/xla в ветке rocm-dev-infra , файл build_tools/rocm/execute_ci_build_upstream.sh
• Кластер EngFlow (RBE + BES): grpcs://wardite.cluster.engflow.com