Smol Training Playbook, часть 2: пост-обучение и инфраструктура

О странице

Это пересказ своими словами (почему не перевод — см. часть 1). Числа и названия сверены с исходным текстом книги. Близкие темы полностью переведены в разделе: SFT — LLM Course, глава 11, DPO — smol course, юнит 2, GRPO — LLM Course, глава 12, устройство GPU — Ultra-Scale Playbook, часть 4.

Коротко

• Сначала оценки, потом обучение. Набор бенчмарков для пост-обучения нужно собрать и проверить до первого запуска; авторы признаются, что поторопились, и RULER у них заработал за несколько дней до релиза.
• Почти любой конвейер начинается с SFT: это дёшево, стабильно и даёт основную часть выигрыша. Самые важные гиперпараметры — скорость обучения, размер батча и упаковка примеров.
• «Вайб-тесты» ловят то, чего не видят метрики. Простой разговор с моделью выявил баг, из-за которого из данных пропали все системные сообщения, и неумение модели переключать режим рассуждения после первой реплики.
• Mid-training на рассуждениях (продолжение предобучения на дистиллированных цепочках рассуждений) почти утроил результаты на AIME25 и LiveCodeBench в режиме рассуждения.
• Оптимизация предпочтений (DPO и её варианты, у SmolLM3 — APO-zero) учит модель не только вежливости, но и лучше рассуждать. RL с проверяемыми наградами работает, но требует аккуратной формы награды.
• Инфраструктура — это поиск узких мест: пропускная способность падает на порядки от памяти GPU к сети и дискам. Число GPU оценивают формулой через $6ND$ и реалистичный MFU, а схему параллелизма — бенчмарками.

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

Пост-обучение — это ступень 6 курса: SFT, DPO, GRPO; оценки — урок 7.3.1. Глава об инфраструктуре дополняет урок 5.7.1 и Ultra-Scale Playbook. Глава о пост-обучении читается почти как самостоятельная книга; инфраструктурную главу новичку достаточно пролистать, задержавшись на итоговой таблице пропускной способности и расчёте числа GPU.

Пост-обучение: компас и цель SmolLM3

Тот же компас, что и для предобучения. Зачем? Нужно ли вообще дообучать — может, готовая модель с Hub уже решает задачу? Есть ли у вас качественные данные предметной области? Можете ли вы измерить успех? Что? Послушный исполнитель инструкций, универсальный ассистент, «движок рассуждений» для математики и кода, многоязычный собеседник? Как? SFT, оптимизация предпочтений, RL, подбор данных и оценки.

Цель SmolLM3 — гибридная модель рассуждений: два режима, включаемых в системном сообщении командами /think (развёрнутое рассуждение) и /no_think (краткий ответ), по образцу Qwen3. Дополнительные требования: рассуждения не должны разваливаться на других языках, нужны вызов инструментов и длинный контекст.

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

Оценки прежде всего

Авторы предлагают многослойный набор оценок:

Слой	Что меряет	Примеры из книги
Базовые способности	знания, математика, код, языки	GPQA Diamond, AIME 2025, MATH-500, LiveCodeBench, Global MMLU, MGSM
Интегральные задачи	длинный контекст, следование инструкциям, согласованность с намерением пользователя, инструменты	RULER, HELMET, IFEval, IFBench, Multi-IF, AlpacaEval, ArenaHard, MixEval, BFCL, TAU-Bench
Защита от переобучения	устойчивость к возмущённым задачам	GSMPlus
Внутренние оценки	то, чего нет в публичных наборах	своя версия Multi-IF для многоходовых рассуждений
«Вайб-тесты» и арены	живое общение с моделью	ручные проверки, LMArena (сигнал слабый: любит лесть и цветистость)

Итоговый набор для SmolLM3: AIME25 (avg@64), LiveCodeBench, GPQA Diamond, IFEval, MixEval Hard, BFCL v3, Global MMLU, GSMPlus и RULER. Отдельное предупреждение: очищайте обучающие данные от утечек бенчмарков (n-граммное сравнение, например скриптами Open-R1) — особенно если данные синтетические.

Правила игры для оценок (в нашем пересказе):

