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_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 poświęconych na walidację zbioru danych |
| 00 : 30 | 00 : 00 | VALIDATING_FILES | 20 minut wykonywania kontroli bezpieczeństwa zbioru danych |
| 01 : 00 | 00 : 00 | QUEUED | 30 minut oczekiwania na dostępny proces roboczy |
| 01 : 30 | 00 : 00 | RUNNING | 30 minut przygotowywania treningu (pobieranie wag, wstępne przetwarzanie itp.) |
| 05 : 30 | 04 : 00 | RUNNING | 4 godziny poświęcone na trening |
| 06 : 00 | 04 : 00 | RUNNING | 30 minut wykonywania ocen bezpieczeństwa powstałego modelu |
| 06 : 00 | 04 : 00 | SUCCEEDED | Trening 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 treningu | Czas rozliczany | Status | Opis |
| 00 : 00 | 00 : 00 | – | Użytkownik tworzy zadanie RFT przez API |
| 00 : 10 | 00 : 00 | VALIDATING_FILES | 10 minut poświęconych na walidację zbioru danych |
| 00 : 30 | 00 : 00 | VALIDATING_FILES | 20 minut wykonywania kontroli bezpieczeństwa zbioru danych |
| 01 : 00 | 00 : 00 | QUEUED | 30 minut oczekiwania na dostępny proces roboczy |
| 01 : 30 | 00 : 00 | RUNNING | 30 minut przygotowywania treningu (pobieranie wag, wstępne przetwarzanie itp.) |
| 03 : 30 | 02 : 00 | RUNNING | 2 godziny poświęcone na trening |
| 03 : 30 | 02 : 00 | RUNNING | Checkpoint utworzony w kroku 5 |
| 04 : 30 | 02 : 00 | RUNNING | Trening kończy się błędem wewnętrznym w kroku 8 (po kolejnej 1 godzinie) |
| 04 : 30 | 02 : 00 | RUNNING | 30 minut oceny i walidacji checkpointu |
| 04 : 30 | 02 : 00 | SUCCEEDED | Zadanie 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.
