OpenAI
Ta strona została przetłumaczona maszynowo. Wyświetl oryginalny artykuł w języku angielskim.

Przewodnik po rozliczaniu API Reinforcement Fine-Tuning

Jak działa rozliczanie API RFT

Zaktualizowano: 12 days ago

Jak działa rozliczanie RFT

Reinforcement Fine‑Tuning (RFT) pozwala optymalizować wydajność modeli rozumujących OpenAI z użyciem uczenia przez wzmacnianie. W odróżnieniu od naszych ofert fine‑tuningu nadzorowanego lub preferencyjnego, rozliczanych według liczby tokenów w zbiorze treningowym, RFT jest rozliczane na podstawie czasu, jaki przebieg treningowy poświęca na wykonywanie kluczowych prac z zakresu uczenia maszynowego.

Ten przewodnik wyjaśnia, co liczy się jako rozliczany czas treningu, jak obsługujemy wstrzymania i anulowania oraz jak wybory konfiguracji mogą wpływać na koszt.

Cennik

  • Obliczenia: 100 USD za każdą godzinę czasu rzeczywistego poświęconą na główną pętlę trenowania modelu o4-mini-2025-04-16. Opłaty są naliczane proporcjonalnie co do sekundy, a na fakturze zaokrąglane do dwóch miejsc po przecinku (np. 2,55 godziny).

  • Wykorzystanie modelu oceniającego: jeśli model OpenAI służy do "oceniania" wyników podczas trenowania, tokeny wykorzystane przez te wywołania są po zakończeniu trenowania rozliczane oddzielnie według standardowych stawek API.

Naliczamy opłaty tylko za pracę związaną z trenowaniem, która faktycznie aktualizuje model (nazywamy ją "zarejestrowanym postępem").

Za co naliczamy opłaty

Naliczamy opłaty za czas, w którym worker treningowy aktywnie trenuje Twój model, w szczególności za:

  • Generowanie próbek z Twojego modelu podczas procesu dostrajania (tzw. „rollouty”)

  • Ocenianie tych wyników za pomocą jednego lub większej liczby graderów zdefiniowanych w zadaniu (dowiedz się więcej o graderach)

  • Obliczanie i stosowanie aktualizacji wag na podstawie ocen (propagacja wsteczna).

  • Wykonywanie skonfigurowanych przez Ciebie kroków walidacji (oceny).

Uruchamianie większości graderów jest „bezpłatne”, co oznacza, że nie pobieramy dodatkowej opłaty za ich użycie poza czasem, który wnoszą do głównej pętli treningu. Wyjątkiem są gradery modelowe, w przypadku których zliczamy również tokeny zużywane przez te gradery podczas powyższych działań. Te tokeny pojawiają się na fakturze jako osobna pozycja. Tokeny zużywane przez gradery modelowe są rozliczane według standardowych stawek za inferencję (cennik OpenAI).

Za co NIE naliczamy opłat

Nie naliczamy opłat za czas poświęcony na:

  • Walidację lub sprawdzanie zbioru danych przed rozpoczęciem treningu.

  • Kontrole bezpieczeństwa zbioru danych.

  • Oczekiwanie w kolejce na zasoby obliczeniowe.

  • Pobieranie wag modelu lub zbiorów danych.

  • Przygotowywanie (renderowanie) zbioru danych do naszego formatu treningowego.

  • Oceny bezpieczeństwa po treningu dostrojonego modelu.

Jeśli praca treningowa zostanie utracona z powodu błędu po naszej stronie (na przykład gdy proces roboczy ulegnie awarii i będzie musiał wrócić do wcześniejszego checkpointu), nie naliczymy opłat za utracony czas obliczeń ani tokeny oceniających. Więcej szczegółów znajdziesz w następnej sekcji.

Zachowany postęp i zdarzenia rozliczeniowe

Trening składa się z wielu małych aktualizacji modelu. Śledzimy, ile z tych aktualizacji zakończyło się powodzeniem. Opłaty są oparte na czasie obliczeń i tokenach oceniających powiązanych z tymi udanymi aktualizacjami.

