Коммуникация

Распределенное обучение тратит существенную долю времени исполнения на синхронизацию градиентов, перераспределение активаций и маршрутизацию токенов по сетевым фабрикам. Чтобы не загромождать текст глав пошаговыми выкладками, это приложение собирает количественные модели стоимости коммуникации, которыми книга пользуется на всем протяжении: формулировки для двухточечных передач ($\alpha$-$\beta$ и LogGP), границы исполнения коллективных операций (AllReduce, AllGather, ReduceScatter, AllToAll), арифметику пузырей конвейера и пороги сжатия градиентов.

Как пользоваться этим приложением

Приложение задумано как справочник для перевода симптома распределенного обучения («AllReduce работает медленно», «пузыри конвейера убивают пропускную способность», «стоит ли сжимать градиенты?») в количественный диагноз.

Используемые здесь соглашения следуют сквозным обозначениям книги: $\alpha$ — задержка запуска одного сообщения, $\beta$ — пропускная способность канала в байтах в секунду, $n$ — размер двухточечного сообщения, $n^{\ast }$ — точка перехода $\alpha$-$\beta$, $N$ — число участвующих GPU, а $M$ — размер полезной нагрузки коллективной операции в байтах.

• Когда AllReduce работает медленно: используйте раздел «Сложность коллективных операций», чтобы вычислить ожидаемое время и сравнить стоимость кольца и дерева.
• Когда выбираете между кольцом и деревом: используйте раздел «Выбор алгоритма» и анализ точки перехода, чтобы подобрать алгоритм под размер сообщения.
• Когда доминируют пузыри конвейера: используйте раздел «Арифметика конвейера», чтобы вычислить долю пузыря и определить необходимое число микробатчей.
• Когда предлагают сжимать градиенты: используйте раздел «Экономика сжатия», чтобы выполнить расчет окупаемости до того, как вкладывать инженерные усилия.

Модель коммуникации $\alpha$-$\beta$

Перспектива: почему это важно

Оценить, сколько займет синхронизация градиентов между 256 GPU, нужно до того, как выбрана топология кластера. Модель $\alpha$-$\beta$ — «roofline для сетей»: она дает предсказание времени передачи первого порядка всего по двум параметрам железа и размеру сообщения.

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

Модель $\alpha$-$\beta$ (уравнение) предсказывает время передачи двухточечного сообщения в $n$ байт:

$$T(n)=\alpha +\frac{n}{\beta }$$

где:

• $\alpha$ — задержка запуска (секунды): фиксированная стоимость начала сообщения, включающая программные накладные расходы, обработку сетевой картой (NIC) и настройку маршрута
• $\beta$ — пропускная способность канала (байт/с): устойчивая скорость данных после запуска
• $n$ — размер сообщения (байты)

Модель раскладывает каждую передачу ровно на две стоимости: налог на сообщение ($\alpha$), который платится независимо от размера, и налог на байт ($n/\beta$), растущий линейно с нагрузкой. Это разложение определяет все решения о выборе алгоритма в разделе «Выбор алгоритма».

Таблица «Параметры $\alpha$-$\beta$ по межсоединениям» задает базовые значения $\alpha$ и $\beta$ для физических межсоединений, которые обычно встречаются в кластерах ML:

Параметры $\alpha$-$\beta$ по межсоединениям: задержка запуска и устойчивая пропускная способность межсоединений, используемых в кластерах ML. В столбце $\beta$ указана односторонняя пропускная способность, то есть пропускная способность на одно направление, поэтому значение для NVLink H100 — половина двунаправленной суммарной спецификации в 900 ГБ/с. NVLink и PCIe работают внутри узла; InfiniBand и RoCE — между узлами. Задержка TCP определяется накладными расходами программного стека ядра.

Режимы с доминированием задержки и пропускной способности

