Основы парка

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

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

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

• При оценке межузловой коммуникации: обратитесь к разделу «Числа, которые должен знать каждый инженер парка» за иерархией пропускной способности и задержки.
• При подборе размеров выделения GPU: обратитесь к разделу «Физика масштабирования», чтобы проанализировать, почему удвоение числа ускорителей не сокращает время обучения вдвое.
• При расчете надежности кластера: проверьте раздел «Числа, которые должен знать каждый инженер парка» на таблицы среднего времени между отказами (MTBF) и модели вероятности отказа.
• При оценке пределов мощности и охлаждения: обратитесь к разделу «Физика тепла и мощности» за потолками плотности мощности и ограничениями охлаждения.
• При бюджетировании накладных расходов времени выполнения: используйте раздел «Числа, которые должен знать каждый инженер парка» для четырех категорий накладных расходов, которые разъедают goodput.

Три системные парадигмы

Инфраструктура машинного обучения в масштабе наследует проектную ДНК двух разных вычислительных линий — и затем ломает допущения обеих. Чтобы выбирать правильные проектные компромиссы, важно понимать, что системы ML заимствуют у высокопроизводительных вычислений (HPC), а что — у складских вычислений (WSC). Системный архитектор, который считает обучение ML «просто HPC», построит инфраструктуру, не способную терпеть отказы. Тот, кто считает его «просто веб-сервисами», построит инфраструктуру, не способную поддерживать тесную связь, которой требует синхронное обучение.

Высокопроизводительные вычисления

HPC-системы происходят из традиции суперкомпьютеров. Их проектная философия — максимизировать FLOP/с на тесно связанных симуляциях: моделировании погоды, молекулярной динамике, ядерной физике. Важен каждый узел: используются специализированные межсоединения (InfiniBand), фабрики с низкой задержкой и однородное железо. Отказоустойчивость следует модели контрольных точек с перезапуском: если отказывает один узел, останавливается все задание, откатывается к последней контрольной точке и стартует заново. Планирование пакетное (Slurm), задания запрашивают жесткие формы ресурсов («512 узлов на 24 часа»). Узлы — питомцы: каждый важен и отслеживается индивидуально.

Складские вычисления

WSC-системы происходят из традиции веб-сервисов. Их проектная философия — максимизировать число запросов в секунду на слабо связанных сервисах: поиск, почта, социальные сети. Железо — обычный Ethernet, сосуществуют разные поколения, узлы неоднородны. Отказоустойчивость следует модели избыточности: если отказывает один узел, балансировщик нагрузки перенаправляет трафик на другую реплику. Пользователь ничего не замечает. Планирование динамическое (Kubernetes, Borg), с эластичной упаковкой. Узлы — скот: взаимозаменяемы и расходуемы.

Парк ML: гибридная архитектура

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

Нагрузки обучения синхронны и требовательны к пропускной способности, как в HPC, но длительны и терпимы к отказам, как в WSC. Нагрузки инференса чувствительны к задержке, как в WSC, но вычислительно тяжелы, как в HPC. Сеть — сплав: TCP/IP для плоскостей управления, InfiniBand или NVLink для плоскостей данных. Отказоустойчивость использует стратегии эластичного обучения: задания обучения могут сжиматься, расширяться, приостанавливаться и возобновляться без полного перезапуска. Планирование сочетает gang-выделение (все или ничего для обучения) с динамическим вытеснением и заменой.

Таблица «Три системные парадигмы» суммирует проектные компромиссы трех парадигм. Главная мысль: парки ML не могут просто принять паттерны HPC или WSC целиком; они должны выборочно сочетать элементы каждой в зависимости от фазы нагрузки.

Три системные парадигмы: парки ML наследуют проектную ДНК и HPC, и WSC, но ломают допущения каждой. Обучение напоминает HPC (тесная связь), инференс напоминает WSC (эластичное обслуживание), а отказоустойчивость — гибрид обеих.

Краткое напоминание основ

Ниже приведен компактный справочник по ключевым основополагающим идеям, которые повторяются в главах о распределенных системах.

