Таксономия C³

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

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

Приложение задумано как справочник. Начните со сводной диагностической таблицы, сформулируйте гипотезу о том, какая ось C³ доминирует, а затем выберите инструмент, который может подтвердить (или опровергнуть) эту гипотезу.

Когда пропускная способность обучения низка, проверьте утилизацию FLOP модели (MFU), долю коммуникации и коэффициент goodput, а затем сопоставьте каждую метрику с осью вычислений, коммуникации или координации. Когда эффективность масштабирования падает ниже ожиданий, используйте разложение закона парка, чтобы определить, какой член вырос. Когда стоимость растет лавинообразно, используйте оценочную карту C³, чтобы усилия были направлены на доминирующий член, а не на неузкое место.

Таксономия C³ — диагностическая рамка для системной инженерии ML в масштабе парка. Если основы одной машины (введены в приложении «Основы D·A·M») диагностируют узкие места внутри одного узла — голодание по данным, алгоритмические накладные расходы или насыщение железа, — то таксономия C³ диагностирует узкие места по всему распределенному парку. Большинство проблем производительности в масштабе парка можно диагностировать, определив доминирующую ось: вычисления (делают ли ускорители полезную математику?), коммуникация (достаточно ли быстро сеть перемещает данные?) или координация (не тратит ли система слишком много времени на синхронизацию, восстановление после отказов и планирование?). Многие промышленные узкие места лежат на пересечениях этих осей.

От D·A·M к C³

Таксономия C³ не заменяет D·A·M, а расширяет ее. Когда нагрузка переходит с одной машины на парк, каждая ось D·A·M приобретает новые режимы отказа, которые рамка одной машины не может отразить. Таблица «Отображение D·A·M на C³» показывает, как происходит этот переход.

Отображение D·A·M на C³: как диагностические задачи одной машины обобщаются на задачи масштаба парка.

Самая важная строка в таблице «Отображение D·A·M на C³» — последняя. На одной машине член накладных расходов ($L_{\text{lat}}$) в железном законе обычно невелик: задержка запуска ядер, диспетчеризация Python, барьеры синхронизации. В масштабе парка координация становится самостоятельной осью: записи контрольных точек, обнаружение отказов и восстановление, накладные расходы пузырей конвейера, вытеснения планировщика и окна обслуживания вместе поглощают значительную долю времени по часам. Координация — ось, ради которой существует эта книга.

Сводка диагностики

С готовым отображением диагностика сводится к сопоставлению симптомов с осью, которая ограничивает парк. Таблица «Сводка диагностики C³» — основная справочная таблица для диагностики в масштабе парка. Каждая ось C³ отображается на физическое ограничение, наблюдаемые симптомы, измеряемые метрики и инженерные рычаги.

Сводка диагностики C³: каждая ось соответствует отдельному физическому ограничению и стратегии оптимизации с высоким рычагом. Начинайте диагностику отсюда: определите, какое ограничение связывает, и затем следуйте указателю оптимизации к нужной главе.

Закон парка

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

$$T_{\text{step}}(N)=\frac{T_{\text{compute}}}{N}+T_{\text{comm}}(N)+T_{\text{sync}}(N)-T_{\text{overlap}}$$

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

Разложение по компонентам

Каждый член закона парка отображается на конкретные измеримые виды деятельности:

• $T_{\text{compute}}/N$: проход вперед, проход назад, шаг оптимизатора — вся локальная арифметика после распределения по $N$ устройствам. Определяется MFU и эффективностью ядер на GPU. Улучшения приходят от лучших ядер, смешанной точности и слияния операторов.
• $T_{\text{comm}}(N)$: AllReduce градиентов, AllGather параметров (в FSDP/ZeRO), передачи активаций в тензорном и конвейерном параллелизме. Определяется пропускной способностью сети и выбором алгоритма коллективных операций. Улучшения приходят от сжатия градиентов, иерархических коллективных операций и перекрытия вычислений и коммуникации.
• $T_{\text{sync}}(N)$: барьеры синхронизации, записи контрольных точек, обнаружение отказов и восстановление, простой из-за пузырей конвейера, вытеснения планировщика и окна обслуживания. Определяется надежностью кластера и программным обеспечением оркестрации. Улучшения приходят от асинхронных контрольных точек, эластичного обучения и более быстрого обнаружения отказов.
• $T_{\text{overlap}}$: время коммуникации или координации, скрытое за полезной арифметикой. Определяется планированием и реализацией перекрытия.

