Smol Training Playbook, часть 1: как Hugging Face предобучали SmolLM3

Почему пересказ, а не перевод

У самой статьи лицензия явно не указана: в репозитории Space лежит файл LICENSE с CC BY 4.0, но он относится к шаблону research-article-template, на котором сделана страница. Поэтому здесь — пересказ своими словами с короткими цитатами. Все числа сверены с исходным текстом (зеркало Space на GitHub). Вторая половина книги — часть 2: пост-обучение и инфраструктура.

The Smol Training Playbook — третья книга «трилогии» Hugging Face после поста о FineWeb и Ultra-Scale Playbook. Если Ultra-Scale Playbook отвечает на вопрос «как разложить обучение по тысячам GPU», то эта книга — о том, какие решения принимать и как их проверять, на примере реального проекта: SmolLM3, модели на 3 млрд параметров, обученной на 11 трлн токенов. Авторы честно показывают не только итоговый рецепт, но и тупики, сбои и перезапуски.

Коротко

• Сначала «зачем», потом «что», и только потом «как». Большинство провальных проектов обучения провалились не из-за гиперпараметров, а потому что модель никому не была нужна. Прежде чем обучать с нуля, проверьте, не решает ли задачу готовая модель с промптами или дообучением.
• Каждое решение проверяется маленьким экспериментом — абляцией. Меняйте одно за раз, оценивайте не только по функции потерь, но и по бенчмаркам, выбранным так, чтобы они давали сигнал рано. Абляции и отладка у SmolLM3 стоили больше половины основного запуска.
• Архитектура — консервативная. Плотный трансформер в стиле Llama, GQA, NoPE в каждом четвёртом слое, маскирование между документами, связанные эмбеддинги, AdamW и расписание WSD. Новинки берут, только если абляция показала пользу.
• Самые большие выигрыши дают данные. Смесь (сколько веба, кода, математики, других языков) подбирают абляциями, а лучшие маленькие наборы оставляют на конец обучения.
• На большом масштабе всё ломается по-новому. За месяц обучения команда столкнулась с падением пропускной способности из-за хранилища, с багом загрузчика данных, с плохим перемешиванием и с ошибкой инициализации в тензорном параллелизме, из-за которой пришлось перезапустить обучение после 1 трлн токенов.

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

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

Новичку на первом проходе можно пропустить длинные разделы о механизмах внимания и о MoE/гибридах (их суть ниже), а разделы «Компас», «Абляции», «Данные» и «Марафон» прочитать внимательно. К разделам о правилах экспериментов («Rules of Engagement») стоит вернуться перед планированием выпускного проекта.

Компас обучения: зачем → что → как

Авторы начинают с неудобного вопроса: а нужно ли вообще обучать свою модель? Открытые модели уровня Qwen, Gemma, DeepSeek, Kimi, OLMo выходят почти каждый день, и многие — с разрешительными лицензиями. Типичная ошибка выглядит так: у команды появилось 100 H100 на три месяца, и она решает «давайте что-нибудь обучим» — размер модели и данные выбираются наугад, а через полгода результат никому не нужен.

Обучать с нуля, по мнению авторов, имеет смысл в трёх случаях.

Причина	Пример	Что проверить заранее
Исследование	«Масштабируется ли новый оптимизатор до 10B+?», «Можно ли получить рассуждения одним RL без SFT?»	Сформулирована ли конкретная гипотеза и какой масштаб эксперимента нужен
Продакшн	Особая предметная область (ДНК, право, финансы), жёсткие ограничения развёртывания (дрон, FPGA), требования регулятора к полному контролю данных	Несколько дней поработать с Qwen3 или Gemma 3: не хватает ли промптов, инструментов или дообучения? Дообучить на 1 трлн токенов дешевле, чем учить с нуля на 10+ трлн
Открытый код	Нет сильной маленькой модели для устройств, слабая поддержка редких языков	Есть ли у вас лучшие данные, рецепт или вычисления, чем у других

