Почему generation_config.json меняет ответы vLLM после обновления модели

Ответы vLLM могут измениться после обновления model repository из-за generation_config.json, даже если launch command осталась прежней. Проверяйте эффективные настройки генерации вместе с весами и tokenizer. Наличие одинакового temperature в одном запросе не доказывает равенство остальных параметров. Полезный результат диагностики — таблица происхождения каждого существенного значения, а не список предполагаемых дефолтов.

Что приносит репозиторий

Generation config хранит параметры поведения генерации отдельно от архитектуры и tensor files. Hugging Face описывает GenerationConfig и настройки завершения, sampling и длины. Обновление соответствующего файла способно изменить поведение клиента, использующего значения по умолчанию. Поэтому при смене revision проверяйте diff конфигурации, а не только размер скачанного checkpoint. Не считайте наличие поля обещанием одинаковой семантики во всех serving frameworks: нужны правила конкретного runtime.

Как vLLM выбирает конфигурацию

Согласно справочнику vLLM, generation-config позволяет использовать автоматическую загрузку из model path, отдельный путь или настройки vLLM. override-generation-config имеет собственные правила объединения. Особенно важно проверить max_new_tokens из выбранной конфигурации: документация описывает его влияние на серверный предел вывода. Зафиксируйте версию runtime и выбранный режим, прежде чем объяснять короткий ответ ошибкой модели или размером ее контекстного окна.

Пример таблицы эффективных значений

Для учебного сравнения возьмите старую и новую revision, затем сформируйте строки «sampling», «stop/EOS», «output limit» и «request override». Для каждой сохраните значение, источник и способ проверки. Числа должны приходить из реальных файлов и запроса, а не из памяти оператора. Сначала повторите запрос без явных overrides, затем с одинаковым набором допустимых request параметров. Это помогает отделить изменившийся default от поведения, которое клиент уже задает самостоятельно.

Приемка обновления

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

Как оформить воспроизводимый релиз

Добавьте generation config в manifest артефактов вместе с commit, tokenizer и launch configuration. Укажите, какие поля должны определяться репозиторием, какие сервером и какие клиентом. Не отключайте конфигурацию целиком только ради прежнего ответа: сначала проверьте, не содержит ли она необходимые EOS значения. Если выбран режим собственных дефолтов vLLM, явно перечислите проверенные различия и обновите fixtures. Такой документ позволяет следующему оператору повторить решение и увидеть намеренное изменение. При rollback возвращайте весь согласованный комплект, иначе прежние веса могут получить новые параметры генерации, и сравнение окажется вводящим в заблуждение даже при совпадении model ID и успешной загрузке сервера.

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

Обновление LLM на GPU: как проверять новую версию небольшим запуском; Воспроизводимый стек инференса: как сохранить результат GPU-пилота.