Как сверить токены промпта между Hugging Face и vLLM

Совпадение текста промпта не гарантирует совпадение входных токенов. Чтобы сравнить Hugging Face и vLLM, сохраните одну историю сообщений, одинаковую ревизию tokenizer и фактические token IDs после применения шаблона. Ищите первое расхождение последовательностей. Обычно это полезнее, чем сравнивать свободно сгенерированные ответы, на которые дополнительно влияют sampling и численные операции.

Разведите рендеринг и генерацию

Рендеринг превращает роли, текст и служебные маркеры в вход модели. Генерация начинается после этого. vLLM описывает renderer endpoints, позволяющие подготовить запрос без выполнения inference, а также инструменты токенизации. Используйте их, чтобы вынести GPU и декодирование за пределы первой проверки. Если входные token IDs уже различаются, одинаковая температура или одинаковый seed не исправляют причину расхождения между клиентскими путями.

Проверьте специальные токены

При отдельном вызове apply_chat_template важно понимать, вернул он текст или сразу токены. В документации Hugging Face отдельно разобран случай последующей токенизации текста: повторное добавление special tokens может дублировать BOS или EOS. Также зафиксируйте add_generation_prompt. Этот параметр определяет начало ожидаемой реплики assistant; он не равнозначен добавлению произвольной строки к пользовательскому сообщению. Сравнивайте настройки вместе с результатом, иначе fixture окажется неполным.

Постройте маленький diff

Для примера используйте историю из system инструкции, короткого user вопроса и одного завершенного assistant ответа. Сохраните два массива ID и индекс первого несовпадения. Рядом выведите декодированное окружение этого индекса, не публикуя чувствительный текст. Если все различия сосредоточены в начале, проверьте BOS. Если расходится хвост, посмотрите generation prompt и признак продолжения последнего сообщения. Если различия идут по всему тексту, сначала проверьте revision и tokenizer files.

Определите приемочные условия

Для контрольного набора требуйте точного совпадения ожидаемой последовательности, когда оба пути должны реализовывать один и тот же шаблон. Добавьте многострочный текст, Unicode, пустое допустимое сообщение и историю с несколькими ролями. Сохраните длину и checksum массива вместе с полными ID в локальном артефакте. Хэш облегчает сравнение релизов, однако для диагностики нужен сам массив: одинаковое число токенов не означает одинаковое содержимое. Укажите используемый формат content отдельно.

Не переносите вывод дальше проверенного

Точное совпадение промпта подтверждает только подготовку входа. Оно не обещает побитово одинаковую генерацию при разных backend, batch composition или версиях библиотек. После успешной сверки можно отдельно проверять generation config и качество ответа. Если deployment намеренно использует другой шаблон, не маскируйте это искусственным требованием parity: оформите отдельный эталон и объясните изменение. Полезный итог работы — версионированный JSON с сообщениями, параметрами шаблонизации, revision и ожидаемыми token IDs. Его можно повторно прогнать без загрузки весов, обнаружив изменение сериализации раньше дорогостоящего нагрузочного теста. Не заменяйте такой артефакт скриншотом ответа: скриншот не показывает границы токенов и скрытые служебные маркеры.

Связанные материалы

Воспроизводимый стек инференса: как сохранить результат GPU-пилота; vLLM bench serve: как прочитать результат командного теста.