Основы D·A·M

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

Цели обучения

• Классифицировать узкие места одной машины по доминирующей оси — данные, алгоритм или машина — и при этом замечать смешанные причины
• Сопоставлять техники оптимизации с зоной их пересечения в D·A·M, чтобы понимать, какие оси они охватывают
• Применять уравнение железного закона для количественной диагностики проблем производительности
• Различать нагрузки, ограниченные памятью и ограниченные вычислениями, по арифметической интенсивности
• Подбирать подходящие инструменты профилирования и стратегии оптимизации для каждой оси: данные, алгоритм или машина
• Оценивать состояние системы по метрикам оценочной карты D·A·M (накладные расходы ввода-вывода, активные параметры, MFU)

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

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

Когда обучение на одном GPU идет медленно, проверьте загрузку, время ожидания данных и утилизацию FLOP модели (MFU), а затем сопоставьте каждую метрику с осью: данные, алгоритм или машина. Когда обслуживание не укладывается в цель по задержке, определите, к какому режиму оно относится: ограничено задержкой (накладные расходы), ограничено памятью (перемещение весов и KV) или ограничено вычислениями. Когда стоимость растет лавинообразно, используйте рубрику D·A·M, чтобы усилия были направлены на доминирующий член, а не на неузкое место.

Таксономия «Данные · Алгоритм · Машина» (D·A·M) — основная диагностическая рамка системной инженерии ML. Она формализует взаимозависимость потока информации, математической логики и физического исполнения. Когда производительность останавливается или поведение деградирует, спросите: где заблокирован поток? Эта таксономия помогает практикам разложить узкие места по трем диагностическим осям,¹ не забывая, что в реальных системах причины могут быть смешанными или оси могут взаимодействовать.

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

Таксономия напрямую связана с железным законом ML-систем, введенным в разделе «Закон парка». Таблица «Справочник по осям D·A·M» суммирует роль, основное физическое ограничение и главный путь оптимизации для каждой оси.

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

Отображение на железный закон

Назвав три оси, свяжем их со временем. Производительность любой задачи ML определяется распределением работы по осям D·A·M, а отображение на железный закон показывает, переменные какого компонента доминируют в исполнении:

$$T=\underset{\text{Данные (D)}}{\underbrace{\frac{D_{\text{vol}}}{\text{BW}}}}+\underset{\text{Алгоритм (A)/Машина (M)}}{\underbrace{\frac{O}{R_{\text{peak}}\cdot {\eta }_{\text{hw}}}}}+\underset{\text{Накладные расходы}}{\underbrace{L_{\text{lat}}}}$$

Алгоритм и машина делят вычислительный член и различаются тем, какой переменной управляет инженер. Сокращение общего числа операций ($O$) — рычаг алгоритма, а повышение пиковой пропускной способности железа ($R_{\text{peak}}$) или его загрузки (${\eta }_{\text{hw}}$) — рычаг машины.

Координация D·A·M: от суммы к максимуму

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

$$T_{\text{sequential}}=\frac{D_{\text{vol}}}{\text{BW}}+\frac{O}{R_{\text{peak}}\cdot {\eta }_{\text{hw}}}+L_{\text{lat}}\stackrel{\text{перекрытие}}{\to }{T}_{\text{pipelined}}\ge \max \left(\frac{D_{\text{vol}}}{\text{BW}},\frac{O}{R_{\text{peak}}\cdot {\eta }_{\text{hw}}}\right)+L_{\text{lat}}$$

Задача системного инженера — сделать так, чтобы эти компоненты работали параллельно, а не последовательно. Таблица «Техники перекрытия D·A·M» суммирует ключевые техники координации D·A·M:

Техники перекрытия D·A·M: каждая техника позволяет одной оси D·A·M выполняться, пока другая в процессе, и превращает аддитивные члены железного закона в перекрытые.

Граница арифметической интенсивности

Эта картина перекрытия оставляет один практический вопрос: ждет ли нагрузка байты или FLOP. Граница между данными (ограничение памятью) и машиной (ограничение вычислениями) не произвольна: она математически определяется арифметической интенсивностью² ($I$) нагрузки.

Приведенные ниже симптомы — скрининговые сигналы, а не диагнозы. Нагрузка, арифметическая интенсивность которой лежит левее $R_{\text{peak}}/\text{BW}$, не может обеспечить ускоритель достаточной полезной работой на байт, но саму загрузку нужно читать вместе с загрузкой пропускной способности памяти, ожиданием загрузчика данных, заполняемостью ядер и разрывами на трассе.

