Локальна вайфу на AMD Polaris: Як запустити ШІ на RX 470, коли ROCm мертвий

На мій подив, матеріал про запуск Stable Diffusion WebUI на старих відеокартах AMD RX викликав певний інтерес серед ентузіастів, а це означає, що власники Polaris все ще намагаються змусити свої GPU виходити за межі, встановлені компанією AMD. Що ж, час перейти до більш хардкорної частини «виживання» на старенькій GCN у 2026 році.

У даному матеріалі ми розглянемо запуск LLM на відеокартах Radeon RX 470 4GB і RX 470 8GB. Причому, це будуть не якісь «крихітки» на зразок застарілих моделей з параметрами 0.5B, або 1B. Ми візьмемо класичну зв'язку з найпопулярніших LLM з параметрами 4B, «8B» і 12B та перевіримо, що з цього буде швидко, а головне стабільно працювати на кожній з піддослідних відеокарт.

Для початку, давайте зафіксуємо вхідні дані. Я проводив свої експерименти на Linux Mint (Debian-based дистрибутив) і KoboldCPP (локальний open‑source сервер для запуску великих мовних моделей), а тестовий стенд виглядав наступним чином:

• Xeon E5-2640 v4;

• 16 GB DDR4 2133 MHz;

• Radeon RX 470 4GB, Radeon RX 470 8GB, Radeon RX R9 270X 4GB;

У даному випадку вибір операційної системи не є критичним фактором. Якщо ви не готові переходити на Linux, ви втратите лише 5–10% у швидкості генерації, але в іншому логіка роботи LLM і налаштування KoboldCPP залишаться ідентичними.

Другий важливий момент: всі тестові відеокарти працювали як додаткові прискорювачі. Це дозволило уникнути впливу операційної системи та браузера на обсяг доступної відеопам'яті. Вся VRAM тестового адаптера була повністю віддана під потреби нейромережі, що варто враховувати, якщо ви плануєте запускати LLM на єдиній відеокарті в системі.

Третій, і не менш важливий момент: ваша відеокарта повинна підтримувати API Vulkan і мати як мінімум 4 ГБ відеопам'яті (хоча у мене для вас припасений сюрприз і для карт на 2 ГБ). Підтримкою Vulkan наділені майже всі адаптери AMD на архітектурах GCN 1.0, 2.0 і 4.0.

Однак є нюанс в обсязі VRAM. Карти серії Radeon HD 7000 в більшості своїй обмежені 2-3 ГБ, чого катастрофічно мало для рушія KoboldCPP. У підсумку: нам підходять моделі з 4 ГБ+ VRAM, починаючи з Radeon R9 270X 4GB (перевірено особисто, результати будуть трохи нижче), і закінчуючи народними RX 470/580, а також Vega 56/64, і, очевидно, Radeon VII з її 16 ГБ HBM2. (280/285/290X/370/380/390X теж підійдуть, як і 6-гігабайтна HD 7970, але це рідкісна тваринка, так що…). Але уточню відразу: вкрай бажано мати 8 ГБ і більше. На такому обсязі робота через Vulkan йде відчутно швидше, а головне — стабільніше.

Системні вимоги та необхідне програмне забезпечення

Для початку переконайтеся, що ви виконали всі вимоги для успішного запуску KoboldCPP з бекендом Vulkan. Завантажте з офіційного репозиторію GitHub необхідні файли: koboldcpp.exe для Windows або koboldcpp-linux-x64 для Linux.

Не варто перейматися вибором між CUDA і noCUDA версіями. Я використовую повноцінний бінарник з підтримкою CUDA, і він чудово працює з усіма іншими API, включно з потрібним нам Vulkan.

Мінімальні системні вимоги:

• Операційна система: Linux (можна і Windows 10/11, але не бажано);

• Обсяг оперативної пам'яті: 16 ГБ і більше (перевіряв і на 8 ГБ - працює, але очевидно, що плавного досвіду чекати не варто);