Naliczamy opłatę, gdy wystąpi jedno z następujących „zdarzeń rozliczeniowych”:

  • Trening kończy się pomyślnie.

  • Wstrzymujesz trening.

  • Anulujesz trening.

  • Trening kończy się niepowodzeniem.

Każda opłata obejmuje przyrost pracy wykonanej od poprzedniego rozliczenia. Na przykład:

  • Jeśli wstrzymasz przebieg, zapisujemy checkpoint i naliczamy opłatę za czas obliczeń oraz tokeny oceniających zużyte od poprzedniego rozliczenia.

  • Po wznowieniu trening jest kontynuowany od checkpointu. Następna opłata (przy zakończeniu, kolejnym wstrzymaniu, anulowaniu lub niepowodzeniu) obejmie tylko dodatkową pracę wykonaną po wznowieniu.

  • Jeśli anulujesz przebieg, naliczamy opłatę za pracę wykonaną do momentu anulowania.

  • Jeśli trening zakończy się niepowodzeniem, a praca od poprzedniego rozliczenia zostanie utracona, nie zostaniesz obciążony za utraconą część.

To podejście „zachowanego postępu” gwarantuje, że płacisz tylko za pracę, która zostaje zachowana w modelu lub z której celowo rezygnujesz.

Wyświetlanie postępu zadania

Zadania RFT mają pole usage_metrics, które zawiera łączne wykorzystanie zasobów przez zadanie do bieżącego kroku. Obejmuje ono czas poświęcony na trenowanie oraz wszystkie tokeny użyte przez wszystkie modele oceniające w zadaniu. To pole można sprawdzić przez API (GET /v1/fine_tuning/jobs/{job_id}) lub w panelu dostrajania.

Czynniki wpływające na czas trenowania

Ponieważ opłaty zależą od czasu, wybrana konfiguracja bezpośrednio wpływa na koszt. Najważniejsze czynniki to:

  • Trudność problemów: jeśli zbiór danych zawiera trudne problemy, model prawdopodobnie poświęci więcej czasu na analizę każdego z nich, co wydłuży generowanie poszczególnych próbek.

  • Intensywność obliczeń: hiperparametr compute_multiplier określa ilość obliczeń wykonywanych w każdym kroku trenowania. Wyższe wartości skłaniają model do bardziej szczegółowego rozumowania nad każdym punktem danych, przez co poszczególne kroki trwają dłużej.

  • Ustawienia walidacji:

  • Wydajność modeli oceniających:

  • Większe lub bardziej zaawansowane modele oceniające potrzebują więcej czasu na wystawienie oceny niż mniejsze modele. Na przykład ocenianie za pomocą modelu rozumującego może trwać 10 razy dłużej niż przy użyciu modelu bez funkcji rozumowania.

  • Złożone funkcje oceniające w języku Python działają dłużej niż proste funkcje.

Te ustawienia pozwalają wyważyć koszt, szybkość i jakość modelu. Na przykład częsta walidacja pozwala wcześniej wykrywać problemy, ale zwiększa koszt. Ocenianie za pomocą bardziej zaawansowanego modelu może znacznie zwiększyć trafność ocen, ale spowalnia każdy etap oceniania i podnosi koszt zadań.

Zarządzanie kosztami

Aby kontrolować wydatki:

  • Zacznij od krótszych przebiegów, aby sprawdzić, jak konfiguracja wpływa na czas.

  • Używaj rozsądnej liczby przykładów walidacyjnych i parametru eval_samples. Nie przeprowadzaj walidacji częściej, niż jest to potrzebne.

  • Wybierz najmniejszy model oceniający, który spełnia wymagania jakościowe.

  • Dbaj o wydajność niestandardowych modeli oceniających w języku Python.

  • Dostosuj parametr compute_multiplier, aby wyważyć szybkość zbieżności i koszt.

  • Monitoruj przebieg w panelu lub przez API. Możesz go w każdej chwili wstrzymać lub anulować.