1. Ускоряйте итерации подмножествами задач, которые хорошо коррелируют с полным набором.
2. У моделей-рассуждателей убирайте цепочку рассуждений из оцениваемого ответа.
3. Если судья — LLM, фиксируйте модель и версию; лучше открытую, чтобы оценка оставалась воспроизводимой.
4. Опасайтесь загрязнения базовой модели: многие модели, вышедшие до AIME 2025, на нём заметно хуже, чем на AIME 2024.
5. Всё, на что вы смотрели при абляциях, — это валидация, а не тест; держите отложенные бенчмарки для финального отчёта.
6. Для маленьких бенчмарков (меньше ~2 тыс. задач) делайте $k$ сэмплов и усредняйте (avg@k).
7. Новую оценку сначала проверьте: воспроизводит ли она опубликованные результаты.
8. Сомневаетесь — смотрите на сами данные и промпты.

Инструменты

Авторы сравнивают фреймворки пост-обучения: TRL, Axolotl, OpenInstruct, Unsloth, verl, Prime RL, PipelineRL, ART, TorchForge, NeMo RL, OpenRLHF — по поддержке SFT, оптимизации предпочтений, RL, мультимодальности, полного дообучения, LoRA и распределённого обучения. Сами используют TRL (они его разрабатывают) и советуют держать внутренний форк фреймворка, чтобы быстро добавлять новое. Отдельно — спор с любителями «всё писать с нуля»: реализовать PPO самому один раз полезно для понимания, но для реальной работы лучше взять фреймворк и доработать его.

SFT: почему с него начинают почти всегда

SFT дешёв, стабилен и даёт правильную отправную точку для DPO и RL. Исключение — передний край вроде DeepSeek-R1-Zero, где сильной модели-учителя нет и рассуждения приходится «открывать» RL-ом.

Базовая модель. Выбирайте размер под будущее развёртывание; плотные модели проще дообучать, чем MoE; смотрите на репутацию — получались ли из этой базы хорошие дообученные модели. По опыту авторов, лучше всего дообучаются базы Qwen, Mistral и DeepSeek, а у Qwen ещё и широкий ряд размеров (Qwen3 — от 0,6B до 235B).

Первая базовая линия. Берите данные, на которых уже учили отличные модели, а не те, что хорошо выглядят на бумаге: при работе над SmolLM датасет WebInstruct сделал модель «слишком научной» — на «как дела?» она отвечала уравнениями. Для SmolLM3 стартовая смесь — около 97 тыс. примеров: Everyday Conversations, SystemChats, Tulu 3 (в режиме /no_think) и те же диалоги, перегенерированные Qwen3-32B с рассуждениями, плюс s1k-1.1 (в режиме /think).

Балансируйте по токенам, а не по примерам

В стартовой смеси SmolLM3 набор s1k-1.1 — меньше 1 % примеров, но около 11 % токенов: его ответы с рассуждениями очень длинные. Если считать доли по числу примеров, легко незаметно перекосить смесь.

Шаблон чата. До обучения нужно решить: может ли пользователь задать свою системную роль, нужны ли инструменты, как обрабатывать блоки <think>…</think> в многоходовом диалоге (часто прошлые рассуждения выбрасывают из контекста).

«Детские» базовые линии и вайб-тесты. Перед большими экспериментами — простые прогоны: полное дообучение (FullFT), скорость обучения $10^{-5}$, эффективный батч 128, одна эпоха; три смеси — только без рассуждений, только с рассуждениями и гибрид. Общение с моделями выявило два сюрприза: из-за ошибки в обработке данных из корпуса пропали все системные сообщения, а гибридная модель включала режим рассуждения только в первой реплике. Для второго авторы сделали набор IFThink — многоходовые диалоги с инструкциями и рассуждениями, сгенерированные Qwen3-32B.

Какие гиперпараметры важны в SFT:

• маскирование потерь — учить только на токенах ассистента (в TRL для этого шаблон помечает реплики ассистента тегом generation);
• упаковка (packing) нескольких примеров в одну последовательность резко ускоряет обучение; на больших наборах она почти всегда выгодна, на маленьких «ручных» наборах её иногда стоит выключить;
• скорость обучения на порядок и более ниже, чем при предобучении, иначе модель «забывает» знания; у авторов лучше всего работали $3 \cdot 10^{-6}$ — $10^{-5}$, а с упаковкой безопаснее чуть меньше;
• эпохи: в абляциях одна, в финале несколько (пять эпох добавили несколько процентных пунктов в среднем).

Продолжение предобучения на рассуждениях

Если SFT упирается в потолок, может помочь mid-training — продолжение предобучения на большом объёме цепочек рассуждений. Авторы взяли Mixture of Thoughts (350 тыс. примеров из DeepSeek-R1), отфильтрованный набор NVIDIA Llama-Nemotron-Post-Training (≈3,64 млн примеров, 18,7 млрд токенов) и OpenThoughts3-1.2M (16,5 млрд токенов). Лучше всего сработала комбинация. Результат после SFT поверх такой модели: в режиме /think AIME25 и LiveCodeBench почти утроились, GPQA Diamond вырос на 10 пунктов, и даже режим /no_think прибавил 4–6 пунктов.