Hugging Face сами обучают модели именно ради третьей причины: BLOOM появился как открытая альтернатива GPT-3, StarCoder — как открытая альтернатива Codex, семейство SmolLM — потому что сильных маленьких моделей почти не было.

Когда ответ на «зачем» есть, из него выводится «что»: модель для устройства → маленькая и эффективная; многоязычная → большой словарь токенизатора; сверхдлинный контекст → гибридная архитектура. Дальше два этапа: планирование (связать каждое ограничение с конкретной характеристикой модели) и проверка (абляции).

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

Мысль для выпускного проекта

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

Каждая большая модель начинается с маленькой абляции

Интуиция в обучении LLM часто обманывает. Пример авторов: данные arXiv кажутся «самыми качественными», но для маленьких моделей обучение на них не помогает и даже вредит — тексты слишком узкие и написаны специфическим академическим языком. Поэтому решения принимают по экспериментам. От абляции нужны две вещи: скорость (чем больше экспериментов, тем больше гипотез проверено) и надёжность (метрики должны различать варианты рано, а не тонуть в шуме).

Базовая модель и «снятие рисков»

Никто не проектирует архитектуру с нуля: Qwen начинали с архитектуры Llama, Llama 3 — с Llama 2, Kimi K2 — с DeepSeek-V3. Хорошая отправная точка подходит под ваши ограничения, проверена на триллионах токенов, хорошо документирована и поддерживается фреймворками. Авторы приводят таблицу кандидатов: плотные Llama 3.1/3.2, Qwen3, Gemma 3, SmolLM2/3; MoE Qwen3 MoE, gpt-oss, Kimi K2, DeepSeek-V3; гибридные Zamba2, Falcon-H1, Qwen3-Next и другие.

Главная дисциплина — derisking («снятие рисков»): ничего не менять, пока эксперимент не показал, что изменение помогает или даёт ощутимую пользу (скорость инференса, память, стабильность) без недопустимой потери качества. Изменения проверяют по одному; удачное становится новой базой для следующего. Перед каждым экспериментом два вопроса: поможет ли это моему сценарию? Оптимизирует ли это обучение? Если ни то ни другое — пропускаем.

Фреймворк

Сравниваются Megatron-LM и DeepSpeed (проверены временем, но огромные — около 200–270 тыс. строк кода), TorchTitan (лёгкий, около 9 тыс. строк, но молодой) и собственный Nanotron. Совет авторов в одну строку: не меняйте фреймворк между абляциями и основным запуском — «это дорога к страданиям».

Как устроены их абляции

• Два способа: учить целевую модель на меньшем числе токенов (SmolLM3 на 3B прогоняли на 100 млрд токенов вместо 11 трлн) или учить маленькую модель-заместителя (Kimi проверяли идеи для K2 на MoE с 3B параметров).
• Основная абляция SmolLM3 — модель 1B по схеме Llama 3.2 1B на 45 млрд токенов: около полутора суток на узле из 8× H100 (≈42 тыс. токенов в секунду на GPU).
• Что вредит в малом масштабе, можно смело отбрасывать; что помогает — нужно подтверждать на достаточном числе токенов и по возможности на целевом размере.
• При архитектурных абляциях следят за числом параметров: например, развязанные эмбеддинги удваивают их число, а GQA уменьшает параметры внимания — иначе сравнение нечестное.

Как оценивать

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

Важная тонкость — формулировка задачи. В формате «выбери букву A/B/C/D» (MCF) маленькие модели долго показывают случайный результат: для 1,7B MMLU в таком формате «оживает» лишь после 6 трлн токенов. Поэтому в абляциях используют cloze-формулировку (CF): сравнивают вероятности вариантов ответа, не показывая их в промпте, с нормировкой логарифма вероятности на число символов (чтобы не было перекоса в сторону коротких ответов). В набор входят MMLU, ARC, HellaSwag, WinoGrande, CommonSenseQA, OpenBookQA, PIQA, а для 3B — ещё GSM8K, HumanEval и RULER; по 1000 вопросов из каждого ради скорости. Всё считается в LightEval.

