Ми витратили $303 030 на ШІ за 29 днів. Ось що насправді визначило суму рахунку

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

За 29 днів ми витратили на ШІ $303 030,95. І ціна моделі за токен виявилася чи не найменш цікавою частиною цієї суми.

Ми у великому масштабі перетворювали неструктуровані вихідні дані на чисті класифіковані записи — у такій роботі перестаєш рахувати рядки й починаєш рахувати трильйони токенів. Коли надійшов остаточний рахунок, понад 90% суми припадало на мовні моделі. Functions, Postgres, сховище, журнали — усе це разом дало лише похибку округлення.

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

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

Починайте з дешевого — і вимикайте режим міркування

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

Нашою робочою конячкою стала GPT-5 Nano: основний шлях узагальнення, низька деталізація, жорстке обмеження відповіді та вимкнене міркування. Останнє було свідомим рішенням. Міркування допомагає у складних крайових випадках, але на таких обсягах воно множить витрати: додає приховану роботу, збільшує затримку й робить токени дорожчими. Ми перетворили його на експериментальне налаштування, а не на стандарт. Увімкнули лише там, де цього вимагала якість; основний потік працював без нього.

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

Рахунок складався з трьох категорій, а не з однієї

Загальна кількість токенів — заспокійливе, але марне число. За наш прогін нарахували близько 4,87 трлн токенів моделі, однак ця одна цифра приховує, куди пішли гроші. Розділіть їх так, як у рахунку: на новий ввід, кешований ввід і вивід — і картина перевертається:

Новий ввід: 953,6 млрд токенів, $176 708. Кешований ввід: 3,749 трлн токенів, $18 856. Вивід: 164,4 млрд токенів, $80 044.

Тепер подивіться на дисбаланс. Кешований ввід становив 77% усіх наших токенів, але менш як 7% вартості. Вивід — лише 3,4% токенів, зате 29% витрат. Дешеві токени домінують за обсягом, а дорогі ховаються у вузькому сегменті. Якщо відстежувати одну усереднену кількість токенів, ви працюєте наосліп. Потрібні щонайменше ці три категорії, адже кожна має власну ціну й потребує окремого способу оптимізації.

Гроші з’їдає хвіст ескалацій

Далі — розподіл за моделями, і саме він виявився найболючішим. Nano обробила майже весь корпус: 4,81 трлн токенів за $129 880. Більша модель (у нашому розгортанні Azure вона тарифікувалася як GPT-5.4) узяла лише складний хвіст: 55 млрд токенів, тобто трохи більше 1% обсягу, за $145 724.

Прочитайте ще раз. Один відсоток токенів. Понад половина витрат на моделі. У середньому один токен GPT-5.4 коштував приблизно у 98 разів дорожче, ніж у Nano, зокрема тому, що Nano так активно використовувала дешевий кешований ввід. Крихітна частка ескалованого трафіку непомітно заволоділа рахунком.

І сам масштаб — окремий урок. 4,87 трлн токенів за два активні тижні — це близько 348 млрд токенів на день, або приблизно 4 млн токенів щосекунди в усьому кластері. На цьому рівні ви вже не налаштовуєте функцію, а керуєте промисловим процесом, де одновідсоткове рішення з маршрутизації перетворюється на шестизначну статтю витрат. На такому рівні вартість ШІ — це архітектура.

Більші моделі — інструмент ескалації, а не вибір за замовчуванням

Результати оцінювання не залишили простору для суперечок з економікою. В одному оцінюванні на рівні записів GPT-5 Nano набрала 85,40 бала зі 100 за приблизно $0,00006377 на запис; більша модель — 91,92 бала за близько $0,00252326. Шість додаткових балів якості приблизно за сорокакратну ціну кожного запису.

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

Одиниця зберігання — не одиниця міркування

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

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

Кожен символ може перетворитися на витрати на токени

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

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

Найгіршими порушниками в наших даних були ідентифікатори. Записи мали ключі GUID, наприклад b1386248-975a-464c-91e5-06f1f6415cd4. Такий GUID розбивається приблизно на 20 токенів, тож список із тисячі рядків витрачає близько 20 000 токенів лише на ідентифікатори — ще до першого корисного слова. Рішення примітивне й ефективне: не надсилати їх. Замість внутрішніх ID ми покладалися на порядок у джерелі, а для таксономії дозволили моделі повертати компактні коди на кшталт ’f:.91′ або ’3v:.88′, які застосунок зіставляв із повними слагами на кшталт ’sport’ чи ’track_and_field’. Це скоротило і ввід, і вивід, а також зменшило відхилення формату, бо модель мала менше довгих міток, у яких можна помилитися.

Кешування змінило те, як ми пишемо промпти

