OpenAI
Ang page na ito ay isinalin ng AI. Tingnan ang orihinal na artikulo sa English.

Gabay sa pagsingil para sa Reinforcement Fine-Tuning API

Paano gumagana ang pagsingil para sa RFT API

Na-update: 8 days ago

Paano gumagana ang pagsingil para sa RFT

Nagbibigay-daan ang Reinforcement Fine‑Tuning (RFT) na i-optimize mo ang performance ng mga nangangatwirang modelo ng OpenAI gamit ang pagpapatibay ng pag-aaral. Hindi tulad ng aming mga alok na supervised o preference fine‑tuning, na sinisingil batay sa bilang ng mga token sa dataset ng pagsasanay, ang RFT ay sinisingil batay sa panahong ginugugol ng iyong training run sa pagsasagawa ng pangunahing gawain sa machine learning.

Ipinapaliwanag ng gabay na ito kung ano ang binibilang bilang nasisingil na oras ng pagsasanay, kung paano namin pinangangasiwaan ang mga pag-pause at pagkansela, at kung paano makaaapekto sa gastos ang iyong mga piniling configuration.

Pagpepresyo

  • Compute: $100 kada oras ng wall-clock time na ginugol sa pangunahing training loop para sa o4-mini-2025-04-16. Ang mga singil ay proporsyonal kada segundo at niro-round sa dalawang decimal place sa invoice (hal., 2.55 oras).

  • Paggamit ng model grader: Kung gagamit ka ng modelo ng OpenAI upang “maggrado” ng mga output habang nagsasanay, ang mga token na kinonsumo ng mga grading call na iyon ay hiwalay na sisingilin sa aming karaniwang API rates pagkatapos makumpleto ang pagsasanay.

Naniningil lamang kami para sa gawaing pagsasanay na aktuwal na nag-a-update sa iyong modelo (ang tinatawag naming “captured forward progress”).

Kung ano ang sinisingil namin

Sinisingil namin ang oras na ginugugol ng iyong training worker sa aktibong pagsasanay ng iyong modelo, partikular ang:

  • Pagbuo ng mga sample mula sa iyong modelo habang nasa proseso ng fine-tuning (kilala bilang “rollouts”)

  • Pagsusuri sa mga output na iyon gamit ang isa o higit pang grader na tinukoy mo sa job (matuto pa tungkol sa mga grader)

  • Pagkalkula at paglalapat ng mga update sa weight batay sa mga grade (backpropagation).

  • Pagpapatakbo ng anumang mga hakbang sa validation (evaluation) na na-configure mo.

Karamihan sa mga grader ay “libre” patakbuhin, ibig sabihin hindi kami naniningil ng dagdag para sa paggamit ng mga ito bukod sa dami ng oras na naidaragdag nila sa pangunahing training loop. Ang eksepsiyon dito ay para sa mga grader na modelo, kung saan binibilang din namin ang mga token na nakokonsumo ng mga grader na iyon sa mga aktibidad sa itaas. Lalabas ang mga token na ito bilang hiwalay na line item sa iyong invoice. Ang mga token na nakonsumo ng mga grader na modelo ay sinisingil sa normal na inference rates (pagpepresyo ng OpenAI).

Ano ang HINDI namin sinisingil

Hindi kami naniningil para sa oras na ginugol sa:

  • Pag-validate o pagsisiyasat ng iyong dataset bago magsimula ang pagsasanay.

  • Mga safety check sa iyong dataset.

  • Paghihintay sa pila para sa mga compute resource.

  • Pagda-download ng weights ng modelo o mga dataset.

  • Paghahanda (pagre-render) ng iyong dataset sa aming training format.

  • Mga post‑training safety evaluation ng iyong fine‑tuned na modelo.

Kung mawala ang gawaing pagsasanay dahil sa isang error sa aming panig (halimbawa, kung mag-crash ang isang worker at kailangang bumalik sa isang nakaraang checkpoint), hindi ka sisingilin para sa nawalang compute time o mga token ng grader. Higit pang detalye tungkol dito sa susunod na seksyon.

Captured forward progress at mga billing event

Binubuo ang pagsasanay ng maraming maliliit na update sa iyong modelo. Sinusubaybayan namin kung ilan sa mga update na ito ang matagumpay na nakumpleto. Nakabatay ang mga singil sa compute time at mga token ng grader na nauugnay sa mga matagumpay na update na ito.