• Железный закон ($T\approx D_{\text{vol}}/\text{BW}+O/(R_{\text{peak}}\cdot {\eta }_{\text{hw}})+L_{\text{lat}}$): производительность ограничена перемещением данных или вычислениями. В масштабе парка член перемещения данных расширяется и включает межузловую коммуникацию, а не только пропускную способность памяти.
• Модель Roofline: различает нагрузки, ограниченные вычислениями и памятью, по арифметической интенсивности. В масштабе парка появляется третий потолок: нагрузки, ограниченные сетью, чья производительность ограничена межузловой пропускной способностью.
• Закон Амдала: ограничивает ускорение при сильном масштабировании величиной $1/s$ (Amdahl, 1967). В масштабе парка «последовательная доля» включает не только последовательный код, но и барьеры синхронизации, коллективную коммуникацию и пузыри конвейера.
• Правило состояния обучения: около 14 байт на параметр для типичного состояния контрольной точки с оптимизатором адаптивной оценки моментов (Adam) в смешанной точности (веса BF16, мастер-веса FP32 и моменты Adam), не считая метаданных фреймворка и специфичных для реализации добавок. В масштабе парка это определяет, как состояние модели разбивается между узлами (ZeRO, тензорный параллелизм, конвейерный параллелизм).
• Закон Литтла ($Q_{\text{req}}={\lambda }_{\text{arr}}{T}_{\text{lat}}$): задает размеры инфраструктуры инференса, где ${\lambda }_{\text{arr}}$ — интенсивность поступления запросов, а $Q_{\text{req}}$ — ожидаемое число одновременных запросов (Little, 1961). В масштабе парка он определяет, сколько реплик обслуживания нужно за балансировщиком нагрузки.

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

Числа, которые должен знать каждый инженер парка

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

Перспектива: числа уровня узла для рассуждений о парке

Рассуждения о парке зависят от нескольких чисел уровня узла, которые напрямую влияют на проект парка: правило состояния обучения около 14 байт на параметр для типичного состояния контрольной точки Adam (с большими объемами, если учитывать градиенты, активации, метаданные или дополнительные буферы оптимизатора); пропускная способность NVLink и памяти с высокой пропускной способностью (HBM) для размещения внутриузлового параллелизма; а также пиковые FLOP/с и емкость HBM для утилизации FLOP модели (MFU), эффективных FLOP/с, подбора размера батча и шардинга модели. Таблица «Числа, которые должен знать каждый инженер парка (краткий справочник)» и приведенные ниже числа коммуникации дают значения для межузлового уровня и нынешнего поколения; иерархия памяти и точки перегиба roofline внутри узла задают необходимую базу. Эти базовые значения уровня узла упрощают интерпретацию отношений уровня парка.

Перспектива: три самых важных числа парка

• Разрыв пропускной способности: пропускная способность NVLink в одном направлении внутри узла в ~9× выше, чем у порта InfiniBand NDR между узлами. Это отношение определяет, где должны проходить границы параллелизма: параллелизм модели внутри узла, параллелизм по данным между узлами.
• Масштабирование MTBF: среднее время между отказами кластера равно MTBF одного компонента, деленному на число компонентов (масштабирование $1/N$). На 100 000 GPU ожидайте отказ каждые 30 мин.
• Эффективная утилизация: после накопления потерь MFU, эффективности масштабирования и накладных расходов кластер из 1 024 GPU отдает примерно 20,5 % пиковых FLOP/с как полезную работу обучения.

Таблица «Числа, которые должен знать каждый инженер парка (краткий справочник)» собирает числа масштаба парка в одном месте. Используйте ее для проверок «на обороте конверта»; при проектировании или отладке пользуйтесь подробными таблицами в каждом подразделе.

Числа, которые должен знать каждый инженер парка (краткий справочник): одностраничная сводка справочных чисел масштаба парка из этого раздела. См. таблицу «Иерархия пропускной способности коммуникации» и таблицу «Иерархия задержки коммуникации» для коммуникации, таблицу «Эффективность масштабирования по размеру кластера» для вычислений и таблицу «MTBF и вероятность отказа по размеру кластера» для координации.