Модель $\alpha$-$\beta$ выявляет два различных режима работы. Для малых сообщений доминирует задержка запуска $\alpha$: канал тратит большую часть времени на начало передач, а не на их поддержание. Для больших сообщений доминирует член пропускной способности $n/\beta$, а стоимость запуска становится пренебрежимой.

Размер сообщения в точке перехода $n^{\ast }$, определенный уравнением, — точка, где оба члена вносят одинаковый вклад:

$$n^{\ast }=\alpha \times \beta$$

Ниже $n^{\ast }$ коммуникация ограничена задержкой: отправка большего числа малых сообщений тратит время на повторные запуски. Выше $n^{\ast }$ коммуникация ограничена пропускной способностью: канал загружен полностью, и ускориться можно только за счет более высокой пропускной способности.

Сценарий: разобранный пример — точка перехода на InfiniBand NDR

Постановка: у InfiniBand NDR $\alpha$ = 5 мкс, а $\beta$ = 50 ГБ/с.

Вопрос: при каком размере сообщения член пропускной способности равен члену задержки?

Расчет:

$n^{\ast }=\alpha \times \beta =$ 5 мкс $\times$ 50 ГБ/с $=$ 250 КБ

Анализ: сообщения меньше 250 КБ ограничены задержкой на IB NDR. Тензоры градиентов одного слоя большой модели обычно составляют 10–100 МБ, то есть заметно выше этого порога. Однако служебные сообщения, heartbeat и барьерные синхронизации лежат значительно ниже него.

Системный вывод: именно поэтому NCCL и Gloo объединяют малые тензоры градиентов в более крупные «корзины» перед запуском AllReduce. Если отправлять каждый тензор по отдельности, стоимость запуска 5 мкс придется платить сотни раз за итерацию, а не несколько.

Расширение модели LogGP

Модель $\alpha$-$\beta$ предполагает, что сообщение — одна неделимая передача. На практике сети конвейеризуют сообщения: отправитель может впрыснуть новый пакет, не дожидаясь полного приема предыдущего. Модель LogGP (Alexandrov et al., 1995) расширяет LogP параметром интервала для длинных сообщений:

• $g$ (gap, интервал): минимальный интервал между последовательными впрыскиваниями сообщений у отправителя. Он моделирует предел скорости впрыскивания сетевой карты.
• $o_{\text{send}}$, $o_{\text{recv}}$ (overhead, накладные расходы): время процессора, потраченное на начало или завершение сообщения, в течение которого он не может выполнять полезные вычисления.

Для длинного сообщения в $n$ байт LogGP моделирует время передачи примерно так: $$T_{\text{long}}(n)\approx o_{\text{send}}+L_{\text{LogGP}}+(n-1)G+o_{\text{recv}}$$

где $L_{\text{LogGP}}$ — сетевая задержка, $o_{\text{send}}$ и $o_{\text{recv}}$ — накладные расходы отправителя и получателя, $G$ — интервал на байт для длинных сообщений, а $g$ задает минимальный интервал между последовательными впрыскиваниями сообщений. Неформальные приближения в духе $\alpha$-$\beta$ могут быть полезны для профилирования ML, но стандартная модель LogGP держит эти параметры интервала отдельно от простого члена пропускной способности.

В большинстве сценариев обучения ML модели $\alpha$-$\beta$ достаточно, потому что тензоры градиентов достаточно велики, чтобы эффекты конвейеризации были вторичны по сравнению с чистой пропускной способностью. Модель LogGP становится важной при анализе накладных расходов множества малых служебных сообщений или при моделировании взаимодействия между коммуникацией и перекрытием вычислений — в ситуациях, которые возникают в мелкозернистом конвейерном параллелизме и асинхронных обновлениях градиентов.

Модель $\alpha$-$\beta$ описывает двухточечные передачи. Коллективные операции, в которых участвуют все GPU, составляются из нескольких двухточечных передач, и их формулы стоимости прямо выводятся из приведенной выше модели.

Сложность коллективных операций

Перспектива: почему это важно