Naglalabas kami ng singil kapag nangyari ang isa sa mga sumusunod na “billing event”:

  • Matagumpay na natapos ang pagsasanay.

  • Ipi-pause mo ang pagsasanay.

  • Kakanselahin mo ang pagsasanay.

  • Nabigo ang pagsasanay.

Sinasaklaw ng bawat singil ang nadagdag na trabahong nagawa mula noong huling singil. Halimbawa:

  • Kung i-pause mo ang isang run, nagse-save kami ng checkpoint at sinisingil ka para sa compute time at mga token ng grader na nagamit mula noong huling singil.

  • Kapag ipinagpatuloy mo ito, magpapatuloy ang pagsasanay mula sa checkpoint. Ang susunod na singil (sa pagkumpleto, panibagong pag-pause, pagkansela, o pagkabigo) ay sasaklaw lamang sa dagdag na trabahong nagawa pagkatapos ipagpatuloy.

  • Kung kakanselahin mo ang isang run, sisingilin ka namin para sa trabahong natapos bago ang pagkansela.

  • Kung mabigo ang pagsasanay at mawala ang trabahong nagawa mula noong huling singil, hindi ka sisingilin para sa nawalang bahagi.

Tinitiyak ng paraang ito ng “captured forward progress” na magbabayad ka lamang para sa trabahong napanatili sa iyong modelo o sadyang tinalikuran mo.

Pagtingin sa progreso ng job

May field ang mga RFT job na tinatawag na usage_metrics na nagdodokumento ng kabuuang paggamit ng job hanggang sa kasalukuyang hakbang. Kabilang dito ang oras na ginugol sa pagsasanay, at lahat ng token na ginamit sa lahat ng grader na modelo sa job. Maaaring suriin ang field na ito sa pamamagitan ng API (GET /v1/fine_tuning/jobs/{job_id}) o sa pamamagitan ng dashboard ng fine-tuning.

Mga salik na nakaaapekto sa oras ng pagsasanay

Dahil nakabatay sa oras ang pagsingil, direktang nakaaapekto sa gastos ang iyong mga piniling configuration. Kabilang sa mahahalagang salik ang:

  • Hirap ng problema: kung ang iyong dataset ay binubuo ng mahihirap na problema, malamang na mas maraming oras ang gugugulin ng modelo sa pangangatwiran sa bawat problema, na nagpapataas sa oras na kailangan para makabuo ng bawat sample.

  • Tindi ng compute: Kinokontrol ng compute_multiplier hyperparameter kung gaano karaming pagkukuwenta ang ginagawa mo sa bawat hakbang ng pagsasanay. Hinihikayat ng mas matataas na halaga ang modelo na mangatwiran nang mas detalyado sa bawat datapoint, kaya mas mabagal tumakbo ang bawat hakbang.

  • Mga setting ng validation:

    • Ang mas malaking validation set ay nagpapataas ng oras na ginugugol sa ebalwasyon.

    • Ang pagtaas ng eval_samples (ang bilang ng mga output ng modelo na ginagawaran ng grado sa bawat validation example) ay nagpapataas ng oras ng validation.

    • Ang mas madalas na pagpapatakbo ng validation (mas mababang eval_interval) ay nagpapataas sa bahagdan ng oras na ginugugol sa validation.

  • Performance ng grader:

    • Mas matagal magbalik ng grado ang mas malalaki o mas may kakayahang model grader kaysa sa mas maliliit. Halimbawa, ang paggrado gamit ang isang nangangatwirang modelo ay maaaring tumagal nang 10x kaysa paggrado gamit ang modelong hindi nangangatwiran.

    • Mas matagal patakbuhin ang mga komplikadong Python grading function kaysa sa mga simple.

Binibigyang-daan ka ng mga setting na ito na timbangin ang gastos, bilis, at kalidad ng modelo. Halimbawa, maaaring mas maagang makahuli ng mga isyu ang madalas na validation ngunit nagpapataas ito ng gastos. Ang paggrado gamit ang mas advanced na modelo ay maaaring lubhang magpahusay sa katumpakan ng paggrado, ngunit pababagalin nito ang bawat hakbang ng paggrado at gagawing mas mahal ang mga job.

Pamamahala ng gastos

Upang makontrol ang iyong paggastos:

  • Magsimula sa mas maiikling run upang maunawaan kung paano nakaaapekto ang iyong configuration sa oras.

  • Gumamit ng makatwirang bilang ng mga validation example at eval_samples. Iwasang mag-validate nang mas madalas kaysa sa kailangan mo.

  • Piliin ang pinakamaliit na grader model na nakatutugon sa iyong mga kinakailangan sa kalidad.

  • Panatilihing episyente ang mga custom Python grader.

  • I-adjust ang compute_multiplier upang mabalanse ang bilis ng convergence at gastos.

  • Subaybayan ang iyong run sa dashboard o sa pamamagitan ng API. Maaari kang mag-pause o magkansela anumang oras.

