

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Referência de hiperparâmetros
<a name="model-customize-mtrl-hyperparams"></a>

A tabela a seguir lista todos os hiperparâmetros configuráveis para trabalhos de treinamento de RL em vários turnos. Os padrões de receita estão incluídos abaixo.


| Categoria | Parâmetros | Padrão | Escolha | Explicação | 
| --- | --- | --- | --- | --- | 
| Batch | global\_batch\_size | 128 | {32, 64, 128} | Número de solicitações exclusivas por etapa do treinamento. | 
| Batch | tamanho\_do\_grupo | 8 | [2, 32] | Implantações por prompt usadas para calcular vantagens baseadas em grupos (GRPO/RLOO). | 
| RL | método\_vantagem | baseado em grupos | monte\_carlo, baseado em grupo, baseado em grupo\_por turno, rolo, reforce\_pp, reforce\_pp\_baseline, opo, grupo\_passk, gpg | Método para calcular vantagens para lançamentos. | 
| RL | loss\_fn | ppo | importância\_amostragem, ppo, ciso | Formulação para perda de RL. | 
| RL | clip\_low\_threshold | 0.8 | [0, 1] | Limite inferior para cortar a razão de probabilidade da política π\_new/π\_old na perda substituta. PPO-style  | 
| RL | clip\_high\_threshold | 1.2 | [1, 10] | Limite superior para reduzir a taxa de probabilidade da política na perda. | 
| parâmetros\_de\_amostragem | temperatura | 1 | [0, 2] | Temperatura de amostragem aplicada aos logits antes da amostragem. | 
| parâmetros\_de\_amostragem | sampling\_top\_p | 1 | [0, 1] | Nucleus-sampling corte. Amostras somente do menor conjunto de tokens cuja probabilidade cumulativa ≥ top\_p. | 
| parâmetros\_de\_amostragem | sampling\_max\_tokens | 4096 | [512, 8192] | Máximo de tokens que o modelo pode gerar por turno durante o lançamento. | 
| val\_sampling\_params | sampling\_max\_tokens | 4096 | [512, 8192] | Número máximo de tokens que o modelo pode gerar por turno durante a avaliação. | 
| val\_metrics\_config | pass\_k\_values | [1, 2, 4, 8, 16, 32] | n/a | Lista de valores k para computação das métricas pass @k. | 
| val\_metrics\_config | limiar de sucesso | 1 | n/a | Limite de recompensa por considerar um lançamento “bem-sucedido”. | 
| Agendamento | max\_epochs | 1 | [1, 30] | O total passa pelos dados. | 
| Agendamento | etapas máximas | 50 | [1, 1000] | Total de iterações de treinamento. | 
| Agendamento | val\_every | 10 | [0, 100] | Intervalo de avaliação (etapas). | 
| Modelo | model\_name\_or\_path | obrigatório |  | Modelo para ajuste fino (por exemplo, "GPT-OSS-20B“). | 
| Modelo | lora\_rank | 32 | [16,64] | A classificação do adaptador LoRa que controla a capacidade do adaptador. | 
| Modelo | lora\_alfa | 64 | [16,128] | Fator de escala LoRa. Magnitude efetiva da atualização e alfa/rank. | 
| Modelo | learning\_rate | 4,00 E-05 | (0, 1e-2] | Taxa de aprendizado de Adam. | 
| Modelo | adam\_beta1 | 0.9 | [0, 0,999999] | Taxa de decaimento exponencial para a média contínua do gradiente (primeiro momento) em Adam. | 
| Modelo | adam\_beta2 | 0,95 | [0, 0,999999] | Taxa de decaimento exponencial para a média contínua do gradiente quadrado (segundo momento) em Adam. | 
| Modelo | adam\_eps | 1,00 E-08 | [1e-16, 1e-2] | Pequena constante adicionada ao denominador para estabilidade numérica na regra de atualização de Adam. | 
| Modelo | adam\_weight\_decay | 0 | [0, 1] | Coeficiente de redução de peso desacoplado (). AdamW-style | 
| Modelo | adam\_grad\_clip\_norm | 1 | [0, 100] | Norma máxima de gradiente global. | 
| Implantação | rollout\_max\_concurrency | 96 | [32, 96] | Os processos máximos de implantação em andamento podem ocorrer paralelamente. | 
| Implantação | tempo\_limite de implementação | 600 | [300, 86400] | Tratamento de falhas: tempo após o qual tratamos como falha na implantação. | 
| Implantação | rollout\_max\_retries | 3 | [1, 10] | Número de tentativas de repetição em implementações malsucedidas. | 
| async\_config | max\_steps\_off\_policy | 3 | [0, 10] | Limite de obsolescência no treinamento assíncrono. Quando 0, é um treinamento síncrono. | 

## Práticas recomendadas para ajustar hiperparâmetros
<a name="model-customize-mtrl-hyperparams-best-practices"></a>

Quando uma corrida é plana ou está em colapso, os seis parâmetros a seguir são responsáveis por quase toda a explicação.

### Taxa de aprendizado
<a name="model-customize-mtrl-hp-bp-lr"></a>

Ele `learning_rate` controla o tamanho da etapa que o otimizador dá em cada iteração de treinamento. No RL de várias voltas, o sinal de gradiente por etapa varia de acordo com a tarefa: um ambiente de recompensa esparsa com resultados binários produz muitos grupos em que todos os lançamentos pontuam de forma idêntica, gerando vantagem zero para todo o grupo. Somente grupos com resultados mistos produzem sinal de gradiente, então o gradiente útil de cada etapa é diluído. A taxa de aprendizado precisa ser menor para se alinhar com o sinal mais fraco, ou a corrida precisa de mais etapas.

Um ambiente de recompensa densa em que as trajetórias dentro de um grupo obtêm pontuações diferentes de forma confiável produz vantagens consistentes e diferentes de zero na maioria dos grupos, e a taxa de aprendizado padrão geralmente já é suficiente.

O tamanho efetivo da etapa também depende da configuração do LoRa - a magnitude real da atualização é `learning_rate × alpha/rank` - portanto, uma taxa fixa de aprendizado ocorre de forma diferente dependendo da capacidade do adaptador.

### Função de perda e faixa de recorte
<a name="model-customize-mtrl-hp-bp-loss"></a>

Se você é iniciante no MTRL, a amostragem por importância (`importance_sampling`) é um bom ponto de partida antes de passar para algoritmos avançados baseados em recortes. O PPO e o CISPO usam `clip_low_threshold` e `clip_high_threshold` para restringir a razão de probabilidade `policy_new(action|state) / policy_old(action|state)` — o quanto a política pode mudar em uma única etapa do treinamento.

Uma proporção de `1.0` significa que não há mudança. O limite mais baixo (por exemplo,`0.8`) impede que a política desaprenda agressivamente as ações que ela preferia anteriormente. O limite superior (por exemplo,`1.2`) impede que ele se comprometa demais com ações que pareciam boas em um lote.
+ **O PPO** with `(clip_low_threshold, clip_high_threshold) = (0.8, 1.2)` é a linha de base segura para qualquer primeira execução.
+ O **CISPO requer um** amplo recorte assimétrico. Comece com`clip_low_threshold = 1.0`,`clip_high_threshold = 6.0`. O CISPO permite que as probabilidades de ação incorreta diminuam livremente e depende apenas do clipe superior para evitar instabilidade.

É recomendável ajustar os limites de recorte se o treinamento sofrer colapso ou falta de treinamento.

### Tamanho do lote e tamanho do grupo
<a name="model-customize-mtrl-hp-bp-batch"></a>

Esses dois parâmetros determinam em conjunto quanto sinal de gradiente útil cada etapa de treinamento recebe.

`global_batch_size`controla quantos prompts exclusivos são incluídos em uma etapa do otimizador. Lotes maiores (128) têm a média de gradientes em relação a mais solicitações, produzindo curvas de recompensa mais suaves e atualizações mais estáveis. Lotes menores (32) são mais baratos por etapa e úteis para iteração rápida, mas produzem gradientes mais ruidosos. Para execuções de produção, 128 é um bom padrão; para depuração ou triagem de hiperparâmetros, 32 é bom.

`group_size`determina quantas implementações independentes são geradas para cada prompt. Essas implementações são comparadas entre si para calcular as vantagens. Se todos os lançamentos receberem a mesma recompensa (todos forem bem-sucedidos ou todos falharem), a vantagem será zero e o grupo não emitirá nenhum sinal de gradiente. O padrão é `group_size = 8`. Reduza se você tiver diversidade suficiente no grupo, aumente se o ambiente exigir mais diversidade.

Total de lançamentos por etapa =. `global_batch_size × group_size` Em configurações de recompensa esparsa, onde a maioria dos grupos produz sinal zero, geralmente é mais eficiente manter o tamanho do grupo moderado e, em vez disso, aumentar o tamanho do lote ou a contagem de etapas.

### Off-policy velhice
<a name="model-customize-mtrl-hp-bp-offpolicy"></a>

No treinamento assíncrono, `max_steps_off_policy` controla o quão obsoleta uma distribuição pode ficar antes de ser descartada. O padrão de `3` oculta a latência final do servidor de distribuição. Mas lançamentos obsoletos têm proporções de importância que se desviam substancialmente e`1.0`, quando essas proporções atingem os limites do clipe, não contribuem com nenhum sinal de gradiente.

**Defina como 0 ao fechar a depuração.** A obsolescência assíncrona aumenta as atualizações ponderadas pela importância e pode obscurecer as causas principais. Defina para`0`, estabilize e reative quando o problema for compreendido. Para ambientes em que as implementações são rápidas, `max_steps_off_policy = 1` pode ser um padrão melhor.

### Amostragem máxima de tokens
<a name="model-customize-mtrl-hp-bp-maxtokens"></a>

`sampling_max_tokens`é o limite de geração por turno. Se o limite for muito baixo, as respostas do modelo ficam truncadas no meio do pensamento e ele recebe uma recompensa por uma tentativa incompleta. A política então aprende a associar esses prefixos truncados a resultados ruins, suprimindo comportamentos exploratórios que teriam sido bem-sucedidos se houvesse mais espaço.

O padrão 4096 funciona para a maioria das tarefas. Aumente para 8192 para modelos com respostas muito thinking/reasoning longas. A regra de dimensionamento é: `max_turns × (sampling_max_tokens + expected_tool_output) + prompt ≤ max_sequence_length` com alguma margem.

**Diagnóstico:** monitor`rollout/tokens/response_max`. Se as trajetórias se agruparem exatamente no limite, o modelo está sendo truncado silenciosamente e provavelmente está perdendo sinal. `val_sampling_params.sampling_max_tokens`deve coincidir com o treinamento.

### Configuração de distribuição
<a name="model-customize-mtrl-hp-bp-rollout"></a>

Esses parâmetros controlam como os lançamentos são produzidos e como o treinador lida com lançamentos lentos ou malsucedidos.
+ `rollout_max_concurrency`— Controla quantos lançamentos estão em andamento ao mesmo tempo. O padrão de 96 funciona bem para a maioria das configurações. Configurá-lo muito alto no modo assíncrono produz lançamentos obsoletos e pode sobrecarregar o mecanismo de inferência.
+ `rollout_timeout`— Quanto tempo (em segundos) esperar por uma única implementação antes de tratá-la como falha. O tamanho padrão de 600 é para ambientes típicos de uso de ferramentas. Definir um valor muito baixo trunca as implementações que teriam sido bem-sucedidas em mais tempo.
+ `rollout_max_retries`— Controla as tentativas de repetição em caso de implementações malsucedidas. Se a taxa de falha permanente exceder aproximadamente 1%, o problema está na configuração do ambiente, não na contagem de novas tentativas.

### Parâmetros de suporte
<a name="model-customize-mtrl-hp-bp-supporting"></a>
+ **Capacidade LoRa (`lora_rank`e`lora_alpha`).** A magnitude efetiva da atualização por etapa é proporcional a`alpha/rank`, que atua como um multiplicador na taxa de aprendizado. O padrão é `lora_rank = 32, lora_alpha = 64` (uma proporção de 2:1). Considere aumentar somente se todo o resto estiver bem ajustado e a curva de recompensa ainda se estabilizar — dobre os dois juntos (64/128) para aumentar a capacidade e, ao mesmo tempo, preservar a mesma taxa efetiva de aprendizado.
+ **temperatura = 1,0, sampling\_top\_p = 1,0 para treinamento.** Para o treinamento de RL, você deseja diversidade nas implementações dentro de um grupo, para que a linha de base do grupo tenha sinal. A temperatura 1,0 é um bom padrão. Para avaliação, use temperatura = 0,0 (decodificação gananciosa) para que as curvas de avaliação sejam determinísticas e comparáveis em todas as execuções.
+ **pass\_k\_values.** Pass @1 é a principal métrica de avaliação. Pass @G (onde G = group\_size) é uma verificação de sanidade útil: se pass @G for muito alto, a maioria dos prompts é muito fácil; se pass @G for muito baixo, a maioria dos prompts será muito difícil e o sinal do grupo será esparso.
+ **max\_steps e max\_epochs.** `max_steps = 50`para triagem (o suficiente para ver se a curva está se movendo), 100 para produção. O colapso do CISPO tende a aparecer entre as etapas 40—80. `max_epochs = 1`é o padrão; várias épocas reutilizam os mesmos prompts com novas implementações, o que pode ajudar se o conjunto de prompts for pequeno, mas corre o risco de se ajustar demais a uma distribuição restrita de prompts.
+ **adam\_beta2 = 0,95.** Menor que o padrão SFT de 0,999. Em RL, as estatísticas de gradiente não são estacionárias, portanto, o otimizador precisa rastrear a variação recente do gradiente de forma mais agressiva.
+ **weight\_decay = 0,0.** O LoRa já restringe as atualizações por meio de parametrização de baixa classificação. A adição de compostos de decaimento de peso à regularização de maneiras que não foram bem caracterizadas para o ajuste fino de RL.
+ **adam\_grad\_clip\_norm = 1,0.** Limita a norma global de gradiente. Se o colapso se correlacionar com grandes picos de pré-clipe, caia para 0,5. Se a norma estiver em exatamente 1,0 para muitas etapas e a recompensa for plana, o clipe pode ser o gargalo — aumente para 2,0 com cuidado.