Koszt API tworzenia gier z AI

Szacuj proces, nie początkowy prompt

Sesja tworzenia gry może wielokrotnie czytać źródła, proponować edycje, interpretować błędy silnika, sprawdzać zrzuty i ponawiać nieudane prace. Początkowy brief jest tylko jednym wejściem. Zacznij budżet od małego zaakceptowanego kamienia milowego, takiego jak pełna runda i restart, zamiast zakładać, że jedno żądanie dostarczy produkt.

Wymień etapy, za które spodziewasz się zapłacić: implementację, debugowanie, zasoby, lokalizację i przegląd. Oznacz, które działają lokalnie, a które wywołują usługę rozliczaną. Użyj pilota, aby dowiedzieć się, gdzie kumuluje się użycie, zanim zatwierdzisz większy budżet; szacunek powinien opisywać założenia, a nie przypominać zmierzonej faktury.

Prowadź osobne rejestry dla osobnych zasobów

Używaj osobnych kategorii dla wywołań modelu tekstowego, generowania obrazów, usług audio, lokalnej pracy silnika i interwencji człowieka. Lokalna kompilacja nie zużywa sama z siebie tokenów modelu, lecz wysłanie jej logu agentowi może utworzyć kolejne żądanie. Jeden asystent może koordynować te działania bez ujednolicania ich jednostek rozliczeniowych.

Aktywność subskrypcji trzymaj oddzielnie od użycia API. Jeśli na potrzeby budżetu wewnętrznego przypisujesz część subskrypcji do projektu, oznacz to jako regułę alokacji, a nie zaobserwowaną opłatę za żądanie. Nie licz też wydatku API zadania deweloperskiego jako kosztu ponoszonego przez każdego przyszłego gracza gry offline.

Przechwytuj rejestry żądań przed agregacją

Przypisz identyfikator przebiegu i etap każdej operacji. Zachowaj identyfikatory żądań dostawcy, gdy są ujawniane, rzeczywistą tożsamość modelu, wynik, użycie oraz odwołanie do dowodu rozliczenia. Oczyść dane uwierzytelniające przed eksportem logów. Poniższy przykładowy rekord celowo pozostawia niezaobserwowane wartości jako null.

Nie wnioskuj o udanym żądaniu na podstawie zaakceptowanego lokalnego pliku ani o zerowej opłacie na podstawie timeoutu. Część użycia może nadejść po utracie połączenia przez klienta. Uzgodnij zapis dostawcy przed zamknięciem sumy i zachowaj widoczne niedopasowane wpisy. Dzięki temu powtarzane eksperymenty są porównywalne bez zamieniania luk telemetrii w pozorne oszczędności.

{
  "run_id": "game-pilot",
  "stage": "controller-repair",
  "provider_request_id": null,
  "model_id": null,
  "outcome": "not_started",
  "usage": null,
  "billed_amount": null,
  "currency": null,
  "billing_evidence": null,
  "accepted_artifact_hash": null
}

Stosuj rzeczywisty kontrakt cenowy dostawcy

Użyj dostawcy i poziomu usługi, który obsłużył żądanie, z harmonogramem stawek właściwym dla tego rekordu rozliczeń. Oficjalne ceny OpenAI opisują kategorie tokenów i narzędzi; ceny APIsRouter są osobnym źródłem handlowym. Żadnego z nich nie należy po cichu zastępować drugim.

Przy szacunku pomnóż każdą rozliczaną kategorię przez właściwą stawkę i dodaj opłaty właściwe dla usługi. Sprawdź, jak dostawca raportuje wejście z cache, wyjście i użycie narzędzi, aby nie liczyć kategorii dwa razy. Jawnie określ walutę i założenia przeliczenia. Przy uzgadnianiu faktycznych wydatków preferuj rozliczoną opłatę dostawcy, a szacunek zachowaj osobno, aby wyjaśnić różnicę.

Ustaw warunki zatrzymania wokół pętli napraw

Ustal limit budżetu i punkt kontrolny po każdym zaakceptowanym kamieniu milowym. Ogranicz automatyczne ponowienia i zdecyduj, jaki objaw uruchamia diagnozę człowieka, na przykład kolejne edycje pozostawiające tę samą reprodukcję bez zmian. Kontrola wydatków dostawcy i limit zadania agenta chronią różne granice; używaj obu, gdy są dostępne, i sprawdź ich zachowanie.

Ogranicz zbędny kontekst, wysyłając właściwą scenę, zmienione pliki i pierwszy znaczący błąd. Zachowaj dość stanu, by nie powtarzać nieudanych podejść. Nie usuwaj ważnych dowodów tylko po to, aby skrócić wejście: tańsze żądanie prowadzące do kolejnej naprawy po omacku może zwiększyć koszt zaakceptowanego wyniku.

Porównuj modele na tej samej ścieżce akceptacji

Utrzymaj stałe brief, bazę projektu, cel i kryteria akceptacji. Zapisuj nieudane próby i pomoc człowieka dla każdego modelu. Porównuj całkowity uzgodniony wydatek i zaakceptowane zachowanie, a nie tylko cenę tokenów lub pozorną jakość pierwszej odpowiedzi.

Różne kategorie zadań przypisuj dopiero po pilotażu pokazującym, że spełniają wymagany standard. Proste przetwarzanie tekstów, trudna diagnoza rozgrywki i przegląd wizualny mogą mieć inne potrzeby. Bardziej sprawny model może zmniejszyć liczbę iteracji, ale pozostaje to hipotezą do czasu potwierdzenia przez zapis tego samego zadania. Unikaj zmiennej listy polecanych modeli, która się zestarzeje lub zasugeruje niezweryfikowaną dostępność.

Oddziel produkcję gry od ekonomii runtime

Wyeksportowana gra offline może po developmentcie używać zwykłej deterministycznej logiki. Jeśli dodajesz generowane na żywo dialogi modelu lub inne funkcje runtime, utwórz osobny budżet obejmujący zachowanie graczy, awarie usługi, kontrole nadużyć i dalszą eksploatację. Sekrety trzymaj za odpowiednią granicą usługi, zamiast umieszczać klucz dostawcy w kliencie gry.

Nie szacuj tego budżetu, mnożąc tokeny developmentu przez sprzedaż. Zmierz rzeczywisty wzorzec żądań funkcji w autoryzowanym teście i sprawdź właściwe wymagania platformy. Zasoby obrazowe wygenerowane raz podczas produkcji oraz obrazy generowane dla graczy w runtime należą do różnych modeli kosztowych.

Dowody i przypadek Astra

Tożsamość modelu prototypu gry pozostaje niezweryfikowana do czasu dołączenia jawnych dowodów Astry. Przed przypisaniem stawki do tego przypadku potwierdź rzeczywistego dostawcę, tryb dostępu i tożsamość modelu. Użyj zapisu rozliczeń dostawcy, a nie wyprowadzaj opłaty z modelu nazwanego w briefie developmentu.

Na tej stronie nie ma zmierzonego budżetu gry. Jej rejestr i kroki budżetowania są metodą uzyskania takiego wyniku. Użyteczny raport końcowy podałby zaakceptowany kamień milowy, tożsamość artefaktu, rzeczywiste wydatki API, osobne opłaty za zasoby, pracę człowieka i nierozwiązane wpisy rozliczeń, aby czytelnicy mogli ocenić, co osiągnięto za te wydatki.

Częste pytania