В этом материале
max-model-len ограничивает суммарный контекст модели; это не размер только пользовательского сообщения.
В vLLM параметр --max-model-len ограничивает длину контекста, включая вход и генерируемый выход. Его выбирают по задаче, поддержке модели и доступной памяти. Большое значение из карточки checkpoint не обязано быть подходящим для конкретного GPU. Начинайте с рабочего сценария и явно резервируйте место для ответа.
Посчитайте весь запрос
Вход включает системное сообщение, историю, пользовательский документ и служебный шаблон. Ответ добавляет новые токены в тот же бюджет. Если учитывать только последнее сообщение пользователя, приложение обнаружит ограничение уже после нескольких сообщений диалога.
Практический пример: при выбранном лимите 8192 токена можно планировать вход до 6000 и резерв ответа до 1500, оставив место для служебных элементов. Это пример проектирования бюджета, а не универсальные настройки. Фактическое число токенов определяйте токенизатором конкретной модели после применения шаблона.
Не увеличивайте контекст одним числом
Архитектура модели и её конфигурация задают поддерживаемый режим контекста. Изменение аргумента движка само по себе не обучает модель работать с более длинной последовательностью. У расширений контекста могут быть отдельные требования и компромиссы качества.
Проверьте справочник serve и карточку выбранного checkpoint. Если значение не задано, движок использует предусмотренный им способ определения длины; не полагайтесь на память о старом выпуске. Для воспроизводимого опыта полезнее сохранить явный проверенный предел в паспорте запуска.
Свяжите длину с памятью
Контекст расходует KV-кеш, а обработка входа создаёт собственную вычислительную нагрузку. Две модели одинакового числа параметров могут иметь разную архитектуру кеша. Следовательно, одинаковое значение max-model-len не означает одинаковый расход VRAM или одинаковую задержку.
Сначала проверьте один длинный запрос, затем несколько независимых. Прохождение одиночного теста подтверждает лишь этот режим. Если нужна массовая обработка коротких документов, выделение ресурсов под редко используемый максимальный контекст может оказаться нерациональным. Связь с ёмкостью рассмотрена в материале о длинном контексте.
Используйте явный учебный запуск
Для совместимой установленной среды пример выглядит так:
vllm serve Qwen/Qwen3-0.6B --max-model-len 4096
Здесь 4096 — ограничение эксперимента. Перед изменением сравните его с конфигурацией модели, доступной памятью и фактическими запросами. Дальнейшие способы настройки описаны в официальной оптимизации vLLM.
В клиенте отдельно установите разумный максимум выхода. Один серверный предел не распределяет бюджет между документом и ответом так, как нужно пользователю. Проверьте сообщение об ошибке на заведомо слишком длинном запросе: приложение должно объяснять ограничение, а не бесконечно повторять отправку.
Сохраните один запрос у принятой границы и один заведомо превышающий её. Разные ожидаемые результаты помогают проверить ограничение после изменения клиента, шаблона или версии движка.
Предлагайте измеренный профиль оборудования
Для пилота подготовьте короткий документ, типичный документ и документ у границы принятого лимита. Для каждого сохраните входные токены, выход, пиковую память и время до первого токена. Затем повторите типичный случай с рабочей параллельностью. Пример диагностики есть в разборе OOM на длинном входе.
Владельцу GPU такой профиль помогает назвать пригодную нагрузку вместо абстрактной «поддержки длинного контекста». Финансирование дополнительной памяти можно обсуждать относительно конкретных документов.