По дороге случилась «тайна плавящихся GPU»: старые карты перегревались и отваливались, а при переходе с DeepSpeed на простой параллелизм по данным потери стали совсем другими. Причина — ошибка в Accelerate: веса и градиенты хранились в BF16 без мастер-копии в FP32. Мораль авторов: часто сохраняйте чекпоинты во внешнее хранилище и делайте обучение устойчивым к перезапускам.

Оптимизация предпочтений

SFT копирует демонстрации — включая ошибки и неуклюжие рассуждения. Оптимизация предпочтений даёт сравнительный сигнал «ответ A лучше ответа B». Данные можно получить двумя способами: «сильная модель против слабой» (ответ Qwen3-32B — выбранный, ответ Qwen3-0.6B — отвергнутый; так авторы сделали 250+ тыс. пар с рассуждениями) или on-policy — несколько ответов самой обучаемой модели, оценённых верификатором или моделью награды.

Алгоритмы: DPO — простой и стабильный стандарт (Hugging Face доказали его применимость моделью Zephyr 7B), а также KTO (оценка отдельных ответов «хорошо/плохо» без пар), ORPO (предпочтения прямо внутри SFT, без модели-эталона), APO (явно управляет, как должны сдвигаться вероятности выбранного и отвергнутого). У SmolLM3 лучшим оказался APO-zero: на IFEval +15–20 пунктов к SFT-чекпоинту и лучший результат вне своей области.

Правила игры для предпочтений:

• не бойтесь генерировать свои данные предпочтений — инференс сейчас дешёвый;
• начинайте с DPO как базовой линии, затем пробуйте ORPO, KTO, APO;
• скорость обучения примерно в 10 раз ниже, чем в SFT (сканировать в диапазоне в 5–20 раз ниже);
• $\beta$ перебирайте в диапазоне 0,01–0,5 (у SmolLM3 лучшим было $\beta = 0{,}1$);
• большинство алгоритмов переобучаются после одной эпохи — делите данные и учите итеративно.

RL и альтернативы

RL имеет смысл, когда правильность можно проверить автоматически (тесты, проверка ответа), когда задача многошаговая и когда цель не сводится к меткам предпочтений. Авторы различают RLHF (модель награды учится на сравнениях людей) и RLVR (награда от верификатора, как в DeepSeek-R1).

В сам релиз SmolLM3 RL не вошёл — не хватило времени, а модель уже была лучшей в своём классе после офлайн-оптимизации предпочтений. После релиза авторы попробовали GRPO на математике (Big-Math) для режима /no_think и получили показательный взлом награды: модель, которую не просили рассуждать, начала писать длинные рассуждения, и режим /no_think стал похож на /think. Помог штраф за слишком длинные ответы из статьи DAPO; лучший компромисс давал порог длины около 2,5–3 тыс. токенов, и тогда GRPO почти удвоил результат на AIME 2025 по сравнению с офлайн-методами вроде APO.

Лёгкие альтернативы RL: онлайн-DPO (модель постоянно генерирует новые ответы и получает свежие метки) и on-policy дистилляция (сигнал — расхождение с учителем на ответах самого ученика; её использовали в Qwen3 для моделей меньше 32B).

flowchart LR
B["Базовая модель"] --> M["Mid-training на рассуждениях (если не хватает)"]
M --> S["SFT: гибридная смесь /think и /no_think"]
B --> S
S --> P["Оптимизация предпочтений: DPO → APO, ORPO, KTO"]
P --> R["RL с проверяемыми наградами (по желанию)"]
E["Оценки и вайб-тесты на каждом шаге"] -.-> S
E -.-> P
E -.-> R

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

Инфраструктура — невоспетый герой

Глава написана как практическое руководство по железу: каждый подраздел начинается с краткого вывода (TL;DR), и главная игра — найти и устранить узкое место.

Внутри GPU. GPU — процессор, оптимизированный под пропускную способность, а не под задержку. У него две задачи — перемещать данные и считать, и производительность определяется их балансом. Разбираются вычислительные блоки, тензорные ядра и точности, иерархия памяти от регистров до HBM, профилирование ядер в Nsight Compute и модель roofline («крыша»): упирается ли ядро в вычисления или в память.