Инварианты: отношения, которые не изменятся

Эти соотношения определяются физикой или архитектурой — они будут верны и в 2035 году.

Отношение иерархии сети

Разрыв пропускной способности между внутриузловой и межузловой коммуникацией — архитектурный инвариант. Каналы между чипами (NVLink, ICI) соединяют по коротким, широким, выделенным путям на общей подложке. Межузловые каналы (InfiniBand, Ethernet) должны проходить через кабели, коммутаторы и сетевые стеки. Это структурное различие гарантирует, что внутриузловая пропускная способность всегда будет на порядок выше межузловой.

Сейчас NVLink 4.0 обеспечивает в 9× больше пропускной способности в одном направлении, чем порт InfiniBand NDR. Даже при улучшении обеих технологий отношение сохраняется, потому что обе ограничены одной и той же физикой: скоростями сигнализации, числом линий и плотностью разъемов. Это отношение — самое важное число для стратегии параллелизма: любая операция, которой нужно больше пропускной способности, чем может дать межузловой канал, должна оставаться внутри одного узла.

Закон масштабирования отказов

Для $N$ независимых компонентов при постоянной интенсивности отказов MTBF системы (уравнение) обратно пропорционален числу компонентов:

$${\text{MTBF}}_{\text{system}}=\frac{{\text{MTBF}}_{\text{component}}}{N}$$

Это чистая арифметика, а не приближение. Удвоение размера кластера вдвое сокращает время между отказами. На 100 000 GPU при среднем времени до отказа (MTTF) на GPU 50 000 ч кластер переживает отказ GPU каждые 30 мин. Ни одна стратегия отказоустойчивости не может этого избежать: вопрос в том, как быстро система восстанавливается.

Масштабирование накладных расходов AllReduce

Пропускно-оптимальный алгоритм кольцевого AllReduce передает $2(N-1)M/N$ байт на участника, где $M$ — размер сообщения, а $N$ — число участников (Patarasuk и Yuan, 2009). При больших $N$ это приближается к $2M$ на GPU, поэтому член пропускной способности на GPU почти не зависит от числа GPU; суммарный трафик кластера при этом по-прежнему растет с числом участников. Поэтому кольцевой AllReduce хорошо масштабируется по члену пропускной способности. Однако член задержки растет как $2(N-1)\times \alpha$, и задержка становится узким местом для малых сообщений на больших кольцах. Этот компромисс мотивирует иерархические стратегии AllReduce, которые используют кольцевой AllReduce внутри узлов и древовидный между узлами.

Числа коммуникации

Коммуникация определяет границы параллелизма. Эти таблицы количественно задают пропускную способность и задержку на каждом ярусе сетевой иерархии — от самых быстрых внутриузловых каналов до самых медленных глобальных соединений. Для любой распределенной операции ML существенный вопрос — какой сетевой ярус пересекает ее коммуникация.

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

Иерархия пропускной способности коммуникации: пропускная способность в одном направлении падает примерно в 9× при переходе от внутриузловой (NVLink) к межузловой (InfiniBand). Это отношение сравнивает односторонний темп NVLink H100 с одним портом InfiniBand NDR и определяет размещение параллелизма.

Односторонняя задержка по ярусам межсоединений (таблица «Иерархия задержки коммуникации») определяет, жизнеспособны ли синхронные коллективные операции.

Иерархия задержки коммуникации: задержка определяет, осуществимо ли синхронное обучение. TCP/IP примерно в 10$\times$ медленнее InfiniBand NDR, что делает его непригодным для синхронизации градиентов в больших кластерах.

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

Числа вычислений

Сырые пиковые FLOP/с — необходимая, но вводящая в заблуждение метрика для планирования емкости парка. Две мультипликативные потери, MFU и эффективность масштабирования, резко снижают эффективную пропускную способность. Понимание этих потерь превращает подбор размера парка из гадания в инженерию.

