В этом материале
Attention backend vLLM нужно принимать по фактическому выбору и поддержке конкретной конфигурации модели.
Attention backend vLLM нужно принимать по фактическому выбору и поддержке конкретной конфигурации модели. Автоматический выбор идет по предусмотренным правилам совместимости, а явный override должен проходить проверку. Название быстрого backend из другого benchmark не является рекомендацией для любой GPU. Сохраните dtype, head dimensions и используемые features, затем подтвердите effective path. Отдельно рассматривайте GEMM quantization и CUDA Graph mode: эти решения связаны, но не являются одним переключателем.
Как работает auto selection
Документация attention backends описывает обход приоритетов и проверку конфигурации. Если backend не задан явно, выбирается допустимая реализация согласно правилам runtime. Поэтому обновление движка способно изменить выбор при тех же исходных аргументах. Не выводите название только из архитектуры GPU или установленной библиотеки. Сохраните наблюдаемый effective backend и engine version, иначе сравнение релизов может ошибочно трактовать новый вычислительный путь как регрессию модели либо случайный эффект аппаратного изменения, которого вообще не было в эксперименте.
Что проверяет явный override
При ручном выборе совместимость оценивается относительно dtype, размеров и других условий. Документированный отказ с причиной полезен: он показывает, почему сочетание не допускается. Не обходите его случайным изменением нескольких параметров сразу. Если требуется другой путь, сверяйте support matrix и повторяйте функциональную приемку. Успешный запуск не означает, что backend реализует все возможные features, нужные приложению. Например, дополнительно используемые режимы могут иметь собственные ограничения, поэтому набор требований нужно перечислить до начала подбора, а не после возникновения ошибки.
Пример acceptance table
Для фиксированных модели и GPU создайте строки auto, выбранный явный backend и заведомо неподходящий вариант только для тестовой проверки отказа. В столбцах укажите requested, selected, validation message и functional fixture. Это структура наблюдения, не рейтинг скорости. Сравните effective path после обновления движка на тех же inputs. Если auto изменился, найдите подтвержденное правило выбора. Если ручной вариант отвергается, сохраните точную причину, а не заменяйте ее общим сообщением «видеокарта недостаточно мощная» без связи с конкретной проверкой совместимости.
Проверьте графы отдельно
Описание CUDA Graphs связывает режимы capture с возможностями attention implementation. Backend может быть допустим для модели, но требовать иной graph path для определенных shapes. Поэтому в протоколе должны быть отдельные строки attention selection и capture mode. Не считайте разрешенный FULL режим доказательством выбора желаемого attention kernel, и наоборот. Для mixed prefill/decode проверьте те shapes, которые реально возникают в workload, вместо одного короткого запроса, покрывающего только узкую ветвь исполнения.
Зафиксируйте решение
После функциональной приемки измеряйте latency и throughput на сохраненной серии, не обещая преимущество явного pinning перед auto. Ручная фиксация дает контроль выбора, но может ограничить будущие совместимые пути. Сохраните причину такого решения и способ пересмотра при обновлении. В release artifact включите модель, GPU capability, runtime, features и фактические backends. Полезный итог объясняет, что выбрано и почему допустимо, а не превращает имя реализации в универсальную характеристику качества. При переносе на другой узел повторите compatibility acceptance: одинаковый объем VRAM и тот же checkpoint не гарантируют совпадения архитектурных условий, kernel support и реально доступного пути исполнения attention.
Связанные материалы
Установка vLLM: как проверить GPU, драйвер и сборку; Эталонная конфигурация GPU-узла: зачем она небольшому пулу.