В чём проблема: reasoning-модель думает на английском
Попросите GPT-OSS-20B рассуждать по-французски, и модель согласится: подтвердит инструкцию в ответе, а затем выдаст chain-of-thought на английском. Поведение воспроизводится стабильно, это устойчивая особенность открытой reasoning-модели, которую в разборе Amazon объясняют сильным английским приором после претрейна.
Замер на 50 мультиязычных примерах: корректный язык рассуждений только в 22% случаев. Расшифровка обнуляет оптимизм: английский - 100%, немецкий - 10% (единственный ненулевой результат вне английского), французский, испанский и итальянский - по 0%. Все 22% набраны английскими примерами, на четырёх других языках модель не справляется вообще.
Дальше кейс разворачивается в два этапа. SFT с LoRA на мультиязычном CoT-датасете поднял язык рассуждений с 22% до 100%, но язык финального ответа остался на 62%. GRPO поверх SFT-чекпоинта с наградой за язык ответа и рассуждений дал 70%, то есть +8 процентных пунктов, и качество рассуждений не просело. Выбор между методами здесь определяется не вкусом, а наличием запаса для улучшения.
Что именно измеряли: 50 кейсов, 5 языков, две метрики
Тест собран из 10 задач по математике и логике, каждую задают на пяти языках: английском, французском, немецком, испанском, итальянском. Итого 50 кейсов. Метрики две, и они измеряют разное:
- reasoning-language correct: chain-of-thought записан на целевом языке;
- answer-language correct: финальный ответ выдан на целевом языке.
Целевой язык задаёт системная инструкция reasoning language:. Она требует рассуждать и отвечать на одном языке, то есть модель должна преодолеть английский приор дважды: в CoT и в финальном ответе.
| Язык | Корректный язык рассуждений, базовая GPT-OSS-20B |
|---|---|
| Английский | 100% |
| Немецкий | 10% |
| Французский | 0% |
| Испанский | 0% |
| Итальянский | 0% |
| Все 50 кейсов | 22% |
Разрыв между двумя метриками и есть суть кейса. Модель может безупречно думать по-немецки и всё равно закончить английской фразой. Пользователь видит поломку, хотя формально инструкция выполнена наполовину.
Практический смысл для пользователя: указание в промпте само по себе не переключает язык рассуждений, если модель не видела достаточно CoT на этом языке. Инструкцию она прочитает и подтвердит, но CoT останется на языке претрейна.
Границы применимости цифр: это набор из 50 примеров на пяти языках, собранный из задач одного типа. Переносить проценты на другой домен, другие языки или продакшн-трафик без собственного замера нельзя.
SFT vs GRPO: два разных инструмента, а не конкуренты
Короткая формулировка разницы: SFT обучает поведению, которого у модели нет, GRPO оптимизирует поведение, которое она уже иногда воспроизводит.
Механика GRPO объясняет ограничение. Алгоритм сэмплирует группу ответов на один промпт, считает награду каждому и смещает политику в сторону тех, что оказались выше среднего по группе. Если нужное поведение имеет нулевую вероятность в базовом распределении, удачных примеров в группе не будет, и усиливать окажется нечего. Награда не создаёт навык, она повышает частоту того, что уже проскакивает в выборке.
Аналогия из спортзала: тренер отшлифует удар, который игрок уже иногда исполняет, но не поставит движение, которого в арсенале нет. Сначала движение ставится, потом доводится до стабильности.
Отсюда рабочее правило: SFT, затем GRPO, и только при остатке запаса. Бывает и другой сценарий, когда RL запускают без доменного SFT: так поступили авторы HuatuoGPT-3-27B, где медицинскую модель адаптировали одним этапом OnePO без промежуточного SFT. Логика та же: у базовой модели уже есть нужное поведение, его надо подтолкнуть, а не создавать с нуля.
Универсальным законом правило не назвать. Вывод получен на одной модели и подкреплён контрольным экспериментом на второй; на вашей задаче пропорции могут оказаться другими.
Почему SFT не решает всё: 100% на рассуждениях, 62% на ответе
SFT с LoRA на HuggingFaceH4/Multilingual-Thinking закрыл первую часть задачи: точность языка рассуждений выросла с 22% до 100%, CoT на всех пяти языках пошёл на нужном языке. Язык финального ответа при этом остановился на 62%.
Причина в том, что перед нами два разных навыка. Формат рассуждений модель заимствует из обучающих трейсов почти механически: структура, лексика, переходы. Финальный ответ генерируется после CoT и зависит от того, насколько прочно целевой язык закрепился в самой политике, а не только в шаблоне рассуждения.
62% для GRPO означают важное: модель уже иногда отвечает на нужном языке. Значит, в выборке найдутся удачные варианты, и сигнал для смещения политики существует. Это и есть headroom, запас, ради которого затевается RL-этап. Те же цифры и контекст этапа: опубликованный разбор Amazon.
Кейс GPT-OSS-20B: от 22% до 100% через SFT с LoRA
Датасет HuggingFaceH4/Multilingual-Thinking: chain-of-thought данные, переведённые на французский, испанский, немецкий и итальянский вместе с английским. Объём скромный: около 949 тренировочных и 50 валидационных примеров. Для 20B-модели это небольшая выборка, и результат на ней показывает, сколько даёт даже небольшой, но целевой набор.
Обучение шло через PyTorch TRL на Amazon SageMaker HyperPod с оркестрацией Amazon EKS. Системная инструкция reasoning language: задавала язык и для CoT, и для ответа, поэтому модель училась переключать язык по явному указанию, а не угадывать его по контексту.
Результат этапа: язык рассуждений 22% → 100%. Язык ответа на этом же чекпоинте 62%, и наивный вывод «SFT выучил всё» здесь не работает.
| Этап | Язык рассуждений | Язык ответа |
|---|---|---|
| Базовая GPT-OSS-20B | 22% | в источнике не указан |
| После SFT с LoRA | 100% | 62% |
| После GRPO | без потери качества | 70% |
Гиперпараметры в опубликованном разборе не приводятся: ни learning rate, ни rank LoRA, ни число эпох, ни размер батча. Повторяющим придётся подбирать их самостоятельно и проверять на своей валидационной выборке.
Почему LoRA, а не полный fine-tuning
LoRA обновляет небольшие низкоранговые адаптеры вместо всех весов. Для 20B-модели это снижает требования к памяти и избавляет от хранения полного состояния оптимизатора по всем параметрам. Практический смысл: этап SFT становится посильным для команды без выделенного кластера на весь цикл обучения.
Конкретные параметры адаптеров в источнике не раскрыты, поэтому воспринимать LoRA здесь стоит как архитектурный выбор, а не как готовый рецепт. Rank, alpha и набор обучаемых модулей влияют на результат и подбираются под задачу.
У SFT на узком домене есть известный риск: общие навыки проседают, если данных мало и они однотипны. Механику падения метрик после SFT и способы его избежать разбирает отдельный материал про катастрофическое забывание при дообучении Qwen3.6-27B.
GRPO поверх SFT: +8 п.п. к языку ответа без потери качества
Второй этап стартовал не с базовой модели, а с SFT-чекпоинта. Награда учитывала два условия: язык финального ответа и язык рассуждений. Результат: язык ответа вырос с 62% до 70%, язык рассуждений остался на прежнем уровне.
Скромный прирост по сравнению с SFT ожидаем. SFT строил навык с нуля и получил +78 процентных пунктов. GRPO работал на краю распределения, вытягивая редкие удачные ответы в норму, поэтому и потолок ниже. Ждать от RL таких же скачков, как от SFT, не стоит.
Инструменты те же: PyTorch TRL для прогонов SFT и GRPO на GPT-OSS-20B.
Как формулировать reward, чтобы не сломать рассуждения
Награда покрывает обе метрики. Логика простая: если награждать только за язык финального ответа, модель быстро найдёт короткий путь, начнёт отвечать по-французски, а думать продолжит по-английски. Формально метрика вырастет, задача останется нерешённой.
Обратная ошибка тоже возможна: награда только за язык CoT подтолкнёт к правильному рассуждению и оставит английский финал, то есть вернёт ситуацию к тем же 62%.
Конкретная формула награды в источнике не детализирована: нет весов, штрафов и правил для смешанных случаев. Воспроизводить придётся своей функцией. Держите в голове риск reward hacking: модель оптимизирует ровно то, что вы измеряете, а не то, что вы имели в виду. Проверка на отложенных промптах и ручной просмотр части ответов здесь дешевле, чем переобучение после неудачного прогона.
Контрольный эксперимент на Qwen2.5-7B: когда GRPO не даёт ничего
Чтобы проверить правило на другой модели, авторы взяли Qwen2.5-7B и сменили тренер: вместо TRL использовали veRL с Ray и KubeRay для распределённой оркестрации. Проверялись две задачи.
Мультиязычная задача, где запас для улучшения был, дала прирост от GRPO. GSM8K, где модель уже стояла на пике (90,5%), прироста не дала. Тот же алгоритм, тот же тренер, разница только в исходном уровне метрики. Детали эксперимента: публикация Amazon.
Вывод: GRPO не универсальный бустер. Он работает там, где политика уже иногда выдаёт желаемое поведение, и бесполезен там, где модель и так у потолка.
Как заранее проверить headroom и не сжечь GPU-часы
Проверка занимает один прогон инференса, а не дни обучения. Чек-лист:
- Соберите набор промптов, похожих на продакшн, 50-100 штук достаточно для первой оценки.
- Прогоните базовую или SFT-модель и посчитайте долю ответов, где желаемое поведение выполнено. Смотрите отдельно на язык рассуждений и язык ответа.
- Если нужное поведение не встречается вообще (0%), GRPO запускать рано, нужен SFT.
- Если поведение есть, но нестабильно (как 62% в кейсе), у GRPO есть материал для работы.
- Если метрика уже у потолка (как 90,5% на GSM8K), GPU-часы уйдут впустую.
Величину прироста этот чек-лист не предскажет. Он отвечает на более дешёвый вопрос: есть ли вообще смысл запускать RL.
Инфраструктура: что нужно, чтобы это повторить
Стек кейса:
- Amazon SageMaker HyperPod: платформа для обучения, на которой выполнялись прогоны;
- Amazon EKS: оркестрация Kubernetes для кластера HyperPod;
- PyTorch TRL: библиотека для SFT и GRPO на GPT-OSS-20B;
- veRL: тренер для контрольного эксперимента на Qwen, вместе с Ray и KubeRay.
Перечисленные в описании кейса Amazon FSx for Lustre, EFA и vLLM остаются без деталей: в опубликованном тексте их роль не раскрыта. За общей механикой стоит идти в разбор SkyRL на SageMaker HyperPod, где показаны колокация vLLM и FSDP на одних GPU, синхронизация LoRA-весов через FSx for Lustre и чекпоинтинг с resume_mode=latest.
Можно ли обойтись без HyperPod
Источник не сравнивал альтернативы, поэтому утверждать, что та же конфигурация поднимется на другом кластере без изменений, нельзя. PyTorch TRL и veRL - открытые инструменты, HyperPod и EKS - обвязка для масштабирования и оркестрации. Перенос на другую инфраструктуру потребует собственной проверки: сеть, файловая система для чекпоинтов и планировщик ведут себя по-разному.
Домашний ПК для такого цикла не подходит. 20B-модель, мультиязычный датасет и два последовательных этапа обучения требуют GPU-кластера; точные конфигурации в кейсе не приводятся, поэтому оценивайте требования по своей реализации.
Практическое правило: как выбрать SFT или GRPO для своей задачи
Сжатый алгоритм под свою задачу и свой язык:
- Замерьте базовое поведение на 50-100 промптах. Отдельно фиксируйте метрику рассуждений и метрику ответа.
- Если желаемого поведения нет совсем, собирайте CoT-датасет на целевом языке и запускайте SFT с LoRA.
- Перезамерьте после SFT. Типичная картина из кейса: рассуждения подтянулись до 100%, ответ отстаёт.
- Если ответ нестабилен, но иногда верен, запускайте GRPO с наградой за обе метрики.
- Если метрика уже у потолка, RL пропускайте.
Связка SFT и последующего RL с детерминированной наградой разобрана в кейсе кастомизации Qwen3-8B в SageMaker: там SFT на схеме категорий сменяется RLVR с GRPO, а reward балансирует recall и precision. Порядок тот же: сначала поведение, потом его устойчивость.
Ограничения правила: один основной кейс, один контрольный эксперимент на второй модели, тест из 50 примеров. Проценты прироста на ваших данных будут другими, гарантировать конкретные величины нельзя.
Типичные ошибки при выборе метода
- Запускать GRPO на поведении с нулевой вероятностью. Если модель ни разу не рассуждала по-французски, награде нечего усиливать: нужен SFT, как на первом этапе кейса.
- Награждать только язык ответа. Получите французский финал при английском CoT: метрика answer-language растёт, задача не решена.
- Ждать, что SFT закроет и ответ. В кейсе он дал 100% по рассуждениям и только 62% по ответу.
- Переносить +8 п.п. на свою задачу. Прирост получен с 62% на конкретном наборе; на другой метрике и другом запасе цифра будет иной.
- Гнать RL на пиковой метрике. GSM8K с 90,5% не дал ничего, GPU-часы ушли в ноль результата.
Первый шаг для вашей задачи занимает один инференс-прогон: посчитайте, как часто модель уже делает то, что нужно, и на каком языке. Если цифра близка к нулю, идите в SFT. Если она средняя, добавляйте GRPO. Если почти сто, оставьте модель в покое и займитесь данными для следующей задачи.