Эффективность парка следует отсюда непосредственно:

$$f_{\text{compute}}=\frac{T_{\text{compute}}/N}{T_{\text{step}}(N)}$$

Когда $f_{\text{compute}}$ падает ниже 0,5, парк тратит больше времени на коммуникацию и координацию, чем на полезную арифметику. Эта доля времени вычислений — не полная эффективность парка; полезная эффективность парка зависит также от MFU, эффективности масштабирования и goodput. Таксономия C³ определяет, какой невычислительный член за это отвечает.

Ландшафт пересечений

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

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

Справочник пересечений C³: каждая зона сопоставляет конкретные техники с осями, которые они охватывают, и главами, где они рассматриваются. Парные пересечения требуют одновременных рассуждений о двух областях; центр требует всех трех.

Вычисления $\cap$ коммуникация

Это пересечение определяет, способна ли система скрыть коммуникацию за вычислениями. Отношение коммуникации к вычислениям ($\rho =T_{\text{comm}}(N)/(T_{\text{compute}}/N)$) — ключевая диагностическая метрика (раздел «Отношение коммуникации к вычислениям»). Когда $\rho <1$, вычисления занимают больше времени, чем коммуникация, и сетевую передачу теоретически можно перекрыть: система ограничена вычислениями и здорова. Когда $\rho >1$, GPU заканчивают локальную работу раньше, чем сеть доставляет следующий раунд операндов, и система становится ограниченной коммуникацией.

В трассе GPU это узкое место выглядит как открытые интервалы коммуникации, когда тензорные ядра простаивают в ожидании завершения коллективной операции (например, ncclKernel_AllReduce или ncclKernel_AllGather). Инженерная работа на этом пересечении сосредоточена на перекрытии и сжатии: запуск AllReduce во время прохода назад до финализации всех градиентов, конвейеризация передач активаций в расписаниях 1F1B, увеличение микробатчей или числа шагов накопления градиентов, чтобы разбавить частоту коммуникации, и применение квантования данных на линии в FP8 или INT4, чтобы вдвое сократить требуемый объем сетевой передачи («Распределенное обучение», «Коллективные коммуникации»).

Вычисления $\cap$ координация

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

Это пересечение определяют три различных механизма:

1. Пузыри конвейера: в конвейерном параллелизме (PP) стадии простаивают при заполнении (разогреве) и опустошении (остывании) конвейера. Для глубины конвейера $p$ и числа микробатчей $m$ доля пузыря $F_{\text{bubble}}=(p-1)/(m+p-1)$ напрямую растрачивает циклы ускорителя, если ее не скрывают чередующиеся расписания 1F1B.
2. Остановки на контрольных точках: синхронные записи контрольных точек, блокирующие цикл обучения ради сериализации терабайтов весов и состояний оптимизатора, превращают дорогое время вычислений во время ожидания хранилища. Асинхронные контрольные точки смягчают это: они делают снимок закрепленной памяти хоста или локальной памяти Non-Volatile Memory Express (NVMe) за миллисекунды, а удаленное сохранение поручают фоновым потокам ввода-вывода.
3. Откат при восстановлении: когда узел отказывает в кластере из $N$ узлов, обучение останавливается и откатывается к последней корректной контрольной точке, растрачивая арифметику, выполненную с момента этого снимка. Минимизация радиуса поражения отказа с помощью быстрых проверок состояния (heartbeat) и динамической замены узлов ограничивает эти потери вычислений («Отказоустойчивость», «Оркестрация парка»).

Коммуникация $\cap$ координация

Это пересечение описывает стоимость синхронизации, встроенную в сетевую коммуникацию. Каждая коллективная операция (AllReduce, AllGather, ReduceScatter) одновременно служит передачей данных по физическим проводам ($C_2$) и барьером на весь кластер ($C_3$). Все участники должны прийти к барьеру, прежде чем коллективная операция сможет завершиться.

Главный режим отказа — усиление отстающих. Если один GPU или канал испытывает потерю пакетов, тепловое дросселирование или задержки повторных попыток ECC, все остальные GPU в коллективной операции ждут, и локальная деградация превращается в остановку всего кластера. В масштабе парка ($N\ge 10000$) над временем барьера доминирует хвостовая задержка: вероятность того, что хотя бы один узел отстанет, приближается к единице ($1-(1-p_{\text{straggle}}{)}^N\to 1$).