MFU измеряет, какую долю пиковых FLOP/с нагрузка обучения реально достигает. Хорошо оптимизированное обучение больших моделей на современном железе достигает MFU 30–50 %. Разрыв порождают остановки памяти, накладные расходы запуска ядер, пузыри конвейера и неоптимальное слияние операторов. MFU ниже нижней границы этого диапазона сигнализирует о возможностях оптимизации; MFU выше верхней границы указывает на отличную утилизацию железа.

Эффективность масштабирования (${\eta }_{\text{scaling}}$) измеряет, какая часть полезных вычислений уцелеет при добавлении ускорителей. Эмпирическая эффективность масштабирования (таблица «Эффективность масштабирования по размеру кластера») показывает деградацию пропускной способности с ростом кластера.

Эффективность масштабирования по размеру кластера: эффективность деградирует примерно как логарифм размера кластера. Эти диапазоны предполагают хорошо оптимизированный параллелизм по данным со сжатием градиентов. Плохо оптимизированные системы могут терять в 2–3$\times$ больше.

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

Числа координации

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

Интенсивность отказов по размеру кластера

Масштабирование MTBF кластера (таблица «MTBF и вероятность отказа по размеру кластера», рассчитанная для MTTF на GPU 50 000 ч) диктует необходимую частоту контрольных точек.

MTBF и вероятность отказа по размеру кластера: модель отказов только GPU с MTTF на GPU 50 000 часов. Реальные кластеры включают также отказы NIC, PSU, кабелей и коммутаторов, поэтому эти оценки консервативны. В столбце вероятности используется $\mathrm{Pr}(\ge 1\text{отказа})=1-e^{-T/\text{MTBF}}$ для $T=24$ часа.

На 8 192 GPU и выше отказ перестает быть редким случаем. MTBF только GPU на 8 192 GPU составляет около 366,2 мин, а вероятность хотя бы одного отказа GPU за 24 часа равна 98 %. Отказоустойчивость в масштабе парка не опциональна: это предпосылка завершения любого долгого задания обучения. Глава «Отказоустойчивость» подробно рассматривает механизмы.

Размеры контрольных точек

Контрольные точки — основной механизм восстановления, и их стоимость зависит от размера модели. Таблица «Размеры контрольных точек по масштабу модели» показывает размеры типичных контрольных точек обучения Adam в смешанной точности (14 байт на параметр: 2 Б для весов BF16 и 12 Б для мастер-весов FP32, моментума и дисперсии). Градиенты обычно временны и пересчитываются после восстановления, а не сериализуются как долговременное состояние контрольной точки.

Размеры контрольных точек по масштабу модели: используется 14 байт на параметр для типичного состояния контрольной точки Adam в смешанной точности. Время записи предполагает суммарную пропускную способность хранилища 100 ГБ/с. Асинхронные контрольные точки (глава «Отказоустойчивость») могут перекрывать записи с обучением и сокращать видимые накладные расходы.

Бюджеты накладных расходов

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

Бюджеты накладных расходов для обучения в масштабе парка: это доли времени по часам. На 10 000+ GPU доминирует восстановление после отказов. Эффект суммируется: итоговый коэффициент goodput $\approx 1,0-(0,05+0,03+0,10+0,05)=0,77\approx 77\%$.

Числа мощности и устойчивости

Планирование емкости парка и отчетность по устойчивости требуют нескольких чисел мощности, которые должен знать каждый инженер парка. В масштабе парка критичны три числа: плотность мощности стойки, эффективность использования энергии (PUE) и предел воздушного охлаждения: они определяют, где возможно строительство и какой будет нагрузка объекта. Таблица «Справочные числа мощности и охлаждения» собирает эти эталонные значения:

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

Эмпирическое правило: нагрузка ИТ (МВт) = (число GPU $\times$ расчетная тепловая мощность (TDP) на GPU)/$10^6$; нагрузка объекта = нагрузка ИТ $\times$ PUE. Кластер из 10 000 GPU H100 по 700 Вт каждый — это 7 МВт ИТ; при PUE 1,40 потребление объекта составляет 9,8 МВт. Об углероде и стоимости см. раздел «Физика тепла и мощности» и главу «Устойчивый ИИ».

