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

Ответы vLLM могут измениться после обновления model repository из-за generation_config.json, даже если launch command осталась прежней.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/vllm-generation-config-precedence/
Language: ru

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

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

Generation config хранит параметры поведения генерации отдельно от архитектуры и tensor files. [Hugging Face](https://huggingface.co/docs/transformers/main/en/main_classes/text_generation) описывает `GenerationConfig` и настройки завершения, sampling и длины. Обновление соответствующего файла способно изменить поведение клиента, использующего значения по умолчанию. Поэтому при смене revision проверяйте diff конфигурации, а не только размер скачанного checkpoint. Не считайте наличие поля обещанием одинаковой семантики во всех serving frameworks: нужны правила конкретного runtime.

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

Согласно [справочнику vLLM](https://docs.vllm.ai/en/stable/cli/serve/), `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: как проверять новую версию небольшим запуском](/ru/journal/model-update-canary/); [Воспроизводимый стек инференса: как сохранить результат GPU-пилота](/ru/journal/software-stack-reproducibility/).