Инженерная работа на этом пересечении сосредоточена на отделении синхронизации от самой коммуникации: иерархические коллективные операции, которые изолируют высокоскоростные внутриузловые домены NVLink от межузловых фабрик InfiniBand, принятие асинхронного обучения с ограниченным устареванием, чтобы поглощать кратковременную хвостовую задержку, и применение gang-планирования с учетом топологии, чтобы выровнять кольца коллективной коммуникации по физическим рельсам коммутаторов spine-leaf («Коллективные коммуникации», «Отказоустойчивость»).

Инженерия ML-систем масштаба парка

В центре ($C_1\cap C_2\cap C_3$) все три ограничения сходятся одновременно. Это дисциплина системной инженерии ML в масштабе парка. Системные инженеры в этом центре оптимизируют не один ускоритель или один сетевой коммутатор, а управляют компромиссами распределенной машины как единого целого.

Центральные инженерные задачи включают:

• Совместное проектирование 4D-параллелизма: баланс параллелизма по данным (DP), тензорного (TP), конвейерного (PP) и экспертного (EP) так, чтобы потребление памяти укладывалось в память с высокой пропускной способностью (HBM) ускорителя ($C_1$), высокочастотная коммуникация отображалась на внутриузловой NVLink, а низкочастотная — на межузловые фабрики ($C_2$), а пузыри конвейера и зависимости барьеров были минимальны ($C_3$).
• Шардинг памяти и объем коммуникации: фреймворки вроде PyTorch FSDP2 и DeepSpeed ZeRO-3 устраняют избыточность памяти ($C_1$), разбивая состояния модели между воркерами, но платят жесткий налог в виде повторяющейся коммуникации AllGather ($C_2$) и метаданных координации состояния ($C_3$).
• Целостная оптимизация goodput: метрика ML Productivity Goodput от Google операционализирует это тройное пересечение, разлагая продуктивность парка на программный goodput (${\eta }_{\text{program}}$, $C_1$), goodput среды выполнения (${\eta }_{\text{runtime}}$, $C_2$) и goodput планирования (${\eta }_{\text{scheduling}}$, $C_3$).

Координация и перекрытие C³

Как исполнение на одном узле превращает аддитивный железный закон в максимум, ограниченный зависимостями (раздел «Координация D·A·M: от суммы к максимуму»), так перекрытие в масштабе парка преобразует закон парка (раздел «Закон парка»), максимизируя $T_{\text{overlap}}$. Таблица «Техники перекрытия C³» суммирует основные техники перекрытия по измерениям C³.

Техники перекрытия C³: системные техники, скрывающие коммуникацию или координацию за полезными вычислениями и максимизирующие $T_{\text{overlap}}$ в законе парка.

Хранилище как постоянная основа

Типичный диагностический вопрос: почему хранилище не появляется как четвертая явная координата в таксономии C³ или как независимый член $T_{\text{storage}}$ в законе парка.

Физический дата-центр закупается вокруг вычислений, сети и хранилища («Хранение данных»). Но во время исполнения устройства хранения не выполняют арифметику модели. Поэтому накладные расходы хранилища проявляются динамически через три измерения C³:

• В вычислениях ($C_1$): высокопроизводительные локальные диски NVMe служат расширением третьего яруса иерархии памяти ускорителя (ниже SRAM и HBM) и обеспечивают выгрузку параметров (ZeRO-Offload) и вытеснение активаций.
• В коммуникации ($C_2$): потоковая подача удаленных наборов данных из параллельных файловых систем (Lustre, GPFS) или объектных хранилищ (S3, Ceph) делит пропускную способность сети кластера и емкость сетевой карты (NIC) с трафиком коллективной коммуникации.
• В координации ($C_3$): надежное распределенное хранилище дает опору постоянного состояния, необходимую для сериализации контрольных точек, отработки отказов узлов и перепланирования заданий.

Когда задержка хранилища останавливает запуск обучения, профилировщики определяют симптом не как сырую задержку диска, а либо как узкое место сетевой коммуникации ($C_2$, голодание по данным), либо как блокирующий барьер координации ($C_3$, синхронный сброс контрольной точки). Хранилище — постоянная основа, поддерживающая все три измерения, а не отдельный член бюджета исполнения шага.

Эмпирические правила

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

Светофор C³

Таблица «Светофор C³» дает пороговую сортировку для каждой оси C³.

Светофор C³: быстрые пороги сортировки для диагностики в масштабе парка. Зеленый означает, что ось здорова; желтый — что ее стоит изучить; красный — что это вероятное узкое место. Пороги предполагают хорошо оптимизированное обучение больших моделей на железе текущего поколения.