• Процесор: 4-ядерний чіп Intel Core i5-2400, чи AMD FX-4300 або кращий (наявність інструкцій AVX, хоча б першого покоління - обов'язкова, AVX2 - ідеально);

• Відеокарта: Radeon R9 270X 4 ГБ, Radeon RX 470 4 ГБ або сучасніша, з підтримкою API Vulkan;

• Накопичувач (бажано SSD, але швидкісний HDD теж підійде): від 10 ГБ вільного місця для сервера і однієї моделі, до запаморочливих обсягів в 300 ГБ+. Все залежить від того, скільки чекпоінтів/моделей ви збираєтеся використовувати.

Налаштування KoboldCPP

Завантажили необхідну версію? Чудово. Тепер перейдемо до налаштування. Я, як уже сказав вище, описуватиму свій шлях на Linux, а ви просто пропускайте ті кроки, які вам не потрібні, з огляду на вашу ОС.

Системний рівень (Оптимізація заліза)

Цей розділ - фішка Linux.

• OMP_PROC_BIND=TRUE / OMP_PLACES=cores - Прив'язує обчислення до конкретних ядер. Процесор перестає «перекидати» завдання між ядрами, що усуває зайві затримки;

• numactl --physcpubind=0-9 / taskset -c 0-9 - Жорстке обмеження. Ми виділяємо нейромережі конкретні 10 ядер (у моєму випадку! Якщо у вас ФІЗИЧНИХ ядер 6, то пишемо 0-5!) і забороняємо їй чіпати інші;

• RADV_PERFTEST=aco / VKD3D_CONFIG=upload_hvv - Тюнінг для відеокарт AMD. Прискорює компіляцію шейдерів і передачу даних у відеопам'ять (VRAM). ЦЕЙ ПАРАМЕТР тільки для Linux OC!

Параметри рушія (KoboldCPP)

А ось тут вже дивимося всі, як користувачі Linux, так і Windows.

• --usevulkan 1: Використання графічного рушія Vulkan для прискорення на відеокарті (альтернатива CUDA\ROCm);

• --gpulayers 999: безкомпромісна команда «все в пам'ять GPU!». Цифра 999 гарантує, що всі шари моделі підуть у відеопам'ять, якщо там вистачить місця. Важливий нюанс: якщо рушій вилітає з помилкою або генерація перетворюється на «слоу-мо» (швидкість падає до 0,1–0,3 t/s), значить, VRAM закінчилася і модель почала використовувати повільну оперативну пам'ять (ОЗУ). У такому випадку дізнайтеся загальну кількість шарів вашої моделі (зазвичай це 32–33 для 4-8B моделей) і експериментально зменшуйте їх кількість. Наприклад, якщо в моделі 33 шари, спробуйте виставити --gpulayers 28, або менше;

• --threads 8: Кількість виділених потоків процесора. Оптимально залишати пару ядер вільними під потреби системи. У мене 10 ядер, 20 потоків. Потоки не враховуються - для нейромережі це сміття. Отже, у нас всього 10 ядер. Залишаючи від них 2, ми дозволяємо системі працювати стабільно. Якщо у вас 6 ядер, пишемо --threads 4 або 5. Тут вже самі тестуйте;

• --batchsize 1024: Розмір «пакета» даних. Більша цифра прискорює обробку довгого промпта на початку діалогу. Це КРИТИЧНО важливий параметр для GPU, заснованого на архітектурі GCN, причому, за моїми спостереженнями, будь-якої версії. Обчислювальні блоки (CU) Polaris часто залишаються недовантаженими, і щоб це виправити та підвищити ефективність генерації, ми забиваємо їх під зав'язку.

Налаштування «Пам'яті» та Контексту

Ось тут увага! Не пропускайте цей розділ і заглибтеся в його зміст. «Контекст» нейромережі, це БУКВАЛЬНО її АКТУАЛЬНА пам'ять. Іншими словами - все ваше листування з нейронкою зберігається в контексті, і від його розміру залежить, чи згадає вона те, що ви їй говорили годину тому і що взагалі відбувається в середовищі вашого спілкування! У контекст потрапляють як ВАШІ повідомлення нейронці, так і ЇЇ. Що критично завантажує його місткість.

Контекст — це буквально фундамент усього, чого ми намагаємося досягти від нейромережі. Будь то «локальна вайфу», «співавтор», «звичайний співрозмовник», «перекладач» тощо.

Але він не безкоштовний (коли ви на своєму локальному ПК, він, звичайно, безкоштовний, але не для вашої відеокарти). Контекст займає місце в і без того крихітному відеобуфері вашої відеокарти, особливо, якщо у вас всього 4 ГБ! Проста математика: якщо модель важить 3 ГБ, то її контекст на 4000 токенів у нестисненому вигляді від'їсть ще близько 500–600 МБ. Додайте сюди оверхед драйвера і API Vulkan — і все. 4 ГБ забиті наглухо!

• --contextsize 8192: Обсяг пам'яті діалогу. 8k токенів — це приблизно 10-15 сторінок тексту, які нейронна мережа тримає в пам'яті. ЦЯ ЦИФРА не повинна бути у вас вписана залізобетонно! Все залежить від використовуваної вами моделі та її квантування! Трохи далі я намагатимуся пояснити, як саме розподілити решту відеопам'яті під потреби контексту;

• --quantkv 2 (Q4 стиснення контексту з відносно невеликою втратою достовірності/точності оповіді/діалогу): Стискає дані про поточний діалог у 3-4 рази. Дозволяє економити сотні мегабайт відеопам'яті майже без втрати сенсу. Якщо з розміром контексту ще можна «погратися», то --quantkv 2 - догма для обсягу відеопам'яті в 4-8 ГБ.

Теоретичний розрахунок споживання відеопам'яті (VRAM) для моделі + вікна контексту

Тут я провів теоретичний розрахунок для умовної зв'язки: Модель в квантуванні Q3_K_M (далеко не ідеал, але працювати і спілкуватися з такою моделлю можна, перевірено особисто неодноразово) + Контекст 8k в Q4 (--quantkv 2) + Системний оверхед від драйверів і Вулкана.

Для кванта Q4_K_M ситуація дещо погіршується, але все ще залишиться реалістичною, хоча для 12B і знаходиться на межі:

Сподіваюся, ви змогли простежити логіку. Тепер перейдемо до практики.

Рушаємо?

В якості системного промпта, я сам написав наступне:

Якщо мій промпт вам сподобався (в чому я сумніваюся) - не соромтеся копіювати його! Саме він був використаний для тестування всіх LLM і відеокарт.

Radeon HD 7870 2GB

Почнемо, мабуть, з екзотики. Чи можна змусити вашу запорошену Radeon HD 7870 на мізерні 2 ГБ запустити сучасну нейромережу? Відповідь — звичайно! Однак необхідно бути реалістами: ні про які величезні моделі тут не йдеться. 2 ГБ - це не просто мало, це мізерний обсяг для актуальних мовних моделей. Проте, ми можемо взяти крихітку з відмінним квантом q8. Наприклад, gemma-3-1b-it-abliterated-v2.q8_0.gguf з такими параметрами запуску:

Linux

ADV_PERFTEST=boltzmann,noconflicthwm ./koboldcpp --model gemma-3-1b-it-abliterated-v2.q8_0.gguf --usevulkan 1 --gpulayers 999 --threads 6 --blasthreads 6 --batchsize 1024 --context 4096 --quantkv 2 --launch

Windows (далі не згадуватиметься, оскільки все, що вам потрібно зробити, це взяти ім'я екзеншника «koboldcpp.exe», а також мою команду, починаючи з прапора --model, і поєднати їх).

koboldcpp.exe --model gemma-3-1b-it-abliterated-v2.q8_0.gguf --usevulkan 1 --gpulayers 999 --threads 6 --blasthreads 6 --batchsize 1024 --contextsize 4096 --quantkv 2 --launch

І отримати на початку контекстного вікна 40 т/с:

Processing Prompt [BATCH] (47 / 47 tokens)Generating (224 / 896 tokens)(EOS token triggered! ID:106)[17:09:26] CtxLimit:634/4096, Amt:224/896, Init:0.01s, Process:0.00s (15666.67T/s), Generate:5.55s (40.37T/s), Total:5.55s

І в кінці, на буквальному стрес-тесті в контекст-шифтингу (зрізанні частини старого контексту, щоб вмістити нові повідомлення) близько 35 т/с:

[Context Shifting: Erased 299 tokens at position 106]Processing Prompt [BATCH] (44 / 44 tokens)Generating (642 / 896 tokens)(EOS token triggered! ID:106)[17:24:44] CtxLimit:3841/4096, Amt:642/896, Init:0.12s, Process:0.09s (494.38T/s), Generate:17.94s (35.79T/s), Total:18.03s

Вам нагадати, скільки цій відеокарті років? Вона вийшла в березні 2012 року. І сьогодні, через 14 років, вона видає швидкість генерації тексту, яка в кілька разів перевищує швидкість людського читання. Чи це не найкраща відповідь тим, хто каже, що для ШІ потрібні тільки новітні RTX?

Проте давайте будемо реалістами до кінця. «Мозок» моделі 1B — це не те, з чим ви зможете довго, а головне — різноманітно базікати після важкого дня. Це скоріше… просто цікавий експеримент. Тим не менш, я все ж вставлю сюди свій холодний розрахунок: Вайфу на 1B - ні, але з агресивним промптопом і низькою температурою, навіть ця «крихітка» на 1 мільярд параметрів стане гарним локальним перекладачем.

Radeon R9 270X 4GB

Зізнаюся чесно, відчувши 4 ГБ, мене відразу ж потягнуло випробувати найважчу модель із сімейства 4B, а саме huihui-ai_Huihui-gemma-3n-E4B-it-abliterated у кванті Q3_K_M. Ймовірно, ті, хто хоча б трохи розбираються у всіх тонкощах неймінгу LLM, вже встигли жахнутися. Так, це саме вона — MatFormer-модель, яка при реальних 8 мільярдах параметрів вміщується в ~3 ГБ пам'яті.

Навіщо? Тому що просто можу і мені було цікаво. Але не будемо відволікатися і почнемо. Параметри запуску наступні:

ADV_PERFTEST=boltzmann,noconflicthwm ./koboldcpp --model huihui-ai_Huihui-gemma-3n-E4B-it-abliterated-Q3_K_M  --usevulkan 1 --gpulayers 999 --threads 6 --blasthreads 6 --batchsize 1024 --context 4096 --quantkv 2 --launch

І, на жаль, відразу ж закінчимо, оскільки дістатися до кінця контекстного вікна я не наважився через дуже повільний т/с в районі 4:

Processing Prompt [BATCH] (117 / 117 tokens)Generating (408 / 896 tokens)(EOS token triggered! ID:106)[17:56:03] CtxLimit:525/4096, Amt:408/896, Init:0.01s, Process:0.02s (4875.00T/s), Generate:95.63s (4.27T/s), Total:95.65s

Але досить знущатися над старенькою 270X, повернемося до класичної gemma-3-4b-it-abliterated-v2 з відмінним квантом q4_k_m. Параметри запуску:

ADV_PERFTEST=boltzmann,noconflicthwm ./koboldcpp --model gemma-3-4b-it-abliterated-v2.q4_k_m
 --usevulkan 1 --gpulayers 999 --threads 6 --blasthreads 6 --batchsize 1024 --context 4096 --quantkv 2 --launch

Підсумкові 19 т/с на початку контекстного вікна:

Processing Prompt (27 / 27 tokens)Generating (453 / 896 tokens)(EOS token triggered! ID:106)[17:59:42] CtxLimit:896/4096, Amt:453/896, Init:0.01s, Process:0.07s (385.71T/s), Generate:22.81s (19.86T/s), Total:22.88s

І, давайте будемо відверті - вражаючі для такої відеокарти 13 т/с в кінці при зрізанні частини контексту:

[Context Shifting: Erased 64 tokens at position 106]Processing Prompt (23 / 23 tokens)Generating (261 / 896 tokens)(EOS token triggered! ID:106)[18:08:02] CtxLimit:3460/4096, Amt:261/896, Init:0.10s, Process:0.43s (53.86T/s), Generate:18.79s (13.89T/s), Total:19.21s

Крім того, що gemma-3-4b-it-abliterated-v2.q4_k_m в цілому непогана, і з нею вже можна вести конструктивний діалог, так ще й швидкість генерації навіть при заповненні контексту досить непогана! Що таке 13 токенів в секунду? Це швидкість, з якою Діна не просто відповідає, а «промовляє» свої думки трохи швидше, ніж ви встигаєте їх читати. І все це відбувається локально, без цензури і хмарних підписок, на залізі, яке багато хто вже списав на брухт.

Radeon RX 470 4GB

Якщо ви раптом подумали: «Ага, ймовірно, MatFormer моделі це не для 4 ГБ. Навряд чи моя старенька рикса впорається з нею». То ви помиляєтеся. Представляю вашій увазі, знову, huihui-ai_Huihui-gemma-3n-E4B-it-abliterated в кванті Q3_K_M, але тепер на Полярісі!

Параметри запуску:

OMP_PROC_BIND=TRUE OMP_PLACES=cores RADV_PERFTEST=aco VKD3D_CONFIG=upload_hvv numactl --physcpubind=0-9 --membind=0 taskset -c 0-9 ./koboldcpp-linux-x64 --model huihui-ai_Huihui-gemma-3n-E4B-it-abliterated-Q3_K_M.gguf --usevulkan 1 --gpulayers 999 --blasbatchsize 1024 --contextsize 4096 --quantkv 2 --threads 6 --port 5002

17 т/с на початку контекстного вікна:

Processing Prompt (23 / 23 tokens)Generating (238 / 896 tokens)(EOS token triggered! ID:106)[18:26:23] CtxLimit:596/4096, Amt:238/896, Init:0.09s, Process:0.02s (1437.50T/s), Generate:13.38s (17.79T/s), Total:13.40s

Та 16 т/с наприкінці при зрізі:

[Context Shifting: Erased 389 tokens at position 336]Processing Prompt (21 / 21 tokens)Generating (468 / 896 tokens)(EOS token triggered! ID:106)[18:36:13] CtxLimit:3667/4096, Amt:468/896, Init:0.22s, Process:0.03s (677.42T/s), Generate:28.36s (16.50T/s), Total:28.39s

Ще раз нагадаю, це не звичайна Гемма 3, яка літала на 270Х, це та, що видавала на ній 4 т/с. І так, вона буквально ширяє на RX 470 4GB. За моїми суб'єктивними дослідженнями (спілкування, подорожі тощо), gemma-3n-E4B (яка лише прикидається 4B, а насправді є жорстко упакованою 8B) знищує звичайну gemma-3-4b.

І тут уважний читач, ймовірно, вже помітив одну важливу річ і, по суті, недолік карт з низьким об'ємом відеопам'яті. Так, все вірно: з обмеженням контексту в 4К ваша умовна «Вайфу» буде часто забувати свої ж репліки або ваші повідомлення. На жаль, але на 4 ГБ — це факт.

Але у нас ще є 8 ГБ - карта, яка зараз коштує трохи більше 50 баксів (а майнінг версії і того дешевше, хоча вони вже відпрацювали своє, і я б їх не радив до покупки). Переходимо до важкої артилерії Поляріса.

Radeon RX 470 8 GB

Почнемо з мого фаворита. Вибачте, я спеціально водив вас за ніс цими горезвісними 8К контексту. Ви готові до справжнього «м'яса»? Поїхали!

Модель MN-Violet-Lotus-12B.i1 в айматрикс (i-matrix) кванті IQ3_M! Тепер найцікавіше, параметри запуску:

OMP_PROC_BIND=TRUE OMP_PLACES=cores RADV_PERFTEST=aco,noatc numactl --physcpubind=0-9 --membind=0 taskset -c 0-9 ./koboldcpp-linux-x64 --model MN-Violet-Lotus-12B.i1-IQ3_M.gguf --usevulkan 1 --gpulayers 999 --blasbatchsize 1024 --contextsize 16384 --quantkv 2 --threads 6 --port 5002 --no-mmap

Очі вас не підводять. Так, тут дійсно цілих 16К контексту! Без вивантаження шарів в оперативну пам'ять і без галюцинацій (у будь-якому випадку серйозних я не помічав, а я провів купу часу в тестах, щоб це було об'єктивно).

Початок контексту - 16 т/с:

Processing Prompt (1 / 1 tokens)Generating (405 / 896 tokens)(EOS token triggered! ID:2)[13:13:47] CtxLimit:3822/16384, Amt:405/896, Init:0.08s, Process:0.00s (250.00T/s), Generate:24.84s (16.31T/s), Total:24.84s

Кінець 16к + зріз - 11 т/с:

[Context Shifting: Erased 231 tokens at position 380]Processing Prompt (28 / 28 tokens)Generating (389 / 896 tokens)(EOS token triggered! ID:2)[13:47:33] CtxLimit:15876/16384, Amt:389/896, Init:0.76s, Process:0.16s (175.00T/s), Generate:35.27s (11.03T/s), Total:35.43s

Чи потрібно казати, що при використанні 12B моделі, та ще й з найважчим для обробки квантом IQ3_M це приголомшливий результат? А якщо абстрагуватися від цифр, то спілкування з такою моделлю виглядає максимально живим і яскравим!

Тепер залишилося лише відповісти на останнє питання в даному матеріалі: якщо я назвав квант IQ3_M найважчим, то, ймовірно, класика у вигляді Q4_K_M видасть більшу швидкість генерації? Безумовно! Але ви втратите в пам'яті моделі - того самого, горезвісного контексту. Сама модель Q4_K_M важить набагато більше, таким чином, ми будемо обмежені лише 8К. Але навіщо я це описую, якщо можу просто навести дані?

MN-Violet-Lotus-12B.Q4_K_M.gguf з параметрами:

OMP_PROC_BIND=TRUE OMP_PLACES=cores RADV_PERFTEST=aco,noatc numactl --physcpubind=0-9 --membind=0 taskset -c 0-9 ./koboldcpp-linux-x64 --model MN-Violet-Lotus-12B.Q4_K_M.gguf --usevulkan 1 --gpulayers 999 --blasbatchsize 1024 --contextsize 8196 --quantkv 2 --threads 6 --port 5002 --no-mmap

Логічно і передбачувано, легкий квант видає на старті 18 т/с:

Processing Prompt (1 / 1 tokens)Generating (127 / 896 tokens)(EOS token triggered! ID:2)[13:59:08] CtxLimit:788/8196, Amt:127/896, Init:0.05s, Process:0.01s (200.00T/s), Generate:7.00s (18.14T/s), Total:7.00s

І в кінці, на зрізі 12 т/с:

[Context Shifting: Erased 206 tokens at position 380]Processing Prompt [BATCH] (366 / 366 tokens)Generating (874 / 896 tokens)(EOS token triggered! ID:2)[14:18:28] CtxLimit:8173/8196, Amt:874/896, Init:0.35s, Process:0.10s (3734.69T/s), Generate:68.52s (12.76T/s), Total:68.62s

Чи варта трохи вища точність і швидкість моделі її пам'яті? На мій погляд, ні. За моїми суб'єктивними спостереженнями, MN-Violet-Lotus-12B.Q4_K_M.gguf виграє у MN-Violet-Lotus-12B.i1-IQ3_M лише в тому, що перша трохи стабільніше справляється з кінцівками займенників. Але і тут є своя гірка пігулка. Як тільки у Q4_K_M починається зріз контексту, вона перетворюється на IQ3_M. То чи варто це того? Проестуйте самі і напишіть свої висновки в коментарях.

Висновок

Що ж, це був довгий шлях і ще довший тест. Заздалегідь прошу вибачення, якщо чогось не згадав (наприклад, налаштувань самої нейронної мережі, таких як температура тощо). Даних так багато, що вмістити їх в одному блозі, якщо й можливо, то це лише спричинить перевантаження в сенсі і загубиться сам зміст. А він досить простий - ви з легкістю можете використовувати свій старенький Поляріс (будь то «найслабша» RX 470 або топова RX 590) для запуску цілком солідних локальних моделей. Безумовно, це не 70B монстри, але і називати умовну MN-Violet-Lotus-12B лише «іграшкою» у мене язик не повернеться. Це стильна файн-тюн модель, яка здатна на тривале оповідання, або відіграш практично будь-якого персонажа, чи довгої сессії у ДнД.