Снаружи GPU. Связь CPU–GPU, GPU–GPU внутри узла (NVLink), между узлами (сеть EFA) и с хранилищем, с командами для диагностики. Итоговые измерения авторов на их кластере:

Уровень	Пропускная способность
Память HBM3 внутри одной GPU	≈3 ТБ/с
NVLink между GPU в узле	≈786 ГБ/с
Межузловая сеть, точка-точка	≈42 ГБ/с
PCIe Gen4 x8, CPU–GPU	≈14,2 ГБ/с
Локальный NVMe	≈26,6 ГиБ/с
Общая сетевая файловая система	до ≈1,1 ГиБ/с

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

У ваших 4× RTX 4080 обмен между картами идёт по PCIe, то есть по строке, которая в этой таблице в десятки раз медленнее NVLink. Поэтому всё, что в книге отнесено к «быстрой связи внутри узла» (тензорный параллелизм), у вас работает заметно хуже; перекрытие коммуникации с вычислениями и параллелизм по данным важнее.

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

Сколько GPU нужно. Формула авторов:

$$\text{число GPU} = \frac{\text{всего FLOP}}{\text{реальная производительность одной GPU} \times \text{время обучения}}$$

Для SmolLM3 — 379 по расчёту (подробно разобран в части 1), взяли 384. Ключевое — реальная, а не паспортная производительность: MFU около 30 %.

Схема параллелизма. Каждое измерение сначала проверяют отдельно и отбрасывают то, что сильно бьёт по пропускной способности. Для небольшой модели 3B конвейерный параллелизм проиграл из-за пузырей и коммуникации между узлами, а ZeRO выше нулевого уровня — из-за лишних all-gather и reduce-scatter. Итог SmolLM3: DP = 192, TP = 2 (внутри узла), микробатч 3, ZeRO-0; глобальный батч $192 \times 3 \times 4096 \approx 2{,}3$ млн токенов. Авторы честно отмечают, что часть решений продиктована состоянием Nanotron на тот момент (не было ZeRO-3 и эффективных конвейерных расписаний).

Заключение книги

Авторы сводят всё к нескольким принципам, общим для предобучения и пост-обучения: проверяйте всё экспериментами, меняйте одну вещь за раз, ждите, что масштаб сломает что-то новое, и пусть решения определяет ваш сценарий, а не очередная статья. Советы на будущее: ставьте эксперименты сами на маленькой модели, читайте исходный код фреймворков (Nanotron, TRL) и следите за свежими техотчётами. Финальная фраза в нашем переводе: «А теперь идите и обучите что-нибудь. И когда в два часа ночи потери загадочно подскочат, помните: за каждой отличной моделью стоят истории отладки».

Что сделать руками

1. Соберите свой набор оценок для дообучаемой модели из урока 6.1.2: один бенчмарк на знания, один на инструкции (IFEval), один «вайб-тест» из 10 своих вопросов. Проверьте, что результат известной модели совпадает с опубликованным.
2. Сделайте SFT-базу по рецепту авторов на маленькой модели (SmolLM2-360M или Qwen3-0.6B): скорость $10^{-5}$, одна эпоха, маскирование потерь на токенах ассистента; сравните с упаковкой и без.
3. Сгенерируйте пары «сильная против слабой» для 200–500 промптов (ответы большой и маленькой локальных моделей) и обучите DPO со скоростью в 10 раз ниже SFT и $\beta = 0{,}1$, как в уроке 6.3.3.
4. Измерьте свои «трубы»: скорость all-reduce между вашими GPU (скрипт из Ultra-Scale Playbook, приложение A0) и скорость чтения датасета с диска; добавьте строки в таблицу выше для своей машины.

Словарик

EN	RU
post-training	пост-обучение (всё после предобучения)
hybrid reasoning model	гибридная модель рассуждений (режимы /think и /no_think)
vibe test / vibe eval	«вайб-тест»: проверка живым общением
decontamination	очистка данных от утечек бенчмарков
benchmaxxing	подгонка модели под публичные бенчмарки
chat template	шаблон чата
loss masking, packing	маскирование потерь, упаковка примеров
mid-training, continued pretraining	продолжение предобучения
preference optimization: DPO, KTO, ORPO, APO	оптимизация предпочтений
strong vs. weak pairs	пары «сильная модель против слабой»
on-policy	на собственных ответах обучаемой модели
RLVR	RL с проверяемыми наградами
reward hacking	взлом награды
overlong completion penalty	штраф за слишком длинный ответ
on-policy distillation	дистилляция на ответах ученика
roofline model	модель roofline («крыша»)