Каждый шаг распределенного обучения заканчивается коллективной синхронизацией. Стоимость этой коллективной операции, а не стоимость умножений матриц, часто определяет, реально ли масштабирование с 8 GPU до 256. Знание точной сложности каждой коллективной операции показывает, какая стратегия параллелизма (по данным, тензорный, конвейерный, экспертный) будет доминировать во времени по часам в заданном масштабе.

Коллективные операции перемещают данные между всеми $N$ GPU одновременно. У каждой коллективной операции есть характерный член пропускной способности (сколько данных течет) и член задержки (сколько последовательных шагов обмена сообщениями требуется). Приведенные ниже формулы используют пропускно-оптимальный кольцевой алгоритм, если не оговорено иное; раздел «Выбор алгоритма» рассматривает, когда предпочтительны другие алгоритмы.

AllReduce

AllReduce — рабочая лошадка обучения с параллелизмом по данным: каждый GPU начинает с локального тензора градиентов размером $M$ байт и заканчивает с глобально редуцированным (просуммированным) результатом. Кольцевой алгоритм раскладывает AllReduce на фазу ReduceScatter, за которой следует фаза AllGather. Время кольцевого AllReduce дает уравнение:

$$T_{\text{ring}}=2\cdot \frac{N-1}{N}\cdot \frac{M}{\beta }+2(N-1)\cdot \alpha$$

Множитель $2(N-1)/N$ в члене пропускной способности приближается к 2 с ростом $N$: каждый байт фактически проходит по кольцу дважды (один раз для reduce-scatter и один для all-gather). Член задержки растет линейно с $N$, из-за чего кольцевой алгоритм дорог по задержке при большом числе GPU.

Для сравнения, древовидный AllReduce имеет стоимость из уравнения:

$$T_{\text{tree}}=2{\log }_{2}N\cdot \frac{M}{\beta }+2{\log }_{2}N\cdot \alpha$$

Древовидный алгоритм обменивает эффективность по пропускной способности на эффективность по задержке: член задержки растет как ${\log }_{2}N$ вместо $N$, но член пропускной способности отправляет полное сообщение $M$ на каждом уровне дерева вместо кусков $M/N$.

Сценарий: разобранный пример — кольцевой и древовидный AllReduce

Постановка: 256 GPU H100, соединенных InfiniBand NDR ($\alpha$ = 5 мкс, $\beta$ = 50 ГБ/с). Тензор градиентов занимает 1 ГБ (модель на 500 млн параметров в FP16).

Вопрос: сколько времени занимает AllReduce в кольцевом и древовидном вариантах?

Кольцевой AllReduce:

$T_{\text{ring}}\approx$ 42,4 мс

Древовидный AllReduce:

$T_{\text{tree}}\approx$ 320,1 мс

Анализ: для этого сообщения в 1 ГБ кольцевой AllReduce занимает 42,4 мс, а древовидный — 320,1 мс: кольцо заметно быстрее, потому что распределяет нагрузку пропускной способности по всем каналам. Логарифмическое преимущество дерева по задержке пренебрежимо мало по сравнению с его штрафом по пропускной способности для больших сообщений.

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

AllGather

AllGather — дополнение к ReduceScatter: каждый GPU начинает с шарда размером $M/N$ и заканчивает с полным тензором в $M$ байт. Это основной примитив коммуникации в полностью шардированном параллелизме по данным (FSDP), где он восстанавливает параметры перед каждым проходом вперед, а в тензорном параллелизме — собирает разделенные активации.

Время кольцевого AllGather (уравнение) требует вдвое меньшего объема передачи, чем AllReduce:

$$T_{\text{allgather}}=\frac{N-1}{N}\cdot \frac{M}{\beta }+(N-1)\cdot \alpha$$

AllGather стоит ровно вдвое меньше AllReduce (один проход по кольцу вместо двух), потому что в нем нет шага редукции.

ReduceScatter