Эталон текущего железа (ок. 2025–2026 гг.)

Эти числа (таблица «Эталон железа масштаба парка (ок. 2025–2026 гг.)») отражают текущее поколение железа масштаба парка. Используйте их для оценок «на обороте конверта», но ожидайте, что они улучшаются примерно в 2$\times$ каждые 2–3 года.

Эталон железа масштаба парка (ок. 2025–2026 гг.): характеристики на ускоритель для поколений 2025–2026 годов. B200, MI300X и TPU v6e (Trillium) представляют передний край плотности вычислений и пропускной способности памяти в масштабе парка.

Для масштабного контекста: DGX H100 SuperPOD содержит 32 узла DGX H100 (256 GPU H100). Meta объявила о двух кластерах масштаба дата-центра по 24 576 H100, построенных на аппаратной платформе Grand Teton. Поды Tensor Processing Unit (TPU) v5p от Google масштабируются до 8 960 чипов. Крупнейшие объявленные кластеры (по состоянию на 2025 год) превышают 100 000 ускорителей.

Физика масштабирования

Числа в предыдущем разделе описывают, на что способно железо. Физика масштабирования описывает, что происходит, когда его вводят в дело больше. Рассуждение начинается с потолка одного ускорителя — roofline — и затем спрашивает, что остается при добавлении устройств; тремя моделями управляют закон Амдала, расширенный на накладные расходы парка, отношение коммуникации к вычислениям и поведение слабого масштабирования.

Roofline одного ускорителя

Производительность парка опирается на производительность одного ускорителя, а ускоритель ограничен одним из двух ресурсов: скоростью, которую выдерживают его арифметические блоки (пиковые FLOP/с), или скоростью, с которой память поставляет операнды (пропускная способность HBM). Какой из них связывает конкретное ядро, зависит от его арифметической интенсивности $I$, числа полезных операций на байт, перемещенный из памяти, как определяет уравнение:

$$I=\frac{\text{FLOP}}{\text{перемещенные байты}}$$

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

Модель Roofline (Williams et al., 2009) превращает интенсивность в потолок производительности. Уравнение утверждает, что достижимая пропускная способность — меньшее из вычислительного потолка и ограниченного пропускной способностью склона:

$$R_{\text{attain}}=\min \left(R_{\text{peak}},I\times \text{BW}\right)$$

В зависимости от интенсивности уравнение вычерчивает «крышу»: растущую линию, ограниченную пропускной способностью, слева и плоский вычислительный потолок справа. Они встречаются в точке перегиба (ridge point) — интенсивности, при которой нагрузка впервые насыщает арифметические блоки; ее определяет уравнение:

$$I_{\text{ridge}}=\frac{R_{\text{peak}}}{\text{BW}}$$

Нагрузка с $I<I_{\text{ridge}}$ ограничена памятью: она лежит на склоне, и более быстрые арифметические блоки ничего не меняют, потому что операнды не успевают приходить. Нагрузка с $I>I_{\text{ridge}}$ ограничена вычислениями: она лежит под плоской крышей и ограничена самими арифметическими блоками.

Для H100 — пик BF16 989 TFLOP/с, пропускная способность HBM 3,35 ТБ/с — точка перегиба равна 295,2 FLOP/байт. Нагрузка должна выполнять сотни операций на каждый извлеченный байт, лишь чтобы арифметические блоки были заняты.

Авторегрессивное декодирование далеко не дотягивает до этой линии, поэтому оно и служит определяющим узким местом обслуживания. Генерация одного токена требует ровно один раз прочитать из HBM каждый вес модели (16,1 ГБ для модели на 8 млрд параметров в BF16), чтобы выполнить около 16,1 GFLOP матричной работы, то есть при интенсивности 1 FLOP/байт. Это далеко ниже точки перегиба, поэтому декодирование одного потока целиком ограничено пропускной способностью: производительность равна скорости чтения весов, около 208,6 токена/с, сколько бы вычислений ни декларировал ускоритель. Системы обслуживания объединяют много запросов в батчи именно затем, чтобы повысить эту интенсивность: каждое чтение весов амортизируется по всем последовательностям батча, и декодирование возвращается ближе к вычислительной крыше.