Mga halimbawa

Matagumpay na training run

Oras ng PagsasanaySinisingil na OrasStatusPaglalarawan
00:0000:00Gumagawa ang user ng RFT job sa pamamagitan ng API
00:1000:00VALIDATING_FILES10 minutong ginugol sa pag-validate ng dataset
00:3000:00VALIDATING_FILES20 minutong pagpapatakbo ng mga safety check sa dataset
01:0000:00QUEUED30 minutong paghihintay para sa available na worker
01:3000:00RUNNING30 minutong pagse-set up ng pagsasanay (pag-download ng mga weight, preprocessing, atbp.)
05:3004:00RUNNING4 na oras na ginugol sa pagsasanay
06:0004:00RUNNING30 minutong pagpapatakbo ng mga safety evaluation ng nagresultang modelo
06:0004:00SUCCEEDEDNatapos ang pagsasanay

Sa kasong ito, ang kabuuang wall-clock na oras ay 6 na oras, pero 4 na oras lang ang maaaring singilin. Ang gastos ay magiging 4 na oras × $100/oras = $400.

Halimbawa ng nabigong job

Sa halimbawang ito, nagsasanay ang run sa loob ng 2 oras, nagsusulat ng checkpoint, nagsasanay pa ng 1 oras, pero pagkatapos ay nabigo. Tanging ang 2 oras ng pagsasanay hanggang sa checkpoint ang maaaring singilin.

Oras ng PagsasanaySinisingil na OrasStatusPaglalarawan
00:0000:00Gumagawa ang user ng RFT job sa pamamagitan ng API
00:1000:00VALIDATING_FILES10 minutong ginugol sa pag-validate ng dataset
00:3000:00VALIDATING_FILES20 minutong pagpapatakbo ng mga safety check sa dataset
01:0000:00QUEUED30 minutong paghihintay para sa available na worker
01:3000:00RUNNING30 minutong pagse-set up ng pagsasanay (pag-download ng mga weight, preprocessing, atbp.)
03:3002:00RUNNING2 oras na ginugol sa pagsasanay
03:3002:00RUNNINGNagkaroon ng checkpoint sa hakbang 5
04:3002:00RUNNINGNabigo ang pagsasanay dahil sa internal error sa hakbang 8 (pagkatapos ng 1 oras pa)
04:3002:00RUNNING30 minutong pagsusuri at pag-validate ng checkpoint
04:3002:00SUCCEEDEDNatapos ang job (kasama ang pinakabagong checkpoint)

Kahit 3 oras ang kabuuang ginugol sa pagsasanay, 2 oras lang ang “nakapaloob” sa magagamit na checkpoint at sinisingil. Hindi mo responsibilidad ang oras ng pagsasanay na nawala dahil sa pagkabigo. Ang gastos ay magiging 2 oras × $100/oras = $200.

Mga madalas itanong

Kailan ako sisingilin?

Sisingilin ka namin kapag nakumpleto, na-pause, nakansela, o nabigo ang iyong run. Saklaw ng bawat singil ang gawaing nagawa mula noong nakaraang singil.

Magbabayad ba ako kung mabigo ang isang run?

Kung nabigo ang isang run dahil sa aming error at may nawalang kamakailang training work, hindi ka sisingilin para sa nawalang bahagi. Kung kanselahin mo ang isang run, sisingilin ka para sa gawaing nagawa hanggang sa pagkansela.

Paano sinisingil ang mga token ng grader na modelo?

Binibilang namin ang mga token na ginamit ng anumang grader na modelo na iko-configure mo. Pagkatapos matapos ang pagsasanay, sinisingil namin ang mga token na iyon sa aming karaniwang per-token rates.

Maaari ko bang i-pause at ipagpatuloy ang isang run?

Oo. Kapag nag-pause ka, nagse-save kami ng checkpoint at naniningil para sa gawaing nagawa na hanggang ngayon. Kapag ipinagpatuloy mo, sisingilin ka lang para sa karagdagang gawaing nagawa pagkatapos ipagpatuloy.

Kung mayroon kang iba pang tanong tungkol sa pagsingil sa Reinforcement Fine‑Tuning, makipag-ugnayan sa aming support team.

Nakatulong ba ang artikulong ito?