ReduceScatter — двойник AllGather: каждый GPU начинает с полного тензора в $M$ байт и заканчивает с шардом размером $M/N$, содержащим глобально редуцированные значения для этого шарда. Это примитив синхронизации градиентов в FSDP и ZeRO: он заменяет полный AllReduce более дешевой операцией, когда каждому GPU нужен только градиент его собственного шарда параметров.

Время кольцевого ReduceScatter (уравнение) дает примитив шардинга градиентов:

$$T_{\text{reducescatter}}=\frac{N-1}{N}\cdot \frac{M}{\beta }+(N-1)\cdot \alpha$$

Эта симметрия не случайна: кольцевой AllReduce раскладывается на один ReduceScatter и один AllGather, а их стоимости в точности складываются в уравнение.

AllToAll

AllToAll — самая общая коллективная операция: каждый GPU отправляет каждому другому GPU свой отдельный кусок размером $M/N$ и получает от каждого отдельный кусок. Это примитив маршрутизации для архитектур со смесью экспертов (MoE), где токены нужно разослать нужным экспертам, а результаты собрать обратно.

Время AllToAll с попарным обменом (уравнение) соответствует обмену персонализированными кусками данных между участниками:

$$T_{\text{alltoall}}=\frac{N-1}{N}\cdot \frac{M}{\beta }+(N-1)\cdot \alpha$$

Хотя по виду формула совпадает с AllGather и ReduceScatter, паттерн коммуникации принципиально иной: AllToAll — персонализированный обмен (каждый GPU отправляет разные данные каждому участнику), из-за чего его труднее перекрывать с вычислениями и он чувствительнее к сетевой перегрузке.

Broadcast

Broadcast отправляет один тензор в $M$ байт с одного корневого GPU всем остальным $N-1$. Он используется для распространения начальных весов модели, обновленных скоростей обучения и изменений конфигурации во время обучения.

Время древовидного Broadcast (уравнение) растет логарифмически с числом участвующих GPU:

$$T_{\text{broadcast}}={\log }_{2}N\left(\alpha +\frac{M}{\beta }\right)$$

Broadcast по своей природе асимметричен (один отправитель, много получателей), что делает естественной древовидную топологию. В несегментированном древовидном broadcast полная нагрузка в $M$ байт пересылается на каждом уровне дерева, поэтому и член задержки, и член пропускной способности входят в критический путь из ${\log }_{2}N$ уровней. Сегментированные варианты или варианты broadcast через scatter и allgather способны уменьшить член пропускной способности, но им нужна иная, специфичная для алгоритма модель.

Сводка по сложности коллективных операций

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

Сводка стоимости коллективных операций: члены пропускной способности и задержки для кольцевых, древовидных алгоритмов и алгоритмов попарного обмена. Член пропускной способности определяет стоимость для больших сообщений (градиенты, параметры); член задержки — для малых (скаляры, барьеры). $N$ — число GPU, $M$ — полный размер сообщения в байтах.

Из этой таблицы видны две закономерности. Во-первых, модели кольца и попарного обмена содержат множитель $(N-1)/N$, который стремится к 1 при большом $N$. Поэтому коммуникация на один ранг приближается к константе, кратной $M$: около $2M$ для кольцевого AllReduce и около $M$ для кольцевых AllGather и ReduceScatter и попарного AllToAll. Суммарный трафик при этом по-прежнему растет с числом рангов. Во-вторых, член задержки растет линейно с $N$ для кольцевых алгоритмов и логарифмически для древовидных, что создает компромисс при выборе алгоритма, анализируемый далее.

Выбор алгоритма

Перспектива: почему это важно

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

Кольцо, дерево и рекурсивное деление пополам и удвоение

Кольцевой алгоритм минимизирует использование пропускной способности, но платит стоимостью задержки, которая растет линейно с $N$. Древовидный алгоритм минимизирует задержку, но расходует пропускную способность впустую, потому что на каждом уровне отправляет полное сообщение. Рекурсивное деление пополам и удвоение занимает промежуточное положение: оно использует деление пополам (как дерево) на фазе редукции и удвоение на фазе сбора и достигает почти оптимальной пропускной способности при $\mathcal{O}(\log N)$ шагов задержки.

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