Roofline — закон одного ускорителя, но масштабируется именно его логика. На уровне парка связывающей пропускной способностью становится не HBM, а межсоединение, а перемещаемые байты — градиенты и активации, пересекающие сеть. Это отношение сетевых байтов к локальной арифметике — отношение коммуникации к вычислениям (раздел «Отношение коммуникации к вычислениям»): roofline парка и линза, через которую смотрит остальная часть этого раздела.

Задание обучения, выделенное на 4 096 GPU, достигает лишь 2,5× пропускной способности запуска на 1 024 GPU. Это наблюдение подразумевает эффективность масштабирования около 31,2 % при большем размере, поэтому физика масштабирования дает диагностические инструменты, чтобы определить, работает ли система так, как позволяет физика, или есть инженерная проблема, которую нужно исправить.

Закон Амдала в масштабе парка

Закон Амдала устанавливает, что максимальное ускорение параллельной системы ограничено ее последовательной долей $s$. В масштабе парка «последовательная доля» — не только последовательный код: она включает любую операцию, которая заставляет ждать все $N$ GPU:

• Синхронизация AllReduce: все GPU должны завершить вычисление градиентов, прежде чем кто-либо сможет продолжить.
• Пузыри конвейера: фазы разогрева и остывания конвейерного параллелизма оставляют стадии простаивающими.
• Записи контрольных точек: даже асинхронные контрольные точки конкурируют за пропускную способность хранилища.
• Накладные расходы на уровне Python: однопоточные операции в цикле обучения (загрузка данных, журналирование метрик).

Чтобы увидеть следствия для масштаба парка, рассмотрим нагрузку обучения, в которой 10 % времени по часам тратится на синхронизацию, коммуникацию и прочие последовательные накладные расходы. Закон Амдала дает следующие ускорения:

• На 32 GPU: ускорение 7,8× (~24 % эффективности масштабирования)
• На 256 GPU: ускорение 9,7× (начинается убывающая отдача)
• На 1 024 GPU: ускорение 9,9× (приближение к потолку)
• На 8 192 GPU: ускорение 10× (почти предел Амдала)
• При $N\to \infty$: ограничение 10×

При последовательных накладных расходах всего 10 % никакое количество железа не даст ускорения больше 10× на этой фиксированной нагрузке. Поэтому обучение в масштабе парка не просто добавляет GPU к той же задаче, а масштабирует саму задачу (слабое масштабирование), чтобы последовательная доля оставалась малой относительно общей работы.

Перспектива: ловушка составных накладных расходов

Приведенная выше последовательная доля 10 % оптимистична. На практике последовательные накладные расходы в масштабе парка складываются из нескольких источников: 5 % пузыри конвейера + 3 % контрольные точки + 10 % восстановление после отказов + 5 % обслуживание. Не все они строго последовательны в смысле Амдала (часть перекрывается с вычислениями), но они показывают, как быстро малые накладные расходы по категориям складываются в значительную потерю пропускной способности.

Отношение коммуникации к вычислениям

Любая стратегия распределенного обучения должна определить, достаточно ли долго идут вычисления между точками синхронизации, чтобы скрыть коммуникацию. Уравнение определяет отношение коммуникации к вычислениям ($\rho$), которое прямо отвечает на этот вопрос:

$$\rho =\frac{T_{\text{comm}}(N)}{T_{\text{compute}}/N}$$

Когда $\rho <1$, доминируют вычисления, и коммуникацию можно перекрыть. Когда $\rho >1$, система ограничена коммуникацией: GPU тратят больше времени на ожидание данных, чем на их вычисление.

Отношения коммуникации к вычислениям для типичных сценариев (таблица «Отношение коммуникации к вычислениям ($\rho$)») показывают, почему стратегия параллелизма должна соответствовать нагрузке.

