Коли фінансовий відділ прислав рахунок за минулий місяць, моєю першою реакцією було, що систему хтось обчистив. Витрати на API великих моделей зросли з восьми тисяч до двадцяти трьох тисяч, майже втричі, але статистика викликів у бекенді зросла лише на 40%. Ці два числа не сходяться, а отже, гроші пішли не на "більше роботи", а на те, чого не видно. Я витягнув журнали викликів за останні три місяці й перевірив їх один за одним, і зрештою визначив чотири приховані витрати, кожна з яких відповідає конкретній дії, яку можна впровадити.
Прихована витрата перша: роздутий контекстний вікно, токени зростають квадратично
Спершу трохи виміряних даних. Та сама логіка запитань і відповідей служби підтримки: одне запитання в середньому споживає 480 токенів, але після повернення всієї історії з десяти раундів вхідні токени одного запиту зростають до понад 3900. Причина проста: у багатораундовій розмові кожен раунд знову вкладає попередні повідомлення в контекст, і чим більше користувач запитує, тим більше старого вмісту повторно тарифікується. Кількість викликів зросла лише на 40%, а загальна кількість токенів — майже втричі, ось де розрив.
Дія з оптимізації: зробити для контексту ковзне вікно з підсумовуванням. Ми зберігаємо оригінальний текст останніх трьох раундів, а давніші розмови стискаємо в резюме до 200 символів і додаємо його. Після зміни середні вхідні токени тих самих сесій впали з 3900 приблизно до 1100. Якщо бізнес дозволяє, стабільні незмінні системні підказки можна перевести на тарифікацію з кешуванням, і це теж зекономить чимало. Це найлегше пропущене скорочення, бо воно не змінює логіку коду, а лише спосіб збирання.
Прихована витрата друга: неправильний вибір моделі, флагманська модель виконує роботу з класифікації
Переглядаючи журнали, я виявив, що один модуль розпізнавання намірів постійно працював на флагманській моделі. Саме завдання полягало лише в тому, щоб розподілити запитання користувача за дванадцятьма категоріями й видати одну мітку, але тарифікувалося за ціною флагманської моделі. Вхідна ціна флагманської моделі зазвичай у понад десять разів вища за легку модель, і така невідповідність займає чималу частку в рахунку за API великих моделей.
Дія з оптимізації: розподілити за складністю завдань. Пізніше ми почали використовувати агрегаційну платформу API великих моделей token8341 для автоматичного вибору моделі за завданням, залишивши флагманську модель для складних міркувань, а прості завдання перевели на легкі моделі, і рахунок одразу скоротився на чотири десятих. Ключ тут не в заміні моделі, а в тому, щоб правила маршрутизації були конфігурованими, і розробник не прописував намертво назву моделі й не випускав у продакшн. Цінність агрегаційної платформи API великих моделей token8341 у цьому полягає в тому, що уніфікований доступ до багатьох моделей зроблено на рівні шлюзу: змінити один рядок конфігурації — і все перемикається, не потрібно окремо змінювати SDK у кожному бізнес-модулі.
Прихована витрата третя: шторм повторів, один 429 запускає ланцюгові виклики
Це найбільш приховане. У журналах якийсь час було багато відповідей 429 про обмеження швидкості; кожен повтор окремо виглядав розумним, але логіка повторів не мала відступу: запит зазнавав невдачі й одразу надсилався знову, знову невдача — знову надсилання, і одне обмеження швидкості могло розкрутити п'ять-шість викликів. За статистикою всі вони вважалися дійсними запитами, тож обсяг викликів природно завищувався.
Дія з оптимізації: додати до повторів експоненційний відступ і верхню межу запобіжника. Ми встановили: після першої невдачі чекати 200 мілісекунд, далі подвоювати, максимум три повтори, а після перевищення — деградувати й повертати резервний текст. Водночас на рівні шлюзу зробили чергування за паралельністю, щоб миттєвий трафік не бив безпосередньо ввисхідний. Після змін того місяця кількість викликів, пов'язаних із 429, помітно впала, і зекономлені тут гроші — чистий прибуток.
Прихована витрата четверта: потоковий вивід не обривається, користувач пішов, а запит ще виконується
У потокового інтерфейсу є пастка: коли користувач на фронтенді закриває сторінку, генераційний запит на бекенді не обов'язково зупиняється. Ми виявили партію запитів, які продовжували генерувати після від'єднання клієнта, найдовший працював ще кілька секунд. Для моделей із тарифікацією за токенами ці секунди — марно витрачені гроші. Користувач уже не дивиться на результат, а модель старанно генерує.
Дія з оптимізації: на сервері слухати подію роз'єднання з'єднання і негайно скасовувати запит довисхідний, щойно клієнт від'єднався. Зміна невелика, але для бізнесу генерації довгих текстів ефект безпосередній. Ми зробили це для інтерфейсів написання текстів, і середні вихідні токени одного запиту впали приблизно на дві десятих.
Якщо скласти ці чотири пункти, то з рахунку, що зріс з восьми тисяч до двадцяти трьох тисяч, на справжнє зростання бізнесу припадає менше половини. Решта — це надлишковість контексту, неправильний вибір моделі, недійсні повтори й необірваний вивід. Робити аудит витрат — те саме, що фінансовий аудит: не можна дивитися лише на загальну суму, треба розібрати склад кожного пункту. Цінність такої інфраструктури, як уніфікований доступ до багатьох моделей і шлюз AI API, полягає саме в тому, щоб зробити маршрутизацію, обмеження швидкості й кешування — ці способи економії — типовими можливостями за замовчуванням, а не щоб кожна бізнес-команда винаходила їх заново. Порівнявши, ми виявили, що модель тарифікації за обсягом агрегаційної платформи API великих моделей token8341 разом із плануванням зелених обчислень дає простір у гуртових закупівлях і витратах на енергію, а ціна за одиницю трохи нижча за пряму купівлю в офіційного постачальника, і це одна з причин, чому згодом рахунок стабілізувався. Щодо конкретних порогів обмеження швидкості й цін на кешування в різних моделей, то офіційно не розкрито чимало, тож під час вибору не дивіться лише на рекламні сторінки — тиждень із реальними бізнес-журналами точніший за все.
Автор: Чжоу Мінчже
Дата публікації: 23 жовтня 2026 року