$$M_{\times }(N)=n^{\ast }\times \frac{(N-1)-{\log }_{2}N}{{\log }_{2}N-(N-1)/N},n^{\ast }=\alpha \beta$$

• $M>M_{\times }(N)$ (большие градиенты): у кольца меньше смоделированная стоимость, потому что его меньший коэффициент пропускной способности перевешивает дополнительные шаги запуска.
• $M<M_{\times }(N)$ (барьеры, скаляры): у дерева меньше смоделированная стоимость, потому что его логарифмический член запуска перевешивает дополнительную стоимость пропускной способности.
• $M\approx M_{\times }(N)$ (тензоры среднего размера): две смоделированные стоимости близки, поэтому сравните их с рекурсивным делением пополам и удвоением на целевой топологии.

Таблица «Руководство по выбору алгоритма» помогает выбрать подходящий алгоритм.

Руководство по выбору алгоритма: сильные и слабые стороны кольца, дерева и рекурсивного деления пополам и удвоения относительно зависящей от числа участников точки перехода кольцо–дерево $M_{\times }(N)$ из уравнения.

Иерархический AllReduce

Современные кластеры имеют двухуровневую топологию: GPU внутри узла соединены NVLink (450 ГБ/с), а узлы соединены InfiniBand (50 ГБ/с). Иерархический AllReduce использует эту асимметрию в три фазы:

1. Редукция внутри узла (NVLink): каждый узел сводит свои 8 локальных GPU к одному результату, используя пропускную способность NVLink 450 ГБ/с. Это быстро, потому что скорость NVLink в одном направлении в 9× выше, чем у порта InfiniBand NDR.
2. AllReduce между узлами (InfiniBand): результаты узлов редуцируются между узлами. Участвует только один представитель от каждых 8 локальных GPU, поэтому в межузловом кольце в восемь раз меньше участников, чем в плоском кольце уровня GPU.
3. Broadcast внутри узла (NVLink): каждый узел рассылает глобальный результат своим 8 локальным GPU.

Иерархический подход уменьшает размер межузлового кольца с числа всех GPU до одного представителя на каждые 8 локальных GPU, сокращая член шагов задержки примерно в 8$\times$ и ограничивая прожорливые по пропускной способности фазы быстрыми внутриузловыми линками. NCCL выбирает среди учитывающих топологию алгоритмов — Ring, Tree, варианты CollNet, NVLS/NVLSTree и PAT — по коллективной операции, размеру сообщения, топологии, архитектуре и версии; иерархическая коммуникация распространена в многоузловых системах, но не является универсальным умолчанием.

Понимание структуры стоимости коллективных операций позволяет рассуждать о накладных расходах параллелизма по данным. Конвейерный параллелизм вносит накладные расходы другого рода: простой, вызванный последовательной зависимостью между стадиями конвейера.

Арифметика конвейера

Перспектива: почему это важно

Конвейерный параллелизм разбивает модель между несколькими GPU так, что каждый GPU хранит лишь долю слоев. Цена — время пузыря: холостые такты, когда GPU ждут активаций или градиентов от вышестоящих или нижестоящих стадий. Количественная оценка доли пузыря показывает, оправдан ли конвейерный параллелизм своей сложностью в заданном масштабе.

Доля пузыря

В конвейере с $p$ стадиями и $m$ микробатчами уравнение определяет долю пузыря как долю общего времени GPU, проведенную в простое:

$$b_{\text{pipe}}=\frac{p-1}{p-1+m}$$

Эта формула применима и к GPipe (где все проходы вперед завершаются до начала любого прохода назад), и к 1F1B (чередование «один прямой — один обратный»). У расписания 1F1B та же асимптотическая доля пузыря, но оно использует меньше пиковой памяти, потому что раньше завершает микробатчи.