Сколько стоят абляции

Этап	GPU	Дней	GPU-часов
Основное предобучение	384	30	276 480
Абляции предобучения	192	15	69 120
Абляции mid-training	192	10	46 080
Перезапуск и отладка	384 / 192	3 / 4	46 080
Итого			437 760

Абляции и отладка заняли 161 280 GPU-часов — больше половины основного запуска; ещё около 10 тыс. GPU-часов ушло на оценки. Отсюда вывод: бюджет = обучение + абляции + запас на сюрпризы. Авторы отдельно замечают, что знаменитые «5,6 млн долларов на DeepSeek-V3» — это стоимость только финального запуска, а не исследований.

Правила игры: будьте параноиками

1. Проверьте, что ваш набор оценок воспроизводит опубликованные результаты известных моделей; генеративные задачи (вроде GSM8K) просмотрите глазами.
2. Тестируйте каждое изменение, даже «обновил библиотеку» и «поменял две строки».
3. Меняйте одну вещь за раз.
4. Учите на достаточном числе токенов и оценивайте достаточно широко.

Проектирование архитектуры

Цели SmolLM3: сильная модель для устройств, многоязычность, хорошие математика и код, надёжный длинный контекст. Отсюда плотная модель на 3B: достаточно большая для серьёзных способностей и достаточно маленькая для телефона. MoE отпала из-за памяти (на устройстве нужно держать в памяти всех экспертов), гибрид — из-за короткого срока проекта (около трёх месяцев).

Авторы сводят в таблицу, на чём сошлись ведущие открытые модели (DeepSeek, OLMo 2, Kimi K2, MiniMax-01, SmolLM3): все — трансформеры, различаются механизмом внимания (MHA, GQA, MLA), позиционным кодированием (RoPE, NoPE, частичный RoPE), расписанием скорости обучения (косинус, ступенчатое, WSD) и размером батча.

Что проверили и что выбрали

Решение	Что показали абляции	Выбор для SmolLM3
Внимание	GQA сохраняет качество MHA и сильно экономит KV-кэш; MLA не проверяли (не было в Nanotron)	GQA, 4 группы
Маскирование между документами	При обучении на склеенных документах токен не «видит» соседний документ; на коротком контексте качество не меняется, а длинный контекст и стабильность выигрывают	включено
Общие эмбеддинги	Для маленьких моделей связанные входные и выходные эмбеддинги экономят заметную долю параметров почти без потерь	связанные
Позиционное кодирование	NoPE (без позиционного кодирования) в части слоёв не портит короткий контекст и помогает длинному	NoPE в каждом 4-м слое, RoPE в остальных
Стабильность	Z-loss, отказ от weight decay для эмбеддингов, QK-norm; убирание weight decay с эмбеддингов снижает их норму без потери качества	weight decay не применяется к эмбеддингам
Форма модели	Глубокие и широкие варианты на 3B дали почти одинаковые результаты	более глубокая раскладка (как у Qwen2.5-3B)
Токенизатор	Сравнивали «плодовитость» (fertility — сколько токенов на слово) на целевых языках	токенизатор Llama 3.2, словарь 128 тыс.

Что такое Z-loss, в двух строках

К функции потерь добавляют штраф $\lambda \cdot \log^2 Z$, где $Z$ — знаменатель softmax над логитами. Если логиты разрастаются, $Z$ растёт, и штраф тянет их обратно. Это одна из мер против «скачков» функции потерь, о которых — в разделе «Марафон».

Изменения добавляли постепенно в порядке «от самых проверенных»: связанные эмбеддинги → GQA → маскирование документов → NoPE → отказ от weight decay для эмбеддингов.

MoE или нет

Архитектура	Плюсы	Минусы	Когда брать
Плотная	изучена, стабильна, поддерживается везде	вычисления растут линейно с размером	по умолчанию, особенно при ограничении памяти и в первом проекте
MoE	лучше качество на единицу вычислений	все эксперты в памяти, сложнее обучение и распределение	если память не ограничена и важна отдача от вычислений
Гибрид (трансформер + Mamba/SSM)	линейная сложность части операций, длинные контексты	меньше проверенных рецептов и поддержки	если нужен очень длинный контекст

