Счётчик токенов не совпадает с usage LLM: как найти причину расхождения

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

Сначала определите, сравниваете ли вы одну и ту же величину. Вход, выход, категории учёта поставщика и денежная сумма не являются взаимозаменяемыми показателями.

Где возникает ошибка

Данные ниже вымышлены: они показывают способ разбора, а не измерения действующего сервиса.

Числа показывают устройство сверки, а не результаты запуска конкретного токенизатора. Для честного сравнения нужен фактически отправленный набор сообщений, а не текст из интерфейса. Преобразование ролей в последовательность может добавлять управляющие элементы; их состав зависит от модели.

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

Как воспроизвести проблему

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

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

Что учитывать при переносе

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

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

Если хотите связать этот разбор с системной практикой, посмотрите программу LLMOps & Evaluation на Latorn: она охватывает контур оценки, версии промптов, мониторинг и выпуск LLM-приложений. Перед оплатой сопоставьте требования курса со своим опытом и задачей проекта.

Следующий шаг: LLMOps: измерение качества, расходы и выпуск изменений. По смежным вопросам: Тайм-ауты в LLM-eval: как не улучшить метрику удалением неудачных ответов, Откат LLM-релиза: почему старый код может не работать с новым индексом.