Фіксована ставка, яка не була такою: 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.7 разів може виправдати побудову робочого процесу навколо одного постачальника. Різницю у 34% потрібно зважувати з надійністю, якістю результату та витратами на перехід.

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

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

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

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

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

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