Правила игры: решения диктует сценарий

Пусть архитектуру определяет то, где модель будет работать; держите баланс между новизной и прагматизмом (MHA вместо GQA сегодня — плохой выбор, но не гонитесь за каждой статьёй); проверяйте всё систематически; помните, что эффекты масштаба реальны — по возможности подтверждайте выводы на целевом размере; токенизатор выбирайте по его эффективности на ваших языках, а не «как у последней модели».

Оптимизатор и гиперпараметры

Брать числа из чужих статей — нормальная отправная точка, но они подобраны под чужие данные и ограничения. Авторы сравнили AdamW, AdEMAMix и Muon на модели 1B (100 млрд токенов): настроенный Muon обгонял AdamW, но был чувствителен к скорости обучения и склонен к расхождению; на 3B расхождения стали чаще. В итоге — «очень ванильно»: AdamW ($\beta_1 = 0{,}9$, $\beta_2 = 0{,}95$), weight decay 0,1, клиппинг градиента 1.

Расписание WSD (warmup — stable — decay: разогрев, долгая постоянная фаза, короткое затухание) по качеству догоняет косинус к концу обучения: во время постоянной фазы косинус впереди, но на фазе затухания WSD почти линейно нагоняет. Его главное преимущество — гибкость: можно продлить обучение или ответвить эксперимент с затуханием в любой момент. Обычно на затухание отводят 10–20 % токенов.

xychart-beta
title "Расписания скорости обучения (схема переводчика)"
x-axis "доля обучения, %" [0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100]
y-axis "скорость обучения, доля от максимума" 0 --> 1
line [0, 1, 1, 1, 1, 1, 1, 1, 1, 0.5, 0]
line [0, 0.98, 0.9, 0.79, 0.65, 0.5, 0.35, 0.21, 0.1, 0.02, 0]

Верхняя линия — WSD (затухание в последних 10–20 %), нижняя — косинус

Скорость обучения для SmolLM3 выбрали перебором: $2 \cdot 10^{-4}$ сходилась заметно быстрее $10^{-4}$, а $3 \cdot 10^{-4}$ давала лишь небольшой выигрыш ценой риска нестабильности. Глобальный батч от 2 до 4 млн токенов почти не влиял на качество, поэтому взяли 2,36 млн — при нём лучше пропускная способность.

Правило главы: «Готово лучше, чем идеально». Тратьте время на данные, а не на недели полировки мелочи; при равенстве выбирайте гибкое и стабильное; назначьте срок исследованиям и начните обучать.

Законы масштабирования и «переобучение»

Законы Чинчиллы (Hoffmann et al., 2022) говорят, как поделить фиксированный бюджет вычислений между размером модели и числом токенов. Но они не учитывают, что большая модель дороже после обучения, на инференсе. Поэтому сейчас модели сознательно «переобучают» (overtraining) — учат маленькую модель гораздо дольше, чем велит Чинчилла: Qwen3 заявляет 36 трлн токенов. Для SmolLM3 длину обучения определил бюджет: 384 H100 примерно на месяц при MFU около 30 % дают как раз 11 трлн токенов.

Проверим арифметику авторов (из главы об инфраструктуре)

Объём вычислений: $6 N D = 6 \cdot 3 \cdot 10^9 \cdot 11 \cdot 10^{12} \approx 1{,}98 \cdot 10^{23}$ FLOP. Пиковая производительность H100 в BF16 в книге принята за $720 \cdot 10^{12}$ FLOP/с, при MFU 30 % — $216 \cdot 10^{12}$. За 4 недели ($4 \cdot 604\,800$ с) одна GPU сделает $\approx 5{,}23 \cdot 10^{20}$ FLOP, значит, нужно $1{,}98 \cdot 10^{23} / 5{,}23 \cdot 10^{20} \approx 379$ GPU. Взяли 384.

