Como funciona a faturação do RFT
O Reinforcement Fine‑Tuning (RFT) permite-lhe otimizar o desempenho dos modelos de raciocínio da OpenAI através de aprendizagem por reforço. Ao contrário das nossas ofertas de fine-tuning supervisionado ou por preferências, que são faturadas pelo número de tokens no conjunto de dados de treino, o RFT é faturado com base no tempo que a sua execução de treino passa a realizar o trabalho central de aprendizagem automática.
Este guia explica o que conta como tempo de treino faturável, como tratamos pausas e cancelamentos, e como as suas escolhas de configuração podem afetar o custo.
Preços
Computação: $100 por hora de tempo de relógio gasto no ciclo principal de treino para
o4-mini-2025-04-16. Os encargos são rateados ao segundo e arredondados a duas casas decimais na fatura (por exemplo, 2,55 horas).Utilização de modelos avaliadores: Se utilizar um modelo da OpenAI para “avaliar” saídas durante o treino, os tokens consumidos por essas chamadas de avaliação são faturados separadamente às nossas taxas normais da API após a conclusão do treino.
Cobramos apenas o trabalho de treino que efetivamente atualiza o seu modelo (ao que chamamos “progresso útil capturado”).
O que faturamos
Faturamos o tempo que o seu worker de treino passa a treinar ativamente o seu modelo, especificamente:
Gerar amostras a partir do seu modelo durante o processo de afinação (conhecidas como «rollouts»)
Avaliar esses resultados com um ou mais avaliadores que definiu na tarefa (saiba mais sobre avaliadores)
Calcular e aplicar atualizações de pesos com base nas notas (retropropagação).
Executar quaisquer passos de validação (avaliação) que tenha configurado.
A maioria dos avaliadores é «gratuita» de executar, o que significa que não cobramos extra pela sua utilização fora do tempo que contribuem para o ciclo principal de treino. A exceção são os avaliadores de modelo, para os quais também contabilizamos os tokens que esses avaliadores consomem durante as atividades acima. Estes tokens aparecem como um item de linha separado na sua fatura. Os tokens consumidos por avaliadores de modelo são faturados às tarifas normais de inferência (preços da OpenAI).
O que NÃO faturamos
Não cobramos o tempo gasto em:
Validar ou inspecionar o seu conjunto de dados antes do início do treino.
Verificações de segurança ao seu conjunto de dados.
Esperar numa fila por recursos computacionais.
Transferir pesos do modelo ou conjuntos de dados.
Preparar (renderizar) o seu conjunto de dados para o nosso formato de treino.
Avaliações de segurança pós-treino do seu modelo ajustado.
Se o trabalho de treino se perder devido a um erro do nosso lado (por exemplo, se um worker falhar e tiver de recuar para um checkpoint anterior), não lhe será cobrado o tempo de computação perdido nem os tokens dos avaliadores. Mais detalhes sobre isto na secção seguinte.
Progresso útil capturado e eventos de faturação
O treino consiste em muitas pequenas atualizações ao seu modelo. Acompanhamos quantas dessas atualizações são concluídas com sucesso. As cobranças baseiam-se no tempo de computação e nos tokens dos avaliadores associados a estas atualizações bem-sucedidas.
Emitimos uma cobrança quando ocorre um dos seguintes “eventos de faturação”:
O treino é concluído com sucesso.
Coloca o treino em pausa.
Cancela o treino.
O treino falha.
Cada cobrança abrange o trabalho incremental realizado desde a última cobrança. Por exemplo:
Se colocar uma execução em pausa, guardamos um checkpoint e cobramos-lhe o tempo de computação e os tokens dos avaliadores usados desde a última cobrança.
Quando retoma, o treino continua a partir do checkpoint. A cobrança seguinte (na conclusão, noutra pausa, cancelamento ou falha) abrangerá apenas o trabalho adicional realizado após a retoma.
Se cancelar uma execução, cobramos-lhe o trabalho realizado até ao cancelamento.
Se o treino falhar e se perder trabalho desde a última cobrança, essa parte perdida não lhe será faturada.
Esta abordagem de “progresso útil capturado” garante que só paga pelo trabalho que é mantido no seu modelo ou que abandona intencionalmente.
Ver o progresso da tarefa
As tarefas de RFT têm um campo chamado usage_metrics, que documenta a utilização total da tarefa até ao passo atual. Isto inclui o tempo gasto em treino e todos os tokens usados por todos os avaliadores de modelo na tarefa. Este campo pode ser inspecionado através da API (GET /v1/fine_tuning/jobs/{job_id}) ou através do painel de afinação.
Fatores que influenciam o tempo de treino
Como a faturação se baseia no tempo, as suas escolhas de configuração afetam diretamente o custo. Os principais fatores incluem:
Dificuldade do problema: se o seu conjunto de dados for composto por problemas difíceis, o modelo provavelmente passará mais tempo a raciocinar sobre cada problema, o que aumenta o tempo necessário para produzir cada amostra.
Intensidade computacional: o hiperparâmetro
compute_multipliercontrola quanta computação faz por passo de treino. Valores mais elevados incentivam o modelo a raciocinar de forma mais detalhada sobre cada ponto de dados, o que faz com que cada passo decorra mais lentamente.Definições de validação:
Um conjunto de validação maior aumenta o tempo gasto na avaliação.
Aumentar
eval_samples(o número de saídas do modelo avaliadas por exemplo de validação) aumenta o tempo de validação.Executar a validação com mais frequência (valor mais baixo de
eval_interval) aumenta a proporção de tempo gasta na validação.
Desempenho do avaliador:
Modelos avaliadores maiores ou mais capazes demoram mais tempo a devolver uma avaliação do que os mais pequenos. Por exemplo, avaliar com um modelo de raciocínio pode demorar 10x mais do que avaliar com um modelo sem raciocínio.
Funções de avaliação Python complexas demoram mais tempo a executar do que as simples.
Estas definições permitem-lhe equilibrar custo, velocidade e qualidade do modelo. Por exemplo, validações frequentes podem detetar problemas mais cedo, mas aumentam o custo. Avaliar com um modelo mais avançado pode melhorar drasticamente a precisão da avaliação, mas tornará cada passo de avaliação mais lento e as tarefas mais dispendiosas.
Gerir custos
Para controlar os seus gastos:
Comece com execuções mais curtas para perceber como a sua configuração afeta o tempo.
Use um número razoável de exemplos de validação e
eval_samples. Evite validar com mais frequência do que a necessária.Escolha o modelo avaliador mais pequeno que satisfaça os seus requisitos de qualidade.
Mantenha eficientes os avaliadores Python personalizados.
Ajuste
compute_multiplierpara equilibrar a velocidade de convergência e o custo.Acompanhe a sua execução no painel ou através da API. Pode colocar em pausa ou cancelar a qualquer momento.
Exemplos
Execução de treino bem-sucedida
| Tempo de treino | Tempo faturado | Estado | Descrição |
|---|---|---|---|
| 00:00 | 00:00 | – | O utilizador cria uma tarefa de RFT via API |
| 00:10 | 00:00 | VALIDATING_FILES | 10 minutos gastos a validar o conjunto de dados |
| 00:30 | 00:00 | VALIDATING_FILES | 20 minutos a executar verificações de segurança do conjunto de dados |
| 01:00 | 00:00 | QUEUED | 30 minutos à espera de um worker disponível |
| 01:30 | 00:00 | RUNNING | 30 minutos a configurar o treino (transferência de pesos, pré-processamento, etc.) |
| 05:30 | 04:00 | RUNNING | 4 horas gastas em treino |
| 06:00 | 04:00 | RUNNING | 30 minutos a executar avaliações de segurança do modelo resultante |
| 06:00 | 04:00 | SUCCEEDED | O treino termina |
Neste caso, o tempo total de relógio é de 6 horas, mas apenas 4 horas são faturáveis. O custo seria 4 horas × $100/hora = $400.
Exemplo de tarefa falhada
Neste exemplo, a execução treina durante 2 horas, escreve um checkpoint, treina durante mais 1 hora, mas depois falha. Apenas as 2 horas de treino até ao checkpoint são faturáveis.
| Tempo de treino | Tempo faturado | Estado | Descrição |
|---|---|---|---|
| 00:00 | 00:00 | – | O utilizador cria uma tarefa de RFT via API |
| 00:10 | 00:00 | VALIDATING_FILES | 10 minutos gastos a validar o conjunto de dados |
| 00:30 | 00:00 | VALIDATING_FILES | 20 minutos a executar verificações de segurança do conjunto de dados |
| 01:00 | 00:00 | QUEUED | 30 minutos à espera de um worker disponível |
| 01:30 | 00:00 | RUNNING | 30 minutos a configurar o treino (transferência de pesos, pré-processamento, etc.) |
| 03:30 | 02:00 | RUNNING | 2 horas gastas em treino |
| 03:30 | 02:00 | RUNNING | Checkpoint criado no passo 5 |
| 04:30 | 02:00 | RUNNING | O treino falha devido a erro interno no passo 8 (após mais 1 hora) |
| 04:30 | 02:00 | RUNNING | 30 minutos a avaliar e validar o checkpoint |
| 04:30 | 02:00 | SUCCEEDED | A tarefa termina (com o checkpoint mais recente) |
Embora tenham sido gastas 3 horas em treino no total, apenas 2 horas são «capturadas» num checkpoint utilizável e são faturadas. A hora de trabalho de treino perdida devido à falha não é da sua responsabilidade. O custo seria 2 horas × $100/hora = $200.
Perguntas frequentes
Quando me é cobrado?
Faturamos quando a sua execução é concluída, pausada, cancelada ou falha. Cada fatura abrange o trabalho realizado desde a fatura anterior.
Pago se uma execução falhar?
Se uma execução falhar devido a um erro nosso e algum trabalho de treino recente se perder, não lhe é cobrada a parte perdida. Se cancelar uma execução, é-lhe cobrado o trabalho realizado até ao cancelamento.
Como são faturados os tokens dos modelos avaliadores?
Contamos os tokens usados por quaisquer avaliadores de modelo que configurar. Depois de o treino terminar, faturamos esses tokens às nossas tarifas padrão por token.
Posso pausar e retomar uma execução?
Sim. Quando pausa, guardamos um checkpoint e cobramos o trabalho realizado até então. Quando retoma, só lhe será cobrado o trabalho adicional realizado depois de retomar.
Se tiver outras perguntas sobre a faturação da Reinforcement Fine‑Tuning, contacte a nossa equipa de apoio.