• Низкая загрузка GPU ($<$ 80 %): проверьте голодание по данным, по CPU или по запуску. Подтвердите ожиданием загрузчика данных, насыщением CPU хоста, счетчиками пропускной способности памяти и разрывами на временной шкале.
• Высокая загрузка GPU ($>$ 95 %): считайте нагрузку ограниченной машиной, только если вычислительные блоки заняты, а пропускная способность памяти не насыщена. Если пропускная способность памяти насыщена, узкое место по-прежнему лежит на границе данных и машины.
• Если размер батча равен 1: воспринимайте это как предупреждение, что могут иметь значение задержка или накладные расходы запуска. Для декодирования больших языковых моделей (LLM) исполнение с батчем 1 часто ограничено пропускной способностью памяти, если только трассы не показывают разрывы диспетчеризации.
• Если арифметическая интенсивность ниже точки перегиба (около 295,2 FLOP/байт на H100): нагрузка, скорее всего, ограничена памятью (граница данных и машины).

Диагностика узкого места

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

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

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

Когда таблица действий сузила вероятное исправление, карта инструментов определяет измерения, нужные для проверки. Используйте таблицу «Карта инструментов D·A·M», чтобы выбрать подходящий инструмент профилирования при диагностике узкого места по конкретной оси D·A·M:

Карта инструментов D·A·M: утилиты профилирования для диагностики узких мест по каждой оси D·A·M.

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

Коэффициенты эффективности в таблице «Рубрика эффективности D·A·M» оценивают производительность системы относительно ее теоретического предела. Эта карта опирается на MFU,³ отношение достигнутых модельных FLOP/с к теоретическому пику FLOP/с железа.

Рубрика эффективности D·A·M: эти три числа характеризуют зрелость одной машины.

Масштабирование таксономии: от узла к парку

Эти оценки для одного узла наиболее полезны, когда их переносят в распределенное проектирование. Таксономия D·A·M — диагностическая основа для одной машины, но при переходе от одного узла к парку машинного обучения каждая ось претерпевает качественное преобразование. Понимание этих связей необходимо для перехода от локальной оптимизации к инженерии масштаба парка.

Эволюция ограничений

Таблица «D·A·M: ограничения от узла к парку» отображает каждую ось от ее фокуса на уровне узла к преобразованию в масштабе парка:

D·A·M: ограничения от узла к парку: как смещается каждая ось таксономии D·A·M при переходе от одного узла к многоузловому парку. Фокус на уровне узла (слева) уступает место качественно иному ограничению масштаба парка (справа); узкое место мигрирует от локального ресурса к глобальной стоимости координации.

Мост к $C^3$

Если D·A·M диагностирует компоненты одного узла, то таксономия $C^3$ (приложение «Таксономия C³») диагностирует взаимодействия парка.

1. Вычисления ($C_1$) наследуют оси алгоритма и машины, но добавляют потерю эффективности масштабирования.
2. Коммуникация ($C_2$) наследует ось данных, но определяется скоростью света и топологией сети, а не только локальным вводом-выводом.
3. Координация ($C_3$) — это связка «в масштабе», у которой нет эквивалента на одном узле. Она представляет налог на координацию: время на синхронизацию, контрольные точки и восстановление после отказов, которое проявляется только в масштабе парка.

Такая последовательность гарантирует, что эффективность одного узла (высокий MFU) никогда не приносится в жертву неэффективности масштаба парка (низкой эффективности масштабирования). Узел оптимизируется, чтобы служить парку.

Итоги

Таксономия D·A·M дает диагностическую основу для любого анализа ML-систем. Локализуя узкое место в данных, алгоритме или машине, практики добиваются того, что усилия оптимизации направлены на связывающее ограничение. Эта дисциплина одного узла — предпосылка для инженерии масштаба парка, которой посвящена вся книга.

Ключевые выводы: диагностические эвристики одной машины

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

1. MECE (Mutually Exclusive, Collectively Exhaustive — взаимоисключающие и в совокупности исчерпывающие): принцип классификации из управленческого консалтинга (популяризирован McKinsey), требующий, чтобы категории не пересекались и вместе покрывали все возможности. В системной инженерии он полезен как идеализированное разложение, но узкие места D·A·M на практике часто пересекаются: одно ядро может быть одновременно ограничено памятью, тяжелым по синхронизации и плохо согласованным с доступным железом. ↩

2. Арифметическая интенсивность: отношение числа операций с плавающей запятой к числу переданных байт (FLOP/байт). Сравнение с точкой перегиба железа ($R_{\text{peak}}/\text{BW}$) определяет, ограничена ли нагрузка памятью или вычислениями. ↩

3. MFU (model FLOPs utilization — утилизация FLOP модели): измеряет только полезные вычисления модели, не учитывая накладные расходы вроде синхронизации градиентов и управления памятью. ↩