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 do seu modelo durante o processo de fine-tuning (conhecidas como “rollouts”)
Avaliar essas saídas com um ou mais avaliadores que definiu na tarefa (saiba mais sobre avaliadores)
Calcular e aplicar atualizações de pesos com base nas avaliações (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 mais pela sua utilização para além do tempo que contribuem para o ciclo principal de treino. A exceção são os modelos avaliadores, em que também contabilizamos os tokens que esses avaliadores consomem durante as atividades acima. Estes tokens aparecem como uma rubrica separada na sua fatura. Os tokens consumidos por modelos avaliadores são faturados às taxas 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 modelos avaliadores na tarefa. Este campo pode ser consultado através da API (GET /v1/fine_tuning/jobs/{job_id}) ou através do painel de fine-tuning.
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 a tarefa de RFT através da 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 trabalhador disponível |
| 01 : 30 | 00 : 00 | RUNNING | 30 minutos a preparar o treino (transferir 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 com falha
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 a tarefa de RFT através da 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 trabalhador disponível |
| 01 : 30 | 00 : 00 | RUNNING | 30 minutos a preparar o treino (transferir 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 um 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 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, é colocada em pausa, é cancelada ou falha. Cada cobrança abrange o trabalho realizado desde a cobrança 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 será cobrada a parte perdida. Se cancelar uma execução, ser-lhe-á cobrado o trabalho realizado até ao cancelamento.
Como são faturados os tokens dos modelos avaliadores?
Contamos os tokens usados por quaisquer modelos avaliadores que configurar. Após a conclusão do treino, faturamos esses tokens às nossas taxas padrão por token.
Posso colocar uma execução em pausa e retomá-la?
Sim. Quando coloca em pausa, guardamos um checkpoint e cobramos o trabalho realizado até esse momento. Quando retoma, só lhe será cobrado o trabalho adicional realizado após a retoma.
Se tiver outras perguntas sobre a faturação do Reinforcement Fine‑Tuning, contacte a nossa equipa de apoio.