Доля пузыря зависит от отношения числа стадий к числу микробатчей. Добавление микробатчей (при фиксированном числе стадий) амортизирует заполнение и опустошение конвейера на большее число полезной работы.

Практическое правило: чтобы накладные расходы пузыря были не выше 20 %, нужно $m\ge 4(p-1)$; строго ниже 20 % — $m>4(p-1)$. Практическое правило $m\ge 4p$ — удобная консервативная цель.

Глубина конвейера и число микробатчей (таблица «Доля пузыря конвейера») определяют эффективную долю пузыря.

Доля пузыря конвейера: процент времени GPU, потерянный на пузыри конвейера при разном числе стадий и микробатчей. Значения ниже 20 % (типичная цель) требуют $m\ge 4p$.

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

Чередующееся планирование

Чередующееся планирование (используется в Megatron-LM) назначает каждому физическому GPU не одну, а $V$ виртуальных стадий. Каждый GPU обрабатывает $V$ неподряд идущих фрагментов модели, то есть в конвейере $p\times V$ виртуальных стадий, но накладные расходы пузыря определяются исходным $p$, как показывает уравнение:

$$b_{\text{interleaved}}=\frac{p-1}{p-1+m\times V}$$

Член микробатчей в знаменателе умножен на $V$ по сравнению с уравнением пузыря конвейера, поэтому сокращение пузыря приближается к $V$, когда $m$ доминирует над $p-1$. При $p$ = 8, $m$ = 16 и $V$ = 4 доля пузыря падает с 30,4 % до 9,9 %, то есть сокращается в 3,1×; расплата — более частая и мелкая коммуникация между стадиями.

Чередующееся планирование подчеркивает повторяющуюся тему распределенного ML: гранулярность коммуникации — настраиваемая ручка. Более мелкие и частые передачи улучшают перекрытие и сокращают простой, но увеличивают суммарные накладные расходы задержки. Тот же компромисс определяет сжатие градиентов.

Экономика сжатия

Перспектива: почему это важно

Сжатие градиентов обещает уменьшить объем коммуникации в 10–1000$\times$, сделав AllReduce почти бесплатным. Но у сжатия есть накладные расходы (время кодирования и декодирования), и оно помогает, только если эти расходы меньше сэкономленного времени коммуникации. Быстрый расчет окупаемости предотвращает напрасные усилия над схемами сжатия, которые на деле не ускорят обучение.

Уравнение сжатия

Сжатие градиентов заменяет исходный градиент в $M$ байт сжатым представлением размера $M/r_{\text{comp}}$, где $r_{\text{comp}}$ — степень сжатия. Уравнение выражает полное время со сжатием:

$$T_{\text{compressed}}=T_{\text{encode}}+T_{\text{transfer}}\left(\frac{M}{r_{\text{comp}}}\right)+T_{\text{decode}}$$

Сжатие полезно, когда $T_{\text{compressed}}<T_{\text{transfer}}(M)$. Преобразование этого неравенства дает условие окупаемости из уравнения:

$$T_{\text{encode}}+T_{\text{decode}}<T_{\text{transfer}}(M)-T_{\text{transfer}}\left(\frac{M}{r_{\text{comp}}}\right)$$

В режиме, где доминирует пропускная способность ($M\gg n^{\ast }$), время коммуникации растет линейно с размером сообщения, и правая часть упрощается примерно до $T_{\text{transfer}}(M)\times (1-1/r_{\text{comp}})$. При высоких степенях сжатия ($r_{\text{comp}}\gg 1$) она приближается к $T_{\text{transfer}}(M)$, то есть сжатие оправдано, пока накладные расходы кодека меньше времени несжатой коммуникации.

Сценарий: разобранный пример — окупается ли сжатие top-k?