Якщо цей проєкт урятував один механізм, то це кешування промптів. І воно перевернуло звичну логіку.

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

Так ми отримали великий повторюваний префікс, який Azure могла кешувати. Це не було теорією. У тестах, наближених до продакшену, один запит використав кеш для 213 504 із 335 164 вхідних токенів; інший — для 324 864 із 381 742. У нашому тарифі новий ввід коштував $0,05 за мільйон токенів, а кешований — $0,005, тобто вдесятеро дешевше. (Тарифи Azure залежать від моделі, регіону й зони даних, тому сприймайте ці цифри як наші, а не як універсальну таблицю.)

За весь прогін 3,749 трлн наших вхідних токенів тарифікувалися як кешовані. Ми заплатили за них $18 856. За тарифами нового вводу для тієї самої моделі й набору зон ці токени коштували б близько $188 556. Кешування дозволило уникнути приблизно $169 700 витрат на моделі. Один механізм.

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

Вихідні токени не кешуються, тож перетворіть відповідь на протокол

Кешування врятувало вхідну частину. Для виводу такої знижки немає: кожен вихідний токен щоразу тарифікується повністю. Нагадаю: вивід становив лише 3% наших токенів, але 29% вартості моделей. Це останнє місце, де варто допускати марнотратство.

Модель має видавати протокол, а не красиву схему. Перша спокуса — чистий JSON, бо він зручний для застосунку: { «topic»: «sport», «subtopic»: «track_and_field» }. Але лапки, фігурні дужки й довгі назви полів — це вихідні токени, за які ви платите в кожному рядку. Нехай модель натомість видає два короткі рядки, T=f і S=track, а легенда (’T’ означає тему, ’f’ - код для sport) один раз живе в кешованому системному промпті. Так дешевше, та й довгих міток, у яких модель може помилитися, стає менше.

Одне застереження, засвоєне важким шляхом: мета — не найкоротший формат, а найменший надійний. Надто хитрий формат, що ламається у крайовому випадку (CSV дешевий, доки випадкова кома не зсуне всі стовпці), спричиняє помилку розбору. А помилка розбору — це ще один оплачуваний виклик для виправлення. Проєктування формату — це FinOps.

Повторна спроба — це рішення про витрати

У такому масштабі політика повторних спроб є політикою витрат. Конвеєр обережно повторює запити після обмеження частоти, враховує рекомендований час очікування й перемикається між ресурсами Azure Foundry, а не просто сидить і чекає. Але він не повторює бездумно все підряд. Некоректне форматування, порожні відповіді, відмови з боку моделі та помилки, не пов’язані з обмеженням частоти, фіксуються, а не виправляються ще одним платним викликом. У разі спрацювання фільтра вмісту виконується рівно одне обережне переформулювання, після чого процес зупиняється. Саме так один складний запис не перетворюється на нескінченну серію оплачуваних запитів.

Ми прорахували альтернативи: дешевший API та власні GPU

Очевидна реакція на такий рахунок — ’ми обрали не ту платформу’. Тому ми виконали реальні розрахунки на наших фактичних обсягах: 4,7 трлн вхідних токенів, 164 млрд вихідних, загалом 4,87 трлн приблизно за два активні тижні. Три реальні варіанти з реальними цифрами з опублікованих тарифів Together.

Варіант 1: дешевший API. Найдешевша достатньо потужна мала модель Together, gpt-oss-20B, коштує $0,05 за мільйон вхідних і $0,20 за мільйон вихідних токенів. Ввід: 4,7 трлн x $0,05 = $235 131. Вивід: 164 млрд x $0,20 = $32 888. Разом: близько $268 000. Через пакетний режим Together — приблизно вдвічі менше, близько $134 000. Це той самий порядок величини, що й наш рахунок Azure, і причина неприємна: малі моделі Together не мають знижки за кешування, тож ми платили б повну ціну за всі 4,7 трлн вхідних токенів — саме ті, які Azure тарифікувала удесятеро дешевше. Час тут не проблема: провайдер керує парком, тому фактичне виконання так само триває дні, як і наш прогін, і нам нічим не потрібно керувати.

Варіант 2: орендувати H100 і самостійно запустити модель 8B. Кластер H100 у Together коштує від $3,09 за зарезервовану до $3,99 за орендовану на вимогу GPU-годину. Припустімо, що модель 8B у пакетному режимі стабільно обробляє близько 15 000 токенів за секунду на одній H100. Тоді 4,87 трлн токенів — це приблизно 90 000 GPU-годин. Обчислення: від $278 000 до $360 000. Час на одній H100: близько 90 000 годин, або 10 років. Щоб вкластися в наші два тижні, потрібно близько 270 H100, які безперервно працюють паралельно; в один тиждень — приблизно 540. Загальна сума майже не залежить від кількості GPU, адже це ті самі 90 000 GPU-годин. Насправді ви купуєте здатність без затримок розгорнути й повністю завантажити кілька сотень H100.

