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: 19 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 proces roboczy treningu aktywnie trenuje model, a konkretnie za:

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

  • Ocenianie tych wyników za pomocą co najmniej jednego oceniającego, którego zdefiniowano dla zadania (dowiedz się więcej o oceniających)

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

  • Uruchamianie wszystkich skonfigurowanych kroków walidacji (ewaluacji).

Uruchamianie większości oceniających jest „bezpłatne”, co oznacza, że nie naliczamy dodatkowej opłaty za ich użycie poza czasem, który wnoszą do podstawowej pętli treningowej. Wyjątkiem są modele oceniające, dla których zliczamy także tokeny zużyte przez te modele podczas powyższych działań. Te tokeny pojawiają się jako osobna pozycja na fakturze. Tokeny zużyte przez modele oceniające są rozliczane według standardowych stawek inferencyjnych (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.

Śledzenie 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 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 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 poświęconych na walidację zbioru danych
00 : 3000 : 00VALIDATING_FILES20 minut wykonywania kontroli bezpieczeństwa zbioru danych
01 : 0000 : 00QUEUED30 minut oczekiwania na dostępny proces roboczy
01 : 3000 : 00RUNNING30 minut przygotowywania treningu (pobieranie wag, wstępne przetwarzanie itp.)
05 : 3004 : 00RUNNING4 godziny poświęcone na trening
06 : 0004 : 00RUNNING30 minut wykonywania ocen bezpieczeństwa powstałego modelu
06 : 0004 : 00SUCCEEDEDTrening się kończy

W tym przypadku łączny 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 checkpoint, trenuje jeszcze 1 godzinę, ale potem kończy się niepowodzeniem. Rozliczane są tylko 2 godziny treningu do checkpointu.

Czas treninguCzas rozliczanyStatusOpis
00 : 0000 : 00Użytkownik tworzy zadanie RFT przez API
00 : 1000 : 00VALIDATING_FILES10 minut poświęconych na walidację zbioru danych
00 : 3000 : 00VALIDATING_FILES20 minut wykonywania kontroli bezpieczeństwa zbioru danych
01 : 0000 : 00QUEUED30 minut oczekiwania na dostępny proces roboczy
01 : 3000 : 00RUNNING30 minut przygotowywania treningu (pobieranie wag, wstępne przetwarzanie itp.)
03 : 3002 : 00RUNNING2 godziny poświęcone na trening
03 : 3002 : 00RUNNINGCheckpoint utworzony w kroku 5
04 : 3002 : 00RUNNINGTrening kończy się błędem wewnętrznym w kroku 8 (po kolejnej 1 godzinie)
04 : 3002 : 00RUNNING30 minut oceny i walidacji checkpointu
04 : 3002 : 00SUCCEEDEDZadanie się kończy (z najnowszym checkpointem)

Mimo że łącznie na trening poświęcono 3 godziny, rozliczane są tylko 2 godziny „zachowane” w użytecznym checkpoincie. Godzina pracy treningowej utracona z powodu błędu nie jest Twoją odpowiedzialnością. Koszt wyniósłby 2 godziny × 100 USD/godz. = 200 USD.

Często zadawane pytania

Kiedy naliczana jest opłata?

Rozliczamy przebieg po jego zakończeniu, wstrzymaniu, anulowaniu lub niepowodzeniu. Każda opłata obejmuje pracę wykonaną od poprzedniego rozliczenia.

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

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

Jak rozliczane są tokeny modeli oceniających?

Zliczamy tokeny używane przez wszystkie skonfigurowane modele oceniające. Po zakończeniu treningu rozliczamy te tokeny według naszych standardowych stawek za token.

Czy mogę wstrzymać i wznowić przebieg?

Tak. Po wstrzymaniu zapisujemy checkpoint i naliczamy opłatę za dotychczas wykonaną pracę. Po wznowieniu opłata zostanie naliczona tylko za dodatkową pracę wykonaną po wznowieniu.

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

Czy ten artykuł był pomocny?