# GRPO Trainer

[![model badge](https://img.shields.io/badge/All_models-GRPO-blue)](https://huggingface.co/models?other=grpo,trl)

## Обзор

TRL поддерживает GRPO Trainer для обучения языковых моделей, как описано в статье [DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models](https://huggingface.co/papers/2402.03300) авторов [Zhihong Shao](https://huggingface.co/syhia), [Peiyi Wang](https://huggingface.co/peiyiwang89), [Qihao Zhu](https://huggingface.co/zqh11), Runxin Xu, [Junxiao Song](https://huggingface.co/haha-point), Mingchuan Zhang, Y. K. Li, Y. Wu, [Daya Guo](https://huggingface.co/guoday).

Аннотация из статьи следующая:

> Математическое рассуждение представляет собой значительный вызов для языковых моделей из-за своей сложной и структурированной природы. В данной статье мы представляем DeepSeekMath 7B, который продолжает предварительное обучение DeepSeek-Coder-Base-v1.5 7B на 120 млрд токенов, связанных с математикой, полученных из Common Crawl, а также на данных естественного языка и кода. DeepSeekMath 7B достиг впечатляющего результата 51,7% на соревновательном бенчмарке MATH без использования внешних библиотек и методов голосования, приближаясь к уровню производительности Gemini-Ultra и GPT-4. Метод self-consistency по 64 выборкам из DeepSeekMath 7B достигает 60,9% на MATH. Способность к математическому рассуждению в DeepSeekMath обусловлена двумя ключевыми факторами: во-первых, мы используем значительный потенциал общедоступных веб-данных с помощью тщательно спроектированного конвейера отбора данных. Во-вторых, мы вводим Group Relative Policy Optimization (GRPO), вариант Proximal Policy Optimization (PPO), который повышает способности к математическому рассуждению, одновременно оптимизируя использование памяти в PPO.

Метод постобучения был предложен [Quentin Gallouédec](https://huggingface.co/qgallouedec).

## Быстрый старт

В этом примере показано, как обучать модель с использованием метода GRPO. Мы обучаем модель [Qwen2.5 0.5B Instruct](https://huggingface.co/Qwen/Qwen2.5-0.5B-Instruct) на промптах из набора данных [DeepMath-103K](https://huggingface.co/datasets/trl-lib/DeepMath-103K). Данные из набора можно посмотреть здесь:

<iframe src="https://huggingface.co/datasets/trl-lib/DeepMath-103K/embed/viewer/default/train?row=0" frameborder="0" width="100%" height="560px"
>

Ниже приведён скрипт для обучения модели. `accuracy_reward` требует math-verify, который можно установить с помощью `pip install trl[math_verify]`.

```python
# train_grpo.py
from datasets import load_dataset
from trl import GRPOTrainer
from trl.rewards import accuracy_reward

dataset = load_dataset("trl-lib/DeepMath-103K", split="train")

trainer = GRPOTrainer(
    model="Qwen/Qwen2.5-0.5B-Instruct",
    reward_funcs=accuracy_reward,
    train_dataset=dataset,
)
trainer.train()
```

Выполните скрипт с помощью следующей команды:

```bash
torchrun --nproc_per_node 8 train_grpo.py
```

Обучение распределено по 8 GPU и занимает примерно 1 день.

![GRPO curves](https://huggingface.co/datasets/trl-lib/documentation-images/resolve/main/grpo_curves.png)

> **Примечание:** Кривые вознаграждения выше были получены с использованием `Qwen/Qwen2-0.5B-Instruct`. Результаты с `Qwen/Qwen2.5-0.5B-Instruct` будут качественно схожи.

## Более подробный обзор метода GRPO

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

![GRPO visual](https://huggingface.co/datasets/trl-lib/documentation-images/resolve/main/grpo_visual.png)

### Генерация завершений

На каждом шаге обучения мы выбираем пакет промптов и генерируем набор из \\( G \\) завершений для каждого промпта (обозначаемых как \\( o_i \\)).

### Вычисление преимущества

Для каждой из \\( G \\) последовательностей мы вычисляем вознаграждение с помощью модели или функции вознаграждения. Чтобы согласовать вычисление с сравнительной природой моделей вознаграждения, как правило, обученных на наборах данных, содержащих сравнения выходов для одного и того же вопроса, преимущество рассчитывается так, чтобы отражать эти относительные сравнения. Нормализация выполняется следующим образом:

$$\hat{A}_{i,t} = \frac{r_i - \text{mean}(\mathbf{r})}{\text{std}(\mathbf{r})}$$

Этот подход и дал методу его название: **Group Relative Policy Optimization (GRPO)**.

> [!TIP]
> В статье [Understanding R1-Zero-Like Training: A Critical Perspective](https://huggingface.co/papers/2503.20783) было показано, что масштабирование на \\( \text{std}(\mathbf{r}) \\) может приводить к смещению по уровню сложности вопросов. Вы можете отключить такое масштабирование, установив `scale_rewards=False` в [GRPOConfig](/docs/trl/main/ru/grpo_trainer#trl.GRPOConfig). Обратите внимание, что отключение масштабирования на основе std также убирает нормализацию дисперсии, поэтому величина обновлений напрямую зависит от исходного масштаба вознаграждения и состава батча.

> [!TIP]
> Как показано в [Части I: Хитрости или ловушки? Глубокий анализ RL для рассуждений LLM (Lite PPO)](https://huggingface.co/papers/2508.08221), вычисление среднего на локальном (групповом) уровне и стандартного отклонения на глобальном (батчевом) уровне обеспечивает более устойчивое формирование вознаграждения. Вы можете использовать эту стратегию масштабирования, установив `scale_rewards="batch"` в [GRPOConfig](/docs/trl/main/ru/grpo_trainer#trl.GRPOConfig).

### Оценка расхождения Кульбака–Лейблера

Дивергенция Кульбака–Лейблера оценивается с помощью аппроксиматора, предложенного в работе [Schulman et al. (2020)](http://joschu.net/blog/kl-approx.html). Аппроксиматор определяется следующим образом:

$$\mathbb{D}_{\text{KL}}\left[\pi_\theta \|\pi_{\text{ref}}\right] = \frac{\pi_{\text{ref}}(o_{i,t} \mid q, o_{i,<t})}{\pi_\theta(o_{i,t} \mid q, o_{i,<t})} - \log \frac{\pi_{\text{ref}}(o_{i,t} \mid q, o_{i,<t})}{\pi_\theta(o_{i,t} \mid q, o_{i,<t})} - 1, $$

### Вычисление функции потерь

Цель состоит в том, чтобы максимизировать преимущество, при этом обеспечивая близость модели к эталонной политике. Следовательно, функция потерь определяется следующим образом:

$$ \mathcal{L}_{\text{GRPO}}(\theta) = -\frac{1}{\sum_{i=1}^G |o_i|} \sum_{i=1}^G \sum_{t=1}^{|o_i|} \left[ \frac{\pi_\theta(o_{i,t} \mid q, o_{i,< t})}{\left[\pi_\theta(o_{i,t} \mid q, o_{i,< t})\right]_{\text{no grad}}} \hat{A}_{i,t} - \beta \mathbb{D}_{\text{KL}}\left[\pi_\theta \| \pi_{\text{ref}}\right] \right], $$

где первый член представляет собой масштабированное преимущество, а второй член штрафует за отклонения от эталонной политики через дивергенцию Кульбака-Лейблера.

> [!TIP]
> Обратите внимание, что в отличие от исходной формулировки в [DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models](https://huggingface.co/papers/2402.03300), мы не масштабируем на  \\( \frac{1}{|o_i|} \\), поскольку в статье [Understanding R1-Zero-Like Training: A Critical Perspective](https://huggingface.co/papers/2503.20783) было показано, что это вносит смещение по длине ответа на уровне ответа. Подробнее в разделе [loss types](#loss-types).

> [!TIP]
> Обратите внимание, что в отличие от исходной формулировки в [DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models](https://huggingface.co/papers/2402.03300), по умолчанию используется \\( \beta = 0.0 \\), что означает, что член KL-расхождения не применяется. Это решение обусловлено рядом недавних исследований (например, [Open-Reasoner-Zero: An Open Source Approach to Scaling Up Reinforcement Learning on the Base Model](https://huggingface.co/papers/2503.24290)), показавших, что член KL-расхождения не является обязательным для обучения с GRPO. В результате стало общепринятой практикой исключать его (например, [Understanding R1-Zero-Like Training: A Critical Perspective](https://huggingface.co/papers/2503.20783), [DAPO: An Open-Source LLM Reinforcement Learning System at Scale](https://huggingface.co/papers/2503.14476)). Если вы хотите включить член KL-расхождения, вы можете установить `beta` в [GRPOConfig](/docs/trl/main/ru/grpo_trainer#trl.GRPOConfig) в ненулевое значение.

В исходной статье эта формулировка обобщается с учётом нескольких обновлений после каждой генерации (обозначается как \\( \mu \\), задаётся параметром `num_iterations` в [GRPOConfig](/docs/trl/main/ru/grpo_trainer#trl.GRPOConfig)) с использованием **обрезанной целевой функции суррогата**:

$$ \mathcal{L}_{\text{GRPO}}(\theta) = - \frac{1}{\sum_{i=1}^G |o_i|} \sum_{i=1}^G \sum_{t=1}^{|o_i|} \left[ \min \left( \frac{\pi_\theta(o_{i,t} \mid q, o_{i,< t})}{\pi_{\theta_{\text{old}}}(o_{i,t} \mid q, o_{i,< t})} \hat{A}_{i,t}, \, \text{clip}\left( \frac{\pi_\theta(o_{i,t} \mid q, o_{i,< t})}{\pi_{\theta_{\text{old}}}(o_{i,t} \mid q, o_{i,< t})}, 1 - \epsilon, 1 + \epsilon \right) \hat{A}_{i,t} \right) - \beta \mathbb{D}_{\text{KL}}\left[\pi_\theta \| \pi_{\text{ref}}\right] \right], $$

где \\(\text{clip}(\cdot, 1 - \epsilon, 1 + \epsilon) \\) гарантирует, что обновления не отклоняются чрезмерно от эталонной политики, ограничивая отношение политик значениями от \\( 1 - \epsilon \\) до \\( 1 + \epsilon \\). Если \\( \mu = 1 \\) (значение по умолчанию в TRL), усечённая целевая функция замещающего вида упрощается до исходной целевой функции.

#### Типы потерь

В литературе предложено несколько формулировок целевой функции. Изначально целевая функция GRPO была определена следующим образом:

$$ \mathcal{L}_{\text{GRPO}}(\theta) = - \frac{1}{G} \sum_{i=1}^G \frac{1}{|o_i|} \sum_{t=1}^{|o_i|} l_{i,t}, $$

где

$$ l_{i,t} = \frac{\pi_\theta(o_{i,t} \mid q, o_{i,< t})}{\left[\pi_\theta(o_{i,t} \mid q, o_{i,< t})\right]_{\text{no grad}}} \hat{A}_{i,t} - \beta \mathbb{D}_{\text{KL}}\left[\pi_\theta \| \pi_{\text{ref}}\right]. $$

Статья [DAPO](https://huggingface.co/papers/2503.14476) указывает на ограничения функции потерь на уровне выборок в алгоритме GRPO в сценариях с длинными цепочками рассуждений (long-CoT), где более длинные ответы получают недостаточное наказание, что приводит к ухудшению качества вывода. Предложенное решение — нормализация на уровне токенов, которая лучше справляется с длинными последовательностями, распределяя более сбалансированные награды между отдельными токенами независимо от длины ответа:

$$ \mathcal{L}_{\text{DAPO}}(\theta) = - \frac{1}{\sum_{i=1}^G |o_i|} \sum_{i=1}^G \sum_{t=1}^{|o_i|} l_{i,t}, $$

Чтобы использовать эту формулировку, установите `loss_type="dapo"` в [GRPOConfig](/docs/trl/main/ru/grpo_trainer#trl.GRPOConfig).

Кроме того, в статье [Understanding R1-Zero-Like Training: A Critical Perspective](https://huggingface.co/papers/2503.20783) было показано, что исходная формулировка GRPO вносит смещение, связанное с длиной ответа. Авторы демонстрируют, что хотя формулировка DAPO снижает это смещение, она не устраняет его полностью. Для полного удаления смещения они предлагают делить на константу, а не на длину последовательности, что приводит к следующей формулировке:

$$ \mathcal{L}_{\text{Dr. GRPO}}(\theta) = - \frac{1}{LG} \sum_{i=1}^G \sum_{t=1}^{|o_i|} l_{i,t}, $$

Рекомендуется устанавливать это значение равным максимальной длине завершения. Чтобы использовать эту формулировку, задайте `loss_type="dr_grpo"` в [GRPOConfig](/docs/trl/main/ru/grpo_trainer#trl.GRPOConfig).

В качестве альтернативы в [статье SAPO](https://huggingface.co/papers/2511.20347) команда Qwen предлагает заменить «жёдкий» механизм обрезки в GRPO на плавный механизм мягкого гейтинга с управлением температурой. Если GRPO обнуляет градиенты, когда политика слишком сильно отклоняется от эталонной, то SAPO использует мягкую область доверия, которая плавно снижает вес градиента. Это позволяет модели сохранять полезные сигналы обучения от токенов, близких к текущей политике, подавляя при этом шум от экстремальных отклонений.

Функция потерь определяется следующим образом:

$$ \mathcal{L}_{\text{SAPO}}(\theta) = - \frac{1}{G} \sum_{i=1}^G \frac{1}{|o_i|} \sum_{t=1}^{|o_i|} f_{i,t} \left( \frac{\pi_\theta(o_{i,t} | q, o_{i,<t})}{\pi_{\theta_{old}}(o_{i,t} | q, o_{i,<t})} \right) \hat{A}_{i,t} $$

Функция мягкого гейтинга \\( f_{i,t} \\) определяется с использованием сигмоидной функции \\( \sigma \\) следующим образом:

$$ f_{i,t}(x) = \sigma \left( \tau_{i,t} (x - 1) \right) \cdot \frac{4}{\tau_{i,t}} $$

Температура \\( \tau_{i,t} \\) выбирается на основе знака преимущества \\( \hat{A}_{i,t} \\):

$$ \tau_{i,t} = \begin{cases} \tau_{\text{pos}}, & \text{if } \hat{A}_{i,t} > 0 \\ \tau_{\text{neg}}, & \text{otherwise} \end{cases} $$

Они рекомендуют использовать асимметричные температуры,  \\( \tau_{\text{neg}} > \tau_{\text{pos}} \\) (значения по умолчанию —  \\( \tau_{\text{pos}}=1.0, \tau_{\text{neg}}=1.05 \\) ). Это обеспечивает более строгое наказание модели за «плохие» действия для предотвращения нестабильности, при этом допуская более свободное поведение в отношении «хороших» действий.

Чтобы использовать эту формулировку, установите `loss_type="sapo"` в [GRPOConfig](/docs/trl/main/ru/grpo_trainer#trl.GRPOConfig).

## Записываемые метрики

Во время обучения и оценки мы фиксируем следующие метрики:

- `num_tokens`: общее количество обработанных на данный момент токенов, включая как промпты, так и завершения. При использовании инструментов учитываются только нетуловые токены.
- `step_time`: среднее время (в секундах), затрачиваемое на один шаг обучения (включая генерацию).
- `completions/mean_length`: средняя длина сгенерированных завершений. При использовании инструментов учитываются только токены, не относящиеся к инструментам.
- `completions/min_length`: минимальная длина генерируемых завершений. При использовании инструментов учитываются только токены, не относящиеся к инструментам.
- `completions/max_length`: максимальная длина генерируемых дополнений. При использовании инструментов учитываются только токены, не относящиеся к инструментам.
- `completions/mean_terminated_length`: средняя длина сгенерированных завершений, которые заканчиваются токеном EOS. При использовании инструментов учитываются только нетуловые токены.
- `completions/min_terminated_length`: минимальная длина сгенерированных завершений, которые заканчиваются токеном EOS. При использовании инструментов учитываются только токены, не относящиеся к инструментам.
- `completions/max_terminated_length`: максимальная длина сгенерированных завершений, которые заканчиваются токеном EOS. При использовании инструментов учитываются только токены, не относящиеся к инструментам.
- `completions/clipped_ratio`: Доля обрезанных (усечённых) завершений.
- `tools/call_frequency`: среднее количество вызовов инструментов на одно завершение в батче генерации. Записывается в журнал только при наличии `tools`.
- `tools/failure_frequency`: доля вызовов инструментов, завершившихся ошибкой (инструмент не найден, возникло исключение или тип вызова не поддерживается). Значение равно `0.0`, если ни один инструмент не был вызван. Записывается в журнал только при наличии `tools`.
- `rewards/{reward_func_name}/mean`: среднее значение вознаграждения от конкретной функции вознаграждения. Если среда владеет вознаграждением через `get_reward`, то `{reward_func_name}` — это имя класса среды.
- `rewards/{reward_func_name}/std`: стандартное отклонение вознаграждения от конкретной функции вознаграждения.
- `reward`: Общая средняя награда после суммирования наград по функциям (с весами `reward_weights`).
- `reward_std`: стандартное отклонение суммарных наград по функциям (с учётом весов `reward_weights`), вычисленное для всей выборки.
- `frac_reward_zero_std`: доля образцов в батче генерации, у которых стандартное отклонение награды равно нулю, что указывает на малое разнообразие для данного промпта (все ответы верные или неверные).
- `sampling/sampling_logp_difference/mean`: средняя абсолютная разница между лог-вероятностями, возвращаемыми сэмплером (vLLM), и пересчитанными моделью обучения, по токенам завершения. Рост значения указывает на увеличение рассогласования между обучением и инференсом. Записывается в лог только при `use_vllm=True` и `vllm_importance_sampling_correction=True`.
- `sampling/sampling_logp_difference/max`: максимальное такое абсолютное значение. Записывается в журнал только при `use_vllm=True` и `vllm_importance_sampling_correction=True`.
- `sampling/importance_sampling_ratio/min`: минимальное отношение важности (importance sampling ratio), используемое для коррекции рассогласования между обучением и инференсом, **после** применения ограничения, выбранного параметром `vllm_importance_sampling_mode` (обрезается до `[C_min, C_max]` для режимов `*_truncate`, устанавливается в ноль для режимов `*_mask`). Вычисляется по токенам завершения (completion tokens) или по последовательностям для режимов `sequence_*`. Записывается в лог только при `use_vllm=True` и `vllm_importance_sampling_correction=True`.
- `sampling/importance_sampling_ratio/mean`: среднее значение ограниченного отношения важности (importance sampling ratio). Записывается в журнал только при `use_vllm=True` и `vllm_importance_sampling_correction=True`.
- `sampling/importance_sampling_ratio/max`: максимальное ограниченное отношение важности выборки. Записывается только при `use_vllm=True` и `vllm_importance_sampling_correction=True`.
- `policy_loss`: значение потери градиента политики (до добавления бонуса за энтропию). Записывается в журнал, если `entropy_coef` не равно нулю или `use_adaptive_entropy=True`.
- `entropy`: Средняя энтропия предсказаний токенов по всем сгенерированным завершениям. (Если `mask_truncated_completions=True`, токены замаскированных последовательностей исключаются.)
- `entropy_coef`: Текущий коэффициент регуляризации энтропии. Записывается в журнал, если `entropy_coef` не равен нулю или `use_adaptive_entropy=True`. Обновляется один раз на каждый шаг оптимизатора, если `use_adaptive_entropy=True`.
- `aux_loss`: вспомогательная функция потерь для балансировки нагрузки в модели Mixture-of-Experts, до её масштабирования коэффициентом `router_aux_loss_coef` и добавления к общей функции потерь. Записывается в журнал только в том случае, если модель является MoE и `router_aux_loss_coef` не равен нулю.
- `kl`: средняя дивергенция Кульбака–Лейблера между моделью и эталонной моделью, рассчитанная по сгенерированным завершениям. Записывается в журнал только если `beta` не равно нулю.
- `clip_ratio/region_mean`: Доля вероятностей токенов (или последовательностей, если `importance_sampling_level="sequence"`), для которых цель GRPO обрезается, чтобы оставаться в пределах области доверия: \\( \text{clip}\left( r_{i,t}(\theta), 1 - \epsilon_\mathrm{low}, 1 + \epsilon_\mathrm{high} \right)\,, \quad r_{i,t}(\theta) = \frac{\pi_\theta(o_{i,t} \mid q, o_{i,< t})}{\pi_{\theta_{\text{old}}}(o_{i,t} \mid q, o_{i,< t})} \\). Более высокое значение означает, что обрезается больше токенов, что ограничивает степень изменения политики $\pi_\theta$.
- `clip_ratio/low_mean`: среднее отношение вероятностей токенов (или последовательностей, если `importance_sampling_level="sequence"`), которые были обрезаны по нижней границе области доверия: \\(r_{i,t}(\theta) < 1 - \epsilon_\mathrm{low}\\).
- `clip_ratio/low_min`: минимальная доля токенов (или последовательности в целом, если `importance_sampling_level="sequence"`) в каждом завершении, обрезанная по нижней границе области доверия: \\(r_{i,t}(\theta) < 1 - \epsilon_\mathrm{low}\\).
- `clip_ratio/high_mean`: среднее отношение вероятностей токенов (или последовательностей, если `importance_sampling_level="sequence"`), которые были обрезаны по верхней границе области доверия: \\(r_{i,t}(\theta) > 1 + \epsilon_\mathrm{high}\\).
- `clip_ratio/high_max`: максимальная доля токенов (или последовательности в целом, если `importance_sampling_level="sequence"`) в каждом завершении, обрезанная по верхней границе области доверия: \\(r_{i,t}(\theta) > 1 + \epsilon_\mathrm{high}\\).
- `cispo_clip_ratio`: доля весов важности сэмплирования токенов (или последовательностей, если `importance_sampling_level="sequence"`), которые были обрезаны по `epsilon_high` при положительном преимуществе: \\(r_{i,t}(\theta) > \epsilon_\mathrm{high}\\). Записывается только при `loss_type="cispo"`.
- `vespo/phi_seq_mean`: Среднее значение взвешивания VESPO Gamma \\(\varphi(w)\\), применяемого к весам важности на уровне последовательности. Значения ниже `1.0` означают, что последовательности понижаются по весу. Записывается только при `loss_type="vespo"`.

## Настройка

### Ускорение обучения с генерацией на базе vLLM

Генерация часто является основным узким местом при обучении с использованием онлайн-методов. Для ускорения генерации можно использовать [vLLM](https://github.com/vllm-project/vllm) — высокопроизводительный движок инференса с низкой задержкой для LLM. Для его включения сначала установите пакет с

```shell
pip install trl[vllm]
```

Мы поддерживаем два способа использования vLLM во время обучения: **режим сервера** и **режим colocation**.

> [!TIP]
> По умолчанию для генерации в vLLM включается выборка с маскированием важности на уровне последовательности (`vllm_importance_sampling_mode="sequence_mask"`) для устранения рассогласования между генерацией и обучением, возникающего при использовании разных фреймворков. Это можно отключить, установив `vllm_importance_sampling_correction=False`. Подробнее см. [Masked Importance Sampling](paper_index#masked-importance-sampling) и [Sequence-level Importance Sampling](paper_index#sequence-level-importance-sampling)

#### Вариант 1: Режим Colocate

В этом режиме vLLM работает внутри процесса тренера и разделяет память GPU с моделью обучения. Это позволяет избежать запуска отдельного сервера и может повысить использование GPU, но может привести к конкуренции за память на GPU, используемых для обучения. Это режим по умолчанию.

```python
from trl import GRPOConfig

training_args = GRPOConfig(
    ...,
    use_vllm=True,  # vllm_mode="colocate" by default
)
```

#### Вариант 2: серверный режим

В этом режиме vLLM работает в отдельном процессе (и на отдельных GPU) и взаимодействует с тренером через HTTP. Это идеальный вариант, если у вас есть выделенные GPU для инференса.

1. **Запустите сервер vLLM**:

   ```bash
   VLLM_SERVER_DEV_MODE=1 vllm serve <model_name> \
       --weight-transfer-config '{"backend": "nccl"}' \
       --logprobs-mode processed_logprobs \
       --max-logprobs -1
   ```

2. **Включите серверный режим в вашем скрипте обучения**:

   ```python
   from trl import GRPOConfig

   training_args = GRPOConfig(
       ...,
       use_vllm=True,
       vllm_mode="server",
   )
   ```

> [!WARNING]
> Убедитесь, что сервер использует другие GPU, чем тренажёр, иначе могут возникнуть ошибки NCCL. Вы можете указать используемые GPU с помощью переменной окружения `CUDA_VISIBLE_DEVICES`.

> [!TIP]
> В зависимости от размера модели и общих требований к памяти GPU для обучения может потребоваться отрегулировать параметр `vllm_gpu_memory_utilization` в [GRPOConfig](/docs/trl/main/ru/grpo_trainer#trl.GRPOConfig), чтобы избежать недоиспользования ресурсов или ошибок нехватки памяти.
>
> Мы предоставляем [HF Space](https://huggingface.co/spaces/trl-lib/recommend-vllm-memory), который помогает оценить рекомендуемое использование памяти GPU на основе конфигурации вашей модели и настроек эксперимента. Просто используйте его следующим образом, чтобы получить рекомендацию по `vllm_gpu_memory_utilization`:
>
> 
>
> Если рекомендуемое значение не работает в вашей среде, мы рекомендуем добавить небольшой запас (например, +0.05 или +0.1) к рекомендуемому значению для обеспечения стабильности.
>
> Если вы по-прежнему получаете ошибки нехватки памяти, установите `vllm_enable_sleep_mode` в True, и параметры vllm и кэш будут выгружены во время шага оптимизации. Подробнее см. в разделе [Снижение потребления памяти с помощью режима сна vLLM](reducing_memory_usage#vllm-sleep-mode).

> [!TIP]
> По умолчанию GRPO использует `MASTER_ADDR=localhost` и `MASTER_PORT=12345` для vLLM, но вы можете переопределить эти значения, установив соответствующие переменные окружения.

Для получения дополнительной информации см. [Ускорение обучения с помощью vLLM](speeding_up_training#vllm-for-fast-generation-in-online-methods).

#### Устранение рассогласования между обучением и инференсом
Хотя vLLM значительно ускоряет инференс, он также разделяет движок инференса и движок обучения. Теоретически эти движки математически идентичны, однако на практике они могут выдавать разные результаты из-за эффектов точности и аппаратно-специфичных оптимизаций. Это расхождение отражает различные цели оптимизации двух систем. Движки инференса стремятся максимизировать пропускную способность сэмплирования, обычно измеряемую в токенах в секунду, при сохранении приемлемой точности сэмплирования. Фреймворки обучения, напротив, фокусируются на численной стабильности и точности для вычисления градиентов, часто используя форматы с более высокой точностью, такие как FP32, для мастер-весов и состояний оптимизатора. Эти различающиеся приоритеты и ограничения вносят неизбежное, хотя и незначительное, несоответствие между обучением и инференсом.

Это несоответствие приводит к смещённым обновлениям градиента, что, как было отмечено, дестабилизирует обучение ([[1]](https://fengyao.notion.site/off-policy-rl)[[2]](https://yingru.notion.site/When-Speed-Kills-Stability-Demystifying-RL-Collapse-from-the-Training-Inference-Mismatch-271211a558b7808d8b12d403fd15edda)[[3]](https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/#true-on-policy-rl)[[4]](https://huggingface.co/papers/2510.26788)[[5]](https://huggingface.co/papers/2510.18855)). Для простоты рассмотрим градиент политики REINFORCE:

$$ \nabla_\theta \mathcal{J}(x,\theta) = \mathbb{E}_{y \sim \pi^\text{train}(\cdot \mid x,\theta)} \left[ \nabla_\theta \log \pi^\text{train}(y \mid x,\theta) \cdot R(x,y) \right] $$

Здесь \\( x \\) обозначает промпты, выбранные из некоторого распределения данных, а \\( \pi^\text{train} \\) — политику, реализованную движком обучения. При использовании vLLM в контуре мы получаем отдельную политику инференса \\( \pi^\text{inference} \\), в результате чего эффективный градиент политики становится

$$ \nabla_\theta \mathcal{J}_{\text{biased}}(x,\theta) = \mathbb{E}_{y \sim \pi^\text{inference}(\cdot \mid x,\theta)} \left[ \nabla_\theta \log \pi^\text{train}(y \mid x,\theta) \cdot R(x,y) \right]. $$

Это превращает задачу RL, которая иначе была бы on-policy, в off-policy.

Стандартный способ компенсации этого смещения распределения — **importance sampling (IS)**. Мы предлагаем два варианта IS: [Truncated Importance Sampling (TIS)](paper_index#truncated-importance-sampling) и [Masked Importance Sampling (MIS)](paper_index#masked-importance-sampling). Оба варианта можно применять как на уровне токенов, так и на уровне последовательностей. Пусть  \\( \rho \\) обозначает вес важности, например  \\( \rho_t \\) для каждого токена или  \\( \rho_{\text{seq}} \\) для каждой последовательности. В случае TIS значения, выходящие за пределы диапазона `[vllm_importance_sampling_clip_min, vllm_importance_sampling_clip_max]`, обрезаются,

$$ \rho \leftarrow \text{clip}(\rho, C_{\min}, C_{\max}). $$

В исходной [статье TIS](https://huggingface.co/papers/1606.02647) был предложен механизм обрезки только по верхней границе, то есть  \\( \min(\rho, C_{\max}) \\). Реализация в TRL обобщила этот подход, введя также нижнюю границу, что привело к двусторонней формулировке, показанной выше, по мотивам метода [IcePop](paper_index#masked-importance-sampling). Обратите внимание, что в IcePop границы обозначаются как  \\( \alpha \\) и  \\( \beta \\), тогда как в TRL используются  \\( C_{\min} \\) и  \\( C_{\max} \\).

В режиме MIS отношения, выходящие за пределы этого диапазона, обнуляются, поэтому такие сэмплы не вносят вклад в градиент. Иными словами, выбросы понизятся по весу в режиме TIS и отбрасываются в режиме MIS. Флаг конфигурации `vllm_importance_sampling_mode` определяет как вариант IS (маскирование или усечение), так и гранулярность (на уровне токенов или последовательностей).

Импортанс-сэмплинг — это принципиальный алгоритмический ответ на рассогласование между обучением и инференсом. Однако существуют и более прямые подходы, направленные на сокращение рассогласования между самыми движками. Большинство из них представляют собой инженерные решения. Например, [MiniMax M1 использует языковую модель с головой в формате FP32](https://huggingface.co/papers/2506.13585) в движке инференса. Thinking Machines исследовала [детерминированные ядра инференса](https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/), хотя это сопряжено со значительными потерями в эффективности. vLLM продемонстрировала [битово согласованные политики](https://blog.vllm.ai/2025/11/10/bitwise-consistent-train-inference.html), опираясь на детерминированные ядра с инвариантностью по батчу от Thinking Machines, но по состоянию на ноябрь 2025 года сохраняется существенное снижение пропускной способности по сравнению со стандартным инференсом в vLLM.

### Ускорение обучения с помощью непрерывного батчинга в transformers

В качестве альтернативы vLLM можно использовать встроенный в transformers движок непрерывного батчинга (continuous batching) для более быстрой генерации. Непрерывный батчинг сразу удаляет завершённые последовательности из батча, а не ждёт завершения самой медленной. Для задач с переменной длиной завершения (например, математическое рассуждение) это обеспечивает более быструю генерацию и меньшее потребление VRAM по сравнению с функцией `generate()` при больших размерах батча (N≥32).

> [!TIP]
> Continuous batching — это решение, которое можно внедрить без настройки сервера или синхронизации весов. Оно работает в рамках процесса и хорошо подходит для обучения на одном GPU или в средах с ограниченной памятью. Для максимальной пропускной способности генерации в масштабе используйте vLLM.

```python
from trl import GRPOConfig

training_args = GRPOConfig(
    ...,
    use_transformers_continuous_batching=True,
    transformers_continuous_batching_config={
        "use_cuda_graph": False,
        "max_memory_percent": 0.4,  # lower values leave more VRAM for the training backward pass
    },
)
```

> [!TIP]
> TRL по умолчанию устанавливает `max_memory_percent` в `0.5` (в отличие от `0.9` в transformers), чтобы оставить достаточно VRAM для обратного прохода при обучении. Уменьшите это значение до `0.3`–`0.4` для больших батчей генерации (N≥32) или если вы видите ошибки нехватки памяти.

Полный пример обучения см. в [`examples/grpo_continuous_batching/grpo_continuous_batching.py`](https://github.com/huggingface/trl/blob/main/examples/grpo_continuous_batching/grpo_continuous_batching.py).

### GRPO в масштабе: обучение модели 70B+ на нескольких узлах

При обучении крупных моделей, таких как **Qwen2.5-72B**, для обеспечения эффективности и масштабируемости обучения на нескольких GPU и узлах необходимы несколько ключевых оптимизаций. К ним относятся:

- **DeepSpeed ZeRO Stage 3**: ZeRO использует параллелизм данных для распределения состояний модели (весов, градиентов, состояний оптимизатора) между несколькими GPU и CPU, что снижает требования к памяти и вычислительным ресурсам на каждом устройстве. Поскольку большие модели не помещаются на одном GPU, для обучения таких моделей необходимо использовать ZeRO Stage 3. Подробнее см. в разделе [DeepSpeed Integration](deepspeed_integration).
- **torchrun**: запускатель PyTorch запускает по одному процессу на каждый GPU на каждом узле и связывает их через общий rendezvous. Подробнее см. в разделе [Распределение обучения](distributing_training).
- **vLLM**: см. предыдущий раздел о том, как использовать vLLM для ускорения генерации.

Ниже приведён пример SLURM-скрипта для обучения модели 70B с GRPO на нескольких узлах. Этот скрипт обучает модель на 4 узлах и использует 5-й узел для генерации на базе vLLM.

```sh
#!/bin/bash
#SBATCH --nodes=5
#SBATCH --gres=gpu:8

# Get the list of allocated nodes
NODELIST=($(scontrol show hostnames $SLURM_JOB_NODELIST))

# Assign the first 4 nodes for training and the 5th node for vLLM
TRAIN_NODES="${NODELIST[@]:0:4}"  # Nodes 0, 1, 2, 3 for training
VLLM_NODE="${NODELIST[4]}"  # Node 4 for vLLM

# Run training on the first 4 nodes (Group 1)
srun --nodes=4 --ntasks=4 --nodelist="${NODELIST[@]:0:4}" torchrun \
     --nnodes 4 \
     --nproc_per_node 8 \
     --node_rank $SLURM_PROCID \
     --rdzv_backend c10d \
     --rdzv_endpoint ${NODELIST[0]}:29500 \
     train_grpo.py \
     --server_ip $VLLM_NODE &

# Run vLLM server on the 5th node (Group 2)
srun --nodes=1 --ntasks=1 --nodelist="${NODELIST[4]}" env VLLM_SERVER_DEV_MODE=1 vllm serve Qwen/Qwen2.5-72B --tensor-parallel-size 8 \
    --weight-transfer-config '{"backend": "nccl"}' \
    --logprobs-mode processed_logprobs \
    --max-logprobs -1 &

wait
```

```python
import argparse

from datasets import load_dataset
from trl import GRPOTrainer, GRPOConfig
from trl.rewards import accuracy_reward

def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("--vllm_server_host", type=str, default="", help="The server IP")
    args = parser.parse_args()

    dataset = load_dataset("trl-lib/DeepMath-103K", split="train")

    training_args = GRPOConfig(
        per_device_train_batch_size=4,
        deepspeed="examples/deepspeed_configs/zero3.json",
        use_vllm=True,
        vllm_mode="server",
        vllm_server_host=args.vllm_server_host.replace("ip-", "").replace("-", "."),  # from ip-X-X-X-X to X.X.X.X
    )

    trainer = GRPOTrainer(
        model="Qwen/Qwen2.5-72B",
        args=training_args,
        reward_funcs=accuracy_reward,
        train_dataset=dataset
    )
    trainer.train()

if __name__=="__main__":
    main()
```

### Использование пользовательской функции вознаграждения

Объект [GRPOTrainer](/docs/trl/main/ru/grpo_trainer#trl.GRPOTrainer) поддерживает использование пользовательских функций вознаграждения вместо плотных моделей вознаграждения. Для обеспечения совместимости ваша функция вознаграждения должна соответствовать следующим требованиям:

Функции вознаграждения могут быть как синхронными вызываемыми объектами Python, так и асинхронными корутинами `async def`. Если вы указываете несколько асинхронных функций вознаграждения, они ожидаются одновременно (выполняются параллельно через `asyncio.gather`), что позволяет перекрыть их задержки.

1. **Аргументы ввода**:
   - Функция должна принимать следующие аргументы по имени:
     - `prompts` (содержит промпты),
     - `completions` (содержит сгенерированные завершения),
     - `completion_ids` (содержит токенизированные завершения),
     - `trainer_state` ([TrainerState](https://huggingface.co/docs/transformers/main/en/main_classes/callback#transformers.TrainerState)): текущее состояние тренера. Это можно использовать для реализации динамических функций вознаграждения, например, для обучения по программе (curriculum learning), где вознаграждение корректируется в зависимости от прогресса обучения.
     - `log_extra`: вызываемый объект `log_extra(column: str, values: list)` для добавления дополнительных столбцов в таблицу с результатами. См. Пример 6.
     - `log_metric`: вызываемый объект `log_metric(name: str, value: float)` для записи скалярных метрик в виде графиков наряду с `kl`, `entropy` и т. д. См. Пример 6.
     - `environments`: список экземпляров сред, по одному на каждое завершение. Присутствует только при указании `environment_factory`. Используйте этот параметр для чтения состояния, накопленного в ходе эпизода (например, `env.counter`). Для сред с состоянием предпочтительнее передавать управление наградой самой среде через метод `get_reward` — см. [Награды](#rewards).
     - Все имена столбцов (кроме `prompt`), которые могут присутствовать в наборе данных. Например, если набор данных содержит столбец с именем `ground_truth`, функция будет вызвана с `ground_truth` в качестве именованного аргумента.

     Самый простой способ выполнить это требование — использовать `**kwargs` в сигнатуре функции.
   - В зависимости от формата набора данных входные данные будут различаться:
     - Для [стандартного формата](dataset_formats#standard) `prompts` и `completions` будут списками строк.
     - Для [диалогового формата](dataset_formats#conversational) `prompts` и `completions` будут списками словарей сообщений.

2. **Возвращаемое значение**: функция должна возвращать список чисел с плавающей точкой. Каждое число представляет награду, соответствующую одному завершению.

#### Пример 1: Поощрение более длинных завершений

Ниже приведен пример функции вознаграждения для стандартного формата, которая поощряет более длинные завершения:

```python
def reward_func(completion_ids, **kwargs):
    """Reward function that assigns higher scores to longer completions (in terms of token count)."""
    return [float(len(ids)) for ids in completion_ids]
```

Вы можете протестировать это следующим образом:

```python
>>> prompts = ["The sky is", "The sun is"]  # not used in the reward function, but the trainer will pass it
>>> completions = [" blue.", " in the sky."]  # not used in the reward function, but the trainer will pass it
>>> completion_ids = [[6303, 13], [304, 279, 12884, 13]]
>>> reward_func(prompts=prompts, completions=completions, completion_ids=completion_ids)
[2.0, 4.0]
```

#### Пример 1.1: Поощрение более длинных завершений (на основе количества символов)

Аналогично предыдущему примеру, но на этот раз функция вознаграждения основана на количестве символов, а не токенов.

```python
def reward_func(completions, **kwargs):
    """Reward function that assigns higher scores to longer completions (in terms of character count)."""
    return [float(len(completion)) for completion in completions]
```

Вы можете протестировать это следующим образом:

```python
>>> prompts = ["The sky is", "The sun is"]
>>> completions = [" blue.", " in the sky."]
>>> completion_ids = [[6303, 13], [304, 279, 12884, 13]]  # not used in the reward function, but the trainer will pass it
>>> reward_func(prompts=prompts, completions=completions, completion_ids=completion_ids)
[6.0, 12.0]
```

#### Пример 2: Награждайте завершения с определенным форматом

Ниже приведен пример функции вознаграждения, которая проверяет, соответствует ли ответ определенному формату. Этот пример вдохновлен функцией _format reward_, используемой в статье [DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning](https://huggingface.co/papers/2501.12948). Она предназначена для диалогового формата, в котором промпты и ответы состоят из структурированных сообщений.

```python
import re

def format_reward_func(completions, **kwargs):
    """Reward function that checks if the completion has a specific format."""
    pattern = r"^<think>.*?</think><answer>.*?</answer>$"
    completion_contents = [completion[0]["content"] for completion in completions]
    matches = [re.match(pattern, content) for content in completion_contents]
    return [1.0 if match else 0.0 for match in matches]
```

Вы можете протестировать эту функцию следующим образом:

```python
>>> prompts = [
...     [{"role": "user", "content": "What is the result of (1 + 2) * 4?"}],
...     [{"role": "user", "content": "What is the result of (3 + 1) * 2?"}],
... ]
>>> completions = [
...     [{"role": "assistant", "content": "<think>The sum of 1 and 2 is 3, which we multiply by 4 to get 12.</think><answer>(1 + 2) * 4 = 12</answer>"}],
...     [{"role": "assistant", "content": "The sum of 3 and 1 is 4, which we multiply by 2 to get 8. So (3 + 1) * 2 = 8."}],
... ]
>>> format_reward_func(prompts=prompts, completions=completions)
[1.0, 0.0]
```

#### Пример 3: Награды за завершения на основе эталонного

Ниже приведен пример функции вознаграждения, которая проверяет правильность завершения. Этот пример вдохновлен функцией _accuracy reward_, используемой в статье [DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning](https://huggingface.co/papers/2501.12948). Данный пример предназначен для [стандартного формата](dataset_formats#standard), в котором набор данных содержит столбец с именем `ground_truth`.

```python
import re

def reward_func(completions, ground_truth, **kwargs):
    # Regular expression to capture content inside \boxed{}
    matches = [re.search(r"\\boxed\{(.*?)\}", completion) for completion in completions]
    contents = [match.group(1) if match else "" for match in matches]
    # Reward 1 if the content is the same as the ground truth, 0 otherwise
    return [1.0 if c == gt else 0.0 for c, gt in zip(contents, ground_truth)]
```

Вы можете протестировать эту функцию следующим образом:

```python
>>> prompts = ["Problem: Solve the equation $2x + 3 = 7$. Solution:", "Problem: Solve the equation $3x - 5 = 10$."]
>>> completions = [r" The solution is \boxed{2}.", r" The solution is \boxed{6}."]
>>> ground_truth = ["2", "5"]
>>> reward_func(prompts=prompts, completions=completions, ground_truth=ground_truth)
[1.0, 0.0]
```

#### Пример 4: Многозадачные функции вознаграждения

Ниже приведен пример использования нескольких функций вознаграждения в [GRPOTrainer](/docs/trl/main/ru/grpo_trainer#trl.GRPOTrainer). В этом примере мы определяем две функции вознаграждения, специфичные для задач: `math_reward_func` и `coding_reward_func`. Функция `math_reward_func` оценивает математические задачи на основе их правильности, а `coding_reward_func` — задачи по программированию на основе того, работает ли решение.

```python
from datasets import Dataset
from trl import GRPOTrainer

# Define a dataset that contains both math and coding problems
dataset = Dataset.from_list(
    [
        {"prompt": "What is 2+2?", "task": "math"},
        {"prompt": "Write a function that returns the sum of two numbers.", "task": "code"},
        {"prompt": "What is 3*4?", "task": "math"},
        {"prompt": "Write a function that returns the product of two numbers.", "task": "code"},
    ]
)

# Math-specific reward function
def math_reward_func(prompts, completions, task, **kwargs):
    rewards = []
    for prompt, completion, t in zip(prompts, completions, task):
        if t == "math":
            # Calculate math-specific reward
            correct = check_math_solution(prompt, completion)
            reward = 1.0 if correct else -1.0
            rewards.append(reward)
        else:
            # Return None for non-math tasks
            rewards.append(None)
    return rewards

# Coding-specific reward function
def coding_reward_func(prompts, completions, task, **kwargs):
    rewards = []
    for prompt, completion, t in zip(prompts, completions, task):
        if t == "code":
            # Calculate coding-specific reward
            works = test_code_solution(prompt, completion)
            reward = 1.0 if works else -1.0
            rewards.append(reward)
        else:
            # Return None for non-coding tasks
            rewards.append(None)
    return rewards

# Use both task-specific reward functions
trainer = GRPOTrainer(
    model="Qwen/Qwen2.5-0.5B-Instruct",
    reward_funcs=[math_reward_func, coding_reward_func],
    train_dataset=dataset,
)

trainer.train()
```

В этом примере `math_reward_func` и `coding_reward_func` разработаны для работы со смешанным набором данных, содержащим как математические, так и программные задачи. Колонка `task` в наборе данных используется для определения, какую функцию вознаграждения применить к каждой задаче. Если для образца в наборе данных нет соответствующей функции вознаграждения, функция вернёт `None`, и [GRPOTrainer](/docs/trl/main/ru/grpo_trainer#trl.GRPOTrainer) продолжит работу с валидными функциями и задачами. Это позволяет [GRPOTrainer](/docs/trl/main/ru/grpo_trainer#trl.GRPOTrainer) обрабатывать несколько функций вознаграждения с разной областью применения.

Обратите внимание, что [GRPOTrainer](/docs/trl/main/ru/grpo_trainer#trl.GRPOTrainer) игнорирует вознаграждения `None`, возвращаемые функциями вознаграждения, и учитывает только вознаграждения, возвращаемые соответствующими функциями. Это гарантирует, что модель обучается на релевантных задачах и игнорирует те, для которых нет соответствующей функции вознаграждения.

#### Пример 5: Асинхронные функции вознаграждения

Пользовательские функции вознаграждения также можно определять как корутины `async def`. Это полезно, если ваше вознаграждение зависит от медленного ввода-вывода (например, вызова удалённого сервиса). При передаче нескольких асинхронных функций вознаграждения [GRPOTrainer](/docs/trl/main/ru/grpo_trainer#trl.GRPOTrainer) выполняет их параллельно, чтобы их задержки перекрывались.

Ниже приведен минимальный пример асинхронной функции вознаграждения, имитирующей операцию, ограниченную вводом-выводом:

```python
import asyncio

async def async_reward_func(prompts, completions, **kwargs):
    # Simulate an I/O-bound call (e.g., HTTP request, database lookup)
    await asyncio.sleep(0.01)
    # Simple toy reward: 1.0 if the completion is non-empty, else 0.0
    return [1.0 if completion else 0.0 for completion in completions]
```

#### Пример 6: Логирование дополнительных столбцов и метрик

Ниже приведен пример функции вознаграждения, которая записывает дополнительные столбцы в таблицу завершений и скалярные метрики в виде графиков.

```python
import re

def reward_func(completions, ground_truth, log_extra=None, log_metric=None, **kwargs):
    extracted = [re.search(r"\\boxed\{(.*?)\}", c) for c in completions]
    extracted = [m.group(1) if m else None for m in extracted]
    rewards = [1.0 if e == gt else 0.0 for e, gt in zip(extracted, ground_truth)]

    if log_extra:
        log_extra("golden_answer", list(ground_truth))
        log_extra("extracted_answer", [e or "[none]" for e in extracted])

    if log_metric:
        log_metric("accuracy", sum(rewards) / len(rewards))

    return rewards
```

#### Передача функции вознаграждения в тренер

Чтобы использовать собственную функцию вознаграждения, передайте её в [GRPOTrainer](/docs/trl/main/ru/grpo_trainer#trl.GRPOTrainer) следующим образом:

```python
from trl import GRPOTrainer

trainer = GRPOTrainer(
    reward_funcs=reward_func,
    ...,
)
```

Можно передать несколько функций вознаграждения в виде списка; этот список может включать как синхронные, так и асинхронные функции:

```python
from trl import GRPOTrainer

trainer = GRPOTrainer(
    reward_funcs=[reward_func, async_reward_func1, async_reward_func2],
    ...,
)
```

а награда будет вычисляться как сумма наград от каждой функции или как взвешенная сумма, если в конфигурации указано `reward_weights`.

Обратите внимание, что [GRPOTrainer](/docs/trl/main/ru/grpo_trainer#trl.GRPOTrainer) поддерживает несколько функций вознаграждения разных типов. Подробности см. в документации по параметрам.

### Регуляризация энтропии

Чтобы стимулировать исследование и предотвратить схлопывание политики к почти детерминированным выводам, можно добавить бонус за энтропию в целевую функцию обучения. Регуляризация энтропии дополняет потерю GRPO следующим образом:

$$ \mathcal{L}(\theta) = \mathcal{L}_{\text{GRPO}}(\theta) - \alpha \cdot \mathcal{H}(\pi_\theta), $$

где \\(\mathcal{H}(\pi_\theta)\\) — средняя энтропия на токен для данной политики, а \\(\alpha\\) — коэффициент энтропии. Бонус всегда равен средней энтропии на токен, независимо от `loss_type`; он не масштабируется для соответствия нормализации политики конкретного типа потерь (например, знаменателю `batch_size * max_completion_length` в Dr. GRPO), поэтому `entropy_coef` имеет одинаковый смысл для всех типов потерь.

**Статическая энтропия** — фиксированный коэффициент на протяжении всего обучения:

```python
from trl import GRPOConfig, GRPOTrainer

training_args = GRPOConfig(entropy_coef=0.05, ...)
```

**Адаптивная энтропия** — коэффициент обновляется на каждом шаге оптимизатора на основе целевой энтропии, как предложено в [Skywork-OR1](https://huggingface.co/papers/2505.22312). Если текущая энтропия равна `entropy_target` или меньше, коэффициент увеличивается на `entropy_coef_delta`; в противном случае он уменьшается. Коэффициент применяется (т. е. не равен нулю) только тогда, когда энтропия равна целевому значению или меньше:

```python
training_args = GRPOConfig(
    entropy_coef=0.01,          # initial coefficient
    use_adaptive_entropy=True,
    entropy_target=5.0,         # target mean per-token entropy (nats); tune for your model
    entropy_coef_delta=0.005,   # step size per optimizer step
    entropy_coef_min=0.0,
    entropy_coef_max=1.0,
    ...
)
```

Типичные языковые модели имеют энтропию на токен в диапазоне 2–10 натов, поэтому значение по умолчанию `entropy_target=0.2` почти никогда не активирует регуляризацию — бонус срабатывает только тогда, когда энтропия равна целевому значению или ниже, то есть при практически полном коллапсе. Установите значение, имеющее смысл для вашей модели, например, близкое к энтропии, наблюдаемой на ранних этапах обучения (логгируется как метрика `entropy`). При использовании `top_entropy_quantile < 1.0` параметр `entropy_target` применяется к подмножеству токенов с высокой энтропией — энтропия этого подмножества будет выше, чем логгируемая энтропия по всем токенам (`entropy`), поэтому калибруйте значение соответственно.

При `use_adaptive_entropy=True` текущий коэффициент энтропии `entropy_coef` сохраняется вместе с каждой контрольной точкой и восстанавливается при возобновлении, что делает обучение полностью возобновляемым.

### Быстрая экспериментальная работа с GRPO

RapidFire AI — это экспериментальный движок с открытым исходным кодом, работающий поверх TRL и позволяющий запускать несколько конфигураций GRPO одновременно, даже на одном GPU. Вместо последовательного перебора конфигураций RapidFire позволяет **ранее увидеть все их кривые обучения, остановить низкоэффективные запуски и клонировать перспективные с новыми настройками на лету** без перезапуска. Подробнее см. [RapidFire AI Integration](rapidfire_integration).

## Обучение агента

GRPO поддерживает **обучение агентов**: модель вызывает инструменты в процессе генерации и учится на полученных результатах.

- **Инструмент** — это обычная функция Python (синхронная или асинхронная), доступная модели. Используйте `tools` для вызовов без состояния (калькулятор, веб-поиск).
- **Environment** — более общая форма: объектом с состоянием, создаваемым заново для каждого rollout, публичные методы которого доступны как инструменты, плюс хук жизненного цикла `reset` и необязательный `get_reward`, позволяющий среде самостоятельно определять награду. Используйте `environment_factory`, если вам нужно состояние для каждого rollout, хук сброса или награда, управляемая средой.

Они комбинируются — вы можете передать автономные `tools` вместе с `environment_factory`.

### Инструменты

Аргумент `tools` принимает список функций Python (синхронных или асинхронных), которые определяют инструменты, доступные агенту:

```python
from trl import GRPOTrainer

trainer = GRPOTrainer(
    tools=[tool1, tool2],
    ...,
)
```

Каждый инструмент должен быть стандартной функцией Python с **аргументами и типом возвращаемого значения, указанными через type hints**, а также **документирующей строкой в стиле Google**, описывающей его назначение, аргументы и возвращаемое значение. Подробнее см. в [руководстве по передаче инструментов](https://huggingface.co/docs/transformers/en/chat_extras#passing-tools).

> [!TIP]
> Цикл вызова инструментов GRPO требует, чтобы шаблон чата был *сохраняющим префикс* (добавление сообщения инструмента не должно изменять отображение предыдущих сообщений). Для известных семейств моделей (например, Qwen3, DeepSeek-V3) TRL автоматически подставляет исправленный шаблон обучения, когда инструменты включены. Полный список см. в разделе [Chat Templates](chat_templates#training-templates).

Используйте `max_tool_calling_iterations` в [GRPOConfig](/docs/trl/main/ru/grpo_trainer#trl.GRPOConfig), чтобы ограничить количество ходов вызова инструментов. По умолчанию ограничение отсутствует, и генерация останавливается, когда модель формирует ответный ход без вызовов инструментов, когда завершение (все ходы и результаты инструментов) достигает `max_completion_length` токенов, или когда полная последовательность достигает максимальной длины модели (`vllm_max_model_length` при `vllm_mode="colocate"`, иначе `max_position_embeddings` модели).

Пример:

```python
from trl import GRPOTrainer

def multiply(a: int, b: int) -> int:
    """
    Multiplies two integers.

    Args:
        a: The first integer.
        b: The second integer.

    Returns:
        The product of the two integers.
    """
    return a * b

async def async_add(a: int, b: int) -> int:
    """
    Asynchronously adds two integers.

    Args:
        a: The first integer.
        b: The second integer.

    Returns:
        The sum of the two integers.
    """
    return a + b

trainer = GRPOTrainer(
    tools=[multiply, async_add],
    ...,
)
```

### Окружения

Вы также можете предоставить инструменты через `environment_factory`. В этом режиме [GRPOTrainer](/docs/trl/main/ru/grpo_trainer#trl.GRPOTrainer) создаёт один экземпляр среды на каждый rollout и предоставляет публичные методы среды в качестве инструментов.

> [!IMPORTANT]
> `environment_factory` требует `transformers>=5.2.0`.

При использовании `environment_factory` среда владеет данными: внешнего `train_dataset` нет. На каждом rollout `reset()` формирует задачу — самообразец из корпуса, которым владеет среда, или процедурная генерация состояния — и возвращает промпт. `max_steps` задаёт длительность обучения. Ниже приведён минимальный пример среды, которая самообразует целевое значение и предоставляет метод `increment` (представленный как инструмент).

```python
import random

from trl import GRPOConfig, GRPOTrainer

class IncrementEnv:
    # Reserved methods
    def reset(self, **kwargs) -> str | None:  # required; called at the start of each rollout
        self.counter = 0
        self.target = random.randint(1, 6)  # self-sample the task
        return f"Increment the counter by {self.target}."  # returned string becomes the prompt

    def get_reward(self) -> float:  # optional: the environment scores itself from its own state
        return float(self.counter == self.target)

    # Public methods (exposed as tools)
    def increment(self, step: int) -> int:
        """
        Increment the internal counter.

        Args:
            step: Value to add to the counter.

        Returns:
            The updated counter value.
        """
        self.counter += step
        return self.counter

trainer = GRPOTrainer(
    model="Qwen/Qwen3-0.6B",
    args=GRPOConfig(max_steps=1000, chat_template_kwargs={"enable_thinking": False}),
    environment_factory=IncrementEnv,
)
trainer.train()
```

Класс окружения имеет два зарезервированных метода: `reset` и `get_reward`. В отличие от любых других публичных методов, они не предоставляются модели в качестве инструментов.

- `reset` (обязательный) вызывается при начале rollout. Он может возвращать либо `None`, либо строку. В GRPO, если возвращается строка, она является пользовательским запросом.
- `get_reward` (необязательный, синхронный или асинхронный) не принимает аргументов и возвращает `float`: среда оценивает только что завершённый эпизод на основе своего внутреннего состояния (завершилась ли игра победой? было ли угадано слово?). Вызывается один раз за каждый завершённый rollout и служит источником вознаграждения.

> [!NOTE]
> Поскольку среда выполняет самоотборку при каждом вызове `reset()`, `G` членов группы GRPO могут не разделять одно и то же начальное состояние, что делает базовую линию группы немного более шумной. Для идентичных состояний внутри группы убедитесь, что `reset()` детерминированно выводит состояние из общего ключа.

#### Предоставление внешнего набора данных (необязательно)

Вместо того чтобы позволять среде самостоятельно генерировать примеры, вы можете передать внешний `train_dataset`. Например, если ваши задачи уже хранятся в датасете, или для маршрутизации между [несколькими средами](#multiple-environments). Для каждого rollout тренер выбирает одну строку, использует её столбец `"prompt"` как промпт и передаёт остальные столбцы этой строки в `reset()` в виде именованных аргументов (таким образом, среда считывает задачу из датасета).

```python
from datasets import Dataset
from trl import GRPOTrainer

# Each row carries the prompt and the task data (here, the counter target to reach).
dataset = Dataset.from_dict(
    {
        "prompt": [[{"role": "user", "content": f"Increment the counter to {i}."}] for i in range(1, 7)],
        "target": list(range(1, 7)),
    }
)

class IncrementEnv:
    def reset(self, target, **kwargs) -> None:  # the row's `target` column arrives as a keyword argument
        self.counter = 0
        self.target = target

    def get_reward(self) -> float:
        return float(self.counter == self.target)

    def increment(self, step: int) -> int:  # exposed as a tool (see the full docstring above)
        self.counter += step
        return self.counter

trainer = GRPOTrainer(
    model="Qwen/Qwen3-0.6B",
    train_dataset=dataset,  # the dataset owns the task; the "target" column reaches reset(target=...)
    environment_factory=IncrementEnv,
)
trainer.train()
```

### Награды

Награды, управляемые средой, и награды, управляемые тренером, не являются взаимоисключающими. Передавайте `reward_funcs` для наград, которые естественно вычисляются по завершению (например, проверка формата текста) _и_ позволяйте среде возвращать свою зависящую от состояния награду через `get_reward`. Все источники суммируются; `reward_weights` применяется только к `reward_funcs` (среда сама управляет своим масштабом).

```python
def format_reward(completions, **kwargs):  # trainer-owned: scores the completion text
    ...

trainer = GRPOTrainer(
    model="Qwen/Qwen3-0.6B",
    args=GRPOConfig(max_steps=1000),
    reward_funcs=format_reward,          # trainer-owned: scores the completion
    environment_factory=IncrementEnv,    # env-owned: scores its internal state via `get_reward`
)
```

Функция `reward_func` также может напрямую читать состояние среды: если задан `environment_factory`, тренер передаёт аргумент `environments` (по одному экземпляру на каждое завершение). Это бывает полезно, но для наград, зависящих от состояния, предпочтительнее использовать `get_reward`.

Это работает идентично для [`AsyncGRPOTrainer`](async_grpo_trainer).

### Несколько сред

Чтобы обучать модель на смеси задач в одном прогоне (например, на задаче программирования и игре), передайте словарь, сопоставляющий имена сред с фабриками, вместо единой вызываемой функции. Каждый rollout выбирает свою среду через поле `environment` в наборе данных, и **доступны только инструменты этой среды**. Это предотвращает утечку нерелевантных инструментов (инструмент `move` из игры в пример с кодом и наоборот). Каждая среда по-прежнему владеет своими данными и возвращает prompt из `reset()`, поэтому в наборе данных достаточно столбца `environment` для маршрутизации между средами.

```python
import random

from datasets import Dataset
from trl import GRPOConfig, GRPOTrainer

class CodingEnv:
    def reset(self, **kwargs) -> str:
        n = random.randint(1, 20)
        return f"Compute the {n}th Fibonacci number."

    def run_code(self, code: str) -> str:  # exposed as a tool only for "coding" examples
        """Run the given Python code and return its stdout.

        Args:
            code: The Python source to execute.

        Returns:
            The captured standard output.
        """
        ...

class GameEnv:
    def reset(self, **kwargs) -> str:
        return "Reach the goal tile."

    def move(self, action: str) -> str:  # exposed as a tool only for "game" examples
        """Apply an action to the game and return the new observation.

        Args:
            action: One of "up", "down", "left", "right".

        Returns:
            The observation after the move.
        """
        ...

# The dataset only routes: each row picks the environment for that rollout
dataset = Dataset.from_dict({"environment": ["coding", "game"] * 500})

trainer = GRPOTrainer(
    model="Qwen/Qwen3-0.6B",
    args=GRPOConfig(chat_template_kwargs={"enable_thinking": False}),
    train_dataset=dataset,
    reward_funcs=reward_func,
    environment_factory={"coding": CodingEnv, "game": GameEnv},
)
trainer.train()
```

Функция вознаграждения по-прежнему получает окружение каждого примера через `reward_kwargs["environments"]`, поэтому она может ветвиться в зависимости от типа окружения (например, `isinstance(env, CodingEnv)`). Экземпляры окружений переиспользуются между шагами (сбрасываются между эпизодами), поэтому дорогостоящий `__init__` выполняется один раз, а не на каждом шаге. Поле `environment` используется тренером и **не** передаётся в `reset`.

### Ответы мультимодальных инструментов

Инструменты могут возвращать изображения вместе с текстом, возвращая список блоков контента. Это полезно для обучения агентов VLM, где инструмент предоставляет визуальную обратную связь (например, скриншоты, графики, снимки с камеры).

```python
from PIL import Image

def take_screenshot() -> list:
    """
    Takes a screenshot of the current screen.

    Returns:
        The screenshot image with a description.
    """
    img = Image.open("screenshot.png")
    return [{"type": "image", "image": img}, {"type": "text", "text": "Here is the screenshot."}]
```

Возвращаемые изображения автоматически добавляются в диалог и передаются в VLM для последующих шагов генерации.

### Поддерживаемые модели

Проверено с:

- **Beam** — например, `reflection/Beam-1.0-501B-A23B`
- [**DeepSeek-R1**](https://huggingface.co/collections/deepseek-ai/deepseek-r1) — например, `deepseek-ai/DeepSeek-R1`
- [**Gemma4**](https://huggingface.co/collections/google/gemma-4) — например, `google/gemma-4-E2B-it`
- **GLM-4-MoE** ([4.5](https://huggingface.co/collections/zai-org/glm-45), [4.6](https://huggingface.co/collections/zai-org/glm-46) или [4.7](https://huggingface.co/collections/zai-org/glm-47)) — например, `zai-org/GLM-4.7`
- [**GPT-OSS**](https://huggingface.co/collections/openai/gpt-oss) — например, `openai/gpt-oss-20b`
- [**Llama 3.1**](https://huggingface.co/collections/meta-llama/llama-31) — например, `meta-llama/Llama-3.1-8B-Instruct`
- [**Llama 3.2**](https://huggingface.co/collections/meta-llama/llama-32) — например, `meta-llama/Llama-3.2-3B-Instruct`
- [**Qwen2.5**](https://huggingface.co/collections/Qwen/qwen25) — например, `Qwen/Qwen2.5-0.5B-Instruct`
- [**Qwen3**](https://huggingface.co/collections/Qwen/qwen3) — например, `Qwen/Qwen3-0.6B`
- [**Qwen3-VL**](https://huggingface.co/collections/Qwen/qwen3-vl) — например, `Qwen/Qwen3-VL-2B-Instruct`
- [**Qwen3.5**](https://huggingface.co/collections/Qwen/qwen35) — например, `Qwen/Qwen3.5-2B`
- [**Qwen3.6**](https://huggingface.co/collections/Qwen/qwen36) — например, `Qwen/Qwen3.6-35B-A3B`

> [!TIP]
> Совместимость со всеми LLM не гарантируется. Если вы считаете, что модель должна поддерживаться, не стесняйтесь открыть issue на GitHub — или, что ещё лучше, отправить pull request с необходимыми изменениями.

### Интеграции с окружениями

Все среды подключаются к одному и тому же слоту `environment_factory`, поэтому на уровне TRL они взаимозаменяемы — выберите ту, чья экосистема лучше подходит для вашей задачи:

| Интеграция | Что это | Используйте, когда |
|---|---|---|
| [OpenEnv](openenv) | Открытый стандарт среды (API в стиле Gymnasium, работающий через WebSocket или в контейнеризованном выполнении), поддерживаемый Hugging Face и сообществом. | Вы используете готовую среду OpenEnv из Hub или определяете собственную в соответствии с открытым стандартом (например, Wordle, Sudoku, Catch). |
| [OpenReward](openreward) | Интеграция с ORS-совместимыми средами (каталог [openreward.ai](https://openreward.ai) или собственный ORS-сервер); задачи **и** вознаграждения предоставляются по HTTP. | Вы хотите обучать модель в среде ORS: каталог (например, `Eigent/SETA`), собственный хостинг на вашей инфраструктуре или локальный сервер, над которым вы работаете. |
| [Harbor](harbor) | Интеграция с наборами задач Harbor: каждая задача представляет собой инструкцию, реальный образ песочницы (`docker`, `e2b`, ...) и верификатор внутри песочницы. | Вы хотите обучать модель на наборе задач Harbor: это дерево задач, каждая из которых представляет собой автономный песочный контейнер и верификатор (например, агент по анализу данных, который исследует файлы в песочнице и записывает ответ, который проверяет оценщик). |

## Обучение моделей «зрение-язык»

GRPO поддерживает обучение моделей Vision-Language (VLM) на мультимодальных наборах данных, содержащих как текст, так и изображения.

### Поддерживаемые модели

Проверено с:

- **Gemma3** — например, `google/gemma-3-4b-it`
- **LLaVA-NeXT** — например, `llava-hf/llava-v1.6-mistral-7b-hf`
- **Qwen2-VL** — например, `Qwen/Qwen2-VL-2B-Instruct`
- **Qwen2.5-VL** — например, `Qwen/Qwen2.5-VL-3B-Instruct`
- **SmolVLM2** — например, `HuggingFaceTB/SmolVLM2-2.2B-Instruct`

> [!TIP]
> Совместимость со всеми VLM не гарантируется. Если вы считаете, что модель должна поддерживаться, не стесняйтесь открыть issue на GitHub — или, что ещё лучше, отправить pull request с необходимыми изменениями.

### Быстрый старт

Используйте [grpo\_vlm.py](https://github.com/huggingface/trl/blob/main/examples/grpo_visual_math/grpo_visual_math.py) для дообучения VLM. Пример команды для обучения на [`lmms-lab/multimodal-open-r1-8k-verified`](https://huggingface.co/datasets/lmms-lab/multimodal-open-r1-8k-verified):

```bash
torchrun --nproc_per_node 8 examples/grpo_visual_math/grpo_visual_math.py \
  --deepspeed examples/deepspeed_configs/zero3.json \
  --model_name_or_path Qwen/Qwen2.5-VL-3B-Instruct \
  --output_dir grpo-Qwen2.5-VL-3B-Instruct \
  --learning_rate 1e-5 \
  --dtype bfloat16 \
  --max_completion_length 1024 \
  --use_vllm \
  --vllm_mode colocate \
  --use_peft \
  --lora_target_modules "q_proj", "v_proj" \
  --log_completions
```

### Советы по конфигурации

- Использование LoRA на проекционных слоях зрительно-языковой модели
- Включите 4-битное квантование для снижения потребления памяти
- VLMs требуют много памяти — начните с меньших размеров батчей
- Большинство моделей совместимы с vLLM (режимы `server` и `colocate`)

### Формат набора данных

Каждая обучающая выборка должна включать:

- `prompt`: Текст, отформатированный через шаблон чата процессора
- `image`/`images`: изображение PIL или список изображений PIL

Тренер автоматически обрабатывает преобразование изображений в тензоры с помощью процессора изображений модели.

## GRPOTrainer[[trl.GRPOTrainer]]

#### trl.GRPOTrainer[[trl.GRPOTrainer]]

```python
trl.GRPOTrainer(model: str | PreTrainedModel | PeftModel, reward_funcs: str | transformers.modeling_utils.PreTrainedModel | collections.abc.Callable[..., list[float | None]] | list[str | transformers.modeling_utils.PreTrainedModel | collections.abc.Callable[..., list[float | None]]] | None = None, args: trl.trainer.grpo_config.GRPOConfig | None = None, train_dataset: datasets.arrow_dataset.Dataset | datasets.iterable_dataset.IterableDataset | None = None, eval_dataset: datasets.arrow_dataset.Dataset | datasets.iterable_dataset.IterableDataset | datasets.dataset_dict.DatasetDict | datasets.dataset_dict.IterableDatasetDict | dict[str, datasets.arrow_dataset.Dataset | datasets.iterable_dataset.IterableDataset] | None = None, processing_class: transformers.tokenization_utils_base.PreTrainedTokenizerBase | transformers.processing_utils.ProcessorMixin | None = None, reward_processing_classes: transformers.tokenization_utils_base.PreTrainedTokenizerBase | list[transformers.tokenization_utils_base.PreTrainedTokenizerBase] | None = None, callbacks: list[transformers.trainer_callback.TrainerCallback] | None = None, optimizers: tuple[typing.Optional[torch.optim.Optimizer], typing.Optional[torch.optim.lr_scheduler.LambdaLR]] = (None, None), quantization_config: BitsAndBytesConfig | None = None, peft_config: PeftConfig | None = None, tools: list[collections.abc.Callable] | None = None, rollout_func: collections.abc.Callable[[list[str], 'GRPOTrainer'], dict[str, typing.Any]] | None = None, environment_factory: collections.abc.Callable[[], trl.trainer.grpo_trainer._SupportsReset] | dict[str, collections.abc.Callable[[], trl.trainer.grpo_trainer._SupportsReset]] | None = None)
```

[Источник](https://github.com/huggingface/trl/blob/main/trl/trainer/grpo_trainer.py#L142)

**Параметры:**

model (`str` или [PreTrainedModel](https://huggingface.co/docs/transformers/main/en/main_classes/model#transformers.PreTrainedModel) или [PeftModel](https://huggingface.co/docs/peft/main/en/package_reference/peft_model#peft.PeftModel)) : Модель, подлежащая обучению. Может быть:  - строкой, являющейся *model id* предобученной модели, размещенной в репозитории моделей на huggingface.co, или путем к *каталогу*, содержащему веса модели, сохраненные с помощью [save_pretrained](https://huggingface.co/docs/transformers/main/en/main_classes/model#transformers.PreTrainedModel.save_pretrained), например, `'./my_model_directory/'`. Модель загружается с помощью `<ModelArchitecture>.from_pretrained` (где `<ModelArchitecture>` определяется из конфигурации модели) с использованием именованных аргументов из `args.model_init_kwargs`. Если `dtype` не указан в `args.model_init_kwargs`, по умолчанию используется `float32`. Это отличается от [from_pretrained](https://huggingface.co/docs/transformers/main/en/main_classes/model#transformers.PreTrainedModel.from_pretrained), где (начиная с Transformers v5) тип данных выводится из конфигурации модели. - Объектом [PreTrainedModel](https://huggingface.co/docs/transformers/main/en/main_classes/model#transformers.PreTrainedModel). Поддерживаются только каузальные языковые модели. - Объектом [PeftModel](https://huggingface.co/docs/peft/main/en/package_reference/peft_model#peft.PeftModel). Поддерживаются только каузальные языковые модели.

reward_funcs (`RewardFunc | list[RewardFunc]`, *необязательный*) : Функции вознаграждения, используемые для вычисления наград. Для вычисления наград мы вызываем все функции вознаграждения с промптами и завершениями и суммируем полученные награды. Этот параметр может быть опущен, если награда предоставляется средой через `environment_factory` (см. ниже). Допустимые значения:  - Одна функция вознаграждения, например: - Строка: *идентификатор модели* предобученной модели, размещенной в репозитории моделей на huggingface.co, или путь к *каталогу*, содержащему веса модели, сохраненные с помощью [save_pretrained](https://huggingface.co/docs/transformers/main/en/main_classes/model#transformers.PreTrainedModel.save_pretrained), например, `'./my_model_directory/'`. Модель загружается с помощью [from_pretrained](https://huggingface.co/docs/transformers/main/en/model_doc/auto#transformers.AutoModelForSequenceClassification.from_pretrained) с параметром `num_labels=1` и аргументами из `args.model_init_kwargs`. - Объект [PreTrainedModel](https://huggingface.co/docs/transformers/main/en/main_classes/model#transformers.PreTrainedModel): поддерживаются только модели классификации последовательностей. - Пользовательская функция вознаграждения: Функция получает промпты и сгенерированные завершения, а также любые дополнительные столбцы из набора данных. Она должна возвращать список наград. Пользовательские функции вознаграждения могут быть как синхронными, так и асинхронными, а также возвращать `None`, если награда неприменима к данным образцам. Это полезно для обучения в режиме нескольких задач, где разные функции вознаграждения применяются к разным типам образцов. Если функция вознаграждения возвращает `None` для образца, эта функция исключается из расчета награды для данного образца. Дополнительные сведения см. в разделе [Использование пользовательской функции вознаграждения](#using-a-custom-reward-function).  Состояние тренера также передается в функцию вознаграждения. Состояние тренера является экземпляром [TrainerState](https://huggingface.co/docs/transformers/main/en/main_classes/callback#transformers.TrainerState) и может быть получено через аргумент `trainer_state` в сигнатуре функции вознаграждения. - Список функций вознаграждения, где каждый элемент может независимо быть любым из вышеуказанных типов. Смешение разных типов в списке (например, строки с идентификатором модели и пользовательской функции вознаграждения) допускается.

args ([GRPOConfig](/docs/trl/main/ru/grpo_trainer#trl.GRPOConfig), *необязательный*) : Конфигурация для этого тренера. Если `None`, используется конфигурация по умолчанию.

train_dataset ([Dataset](https://huggingface.co/docs/datasets/main/en/package_reference/main_classes#datasets.Dataset) или [IterableDataset](https://huggingface.co/docs/datasets/main/en/package_reference/main_classes#datasets.IterableDataset), *необязательно*) : Набор данных для обучения. Он должен содержать столбец `"prompt"`. Любые дополнительные столбцы в наборе данных игнорируются. Формат образцов может быть следующим:  - [Стандартный](dataset_formats#standard): каждый образец содержит обычный текст. - [Диалоговый](dataset_formats#conversational): каждый образец содержит структурированные сообщения (например, роль и содержимое).  Может быть опущен только в том случае, если предоставлен `environment_factory` и среда владеет данными (или генерирует их процедурно), возвращая подсказку из метода `reset()`. В этом случае необходимо установить `max_steps`, чтобы определить длительность обучения.  Если `train_dataset` является [IterableDataset](https://huggingface.co/docs/datasets/main/en/package_reference/main_classes#datasets.IterableDataset) (например, потоковым набором данных), в аргументах обучения необходимо установить `max_steps`, поскольку его длину невозможно определить, а общее количество шагов обучения требуется для ограничения цикла обучения и настройки планировщика скорости обучения.

eval_dataset ([Dataset](https://huggingface.co/docs/datasets/main/en/package_reference/main_classes#datasets.Dataset), [IterableDataset](https://huggingface.co/docs/datasets/main/en/package_reference/main_classes#datasets.IterableDataset), [DatasetDict](https://huggingface.co/docs/datasets/main/en/package_reference/main_classes#datasets.DatasetDict), [IterableDatasetDict](https://huggingface.co/docs/datasets/main/en/package_reference/main_classes#datasets.IterableDatasetDict) или `dict[str, Dataset | IterableDataset]`) : Набор данных для использования при оценке. Он должен соответствовать тем же требованиям, что и `train_dataset`.

processing_class ([PreTrainedTokenizerBase](https://huggingface.co/docs/transformers/main/en/internal/tokenization_utils#transformers.PreTrainedTokenizerBase), [ProcessorMixin](https://huggingface.co/docs/transformers/main/en/main_classes/processors#transformers.ProcessorMixin), *необязательно*) : Класс обработки, используемый для обработки данных. Сторона отступов должна быть установлена в "left". Если `None`, класс обработки загружается по имени модели с помощью [from_pretrained](https://huggingface.co/docs/transformers/main/en/model_doc/auto#transformers.AutoProcessor.from_pretrained). Токен отступов, `tokenizer.pad_token`, должен быть установлен. Если класс обработки не установил токен отступов, по умолчанию будет использован `tokenizer.eos_token`.

reward_processing_classes ([PreTrainedTokenizerBase](https://huggingface.co/docs/transformers/main/en/internal/tokenization_utils#transformers.PreTrainedTokenizerBase) или `list[PreTrainedTokenizerBase]`, *необязательный*) : Классы обработки, соответствующие функциям вознаграждения, указанным в `reward_funcs`. Может быть:  - Одиночный класс обработки: используется, если `reward_funcs` содержит только одну функцию вознаграждения. - Список классов обработки: должен соответствовать порядку и длине функций вознаграждения в `reward_funcs`. Если установлено значение `None`, или если элемент списка, соответствующий [PreTrainedModel](https://huggingface.co/docs/transformers/main/en/main_classes/model#transformers.PreTrainedModel), равен `None`, токенайзер для модели загружается автоматически с помощью [from_pretrained](https://huggingface.co/docs/transformers/main/en/model_doc/auto#transformers.AutoTokenizer.from_pretrained). Для элементов в `reward_funcs`, которые являются пользовательскими функциями вознаграждения (не [PreTrainedModel](https://huggingface.co/docs/transformers/main/en/main_classes/model#transformers.PreTrainedModel)), соответствующие записи в `reward_processing_classes` игнорируются.

callbacks (список [TrainerCallback](https://huggingface.co/docs/transformers/main/en/main_classes/callback#transformers.TrainerCallback), *необязательный*) : Список колбэков для настройки цикла обучения. Эти колбэки будут добавлены к списку колбэков по умолчанию, описанному [здесь](https://huggingface.co/docs/transformers/main_classes/callback). Если вы хотите удалить один из колбэков по умолчанию, используйте метод [remove_callback](https://huggingface.co/docs/transformers/main/en/main_classes/trainer#transformers.Trainer.remove_callback).

optimizers (`tuple[torch.optim.Optimizer | None, torch.optim.lr_scheduler.LambdaLR | None]`, *необязательный*, по умолчанию `(None, None)`) : Кортеж, содержащий оптимизатор и планировщик, которые следует использовать. По умолчанию будет использован экземпляр `AdamW` для вашей модели и планировщик, заданный [get_linear_schedule_with_warmup](https://huggingface.co/docs/transformers/main/en/main_classes/optimizer_schedules#transformers.get_linear_schedule_with_warmup) и управляемый `args`.

quantization_config ([BitsAndBytesConfig](https://huggingface.co/docs/transformers/main/en/main_classes/quantization#transformers.BitsAndBytesConfig), *optional*) : Конфигурация квантования, используемая при загрузке модели по идентификатору модели. Используйте в сочетании с `peft_config` для обучения QLoRA. Игнорируется, если модель уже инициализирована.

peft_config ([PeftConfig](https://huggingface.co/docs/peft/main/en/package_reference/config#peft.PeftConfig), *необязательный*) : конфигурация PEFT, используемая для обёртки модели. Если `None`, модель не оборачивается.

tools (список `Callable`, *необязательный*) : список вызываемых функций-инструментов (синхронных или асинхронных), которые модель может вызывать во время генерации. Каждый инструмент должен быть стандартной функцией Python с корректно типизированными аргументами и значениями возвращаемых типов, а также строкой документации в стиле Google, описывающей его назначение, аргументы и возвращаемое значение. Дополнительные сведения см. здесь: https://huggingface.co/docs/transformers/en/chat_extras#passing-tools. Модель использует имя функции, аннотации типов и строку документации, чтобы определить, как её вызвать. Убедитесь, что шаблон чата модели поддерживает использование инструментов и что модель была дообучена для вызова инструментов.

rollout_func (`RolloutFunc`, *необязательный*) : Функция для генерации ответов. Она принимает список промптов, назначенных текущему процессу, и экземпляр тренера. Она должна возвращать словарь с полями `"prompt_ids"`, `"completion_ids"` и `"logprobs"`, а также может необязательно возвращать `"logprob_token_ids"` (с той же формой, что и `"logprobs"`). Все остальные поля передаются функциям вознаграждения. Функция получает исходный срез промптов для процесса без дублирования; она отвечает за возврат правильного количества ответов на каждый промпт (см. `num_generations` / `num_generations_eval` в тренере). Эта функция является экспериментальной и может быть изменена или удалена в любой момент без предварительного уведомления.

environment_factory (`EnvironmentFactory` или `dict[str, EnvironmentFactory]`, *необязательный*) : Вызываемый объект, который создает и возвращает экземпляр среды, или словарь, сопоставляющий имена сред с такими вызываемыми объектами. Класс среды должен определять методы, которые могут вызываться как инструменты в процессе генерации. Каждый метод должен соответствовать тем же требованиям, что и `tools`, описанные выше. Среда также должна реализовывать вызываемый метод `reset`, который можно использовать для сброса состояния между генерациями. Метод `reset` должен возвращать либо `None`, либо строку: если возвращается строка, она добавляется к последнему сообщению пользователя перед генерацией. Среда также может определять метод `get_reward`, не принимающий аргументов и возвращающий `float`: если такой метод присутствует, среда управляет вознаграждением, и `get_reward` вызывается один раз за каждый завершенный прогон для оценки на основе внутреннего состояния среды. Он действует как дополнительный источник вознаграждения (с весом 1, логируется под именем класса среды) наряду с `reward_funcs`, который в этом случае становится необязательным. При использовании одного вызываемого объекта каждый пример использует одну и ту же среду, при этом на каждый прогон создается отдельный экземпляр, чтобы их взаимодействия оставались изолированными. При использовании словаря каждый пример должен содержать поле `environment`, указывающее среду по имени, и в его промпте будут доступны только инструменты этой среды — это позволяет в одном запуске смешивать задачи (например, среду для программирования и игру). Эта функция является экспериментальной и может быть изменена или удалена в любой момент без предварительного уведомления.

Trainer для метода Group Relative Policy Optimization (GRPO). Данный алгоритм был впервые предложен в статье [DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models](https://huggingface.co/papers/2402.03300).

Пример:

```python
>>> from trl import GRPOTrainer
>>> from trl.rewards import accuracy_reward
>>> from datasets import load_dataset

>>> dataset = load_dataset("trl-lib/DeepMath-103K", split="train")

>>> trainer = GRPOTrainer(
...     model="Qwen/Qwen2.5-0.5B-Instruct",
...     reward_funcs=accuracy_reward,
...     train_dataset=dataset,
... )
>>> trainer.train()
```

#### train[[trl.GRPOTrainer.train]]

```python
train(resume_from_checkpoint: str | bool | None = None, trial: optuna.Trial | dict[str, Any] | None = None, ignore_keys_for_eval: list[str] | None = None)
```

[Источник](https://github.com/huggingface/trl/blob/main/transformers/trainer.py#L1447)

**Параметры:**

resume_from_checkpoint (`str` или `bool`, *необязательный*) : Если передано значение типа `str`, это локальный путь к сохранённой контрольной точке, созданной предыдущим экземпляром `Trainer`. Если передано значение типа `bool` и оно равно `True`, загружается последняя контрольная точка из *args.output_dir*, сохранённая предыдущим экземпляром `Trainer`. Если параметр указан, обучение возобновляется из состояний модели/оптимизатора/планировщика, загруженных отсюда.

trial (`optuna.Trial` или `dict[str, Any]`, *необязательный*) : Запуск испытания или словарь гиперпараметров для поиска гиперпараметров.

ignore_keys_for_eval (`list[str]`, *необязательный*) : Список ключей в выводе вашей модели (если он является словарём), которые следует игнорировать при сборе предсказаний для оценки во время обучения.

**Возвращает:** `~trainer_utils.TrainOutput`

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

Основная точка входа для обучения.

#### save_model[[trl.GRPOTrainer.save_model]]

```python
save_model(output_dir: str | None = None, _internal_call: bool = False)
```

[Источник](https://github.com/huggingface/trl/blob/main/transformers/trainer.py#L4036)

Сохранит модель, чтобы вы могли загрузить её снова с помощью `from_pretrained()`.

Сохранение будет выполняться только из основного процесса.

#### push_to_hub[[trl.GRPOTrainer.push_to_hub]]

```python
push_to_hub(commit_message: str | None = 'End of training', blocking: bool = True, token: str | None = None, revision: str | None = None, **kwargs)
```

[Источник](https://github.com/huggingface/trl/blob/main/transformers/trainer.py#L4307)

**Параметры:**

commit_message (`str`, *необязательный*, по умолчанию `"End of training"`) : Сообщение для коммита при отправке.

blocking (`bool`, *необязательный*, по умолчанию `True`) : Указывает, должна ли функция возвращаться только после завершения `git push`.

token (`str`, *необязательный*, по умолчанию `None`) : Токен с правом записи для перезаписи исходных аргументов Trainer.

revision (`str`, *необязательный*) : git-ревизия, от которой выполняется коммит. По умолчанию используется head ветки "main".

kwargs (`dict[str, Any]`, *необязательный*) : Дополнительные именованные аргументы, передаваемые в `~Trainer.create_model_card`.

**Возвращает:**

URL репозитория, в который была загружена модель, если `blocking=False`, или объект `Future`, отслеживающий ход коммита, если `blocking=True`.

Загрузите `self.model` и `self.processing_class` в модельный хаб 🤗 в репозиторий `self.args.hub_model_id`.

## GRPOConfig[[trl.GRPOConfig]]

#### trl.GRPOConfig[[trl.GRPOConfig]]

```python
trl.GRPOConfig(output_dir: str | None = None, per_device_train_batch_size: int = 8, num_train_epochs: float = 3.0, max_steps: int = -1, learning_rate: float = 1e-06, lr_scheduler_type: transformers.trainer_utils.SchedulerType | str = 'linear', lr_scheduler_kwargs: dict | str | None = None, warmup_steps: float = 0, optim: transformers.training_args.OptimizerNames | str = 'adamw_torch_fused', optim_args: str | None = None, weight_decay: float = 0.0, adam_beta1: float = 0.9, adam_beta2: float = 0.999, adam_epsilon: float = 1e-08, optim_target_modules: None | str | list[str] = None, gradient_accumulation_steps: int = 1, average_tokens_across_devices: bool = True, max_grad_norm: float = 1.0, label_smoothing_factor: float = 0.0, bf16: bool | None = None, fp16: bool = False, bf16_full_eval: bool = False, fp16_full_eval: bool = False, tf32: bool | None = None, gradient_checkpointing: bool = True, gradient_checkpointing_kwargs: dict[str, typing.Any] | str | None = None, torch_compile: bool = False, torch_compile_backend: str | None = None, torch_compile_mode: str | None = None, use_liger_kernel: bool = False, liger_kernel_config: dict[str, bool] | None = None, use_cache: bool = False, neftune_noise_alpha: float | None = None, torch_empty_cache_steps: int | None = None, auto_find_batch_size: bool = False, logging_strategy: transformers.trainer_utils.IntervalStrategy | str = 'steps', logging_steps: float = 10, logging_first_step: bool = False, log_on_each_node: bool = True, logging_nan_inf_filter: bool = True, include_num_input_tokens_seen: str | bool = 'no', log_level: str = 'passive', log_level_replica: str = 'warning', disable_tqdm: bool | None = None, report_to: None | str | list[str] = 'none', run_name: str | None = None, project: str = 'huggingface', trackio_space_id: str | None = None, trackio_bucket_id: str | None = None, trackio_static_space_id: typing.Union[str, NoneType, typing.Literal[False]] = None, eval_strategy: transformers.trainer_utils.IntervalStrategy | str = 'no', eval_steps: float | None = None, eval_delay: float = 0, per_device_eval_batch_size: int = 8, prediction_loss_only: bool = False, eval_on_start: bool = False, eval_do_concat_batches: bool = True, eval_use_gather_object: bool = False, eval_accumulation_steps: int | None = None, include_for_metrics: list[str] = <factory>, batch_eval_metrics: bool = False, save_only_model: bool = False, save_strategy: transformers.trainer_utils.SaveStrategy | str = 'steps', save_steps: float = 500, save_on_each_node: bool = False, save_total_limit: int | None = None, enable_jit_checkpoint: bool = False, push_to_hub: bool = False, hub_token: str | None = None, hub_private_repo: bool | None = None, hub_model_id: str | None = None, hub_strategy: transformers.trainer_utils.HubStrategy | str = 'every_save', hub_always_push: bool = False, hub_revision: str | None = None, load_best_model_at_end: bool = False, metric_for_best_model: str | None = None, greater_is_better: bool | None = None, ignore_data_skip: bool = False, restore_callback_states_from_checkpoint: bool = False, full_determinism: bool = False, seed: int = 42, data_seed: int | None = None, use_cpu: bool = False, accelerator_config: dict | str | None = None, parallelism_config: accelerate.parallelism_config.ParallelismConfig | None = None, dataloader_drop_last: bool = False, dataloader_num_workers: int = 0, dataloader_pin_memory: bool = True, dataloader_persistent_workers: bool = False, dataloader_prefetch_factor: int | None = None, dataloader_multiprocessing_context: str | None = None, dataloader_in_order: bool = True, remove_unused_columns: bool | None = False, label_names: list[str] | None = None, train_sampling_strategy: str = 'random', length_column_name: str = 'length', ddp_find_unused_parameters: bool | None = None, ddp_bucket_cap_mb: int | None = None, ddp_broadcast_buffers: bool | None = None, ddp_static_graph: bool | None = None, ddp_backend: str | None = None, ddp_timeout: int = 1800, fsdp: str | None = None, fsdp_config: dict[str, typing.Any] | str | None = None, deepspeed: dict | str | None = None, debug: str | list[transformers.debug_utils.DebugOption] = '', skip_memory_metrics: bool = True, do_train: bool = False, do_eval: bool = False, do_predict: bool = False, resume_from_checkpoint: str | None = None, local_rank: int = -1, model_init_kwargs: dict[str, typing.Any] | str | None = None, trust_remote_code: bool = False, router_aux_loss_coef: float | None = None, disable_dropout: bool = False, cast_lm_head_to_fp32: bool = False, num_generations: int | None = 8, num_generations_eval: int | None = None, max_completion_length: int | None = 512, ds3_gather_for_generation: bool = True, shuffle_dataset: bool | None = True, pad_to_multiple_of: int | str | None = 'auto', generation_batch_size: int | None = None, steps_per_generation: int | None = None, temperature: float = 1.0, top_p: float = 1.0, top_k: int = 0, min_p: float | None = None, generation_kwargs: dict | str | None = None, chat_template_kwargs: dict | str | None = None, repetition_penalty: float = 1.0, cache_implementation: str | None = None, use_vllm: bool = False, vllm_mode: str = 'colocate', vllm_model_impl: str = 'vllm', vllm_enable_sleep_mode: bool = False, vllm_structured_outputs_regex: str | None = None, vllm_server_base_url: str | None = None, vllm_server_host: str = '0.0.0.0', vllm_server_port: int = 8000, vllm_server_timeout: float = 240.0, vllm_group_port: int = 51216, vllm_gpu_memory_utilization: float = 0.3, vllm_max_model_length: int | None = None, vllm_tensor_parallel_size: int = 1, beta: float = 0.0, num_iterations: int = 1, epsilon: float = 0.2, delta: float | None = None, epsilon_high: float | None = None, sapo_temperature_neg: float = 1.05, sapo_temperature_pos: float = 1.0, vespo_k_pos: float = 2.0, vespo_lambda_pos: float = 3.0, vespo_k_neg: float = 3.0, vespo_lambda_neg: float = 2.0, importance_sampling_level: str = 'token', reward_weights: list[float] | None = None, multi_objective_aggregation: str = 'sum_then_normalize', scale_rewards: str = 'group', loss_type: str = 'dapo', mask_truncated_completions: bool = False, sync_ref_model: bool = False, ref_model_mixup_alpha: float = 0.6, ref_model_sync_steps: int = 512, top_entropy_quantile: float = 1.0, entropy_coef: float = 0.0, use_adaptive_entropy: bool = False, entropy_coef_min: float = 0.0, entropy_coef_max: float = 1.0, entropy_coef_delta: float = 0.005, entropy_target: float = 0.2, max_tool_calling_iterations: int | None = None, vllm_importance_sampling_correction: bool = True, vllm_importance_sampling_mode: str = 'sequence_mask', vllm_importance_sampling_clip_max: float | None = 3.0, vllm_importance_sampling_clip_min: float | None = None, off_policy_mask_threshold: float | None = None, use_bias_correction_kl: bool = True, log_completions: bool = False, log_multimodal: bool = True, num_completions_to_print: int | None = None, log_unique_prompts: bool = False, log_completions_hub_repo: str | None = None, use_transformers_continuous_batching: bool = False, transformers_continuous_batching_config: dict | str | None = None, use_transformers_paged: bool = False, vllm_importance_sampling_cap: float | None = None)
```

[Источник](https://github.com/huggingface/trl/blob/main/trl/trainer/grpo_config.py#L23)

**Параметры, управляющие моделью и эталонной моделью:**

model_init_kwargs (`str` или `dict[str, Any]`, *необязательный*) : Именованные аргументы для [from_pretrained](https://huggingface.co/docs/transformers/main/en/model_doc/auto#transformers.AutoModelForCausalLM.from_pretrained), используемые, когда аргумент `model` в [GRPOTrainer](/docs/trl/main/ru/grpo_trainer#trl.GRPOTrainer) передан в виде строки. Значение `revision` также используется при загрузке классов обработки.

trust_remote_code (`bool`, *optional*, defaults to `False`) : Whether to allow loading models and tokenizers that ship custom Python code from the Hub. Forwarded to [from_pretrained](https://huggingface.co/docs/transformers/main/en/model_doc/auto#transformers.AutoModelForCausalLM.from_pretrained) and [from_pretrained](https://huggingface.co/docs/transformers/main/en/model_doc/auto#transformers.AutoProcessor.from_pretrained). Also applied to reward-model and reward-tokenizer loads.

router_aux_loss_coef (`float`, *необязательный*) : Коэффициент вспомогательной функции потерь для балансировки нагрузки в моделях Mixture-of-Experts (MoE), добавляемой к функции потерь обучения с этим весом. Если значение не задано, используется значение, объявленное в конфигурации модели. Установите `0.0`, чтобы отключить. Вызывает ошибку при использовании с моделью, не являющейся MoE.

disable_dropout (`bool`, *необязательный*, по умолчанию `False`) : Указывает, следует ли отключить dropout в модели. Это полезно при обучении с опорной моделью, так как предотвращает генерацию моделью различных logprobs для одного и того же входа.

cast_lm_head_to_fp32 (`bool`, *необязательный*, по умолчанию `False`) : Указывает, следует ли преобразовать слой предсказания следующего токена (language modeling head) моделей политики и эталонной модели в float32. Рекомендуется в рецепте [ScaleRL](https://huggingface.co/papers/2510.13786). Этот флаг поддерживается только в том случае, если у модели слои word embedding и language modeling head не связаны, то есть `tie_word_embeddings` в конфигурации модели равно False.

**Параметры, управляющие предобработкой данных:**

remove_unused_columns (`bool`, *необязательный*, по умолчанию `False`) : Указывает, следует ли в наборе данных оставлять только столбец `"prompt"`. Если вы используете пользовательскую функцию вознаграждения, которая требует столбец, отличный от `"prompts"` и `"completions"`, оставьте это значение равным `False`.

num_generations (`int`, *optional*, по умолчанию `8`) : Количество генераций на промпт для выборки. Эффективный размер батча (num_processes * per_device_batch_size * gradient_accumulation_steps) должен делиться на это значение без остатка.

num_generations_eval (`int`, *optional*) : Количество генераций для выборки во время оценки. Это позволяет использовать меньшее количество генераций при оценке для экономии вычислений. Если `None`, используется значение `num_generations`.

max_completion_length (`int` или `None`, *необязательный*, по умолчанию `512`) : Максимальная длина генерируемого завершения.

ds3_gather_for_generation (`bool`, *необязательный*, по умолчанию `True`) : Этот параметр применяется к DeepSpeed ZeRO-3. Если включен, веса модели политики собираются для генерации, что повышает скорость генерации. Однако отключение этого параметра позволяет обучать модели, превышающие объем VRAM одного GPU, хотя и за счет более медленной генерации. Отключение этого параметра несовместимо с генерацией vLLM.

shuffle_dataset (`bool`, *необязательный*, по умолчанию `True`) : Нужно ли перемешивать обучающий набор данных.

pad_to_multiple_of (`int` или `str`, *необязательный*, по умолчанию `"auto"`) : Если задано, идентификаторы промптов и завершений будут дополнены до кратного этого значения. `"auto"` дополняет до кратного 128 на Neuron (AWS Trainium), который компилируется один раз для каждой формы входных данных, и не выполняет дополнения в других случаях.

**Параметры, управляющие генерацией:**

generation_batch_size (`int`, *optional*) : Размер батча, используемый для генерации. Если `None`, по умолчанию используется эффективный размер обучающего батча: `per_device_train_batch_size * num_processes * steps_per_generation`. Иными словами, на каждый шаг оптимизации обрабатывается один батч генерации. Взаимоисключается с `steps_per_generation`.

steps_per_generation (`int`, *необязательный*) : Количество шагов на генерацию. Если `None`, по умолчанию используется `gradient_accumulation_steps`. Взаимоисключается с `generation_batch_size`.

temperature (`float`, *необязательный*, по умолчанию `1.0`) : Температура для выборки. Чем выше температура, тем более случайными будут завершения.

top_p (`float`, *optional*, по умолчанию `1.0`) : Число с плавающей точкой, управляющее накопительной вероятностью верхних токенов, которые следует учитывать. Должно находиться в диапазоне (0, 1]. Установите значение `1.0`, чтобы учитывать все токены.

top_k (`int`, *optional*, по умолчанию `0`) : Количество токенов словаря с наивысшей вероятностью, которые следует оставить для фильтрации top-k. Если `0`, фильтрация top-k отключена, и учитываются все токены.

min_p (`float`, *optional*) : Минимальная вероятность токена, которая масштабируется вероятностью наиболее вероятного токена. Значение должно находиться в диапазоне от `0.0` до `1.0`. Типичные значения лежат в диапазоне `0.01-0.2`.

generation_kwargs (`dict[str, Any]`, *необязательный*) : Дополнительные именованные аргументы, передаваемые в [GenerationConfig](https://huggingface.co/docs/transformers/main/en/main_classes/text_generation#transformers.GenerationConfig) (при использовании transformers) или `SamplingParams` (при использовании vLLM) при выборке завершений. Это позволяет дополнительно настраивать поведение генерации, например, задавать `suppress_tokens`, `num_beams` и т. д. Если в нем содержатся ключи, конфликтующие с другими параметрами генерации (например, `min_p`, `top_p` и т. д.), они будут иметь приоритет.

chat_template_kwargs (`dict[str, Any]`, *необязательный*) : Дополнительные именованные аргументы, передаваемые в функцию `apply_chat_template` при генерации ответов.

repetition_penalty (`float`, *optional*, по умолчанию `1.0`) : Число с плавающей точкой, которое штрафует новые токены в зависимости от того, встречаются ли они в промпте и в уже сгенерированном тексте. Значения > `1.0` побуждают модель использовать новые токены, а значения < `1.0` — повторять токены.

cache_implementation (`str`, *необязательный*) : Реализация метода кэширования для более быстрой генерации, когда `use_vllm` установлен в `False`.

**Параметры, управляющие ускорением генерации на базе vLLM:**

use_vllm (`bool`, *необязательный*, по умолчанию `False`) : Использовать ли vLLM для генерации завершений. Если установлено в `True`, тренер будет использовать vLLM для генерации вместо стандартного model.generate(). Требуется установка `vllm`.

vllm_mode (`str`, *необязательный*, по умолчанию `"colocate"`) : Режим, используемый для интеграции с vLLM, когда `use_vllm` установлен в `True`. Должен быть одним из `"server"` или `"colocate"`.  - `"server"`: Тренировщик будет отправлять запросы на генерацию отдельному серверу vLLM. Убедитесь, что сервер vLLM запущен (запустите с помощью `vllm serve`). - `"colocate"`: vLLM будет работать в том же процессе и использовать те же GPU, что и для обучения. Это избавляет от необходимости запускать отдельный сервер, но может привести к конкуренции за ресурсы с процессом обучения.

vllm_model_impl (`str`, *необязательный*, по умолчанию `"vllm"`) : Реализация модели для vLLM. Должно быть одним из `"transformers"` или `"vllm"`. `"transformers"`: Использовать бэкенд `transformers` для реализации модели. `"vllm"`: Использовать библиотеку `vllm` для реализации модели.

vllm_enable_sleep_mode (`bool`, *необязательный*, по умолчанию `False`) : Включает режим сна vLLM для выгрузки весов/кэша во время шага оптимизатора. Позволяет поддерживать низкое использование памяти GPU, но пробуждение движка добавляет задержку при передаче данных между хостом и устройством.

vllm_structured_outputs_regex (`str`, *необязательный*) : Регулярное выражение для структурированных выходов vLLM. Если `None` (по умолчанию), структурированные выходы отключены.

**Параметры, управляющие сервером vLLM (используются только при `vllm_mode` = `"server"`):**

vllm_server_base_url (`str`, *необязательный*) : Базовый URL для сервера vLLM (например, `"http://localhost:8000"`). Если указан, `vllm_server_host` и `vllm_server_port` игнорируются.

vllm_server_host (`str`, *необязательный*, по умолчанию `"0.0.0.0"`) : Хост сервера vLLM для подключения. Игнорируется, если указано `vllm_server_base_url`.

vllm_server_port (`int`, *необязательный*, по умолчанию `8000`) : Порт сервера vLLM для подключения. Игнорируется, если указано `vllm_server_base_url`.

vllm_server_timeout (`float`, *необязательный*, по умолчанию `240.0`) : Общее время ожидания в секундах, пока сервер vLLM не станет доступным. Если сервер не запустится по истечении этого времени, будет выброшено исключение `ConnectionError`.

vllm_group_port (`int`, *optional*, по умолчанию `51216`) : Номер порта для группы обновления весов. Используется для связи с сервером vLLM. Если порт свободен, менять его не нужно.

**Параметры, управляющие выполнением vLLM в режиме colocation (используются только при `vllm_mode` = `"colocate"`):**

vllm_gpu_memory_utilization (`float`, *optional*, по умолчанию `0.3`) : Управляет использованием памяти GPU в vLLM. Этот параметр применяется только при установке `vllm_mode` в значение `"colocate"`. Если вы используете `vllm_mode="server"`, этот параметр необходимо передавать отдельно при запуске сервера vLLM с помощью флага `--vllm_gpu_memory_utilization`.

vllm_max_model_length (`int`, *optional*) : Контекстное окно для vLLM. Установите значение не менее максимальной длины промпта в наборе данных плюс `max_completion_length`; если параметр не указан, он вычисляется из конфигурации модели.

vllm_tensor_parallel_size (`int`, *optional*, по умолчанию `1`) : управляет размером тензорного параллелизма для vLLM. Этот параметр применяется только при установке `vllm_mode` в значение `"colocate"`. Если вы используете `vllm_mode="server"`, этот параметр необходимо передавать отдельно при запуске сервера vLLM с помощью флага `--vllm_tensor_parallel_size`.

**Параметры, управляющие обучением:**

beta (`float`, *optional*, по умолчанию `0.0`) : коэффициент KL. Если `0.0` (по умолчанию), референсная модель не загружается, что снижает потребление памяти и ускоряет обучение. [DeepSeek-R1 incentivizes reasoning in LLMs through reinforcement learning](https://huggingface.co/papers/2501.12948) используют значение `0.001`.

num_iterations (`int`, *необязательный*, по умолчанию `1`) : Количество итераций на один пакет (обозначается как μ в алгоритме).

epsilon (`float`, *необязательный*, по умолчанию `0.2`) : Значение эпсилона для обрезания.

delta (`float`, *optional*) : Включает верхнюю границу обрезания в двухсторонней функции потерь GRPO, если установлено значение типа float. Если `None` (по умолчанию), используется стандартное обрезание GRPO. Рекомендуется устанавливать значение, большее `1 + ε`, при включении. Этот метод представлен в [техническом отчёте INTELLECT-2](https://huggingface.co/papers/2505.07291).

epsilon_high (`float`, *optional*) : Верхнее значение epsilon для обрезки. Если не указано, по умолчанию используется то же значение, что и нижняя граница, заданная в аргументе `epsilon`. Статья [DAPO](https://huggingface.co/papers/2503.14476) рекомендует `0.28`. При использовании с `loss_type='cispo'` это соответствует параметру ε_max, указанному в статье [ScaleRL](https://huggingface.co/papers/2510.13786), и по умолчанию принимает рекомендуемое значение `5.0`.

sapo_temperature_neg (`float`, *необязательный*, по умолчанию `1.05`) : Температура для токенов с неположительными оценками преимущества, используемая в функции потерь `sapo`. Этот параметр введен в статье [Soft Adaptive Policy Optimization](https://huggingface.co/papers/2511.20347).

sapo_temperature_pos (`float`, *необязательный*, по умолчанию `1.0`) : Температура для токенов с положительными оценками преимущества, используемая в функции потерь `sapo`. Этот параметр введен в статье [Soft Adaptive Policy Optimization](https://huggingface.co/papers/2511.20347).

vespo_k_pos (`float`, *необязательный*, по умолчанию `2.0`) : параметр k для положительных преимуществ, он является показателем степени в функции потерь VESPO. Определяет, насколько агрессивно мы снижаем вес образцов с низкими весами важности (когда отношение важности выборки < 1).

vespo_lambda_pos (`float`, *optional*, по умолчанию `3.0`) : параметр lambda для положительных преимуществ, это коэффициент затухания в функции потерь VESPO. Определяет, насколько агрессивно мы снижаем вес образцов с высокими весами важности (когда отношение импоранс-сэмплинга > 1).

vespo_k_neg (`float`, *необязательный*, по умолчанию `3.0`) : параметр k для отрицательных преимуществ, он является показателем степени в функции потерь VESPO. Определяет, насколько агрессивно мы снижаем вес образцов с низкими весами важности (когда отношение импоранс-сэмплинга < 1).

vespo_lambda_neg (`float`, *необязательный*, по умолчанию `2.0`) : параметр lambda для отрицательных преимуществ, представляет собой коэффициент экспоненциального затухания в функции потерь VESPO. Определяет, насколько агрессивно мы снижаем вес образцов с высокими весами важности (когда отношение импоранс-сэмплинга > 1).

importance_sampling_level (`str`, *необязательный*, по умолчанию `"token"`) : Определяет, вычисляются ли коэффициенты Importance Sampling на уровне `"token"` или `"sequence"`. `"token"` сохраняет исходные отношения лог-вероятностей для каждого токена (один вес на токен). `"sequence"` усредняет отношения лог-вероятностей по всем валидным токенам, чтобы получить одно отношение на последовательность. Статья [GSPO](https://huggingface.co/papers/2507.18071) показывает, что выборка на уровне последовательности часто обеспечивает более стабильное обучение и лучшее согласование с наградами на уровне последовательности.

reward_weights (`list[float]`, *необязательный*) : Веса для каждой функции вознаграждения. Количество должно совпадать с числом функций вознаграждения. Если `None`, все вознаграждения имеют равный вес `1.0`.

multi_objective_aggregation (`str`, *необязательный*, по умолчанию `"sum_then_normalize"`) : Метод агрегации нескольких функций вознаграждения. Поддерживаемые значения:  - `"sum_then_normalize"` (по умолчанию): Сначала суммирует взвешенные вознаграждения от каждой функции вознаграждения, затем применяет масштабирование/нормализацию вознаграждения, указанное в `scale_rewards` (см. `scale_rewards` для подробностей). - `"normalize_then_sum"`: Сначала нормализует/масштабирует каждую функцию вознаграждения по поколениям (в пределах каждой группы), затем суммирует нормализованные вознаграждения с использованием указанных весов. Затем агрегированное вознаграждение нормализуется на уровне батча при формировании преимуществ. Это рекомендуемый подход из статьи [GDPO: Group reward-Decoupled Normalization Policy Optimization for Multi-reward RL Optimization](https://huggingface.co/papers/2601.05242).

scale_rewards (`str` или `bool`, *необязательный*, по умолчанию `"group"`) : Определяет стратегию масштабирования наград. Поддерживаемые значения:  - `True` или `"group"` (по умолчанию): награды масштабируются по стандартному отклонению внутри каждой группы, что обеспечивает единичную дисперсию внутри группы. - `"batch"`: награды масштабируются по стандартному отклонению для всей выборки, как рекомендуется в [статье PPO Lite](https://huggingface.co/papers/2508.08221). - `False` или `"none"`: масштабирование не применяется. В [статье Dr. GRPO](https://huggingface.co/papers/2503.20783) рекомендуется не масштабировать награды, так как масштабирование по стандартному отклонению вносит смещение, связанное со сложностью вопроса.

loss_type (`str`, *необязательный*, по умолчанию `"dapo"`) : Определяет формулу потерь, которую следует использовать. Поддерживаемые значения:  - `"grpo"`: Агрегирует потери на уровне токенов, нормализуя по длине последовательности. Не рекомендуется из-за смещения по длине — этот подход склонен отдавать предпочтение более коротким завершениям с положительными преимуществами и более длинным — с отрицательными. - `"dr_grpo"`: Агрегирует потери на уровне токенов, нормализуя глобальной константой. Этот метод был предложен в [статье Dr. GRPO](https://huggingface.co/papers/2503.20783) для устранения смещения по длине. Значение константы соответствует `max_completion_length`. - `"dapo"` (по умолчанию): Агрегирует потери на уровне токенов, нормализуя по количеству активных токенов в глобальном накопленном батче. Этот метод был предложен в [статье DAPO](https://huggingface.co/papers/2503.14476) для устранения смещения по длине. - `"bnpo"`: Агрегирует потери на уровне токенов, нормализуя по количеству активных токенов в локальном батче. Обратите внимание, что нормализация выполняется только по локальному батчу, поэтому результаты могут незначительно различаться в зависимости от размера локального батча, несмотря на постоянный эффективный размер батча. При использовании `per_device_train_batch_size==1` потери эквивалентны потерям GRPO. - `"cispo"`: Обрезает веса importance sampling, а не веса importance sampling, масштабированные преимуществом. Затем обрезанные веса умножаются на преимущества и логарифмические вероятности модели политики. Потери отдельных токенов агрегируются путем нормализации по количеству активных токенов в глобальном накопленном батче. Этот метод был предложен в [статье MiniMax-M1](https://huggingface.co/papers/2506.13585). - `"sapo"`: Потери Soft Adaptive Policy Optimization, как описано в [статье Soft Adaptive Policy Optimization](https://huggingface.co/papers/2511.20347). Заменяет жёсткую обрезку плавным шлюзом с управлением температурой, который адаптивно ослабляет обновления вне политики, сохраняя при этом полезные сигналы обучения. - `"luspo"`: Потери Length-Unbiased Sequence Policy Optimization. Потери на уровне последовательности, которые масштабируют потери каждой последовательности её длиной. Это модификация GSPO и требует `importance_sampling_level="sequence"`. Предложен в [статье LUSPO](https://huggingface.co/papers/2602.05261). - `"vespo"`: Variational Sequence-Level Soft Policy Optimization. Заменяет жёсткую обрезку плавной асимметричной весовой функцией Gamma, применяемой непосредственно к весам importance sampling на уровне последовательности. Предложен в [статье VESPO](https://huggingface.co/papers/2602.10693).

mask_truncated_completions (`bool`, *необязательный*, по умолчанию `False`) : Если включено, усечённые завершения исключаются из расчёта функции потерь, что предотвращает их некорректное наказание и появление шума в процессе обучения. Согласно статье [DAPO](https://huggingface.co/papers/2503.14476), это хорошая практика для обеспечения стабильности обучения.

sync_ref_model (`bool`, *необязательный*, по умолчанию `False`) : следует ли синхронизировать эталонную модель с активной моделью каждые `ref_model_sync_steps` шагов, используя параметр `ref_model_mixup_alpha`. Эта синхронизация заимствована из статьи [TR-DPO](https://huggingface.co/papers/2404.09656).

ref_model_mixup_alpha (`float`, *optional*, по умолчанию `0.6`) : параметр α из статьи [TR-DPO](https://huggingface.co/papers/2404.09656), который управляет соотношением между текущей политикой и предыдущей опорной политикой при обновлениях. Опорная политика обновляется по формуле: `π_ref = α * π_θ + (1 - α) * π_ref_prev`. Чтобы использовать этот параметр, необходимо установить `sync_ref_model=True`.

ref_model_sync_steps (`int`, *необязательный*, по умолчанию `512`) : параметр τ из статьи [TR-DPO](https://huggingface.co/papers/2404.09656), определяющий, как часто текущая политика синхронизируется с эталонной политикой. Чтобы использовать этот параметр, необходимо установить `sync_ref_model=True`.

top_entropy_quantile (`float`, *необязательный*, по умолчанию `1.0`) : параметр ρ из статьи [Beyond the 80/20 Rule](https://huggingface.co/papers/2506.01939). В члене потерь политики сохраняются только токены из верхнего ρ-квантиля по энтропии распределения вероятностей на каждой позиции последовательности, что улучшает результаты. Диапазон: `[0.0-1.0]`. Значение `0.0` маскирует все токены, кроме токена с максимальной энтропией; `1.0` сохраняет все токены. В статье рекомендуется значение `0.2`. При использовании с `mask_truncated_completions=True` учитываются только токены из неотсечённых завершений.

entropy_coef (`float`, *optional*, по умолчанию `0.0`) : Коэффициент слагаемого энтропийной регуляризации в функции потерь. Положительное значение добавляет энтропийный бонус, который стимулирует исследование, не давая политике схлопнуться к почти детерминированным выводам. Бонус всегда представляет собой среднюю энтропию на токен, независимо от `loss_type`; он не масштабируется для соответствия нормализации политики конкретного типа потерь, поэтому `entropy_coef` имеет одинаковый смысл для всех типов потерь. Если `use_adaptive_entropy=True`, это значение служит начальным коэффициентом и обновляется на каждом шаге оптимизатора. Не оказывает влияния, если установлено в `0.0` (по умолчанию).

use_adaptive_entropy (`bool`, *необязательный*, по умолчанию `False`) : Использовать ли адаптивное управление энтропией, представленное в [Skywork-OR1](https://huggingface.co/papers/2505.22312). При включении коэффициент энтропии `entropy_coef` обновляется на каждом шаге оптимизатора: увеличивается на `entropy_coef_delta`, если текущая энтропия ниже `entropy_target`, и уменьшается в противном случае. Коэффициент применяется только тогда, когда энтропия равна или ниже `entropy_target`.

entropy_coef_min (`float`, *необязательный*, по умолчанию `0.0`) : Нижняя граница для коэффициента энтропии при использовании адаптивного управления энтропией.

entropy_coef_max (`float`, *необязательный*, по умолчанию `1.0`) : Верхняя граница для коэффициента энтропии при использовании адаптивного управления энтропией.

entropy_coef_delta (`float`, *необязательный*, по умолчанию `0.005`) : Размер шага для корректировки коэффициента энтропии на каждом шаге оптимизатора при адаптивном контроле энтропии.

entropy_target (`float`, *optional*, по умолчанию `0.2`) : Целевое среднее значение энтропии на токен (в натах), используемое адаптивным управлением энтропией. Коэффициент применяется только в том случае, если текущая энтропия равна этому значению или ниже. Значение измеряется на том же наборе токенов, что и для потери политики: по умолчанию это все токены завершения, либо только подмножество с высокой энтропией, если `top_entropy_quantile < 1.0`. У типичных языковых моделей энтропия на токен находится в диапазоне 2–10 натов, поэтому значение по умолчанию `0.2` почти никогда не активирует регуляризацию (только при почти полном коллапсе энтропии); установите его близким к энтропии, которую вы наблюдаете на ранних этапах обучения (логгируется как метрика `entropy`), чтобы бонус срабатывал до коллапса политики (и учитывайте подмножество токенов при использовании `top_entropy_quantile`).

max_tool_calling_iterations (`int`, *optional*) : Максимальное количество ходов вызова инструментов при обучении агента. Если `None`, ограничений нет, и генерация останавливается, когда модель генерирует ход ответа без вызовов инструментов, когда завершение (все ходы и результаты инструментов) достигает `max_completion_length` токенов, или когда полная последовательность достигает максимальной длины модели (`vllm_max_model_length` при `vllm_mode="colocate"`, иначе `max_position_embeddings` модели).

vllm_importance_sampling_correction (`bool`, *optional*, defaults to `True`) : Whether to apply Importance Sampling (IS) to correct for the mismatch between vLLM completion logprobs and recomputed training logprobs. If set to `False`, no IS is applied regardless of `vllm_importance_sampling_mode`. When `True`, the selected mode determines how the IS ratios are computed and constrained. With `top_p < 1`, `top_k > 0` or `min_p > 0`, the recomputed logprobs are normalized over the candidate set each token was sampled from, which requires `vllm_mode="colocate"` and vLLM 0.28 or later; otherwise, the IS ratios are biased. vLLM bounds that candidate set with `top_k`, so `top_p < 1`, `min_p > 0` and structured outputs, which restrict it to the tokens the grammar allows, require `top_k > 0` (e.g. `top_k=512`). Structured outputs, which would otherwise stall training, also require `vllm_mode="colocate"` and vLLM 0.28 or later. vLLM also applies `repetition_penalty` to the logprobs it returns, so `repetition_penalty != 1.0` requires `vllm_importance_sampling_correction=False`.

vllm_importance_sampling_mode (`str`, *необязательный*, по умолчанию `"sequence_mask"`) : Определяет способ выполнения Importance Sampling, когда `vllm_importance_sampling_correction=True`. Возможные значения:  - `"token_truncate"`: Обрезка Importance Sampling на уровне токенов. Отношения для каждого токена ограничиваются диапазоном [C_min, C_max]. - `"token_mask"`: Маскирование Importance Sampling на уровне токенов. Отношения для токенов вне диапазона [C_min, C_max] устанавливаются в ноль. - `"sequence_truncate"`: Обрезка Importance Sampling на уровне последовательности. Единое отношение последовательности ограничивается диапазоном [C_min, C_max] и применяется ко всем токенам в последовательности. - `"sequence_mask"`: Маскирование Importance Sampling на уровне последовательности. Последовательности с отношениями вне диапазона [C_min, C_max] маскируются.

vllm_importance_sampling_clip_max (`float`, *optional*, по умолчанию `3.0`) : Верхняя граница C_max для importance sampling, используемая в `vllm_importance_sampling_mode`. Для режимов `*_truncate` отношения importance обрезаются сверху по значению C_max. Для режимов `*_mask` отношения, превышающие C_max, обнуляются.

vllm_importance_sampling_clip_min (`float`, *optional*) : Нижняя граница C_min для importance sampling, используемая в `vllm_importance_sampling_mode`. Для режимов `*_truncate` отношения обрезаются снизу по значению C_min. Для режимов `*_mask` отношения, меньшие C_min, обнуляются. Чтобы строго маскировать отношения ниже C_min без верхней границы, установите `vllm_importance_sampling_clip_max=None`.

off_policy_mask_threshold (`float`, *optional*) : Порог для маскирования off-policy последовательностей. Если `None`, маскирование off-policy последовательностей отключено. При заданном значении последовательности с отрицательными преимуществами и высоким расхождением KL маскируются для стабилизации обучения. Этот параметр соответствует порогу `delta` в уравнении 9 статьи [DeepSeek-V3.2 paper](https://huggingface.co/papers/2512.02556). Ожидается положительное значение (например, 0.5).

use_bias_correction_kl (`bool`, *необязательный*, по умолчанию `True`) : Указывает, следует ли умножать член KL на отношение важности выборки (importance sampling ratio), чтобы градиент KL стал несмещённым градиентом обратного KL, как описано в [статье DeepSeek-V3.2](https://huggingface.co/papers/2512.02556). Это изменяет градиент KL при `beta != 0`, в том числе в on-policy режиме: отношение дифференцируемо, поэтому оно влияет на градиент даже там, где его значение равно точно 1. Свойство несмещённого обратного KL выполняется для `importance_sampling_level="token"`; при `"sequence"` вес на уровне последовательности распространяется на KL для каждого токена.

**Параметры, управляющие ведением журнала:**

log_completions (`bool`, *необязательный*, по умолчанию `False`) : Флаг, определяющий, нужно ли логировать выборку пар (prompt, completion) каждые `logging_steps` шагов. Если установлен пакет `rich`, выборка выводится в консоль. Если включено логирование в `wandb` и/или `trackio`, данные отправляются в `wandb` и/или `trackio`.

log_multimodal (`bool`, *необязательный*, по умолчанию `True`) : Флаг, определяющий, следует ли записывать в журнал мультимодальное содержимое (изображения, видео и т. д.) вместе с завершениями. Отключите эту опцию, чтобы уменьшить размер журнала при работе с мультимодальными данными высокого разрешения.

num_completions_to_print (`int`, *optional*) : Количество завершений, которые выводить с помощью `rich`. Если `None`, в журнал записываются все завершения.

log_unique_prompts (`bool`, *необязательный*, по умолчанию `False`) : Флаг, определяющий, следует ли регистрировать уникальные промпты. Если `True`, регистрируются только уникальные промпты. Если `False`, регистрируются все промпты.

log_completions_hub_repo (`str`, *необязательный*) : репозиторий Hugging Face Hub для сохранения завершений. Должно быть полным именем репозитория, например `'username/reponame'` или `'orgname/reponame'`, или просто `'reponame'`, в этом случае репозиторий будет создан в пространстве имён текущего пользователя Hugging Face. Обратите внимание, что этот репозиторий будет публичным, если не установить `hub_private_repo=True` или если по умолчанию в вашей организации не создаются приватные репозитории.

**Параметры, управляющие ускорением генерации на основе непрерывного батчинга в transformers:**

use_transformers_continuous_batching (`bool`, *необязательный*, по умолчанию `False`) : Использовать ли движок непрерывного батчинга transformers для генерации завершений. Требуется `transformers>=5.8.0`.

transformers_continuous_batching_config (`dict`, *необязательный*) : Именованные аргументы для `ContinuousBatchingConfig`.

**Устаревшие параметры:**

use_transformers_paged :   Параметр `use_transformers_paged` устарел и будет удален в версии v2.0.0. Вместо него используйте `use_transformers_continuous_batching`.

vllm_importance_sampling_cap :   Параметр `vllm_importance_sampling_cap` устарел и будет удалён в версии v2.0.0. Используйте вместо него `vllm_importance_sampling_clip_max`.

Класс конфигурации для [GRPOTrainer](/docs/trl/main/ru/grpo_trainer#trl.GRPOTrainer).

Этот класс содержит только параметры, специфичные для обучения GRPO. Полный список аргументов обучения см. в документации [TrainingArguments](https://huggingface.co/docs/transformers/main/en/main_classes/trainer#transformers.TrainingArguments). Обратите внимание, что значения по умолчанию в этом классе могут отличаться от значений в [TrainingArguments](https://huggingface.co/docs/transformers/main/en/main_classes/trainer#transformers.TrainingArguments).

С помощью [HfArgumentParser](https://huggingface.co/docs/transformers/main/en/internal/trainer_utils#transformers.HfArgumentParser) мы можем превратить этот класс в аргументы [argparse](https://docs.python.org/3/library/argparse#module-argparse), которые можно указать в командной строке.

> [!NOTE]
> Эти параметры имеют значения по умолчанию, отличные от [TrainingArguments](https://huggingface.co/docs/transformers/main/en/main_classes/trainer#transformers.TrainingArguments): - `logging_steps`: по умолчанию `10`, а не `500`. - `gradient_checkpointing`: по умолчанию `True`, а не `False`. - `bf16`: по умолчанию `True`, если `fp16` не задан, а не `False`. - `learning_rate`: по умолчанию `1e-6`, а не `5e-5`.