Parallelism and Memory Engineering

Зачем

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

Как считать память

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

• Weights / параметры — живут всё время forward/backward; если модель не помещается в HBM, обычно это первый кандидат.
• Gradients — растут с batch и шириной модели; после backward они становятся обязательным участником всех comm-операций.
• Optimizer states (Adam/Adafactor и т.д.) — в FP16/BF16 это часто самый дорогой дополнительный слой.
• Activations / buffers — особенно важны при длинном контексте и длинной последовательности микробатчей.

Что даёт DP/TP/PP/FSDP

• DP (Data Parallelism) убирает нехватку throughput за счет data scaling, но почти не уменьшает memory footprint модели на каждом ранке.
• TP (Tensor Parallelism) режет матричные операции внутри слоя и снижает per-GPU footprint параметров, но делает сеть чувствительной к topology.
• PP (Pipeline Parallelism) уменьшает per-GPU веса/активации, но даёт bubbles на границах stages.
• FSDP/ZeRO-style sharding режет параметры, градиенты и optimizer states по ранкам и часто даёт самый сильный memory lift.
• Activation checkpointing не экономит напрямую state, но резко снижает footprint за счет recomputation.

Как выбрать план

Важен порядок: сначала устраняем базовый bottleneck (память), потом смотрим, где вырастает overhead из-за коммуникаций, и только после этого меняем topology.

Mini decision tree

• Если OOM из-за параметров/optimizer state: сначала precision → micro-batch → sharding (FSDP/ZeRO).
• Если после этого bottleneck в сети: проверяем all-gather/reduce-scatter частоты и TP/PP расстановку.
• Если есть pipeline bubbles: балансируем PP stages и micro-steps до целевого utilization.
• Если рост ошибок в resuming/restore: убираем сложный режим, упорядочиваем checkpoint pipeline и версии config.

Как пройти собеседование по этому узлу

Тут обычно проверяют логику: где bottleneck, что меняется в профиле памяти и почему ты выбрал конкретную связку DP/TP/PP/FSDP именно для данного GPU бюджета.

Интерактивная мыслительная модель

Проверка конфигурации идёт по 4 зонам: HBM, communication, pipeline bubbles и checkpoint I/O risk. То есть мы смотрим не на «идеальную формулу», а на фактический режим работы конкретного job.

Неочевидные точки для собеседования: topology может быть важнее теории, resume semantics и checkpoint policy ломают долгие тренировки, а I/O может стать новой вершиной bottleneck после шардирования.