Deep Learning Tuning Playbook, часть 1: как начинать новый проект

Это не официально поддерживаемый продукт Google.

Варун Годболе†, Джордж И. Даль†, Джастин Гилмер†, Кристофер Дж. Шаллю‡, Захари Надо†

† Google Research, Brain Team · ‡ Гарвардский университет

О переводе

Deep Learning Tuning Playbook («Сборник рецептов по настройке глубокого обучения») — открытое руководство, лицензия CC BY 4.0. Перевод полный и разбит на три страницы:

1. Эта страница — для кого документ, зачем он и как начинать новый проект (архитектура, оптимизатор, размер батча, начальная конфигурация).
2. Часть 2: научный подход к улучшению модели — пошаговая стратегия тюнинга, планирование экспериментов, анализ результатов.
3. Часть 3: длительность обучения, конвейер и частые вопросы — сколько шагов обучать, оценка, чекпоинты, расписания learning rate, неустойчивость обучения, правила обновления оптимизаторов.

В оригинале многие подразделы спрятаны под «[Click to expand]» — здесь они раскрыты. Ссылки внутри документа ведут на соответствующие места перевода. Разделы, помеченные эмодзи 🤖, авторы считают открытыми исследовательскими вопросами. Примечания переводчика оформлены отдельными блоками.

Как читать вместе с курсом ChinaAI

Документ написан для тех, кто уже обучал нейросети. Самое полезное время для чтения — после урока «Как отлаживать обучение»: там вы впервые сами подбираете learning rate и смотрите на кривые потерь. Части 2 и 3 особенно пригодятся на ступени 5 (урок «Muon и стабильность обучения») и в выпускном проекте (урок «План выпускного проекта»). Новичку при первом чтении можно пропустить подразделы о расходе ресурсов и batch norm.

Для кого этот документ

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

Главное внимание мы уделяем процессу подбора гиперпараметров. Мы касаемся и других сторон обучения глубоких моделей, например реализации и оптимизации конвейера обучения, но не претендуем на полноту в этих вопросах.

Мы предполагаем, что задача машинного обучения — это обучение с учителем или что-то очень на него похожее (например, самообучение, self-supervised). Впрочем, часть рекомендаций может подойти и к задачам других типов.

Зачем нужен сборник рецептов по настройке

Сегодня, чтобы глубокие нейросети действительно хорошо работали на практике, приходится проделывать поразительно много рутинной работы и действовать во многом наугад. Хуже того, рецепты, которыми люди на деле добиваются хороших результатов в глубоком обучении, редко записываются. Статьи сглаживают путь к итоговым результатам, чтобы история выглядела стройнее, а у инженеров машинного обучения, решающих коммерческие задачи, редко бывает время отступить на шаг и обобщить свой процесс. Учебники обычно избегают практических советов и ставят на первое место фундаментальные принципы — даже если у авторов достаточно прикладного опыта, чтобы дать полезные советы. Готовясь писать этот документ, мы не нашли ни одной всеобъемлющей попытки объяснить, как получать хорошие результаты в глубоком обучении. Вместо этого мы нашли обрывки советов в блогах и соцсетях, приёмы, выглядывающие из приложений к научным статьям, отдельные разборы одного конкретного проекта или конвейера — и много путаницы. Между результатами, которых добиваются эксперты по глубокому обучению, и результатами менее опытных практиков, применяющих внешне похожие методы, — огромная пропасть. При этом сами эксперты охотно признают, что часть того, что они делают, может быть не слишком обоснована. По мере того как глубокое обучение взрослеет и всё сильнее влияет на мир, сообществу нужно больше материалов с полезными рецептами — со всеми практическими деталями, которые бывают так важны для хороших результатов.

Мы — команда из пяти исследователей и инженеров, которые много лет работают в глубоком обучении, некоторые — с 2006 года. Мы применяли глубокое обучение к задачам от распознавания речи до астрономии и многому научились по дороге. Этот документ вырос из нашего опыта обучения нейросетей, обучения новых инженеров машинного обучения и консультирования коллег по практике глубокого обучения. Хотя приятно видеть, как глубокое обучение прошло путь от подхода, который практиковали несколько академических лабораторий, до технологии, на которой работают продукты для миллиардов людей, как инженерная дисциплина оно всё ещё в младенчестве, и мы надеемся, что этот документ побудит других помочь систематизировать экспериментальные протоколы в этой области.

