В этом материале
Сравнивайте native token count с полной подготовленной последовательностью сообщений, а не с одним пользовательским текстом без шаблона.
Число символов в запросе не определяет prompt_tokens. Даже локальная токенизация текста пользователя может отличаться от счётчика сервера, потому что модель получает подготовленную последовательность сообщений. В ней присутствуют роли, управляющие маркеры и другие элементы выбранного chat template. Разбор расхождения начинается с определения измеряемого объекта, а не с предположения, что любой из двух счётчиков ошибается.
Опишите вход до токенизации
Сохраните обезличенный массив messages с точным порядком ролей. Не заменяйте его объединённой строкой: такое преобразование теряет структуру диалога. Отдельно запишите инструменты, системные инструкции и параметры шаблона, если они участвуют в подготовке выбранной модельной последовательности.
Руководство Hugging Face объясняет, что chat messages преобразуются в последовательность токенов и что модели используют разные управляющие форматы. Значит, одинаковый видимый диалог не обязан иметь одинаковое число токенов у двух моделей. Сравнение требует конкретной версии tokenizer и template.
Зафиксируйте уровень счётчика
Схема OpenRouter описывает native tokenizer как основу возвращаемых token counts. Это не обещание совпадения с произвольной клиентской библиотекой подсчёта. Для собственного сервиса нужно определить, на какой границе считается prompt: до шаблона, после него либо по подтверждённому значению движка.
Сохраните единицы и происхождение числа в отчёте. Поле «приблизительная оценка клиента» не должно переименовываться в «фактический расход». Если счётчик недоступен на выбранном пути, укажите неизвестное значение, а не подставляйте ноль ради удобной таблицы.
Сделайте маленький набор сравнений
Начните с одного user message. Затем добавьте system message, историю из нескольких ролей и определение одного инструмента. Меняйте только один элемент за шаг. Для каждого варианта сохраните видимый текст, подготовленную последовательность при доступности такой диагностики и native prompt count.
Артефакт представляет таблицу «fixture — ревизия — метод подсчёта — значение — объяснение разницы». Он полезнее снимка экрана с двумя числами. Входы должны быть короткими и синтетическими, чтобы их можно было хранить рядом с тестом без содержания настоящих разговоров.
Разберите типичные развилки
Если расхождение появляется только после добавления роли, проверьте шаблон и служебные маркеры. Если оно возникает на всех входах после обновления, сравните версии tokenizer и подготовку special tokens. Если отличается только сложный запрос с tools, исследуйте именно сериализацию инструментов на границе адаптера.
Не исправляйте расхождение постоянным коэффициентом. Состав сообщений меняется, поэтому поправка, подходящая одному примеру, может не работать на другом. Отдельно проверьте, не добавляются ли маркеры дважды из-за последовательного применения двух механизмов подготовки.
Сохраните границы сверки
Такой набор объясняет воспроизводимое различие технических счётчиков, но не устанавливает цену запроса и не подтверждает корректность любого внешнего отчёта. Для финансовой сверки нужны свои правила и источник окончательного расчёта. Нельзя также выводить качество ответа из совпавшего количества входных токенов.
Связанные темы — токены и биллинг и воспроизводимый стек. Их объединяет сохранение происхождения данных: название модели и итоговое число без условий не дают достаточного основания для сравнения.