Багато команд при складанні бюджету звикли оцінювати вартість API великих моделей за формулою «ціна за одиницю × кількість викликів», але фактичний рахунок часто виявляється значно вищим за очікування. Я допомагав клієнту порахувати: система обслуговування клієнтів із 100 000 викликів на день за поверхневою ціною за одиницю оцінювалася приблизно в 3000 юанів на місяць, але фактичний рахунок сягнув майже 9000 юанів. Проблема криється в чотирьох деталях тарифікації, які легко пропустити. Нижче я, спираючись на реальний досвід помилок, розберу кожну пастку окремо й надам практичні рішення для оптимізації.
Пастка перша: недооцінка різниці цін між вхідними та вихідними Token
Більшість моделей використовують різні ціни для вхідних і вихідних Token, причому вихідні зазвичай дорожчі. Наприклад, для GPT-4o API вхідні становлять близько 2,5 долара за мільйон Token, а вихідні — близько 10 доларів за мільйон Token, тобто різниця сягає 4 разів. Ціна вихідних у Claude 4 Sonnet також приблизно в 5 разів вища за вхідні. Вітчизняні моделі працюють так само: ціна вихідних у популярних API, таких як Qwen, Doubao, DeepSeek, зазвичай у 2–4 рази перевищує ціну вхідних.
Якщо ваш сценарій — «короткий вхід, довгий вихід», наприклад API для написання текстів ШІ або генерації контенту, фактична вартість буде у 2–3 рази вищою за оцінку за середньою ціною. Ось конкретний приклад: одна контент-команда генерувала маркетингові тексти, у середньому 200 Token на вході та 800 Token на виході. Вони оцінили місячну вартість приблизно в 4000 юанів за «середньою ціною», але фактичний рахунок сягнув 11 000 юанів. Причина в тому, що вихідні Token становили аж 80%, а ціна вихідних у 4 рази вища за вхідні, тож зважена реальна ціна виявилася набагато вищою за використане ними середнє значення.
І навпаки, якщо це сценарій «довгий вхід, короткий вихід», наприклад стиснення документів або RAG-запитання й відповіді, структура витрат буде значно м'якшою. У таких сценаріях вхідні можуть становити понад 90%, а ціна вхідних низька, тож фактичний рахунок часто виявляється навіть нижчим за очікування. Тому перед складанням бюджету спершу з'ясуйте, до якого типу належить ваш бізнес, і не робіть висновків на основі узагальненої «середньої вартості виклику».
Рекомендації щодо оптимізації: у підказці чітко вимагайте лаконічного виводу, наприклад «відповідай не більше ніж 100 словами»; встановлюйте жорстку верхню межу довжини виводу (max_tokens); для структурованих завдань переходьте на режим JSON, щоб зменшити надлишкові описи; для завдань генерації довгих текстів розгляньте виклики частинами, щоб уникнути надто довгого одноразового виводу, який активує дорожчий тариф. Крім того, деякі моделі мають ступінчасту тарифікацію виводу: після певної довжини ціна за одиницю зростає — це також слід враховувати із запасом при складанні бюджету.
Пастка друга: системна підказка щоразу споживає Token
Це найбільш прихований пункт. Багато застосунків додають до кожного виклику фіксований System Prompt, наприклад налаштування ролі, вимоги до формату, фонові знання, довжиною від 500 до 2000 Token. Якщо на день припадає 100 000 викликів, лише системна підказка щодня споживає від 50 мільйонів до 200 мільйонів Token.
За ціною вхідних DeepSeek-V3 близько 0,5 юаня за мільйон Token ця частина коштує від 25 до 100 юанів на день, тобто від 750 до 3000 юанів на місяць. Якщо замінити на дорогу модель типу GPT-4o, той самий обсяг системної підказки може за місяць сягнути десятків тисяч юанів. Ще складніше те, що багато команд на етапі тестування використовують спрощену версію підказки, а після запуску поступово її подовжують, через що витрати непомітно подвоюються.
Рекомендації щодо оптимізації: стисніть фіксовану системну підказку до необхідної довжини, а знання, які можна використовувати повторно, винесіть у зовнішній пошук, а не вкладайте в Prompt; використовуйте механізм кешування API великих моделей — деякі платформи дають знижку на повторювані префікси, наприклад OpenAI Prompt Caching пропонує 50% знижки або навіть більше на вхідні Token, що потрапили в кеш, а в Anthropic є чітка різниця цін між записом і читанням кешу. Робіть так: розміщуйте System Prompt на самому початку й тримайте його стабільним, щоб максимізувати влучання в кеш. У наших тестах розумне використання кешу дозволило знизити витрати на системну підказку до менш ніж 30% від початкових.
Пастка третя: повторні спроби та тайм-аути спричиняють подвійну тарифікацію
Мережеві збої, повільна відповідь моделі, перевищення ліміту паралельності — усе це викликає повторні спроби. Ключове в тому, що багато API після тайм-ауту все одно тарифікують Token, якщо модель уже згенерувала частину контенту. У системі з 5% тайм-аутів між фактичними ефективними викликами й тарифікованими викликами виникає розбіжність у 5%, а якщо стратегія повторів агресивна, ця частка може сягнути понад 10%.
Ми провели внутрішнє стрес-тестування: у сценарії обслуговування клієнтів із паралельністю 500 при встановленні тайм-ауту в 3 секунди частка повторів становила близько 8%; після збільшення до 8 секунд вона впала нижче 2%, але через довший час очікування частину запитів користувачі скасовували самостійно, що створило нові втрати. Зрештою знайдений баланс — тайм-аут 5 секунд у поєднанні з експоненційним відступом при повторах, що дозволило утримати загальну надлишковість на рівні близько 3%, заощадивши приблизно 6% рахунку порівняно з початковою агресивною стратегією.
Ще один момент, який легко пропустити, — потоковий вивід. У потоковому сценарії, якщо клієнт передчасно відключається, сервер може вже згенерувати частину Token і виставити рахунок. Тому для мобільних пристроїв або середовищ зі слабким зв'язком потрібно подбати про перепідключення й дедуплікацію, щоб один запит не тарифікувався двічі.
Рекомендації щодо оптимізації: встановіть розумний поріг тайм-ауту, щоб надто короткий не спричиняв часті повтори; для сценаріїв із високими вимогами до ідемпотентності використовуйте дедуплікацію за ID запиту; для некритичних завдань застосовуйте «деградацію при збої», а не нескінченні повтори. Тестуючи багатомодельну маршрутизацію SiCore TokenWorks, ми виявили, що автоматичний вибір оптимальної моделі за завданням зменшує повтори через обмеження лімітів окремої моделі, знижуючи загальну надлишковість з 5% до менш ніж 2%.
Пастка четверта: неузгодженість методик тарифікації при змішуванні кількох моделей
Коли ви одночасно підключаєте Qwen API, API великої моделі Doubao, Gemini API, кожна з них рахує Token по-різному. Деякі приблизно за кількістю символів, деякі за фактичною кількістю Token, деякі застосовують різні коефіцієнти для китайської та англійської. У китайськомовних сценаріях один ієрогліф відповідає приблизно від 0,6 до 1,5 Token, і різні токенізатори дуже відрізняються. Після уніфікованого підключення кількох моделей, якщо фінансовий відділ рахує за єдиною ціною, відхилення накопичуватиметься.
Ось реальний приклад: одна команда використовувала три моделі для модерації контенту, і фінансовий відділ рахував за єдиною ставкою «0,02 юаня за тисячу викликів». Під час квартальної звірки виявилося, що фактичні витрати на 40% перевищили бюджет. При детальному розборі з'ясувалося, що одна з моделей рахувала Token для китайської майже вдвічі більше за дві інші, і саме вона мала найбільший обсяг викликів.
Рекомендації щодо оптимізації: використовуйте агрегаційну платформу AI API для уніфікації методики обліку або створіть власний лічильник Token для звірки; ведіть окремий облік витрат для кожної моделі та звіряйте щотижня; на рівні маршрутизації фіксуйте для кожного виклику модель, кількість вхідних і вихідних Token та фактичну вартість, щоб полегшити подальший аналіз. Такі платформи, як token8341, уніфікували прозорість тарифікації, працюють за принципом оплати за обсяг, пропонуючи вигіднішу вартість, і підходять командам, яким потрібно змішувати кілька моделей.
Як оминути ці пастки
Якщо сформулювати одним реченням: не складайте бюджет за формулою «ціна за одиницю × кількість викликів», а оцінюйте за формулою «вхідні Token × ціна вхідних + вихідні Token × ціна вихідних + Token системної підказки + надлишковість на повтори». Рекомендую спершу протягом тижня зібрати реальні логи викликів, порахувати фактичний розподіл Token, а потім помножити на коефіцієнт запасу 1,2.
У практичному плані можна діяти в чотири кроки: перший — налаштувати збір даних, фіксуючи для кожного виклику вхідні та вихідні Token, модель, час виконання, чи був повтор; другий — класифікувати статистику за бізнес-сценаріями, розрізняючи короткий вхід із довгим виходом та довгий вхід із коротким виходом; третій — провести цільову оптимізацію для сценаріїв із найбільшою часткою, насамперед стискаючи системну підказку та довжину виводу; четвертий — щомісяця звіряти відхилення між рахунком і логами, постійно калібруючи бюджетну модель.
Для команд, яким потрібно швидко підключити кілька вітчизняних і зарубіжних API великих моделей, агрегаційна платформа AI API позбавить клопоту з інтеграцією кожного SDK окремо. Інтерфейс, сумісний з OpenAI SDK, дозволяє змінити модель, змінивши лише один рядок base_url, що зручніше як для обліку витрат, так і для порівняння моделей. При змішуванні кількох моделей уніфікація методики обліку важливіша за просте прагнення до низької ціни за одиницю, адже приховані витрати від неузгодженості методик часто перевищують різницю в ціні за одиницю.
Додаткове читання: варто стежити за оновленнями документації щодо тарифікації API великих моделей, особливо за правилами ціноутворення вихідних Token і знижок за кешування — ці два пункти найбільше впливають на підсумковий рахунок. Крім того, версії моделей оновлюються часто, і нові версії іноді змінюють ціноутворення або спосіб токенізації, тож перед зміною моделі рекомендується провести невеликий тестовий запуск для звірки, щоб уникнути різкого стрибка рахунку.