Расходы на ИИ-API: токены и группы

Учёт расходов на ИИ-API полезен, когда каждое списание связано с конкретным запросом, моделью, группой и измеренной единицей работы. Итог за месяц показывает изменение расходов, а запись по запросу объясняет причину.

Modelflare объединяет цены моделей, измеренное использование, политику групп и журналы запросов, поэтому стоимость не приходится оценивать по одному лишь видимому тексту.

Четыре уровня стоимости запроса

1. Цена модели

У каждой модели своя основа тарификации. Многие текстовые модели отдельно учитывают входные и выходные токены; API изображений, аудио, ранжирования и других задач могут использовать иные единицы. Для возможностей, которые нельзя выразить одной ценой за токен, применяются версионированные расширенные правила.

Используйте раздел Модели и цены как актуальный источник по модели и формату API, а не копируйте цену в код приложения.

2. Измеренное использование

Шлюз записывает использование, возвращённое провайдером или вычисленное для завершённого запроса. У текстовых моделей вход и выход хранятся раздельно, поскольку их тарифы могут отличаться.

Видимый в терминале потоковый текст — ненадёжная основа для расчёта. Элементы инструментов, рассуждения, кэшированный ввод, нормализованные токены и специальные поля использования могут учитываться, даже если не отображаются как обычный текст ассистента.

3. Коэффициент группы

Выбранная группа маршрутизации может применять коммерческий коэффициент к базовой стоимости. Например, коэффициент 0.9 означает 90% базовой стоимости модели для данного запроса.

Коэффициент относится к оплате использования. Он не меняет сумму кредита, которую пополнение добавляет в кошелёк.

4. Итоговая запись запроса

Журнал связывает рассчитанную сумму с моделью, группой, статусом, токенами, временем и безопасными операционными метаданными. Неудачные или отменённые запросы могут рассчитываться иначе, поэтому сохранённый результат надёжнее оценки на стороне клиента.

Что сравнивать при изменении расходов

• Модель: перешёл ли трафик на модель с другой ценой входа, выхода или функций?
• Группа: использовалась ли основная или резервная группа с другим коэффициентом?
• Протокол: изменился ли формат использования при переходе между Chat Completions и Responses?
• Размер входа: выросли ли промпты, извлечённый контекст, файлы или результаты инструментов?
• Размер выхода: дали ли увеличенные лимиты или циклы агента больше результата?
• Статус и повторы: вызвали ли ошибки дополнительные завершённые попытки?
• Время: означала ли долгая генерация больший вывод или только ожидание?

Изолируйте нагрузку по стабильному ID запроса или ключу конкретного приложения, а не сравнивайте несвязанный трафик всего аккаунта.

Задайте практические ограничения

Разделяйте ключи по нагрузке

Используйте разные ключи для production, разработки, автоматизации и личных инструментов. Для каждого можно задать имя, срок действия, политику групп и ограниченную или неограниченную квоту.

Выбирайте группы осознанно

Не ориентируйтесь только на название. Проверьте фактическую доступность модели, коэффициент, условия доступа, RPM и резервную политику. Более дешёвая основная группа с приемлемым резервом может быть предсказуемее неявного выбора, который трудно объяснить.

Сначала сокращайте вход

Длинные системные промпты, повторяемая история, найденные документы и результаты инструментов часто составляют основную часть входа. Удаляйте контекст, который больше не влияет на ответ, и не отправляйте неизменные данные повторно, если клиент может безопасно ссылаться на них или кэшировать.

Анализируйте циклы агентов

Одно действие пользователя может запустить несколько запросов к модели. Учитывайте каждый раунд инструментов и повтор, а не воспринимайте итоговый видимый ответ как один вызов API.

Почему клиентская оценка расходится с расчётом

Локальный токенизатор или подсчёт символов полезны для планирования, но могут отличаться от тарифицируемого использования:

• провайдеры по-разному нормализуют и считают содержимое;
• кэш, рассуждения, изображения, аудио и инструменты могут иметь отдельные ставки;
• расчёт использует фактически выбранные модель и группу;
• ошибки и возвраты зависят от реального жизненного цикла запроса;
• цены могут измениться, а старые запросы сохранят записанный результат.

Для финансовой сверки сопоставляйте сохранённые записи использования и кошелька. Не восстанавливайте баланс по одному полю интерфейса.

Повторяемый процесс проверки

1. Отфильтруйте журналы по одному API-ключу и периоду.
2. Сгруппируйте запросы по модели и выбранной группе.
3. Сравните вход, выход, статус и стоимость каждого запроса.
4. Проверьте выбросы: повторы, длинный контекст, циклы инструментов или резервные переключения.
5. Подтвердите актуальные цену и политику до изменения маршрутизации.
6. Установите конечную квоту ключа, если нужна жёсткая граница расходов.
7. После изменения снова проверьте те же показатели.

Контроль расходов начинается с атрибуции. Пока модель, группа, использование и результат связаны, команда может оптимизировать реальный источник затрат, а не гадать по агрегированным итогам.