Принципы парка

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

Такой переход требует принципиально иного взгляда. В масштабе отдельный GPU — лишь компонент более крупной, жестко связанной системы. Принципы парка — не лучшие практики управления кластерами, а физические инварианты, которые определяют, какие модели можно обучать и как их можно обслуживать. От термодинамических пределов рассеяния тепла до бисекционной пропускной способности сетевой фабрики — эти ограничения очерчивают границы стека парка. Общая закономерность повторяет одиночный узел: если узел связан сохранением сложности между данными, алгоритмом и машиной, то парк связан смещением накладных расходов между вычислениями, коммуникацией и координацией (таксономия C³). Налог на исполнение в масштабе нельзя устранить, его можно только переместить.

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

Принцип «термодинамический предел»

Инвариант: необратимые вычисления и перемещение данных рассеивают электрическую энергию в виде тепла; в масштабе дата-центра практическим пределом становится скорость, с которой это тепло можно отвести. $${\dot{Q}}_{\text{IT}}\le {\dot{Q}}_{\text{remove,max}}(\text{площадка},\text{конфигурация охлаждения})$$ где ${\dot{Q}}_{\text{IT}}$ — тепло, выделяемое ИТ-оборудованием, а ${\dot{Q}}_{\text{remove,max}}$ — максимальная скорость отвода тепла установленной площадкой и конфигурацией охлаждения.

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

На уровне стойки тот же тепловой бюджет превращается в ограничение плотности.

Принцип «стена плотности мощности»

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

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

Тепловая мощность задает внешнюю границу; внутри нее емкость памяти определяет, как нужно делить передовые модели.

Принцип «разрыв емкости памяти»

Инвариант: требования передовых моделей к памяти растут быстрее и неравномернее, чем емкость HBM одного ускорителя.

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

Когда модель разделена между устройствами, сеть становится частью пути исполнения.

Принцип «теорема о бисекционной пропускной способности»

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

Следствие: синхронное обучение требует бисекционной пропускной способности, соразмерной трафику, который коллективные операции вроде AllReduce отправляют через фабрику. Fat-tree можно проектировать как неблокирующие сети, а сети Dragonfly обменивают меньшее число глобальных линков на зависящую от нагрузки конкуренцию, с которой должны справляться маршрутизация и размещение.

Парк также задает баланс между универсальной гибкостью и аппаратной специализацией.

Принцип «налог на универсальность»

Инвариант: для нагрузок с устойчивыми паттернами вычислений специализация может повысить производительность на ватт за счет снижения универсальных накладных расходов, но одновременно снижает программируемость и гибкость в выборе нагрузок. $${\rho }_{\text{energy,specific}}\gg {\rho }_{\text{energy,general}}\text{при фиксированном бюджете мощности}$$

Следствие: траектория от CPU к GPU, далее к тензорному процессору (TPU) и к специализированной ASIC — архитектурный компромисс, зависящий от нагрузки, а не универсальный физический закон. Каждый шаг может обменять программируемость на эффективность, и архитектору парка нужно выбрать подходящую точку на этой кривой для каждой нагрузки.

Эффективность вычислений помогает только в том случае, если конвейер обучения успевает кормить ускорители.

Принцип «стена I/O»

Инвариант: когда пропускная способность хранилища не успевает отдавать обучающие данные так быстро, как ускорители их потребляют, GPU простаивают независимо от своей вычислительной мощности. $$\text{Загрузка}=\min \left(1,\frac{{\text{BW}}_{\text{storage}}}{N_{\text{GPU}}\times R_{\text{consumption}}}\right)$$ где ${\text{BW}}_{\text{storage}}$ — суммарная пропускная способность хранилища, $N_{\text{GPU}}$ — число ускорителей, а $R_{\text{consumption}}$ — скорость потребления данных каждым ускорителем.

Следствие: хранилище, которого хватало для 8 GPU, становится узким местом на 64. Стена I/O растет вместе с числом ускорителей: каждый GPU, добавленный в кластер, поднимает нижнюю границу пропускной способности, которую должно выдерживать хранилище, и ограничивающим фактором становится конвейер данных, а не модель.

Чтобы удовлетворить такой спрос, нужна иерархия, а не единый недифференцированный пул хранения.

Принцип «иерархия хранилищ»

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

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

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

Принцип «граница эффективности масштабирования»

Инвариант: добавление узлов в задание распределенного обучения дает убывающую отдачу, потому что коммуникационные накладные расходы растут вместе с размером кластера, а вычисления на узел остаются постоянными. $${\eta }_{\text{scaling}}=\frac{T_1}{N\times T_N}$$

Следствие: идеальное линейное масштабирование (${\eta }_{\text{scaling}}=1,0$) — идеальная линейная база, а не практическая цель. Хорошо настроенные задания плотного обучения обычно достигают ${\eta }_{\text{scaling}}\approx 0,85$–$0,95$ при умеренном масштабе на современных фабриках и теряют эффективность по мере роста $N$. Разрыв между ${\eta }_{\text{scaling}}=1,0$ и достигнутой эффективностью — коммуникационный налог, цена координации.

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