Документ появился, когда мы пытались кристаллизовать собственный подход к глубокому обучению, поэтому он отражает мнения авторов на момент написания, а не какую-то объективную истину. Наши собственные мучения с подбором гиперпараметров сделали его главной темой наших советов, но мы разбираем и другие важные проблемы, с которыми сталкивались в работе (или видели, как что-то идёт не так). Мы задумали этот документ как живой: он будет расти и меняться вместе с нашими взглядами. Например, материал об отладке и предотвращении сбоев обучения мы не смогли бы написать два года назад — он основан на недавних результатах и продолжающихся исследованиях. Неизбежно часть наших советов придётся обновить с учётом новых результатов и улучшенных рабочих процессов. Мы не знаем оптимального рецепта глубокого обучения, но, пока сообщество не начнёт записывать и обсуждать разные процедуры, нечего и надеяться его найти. Поэтому мы призываем читателей, не согласных с нашими советами, предлагать альтернативные рекомендации вместе с убедительными доказательствами, чтобы мы могли обновить руководство. Мы также будем рады увидеть другие руководства с иными рекомендациями, чтобы всем сообществом прийти к лучшим практикам. Наконец, разделы, помеченные эмодзи 🤖, — места, где мы хотели бы провести больше исследований. Только попытавшись написать это руководство, мы до конца осознали, как много интересных и обойдённых вниманием исследовательских вопросов скрывается в повседневной работе практика глубокого обучения.

Как начинать новый проект

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

Наши советы ниже исходят из следующих предположений:

• Основная работа по постановке задачи, чистке данных и т. п. уже проделана настолько, что тратить время на архитектуру модели и конфигурацию обучения имеет смысл.
• Уже есть конвейер (pipeline), который выполняет обучение и оценку, и запускать задания обучения и предсказания для разных интересующих моделей легко.
• Подходящие метрики выбраны и реализованы. Они должны как можно точнее отражать то, что будет измеряться в рабочей среде.

Выбор архитектуры модели

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

• Сначала добейтесь работы хорошо зарекомендовавшей себя, широко используемой архитектуры. Свою модель всегда можно построить позже.
• У архитектур обычно есть разные гиперпараметры, задающие размер модели и другие детали (например, число слоёв, ширину слоя, тип функции активации).
  • Поэтому выбрать архитектуру на деле значит выбрать семейство разных моделей (по одной на каждый набор гиперпараметров модели).
  • Как выбирать гиперпараметры модели, мы обсудим в разделах «Выбор начальной конфигурации» и «Научный подход к улучшению качества модели».
• По возможности найдите статью, где решается задача, максимально близкая к вашей, и воспроизведите её модель как отправную точку.

Выбор оптимизатора

Коротко: начните с оптимизатора, самого популярного для задач такого типа.

• Ни один оптимизатор не «лучший» для всех типов задач машинного обучения и архитектур моделей. Даже просто сравнить качество оптимизаторов — трудная задача. 🤖
• Мы советуем придерживаться хорошо зарекомендовавших себя популярных оптимизаторов, особенно в начале нового проекта.
  • В идеале выбирайте оптимизатор, который чаще всего используют для задач того же типа.
• Будьте готовы уделить внимание всем гиперпараметрам выбранного оптимизатора.
  • Оптимизаторы с большим числом гиперпараметров могут потребовать больше усилий на настройку, чтобы найти лучшую конфигурацию.
  • Это особенно важно на ранних этапах проекта, когда мы ищем лучшие значения разных других гиперпараметров (например, гиперпараметров архитектуры), а гиперпараметры оптимизатора считаем мешающими (nuisance).
  • На первых этапах проекта может быть лучше начать с более простого оптимизатора (например, SGD с фиксированным моментом или Adam с фиксированными $\epsilon$, $\beta_{1}$ и $\beta_{2}$), а позже перейти к более общему.
• Хорошо зарекомендовавшие себя оптимизаторы, которые нам нравятся (но не только они):
  • SGD с моментом (нам нравится вариант Нестерова);
  • Adam и NAdam — они более общие, чем SGD с моментом. Учтите, что у Adam 4 настраиваемых гиперпараметра, и все они могут быть важны!
    • См. «Как подбирать гиперпараметры Adam?»