Przykłady

Udany przebieg treningu

Czas treninguCzas rozliczanyStatusOpis
00:0000:00Użytkownik tworzy zadanie RFT przez API
00:1000:00VALIDATING_FILES10 minut na walidację zbioru danych
00:3000:00VALIDATING_FILES20 minut na kontrole bezpieczeństwa zbioru danych
01:0000:00QUEUED30 minut oczekiwania na dostępnego workera
01:3000:00RUNNING30 minut na konfigurację treningu (pobieranie wag, przetwarzanie wstępne itp.)
05:3004:00RUNNING4 godziny poświęcone na trening
06:0004:00RUNNING30 minut na oceny bezpieczeństwa wynikowego modelu
06:0004:00SUCCEEDEDTrening zostaje ukończony

W tym przypadku całkowity czas zegarowy wynosi 6 godzin, ale rozliczane są tylko 4 godziny. Koszt wyniósłby 4 godziny × 100 USD/godz. = 400 USD.

Przykład nieudanego zadania

W tym przykładzie przebieg trenuje przez 2 godziny, zapisuje punkt kontrolny, trenuje przez kolejną godzinę, ale potem kończy się niepowodzeniem. Rozliczane są tylko 2 godziny treningu do punktu kontrolnego.

Czas treninguCzas rozliczanyStatusOpis
00:0000:00Użytkownik tworzy zadanie RFT przez API
00:1000:00VALIDATING_FILES10 minut na walidację zbioru danych
00:3000:00VALIDATING_FILES20 minut na kontrole bezpieczeństwa zbioru danych
01:0000:00QUEUED30 minut oczekiwania na dostępnego workera
01:3000:00RUNNING30 minut na konfigurację treningu (pobieranie wag, przetwarzanie wstępne itp.)
03:3002:00RUNNING2 godziny poświęcone na trening
03:3002:00RUNNINGPunkt kontrolny utworzony w kroku 5
04:3002:00RUNNINGTrening kończy się niepowodzeniem z powodu błędu wewnętrznego w kroku 8 (po 1 kolejnej godzinie)
04:3002:00RUNNING30 minut na ocenę i walidację punktu kontrolnego
04:3002:00SUCCEEDEDZadanie kończy się (z najnowszym punktem kontrolnym)

Chociaż łącznie na trening poświęcono 3 godziny, tylko 2 godziny są „ujęte” w użytecznym punkcie kontrolnym i rozliczane. Nie ponosisz odpowiedzialności za godzinę pracy treningowej utraconą z powodu niepowodzenia. Koszt wyniósłby 2 godziny × 100 USD/godz. = 200 USD.

Często zadawane pytania

Kiedy naliczana jest opłata?

Opłatę naliczamy po zakończeniu, wstrzymaniu, anulowaniu lub niepowodzeniu przebiegu. Każdy rachunek obejmuje pracę wykonaną od czasu wystawienia poprzedniego.

Czy płacę, jeśli przebieg się nie powiedzie?

Jeśli przebieg zakończy się niepowodzeniem z powodu naszego błędu i utracona zostanie część ostatniej pracy treningowej, nie naliczymy opłaty za utraconą część. Jeśli anulujesz przebieg, naliczymy opłatę za pracę wykonaną do momentu anulowania.

Jak rozliczane są tokeny modelu gradera?

Zliczamy tokeny użyte przez skonfigurowane przez Ciebie gradery modelowe. Po zakończeniu treningu rozliczamy te tokeny według naszych standardowych stawek za token.

Czy mogę wstrzymać i wznowić przebieg?

Tak. Gdy wstrzymasz przebieg, zapisujemy punkt kontrolny i naliczamy opłatę za dotychczas wykonaną pracę. Gdy wznowisz przebieg, opłata zostanie naliczona tylko za dodatkową pracę wykonaną po wznowieniu.

Jeśli masz inne pytania dotyczące rozliczeń Reinforcement Fine‑Tuning, skontaktuj się z naszym zespołem pomocy.

Czy ten artykuł był pomocny?