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_multiplierkontroluje, 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 treningu | Czas rozliczany | Status | Opis |
|---|---|---|---|
| 00:00 | 00:00 | – | Użytkownik tworzy zadanie RFT przez API |
| 00:10 | 00:00 | VALIDATING_FILES | 10 minut na walidację zbioru danych |
| 00:30 | 00:00 | VALIDATING_FILES | 20 minut na kontrole bezpieczeństwa zbioru danych |
| 01:00 | 00:00 | QUEUED | 30 minut oczekiwania na dostępnego workera |
| 01:30 | 00:00 | RUNNING | 30 minut na konfigurację treningu (pobieranie wag, przetwarzanie wstępne itp.) |
| 05:30 | 04:00 | RUNNING | 4 godziny poświęcone na trening |
| 06:00 | 04:00 | RUNNING | 30 minut na oceny bezpieczeństwa wynikowego modelu |
| 06:00 | 04:00 | SUCCEEDED | Trening 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 treningu | Czas rozliczany | Status | Opis |
|---|---|---|---|
| 00:00 | 00:00 | – | Użytkownik tworzy zadanie RFT przez API |
| 00:10 | 00:00 | VALIDATING_FILES | 10 minut na walidację zbioru danych |
| 00:30 | 00:00 | VALIDATING_FILES | 20 minut na kontrole bezpieczeństwa zbioru danych |
| 01:00 | 00:00 | QUEUED | 30 minut oczekiwania na dostępnego workera |
| 01:30 | 00:00 | RUNNING | 30 minut na konfigurację treningu (pobieranie wag, przetwarzanie wstępne itp.) |
| 03:30 | 02:00 | RUNNING | 2 godziny poświęcone na trening |
| 03:30 | 02:00 | RUNNING | Punkt kontrolny utworzony w kroku 5 |
| 04:30 | 02:00 | RUNNING | Trening kończy się niepowodzeniem z powodu błędu wewnętrznego w kroku 8 (po 1 kolejnej godzinie) |
| 04:30 | 02:00 | RUNNING | 30 minut na ocenę i walidację punktu kontrolnego |
| 04:30 | 02:00 | SUCCEEDED | Zadanie 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.