Примечание переводчика

Документ вышел в 2023 году (последнее изменение репозитория — июнь 2024). Сегодня для трансформеров «самый популярный оптимизатор» — AdamW (Adam с отделённым затуханием весов); в 2025–2026 годах к нему добавился Muon для матриц весов (урок «Muon и стабильность обучения»). Сам совет — начинать с того, что работает у других на похожей задаче, — от этого не меняется. Как устроены SGD с моментом и Adam, объясняет урок «Momentum и Adam».

Выбор размера батча

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

• Размер батча — ключевой фактор, определяющий время обучения и расход вычислительных ресурсов.
• Увеличение размера батча часто сокращает время обучения. Это бывает очень полезно, потому что, например:
  • позволяет тщательнее подобрать гиперпараметры за фиксированное время и, возможно, получить лучшую итоговую модель;
  • сокращает задержку цикла разработки, и новые идеи можно проверять чаще.
• Увеличение размера батча может уменьшить, увеличить или не изменить расход ресурсов.
• Размер батча не следует считать гиперпараметром, который подбирают ради качества на валидационной выборке.
  • Если все гиперпараметры хорошо подобраны (особенно learning rate и гиперпараметры регуляризации) и шагов обучения достаточно, одного и того же итогового качества можно добиться с любым размером батча (см. Shallue et al. 2018).
  • См. «Почему размер батча не стоит подбирать ради качества на валидации?»

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

• Для данной модели и оптимизатора имеющееся оборудование обычно поддерживает некоторый диапазон размеров батча. Ограничивает его, как правило, память ускорителя.
• К сожалению, трудно посчитать, какие размеры батча поместятся в память, не запустив (или хотя бы не скомпилировав) программу обучения целиком.
• Проще всего обычно запустить задания обучения с разными размерами батча (например, со степенями двойки по возрастанию) на небольшое число шагов, пока одно из заданий не превысит доступную память.
• Для каждого размера батча нужно обучать достаточно долго, чтобы надёжно оценить пропускную способность обучения (training throughput):

$$\text{пропускная способность обучения} = \text{число примеров, обрабатываемых в секунду}$$

или, что то же самое, время одного шага:

$$\text{время шага} = \frac{\text{размер батча}}{\text{пропускная способность обучения}}$$

• Пока ускорители ещё не загружены полностью, при удвоении размера батча пропускная способность обучения тоже должна удваиваться (или хотя бы почти удваиваться). Иначе говоря, время шага должно оставаться постоянным (или почти постоянным) с ростом размера батча.
• Если это не так, в конвейере обучения есть узкое место — например, ввод-вывод или синхронизация между вычислительными узлами. Его стоит найти и устранить, прежде чем двигаться дальше.
• Если пропускная способность растёт только до некоторого максимального размера батча, рассматривать стоит лишь размеры до этого максимума, даже если оборудование поддерживает и больший.
  • Все выгоды большего батча предполагают, что пропускная способность растёт. Если не растёт, устраните узкое место или используйте меньший батч.
  • Накопление градиентов (gradient accumulation) имитирует размер батча больше того, что поддерживает оборудование, и поэтому никакого выигрыша в пропускной способности не даёт. В прикладной работе его, как правило, следует избегать.
• Эти шаги, возможно, придётся повторять при каждой смене модели или оптимизатора (например, другая архитектура может позволить поместить в память больший батч).

Пример с числами (примечание переводчика)

Допустим, на одной видеокарте вы замерили: батч 16 — 0,20 с на шаг (80 примеров в секунду), батч 32 — 0,21 с (≈152 примера в секунду), батч 64 — 0,40 с (160 примеров в секунду). От 16 к 32 пропускная способность почти удвоилась — ускоритель не был загружен. От 32 к 64 она почти не выросла, время шага удвоилось — карта уже загружена полностью. Значит, разумный предел — около 32: больший батч не ускоряет обработку примеров. Про накопление градиентов: в курсе 7 AI Research Foundations его используют, чтобы получить эффект большого батча на маленькой GPU, — это законный учебный приём, но авторы Playbook правы: быстрее от него обучение не станет, эпоха займёт столько же времени, что и с маленьким батчем.

Размер батча, минимизирующий время обучения

