Вартість API розробки ігор з AI

Оцінюйте процес, а не початковий prompt

Сеанс розробки гри може багаторазово читати джерело, пропонувати зміни, тлумачити помилки рушія, перевіряти знімки й повторювати невдалу роботу. Початковий brief — лише один вхід. Почніть бюджет із малого прийнятого етапу, наприклад повного раунду та перезапуску, а не припускайте, що один запит створить результат.

Перелічіть етапи, за які очікуєте платити: реалізація, налагодження, ресурси, локалізація та перевірка. Позначте, що працює локально, а що викликає платний сервіс. Використайте пілот, щоб дізнатися, де накопичується використання, до затвердження більшого бюджету; оцінка має описувати припущення, а не нагадувати виміряний рахунок.

Ведіть окремі журнали для окремих ресурсів

Використовуйте різні категорії для викликів текстової моделі, генерації зображень, аудіосервісів, локальної роботи рушія та людського втручання. Локальна компіляція сама по собі не витрачає токени моделі, але надсилання її логу агенту може створити новий запит. Один асистент може координувати всі ці дії, не роблячи їхні одиниці оплати однаковими.

Тримайте активність підписки окремо від використання API. Якщо для внутрішнього бюджету розподіляєте частину підписки на проєкт, позначте це як правило розподілу, а не як спостережувану плату за запит. Так само не вважайте витрати API завдання розробки витратами кожного майбутнього гравця офлайн-гри.

Зберігайте записи запитів до агрегації

Призначте кожній операції ідентифікатор запуску та етап. Зберігайте ідентифікатори запитів провайдера, якщо вони доступні, фактичну ідентичність моделі, результат, використання та посилання на доказ оплати. Стерилізуйте облікові дані до експорту логів. Ілюстративний запис нижче навмисно залишає неспостережувані значення як null.

Не виводьте успішний запит із прийнятого локального файла або нульову оплату з timeout. Частина використання може надійти після втрати клієнтом з’єднання. Узгодьте запис провайдера до завершення підсумку та залишайте невідповідні записи видимими. Так повторні експерименти будуть порівнюваними без перетворення прогалин телеметрії на уявну економію.

{
  "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
}

Застосовуйте фактичний ціновий контракт провайдера

Використовуйте провайдера й рівень сервісу, що обробили запит, із тарифним графіком для відповідного запису оплати. Офіційні ціни OpenAI описують категорії токенів та інструментів; ціни APIsRouter є окремим комерційним джерелом. Не можна мовчки замінювати один контракт іншим.

Для оцінки помножте кожну платну категорію на відповідний тариф і додайте окремі платежі сервісу. Перевірте, як провайдер звітує про кешований вхід, вихід і використання інструментів, щоб не рахувати категорії двічі. Явно вкажіть валюту й припущення конвертації. Для фактичних витрат віддавайте перевагу остаточному платежу провайдера, а оцінку зберігайте окремо для пояснення різниці.

Встановіть умови зупинки навколо циклів виправлення

Задайте стелю бюджету й контрольну точку після кожного прийнятого етапу. Обмежте автоматичні повтори та визначте симптом, який запускає людську діагностику, наприклад повторні зміни, що не змінюють відтворення. Контроль витрат провайдера й ліміт завдання агента захищають різні межі; використовуйте обидва, якщо вони доступні, і перевірте їхню поведінку.

Зменшуйте зайвий контекст, надсилаючи потрібну сцену, змінені файли та першу змістовну помилку. Зберігайте достатньо стану, щоб не повторювати невдалі підходи. Не вилучайте важливі докази лише для скорочення входу: дешевший запит, що породжує ще одне виправлення навмання, може збільшити вартість прийнятого результату.

Порівнюйте моделі на одному шляху прийняття

Зберігайте сталими brief, базовий стан проєкту, ціль і критерії прийняття. Записуйте невдалі спроби та людську допомогу для кожної моделі. Порівнюйте загальні узгоджені витрати й прийняту поведінку, а не лише ціну токенів або уявну якість першої відповіді.

Призначайте різні категорії завдань лише після пілота, який підтвердив потрібний стандарт. Просте оброблення рядків, складна діагностика gameplay і візуальна перевірка можуть мати різні потреби. Потужніша модель може скоротити ітерації, але це лише гіпотеза, доки її не підтвердить запис тієї самої задачі. Уникайте рухомого списку рекомендованих моделей, який застаріває або натякає на неперевірену доступність.

Відокремте виробництво гри від економіки під час виконання

Експортована офлайн-гра після розробки може використовувати звичайну детерміновану логіку. Якщо додаєте діалоги, згенеровані моделлю наживо, або інші функції під час виконання, створіть окремий бюджет для поведінки гравців, відмов сервісу, контролю зловживань і постійної експлуатації. Зберігайте секрети за відповідною межею сервісу, а не вбудовуйте ключ провайдера в клієнт гри.

Не оцінюйте бюджет під час виконання множенням токенів розробки на продажі. Виміряйте реальний шаблон запитів функції в авторизованому тесті й перевірте вимоги платформи. Ресурси зображень, згенеровані один раз під час виробництва, та зображення, що генеруються для гравців під час виконання, належать до різних моделей вартості.

Докази та випадок Astra

Ідентичність моделі прототипу гри залишається неперевіреною, доки не буде додано явні докази Astra. До застосування будь-якого тарифу підтвердьте фактичного провайдера, режим доступу та ідентичність моделі. Використовуйте запис оплати провайдера, а не виводьте витрати з моделі, названої в brief розробки.

На цій сторінці немає виміряного бюджету гри. Її журнал і кроки бюджетування — метод отримати такий результат. Корисний фінальний звіт указав би прийнятий етап, ідентичність артефакту, фактичні витрати API, окремі платежі за ресурси, людську роботу та невирішені записи оплати, щоб читачі могли оцінити, чого досягли витрати.

Поширені запитання