llama.cpp прискорює DeepSeek‑V4 у Vulkan завдяки об’єднаним GPU-операціям

У тестовій збірці llama.cpp b10844 з’явилися спеціалізовані Vulkan-операції для hyper-connections у DeepSeek‑V4. Замість виконання довгого ланцюга дрібних primitive operations графічний backend об’єднує роботу в три kernels: DSV4_HC_COMB, DSV4_HC_PRE і DSV4_HC_POST. За даними розробника, саме unfused-ланцюг Sinkhorn у моделі DeepSeek‑V4‑Flash забирав близько 32% часу decode-операцій на AMD Strix Halo.

Де виникало вузьке місце

DeepSeek‑V4 використовує hyper-connections, які складніше за звичайний residual-зв’язок розподіляють потік даних між гілками мережі. На Vulkan обчислення виконувалися як послідовність універсальних вузлів. Для однієї ділянки comb це означало приблизно 137 строго впорядкованих запусків, а протягом генерації — близько 16 тисяч dispatch на один token у наведеному розробником сценарії.

GPU добре працює з великими паралельними блоками, але кожний окремий dispatch має накладні витрати: підготовку, синхронізацію, читання проміжних даних і перехід до наступного kernel. Коли корисна математика невелика, а таких кроків тисячі, драйвер і memory traffic можуть коштувати більше, ніж самі арифметичні операції.

Що робить fusion

dsv4_hc_comb виконує повний 20-ітераційний Sinkhorn усередині регістрів. Матриця 4×4 для одного token розміщується у 16 сусідніх lanes subgroup, а операції shuffle скорочують рядки й стовпці без запису кожного проміжного результату в глобальну пам’ять. За subgroup size 64 одночасно вміщуються чотири незалежні token.

Операції pre і post обробляють згортання та розгалуження потоків навколо основної матриці, а коефіцієнти для token зберігаються у shared memory. Таким чином backend скорочує кількість dispatch і бар’єрів, не змінюючи математичну семантику моделі.

Чому це важливо саме для Vulkan

CUDA отримала ці спеціалізовані операції разом із підтримкою DeepSeek‑V4, а Metal — в окремій попередній зміні. Vulkan залишався останнім із великих backend, що виконував unfused primitive chain. Це особливо відчутно на інтегрованій графіці та спільній пам’яті, де локальні LLM запускають без окремої серверної NVIDIA-карти.

Водночас цифра 32% описує частку часу конкретної decode-операції на gfx1151, а не гарантоване прискорення всього застосунку на 32%. Загальна швидкість залежить від quantization, розміру моделі, довжини контексту, memory bandwidth, batch size, shader compiler і частки інших operators. На іншій GPU вузьке місце може бути зовсім іншим.

Як реалізацію можна перевіряти

У зміну додано eval cases із виробничим значенням n_iter=20 для batch sizes, що перетинають межі subgroup і workgroup. Це важливо: помилка в lane mapping може проявлятися лише тоді, коли дані перестають поміщатися в одну групу. Розробники також прибрали тимчасові per-op перемикачі після code review та спростили умови підтримки, спираючись на гарантії stride у ggml.

Для незалежної перевірки потрібно порівнювати не лише tokens per second, а й logits або вихід моделі в однакових умовах. Fusion змінює порядок низькорівневих обчислень, тому невеликі floating-point відмінності можливі; важливо переконатися, що вони не накопичуються до зміни якості відповіді.

Що робити користувачу

• Пам’ятати, що b10844 — попередня тестова збірка, а не стабільний реліз.
• Зафіксувати модель, quantization, prompt, seed, context і параметри GPU-offload.
• Оновити драйвер Vulkan та зберегти попередній binary для швидкого відкату.
• Зняти prefill і decode окремо: fusion стосується конкретної частини decode-графа.
• Контролювати температуру, частоти й memory pressure, щоб короткий benchmark не створив хибну перевагу.
• Перед production прогнати довгі діалоги й batch-навантаження, а не лише одиночний prompt.

Обмеження й контекст

Зміна орієнтована на конкретну архітектуру DeepSeek‑V4 та її hyper-connection operators. Вона не прискорює автоматично всі Llama-, Qwen- чи Mistral-сумісні моделі. Не можна також переносити результат зі Strix Halo на будь-яку AMD, Intel або мобільну GPU без вимірювання. Цінність релізу — в усуненні очевидного структурного bottleneck і вирівнюванні можливостей Vulkan із CUDA та Metal.

Практичний висновок: b10844 показує, наскільки продуктивність локальної AI-моделі залежить не лише від quantization чи потужності GPU, а й від форми обчислювального графа. Об’єднання сотень дрібних кроків у кілька kernels може бути важливішим за загальну оптимізацію одного математичного блока.

Джерело та права

Матеріал є самостійним українським перекладом-переказом офіційних release notes тестової збірки llama.cpp b10844, опублікованих 7 вересня 2026 року. Вихідний текст, код і документація репозиторію поширюються за ліцензією MIT. Перекладено й адаптовано редакцією «Бібліотеки програміста». Обкладинка створена редакцією за допомогою AI і не входить до першоджерела.