Pytorch Fsdp

Экспертное руководство по Fully Sharded Data Parallel обучению с PyTorch FSDP — шардирование параметров, смешанная точность, выгрузка на CPU, FSDP2

Метаданные навыка

Источник	Опционально — установка с помощью vibeos skills install official/mlops/pytorch-fsdp
Путь	optional-skills/mlops/pytorch-fsdp
Версия	1.0.0
Автор	Orchestra Research
Лицензия	MIT
Зависимости	torch>=2.0, transformers
Платформы	linux, macos
Теги	Distributed Training, PyTorch, FSDP, Data Parallel, Sharding, Mixed Precision, CPU Offloading, FSDP2, Large-Scale Training

Справочник: полный SKILL.md

к сведению

Ниже приведено полное определение навыка, которое VibeOS загружает при активации этого навыка. Это то, что агент видит в качестве инструкций, когда навык активен.

Навык Pytorch-Fsdp

Всесторонняя помощь в разработке с pytorch-fsdp, сгенерированная на основе официальной документации.

Когда использовать этот навык

Этот навык следует активировать, когда:

• Вы работаете с pytorch-fsdp
• Вы задаёте вопросы о функциях или API pytorch-fsdp
• Вы реализуете решения на pytorch-fsdp
• Вы отлаживаете код pytorch-fsdp
• Вы изучаете лучшие практики pytorch-fsdp

Краткий справочник

Распространённые паттерны

Паттерн 1: Generic Join Context Manager# Создан: 06 июня 2025 | Последнее обновление: 06 июня 2025 Generic join context manager упрощает распределённое обучение на неравномерных входных данных. На этой странице описан API соответствующих классов: Join, Joinable и JoinHook. Учебное пособие см. в разделе Distributed Training with Uneven Inputs Using the Join Context Manager. class torch.distributed.algorithms.Join(joinables, enable=True, throw_on_early_termination=False, **kwargs)[source]# Этот класс определяет generic join context manager, который позволяет вызывать пользовательские хуки после того, как процесс присоединился. Эти хуки должны затенять коллективные коммуникации неприсоединившихся процессов, чтобы предотвратить зависание и ошибки, а также обеспечить алгоритмическую корректность. Подробности об определении хука см. в JoinHook. Предупреждение Контекстный менеджер требует, чтобы каждый участвующий Joinable вызывал метод notify_join_context() перед своими собственными коллективными коммуникациями на каждой итерации для обеспечения корректности. Предупреждение Контекстный менеджер требует, чтобы все атрибуты process_group в объектах JoinHook были одинаковыми. Если существует несколько объектов JoinHook, используется устройство первого из них. Информация о группе процессов и устройстве используется для проверки неприсоединившихся процессов и для уведомления процессов о необходимости выбросить исключение, если включён throw_on_early_termination, причём оба действия выполняются с помощью all-reduce. Параметры joinables (List[Joinable]) – список участвующих Joinable; их хуки перебираются в заданном порядке. enable (bool) – флаг, включающий обнаружение неравномерных входных данных; установка значения False отключает функциональность контекстного менеджера и должна использоваться только в том случае, если пользователь уверен, что входные данные не будут неравномерными (по умолчанию: True). throw_on_early_termination (bool) – флаг, управляющий тем, нужно ли выбрасывать исключение при обнаружении неравномерных входных данных (по умолчанию: False). Пример: >>> import os >>> import torch >>> import torch.distributed as dist >>> import torch.multiprocessing as mp >>> import torch.nn.parallel.DistributedDataParallel as DDP >>> import torch.distributed.optim.ZeroRedundancyOptimizer as ZeRO >>> from torch.distributed.algorithms.join import Join >>> >>> # На каждом порождённом рабочем процессе >>> def worker(rank): >>> dist.init_process_group("nccl", rank=rank, world_size=2) >>> model = DDP(torch.nn.Linear(1, 1).to(rank), device_ids=[rank]) >>> optim = ZeRO(model.parameters(), torch.optim.Adam, lr=0.01) >>> # Ранг 1 получает на один вход больше, чем ранг 0 >>> inputs = [torch.tensor([1.]).to(rank) for _ in range(10 + rank)] >>> with Join([model, optim]): >>> for input in inputs: >>> loss = model(input).sum() >>> loss.backward() >>> optim.step() >>> # Все ранги достигают этой точки без зависания/ошибок static notify_join_context(joinable)[source]# Уведомляет join context manager о том, что вызывающий процесс ещё не присоединился. Затем, если throw_on_early_termination=True, проверяет, были ли обнаружены неравномерные входные данные (т.е. если один процесс уже присоединился), и в этом случае выбрасывает исключение. Этот метод должен вызываться из объекта Joinable перед его собственными коллективными коммуникациями на каждой итерации. Например, он должен вызываться в начале прямого прохода в DistributedDataParallel. Только первый объект Joinable, переданный в контекстный менеджер, выполняет коллективные коммуникации в этом методе; для остальных этот метод не имеет эффекта. Параметры joinable (Joinable) – объект Joinable, вызывающий этот метод. Возвращает Асинхронный дескриптор работы для all-reduce, предназначенный для уведомления контекстного менеджера о том, что процесс ещё не присоединился, если joinable является первым, переданным в контекстный менеджер; в противном случае — None. class torch.distributed.algorithms.Joinable[source]# Определяет абстрактный базовый класс для joinable-классов. Joinable-класс (наследующий от Joinable) должен реализовывать join_hook(), который возвращает экземпляр JoinHook, а также join_device() и join_process_group(), возвращающие информацию об устройстве и группе процессов соответственно. abstract property join_device: device# Возвращает устройство, с которого будут выполняться коллективные коммуникации, необходимые join context manager. abstract join_hook(**kwargs)[source]# Возвращает экземпляр JoinHook для данного Joinable. Параметры kwargs (dict) – словарь, содержащий любые именованные аргументы для изменения поведения join hook во время выполнения; всем экземплярам Joinable, использующим один и тот же join context manager, передаётся одно и то же значение kwargs. Тип возвращаемого значения JoinHook abstract property join_process_group: Any# Возвращает группу процессов для коллективных коммуникаций, необходимых самому join context manager. class torch.distributed.algorithms.JoinHook[source]# Определяет join hook, который предоставляет две точки входа в join context manager. Точки входа: основной хук, который вызывается повторно, пока существует неприсоединившийся процесс, и пост-хук, который вызывается после того, как все процессы присоединились. Чтобы реализовать join hook для generic join context manager, определите класс, наследующий от JoinHook, и переопределите main_hook() и post_hook() по мере необходимости. main_hook()[source]# Вызывайте этот хук, пока существует неприсоединившийся процесс, чтобы затенять коллективные коммуникации на итерации обучения. Итерация обучения, т.е. один прямой проход, обратный проход и шаг оптимизатора. post_hook(is_last_joiner)[source]# Вызывайте хук после того, как все процессы присоединились. Ему передаётся дополнительный аргумент bool is_last_joiner, который указывает, является ли данный ранг одним из последних присоединившихся. Параметры is_last_joiner (bool) – True, если ранг является одним из последних присоединившихся; в противном случае False.