Таблица диагностики узких мест

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

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

Разборы случаев C³

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

Случай 1: недогруженный парк (вычисления)

Симптом

Инженерная команда выделяет 4 096 GPU H100 для запуска обучения большой языковой модели. Цикл обучения работает без ошибок, но PyTorch Profiler показывает MFU всего 15 %. Сетевой профилировщик показывает, что коммуникация занимает меньше 10 % времени шага. Кластер работает, но почти ничего не делает.

Диагноз

Узкое место — ось вычислений. При MFU 15 % 85 % пиковой мощности парка не засчитывается как полезные FLOP модели. Это не проблема коммуникации или координации: сеть достаточно быстрая, а система стабильна. Система неэффективно подает работу на GPU.

Исправление

Это проблема эффективности на GPU, которая просто умножена на 4 096 ускорителей. Нужно работать с осью вычислений:

• Смешанная точность: убедитесь, что задействованы тензорные ядра BF16/FP8. Частая причина — откат к FP32 в слоях нормализации или при вычислении потерь.
• Слияние операторов: используйте torch.compile или аналогичную JIT-компиляцию (just-in-time), чтобы объединять поэлементные операции и сокращать накладные расходы запуска ядер.
• Подбор размера батча: если размер батча на GPU слишком мал, у матричных умножений недостаточно арифметической интенсивности, чтобы насытить тензорные ядра.

Повышение MFU с 15 % до 50 % на том же железе дает 50 %/15 % = 3,3× больше полезной работы — эквивалент утроения парка без покупки ни одного GPU.

Случай 2: стена коммуникации (коммуникация)

Симптом

Запуск обучения с параллелизмом по данным на 512 GPU достигает иллюстративной эффективности фазы вычислений 45 % во время вычислительных ядер на каждом GPU — хорошая эффективность ядер на устройство. MFU по времени часов на всем шаге (включая AllReduce) составляет всего 20,2 %, потому что AllReduce поглощает 55 % каждого шага обучения. Масштабирование с 64 GPU до 512 GPU дает ускорение лишь в 4× вместо ожидаемого 8×, то есть эффективность масштабирования 50 %.

Диагноз

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

Исправление

Нужно работать с осью коммуникации, не трогая вычисления на GPU:

• Перекрытие вычислений и коммуникации: запускайте AllReduce во время прохода назад, а не ждите его завершения. Современные фреймворки (FSDP, DeepSpeed) поддерживают это нативно.
• Сжатие градиентов: примените разреживание TopK или квантование, чтобы сократить число байт, проходящих по сети, в 10–100$\times$.
• Иерархические коллективные операции: используйте внутриузловой NVLink для первой стадии редукции, а межузловой InfiniBand — только для межузловой агрегации, сокращая межузловой трафик в 8$\times$.

Если бы коммуникация была устранена полностью, пропускная способность выросла бы в 2,2× (закон Амдала, примененный к доле вычислений 45 %). Реалистично, снижение коммуникации с 55 % до 20 % времени шага вернуло бы большую часть потерянного масштабирования.

Случай 3: налог на координацию (координация)

Симптом

Запуск обучения на 10 000 GPU показывает MFU 40 % на устройство, а коммуникация занимает лишь 15 % времени шага — оба показателя здоровые. Однако коэффициент goodput задания (полезные шаги обучения в секунду, деленные на идеальную или выделенную скорость шагов) составляет только 60 %. Остальные 40 % времени по часам уходят на записи контрольных точек, перезапуски восстановления после отказов, простой из-за пузырей конвейера, вытеснения планировщика (17 % времени по часам) и окна обслуживания.

Диагноз

Доминирует ось координации. Вычисления на GPU и межузловая коммуникация эффективны, но 40 % времени по часам поглощают непродуктивные накладные расходы: 10 % на восстановление после отказов (на 10 000 GPU отказы GPU происходят примерно раз в 5 ч), 5 % на пузыри конвейера, 3 % на записи контрольных точек и 5 % на окна обслуживания. Ни более быстрые GPU, ни более быстрые сети не помогут: время уходит на координацию, а не на вычисления или коммуникацию.

Исправление

Нужно работать с осью координации:

