llama.cpp виправив аварії Qwen3 у Vulkan: що змінилося в тестовій збірці b10839

У тестовій збірці llama.cpp b10839 виправлено аварійне завершення Vulkan-backend під час запуску деяких мультимодальних і голосових моделей Qwen3. Проблема виникала в операції GET_ROWS, коли тензор був представленням іншого буфера, а його фактичне зміщення не відповідало вимозі minStorageBufferOffsetAlignment. Замість жорсткого падіння розробники навчили backend правильно враховувати зміщення як для звичайних, так і для квантованих тензорів.

Де проявлялася помилка

У release notes наведено конкретний сценарій відтворення: запуск llama-tts із GGUF-моделлю Qwen3-TTS, окремим мультимодальним проєктором і майже повним перенесенням шарів на GPU. Аналогічний шаблон буферів зустрічається у Qwen3-VL. Такі моделі створюють зрізи KV-cache та інші представлення тензорів із ненульовим view_offs. Старий Vulkan-код припускав вирівнювання, якого в цьому випадку не було, після чого спрацьовував GGML_ASSERT.

Це не означає, що кожен користувач Qwen3 стикався з падінням. Помилка залежала від backend, типу операції, схеми тензора, квантизації та розташування даних у буфері. CPU або інший GPU-backend міг поводитися інакше. Саме тому виправлення важливе для тих, хто локально запускає TTS чи vision-language моделі через Vulkan на Windows або Linux.

Чому простого переходу на CPU було недостатньо

Перший варіант зміни пропонував повертати false із supports_op() і передавати проблемний GET_ROWS на CPU. Це прибирало падіння, але створювало потенційно дорогий перехід між GPU та CPU. Для генерації голосу або обробки зображення така межа може збільшити затримку й копіювання пам’яті.

Фінальне рішення залишає операцію на Vulkan. Код прив’язує буфер до вирівняної позиції біля потрібного представлення, а точне зміщення передає через push constants. Допоміжна функція шукає мінімальне значення, кратне одночасно вимогам Vulkan і розміру типу. Це особливо важливо для блокових квантованих форматів, де просте ділення зміщення могло втратити частину байтів.

Виправлено і дискретні GPU, і UMA

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

Нова функція ggml_vk_tensor_physical_offset дає обом режимам одну основу для розрахунків. Це не обіцянка однакової швидкості на всіх GPU, а усунення розбіжності у визначенні адреси. У release notes також згадано корекцію структури gated_linear_attn і зміни перевірки підтримки операцій для OpenVINO та WebGPU.

Що саме перевірили

До backend-тестів додали представлення з ненульовим зміщенням для F32, F16, Q4_0, Q4_K, Q8_0 та I32. Перевіряються квантовані й неквантовані шляхи, різні розміри другого виміру та варіанти з view-тензорами. Автори повідомляють про успішне проходження всіх 223 тестів GET_ROWS на NVIDIA GeForce RTX 5060 Ti.

Один успішний GPU не доводить відсутність регресій на інших драйверах. У Vulkan поведінка залежить від значення вирівнювання, моделі пам’яті та компілятора shader. Користувачам AMD, Intel, мобільних або інтегрованих GPU варто перевіряти власну конфігурацію, особливо якщо застосунок використовує довгі контексти чи мультимодальний проєктор.

Як безпечно перевірити збірку

• Пам’ятати, що b10839 позначена як попередня тестова збірка, а не стабільний реліз із довгим циклом підтримки.
• Зафіксувати той самий GGUF, параметри -ngl, драйвер і довжину контексту до та після оновлення.
• Повторити TTS або vision-запит кілька разів і перевірити не лише відсутність crash, а й правильність результату.
• Порівняти швидкість, використання VRAM/RAM та кількість переходів на CPU.
• Для production зберегти попередній binary та виконати canary-тест на невеликій частині задач.

Практичний висновок: b10839 корисна насамперед користувачам Qwen3-TTS і Qwen3-VL на Vulkan, які бачили assert у GET_ROWS. Зміна виправляє адресацію тензорних представлень замість маскування проблеми повільним CPU-fallback, але тестовий статус збірки вимагає перевірки на конкретному обладнанні.

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

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