Отношение коммуникации к вычислениям ($\rho$): когда $\rho \ll 1$, коммуникацию можно полностью перекрыть с вычислениями. Когда $\rho \gg 1$, система ограничена коммуникацией, и GPU простаивают в ожидании данных. Строка NVLink — нижняя граница двухточечной передачи только по пропускной способности; коллективная операция тензорного параллелизма несет еще и затраты на топологию, задержку и конкуренцию.

Модель на 7 млрд параметров на 256 GPU достигает $\rho =$ 0,11: коммуникация занимает около 11,2 % времени вычислений и может быть частично перекрыта. У модели на 350 млн на том же кластере $\rho =$ 3: доминирует коммуникация, и эта конфигурация ограничена коммуникацией. Решение — либо использовать меньше GPU (уменьшить $N$ в AllReduce), либо увеличить вычисления на шаг (больший размер батча, накопление градиентов).

Для одной двухточечной нагрузки в 16 МБ идеальная нижняя граница только по пропускной способности равна $\rho =$ 0,036. Это не модель коллективной операции тензорного параллелизма, и сама по себе она не может установить, ограничена ли реализация вычислениями.

Слабое масштабирование в масштабе парка

Закон Амдала рисует пессимистичную картину, потому что предполагает фиксированный размер задачи. На практике обучение в масштабе парка часто следует слабому масштабированию: размер задачи (токены, данные, параметры модели) растет пропорционально числу GPU. Закон Густафсона отражает этот более оптимистичный взгляд (Gustafson, 1988).

Главная мысль для ML в масштабе парка: слабое масштабирование — не просто математическое удобство, а отражение реальности. Инженеры не используют 8 192 GPU, чтобы быстрее обучить модель на 7 млрд; они используют их, чтобы за разумное время обучить модель на 70 или 700 млрд. По мере роста моделей и батчей обучения инженеры часто увеличивают вычисления между точками синхронизации. Для плотных трансформеров вычисления обычно оценивают примерно как 6$\times$ параметры $\times$ токены, тогда как коммуникация градиентов растет с числом байт параметров, поэтому отношение коммуникации к вычислениям $\rho$ зависит от размера батча, длины последовательности, накопления и раскладки параллелизма, а не только от числа параметров.

Перспектива: составная потеря утилизации парка

Кластер из 1 024 GPU H100 имеет суммарную пиковую пропускную способность 1 012 736 TFLOP/с. Эта иллюстративная декомпозиция держит факторы непересекающимися: MFU представляет эффективность ядер и памяти на устройство, эффективность масштабирования — потери распределенной коммуникации и конвейера, а операционный goodput — контрольные точки, восстановление после отказов и обслуживание. Эффективная пропускная способность равна:

$$R_{\text{eff}}=N{R}_{\text{peak}}\times \text{MFU}\times {\eta }_{\text{scaling}}\times {\eta }_{\text{operational}}$$

$$=1012736\text{ TFLOP/с}\times 0,50\times 0,50\times 0,82\approx 207610,9\text{ TFLOP/с}$$

Кластер отдает 20,5 % своих пиковых FLOP/с как полезную работу обучения. Остальные 79,5 % объясняются сохраненными факторами: 50 % MFU, 50 % эффективности масштабирования и 82 % операционного goodput.

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

Физика тепла и мощности

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

Проект кластера на 10 000 GPU H100 по 700 Вт каждый — 7 МВт нагрузки ИТ — при PUE 1,40 дает нагрузку объекта 9,8 МВт в целом. Это электрическая нагрузка небольшого города. Прежде чем оптимизировать программное обеспечение, подача энергии и отвод тепла должны быть физически осуществимы.

Стена плотности мощности

Переход от традиционных нагрузок дата-центров к обучению ИИ создал кризис плотности мощности. Таблица «Плотность мощности: традиционные нагрузки и нагрузки ИИ» количественно показывает разрыв.

Плотность мощности: традиционные нагрузки и нагрузки ИИ: стойки ИИ потребляют примерно в 5,8× больше мощности, чем традиционные стойки. Воздушное охлаждение физически не может отводить тепло достаточно быстро выше ~30 кВт на стойку, что делает жидкостное охлаждение обязательным для современных кластеров ИИ.

