Сплануйте відтворюваний запуск PyTorch

Доведіть один повний крок перед масштабуванням

Зафіксуйте версії моделі та набору даних, версії залежностей, конфігурацію навчання, випадкові початкові значення та дайджест контейнера. Запустіть завантаження моделі, повний крок навчання, оцінювання, збереження контрольної точки та відновлення контрольної точки на одному прискорювачі.

Використовуйте ту саму довжину послідовності та налаштування мікробатчу, що й для довшого запуску. Крихітний пілотний запуск, який пропускає стан оптимізатора або використовує коротші послідовності, може приховати проблему з пам'яттю, яку ви намагаєтеся виміряти.

Виміряйте репрезентативний крок оптимізації

У межах наявної програми навчання оточіть репрезентативний крок вимірюванням пікового використання пам'яті. Приклад передбачає, що модель, пакет і оптимізатор уже ініціалізовано на GPU. Включіть крок оптимізатора, оскільки деякий стан створюється ліниво.

torch.cuda.reset_peak_memory_stats()
optimizer.zero_grad(set_to_none=True)
loss = model(**batch).loss
loss.backward()
optimizer.step()
torch.cuda.synchronize()
peak_gib = torch.cuda.max_memory_allocated() / 2**30
print(f"Peak tensor memory: {peak_gib:.2f} GiB")

Це показує пікове виділення тензорів, а не повний обсяг пам'яті пристрою. Також перевірте зарезервовану пам'ять, накладні витрати середовища виконання та системний звіт про пам'ять пристрою.

Обирайте DDP або шардинг з правильної причини

DistributedDataParallel зберігає репліку моделі в кожному процесі та синхронізує градієнти. Це корисно, коли повний стан навчання поміщається на кожному GPU і ви хочете обробляти більше даних паралельно; він не об'єднує VRAM в один безперервний пул.

Fully Sharded Data Parallel може розподіляти параметри, градієнти та стан оптимізатора. Використовуйте його, коли тиск на пам'ять виправдовує шардування, і враховуйте додаткову комунікацію та складність розподілених контрольних точок.

Змішана точність і контрольні точки активацій — це окремі рішення. Перевірте числову поведінку для нижчої точності; виміряйте обчислювальну вартість повторного обчислення активацій, коли контрольні точки економлять пам'ять.

Запустіть пілот на одному вузлі

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

torchrun --standalone --nproc-per-node=4 \
  train.py --config configs/pilot.yaml

Запускайте це лише на наданому вузлі. Локальна демонстрація AnchorGPU не виконує навчання та не виділяє віддалені GPU.

Виберіть обладнання за результатом пілотного запуску

Використовуйте A100 як дешевший базовий рівень 80 GB CUDA, і тестуйте H100, якщо робоче навантаження має корисний шлях, специфічний для Hopper. H200 пропонує більшу конфігурацію пам'яті CUDA. MI300X пропонує більшу ємність на прискорювач у цьому каталозі, за умови, що повна програма кваліфікована на ROCm.

Для AMD перевіряйте власні розширення, ядра, версії пакетів і образ PyTorch, протестований з ROCm, як єдиний комплект. Сумісність на рівні фреймворку не підтверджує кожну необов'язкову операцію.

Тестуйте відновлення, а не лише збереження

Записуйте модель, оптимізатор, планувальник, крок навчання, конфігурацію та стан масштабувальника змішаної точності, де це доречно. Збережіть контрольну точку, завершіть процес, потім відновіть і продовжте, перш ніж переходити до тривалого запуску.

Використовуйте метод контрольних точок, що відповідає розподіленому стану. Перевірте, що збережені артефакти можна прочитати незалежно від початкового процесу, а результат оцінювання залишається в межах очікуваної похибки.

Плануйте бюджет на весь конвеєр

Включіть завантаження, попередню обробку, завантаження даних, валідацію, створення контрольних точок, експорт і копіювання результатів з вузла. Вимірюйте пропускну здатність разом із пам'яттю, затримками завантаження даних, часом комунікації, тривалістю контрольних точок і якістю валідації.

Термін 7 днів корисний для обмеженого проходу перевірки сумісності та профілювання. Обирайте резервування на 30 днів лише після того, як зможете оцінити корисну роботу та операційний запас. Більша кількість GPU допомагає лише тоді, коли додаткові обчислення переважають обмеження комунікації та вхідного конвеєра.