Join

Паттерн 2: Пакет распределённой связи — torch.distributed# Создан: 12 июля 2017 | Последнее обновление: 04 сентября 2025 Примечание Пожалуйста, обратитесь к PyTorch Distributed Overview для краткого введения во все функции, связанные с распределённым обучением. Бэкенды# torch.distributed поддерживает четыре встроенных бэкенда, каждый с разными возможностями. В таблице ниже показано, какие функции доступны для использования с CPU или GPU для каждого бэкенда. Для NCCL GPU означает CUDA GPU, а для XCCL — XPU GPU. MPI поддерживает CUDA только в том случае, если реализация, используемая для сборки PyTorch, поддерживает это. Бэкенд gloo mpi nccl xccl Устройство CPU GPU CPU GPU CPU GPU CPU GPU send ✓ ✘ ✓ ? ✘ ✓ ✘ ✓ recv ✓ ✘ ✓ ? ✘ ✓ ✘ ✓ broadcast ✓ ✓ ✓ ? ✘ ✓ ✘ ✓ all_reduce ✓ ✓ ✓ ? ✘ ✓ ✘ ✓ reduce ✓ ✓ ✓ ? ✘ ✓ ✘ ✓ all_gather ✓ ✓ ✓ ? ✘ ✓ ✘ ✓ gather ✓ ✓ ✓ ? ✘ ✓ ✘ ✓ scatter ✓ ✓ ✓ ? ✘ ✓ ✘ ✓ reduce_scatter ✓ ✓ ✘ ✘ ✘ ✓ ✘ ✓ all_to_all ✓ ✓ ✓ ? ✘ ✓ ✘ ✓ barrier ✓ ✘ ✓ ? ✘ ✓ ✘ ✓ Бэкенды, поставляемые с PyTorch# Пакет распределённой обработки PyTorch поддерживает Linux (стабильно), MacOS (стабильно) и Windows (прототип). По умолчанию для Linux бэкенды Gloo и NCCL собираются и включаются в состав PyTorch distributed (NCCL только при сборке с CUDA). MPI — это опциональный бэкенд, который можно включить только при сборке PyTorch из исходного кода (например, сборка PyTorch на хосте с установленным MPI). Примечание Начиная с PyTorch v1.8, Windows поддерживает все бэкенды коллективных коммуникаций, кроме NCCL. Если аргумент init_method функции init_process_group() указывает на файл, он должен соответствовать следующей схеме: Локальная файловая система, init_method="file:///d:/tmp/some_file" Общая файловая система, init_method="file://////{machine_name}/{share_folder_name}/some_file" Как и на платформе Linux, вы можете включить TcpStore, установив переменные окружения MASTER_ADDR и MASTER_PORT. Какой бэкенд использовать?# Раньше нас часто спрашивали: «Какой бэкенд мне следует использовать?» Эмпирическое правило Используйте бэкенд NCCL для распределённого обучения с CUDA GPU. Используйте бэкенд XCCL для распределённого обучения с XPU GPU. Используйте бэкенд Gloo для распределённого обучения с CPU. Хосты с GPU и межсоединением InfiniBand Используйте NCCL, так как это единственный бэкенд, который в настоящее время поддерживает InfiniBand и GPUDirect. Хосты с GPU и межсоединением Ethernet Используйте NCCL, так как он в настоящее время обеспечивает наилучшую производительность распределённого обучения на GPU, особенно для многопроцессорного одноузлового или многоузлового распределённого обучения. Если у вас возникли проблемы с NCCL, используйте Gloo в качестве запасного варианта. (Обратите внимание, что Gloo в настоящее время работает медленнее, чем NCCL для GPU.) Хосты с CPU и межсоединением InfiniBand Если ваш InfiniBand поддерживает IP over IB, используйте Gloo, в противном случае используйте MPI. Мы планируем добавить поддержку InfiniBand для Gloo в будущих релизах. Хосты с CPU и межсоединением Ethernet Используйте Gloo, если у вас нет особых причин использовать MPI. Распространённые переменные окружения# Выбор сетевого интерфейса# По умолчанию бэкенды NCCL и Gloo пытаются найти правильный сетевой интерфейс для использования. Если автоматически обнаруженный интерфейс неверен, вы можете переопределить его с помощью следующих переменных окружения (применимых к соответствующему бэкенду): NCCL_SOCKET_IFNAME, например export NCCL_SOCKET_IFNAME=eth0 GLOO_SOCKET_IFNAME, например export GLOO_SOCKET_IFNAME=eth0 Если вы используете бэкенд Gloo, вы можете указать несколько интерфейсов, разделив их запятой, например: export GLOO_SOCKET_IFNAME=eth0,eth1,eth2,eth3. Бэкенд будет распределять операции между этими интерфейсами по круговому принципу. Крайне важно, чтобы все процессы указывали одинаковое количество интерфейсов в этой переменной. Другие переменные окружения NCCL# Отладка — в случае сбоя NCCL вы можете установить NCCL_DEBUG=INFO, чтобы вывести явное предупреждающее сообщение, а также базовую информацию об инициализации NCCL. Вы также можете использовать NCCL_DEBUG_SUBSYS для получения более подробной информации о конкретном аспекте NCCL. Например, NCCL_DEBUG_SUBSYS=COLL выведет журналы коллективных вызовов, что может быть полезно при отладке зависаний, особенно вызванных несоответствием типа коллективной операции или размера сообщения. В случае сбоя обнаружения топологии будет полезно установить NCCL_DEBUG_SUBSYS=GRAPH для просмотра подробного результата обнаружения и сохранения его в качестве справки, если потребуется дальнейшая помощь от команды NCCL. Настройка производительности — NCCL выполняет автоматическую настройку на основе обнаружения топологии, чтобы избавить пользователей от необходимости ручной настройки. В некоторых системах на основе сокетов пользователи всё же могут попробовать настроить NCCL_SOCKET_NTHREADS и NCCL_NSOCKS_PERTHREAD для увеличения пропускной способности сети сокетов. Эти две переменные окружения были предварительно настроены NCCL для некоторых облачных провайдеров, таких как AWS или GCP. Полный список переменных окружения NCCL см. в официальной документации NVIDIA NCCL. Вы можете дополнительно настроить коммуникаторы NCCL с помощью torch.distributed.ProcessGroupNCCL.NCCLConfig и torch.distributed.ProcessGroupNCCL.Options. Узнайте больше о них, используя help (например, help(torch.distributed.ProcessGroupNCCL.NCCLConfig)) в интерпретаторе. Основы# Пакет torch.distributed предоставляет поддержку PyTorch и примитивы связи для многопроцессорного параллелизма на нескольких вычислительных узлах, работающих на одной или нескольких машинах. Класс torch.nn.parallel.DistributedDataParallel() основан на этой функциональности и обеспечивает синхронное распределённое обучение в качестве обёртки вокруг любой модели PyTorch. Это отличается от видов параллелизма, предоставляемых пакетом Multiprocessing package - torch.multiprocessing и torch.nn.DataParallel(), тем, что поддерживает несколько машин, соединённых сетью, и тем, что пользователь должен явно запускать отдельную копию основного обучающего скрипта для каждого процесса. В случае синхронной работы на одной машине torch.distributed или обёртка torch.nn.parallel.DistributedDataParallel() всё ещё могут иметь преимущества перед другими подходами к параллелизму данных, включая torch.nn.DataParallel(): Каждый процесс поддерживает свой собственный оптимизатор и выполняет полный шаг оптимизации на каждой итерации. Хотя это может показаться избыточным, поскольку градиенты уже были собраны и усреднены по процессам и, следовательно, одинаковы для каждого процесса, это означает, что этап широковещательной рассылки параметров не требуется, что сокращает время, затрачиваемое на передачу тензоров между узлами. Каждый процесс содержит независимый интерпретатор Python, что устраняет дополнительные накладные расходы на интерпретатор и «GIL-thrashing», возникающие при запуске нескольких потоков выполнения, реплик модели или GPU из одного процесса Python. Это особенно важно для моделей, которые активно используют среду выполнения Python, включая модели с рекуррентными слоями или множеством мелких компонентов. Инициализация# Пакет необходимо инициализировать с помощью функции torch.distributed.init_process_group() или torch.distributed.device_mesh.init_device_mesh() перед вызовом любых других методов. Обе функции блокируются до тех пор, пока все процессы не присоединятся. Предупреждение Инициализация не является потокобезопасной. Создание группы процессов должно выполняться из одного потока, чтобы предотвратить непоследовательное назначение «UUID» между рангами и предотвратить состояния гонки во время инициализации, которые могут привести к зависанию. torch.distributed.is_available()[source]# Возвращает True, если пакет распределённой обработки доступен. В противном случае torch.distributed не предоставляет никаких других API. В настоящее время torch.distributed доступен на Linux, MacOS и Windows. Установите USE_DISTRIBUTED=1, чтобы включить его при сборке PyTorch из исходного кода. В настоящее время значение по умолчанию — USE_DISTRIBUTED=1 для Linux и Windows, USE_DISTRIBUTED=0 для MacOS. Тип возвращаемого значения bool torch.distributed.init_process_group(backend=None, init_method=None, timeout=None, world_size=-1, rank=-1, store=None, group_name='', pg_options=None, device_id=None)[source]# Инициализирует группу процессов по умолчанию. Это также инициализирует пакет распределённой обработки. Существует 2 основных способа инициализации группы процессов: Явно указать store, rank и world_size. Указать init_method (строку URL), которая указывает, где/как обнаруживать пиров. Дополнительно указать rank и world_size или закодировать все необходимые параметры в URL и опустить их. Если не указано ни то, ни другое, init_method считается равным «env://». Параметры backend (str или Backend, optional) – Используемый бэкенд. В зависимости от конфигурации сборки допустимые значения включают mpi, gloo, nccl, ucc, xccl или зарегистрированные сторонним плагином. Начиная с версии 2.6, если бэкенд не указан, c10d будет использовать бэкенд, зарегистрированный для типа устройства, указанного в аргументе device_id (если он предоставлен). Известные регистрации по умолчанию на сегодняшний день: nccl для cuda, gloo для cpu, xccl для xpu. Если не указаны ни backend, ни device_id, c10d обнаружит ускоритель на работающей машине и будет использовать бэкенд, зарегистрированный для этого обнаруженного ускорителя (или cpu). Это поле может быть задано в виде строки в нижнем регистре (например, «gloo»), к которой также можно получить доступ через атрибуты Backend (например, Backend.GLOO). При использовании нескольких процессов на одной машине с бэкендом nccl каждый процесс должен иметь эксклюзивный доступ к каждому используемому GPU, поскольку совместное использование GPU между процессами может привести к взаимоблокировке или недопустимому использованию NCCL. Бэкенд ucc является экспериментальным. Бэкенд по умолчанию для устройства можно запросить с помощью get_default_backend_for_device(). init_method (str, optional) – URL, указывающий, как инициализировать группу процессов. По умолчанию используется «env://», если не указаны init_method или store. Взаимоисключающ с store. world_size (int, optional) – Количество процессов, участвующих в задании. Обязателен, если указан store. rank (int, optional) – Ранг текущего процесса (должен быть числом от 0 до world_size-1). Обязателен, если указан store. store (Store, optional) – Хранилище ключ/значение, доступное всем рабочим процессам, используемое для обмена информацией о соединении/адресе. Взаимоисключающ с init_method. timeout (timedelta, optional) – Тайм-аут для операций, выполняемых в группе процессов. Значение по умолчанию — 10 минут для NCCL и 30 минут для других бэкендов. Это продолжительность, после которой коллективные операции будут асинхронно прерваны, и процесс завершится аварийно. Это сделано потому, что выполнение CUDA является асинхронным, и продолжать выполнение пользовательского кода больше небезопасно, поскольку сбойные асинхронные операции NCCL могут привести к тому, что последующие операции CUDA будут выполняться с повреждёнными данными. Когда установлен TORCH_NCCL_BLOCKING_WAIT, процесс будет заблокирован и будет ждать в течение этого тайм-аута. group_name (str, optional, устарело) – Имя группы. Этот аргумент игнорируется. pg_options (ProcessGroupOptions, optional) – Параметры группы процессов, указывающие, какие дополнительные параметры необходимо передать при создании конкретных групп процессов. На данный момент единственная поддерживаемая опция — ProcessGroupNCCL.Options для бэкенда nccl; можно указать is_high_priority_stream, чтобы бэкенд nccl мог использовать потоки cuda с высоким приоритетом, когда ожидают вычислительные ядра. Другие доступные опции для настройки nccl см. на странице https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/api/types.html#ncclconfig-t device_id (torch.device | int, optional) – одно конкретное устройство, с которым будет работать этот процесс, что позволяет выполнять оптимизацию для конкретного бэкенда. В настоящее время это имеет два эффекта, только в NCCL: коммуникатор формируется немедленно (вызов ncclCommInit* немедленно, а не обычный ленивый вызов), и подгруппы будут использовать ncclCommSplit, когда это возможно, чтобы избежать ненужных накладных расходов на создание группы. Если вы хотите узнать об ошибке инициализации NCCL на раннем этапе, вы также можете использовать это поле. Если указано целое число, API предполагает, что будет использоваться тип ускорителя, определённый во время компиляции. Примечание Чтобы включить backend == Backend.MPI, PyTorch должен быть собран из исходного кода в системе, поддерживающей MPI. Примечание Поддержка нескольких бэкендов является экспериментальной. В настоящее время, если бэкенд не указан, будут созданы бэкенды gloo и nccl. Бэкенд gloo будет использоваться для коллективных операций с тензорами CPU, а бэкенд nccl — для коллективных операций с тензорами CUDA. Пользовательский бэкенд можно указать, передав строку в формате «<device_type>:<backend_name>,<device_type>:<backend_name>», например «cpu:gloo,cuda:custom_backend». torch.distributed.device_mesh.init_device_mesh(device_type, mesh_shape, *, mesh_dim_names=None, backend_override=None)[source]# Инициализирует DeviceMesh на основе параметров device_type, mesh_shape и mesh_dim_names. Это создаёт DeviceMesh с n-мерным массивом, где n — длина mesh_shape. Если указан mesh_dim_names, каждое измерение помечается как mesh_dim_names[i]. Примечание init_device_mesh следует модели программирования SPMD, что означает, что одна и та же программа PyTorch Python выполняется на всех процессах/рангах в кластере. Убедитесь, что mesh_shape (размеры nD массива, описывающего расположение устройств) идентичен на всех рангах. Несогласованный mesh_shape может привести к зависанию. Примечание Если группа процессов не найдена, init_device_mesh инициализирует группу(ы) распределённых процессов, необходимые для распределённых коммуникаций, «за кулисами». Параметры device_type (str) – Тип устройств сетки. В настоящее время поддерживается: «cpu», «cuda/cuda-like», «xpu». Передача типа устройства с индексом GPU, например «cuda:0», не допускается. mesh_shape (Tuple[int]) – Кортеж, определяющий размеры многомерного массива, описывающего расположение устройств. mesh_dim_names (Tuple[str], optional) – Кортеж имён измерений сетки для назначения каждому измерению многомерного массива, описывающего расположение устройств. Его длина должна совпадать с длиной mesh_shape. Каждая строка в mesh_dim_names должна быть уникальной. backend_override (Dict[int | str, tuple[str, Options] | str | Options], optional) – Переопределения для некоторых или всех ProcessGroups, которые будут созданы для каждого измерения сетки. Каждый ключ может быть либо индексом измерения, либо его именем (если указан mesh_dim_names). Каждое значение может быть кортежем, содержащим имя бэкенда и его параметры, или только одним из этих двух компонентов (в этом случае другой будет установлен в значение по умолчанию). Возвращает Объект DeviceMesh, представляющий расположение устройств. Тип возвращаемого значения DeviceMesh Пример: >>> from torch.distributed.device_mesh import init_device_mesh >>> >>> mesh_1d = init_device_mesh("cuda", mesh_shape=(8,)) >>> mesh_2d = init_device_mesh("cuda", mesh_shape=(2, 8), mesh_dim_names=("dp", "tp")) torch.distributed.is_initialized()[source]# Проверяет, была ли инициализирована группа процессов по умолчанию. Тип возвращаемого значения bool torch.distributed.is_mpi_available()[source]# Проверяет, доступен ли бэкенд MPI. Тип возвращаемого значения bool torch.distributed.is_nccl_available()[source]# Проверяет, доступен ли бэкенд NCCL. Тип возвращаемого значения bool torch.distributed.is_gloo_available()[source]# Проверяет, доступен ли бэкенд Gloo. Тип возвращаемого значения bool torch.distributed.distributed_c10d.is_xccl_available()[source]# Проверяет, доступен ли бэкенд XCCL. Тип возвращаемого значения bool torch.distributed.is_torchelastic_launched()[source]# Проверяет, был ли этот процесс запущен с помощью torch.distributed.elastic (также известного как torchelastic). Наличие переменной окружения TORCHELASTIC_RUN_ID используется в качестве прокси для определения того, был ли текущий процесс запущен с помощью torchelastic. Это разумный прокси, поскольку TORCHELASTIC_RUN_ID соответствует идентификатору rendezvous, который всегда является ненулевым значением, указывающим идентификатор задания для целей обнаружения пиров. Тип возвращаемого значения bool torch.distributed.get_default_backend_for_device(device)[source]# Возвращает бэкенд по умолчанию для данного устройства. Параметры device (Union[str, torch.device]) – Устройство, для которого нужно получить бэкенд по умолчанию. Возвращает Бэкенд по умолчанию для данного устройства в виде строки в нижнем регистре. Тип возвращаемого значения str В настоящее время поддерживаются три метода инициализации: TCP-инициализация# Существует два способа инициализации с использованием TCP, оба требуют сетевого адреса, доступного всем процессам, и желаемого world_size. Первый способ требует указания адреса, принадлежащего процессу с рангом 0. Этот метод инициализации требует, чтобы все процессы вручную указали свои ранги. Обратите внимание, что многоадресный адрес больше не поддерживается в последней версии пакета распределённой обработки. group_name также устарел. import torch.distributed as dist # Используйте адрес одной из машин dist.init_process_group(backend, init_method='tcp://10.1.1.20:23456', rank=args.rank, world_size=4) Инициализация через общую файловую систему# Другой метод инициализации использует файловую систему, которая является общей и видна со всех машин в группе, а также желаемый world_size. URL должен начинаться с file:// и содержать путь к несуществующему файлу (в существующем каталоге) в общей файловой системе. Инициализация через файловую систему автоматически создаст этот файл, если он не существует, но не удалит его. Поэтому вы несёте ответственность за то, чтобы файл был очищен перед следующим вызовом init_process_group() с тем же путём/именем файла. Обратите внимание, что автоматическое назначение рангов больше не поддерживается в последней версии пакета распределённой обработки, и group_name также устарел. Предупреждение Этот метод предполагает, что файловая система поддерживает блокировку с помощью fcntl — большинство локальных систем и NFS поддерживают её. Предупреждение Этот метод всегда будет создавать файл и приложит все усилия для его очистки и удаления в конце программы. Другими словами, каждая инициализация с помощью файлового метода init потребует совершенно нового пустого файла для успешной инициализации. Если тот же файл, использованный в предыдущей инициализации (который случайно не был очищен), используется снова, это приведёт к непредсказуемому поведению и часто может вызывать взаимоблокировки и сбои. Поэтому, даже если этот метод приложит все усилия для очистки файла, если автоматическое удаление окажется неудачным, вы несёте ответственность за то, чтобы файл был удалён в конце обучения, чтобы предотвратить его повторное использование в следующий раз. Это особенно важно, если вы планируете вызывать init_process_group() несколько раз с одним и тем же именем файла. Другими словами, если файл не удалён/не очищен и вы снова вызываете init_process_group() для этого файла, ожидаются сбои. Эмпирическое правило здесь заключается в том, чтобы убедиться, что файл не существует или пуст каждый раз при вызове init_process_group(). import torch.distributed as dist # ранг всегда должен быть указан dist.init_process_group(backend, init_method='file:///mnt/nfs/sharedfile', world_size=4, rank=args.rank) Инициализация через переменные окружения# Этот метод будет считывать конфигурацию из переменных окружения, что позволяет полностью настроить способ получения информации. Устанавливаемые переменные: MASTER_PORT — обязательно; должен быть свободным портом на машине с рангом 0 MASTER_ADDR — обязательно (кроме ранга 0); адрес узла с рангом 0 WORLD_SIZE — обязательно; может быть установлен либо здесь, либо в вызове функции init RANK — обязательно; может быть установлен либо здесь, либо в вызове функции init Машина с рангом 0 будет использоваться для установки всех соединений. Это метод по умолчанию, то есть init_method не нужно указывать (или он может быть «env://»). Улучшение времени инициализации# TORCH_GLOO_LAZY_INIT — устанавливает соединения по требованию, а не использует полную сетку, что может значительно улучшить время инициализации для операций, отличных от all2all. После инициализации# После запуска torch.distributed.init_process_group() можно использовать следующие функции. Чтобы проверить, была ли уже инициализирована группа процессов, используйте torch.distributed.is_initialized(). class torch.distributed.Backend(name)[source]# Класс, подобный перечислению, для бэкендов. Доступные бэкенды: GLOO, NCCL, UCC, MPI, XCCL и другие зарегистрированные бэкенды. Значения этого класса являются строками в нижнем регистре, например «gloo». К ним можно получить доступ как к атрибутам, например Backend.NCCL. Этот класс можно вызывать напрямую для разбора строки, например Backend(backend_str) проверит, является ли backend_str допустимым, и вернёт разобранную строку в нижнем регистре, если это так. Он также принимает строки в верхнем регистре, например Backend("GLOO") возвращает «gloo». Примечание Запись Backend.UNDEFINED присутствует, но используется только как начальное значение некоторых полей. Пользователям не следует использовать её напрямую или предполагать её существование. classmethod register_backend(name, func, extended_api=False, devices=None)[source]# Регистрирует новый бэкенд с заданным именем и функцией создания экземпляра. Этот метод класса используется расширениями ProcessGroup сторонних производителей для регистрации новых бэкендов. Параметры name (str) – Имя бэкенда расширения ProcessGroup. Оно должно совпадать с именем в init_process_group(). func (function) – Обработчик функции, создающий экземпляр бэкенда. Функция должна быть реализована в расширении бэкенда и принимать четыре аргумента: store, rank, world_size и timeout. extended_api (bool, optional) – Указывает, поддерживает ли бэкенд расширенную структуру аргументов. По умолча