В этом материале
Релиз tokenizer нужно принимать как согласованный набор vocabulary, special tokens и chat template одной предназначенной версии.
Релиз tokenizer нужно принимать как согласованный набор vocabulary, special tokens и chat template одной предназначенной версии. Частичное обновление способно оставить старые настройки рядом с новыми весами, хотя сервер продолжит запускаться. Сохраните manifest файлов и контрольные преобразования. Это задача целостности пакета, отдельно от сравнения двух renderer реализаций: сначала нужно доказать, что каждая из них вообще получила один и тот же задуманный комплект артефактов.
Определите состав состояния tokenizer
Документация tokenizer описывает сохранение полного состояния через save_pretrained. Не считайте один vocabulary файл полным представлением всех настроек. Special tokens, normalization и другие параметры могут храниться отдельно и влиять на IDs. Зафиксируйте используемый tokenizer class и сохраненные файлы. Если repository содержит несколько вариантов, укажите выбранный путь. Переименование директории не делает смешанный комплект релизом: происхождение каждого элемента должно быть связано с принятой revision или явно задокументированным собственным преобразованием, которое можно воспроизвести.
Проверьте snapshot filters
Hub download guide показывает, как revision и file patterns определяют состав скачанного snapshot. Слишком узкий filter может оставить часть tokenizer metadata за пределами пакета. Не исправляйте это случайным копированием JSON из соседней модели. Сначала сравните список с принятым manifest и повторите получение нужных файлов. Если tokenizer поставляется отдельно от weights, сохраните обе revisions и заявленную совместимость. Один общий model alias не определяет, какую комбинацию фактически использует процесс сервера после локальных изменений каталога.
Сохраните chat template вместе с tokens
Руководство chat templating объясняет, как шаблон формирует последовательность и взаимодействует со special tokens. Поэтому template входит в контрольный комплект, даже если operator изменял его вручную. Для собственного override сохраняйте источник и hash, не называя его неизмененным repository default. Разделите намеренное изменение шаблона и случайное смешивание файлов. Первое требует новой версии fixtures, второе должно считаться нарушением принятого пакета. Успешная генерация не показывает, какой именно вариант шаблона был применен на подготовке входа.
Пример release manifest
Создайте таблицу file, source revision, hash и назначение. Добавьте короткий Unicode текст, строку с пробелами и conversation с несколькими ролями. Сохраните token IDs, decode round trip и rendered prompt. Это контрольные fixtures, не обещание обратимости любой normalization без изменений текста. Если round trip намеренно отличается, зафиксируйте ожидаемое поведение. При частичном обновлении одного файла тест должен обнаруживать отклонение прежде, чем оператор приступит к сравнению качества ответов или поиску вычислительной ошибки GPU.
Приемка и rollback
Проверяйте manifest на узле после доставки и до открытия serving. Затем выполните fixtures выбранным loader, чтобы подтвердить применение нужного комплекта, а не наличие файлов в неиспользуемом каталоге. При rollback возвращайте tokenizer artifacts вместе с model и template overrides. Полезный отчет показывает, что было доставлено, что загрузил runtime и какие преобразования подтверждены. Он не обещает, что tokenizer другой модели подойдет благодаря одинаковому размеру vocabulary. Такая граница релиза предотвращает скрытое изменение IDs и role markers при сохранении прежнего API model name. После смены framework повторите fixtures: тот же комплект должен проверяться по фактическому поведению используемого loader, а не только по внешнему checksum, который подтверждает файлы, но не выбор runtime пути.
Связанные материалы
Воспроизводимый стек инференса: как сохранить результат GPU-пилота; Обновление LLM на GPU: как проверять новую версию небольшим запуском.