$$\text{время обучения} = \text{время шага} \times \text{общее число шагов}$$

• Часто можно считать время шага примерно постоянным для всех возможных размеров батча. Так бывает, когда параллельные вычисления не дают накладных расходов, а все узкие места обучения найдены и устранены (как искать узкие места — см. предыдущий раздел). На практике рост размера батча обычно даёт хоть какие-то накладные расходы.
• С ростом размера батча общее число шагов, нужное для достижения фиксированной цели по качеству, обычно уменьшается (при условии, что все важные гиперпараметры подбираются заново при смене размера батча; Shallue et al. 2018).
  • Например, удвоение размера батча может вдвое сократить нужное число шагов. Это называют идеальным масштабированием (perfect scaling).
  • Идеальное масштабирование выполняется для всех размеров батча до критического размера батча, за которым отдача убывает.
  • В конце концов рост размера батча перестаёт уменьшать число шагов обучения (но и никогда его не увеличивает).
• Поэтому размер батча, минимизирующий время обучения, — обычно самый большой размер батча, который ещё уменьшает нужное число шагов обучения.
  • Этот размер зависит от набора данных, модели и оптимизатора, и как его вычислить, кроме как экспериментально для каждой новой задачи, — открытый вопрос. 🤖
  • Сравнивая размеры батча, помните о разнице между бюджетом в примерах или эпохах (все эксперименты с фиксированным числом предъявлений обучающих примеров) и бюджетом в шагах (все эксперименты с фиксированным числом шагов обучения).
    • Сравнение размеров батча при бюджете в эпохах исследует только режим идеального масштабирования, даже если большие батчи могли бы ещё заметно ускорить обучение, сократив нужное число шагов.
  • Часто самый большой размер батча, который поддерживает оборудование, меньше критического. Поэтому хорошее практическое правило (без всяких экспериментов) — брать самый большой возможный батч.
• Нет смысла брать больший батч, если в итоге время обучения растёт.

flowchart LR
A["Батч ×2"] --> B{"Ниже критического размера?"}
B -->|"да"| C["Шагов нужно ~вдвое меньше: идеальное масштабирование"]
B -->|"нет"| D["Шагов почти столько же: отдача убывает"]
C --> E["Время обучения падает, если время шага не выросло"]

Как размер батча влияет на время обучения (схема переводчика)

Размер батча, минимизирующий расход ресурсов

• С увеличением размера батча связаны два вида затрат ресурсов:
  1. Первоначальные затраты, например покупка нового оборудования или переписывание конвейера обучения под обучение на нескольких GPU или TPU.
  2. Текущие затраты, например списания с ресурсного бюджета команды, счета облачного провайдера, расходы на электричество и обслуживание.
• Если первоначальные затраты на увеличение батча велики, может быть лучше отложить увеличение, пока проект не созреет и станет проще оценить соотношение затрат и выгод. Многохостовые параллельные программы обучения могут принести ошибки и тонкие проблемы, так что, вероятно, в любом случае лучше начать с более простого конвейера. (С другой стороны, большое ускорение обучения может оказаться очень полезным именно в начале работы, когда нужно много экспериментов по настройке.)
• Общие текущие затраты (они могут включать несколько разных видов затрат) мы называем «расходом ресурсов». Его можно разложить на составляющие:

$$\text{расход ресурсов} = \text{расход ресурсов на шаг} \times \text{общее число шагов}$$

• Увеличение размера батча обычно позволяет сократить общее число шагов. Вырастет расход ресурсов или упадёт, зависит от того, как изменится расход на шаг.
  • Увеличение размера батча может уменьшить расход ресурсов. Например, если каждый шаг с большим батчем можно выполнить на том же оборудовании, что и с меньшим (лишь немного увеличив время шага), то рост расхода на шаг может с лихвой перекрыться сокращением числа шагов.
  • Увеличение размера батча может не изменить расход ресурсов. Например, если удвоение батча вдвое сокращает нужное число шагов и вдвое увеличивает число используемых GPU, общий расход (в GPU-часах) не изменится.
  • Увеличение размера батча может увеличить расход ресурсов. Например, если для большего батча нужно более мощное оборудование, рост расхода на шаг может перевесить сокращение числа шагов.

