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: 2 hours ago

Jak działa rozliczanie RFT

Reinforcement Fine‑Tuning (RFT) pozwala optymalizować wydajność modeli rozumujących OpenAI za pomocą uczenia przez wzmacnianie. W przeciwieństwie do naszych ofert dostrajania nadzorowanego lub opartego na preferencjach, które są rozliczane według liczby tokenów w zbiorze treningowym, RFT jest rozliczane na podstawie czasu, jaki przebieg treningowy poświęca na wykonywanie podstawowej pracy 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 godzinę czasu zegarowego spędzonego w podstawowej pętli treningowej dla o4-mini-2025-04-16. Opłaty są naliczane proporcjonalnie do sekundy i zaokrąglane na fakturze do dwóch miejsc po przecinku (np. 2,55 godziny).

  • Użycie modeli oceniających: jeśli podczas treningu używasz modelu OpenAI do „oceniania” odpowiedzi, tokeny zużyte przez te wywołania oceniające są rozliczane osobno według naszych standardowych stawek API po zakończeniu treningu.

Opłaty naliczamy tylko za pracę treningową, która rzeczywiście aktualizuje model (to, co nazywamy „zachowanym 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 o nazwie usage_metrics, które dokumentuje całkowite użycie zadania do bieżącego kroku. Obejmuje to czas poświęcony na trening oraz wszystkie tokeny użyte przez wszystkie gradery modelowe 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 treningu

Ponieważ rozliczenie jest oparte na czasie, wybory konfiguracji bezpośrednio wpływają na koszt. Kluczowe czynniki obejmują:

  • Trudność problemu: jeśli zbiór danych składa się z trudnych problemów, model prawdopodobnie będzie poświęcał więcej czasu na rozumowanie nad każdym problemem, co wydłuża czas potrzebny do wygenerowania każdej próbki.

  • Intensywność obliczeń: hiperparametr compute_multiplier kontroluje, ile obliczeń wykonujesz na krok treningowy. Wyższe wartości zachęcają model do bardziej rozbudowanego rozumowania nad każdym punktem danych, co spowalnia każdy krok.

  • Ustawienia walidacji:

    • Większy zbiór walidacyjny zwiększa czas poświęcany na ocenę.

    • Zwiększenie eval_samples (liczby odpowiedzi modelu ocenianych dla każdego przykładu walidacyjnego) wydłuża czas walidacji.

    • Częstsze uruchamianie walidacji (niższe eval_interval) zwiększa udział czasu poświęcanego na walidację.

  • Wydajność oceniających:

    • Większe lub bardziej zaawansowane modele oceniające potrzebują więcej czasu na zwrócenie oceny niż mniejsze. Na przykład ocenianie za pomocą modelu rozumującego może trwać 10 razy dłużej niż ocenianie modelem nierozumującym.

    • Złożone funkcje oceniające w Pythonie działają dłużej niż proste.

Te ustawienia pozwalają równoważyć koszt, szybkość i jakość modelu. Na przykład częsta walidacja może wcześniej wykrywać problemy, ale zwiększa koszt. Ocenianie bardziej zaawansowanym modelem może radykalnie poprawić dokładność ocen, ale spowolni każdy krok oceniania i podniesie koszt zadań.

Zarządzanie kosztami

Aby kontrolować wydatki:

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

  • Używaj rozsądnej liczby przykładów walidacyjnych i eval_samples. Unikaj częstszej walidacji, niż potrzebujesz.

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

  • Zadbaj o wydajność niestandardowych oceniających w Pythonie.

  • Dostosuj compute_multiplier, aby zrównoważyć szybkość zbieżności i koszt.

  • Monitoruj przebieg w panelu lub przez API. W dowolnym momencie możesz go 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?

Wystawiamy rachunek, gdy przebieg zostanie ukończony, wstrzymany, anulowany lub zakończy się niepowodzeniem. Każdy rachunek obejmuje pracę wykonaną od poprzedniego rachunku.

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?