Рост плотности мощности стойки в 5,8× между традиционными нагрузками и нагрузками ИИ — не просто инженерная задача, а фундаментальное ограничение на проект объекта. Существующие дата-центры, построенные под стойки 12 кВт, нельзя просто «дооснастить» оборудованием ИИ. Электрическое распределение, инфраструктуру охлаждения и нагрузку на пол нужно проектировать заново. Поэтому новые дата-центры для ИИ строят с нуля, принимая жидкостное охлаждение за базовое допущение.

Иерархия энергии в масштабе

PUE измеряет накладные расходы энергии объекта: полная энергия объекта, деленная на энергию ИТ-оборудования (The Green Grid, 2007; Uptime Institute, 2022). PUE 1,0 означал бы, что вся энергия объекта доставляется ИТ-оборудованию; значения выше 1,0 представляют накладные расходы на охлаждение, преобразование энергии, освещение и другие системы объекта.

Таблица «Эффективность использования энергии (PUE)» сравнивает PUE разных поколений дата-центров и технологий охлаждения.

Эффективность использования энергии (PUE): чем ниже, тем лучше. Жидкостное охлаждение дает PUE около 1,0, потому что отводит тепло прямо от чипа без промежуточной стадии нагрева воздуха. Разрыв между устаревшим (1,58) и жидкостным (1,06) означает примерно 32,9 % сокращения полной мощности объекта при фиксированной нагрузке ИТ; накладные расходы вне ИТ падают с 0,58 МВт до 0,06 МВт на МВт нагрузки ИТ.

В расчетах стоимости в масштабе парка PUE напрямую умножает счет за электричество. Нагрузка ИТ 10 МВт в устаревшем дата-центре (PUE 1,58) требует 15,8 МВт в целом, а та же нагрузка в объекте с жидкостным охлаждением (PUE 1,06) — всего 10,6 МВт: экономия 5,2 МВт. При типичных коммерческих тарифах на электроэнергию эта разница выливается в миллионы долларов в год. Полные следствия для устойчивости рассматривает глава «Устойчивый ИИ».

Итоги

Ключевые выводы: масштаб парка меняет каждое ограничение

• Три парадигмы, один гибрид: парки ML сочетают тесную связь HPC (для обучения) с эластичной отказоустойчивостью WSC (для инференса) и создают новую архитектурную парадигму, которая не может принять паттерны ни одного из предшественников целиком.
• Разрыв пропускной способности: NVLink обеспечивает в ~9× больше пропускной способности в одном направлении, чем InfiniBand NDR. Этот инвариантный коэффициент определяет размещение параллелизма: тензорный параллелизм внутри узлов, параллелизм по данным между узлами.
• Отказы становятся рутиной в масштабе: MTBF кластера масштабируется как $1/N$. На 8 192 GPU ожидайте отказ GPU примерно каждые 366,2 мин с вероятностью 98,04 % за 24 часа. Отказоустойчивость не опциональна, а необходима для завершения любого задания обучения в масштабе парка.
• Составная потеря утилизации: после накопления непересекающихся факторов MFU (~50 %), эффективности масштабирования (~50 %) и операционного goodput (~82 %) кластер из 1 024 GPU отдает ~20,5 % пиковых FLOP/с как полезную работу.
• Плотность мощности требует жидкостного охлаждения: стойки ИИ потребляют в 5,8× больше мощности, чем традиционные. Воздушное охлаждение не справляется выше ~30 кВт на стойку, и жидкостное охлаждение становится физическим требованием для современных кластеров ИИ.
• Отношение коммуникации к вычислениям ($\rho$) определяет стратегию масштабирования: когда $\rho >1$, GPU простаивают в ожидании данных: уменьшайте параллелизм или увеличивайте вычисления на шаг. Когда $\rho \ll 1$, коммуникацию можно полностью перекрыть.
• Слабое масштабирование — парадигма масштаба парка: инженеры не используют больше GPU, чтобы быстрее решить ту же задачу (сильное масштабирование); они используют больше GPU, чтобы за разумное время решать более крупные задачи. Это удерживает последовательную долю малой, а утилизацию высокой.