В этом материале
Различие эффективного вычисления attention и страничного управления KV-памятью: почему backend сервинга может сочетать идеи обоих подходов.
FlashAttention и PagedAttention часто перечисляют как конкурирующие способы ускорения LLM. Однако они исходят из разных проблем. FlashAttention меняет перемещение данных при вычислении attention на GPU, а PagedAttention организует растущее KV-состояние обслуживаемых запросов. Различие позволяет избежать ложного выбора между идеями, которые современный backend способен сочетать. Ни одно название само по себе не описывает всю систему генерации ответа.
Найдите вычисление attention
Исходная работа FlashAttention предлагает IO-aware метод точного attention с плиточной обработкой. Основная цель — сократить дорогое перемещение памяти внутри операции. Слово «точный» описывает формулировку attention, а не обещает побитово одинаковые результаты всех реализаций на любых устройствах.
На схеме отделите вычислительное ядро от места хранения прошлых ключей и значений. Быстрое ядро автоматически не решает фрагментацию выделения, не определяет совместное использование блоков запросами и не выбирает момент вытеснения старого контекста из ограниченной памяти.
Найдите проблему памяти сервинга
Работа PagedAttention рассматривает управление KV-памятью при росте и сокращении контекстов запросов. Страничный подход обеспечивает гибкое размещение и совместное использование блоков. Это особенно существенно при нескольких запросах разной длины и продолжительности жизни.
Страницы не отменяют арифметику attention. Движок по-прежнему читает нужные блоки и вычисляет результат. Возможность совместного использования тоже зависит от отношения запросов и реализации, а не от присутствия слова Paged в рекламном описании или перечне установленных библиотек.
Разделите работы и названия backend
Репозиторий FlashAttention содержит конкретные реализации с требованиями к релизу и оборудованию. Название attention backend в движке может объединять ядра, раскладки и интеграцию планировщика. Это не обязательно прямой переключатель между двумя исходными научными работами.
Запишите версию движка, выбранный backend, архитектуру GPU, тип attention модели и расположение KV. Читайте фактический выбор при запуске, не предполагая, что установка пакета полностью определяет исполнение. Некоторые пути специализируются на prefill, decode, оконном attention или отдельных форматах кэша.
Сравните один определённый уровень
При проверке ядер сохраняйте сопоставимое хранение и нагрузку настолько, насколько допускает backend. При проверке памяти меняйте длины запросов, пересечение сроков жизни и совместное использование, учитывая исполняемые ядра. Явно отмечайте параметры, которые невозможно сохранить одинаковыми в выбранных реализациях.
Измеряйте полезно завершённые запросы и задержку вместе с памятью. Один длинный вход без конкурентности плохо описывает фрагментацию занятого сервиса. Максимальная пропускная способность тоже недостаточно характеризует интерактивную нагрузку с требованием предсказуемой равномерности вывода токенов.
Объясните результат без ложного победителя
Полезный вывод называет фактическую конфигурацию и объясняет источник выигрыша: вычисления, выделение, повторное использование или другое изменение. Он не объявляет исходную идею устаревшей из-за удачного результата другого backend на отдельном тесте.
При планировании инфраструктуры используйте различие для вопросов о пути исполнения модели. Ёмкость GPU, контекст и конкурентность связаны и с вычислениями, и с управлением кэшем. Ни одна метка attention отдельно не подтверждает размещение модели, поддерживаемое оборудование и итоговую производительность обслуживаемого сервиса.
Материалы по теме
Attention backend в vLLM: как проверить auto selection и явную фиксацию, KV-кеш и экономика GPU: зачем считать память активных запросов.