Фіксована ставка, яка не була такою: 0.134 заявлено, 4.75 нараховано

План був звичайним: згенерувати восьмисекундний кадр за референтним зображенням у нативній роздільній здатності 1080p через провайдера, який рекламував одну з найкращих цін за секунду для цієї моделі. Оголошена ціна становила $0.134 за секунду, однакова для режимів text-to-video, image-to-video та reference-to-video. Вісім секунд - отже, трохи більше долара. Непогано.

Запуск коштував $4.75. Це $0.594 за секунду, або у 4.4 разів більше за заявлену вартість.

Що означало «незмінне»

Тариф був незмінним для всіх режимів генерації - текст у відео, зображення у відео, референс у відео - що і було заявлено в реченні. Він не був незмінним для роздільної здатності, і нативне 1080p взагалі не враховувалося. Ключовим було слово «нативне»: дешевший шлях передбачає рендеринг у 720p з подальшим апскейлом, що має іншу ціну та вигляд. На кадрах із дрібним текстом або тонкими межами апскейл-версія настільки сильно розмиває синтетичний шрифт, що стає непридатною, тому дорожчий шлях не є опціональним.

Тут не було нічого прихованого. Інформація була на сторінці моделі. Вона просто не була на тій сторінці, де вказано число, а саме це число всі цитують.

Порівняння, що зламало систему

Заявлені 0.134$ змусили цього провайдера виглядати приблизно в 6.7 разів дешевше за конкурента, який пропонує 0.90$ за секунду у 1080p. За фактичними показниками він приблизно на 34% дешевше - все одно вигідніша пропозиція на цьому рівні, але це зовсім інше рішення. Різниця у 6.7x може виправдати перебудову робочого процесу під одного постачальника. Різницю у 34% потрібно зважувати з надійністю, якістю результату та витратами на перехід.

Ви не можете перевірити це зсередини власного скрипту

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

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

Що це означає для вашого бюджету

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

Що ми робимо зараз

• Встановіть ціну для рівня, який ви випускаєте. Не для моделі та не для заголовка - а для точної роздільної здатності та режиму, оскільки саме там криються обмеження.
• Перевірте один платний запуск кожного провайдера, перш ніж планувати бюджет на основі їхніх тарифів. Одного рахунку достатньо, щоб виявити розрив у 4.4 раза.
• Позначайте кожне неузгоджене число як опубліковане, а не виміряне. У наших власних нотатках це розрізнення вказано в кожному рядку, і цей сайт робить так само.
• Припускайте, що API не зможе повідомити вам, скільки було витрачено, поки ви не побачите це на власні очі.

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