В этом материале
Сверка связывает запрос, фактический маршрут, единицы использования и начисление. Локальная оценка числа токенов полезна для контроля, но не должна молча подменять данные окончательного расчёта.
В простом примере приложение отправляет один запрос и получает один ответ. В рабочей системе могут появиться резервирование, кеш, прерывание потока и разные credentials. Поэтому учёт токенов нужно строить вокруг наблюдаемой цепочки, а не только вокруг исходного текста пользователя.
Материал проверен 1 ноября 2026 года. Мы предлагаем способ контрольной сверки, который можно адаптировать к выбранному шлюзу и поставщику. Он не задаёт универсальное правило начислений: окончательные условия относятся к конкретному продукту и режиму вызова.
Создайте контрольный набор событий
Начните с нескольких синтетических запросов: короткий ответ, длинный вход, потоковая выдача и согласованное прерывание. Задайте идентификатор прикладной операции и сохраните доступные идентификаторы запросов каждого слоя. Содержание можно отделить от учётных метаданных.
Полезная строка сверки содержит время, модель, конечного исполнителя, credentials-путь и статус. Если один прикладной запрос породил несколько попыток, отразите их отдельно. Иначе сумму легко связать с неверным событием или ошибочно посчитать один запрос несколько раз.
Читайте usage по выбранному интерфейсу
OpenRouter Support описывает использование данных провайдера для расчётов и различные единицы моделей. Для вашего интерфейса проверьте, какие поля возвращаются и когда они становятся доступны. Потоковый и непотоковый режимы могут требовать разного способа сбора.
Не считайте текстовую длину надёжным заменителем usage. Токенизатор, служебная структура и особенности модели влияют на результат. Локальный подсчёт полезен как диагностическая оценка, если его происхождение явно указано рядом с данными сервиса.
Сопоставьте промежуточный и окончательный учёт
В LiteLLM Spend Tracking описаны средства внутреннего учёта. Для любой такой системы важно знать источник цены и полноту наблюдаемых запросов. Внутренний показатель может отличаться от внешнего счёта по объяснимым причинам.
Условный пример: шлюз оценил стоимость по прежней карточке цены, а поставщик применил иные актуальные условия. Правильный следующий шаг — установить причину и обновить модель учёта. Нельзя скрывать расхождение, просто заменяя одно число другим без истории изменения.
Разберите специальные случаи отдельно
Проверьте кешированные части, reasoning, дополнительные модальности и прерванные ответы, если они относятся к вашей нагрузке. Не переносите правила обычного текстового вызова на все варианты API. Для каждого специального случая нужна отдельная контрольная строка.
Определите период сверки, часовой пояс и порядок поздних корректировок. Это помогает согласовать внутренний отчёт с внешним расчётом. Если подтверждение начисления появляется позже технического события, его статус должен оставаться видимым до завершения проверки.
Для каждого расхождения назначьте статус: установлена причина, ожидается подтверждение или требуется исправление. Это позволяет финансовой стороне видеть качество сверки, не подменяя неопределённые суммы окончательно подтверждёнными начислениями.
Как использовать сверку в GPU-пуле
Для расчётов с владельцем оборудования важны согласованные определения, а не только общий график загрузки. Технический выпуск токенов нельзя автоматически приравнивать к оплаченной работе.
Для подготовки полезны показатели работы оборудования и полная стоимость роутера.