• Асинхронные контрольные точки: перекрывайте записи контрольных точек со следующим шагом обучения, сокращая видимые накладные расходы контрольных точек с 3 % почти до нуля.
• Эластичное обучение: когда узел отказывает, сжимайте задание и продолжайте, а не останавливайте все 10 000 GPU ради восстановления. Это превращает стоимость восстановления после отказов 10 % в меньшее снижение пропускной способности.
• Оптимизация расписания конвейера: перейдите с GPipe на чередующееся расписание 1F1B, чтобы уменьшить долю пузыря, или увеличьте число микробатчей на сброс конвейера.
• Более быстрое обнаружение отказов: сократите тайм-аут heartbeat с 30 секунд до 5 с помощью аппаратного мониторинга состояния, уменьшив простой между возникновением отказа и началом восстановления.

Устранение неполадок в эксплуатации

Таблица «Матрица устранения неполадок C³» дает диагностическую матрицу для типичных режимов отказа в масштабе парка.

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

Карта инструментов

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

Карта инструментов C³: утилиты профилирования для диагностики узких мест в масштабе парка. Для быстрой сортировки начинайте с основного инструмента; для глубокого анализа используйте вторичные. Инструменты вычислений работают на уровне GPU; инструменты коммуникации — на сетевом уровне; инструменты координации — на уровне кластера или задания.

Оценочная карта C³

Оценочная карта C³ оценивает эффективность парка по известным порогам и расширяет оценочную карту одной машины (приложение «Основы D·A·M») на распределенную среду. Таблица «Рубрика эффективности C³» определяет три метрики, характеризующие здоровье парка.

Рубрика эффективности C³: эти три числа характеризуют здоровье парка. В знаменателе MFU используется суммарный пик парка, записываемый как $N{R}_{\text{peak,device}}$, когда $R_{\text{peak}}$ — значение на устройство. Парк, проходящий все три порога, исчерпал легкие оптимизации; дальнейший выигрыш требует архитектурных изменений, обновления железа или более крупных задач, чтобы улучшить режим масштабирования.

Дерево диагностики инфраструктуры C³ и оценочная карта D·A·M парка

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

Отображение сигналов телеметрии на стены C³

Современные кластеры GPU порождают плотную телеметрию по кремнию, шинам PCIe, тепловым датчикам и сетевым коммутаторам:

• Падения MFU: внезапные или устойчивые падения утилизации FLOP модели ниже ожидаемых базовых уровней.
• Повторы PCIe AER (Advanced Error Reporting): нефатальные ошибки шины, вызывающие повтор пакетов, понижение скорости линка (например, PCIe Gen 5 $\to$ Gen 3) или дросселирование прямого доступа к памяти (DMA) хост–устройство.
• Тепловое дросселирование: понижение тактовой частоты SM GPU (например, 1,9 ГГц $\to$ 1,1 ГГц), вызванное пределами температуры перехода или деградацией вентиляторов охлаждения.
• Остановки по кредитам InfiniBand и кадры паузы PFC: кадры паузы приоритетного управления потоком (PFC), пакеты уведомления о перегрузке (CNP) или голодание коммутатора по кредитам буфера.

Дерево диагностики

Приведенное ниже дерево диагностики, идущее от железа, ведет сортировку от первичных сигналов телеметрии к лежащей в основе стене C³ и действию по устранению.

                [Сигнал телеметрии / производительности]
                         [Обнаружена аномалия]
                                  |

                 /----------------+----------------\
                 v                                 v
       [Системная телеметрия]              [Сетевая телеметрия]
  [Падение MFU, нагрев, AER]         [Паузы PFC, остановки по кредитам]
                 |                                 |

          /------+------\                   /------+------\
          v             v                   v             v
      [Нагрев]        [PCIe]            [Кредиты IB]   [Высокая]
      [Темп.]         [AER]              [Остановки]   [хвостовая]
     [> 85 °C]      [Повторы]              [> 5 %]     [задержка]
          |             |                   |             |

          v             v                   v             v
    [СТЕНА ВЫЧИСЛЕНИЙ][СТЕНА ВЫЧИСЛЕНИЙ][СТЕНА КОММУНИКАЦИИ][СТЕНА КООРДИНАЦИИ]

     (Тепловое       (Деградация          (Перегрузка     (Барьер
    дросселирование)  шины PCIe)             сети)        отстающего)

Структурированная таблица диагностической телеметрии

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

Отображение диагностической телеметрии C³: прямое отображение сигналов телеметрии уровня кремния на стены распределенных узких мест и процедуры исправления.

Оценочная карта D·A·M парка

Оценочная карта D·A·M парка в таблице «Оценочная карта D·A·M парка» обобщает диагностику одного узла по данным, алгоритму и машине (D·A·M) на узкие места C³ в масштабе парка.

