Стоимость AI API по проектам: как считать бюджеты без ложной точности

Начните с единицы учёта

Сначала решите, что именно команда называет проектом: продукт, tenant, функция, окружение или центр затрат. Не используйте API key как единственный финансовый тег: один ключ может обслуживать несколько функций, а ключи нужно ротировать. Лучше серверу явно передавать внутренние поля projectId, feature и environment, валидировать их по allowlist и записывать рядом с безопасным request ID.

Тег не должен содержать email, имя клиента, текст запроса или другой персональный идентификатор. Если бизнесу нужно связать расход с tenant, храните внутренний псевдоним и контролируйте доступ к таблице соответствий. Платёжная отчётность и продуктовая аналитика имеют разные цели: первая может требовать сверки по периоду, вторая — быстрых агрегатов. Не делайте вывод о точной марже из одного HTTP-ответа, пока не учтены повторы, отмены, кеш, асинхронные задачи и правила выставления счёта.

Считайте стоимость успешной задачи

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

Отдельно отмечайте неуспешные операции. Если запрос вернул 400 из-за вашего payload, это сигнал исправить интеграцию, а не списать его на модель. Если 429 заставил поставить задачу в очередь, не создавайте бесконечные повторы. Если пользователь отменил поток, запишите событие отмены и проверьте, как ваша политика считает частично выполненную работу. Такая картина помогает выбирать оптимизацию по фактам, а не по самой низкой цене в каталоге. Базовую модель расчёта объясняет статья о снижении стоимости LLM API.

Сделайте бюджеты защитой, а не обещанием

У бюджета есть как минимум три уровня: предупреждение для владельца функции, мягкое ограничение с очередью или меньшим объёмом и жёсткая остановка для сценария, где риск превышения недопустим. Пороги выбираются вашей организацией по сезону, контракту и ценности функции; они не являются лимитом RussiaAPI и не должны описываться как гарантия. Пользователю сообщайте понятное состояние: функция временно ограничена, запрос поставлен в очередь или предложен повтор позже.

Не понижайте модель автоматически только потому, что бюджет почти исчерпан. Сначала подтвердите, что fallback разрешён для конкретных данных и функции, прошёл контрактный тест и не меняет ожидаемый формат. Для некоторых операций безопаснее остановиться, чем незаметно выдать другой результат. Сохраните владельца бюджета, дату пересмотра и действие при превышении. Такой процесс лучше, чем разрешить всем сервисам расходовать общий баланс без наблюдаемости.

Пример серверной записи расхода

Ниже не рассчитывается цена поставщика: пример показывает, как привязать безопасную метку проекта к ответу и передать usage в вашу проверенную таблицу тарифов. Поля usage, их наличие и смысл зависят от текущего API-контракта; сначала подтвердите их в каталоге и документации. API key не попадает в запись, а исходный prompt и ответ модели не нужны для финансового среза.

export async function recordUsage({ projectId, feature, response, requestId }) {
  const usage = response.usage;
  if (!usage) return ledger.markIncomplete({ projectId, feature, requestId });
  const tariff = await tariffs.current({ model: response.model }); // approved internal table
  const estimated = tariff.estimate({ input: usage.prompt_tokens ?? 0, output: usage.completion_tokens ?? 0 });
  await ledger.write({ projectId, feature, requestId, tariffVersion: tariff.version,
    inputUnits: usage.prompt_tokens ?? null, outputUnits: usage.completion_tokens ?? null, estimated });
  return estimated; // no API key, prompt, completion or personal data is stored
}

Если usage отсутствует или контракт изменился, помечайте запись как неполную и не подменяйте её выдуманным числом. Позже сверяйте агрегаты с утверждённой отчётностью. Наблюдаемость полезна только при явной версии тарифной таблицы: без неё сравнение месяца с месяцем легко превращается в ложную точность.

Постройте отчёт для владельца функции

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

При всплеске начинайте с безопасных вопросов: изменилась ли версия модели, модельный ID, размер контекста, retry-политика, очередь, трафик функции или тарифная таблица? Затем проверьте один обезличенный тестовый набор. Резкое увеличение может быть вашей ошибкой сериализации, а не свойством API. Для технических метрик без утечки контента используйте OpenTelemetry для LLM API и безопасные логи.

Оптимизируйте только после измерения

Частые меры — ограничить историю диалога, кешировать безопасные стабильные данные, объединить небольшие операции, уменьшить лишние retries и выбрать подходящую модель после теста. Но ни одна мера не универсальна. Сильное сжатие контекста может ухудшить ответ и увеличить число повторных обращений; дешёвая модель может добавить ручную проверку; агрессивный кеш способен вернуть устаревшую информацию. Сравнивайте итоговую стоимость успешного сценария и качество, а не только расход единиц.

Не обещайте пользователю фиксированную цену функции, пока договор и ваша продуктовая политика не определили расчёт. Каталог, доступные модели и условия могут меняться. Дайте владельцу возможность видеть актуальную конфигурацию и дату проверки, а затем корректируйте бюджет прозрачно. Вопросы выбора модели лучше решать по матрице качества, задержки и стоимости, как описано в чек-листе выбора модели.

Чек-лист финансовой наблюдаемости

1. Каждый запрос серверно связан с allowlist-тегами проекта, функции и окружения, а не только с ключом.
2. Отчёт разделяет попытки, успешные результаты, отмены и ошибки без хранения prompt или секретов.
3. Оценка использует версию утверждённой тарифной таблицы и помечает неполные записи.
4. Бюджеты имеют владельца, дату пересмотра, мягкое действие и безопасный сценарий остановки.
5. Fallback и оптимизация включаются только после контрактного теста и измерения итоговой стоимости задачи.

Начните с одного продукта и короткого периода, затем расширяйте разметку. Хорошая отчётность помогает видеть фактическое решение команды; она не заменяет текущие условия RussiaAPI, договор, налоговую или юридическую консультацию.