Для вашей машины: модель 0,5B на 10 млрд токенов — $6 \cdot 0{,}5 \cdot 10^9 \cdot 10^{10} = 3 \cdot 10^{19}$ FLOP. Если предположить, что каждая из 4 карт реально выдаёт $3 \cdot 10^{13}$ FLOP/с, выйдет $3 \cdot 10^{19} / (1{,}2 \cdot 10^{14}) \approx 2{,}5 \cdot 10^5$ с — около 70 часов. Подставьте измеренную пропускную способность своей конфигурации.

Искусство подбора данных

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

Поэтому смесь меняют по ходу обучения (многоэтапное обучение, curriculum): обильные источники — в начале, маленькие высококачественные — к концу, когда идёт затухание скорости обучения, потому что поведение модели сильнее всего определяется данными последних этапов. Автоматические методы подбора долей (DoReMi, RHO-LOSS, RegMix) у авторов в итоге советовали примерно «естественные» пропорции и не обогнали ручные абляции.

Как подбирали смесь SmolLM3 (абляции — прямо на модели 3B, прогоны по 50–100 млрд токенов, плюс «отжиг» от промежуточного чекпоинта: 40 % старой смеси + 60 % кандидата, 50 млрд токенов):

Компонент	Что выяснили	Итог в этапе 1
Английский веб	FineWeb-Edu лучше на образовательных и STEM-задачах, DCLM — на здравом смысле; лучшие пропорции 60/40 или 50/50	FineWeb-Edu и DCLM 50/50, всего 5,1 трлн токенов
Другие языки	5 целевых языков из FineWeb2-HQ (628 млрд токенов) и ещё 10 языков понемногу, включая китайский и русский — чтобы сообществу было проще дообучать	около 12 % многоязычных данных — английский не страдает
Код	25 % кода (по совету литературы) заметно ухудшили английские бенчмарки; 10 % не помогли английскому, но код нужен сам по себе	10 %, Stack-Edu отложен на поздние этапы
Математика	Высококачественной математики мало (54 млрд токенов), больше — значит повторять 5+ раз	3 %: FineMath3+ и InfiWebMath3+

Итоговая пропорция этапа 1 — веб/многоязычное/код/математика примерно 75/12/10/3.

Марафон обучения

384 H100 (48 узлов), почти месяц, 11 трлн токенов. Перед стартом — чек-лист: резервирование узлов в Slurm на весь запуск; стресс-тест GPU (нашли и заменили две «троттлящие» карты); автоматические оценки каждого чекпоинта; автоматическое возобновление после сбоя; логирование всех метрик (потери, норма градиента, пропускная способность, температура и загрузка GPU); проверка конфигурации.

Четыре загадки

Симптом	Причина	Решение
Через несколько часов пропускная способность резко падает	Сетевое хранилище с «горячим» кэшем выталкивало куски 24-терабайтного датасета в S3	Данные — на локальные NVMe каждого узла; запасной узел с уже загруженными данными, чтобы заменять сломанный мгновенно
Провалы пропускной способности остаются и воспроизводятся даже на одном узле	Встроенный загрузчик данных Nanotron строил индекс, растущий с числом шагов	Переход на проверенный загрузчик TokenizedBytes из прошлого проекта
Функция потерь стала «шумнее»	Новый загрузчик читал последовательности одного документа подряд: длинный плохой файл кода мог занять целый батч	Заранее перемешать токенизированные последовательности (по своему зерну на каждую эпоху)
После 1 трлн токенов модель 3B отстаёт от SmolLM2 1.7B на том же этапе	В тензорном параллелизме (TP=2) все ранги инициализировались одним и тем же зерном — шарды весов получались коррелированными	Разные зёрна на разных рангах TP; обучение перезапущено с нуля

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

Урок для ваших экспериментов

Сохраняйте промежуточные оценки и сравнивайте их с эталонной моделью похожего размера — например, с промежуточными чекпоинтами SmolLM2, которые Hugging Face выложили открыто. Потери могут выглядеть идеально, когда модель учится хуже, чем должна.