Оценочная карта D·A·M парка: количественно показывает, как аппаратная телеметрия одного узла отображается на ограничения исполнения C³ уровня парка.

Законы масштабирования через призму C³

Законы масштабирования обычно записывают в алгоритмических FLOP, но парк обучения отдает лишь те полезные FLOP, которые переживают потери утилизации, коммуникации и координации. Цели законов масштабирования напрямую переводятся в термины C³: скрытое допущение идеальных систем абстрагируется от потерь, а эффективные FLOP/с определяют используемую пропускную способность, связывающую прогнозы качества модели с реальной емкостью кластера.

Почему законы масштабирования предполагают идеальные C³

Законы масштабирования (Каплана, Chinchilla и их преемников) предсказывают качество модели как функцию алгоритмических вычислений обучения. Они обычно абстрагируются от системной эффективности: время по часам, пиковые FLOP/с ускорителя, эффективность фазы вычислений, накладные расходы коммуникации и потери планировщика учитываются позже, когда команды закупают железо, способное обеспечить целевой вычислительный бюджет. В терминах C³ FLOP из законов масштабирования нужно пересчитать в сырую емкость парка после потерь фазы вычислений, распределенного шага и операционного goodput.

Разрыв между предсказаниями законов масштабирования и наблюдаемыми результатами обучения в значительной мере — разрыв C³. Команда, закладывающая на обучение $10^{24}$ FLOP, на деле отдаст модели гораздо меньше эффективных FLOP, потому что каждый FLOP должен пережить три мультипликативных потери: эффективность фазы вычислений на GPU, межузловую эффективность масштабирования (${\eta }_{\text{scaling}}$) и операционный goodput.

Концепция эффективных FLOP/с

Эффективные FLOP/с парка — это используемая пропускная способность после перемножения трех непересекающихся факторов эффективности C³:

$$\text{Эффективная}=\text{Пиковая}\times \underset{\text{Вычисления}}{\underbrace{{\eta }_{\text{compute-phase}}}}\times \underset{\text{Распределенный шаг}}{\underbrace{{\eta }_{\text{scaling}}}}\times \underset{\text{Операционный goodput}}{\underbrace{{\eta }_{\text{operational}}}}$$

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

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

Перспектива: налог C³ на кластер из 100 000 GPU

Рассмотрим кластер из 100 000 GPU H100 с суммарной пиковой пропускной способностью 98 900 PFLOP/с. После трех непересекающихся факторов эффективности C³:

$$\text{Эффективная}=98900\text{ PFLOP/с}\times 0,50\times 0,35\times 0,65\approx 11249,9\text{ PFLOP/с}$$

Парк отдает 11,4 % своей пиковой мощности как полезную работу обучения. Налог C³ — отношение пика к эффективной мощности — равен 8,8×: чтобы получить заданный эффективный вычислительный бюджет, нужно в 8,8× больше сырого железа. Фаза вычислений сохраняет фактор эффективности 50 %. Распределенный шаг сохраняет фактор масштабирования 35 %, при этом эталон из 8 192 GPU используется как иллюстративный прокси, включающий потери конвейера. Эксплуатация сохраняет фактор goodput 65 % после контрольных точек, отказов, вытеснений планировщика и обслуживания.

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

Итоги

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

Ключевые выводы: куда смотреть в первую очередь в масштабе парка

• У каждого узкого места масштаба парка есть доминирующая ось C³: вычисления, коммуникация или координация, причем многие реальные узкие места лежат на пересечениях. Определите доминирующую ось до начала оптимизации.
• Измеряйте оценочную карту C³: прежде чем вкладываться в оптимизации, используйте MFU $>$ 50 %, эффективность масштабирования $>$ 70 % и коэффициент goodput $>$ 90 %.
• Налог C³ мультипликативен: пиковые FLOP/с $\times$ эффективность фазы вычислений $\times$ эффективность масштабирования $\times$ операционный goodput = эффективные FLOP/с. На 100 000 GPU ожидайте лишь ~11,4 % от пика.
• Координация — новая ось: на одной машине накладные расходы пренебрежимы. В масштабе парка контрольные точки, отказы, пузыри конвейера и планирование поглощают 40 % времени по часам и более.
• Оптимизация не той оси C³ дает ограниченное улучшение: более быстрые GPU сами по себе не исправят парк, ограниченный коммуникацией; более быстрые сети не исправят накладные расходы координации.