#Claude #Codex # Sinubok ang Lokal na LLM sa Ryzen Zen3 GPU (Paghahambing at Pagsusuri ng Paggana ng Qwen3-8B Heretic CPU at GPU) Magtiyaga, AMD, magtiyaga ang Vulkan Akala ko ay hindi malaki ang GPU para sa mga laro, at tama naman ang aking akala Ang memory bandwidth ang problema (maliit ang VRAM, kaya ginagamit ang pangunahing memorya; umaasa sa Mac M5 Studio) Ang pinakabagong AMD ay Zen6, kaya ito ay CPU na tatlong henerasyon na pala (may built-in GPU) ---- # Paghahambing at Pagsusuri ng Paggana ng Qwen3-8B Heretic CPU at GPU Petsa ng Pagsusuri: 2026-11-02 / Target: Ubuntu machine ## Konklusyon - **Mas mabilis ang GPU (built-in Radeon GPU) sa pag-load ng prompt, halos 2.5 beses mas mabilis kaysa sa CPU.** - **Ang pagbuo ng teksto ay nagsisigla lamang ng 1.1 hanggang 1.2 beses kaysa sa CPU.** Ang bilis ng pagbuo ay nakakapag-utos sa bilis ng paglipat ng memorya, at dahil ang built-in GPU ay nagbabahagi ng parehong memorya sa CPU. - Sa paggamit na parang OpenClaw kung saan palaging ipinapadala ang mahabang instruksyon, mas malaki ang epekto ng **cache ng prompt** kaysa sa GPU, at mula sa 7 minuto ay bumaba sa 1 minuto na lamang mula sa pangalawang pagkakataon pa lamang. ## Mga Detalye ng Mga Kasangkapan | Item | Nilalaman | |---|---| | CPU | AMD Ryzen 7 7730U (8-core 16-thread, Zen 3) | | GPU | Built-in AMD Radeon Graphics (Barcelo, katumbas ng Vega 8) | | Memorya | 30GB (spesipikasyon: DDR4-3200 dual-channel. Hindi pa nasusuri sa totoong aparato) | | GPU Memorya | 512MB dedicated VRAM + shared memory (GTT) na halos 15.4GB. Ang gagamitin ng LM Studio ay 10.59GiB lamang | | OS / Driver | Ubuntu 24.04.5 LTS, Mesa 25.2.8 (RADV) | | LM Studio | Headless version (llmster), llama.cpp 2.66.0 | | CPU Runtime | `llama.cpp-linux-x86_64-avx2` | | GPU Runtime | `llama.cpp-linux-x86_64-vulkan-avx2` (lahat ng layer ay naka-set sa GPU, `--gpu max`) | | Model | DreamFast/qwen3-8b-heretic Q4_K_M (5.03GB) | | Pag-load Settings | Context length 32768, batch size 1 | ## Paraan ng Pagsusuri - Ipinadala ang parehong prompt sa API ng LM Studio (`/api/v0/chat/completions`) at hinambing ang CPU at GPU. - Bawat kondisyon ay isinagawa nang dalawang beses. Ang pangalawang pagkakataon ay gumagamit ng cache mula sa naunang prompt, kaya **ang bilis ng pag-load ay batay sa unang resulta**. - Ang bilis ng pagbuo ay batay sa `tokens_per_second` na ibinabigay ng LM Studio. - Ang pag-iisip bago ang sagot ay pinigil gamit ang `/no_think`, at ang `temperature` ay itinakda sa 0. - Pagkatapos ng pagsusuri sa GPU, inantay ang 2 minuto para mag-cool bago isagawa ang pagsusuri sa CPU. - Ang mga script at rekord ay nasa `~/bench/bench.py`, `~/bench/run.sh`, at `~/bench/result.log` ng Ubuntu machine. ## Mga Resulta ### Buod ng Paghahambing | Nilalaman | Item | CPU | GPU | Pagkakaiba | |---|---|---|---|---| | Maikling tanong (24 tokens) na bumuo ng 256 tokens | Bilis ng Pagbuo | 7.3 tokens/sec | 8.2 tokens/sec | 1.13x | | | Oras na Kailangan | 35.7 sec | 31.4 sec | | | Prompt na may 921 tokens | Bilis ng Pag-load | 30.5 tokens/sec | 76.3 tokens/sec | **2.5x** | | | Hanggang sa unang karakter | 30.2 sec | 12.1 sec | | | | Bilis ng Pagbuo | 7.0 tokens/sec | 8.0 tokens/sec | 1.13x | | Prompt na may 3,621 tokens | Bilis ng Pag-load | 35.4 tokens/sec | 87.5 tokens/sec | **2.5x** | | | Hanggang sa unang karakter | 102.3 sec | 41.4 sec | | | | Bilis ng Pagbuo | 5.9 tokens/sec | 7.2 tokens/sec | 1.2x | ### Detalye ng Mga Resulta | Paraan | Nilalaman | Pagkakataon | Prompt | Pagbuo | Oras na Kailangan | Hanggang sa Unang Karakter | Bilis ng Pagbuo | |---|---|---|---|---|---|---|---| | GPU | Maikling tanong | 1 | 24 | 256 | 31.4 sec | 0.50 sec | 8.26 | | GPU | Maikling tanong | 2 | 24 | 256 | 31.2 sec | 0.12 sec | 8.23 | | GPU | Prompt na halos 1,000 | 1 | 921 | 32 | 16.0 sec | 12.07 sec | 7.97 | | GPU | Prompt na halos 1,000 (cache) | 2 | 921 | 32 | 4.0 sec | 0.14 sec | 7.98 | | GPU | Prompt na halos 4,000 | 1 | 3,621 | 32 | 45.7 sec | 41.38 sec | 7.18 || GPU | Pahiwatig na humigit-kumulang 4,000 | 2 (cache) | 3,621 | 32 | 4.5 segundo | 0.14 segundo | 7.22 | | CPU | Maikling tanong | 1 | 24 | 256 | 35.7 segundo | 0.73 segundo | 7.29 | | CPU | Maikling tanong | 2 | 24 | 241 | 32.8 segundo | 0.14 segundo | 7.36 | | CPU | Pahiwatig na humigit-kumulang 1,000 | 1 | 921 | 32 | 34.7 segundo | 30.21 segundo | 7.03 | | CPU | Pahiwatig na humigit-kumulang 1,000 | 2 (cache) | 921 | 32 | 4.6 segundo | 0.15 segundo | 6.96 | | CPU | Pahiwatig na humigit-kumulang 4,000 | 1 | 3,621 | 32 | 107.5 segundo | 102.30 segundo | 5.94 | | CPU | Pahiwatig na humigit-kumulang 4,000 | 2 (cache) | 3,621 | 32 | 5.4 segundo | 0.17 segundo | 5.96 | Ang yunit ng pahiwatig at pagbuo ay token, at ang yunit ng bilis ng pagbuo ay token/segundo. ### Paunlaping Pagkakamali Noong una kong sinukat, sinabi kong ang bilis ng pagbuo sa GPU ay naging halos 2.2 beses na mas mabilis. Ngunit mali ito. Ang halagang 3.86 token/segundo ng CPU ay nakuha nang pinroseso ang pahiwatig na halos 14,000 token sa bot2. Dahil mas mabagal ang pagbuo kapag mahaba ang pahiwatig, mali ang paghahambing namin sa halaga para sa maikling tanong. Kapag hinambing sa parehong kondisyon, ang pagkakaiba sa pagbuo ay nasa pagitan ng 1.1 hanggang 1.2 beses lamang. ## Bakit hindi gaanong mabilis ang GPU ### 1. Ang pagbuo ay limitado ng bilis ng pagpapadala ng memorya Ang bawat token na binubuo ng LLM ay nangangailangan ng pagbasa sa lahat ng timbang ng modelo mula sa memorya. Ang maximum na bilis ng pagbuo ay tinukoy ng: “bilis ng pagpapadala ng memorya ÷ laki ng modelo”. | Item | Halaga | |---|---| | Teoretikal na bilis ng pagpapadala ng memorya | Humigit-kumulang 51 GB/segundo sa dual-channel DDR4-3200 | | Damit na binabasa bawat token | Humigit-kumulang 5 GB (buong modelo) | | Teoretikal na maximum na bilis ng pagbuo | 51 ÷ 5.03 ≒ **humigit-kumulang 10 token/segundo** | | Natuklasang resulta (GPU) | 8.2 token/segundo (80% ng maximum) | | Natuklasang resulta (CPU) | 7.3 token/segundo (70% ng maximum) | Ang built-in GPU ay nagbabahagi ng parehong pangunahing memorya sa CPU, kaya ang maximum ay halos magkakapareho. Kahit may GPU ka pa, ang posibilidad na mapalapit sa maximum ay maliit lamang—1 hanggang 2 porsyento. Ang labas na GPU ay may sariling mabilis na memorya, kaya mas mataas ang limitasyong ito. | GPU | Bilis ng pagpapadala ng memorya | Ratio sa Ubuntu machine na ito | |---|---|---| | Built-in GPU sa Ubuntu machine na ito | Humigit-kumulang 51 GB/segundo (bahagi ng CPU) | 1x | | RTX 4060 | Humigit-kumulang 272 GB/segundo | Humigit-kumulang 5x | | RTX 4090 | Humigit-kumulang 1,008 GB/segundo | Humigit-kumulang 20x | ### 2. Ang pagbasa ay depende sa computation, pero maliit ang computation power ng built-in GPU Ang pagbasa ng pahiwatig ay nagpapadala ng maraming token nang sabay-sabay, kaya ang bilis ay depende sa computation power kaysa sa memorya. Dito nakikita ang epekto ng GPU—naging 2.5 beses na mas mabilis ang resulta. Ngunit may mga limitasyon ang GPU na ito, kaya limitado lang sa 2.5 beses: | Limitasyon | Detalye | |---|---| | Maraming computation units | Mayroon lamang 8. Humigit-kumulang 2 TFLOPS sa single-precision, isang bahagi lamang ng isang game GPU | | Walang espesyal na circuit para sa matrix operations | Walang tulad ng NVIDIA’s Tensor Cores para sa AI | | Hindi suportado ang ROCm | Ang AMD GPU computing platform ay hindi opisyally sumusuporta sa built-in GPU na ito; gumagana ito gamit ang pangkalahatang Vulkan | Ang isang token sa isang 8B model ay nangangailangan ng humigit-kumulang 16 GFLOP computation. Kung mayroon kang humigit-kumulang 2 TFLOPS, ang teoretikal na maximum ay humigit-kumulang 120 token/segundo. Ang natuklasan nating resulta (76–88 token/segundo) ay nasa anim hanggang pito porsyento lamang nito. ### 3. Mas mabagal ang pagbasa at pagbuo kapag mas mahaba ang pahiwatig Kapag mas mahaba ang konteksto, mas maraming nakaraang token ang tinitingnan ng bawat token, kaya mas mabagal ang pagbasa at pagbuo. | Kondisyon | Bilis ng Pagbasa | Bilis ng Pagbuo | |---|---|---| | GPU, pahiwatig na humigit-kumulang 1,000 token | 76 token/segundo | 8.0 token/segundo | | GPU, pahiwatig na humigit-kumulang 3,600 token | 88 token/segundo | 7.2 token/segundo | | GPU, OpenClaw (15,686 token), unang 2,048 token | 78.7 token/segundo | — | | GPU, OpenClaw (15,686 token), average sa buong pahiwatig | 44.1 token/segundo | 5.1 token/segundo | | CPU, OpenClaw (14,021 token) | Humigit-kumulang 19.5 token/segundo | 3.86 token/segundo |Hanggang 3,600 tokens, mas mabilis ang pag-load dahil mas malaki ang dami ng maipaproseso nang sabay. Pagpasok sa higit sa 15,000 tokens, bumaba ang bilis hanggang 46 tokens/second sa huling bahagi. ## Pag-verify ng Cache sa OpenClaw (bot2 mei) Ipinadala ko ang dalawang mensahe nang sunud-sunod sa isang session na ginagamit ang Qwen3 na tumatakbo sa GPU. | Item | Unang Mensahe | Ikalawang Mensahe | |---|---|---| | Prompt na ipinadala ng OpenClaw | 15,686 tokens | 15,744 tokens | | Tunay na naload na tokens | 15,686 (lahat) | **135 (mga bagong idinagdag lamang)** | | Oras ng pag-load | 356.1 segundo | **6.1 segundo** | | Pagbuo | 247 tokens, 48.1 segundo (5.11 tokens/second) | 249 tokens, 48.5 segundo (5.11 tokens/second) | | Kabuuan | **410 segundo** | **58 segundo** | - Ang OpenClaw ay laging ipinapadala ang parehong nilalaman sa simula ng mga instruksyon, kaya ang ikalawang mensahe ay gumamit muli ng 98% na na-prosesong bahagi. - Ang karamihan sa paghihintay sa ikalawang mensahe ay mula sa pag-iisip ng humigit-kumulang 240 tokens. Kahit na iset ang `--thinking off`, hindi pa rin tumigil ang pag-iisip. Kung matutulungan nating itigil ang pag-iisip, maaaring bumaba ito sa humigit-kumulang 10 segundo. - Ang cache ay hindi nawawala batay sa oras. Nawawala ito kung ang modelo ay inalis, kung may iba pang proseso ang sumali (dahil limitado sa 1 parallel process), o kung ang usapan ay komprimo. ## Mga Pagsasagawa para Mabilisin Hindi natin maaaring baguhin ang bilis ng pag-transfer ng memorya, kaya ang epektibong paraan ay bawasan ang dami ng datos na naload bawat token. | Paraan | Inaasahang Epekto | Mga Paalala | |---|---|---| | Gamitin ang cache ng prompt | Ang pag-load sa ikalawa at sunod-sunod na mensahe ay nagsasagawa sa ilang segundo (nabigyan ng patotoo) | Maaaring mawala dahil sa pagpapalit o kompresyon | | Itigil ang pag-iisip ng Qwen3 | Pagbaba ng halos 48 segundo bawat mensahe | Maaaring bumaba ang kalidad ng sagot | | Palitan sa MoE na Qwen3-30B-A3B | Ang bawat token ay gumagamit lamang ng halos 3B na weights. Inaasahang dalawang hanggang tatlong beses mas mabilis ang pagbuo, at mas matalino rin | May laki na humigit-kumulang 18GB, hindi nabibilang sa 10.6GiB ng GPU, kaya kailangan ng CPU para sa ilang bahagi. Ang pagkakaroon o kawalan ng censored version ay hindi pa nasusuri | | Gamitin ang mas maliit na modelo (Qwen3-4B) | Ang pagbuo ay halos dalawang beses mas mabilis | Mababaw ang kakayahan | | Gamitin ang speculative decoding | Gamitin ang Qwen3-0.6B bilang draft. Inaasahang 1.3 hanggang 2 beses mas mabilis ang pagbuo | Ang epekto ay nakadepende sa nilalaman | | I-quantize pa higit pa (Q3 atbp.) | Pagpapabuti ng 10-20% | Bumababa ang akurasyon | | Gawing maikli ang mga instruksyon | Mas maikli ang pag-load sa unang mensahe at pagkatapos mawala ang cache | Maaaring mawala ang ilang mga tampok | Ang epekto sa tabla ay mga inaasahang halaga lamang, maliban sa cache ng prompt—hindi pa ito nasusukat. ## Kasalukuyang Kalagayan (tungkol sa 2026-11-03) | Item | Kalagayan | |---|---| | LM Studio | Ipinatigil. Ang awtomatikong pagsisimula ay hindi pinapagana | | Pinipili na runtime | Vulkan (GPU) | | bot2 (mei) | gpt-5.4-mini | | Port para sa bot2 | Ipinatigil. Ang awtomatikong pagsisimula ay hindi pinapagana | | Mga setting ng bot2 para sa Qwen3 | `~/.openclaw-bot2/openclaw.json.bak-qwen3-active-*` |