#Claude #Codex # Спробував запустити локальний LLM на GPU Ryzen Zen3 (Порівняння та аналіз продуктивності Qwen3-8B Heretic CPU та GPU) Тримайся, AMD, тримайся Vulkan Думав, що це просто ігрова GPU — і не варто очікувати багато, і виявилось, що так і є Головний обмежувач — пропускна здатність пам’яті (маленький об’єм VRAM, тому використовується основна пам’ять; чекаємо на Mac M5 Studio) Найновіша архітектура AMD — Zen6, а тут — CPU трьох поколінь минулого (з вбудованим GPU) ---- # Порівняння та аналіз продуктивності Qwen3-8B Heretic CPU та GPU Дата вимірювання: 2026-11-02 / Система: Ubuntu ## Висновки - **GPU (вбудований Radeon) швидше завантажує промпти — приблизно в 2,5 рази швидше, ніж CPU.** - **Генерація тексту прискорюється лише на 1,1–1,2 рази.** Швидкість генерації обмежена швидкістю передачі даних пам’яті, оскільки вбудований GPU використовує ту саму пам’ять, що й CPU. - При використанні, як у OpenClaw, де кожного разу надсилаються довгі інструкції, **кешування промптів** має набагато більший ефект, ніж GPU: з другого разу час зменшився з ~7 хвилин до ~1 хвилини. ## Середовище вимірювання | Параметр | Значення | |---|---| | CPU | AMD Ryzen 7 7730U (8 ядер, 16 потоків, Zen 3) | | GPU | Вбудований AMD Radeon Graphics (Barcelo, еквівалент Vega 8) | | Пам’ять | 30 ГБ (за специфікацією — DDR4-3200 dual-channel; на реальному пристрої не перевірено) | | Пам’ять для GPU | 512 МБ власної VRAM + спільна пам’ять (GTT) ~15,4 ГБ. LM Studio може використовувати 10,59 ГiБ | | ОС / драйвери | Ubuntu 24.04.5 LTS, Mesa 25.2.8 (RADV) | | LM Studio | Безголовна версія (llmster), llama.cpp 2.66.0 | | Рантайм для CPU | `llama.cpp-linux-x86_64-avx2` | | Рантайм для GPU | `llama.cpp-linux-x86_64-vulkan-avx2` (усі шари розміщені на GPU, `--gpu max`) | | Модель | DreamFast/qwen3-8b-heretic Q4_K_M (5,03 ГБ) | | Налаштування завантаження | Довжина контексту 32768, кількість одночасних запитів 1 | ## Методика вимірювання - Надсилав однаковий промпт через API LM Studio (`/api/v0/chat/completions`) і порівнював результати для CPU та GPU. - Кожна умова виконувалася двічі. Другий раз промпт використовувався з кешу — тому **швидкість завантаження бралася з першого запуску**. - Швидкість генерації — це значення `tokens_per_second`, що повертає LM Studio. - Мислення перед відповіддю вимкнено за допомогою `/no_think`, `temperature` встановлено на 0. - Після вимірювання GPU пристрій охолоджувався 2 хвилини, потім проводилося вимірювання CPU. - Скрипти та записи знаходяться у файлових системах Ubuntu: `~/bench/bench.py`, `~/bench/run.sh`, `~/bench/result.log`. ## Результати ### Загальне порівняння | Параметр | Категорія | CPU | GPU | Розбіжність | |---|---|---|---|---| | Коротке запитання (24 токени), генерація 256 токенів | Швидкість генерації | 7,3 токени/с | 8,2 токени/с | 1,13x | | | Загальний час | 35,7 с | 31,4 с | | | Промпт 921 токен | Швидкість завантаження | 30,5 токенів/с | 76,3 токени/с | **2,5x** | | | Час до першого символу | 30,2 с | 12,1 с | | | | Швидкість генерації | 7,0 токенів/с | 8,0 токени/с | 1,13x | | Промпт 3 621 токен | Швидкість завантаження | 35,4 токени/с | 87,5 токенів/с | **2,5x** | | | Час до першого символу | 102,3 с | 41,4 с | | | | Швидкість генерації | 5,9 токенів/с | 7,2 токени/с | 1,2x | ### Детальні результати вимірювань | Метод | Параметр | Повтор | Промпт | Генерація | Загальний час | Час до першого символу | Швидкість генерації | |---|---|---|---|---|---|---|---| | GPU | Коротке запитання | 1 | 24 | 256 | 31,4 с | 0,50 с | 8,26 | | GPU | Коротке запитання | 2 | 24 | 256 | 31,2 с | 0,12 с | 8,23 | | GPU | Промпт ~1000 токенів | 1 | 921 | 32 | 16,0 с | 12,07 с | 7,97 | | GPU | Промпт ~1000 токенів (кеш) | 2 | 921 | 32 | 4,0 с | 0,14 с | 7,98 | | GPU | Промпт ~4000 токенів | 1 | 3621 | 32 | 45,7 с | 41,38 с | 7,18 || GPU | Приблизно 4 000 токенів запиту | 2 (кеш) | 3 621 | 32 | 4,5 секунди | 0,14 секунди | 7,22 | | CPU | Коротке запитання | 1 | 24 | 256 | 35,7 секунди | 0,73 секунди | 7,29 | | CPU | Коротке запитання | 2 | 24 | 241 | 32,8 секунди | 0,14 секунди | 7,36 | | CPU | Приблизно 1 000 токенів запиту | 1 | 921 | 32 | 34,7 секунди | 30,21 секунди | 7,03 | | CPU | Приблизно 1 000 токенів запиту | 2 (кеш) | 921 | 32 | 4,6 секунди | 0,15 секунди | 6,96 | | CPU | Приблизно 4 000 токенів запиту | 1 | 3 621 | 32 | 107,5 секунди | 102,30 секунди | 5,94 | | CPU | Приблизно 4 000 токенів запиту | 2 (кеш) | 3 621 | 32 | 5,4 секунди | 0,17 секунди | 5,96 | Одиниці запиту та генерації — токени; одиниця швидкості генерації — токени/сек. ### Виправлення Під час першого спрощеного вимірювання ми повідомили, що швидкість генерації на GPU зросла приблизно в 2,2 рази, але це було помилково. Значення в 3,86 токенів/сек для CPU було отримане під час обробки запиту довжиною близько 14 000 токенів на bot2. Оскільки з довгими запитами генерація стає повільнішою, порівнювати її зі значенням для коротких запитань було помилкою. При порівнянні за однакових умов різниця в швидкості генерації становить лише 1,1–1,2 рази. ## Чому використання GPU не призводить до значного прискорення ### 1. Генерація обмежена швидкістю передачі пам’яті Кожного разу, коли LLM генерує один токен, він завантажує всі ваги моделі з пам’яті. Верхня межа швидкості генерації визначається приблизно як: «швидкість передачі пам’яті ÷ розмір моделі». | Показник | Значення | |---|---| | Теоретична швидкість передачі пам’яті | Приблизно 51 ГБ/с при подвійному каналі DDR4-3200 | | Обсяг даних, що завантажуються на один токен | Приблизно 5 ГБ (вся модель) | | Теоретична верхня межа швидкості генерації | 51 ÷ 5,03 ≒ **приблизно 10 токенів/сек** | | Практичне значення (GPU) | 8,2 токени/сек (~80% від верхньої межі) | | Практичне значення (CPU) | 7,3 токени/сек (~70% від верхньої межі) | Вбудований GPU використовує ту саму основну пам’ять, що й CPU, тому верхня межа практично ідентична. Навіть з GPU залишається лише 10–20% простору для зростання швидкості до межі. Зовнішні GPU мають власну швидку пам’ять, тому їхня верхня межа значно вища. | GPU | Швидкість передачі пам’яті | Співвідношення з цим пристроєм Ubuntu | |---|---|---| | Вбудований GPU цього пристрою Ubuntu | Приблизно 51 ГБ/с (спільна з CPU) | 1x | | RTX 4060 | Приблизно 272 ГБ/с | Приблизно 5x | | RTX 4090 | Приблизно 1 008 ГБ/с | Приблизно 20x | ### 2. Завантаження залежить від обчислювальної потужності, але вбудований GPU має слабку обчислювальну потужність При завантаженні запиту багато токенів обробляються разом, тому швидкість визначається обчислювальною потужністю, а не швидкістю пам’яті. Саме тут проявляється перевага GPU — у практиці швидкість зросла в 2,5 рази. Проте цей GPU має такі обмеження, через які досягнуто лише подвоєння: | Обмеження | Опис | |---|---| | Мало обчислювальних блоків | Лише 8. Оцінка потужності: близько 2 TFLOPS у одинарній точності — у десятки разів менше, ніж у ігрових GPU | | Відсутність спеціалізованих схем для матричних операцій | Немає спеціалізованих схем на кшталт Tensor Core в NVIDIA | | Неможливість використання ROCm | Платформа ROCm для GPU AMD офіційно не підтримує цей вбудований GPU; працює через універсальний Vulkan | Для моделей розміром 8B потрібно приблизно 16 GFLOP на один токен. При потужності близько 2 TFLOPS теоретична верхня межа становить близько 120 токенів/сек. Практичні значення в діапазоні 76–88 токенів/сек — це приблизно 6–7% від теоретичної межі. ### 3. Чим довший запит — тим повільніша робота З ростом довжини контексту кожен токен посилається на багато попередніх токенів, що сповільнює як завантаження, так і генерацію. | Умова | Швидкість завантаження | Швидкість генерації | |---|---|---| | GPU, запит приблизно 1 000 токенів | 76 токенів/сек | 8,0 токени/сек | | GPU, запит приблизно 3 600 токенів | 88 токенів/сек | 7,2 токени/сек | | GPU, OpenClaw (15 686 токенів), першi 2 048 токенiв | 78,7 токенiв/сек | — | | GPU, OpenClaw (15 686 токенiв), середнє значення за всiм запитом | 44,1 токенiв/сек | 5,1 токени/сек | | CPU, OpenClaw (14 021 токенiв) | Приблизно 19,5 токенiв/сек | 3,86 токени/сек |До 3 600 токенів час завантаження навіть зменшився, оскільки обсяг обробки одночасно збільшився. Після 15 000 токенів швидкість завантаження впала до 46 токенів/с. ## Перевірка кешу в OpenClaw (bot2 mei) У тестовому сеансі я надіслав два повідомлення послідовно, використовуючи Qwen3, запущений на GPU. | Показник | Перше повідомлення | Друге повідомлення | |---|---|---| | Промпт, відправлений OpenClaw | 15 686 токенів | 15 744 токени | | Фактично завантажені токени | 15 686 (усі) | **135 (лише нові)** | | Час завантаження | 356,1 секунди | **6,1 секунди** | | Генерація | 247 токенів, 48,1 секунди (5,11 токенів/с) | 249 токенів, 48,5 секунди (5,11 токенів/с) | | Загалом | **410 секунд** | **58 секунд** | - OpenClaw завжди надсилає однаковий початок інструкції, тому друге повідомлення повторно використало вже оброблену частину (98%). - Більшість часу очікування у другому повідомленні — це приблизно 240 токенів міркувань. Навіть з `--thinking off` міркування не зупинилися. Якби їх можна було вимкнути, час очікування скоротився б до ~10 секунд. - Кеш не зникає з часом. Він зникає лише тоді, коли модель видаляється, коли інший процес перериває обробку (через обмеження в 1 одночасний процес) або коли діалог стискається. ## Варіанти прискорення Оскільки швидкість передачі пам’яті змінити неможливо, ефективніше зменшити обсяг завантаження на кожен токен. | Метод | Передбачуваний ефект | Примітки | |---|---|---| | Використання кешу промпту | Завантаження на другому і наступних повідомленнях — кілька секунд (підтверджено) | Може зникнути через переривання або стиснення | | Вимкнення міркувань Qwen3 | Зменшення часу на ~48 секунд на повідомлення | Якість відповідей може трохи знизитися | | Заміна на MoE-модель Qwen3-30B-A3B | Використовується ~3B ваг на токен; генерація може прискоритися в 2–3 рази, зростає розумність | Розмір ~18 ГБ, не вміщується в 10,6 ГБ GPU — частина оброблятиметься на CPU. Наявність версії без цензури невідома | | Перехід на меншу модель (Qwen3-4B) | Генерація приблизно в 2 рази швидша | Зниження розумності | | Використання спекулятивного декодування | Використання Qwen3-0.6B як чернетки; генерація прискорюється в 1,3–2 рази | Ефект залежить від контенту | | Додаткове квантування (Q3 тощо) | Покращення на 10–20% | Зниження точності | | Скорочення інструкції | Зменшення часу завантаження для першого повідомлення та після втрати кешу | Призведе до втрати функціональності | Ефекти у цій таблиці, крім кешу промпту, є оцінками — не перевірялися експериментально. ## Поточний стан (на 2026-11-03) | Показник | Стан | |---|---| | LM Studio | Зупинено. Автоматичний запуск вимкнено | | Обрана середовище виконання | Vulkan (GPU) | | bot2 (mei) | gpt-5.4-mini | | Порт для bot2 | Зупинено. Автоматичний запуск вимкнено | | Налаштування bot2 для Qwen3 | `~/.openclaw-bot2/openclaw.json.bak-qwen3-active-*` |