"Тренили OlympicCoder со следующими параметрами: Базовая модель: Qwen2.5 Coder Instruct 7B and 32B количество эпох: 10 батч сайз: 128 Learning rate: 4e-5 Scheduler: Cosine with a decay to 10% of the peak learning rate длина контекста: 32,768 токенов для 7B и 22,528 токенов 32B И вот что выяснили Урок 1: packing ухудшает качество рассуждений Упаковка образцов – это широко применяемый метод для эффективной обработки последовательностей переменной длины и ускорения обучения. ""тот метод заключается в конкатенации обучающих образцов (раскрашенных) в чанки равного размера, что устраняет необходимость использования токенов заполнения) в батчах: При упаковке образцы могут перекрываться через границы каждого чанка, но на практике это не имеет большого значения, если большинство образцов значительно меньше размера чанка. Без упаковки производительность улучшается в течение нескольких эпох, прежде чем стабилизируется. Тем не менее, мы обнаружили, что во всех анализируемых датасетах упаковка давала худшие результаты. (в trl трейнере за это отвечает параметр packing) Урок 2: Используйте большой learning rate для лучшей производительности Для большинства экспериментов SFT, которые мы проводили с моделями Qwen, lr 2e-5 обычно достаточна для достижения высокой производительности. Однако при применении SFT с данными рассуждений к уже существующей модели-инструктору, мы обнаружили, что значительное улучшение результатов можно получить, используя гораздо большую скорость обучения — 4e-5. Как показано на диаграмме ниже, каждое удвоение скорости обучения давало улучшение почти на 10 пунктов по LiveCodeBench! Урок 3: Включение редакционных комментариев не повышает производительность Когда мы создавали поднабор solutions_w_editorials из open-r1/codeforces-cots, наша интуиция заключалась в том, что, предоставив R1 проблему и решение, мы получим лучшие трассы рассуждений. Однако, к нашему удивлению, эта интуиция не подтвердилась при оценке: наивная выборка из описаний задач давала скромное, но последовательное улучшение в процессе обучения. Урок 4: Используйте префилл с <think>, чтобы стабильно активировать длинные цепочки рассуждений При тестировании некоторых наших моделей мы столкнулись с любопытным явлением: при подаче запросов из той же предметной области (например, по конкурентному программированию) модель генерировала ожидаемую длинную цепочку рассуждений, заключённую между токенами <think> и </think>, за которой следовал окончательный ответ. Однако для запросов из другой области, таких как «Какая столица Швейцарии?», модель возвращалась к поведению исходной модели-инструктора! Это показывает, что при дистилляции трейсов рассуждений в уже обученную модель-инструктора следует по умолчанию использовать префилл в шаблоне чата финальной модели. Кстати, именно так поступает DeepSeek со своими дистиллированными моделями, и описанное выше поведение может быть объяснением их подхода. Урок 5: Используйте 8-битные оптимизаторы для масштабирования больших моделей с длинным контекстом На одном узле 8xH100 авторы смогли обучить модели с контекстом в 32k используя DeepSpeed ZeRO-3. Однако при попытке применить подход к 32B модели возникло множество проблем с памятью. В частности, наши эксперименты приводили к ошибке Out Of Memory, когда контекст увеличивался свыше 20к токенов, даже на 16 узлах 8xH100. А в датасете CodeForces-CoTs 20% трейсов больше 20к токенов, значит они бы обрезались во время трена. Корень проблемы в том, что и трансформеры, и trl пока не поддерживают параллелизм по контексту, хотя по данной проблеме можно следить по соответствующему issue. В то же время мы изучили различные техники экономии памяти и обнаружили, что сочетание FSDP с оптимизатором paged_adamw_8bit позволило нам масштабировать контекст до 22,528 токенов: всё ещё не идеально, но теперь обрезается только 9% данных."