В этом материале
После обновления vLLM проверяйте фактический режим CUDA Graphs, а не только запрошенную настройку.
После обновления vLLM проверяйте фактический режим CUDA Graphs, а не только запрошенную настройку. Возможности attention backend и форма batch способны изменить доступный путь захвата. Изменение задержки поэтому не следует сразу объяснять другой GPU. Сохраните конфигурацию, выбранный backend и журнал capture, затем сопоставьте decode и смешанные шаги на одном контрольном workload до обсуждения причин регрессии производительности.
Что означают режимы
В документе CUDA Graphs перечислены NONE, PIECEWISE, FULL и варианты, отдельно охватывающие decode. Они различаются областью захвата и сочетанием с компиляцией. Название FULL не означает поддержку любой динамической операции для любой модели. Запрашиваемый режим следует проверять относительно используемого runner и поддерживаемых операций. Сохраняйте точное имя параметра текущего релиза, потому что пример из старой конфигурации не доказывает неизменную семантику после обновления движка.
Проверьте attention compatibility
Матрица attention backends связывает выбор с конфигурацией модели и поддерживаемыми features. Отдельные реализации могут требовать другой путь выполнения для определенных shapes. Не рассматривайте backend и CUDA Graph mode как независимые переключатели с произвольными сочетаниями. До benchmark запишите фактический backend, dtype и ключевые размеры модели. Если явный выбор несовместим, сохраните причину отказа вместо попытки скрыть проблему последовательным включением случайных параметров, которые меняют сразу несколько условий эксперимента.
Пример приемочной таблицы
Для старого и нового релиза подготовьте строки «decode одиночного запроса», «несколько активных ответов» и «prefill вместе с decode». В столбцах укажите запрошенный режим, фактический путь, capture события и функциональный результат. Числа задержки добавляйте только после отдельного измерения. Если расхождение возникает лишь в смешанной строке, исследуйте поддержку соответствующей формы batch, а не объявляйте, что весь режим FULL перестал работать или что модель больше не поддерживается в выбранном runtime.
Отделите capture от прогрева
Первое выполнение может включать компиляцию и подготовку графов. Сравнивайте повторные серии отдельно от холодного старта. Также держите одинаковыми контекст, длину ответа и schedule подачи запросов: другое распределение shapes меняет состав реально используемых путей. Профиль нужен, чтобы подтвердить интерпретацию сообщений журнала. Низкая средняя GPU utilization не показывает, какой именно graph path был выбран, и не заменяет фактическую проверку capture событий в исследуемом процессе сервера.
Зафиксируйте решение релиза
В manifest укажите режим, backend, model revision и тестовые shapes. Если допустим fallback, опишите его область и проверенную стоимость для конкретного workload. Если требуется строго определенный режим, несовместимость должна останавливать приемку, а не превращаться в невидимое снижение требований. Не обещайте ускорение только по факту успешного capture: запуск графа может занимать разную долю общей задержки. При rollback восстанавливайте согласованные runtime и настройки. Полезный итог — таблица фактических путей исполнения и их проверок, позволяющая следующему оператору отличить ожидаемую смену реализации от ошибки конфигурации и повторить сравнение без предположений о том, что одинаковая строка launch command обязательно дает одинаковый вычислительный маршрут на новой версии.
Связанные материалы
Установка vLLM: как проверить GPU, драйвер и сборку; Обновление LLM на GPU: как проверять новую версию небольшим запуском.