Скачки функции потерь

Авторы делят скачки на восстанавливаемые (можно учить дальше или откатиться и пропустить «плохие» батчи) и невосстанавливаемые (расхождение или плато хуже прежнего). Частые причины: слишком большая скорость обучения, плохие данные, неудачное сочетание батча и состояния параметров, неудачная инициализация (OLMo 2 перешли на нормальное распределение со стандартным отклонением 0,02), низкая точность (FP16 у BLOOM). Профилактика: чистые и хорошо перемешанные данные (OLMo 2 убрали документы с многократно повторяющимися n-граммами), Z-loss, отказ от weight decay для эмбеддингов, QK-norm. Лечение: откат и пропуск батчей (PaLM пропускали 200–500 батчей вокруг скачка), временно более жёсткий клиппинг градиента.

Mid-training и длинный контекст

flowchart LR
S1["Этап 1: 8 трлн токенов, контекст 4k — основная смесь"] --> S2["Этап 2: 2 трлн, 4k — Stack-Edu, FineMath4+, MegaMath"]
S2 --> S3["Этап 3: 1,1 трлн, 4k — затухание LR, данные с рассуждениями и вопросами-ответами"]
S3 --> L1["4k → 32k: 50 млрд токенов, RoPE theta = 2M"]
L1 --> L2["32k → 64k: 50 млрд токенов, RoPE theta = 5M"]
L2 --> Y["128k на инференсе через YaRN"]

Этапы обучения SmolLM3 по данным книги (схема переводчика)

Длинный контекст наращивали ступенями, начиная для каждой ступени новое расписание скорости обучения. Базу частоты RoPE (theta) поднимали до 2M, затем до 5M: 10M чуть улучшал RULER, но портил короткие задачи вроде GSM8K. Специальная пересборка данных с длинными книгами и синтетикой не дала выигрыша — авторы связывают это с тем, что длинных документов в базовой смеси и так около 10 %, а NoPE помогает. Скользящее окно внимания на этом этапе было хуже полного внимания. 128k достигается экстраполяцией YaRN от чекпоинта 64k; 256k уже хуже, поэтому модель рекомендуют использовать до 128k.

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

1. Компас для своего проекта. Ответьте письменно: зачем вам обучать модель, какую (размер, тип, языки, контекст), и проверьте, не решает ли задачу готовая модель с промптом или LoRA. Пригодится в уроке 10.1.1.
2. Мини-абляция в проекте MiniMind. В уроке 5.6.2 измените одну вещь (например, связанные эмбеддинги или расписание WSD вместо косинуса), остальное оставьте как есть, и сравните не только потери, но и простой бенчмарк в cloze-формате.
3. Посчитайте бюджет. Формулой $6ND$ оцените, сколько часов займёт ваш план на 4 GPU, и добавьте к нему «налог на абляции» — по опыту SmolLM3, ещё половину.
4. Сравните с эталоном. Скачайте один-два промежуточных чекпоинта SmolLM2 и прогоните на них тот же набор оценок, что и на своей модели.

Словарик

EN	RU
ablation	абляция (контрольный эксперимент с одним изменением)
derisking	снятие рисков: ничего не менять без проверки
baseline	базовая модель, отправная точка
multiple choice format (MCF) / cloze formulation (CF)	формат «выбери букву» / сравнение вероятностей вариантов
fertility	«плодовитость» токенизатора: токенов на слово
tied embeddings	связанные (общие) входные и выходные эмбеддинги
NoPE	без позиционного кодирования
intra-document masking	маскирование внимания между документами
WSD (warmup–stable–decay)	расписание «разогрев — плато — затухание»
overtraining	обучение дольше, чем «оптимально» по Чинчилле
data mixture, curriculum	смесь данных, многоэтапное обучение
annealing	«отжиг»: финальная фаза с затуханием скорости обучения
loss spike	скачок функции потерь
throughput	пропускная способность (токенов в секунду)