Постановка: кольцевой AllReduce градиента 1 ГБ между 256 GPU H100 по InfiniBand NDR занимает 42,4 мс без сжатия. Схема разреживания top-k дает сжатие 64× при суммарных накладных расходах кодирования и декодирования 2 мс.

Вопрос: сокращает ли сжатие полное время AllReduce?

Расчет:

• Несжатый AllReduce: 42,4 мс
• Сжатая коммуникация: 3,2 мс
• Всего со сжатием: 5,2 мс
• Ускорение: 8,2×

Результат: сжатие дает ускорение коммуникации в 8,2×. Накладные расходы кодека 2 мс составляют малую долю несжатого базового времени 42,4 мс.

Системный вывод: в этом масштабе (256 GPU, градиенты по 1 ГБ) сжатие градиентов явно выгодно. Но влияние на сходимость нужно проверить: разреживание top-k отбрасывает информацию, и модели может потребоваться больше итераций для той же точности, что способно свести на нет выигрыш на итерацию.

Пределы окупаемости накладных расходов кодека (таблица «Пороги окупаемости сжатия») растут со степенью сжатия и временем несжатого AllReduce. Более высокие степени сжатия допускают большие накладные расходы кодека, вплоть до зависящей от пропускной способности части несжатой коллективной операции.

Пороги окупаемости сжатия: максимальные допустимые накладные расходы кодека (кодирование и декодирование), при которых сжатие сокращает полное время, вычисленные как фактическая разность времен коллективной операции $T_{\text{transfer}}(M)-T_{\text{transfer}}(M/r_{\text{comp}})$. Общая задержка запуска сокращается, поэтому даже при высоких степенях сжатия она не входит в бюджет кодека.

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

Итоги

Ключевые выводы: стоимость коммуникации предсказуема

• Модель $\alpha$-$\beta$: модель ($T(n)=\alpha +n/\beta$) раскладывает каждую сетевую передачу на фиксированную стоимость запуска и стоимость пропускной способности, пропорциональную нагрузке (принцип «компромисс пропускной способности и задержки (модель α-β)»). Размер сообщения в точке перехода $n^{\ast }=\alpha \times \beta$ определяет, какая стоимость доминирует.
• Структура стоимости коллективных операций: кольцевые AllReduce, AllGather и ReduceScatter и AllToAll с попарным обменом содержат множитель пропускной способности $(N-1)/N$, а их члены задержки растут линейно с числом GPU. Древовидные алгоритмы обменивают пропускную способность на логарифмический рост задержки.
• Выбор алгоритма: размер сообщения относительно зависящей от числа участников точки перехода $M_{\times }(N)$ определяет, какая из приведенных моделей, кольцевая или древовидная, дешевле. В промышленном выборе также сравнивают рекурсивное деление пополам и удвоение и иерархические схемы на целевой топологии.
• Доля пузыря конвейера: $b_{\text{pipe}}=(p-1)/(p-1+m)$ — фундаментальные накладные расходы конвейерного параллелизма. Практическое правило $m\ge 4p$ удерживает пузыри ниже 20 %, а чередующееся планирование с $V$ виртуальными стадиями приближает сокращение пузыря к $V$, когда доминирует член микробатчей.
• Сжатие градиентов: сжатие градиентов выгодно, когда накладные расходы кодека (кодирование и декодирование) меньше сэкономленного времени коммуникации. При высоких степенях сжатия зависящая от пропускной способности часть времени несжатого AllReduce приближается к бюджету накладных расходов, но влияние на сходимость всегда нужно проверять.
• Предсказательные параметры: модели двухточечной и коллективной коммуникации в этом приложении выводятся из двух параметров железа ($\alpha$ и $\beta$) и двух параметров нагрузки (размер полезной нагрузки сообщения $n$ или $M$ и число участников $N$ для коллективных операций). Измерение этих величин для кластера дает полное предсказание первого порядка накладных расходов распределенного обучения, а модели конвейера и сжатия вводят дополнительные параметры.