При смене размера батча большинство гиперпараметров нужно подбирать заново

• Оптимальные значения большинства гиперпараметров чувствительны к размеру батча. Поэтому смена размера батча обычно требует начать процесс настройки заново.
• Сильнее всего с размером батча взаимодействуют — и поэтому важнее всего настраиваются отдельно для каждого размера батча — гиперпараметры оптимизатора (например, learning rate, момент) и гиперпараметры регуляризации.
• Помните об этом, выбирая размер батча в начале проекта. Если позже придётся перейти на другой размер, может оказаться трудно, долго и дорого заново настраивать всё под новый размер батча.

Как batch norm взаимодействует с размером батча

• Батч-нормализация (batch norm) — штука сложная, и, как правило, для вычисления её статистик следует использовать размер батча, отличный от того, по которому считается градиент. Подробное обсуждение — в разделе о batch norm.

Выбор начальной конфигурации

• Прежде чем начинать подбор гиперпараметров, нужно определить отправную точку. Это включает (1) конфигурацию модели (например, число слоёв), (2) гиперпараметры оптимизатора (например, learning rate) и (3) число шагов обучения.
• Чтобы определить начальную конфигурацию, понадобится несколько обучающих запусков, настроенных вручную, и метод проб и ошибок.
• Наш руководящий принцип — найти простую, относительно быструю и относительно нетребовательную к ресурсам конфигурацию, которая даёт «разумный» результат.
  • «Простая» значит без излишеств, где только можно; их всегда можно добавить позже. Даже если излишества в итоге окажутся полезными, добавив их в начальную конфигурацию, вы рискуете потратить время на настройку бесполезных возможностей и (или) зашить в систему ненужные усложнения.
    • Например, начните с постоянного learning rate, прежде чем добавлять причудливые расписания затухания.
  • Быстрая и экономная начальная конфигурация сделает подбор гиперпараметров гораздо эффективнее.
    • Например, начните с модели поменьше.
  • «Разумное» качество зависит от задачи, но как минимум означает, что обученная модель на валидационной выборке работает намного лучше случайного угадывания (хотя может быть настолько плохой, что выпускать её не стоит).
• Выбор числа шагов обучения требует найти равновесие между двумя противоположными соображениями:
  • С одной стороны, обучение на большем числе шагов может улучшить качество и упрощает подбор гиперпараметров (см. Shallue et al. 2018).
  • С другой стороны, обучение на меньшем числе шагов означает, что каждый запуск быстрее и тратит меньше ресурсов, а это повышает эффективность настройки: сокращается время между циклами и можно параллельно запускать больше экспериментов. Кроме того, если поначалу выбрать неоправданно большой бюджет шагов, позже его может быть трудно уменьшить, например после того, как расписание learning rate уже настроено под это число шагов.

🖥 На вашей машине (примечание переводчика)

Совет «найдите самый большой батч, при котором растёт пропускная способность» легко проверить на практике. Возьмите модель из урока «GPT на PyTorch» и на одной RTX 4080 прогоните по 20 шагов с батчами 8, 16, 32, 64, 128, замеряя time.perf_counter() вокруг шага (после torch.cuda.synchronize()). Постройте график «примеров в секунду» от размера батча: где он выходит на плато — там и предел. Затем то же на четырёх картах с DDP (урок «Четыре видеокарты: DDP и FSDP на практике»): без NVLink синхронизация градиентов через PCIe может стать тем самым узким местом, о котором говорят авторы.

Словарик

English	Русский
tuning playbook	сборник рецептов по настройке
hyperparameter tuning	подбор (настройка) гиперпараметров
training pipeline	конвейер обучения
supervised / self-supervised learning	обучение с учителем / самообучение
optimizer	оптимизатор
nuisance hyperparameter	мешающий гиперпараметр
batch size	размер батча
accelerator memory	память ускорителя
training throughput	пропускная способность обучения
time per step	время шага
gradient accumulation	накопление градиентов
perfect scaling	идеальное масштабирование
critical batch size	критический размер батча
epoch budget / step budget	бюджет в эпохах / бюджет в шагах
upfront costs / usage costs	первоначальные / текущие затраты
resource consumption	расход ресурсов
batch normalization	батч-нормализация
initial configuration	начальная конфигурация
learning rate decay schedule	расписание затухания learning rate