Что нового в llama.cpp: отдельное Vulkan-ядро Flash Attention для prefill на Intel Arc и Xe
В master-ветке llama.cpp появилось выделенное Vulkan-ядро Flash Attention для prefill на GPU Intel Arc и Xe. Об этом сообщил автор изменения в r/LocalLLaMA 12 ноября 2026 года, там же приведены таблицы замеров. Пока это master, а не релиз: сборка из исходников и возможные регрессии между коммитами входят в комплект.
Что это даёт на практике: обработка входного промпта на графике Intel ускоряется, и тем сильнее, чем длиннее промпт. Ядро при этом включено не везде, оно активируется только на конкретных архитектурах, а на Arc A770 остаётся выключенным. Шейдеры написаны под нативные матричные формы Intel и разделяемую локальную память SLM, включая m16n16k16 и SIMD32.
Дальше по порядку: чем prefill отличается от decode, таблицы замеров для ARL-H, PTL-H, B70 Pro и B580, сборка с Vulkan и проверка результата, ограничения, история с MQA/MLA и вывод о том, кому обновление реально нужно.
Prefill vs decode: почему ускорение именно в prefill и кому оно важно
Инференс в llama.cpp делится на две фазы. Prefill: модель читает весь промпт сразу, батчем, и считает матричные произведения для всех входных токенов. Decode: выпуск по одному токену, где узкое место обычно пропускная способность памяти, а не арифметика.
Новое ядро ускоряет только prefill. Скорость генерации на выходе (tokens per second) от него напрямую не меняется, и ждать рывка в чате с короткими репликами не стоит.
В замерах используются метки pp8192 и pp16384: это длина промпта в токенах, а t/s показывает, сколько токенов входа GPU обрабатывает за секунду. Чем длиннее вход, тем больше работы приходится на prefill и тем заметнее разница. Время до первого токена в RAG-цепочках, агентских сценариях, суммаризации больших документов и кодинг-ассистентах с объёмным system prompt определяется именно этой фазой.
Похожая история на другом железе: ускорение обработки промптов через ROCm на AMD GPU тоже касалось prefill и тоже требовало обновления до свежих коммитов.
Цифры ускорения: ARL-H, PTL-H, B70 Pro и B580
Замеры в отчёте сгруппированы по платформам, и разброс между ними большой. Все значения ниже взяты из опубликованных таблиц и относятся к конкретным моделям, квантованиям и ОС.
ARL-H, Windows, pp8192
| Модель | Было, t/s | Стало, t/s | Рост |
|---|---|---|---|
| qwen3 8B Q4_K | 126,58 | 415,31 | ~3,3x |
| qwen35 27B Q4_K | 83,38 | 119,95 | ~1,4x |
| qwen35moe 35B.A3B Q4_K | 247,82 | 394,44 | ~1,6x |
| gpt-oss 20B Q4_K | 478,14 | 639,02 | ~1,3x |
PTL-H, Windows, pp8192
| Модель | Было, t/s | Стало, t/s | Рост |
|---|---|---|---|
| qwen3 8B Q4_K | 234,92 | 911,60 | ~3,9x |
| qwen35 27B Q4_K | 194,93 | 264,39 | ~1,4x |
| qwen35moe 35B.A3B Q4_K | 632,12 | 914,80 | ~1,4x |
| gpt-oss 20B Q4_K | 804,70 | 1357,34 | ~1,7x |
B70 Pro, Windows и Linux, pp8192
| ОС | Модель | Было, t/s | Стало, t/s | Рост |
|---|---|---|---|---|
| Windows | qwen3 8B Q4_K | 1064,67 | 2955,83 | ~2,8x |
| Windows | qwen35 27B Q4_K | 659,10 | 932,13 | ~1,4x |
| Windows | qwen35moe 35B.A3B Q4_K | 2088,50 | 3005,11 | ~1,4x |
| Windows | gpt-oss 20B Q4_K | 2311,37 | 3967,29 | ~1,7x |
| Linux | qwen3 8B Q4_K | 783,67 | 1518,19 | ~1,9x |
| Linux | qwen35 27B Q4_K | 497,22 | 647,78 | ~1,3x |
| Linux | qwen35moe 35B.A3B Q4_K | 1060,55 | 1311,62 | ~1,2x |
| Linux | gpt-oss 20B Q4_K | 1237,51 | 1841,35 | ~1,5x |
B580, pp16384, f16 prefill, FA1
| Модель | Было, t/s | Стало, t/s | Прирост |
|---|---|---|---|
| Ling-3.0-tiny (hkv=1) | 76 | 1239 | +1530,3% |
| Gemma4 12B (hkv=1) | 52 | 649 | +1144,2% |
| Gemma4 E4B Q4_K_M | 115,98 | 1156,62 | +897,3% |
| Phi-3.5-mini Q4_K_M | 384,45 | 932,90 | +142,7% |
| Granite 4.2 8B Q4_K_M | 282,67 | 520,98 | +84,3% |
| DeepSeek-R1-Qwen3-8B Q5_K_M | 306,88 | 559,34 | +82,3% |
| Ministral-3-8B Q5_K_M | 324,17 | 590,91 | +82,3% |
| Llama 3.1 8B Q4_K_M | 347,79 | 633,73 | +82,2% |
| Qwen3.5-9B Q6_K | 687,50 | 979,49 | +42,5% |
| Gemma3 4B Q4_1 | 1414,61 | 1948,23 | +37,7% |
| Granite 4.0-h-tiny Q4_K_M | 2503,03 | 2927,33 | +16,95% |
Как читать эти цифры. Диапазон 1,4-3,9 раза на pp8192 держится на четырёх моделях и трёх платформах, это обобщение, а не единый коэффициент. «До 15 раз» относится к отдельным моделям на B580 при pp16384, где Ling-3.0-tiny дал рост с 76 до 1239 t/s, а Gemma4 12B - с 52 до 649 t/s. Обе модели с одной KV-головой, и именно они дали самый большой относительный скачок.
Обратная сторона: у Granite 4.0-h-tiny прирост всего 16,95%, а границы замеров на B580 сняты в отдельном режиме (f16 prefill, FA1, pp16384), поэтому напрямую сравнивать их с таблицей pp8192 нельзя. Экстраполировать эти числа на модели, которых в таблицах нет, тоже не стоит.
Отдельно про железо: B70 32GB против RTX 5090 в локальных LLM - о том, какую скорость генерации и prefill даёт карта Intel за пятую часть цены.
Почему это работает: SLM, m16n16k16 и SIMD32 простыми словами
SLM (Shared Local Memory) - небольшая быстрая память внутри Xe-ядра, доступная всем потокам рабочей группы. Её удобно держать как кэш для тайлов матриц: данные загружаются один раз и переиспользуются десятки раз, без походов в общую память.
m16n16k16 - нативная форма матричного блока, 16 на 16 на 16, под которую рассчитаны матричные блоки XMX в GPU Intel. Когда тайлы шейдера совпадают с этой формой, железо считает без лишних перестановок и выравниваний.
SIMD32 - ширина исполнения: 32 потока выполняют одну инструкцию. Шейдер, рассчитанный на такую ширину, реже простаивает на ветвлениях и полнее загружает вычислительные блоки.
Прежний generic Vulkan-путь эти особенности не учитывал. Аналогия простая: generic-ядро раскладывает данные так, как удобно компилятору, а новое ядро - по форме конкретного железа. Имена функций и структуру файлов автор изменения не раскрывает, поэтому деталей реализации в разборе нет.
Как включить Vulkan-ядро Flash Attention в llama.cpp: пошаговая инструкция
Отдельного переключателя для нового ядра в отчёте не описано. Схема штатная: собрать master с Vulkan-бэкендом и включить Flash Attention. Синтаксис флагов сверяйте с документацией и --help своей сборки, проект меняет CLI от версии к версии.
- Обновитесь до актуального master:
git pullв клоне репозитория. Релиза с этим ядром на момент публикации нет. - Соберите проект с Vulkan: базовая опция CMake
-DGGML_VULKAN=ON. Нужны Vulkan SDK и свежий драйвер Intel с поддержкой Vulkan. - Убедитесь, что бэкенд видит нужную карту: в логе при старте или через флаг
--list-devices(набор флагов зависит от версии) должен появиться ваш Arc или Xe нужного поколения. - Включите Flash Attention при запуске: в большинстве сборок это
-faили--flash-attn. Доступные значения смотрите в--help. - Измерьте prefill на своей модели:
llama-bench -p 8192, для B580 имеет смысл-p 16384. Сравните результат с прогоном без FA.
Если карта не входит в список поддерживаемых архитектур, ядро не подключится само. Ручное включение через правку кода автор изменения не предлагает и стабильности на неподдерживаемых чипах не обещает. У владельцев Intel есть и второй путь: рефакторинг XMX в SYCL-бэкенде ускорил speculative decoding на Arc B70 и работает независимо от Vulkan-ядра.
Ограничения и подводные камни: A770, нестабильность и совместимость
Главное ограничение: ядро включено только для конкретных архитектур, а на Arc A770 остаётся отключённым из-за нестабильных результатов тестов. Формулировка важна: нестабильность означает непредсказуемость, а не низкую скорость. На одних прогонах счётчик может показать красивые цифры, на других - ошибки или просадки, поэтому по умолчанию выключено.
master-ветка добавляет свои риски: регрессии, ломающие изменения интерфейса, необходимость пересборки после обновления. Драйвер Intel с актуальной поддержкой Vulkan обязателен, на старых версиях поведение не гарантировано.
Разница ОС заметна. На B70 Pro под Windows qwen3 8B ускорилась в 2,8 раза, под Linux - в 1,9 раза, и это при том, что абсолютные значения на Windows выше. Причину такого расхождения источник не объясняет, ссылаться на драйверы как на единственный фактор было бы догадкой.
Сроков включения ядра на A770 нет, обещаний по ним тоже. Планировать апгрейд под этот апдейт не стоит.
MQA и MLA: почему ускорение теперь касается моделей с одной KV-головой
MQA (Multi-Query Attention) и MLA (Multi-head Latent Attention) - варианты внимания, где KV-голова одна или сильно сжата. Форма тензоров у них отличается от классического MHA, и такие модели раньше могли выпадать из оптимизированного пути: быстрое ядро просто не запускалось на их конфигурации.
Доработки бэкенда в том же обновлении распространяют ускорение на модели с одной KV-головой, включая MQA и MLA. Именно этим объясняется всплеск на B580: Ling-3.0-tiny (hkv=1) выросла с 76 до 1239 t/s, Gemma4 12B (hkv=1) - с 52 до 649 t/s, тогда как обычные модели того же размера прибавили 40-140%.
Практический вывод: смотрите на конфигурацию внимания своей модели, а не только на название архитектуры. Модели с одной KV-головой получают от нового ядра больше, чем можно предположить по их размеру.
Стоит ли обновляться: практический вывод для владельцев Intel Arc
Польза ощутима, если вы гоняете длинные промпты от 8K токенов на B580, B70 Pro, ARL-H или PTL-H: RAG с большими вставками, агенты с длинной историей, суммаризация документов, кодинг с объёмным контекстом. Там prefill заметен в общем времени ответа.
Разница не критична при коротких промптах и нагрузке, упирающейся в decode: скорость генерации ядро не меняет. Владельцам A770 ждать нечего, а тем, кто не готов собирать master и отлаживать регрессии, логичнее дождаться релизной сборки.
Чек-лист перед обновлением:
- проверьте, что ваша карта относится к поддерживаемым архитектурам Xe;
- обновите драйвер Intel и Vulkan SDK;
- соберите master с
-DGGML_VULKAN=ON, запустите с включённым Flash Attention; - прогоните
llama-bench -p 8192на своих моделях и квантованиях, сравните с baseline; - сохраните рабочую сборку, к которой можно откатиться.
Замеры из отчёта получены на конкретных платформах и моделях, гарантии для вашей конфигурации они не дают. Тестировать нужно на своих весах и своей длине промпта; что именно мерить в pp и decode, мы разбирали в материале про локальные модели на 2×RTX 5080 и 128 ГБ RAM, логика метрик там та же.