Варіант 3: дешевші споживчі відеокарти. RunPod пропонує RTX 4090 приблизно за $0,69 на годину — це частка вартості H100. Але 4090 обробляє значно менше токенів за секунду; за швидкості близько 5 000 токенів для тієї самої роботи знадобиться приблизно 270 000 GPU-годин. Обчислення: близько $187 000. Час на одній карті: приблизно 31 рік. Щоб завершити роботу за два тижні, потрібно близько 800 карт. Низьку погодинну ціну з’їдає потреба у вп’ятеро більшій кількості годин і плануванні роботи восьмисот карт.

Поставте варіанти поруч. API коштує приблизно від $134 000 до $268 000. Власні H100 — від $280 000 до $360 000 плюс кластер із 270 GPU, за яким треба наглядати. Дешеві карти — близько $187 000 плюс 800 пристроїв. Кожен шлях відступу приводить приблизно до тієї самої суми, яку ми вже заплатили, але додає роботу з надійністю, моніторингом та оцінюванням, яку керований API виконував без додаткової плати. Платформа — не головний важіль. Одне лише кешування, єдине архітектурне рішення, зменшило цей рахунок приблизно на $169 700 — більше, ніж заощадила б будь-яка зміна провайдера з наведених варіантів.

Порядок дій — саме в такій послідовності

• За замовчуванням використовуйте найменшу модель із вимкненим режимом міркування.
• Ескалуйте лише невдалі випадки й стежте за часткою ескалацій. Це ваш найпотужніший важіль.
• Відфільтровуйте сміттєві рядки кодом до виклику моделі. Найдешевший токен — той, якого ви не надсилали.
• Кешуйте повторюваний префікс. Переносьте стабільні правила в системний промпт, щоб кешовані читання тарифікувалися вдесятеро дешевше.
• Скорочуйте корисне навантаження. Використовуйте порядок у джерелі або короткі коди замість GUID, відмовтеся від красивого форматування та довгих назв полів.
• Обмежуйте та формуйте вивід. На Nano він коштує приблизно у вісім разів дорожче за ввід і ніколи не кешується.
• Обробляйте пакетно все, що не потребує роботи в реальному часі, — приблизно за половину ціни. Ми вже почали переводити важку модель у цей режим.
• Перш ніж мігрувати, прорахуйте дешевшого провайдера або власні GPU. На наших обсягах обидва варіанти вийшли приблизно на ту саму суму, що й рахунок. Архітектура змінює цифру набагато сильніше за платформу.
• Зробіть повторні спроби свідомими. Повторюйте запити після обмеження частоти, а не помилки, за повторення яких ви просто заплатите знову.
• Вимірюйте вартість прийнятого результату, а не токена. Цей показник враховує повторні спроби, виклики для виправлення та ескалації, які приховує ціна за токен.

Головний висновок

На таких обсягах вартість ШІ — це архітектура. Не гасло. Стаття бюджету.

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

Тому ми провели очевидну перевірку здорового глузду: чи справді ми обрали правильну платформу? Для кожного шляху відступу взяли ті самі 4,87 трлн токенів за ті самі два тижні. Підсумок:

→ Azure із кешуванням (фактично сплачено): $275 608 · 91% усього рахунку → Найдешевша заміна API (Together gpt-oss-20B): $268 000 ($134 000 у пакетному режимі) · кешування немає, тому повна ціна за всі 4,7 трлн вхідних токенів → Оренда власних H100: близько $280 000-360 000 за обчислення · плюс 270 GPU паралельно протягом двох тижнів (одна карта: понад 10 років) → Дешеві споживчі карти: близько $187 000 · лише якщо знайдете 800 карт і зможете за ними наглядати

Прочитайте це двічі, бо в цьому вся суть. Кожна альтернатива приводить приблизно до тієї самої суми, яку ми вже заплатили, і кожна додає вам другу роботу: надійність, моніторинг, відмовостійкість, оцінювання та підтримку кластера, що обробляє 4 млн токенів за секунду. Azure вже включала все це, а також єдиний важіль, що справді змінив цифру: кешування, яке непомітно заощадило близько $169 700. Жодна зміна провайдера в цьому списку не дала б такої економії.

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

І ось що варто запам’ятати: такий рахунок не просто трапляється — ви його проєктуєте. Одне лише кешування визначило різницю між $276 000 і $445 000. Маршрутизація втримала дорогу модель на 1% трафіку замість усіх 100%. Ті самі моделі, ті самі ціни, ті самі токени. Система, яку ви будуєте навколо моделі, і є вашим рахунком.

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