llama.cpp Flash Attention: включить, проверить и сравнить

Когда включать Flash Attention в llama.cpp?

В закреплённом llama-server параметр -fa, --flash-attn [on|off|auto] управляет применением Flash Attention; по умолчанию — auto. Общее чтение аргументов переводит on в разрешённый режим, off в запрещённый, auto в автоматический. on — запрос режима, не доказательство, что любой backend и любая модель успешно исполняют подходящий оператор. Оставьте auto для обычного первого запуска; on и off нужны для контролируемого сравнения или диагностики. s1 s2

Таблица операций GGML указывает для FLASH_ATTN_EXT частичную поддержку на CUDA, Vulkan, Metal и нескольких других backend; это сводка операций, а не список гарантированно совместимых видеокарт. При смене версии, драйвера, модели, типа KV-кеша и контекста проверка на своём устройстве остаётся обязательной. Новость об исправлении сбоя Vulkan на отдельной сборке относится к конкретной ошибке, а не обещает поведение всего Vulkan. s5

Если нужен первый контрольный сервер, начните с общего гайда llama.cpp. Для теста подойдёт один и тот же файл Qwen3-0.6B-Q8_0.gguf из закреплённой ревизии Qwen: он присутствует в списке файлов, карточка автора описывает этот вариант и маркирует Apache-2.0, а файл LICENSE содержит условия; здесь нет вывода о лицензиях всех вариантов Qwen. Скачайте именно закреплённый файл и сохраните его SHA-256 локально перед обеими сериями. Размер файла не является минимумом RAM/VRAM; сначала проверьте фактическую загрузку на своём backend. s6 s7 s8

Что подготовить, чтобы сравнение было честным?

Нужны одна сборка llama.cpp с известным Git-коммитом, один GGUF с сохранённым хешем, то же устройство и backend, одинаковые драйвер, offload слоёв, число потоков, длина входа/выхода и свободная память. Запишите выбранные параметры -ngl, -ctk, -ctv, -p, -n и -fa; режим KV-кеша обсуждается отдельно в гайде по KV-кешу. Не смешивайте сравнение Flash Attention с разным количеством серверных слотов или другой квантизацией модели. s1 s3

Сначала обычным llama-server получите контрольный ответ модели при --flash-attn auto и сохраните лог запуска, адрес backend и ошибку, если модель не загружается. Параметр сервера передавайте как --flash-attn on или --flash-attn off; проверяйте синтаксис конкретной установленной сборки через --help, потому что эта статья привязана к ревизии исходников, а не к любому бинарнику. Не публикуйте API наружу ради теста; учебный сервер привяжите к loopback. Статус /health подтверждает готовность сервера после загрузки, но не смысл ответа и не фактический выигрыш. s1 s2

Как запустить два замера скорости без подмены условий?

Официальный llama-bench на этой ревизии принимает -m, -fa on|off|auto, -p для prompt processing, -n для генерации, -r для повторений и -o csv для машинного вывода. Допускаются несколько значений -fa через запятую; инструмент строит комбинации тестов и выводит скорость в токенах в секунду с разбросом. Например, после локального скачивания и успешного запуска обоих режимов: ./build/bin/llama-bench -m /путь/Qwen3-0.6B-Q8_0.gguf -fa on,off -p 512 -n 128 -r 5 -o csv. Здесь /путь/ — подстановка реального файла, а не готовая команда для копирования без правки. s3 s4 s8

Сохраните весь вывод и лог вместе с коммитом сборки и конфигурацией устройства. В CSV сопоставляйте строки flash_attn, n_prompt, n_gen, n_gpu_layers, backends, avg_ts и stddev_ts, а не единственное лучшее значение. Документация различает prompt processing (pp) и text generation (tg): режим может влиять на них неодинаково. Прогрев и повторения предусмотрены инструментом; не сравнивайте результаты, если параллельно работали другие процессы или один режим не запустился. По документации llama-bench не включает время токенизации и сэмплирования, поэтому его avg_ts не равен полной задержке ответа HTTP. s3 s4

Для пользовательской задержки дополнительно выполните одинаковые запросы через llama-server поочерёдно в двух режимах при неизменных настройках, сохраните статусы HTTP, полный ответ и время клиента. Отдельно зафиксируйте пиковое использование RAM и VRAM средствами вашей ОС/драйвера при одинаковой длине контекста и после загрузки модели; llama-bench не превращает размер GGUF в измерение пика памяти. Сравните также осмысленность ответа на одних и тех же тестовых входах: изменение скорости не доказывает сохранение качества. Это предлагаемый протокол, а не уже выполненный опыт. s1 s3

Как трактовать неудачный запуск или отсутствие выигрыша?

Если on не загружает модель или возвращает ошибку backend, запишите полный лог, модель, тип K/V, устройство и версию. Проверьте тот же сценарий с auto и off, а также матрицу конкретной сборки; не объявляйте Flash Attention «обязательным» и не делайте вывод о всех CUDA/ROCm/Vulkan из одного отказа. Матрица FLASH_ATTN_EXT показывает частичную поддержку нескольких backend, но не диагностирует вашу конкретную ошибку. s1 s2 s5

Если обе ветки работают, а скорость близка, результат не означает, что настройка бесполезна в любом контексте: испытайте типичную для своей задачи длину входа и выходов, сравните повторения и полную задержку сервера, а затем выбирайте режим под собственное железо. Если при on хуже стабильность или ответы, вернитесь к auto либо off и сохраните воспроизводимый отчёт; нет оснований рекламировать ускорение или экономию VRAM без результата вашей машины. Эта страница не содержит собственных чисел производительности Modelium. s1 s3 s5

Основной следующий шаг — проверить базовый локальный запуск llama.cpp на выбранном GGUF, затем повторить одну и ту же контрольную нагрузку в on и off и сохранить CSV, лог и наблюдение за памятью. Описания Qwen и документации не заменяют реальный тест на вашем устройстве. s1 s3 s6