Кэш AI-изображений в играх: как снизить стоимость до $0.002 за ассет

Статья разбирает практический вопрос: как в играх с пользовательскими комбинациями удержать расходы на генерацию изображений на уровне около $0.002 за игровой ассет, если API берёт $0.005 за завершённое изображение Z-Image. Кэширование не делает дешевле полностью новые изображения, но позволяет не платить повторно за одинаковые или семантически близкие результаты. Основная формула дневных затрат: число крафтов, умноженное на долю платных промахов, умноженное на число завершённых попыток на один принятый ассет, умноженное на цену генерации. Чтобы уложиться в $0.002 при цене $0.005, произведение доли платных промахов и числа завершённых попыток должно быть не больше 0.4. В таблице для трёх тысяч крафтов в день и одной попытки показано: при 100% промахов это 3000 новых генераций в день и $450 за 30 дней, при 40% — 1200 и $180, при 20% — 600 и $90, при 10% — 300 и $45. Если в среднем требуется 1.5 завершённой попытки на принятый ассет, допустимая доля промахов снижается до 26.7%. Центральная рекомендация — кэшировать не сам текст промпта, а смысл. Рецептный ключ описывает ввод игрока. Перед хешированием ID предметов стоит нормализовать, а если порядок не важен, отсортировать, чтобы iron + fire и fire + iron ссылались на одну серверную строку рецепта. В ключ включают версию правил, потому что более поздний балансный патч может изменить результат. Для ключей не советуют slugify: потеря информации способна объединить разные предметы. Семантический ключ ассета описывает то, что игрок в итоге видит. Пример: ember-shield | inventory-icon-v1 | z-image | 1:1 | filtered. Несколько рецептов и переводы могут обозначать один и тот же результат, поэтому они могут переиспользовать один одобренный визуал. Если кэшировать сырой промпт, замена слова фрагментирует кэш, а одинаковый промпт после смены художественного направления устаревает. Вместо этого каждый рецепт связывают со стабильным ID результата, а арт ключуют по ID результата, модели, соотношению сторон, режиму безопасности и версии стиля. Когда нужен новый визуал, поднимают версию. Поток кэш-первого запроса: входящий рецепт превращают в семантический ID результата, затем ищут семантический ключ ассета в постоянном хранилище. При попадании сразу возвращают сохранённый URL. При промахе атомарно вставляют общую строку задачи по семантическому ассету и в той же транзакции резервируют слот из общего дневного бюджета отправок. Другие воркеры при такой же задаче получают уже существующую строку, а не создают дубль. Строку коммитят как submitting и делают один POST, сразу сохраняя ID. Если отправка неопределённая, задачу помечают submit_uncertain и останавливаются. Известный ID опрашивают через GET до завершённого или неудачного состояния, фиксируют терминальный статус и потраченные кредиты. Готовое изображение копируют в своё хранилище и переводят в pending_review; только подтверждение приёмки переводит ассет в ready. Клиенту возвращают плейсхолдер и pending-статус, а фоновый воркер продолжает опрос. Ключ reAPI клиенту не отдают: опрос бесплатный, для клиента достаточно игрового эндпоинта. Авторы упоминают тест из трёх задач: первая отправка завершила три исходных кандидата за 15 кредитов, то есть $0.015, но они ещё не принятые ассеты, поскольку не прошли визуальную проверку. Главный вывод: если даже после кэша 3000 ежедневных изображений действительно новые, кэш не решает экономику; тогда нужно чаще переиспользовать арт, сузить поверхность генерации или закладывать более высокие расходы.