#Claude #Codex # 在 Ryzen Zen3 GPU 上運行本地 LLM（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 GPU）在提示詞載入時更快，約為 CPU 的 2.5 倍。** - **文章生成時僅快 1.1 至 1.2 倍。** 生成速度受限於記憶體傳輸速率，因內建 GPU 與 CPU 共享同一記憶體。 - 在類似 OpenClaw 每次傳送長指令的使用情境下，**提示詞快取**的效果更為顯著，第二條及之後的回應時間從約 7 分鐘縮短至約 1 分鐘。 ## 測量環境 | 項目 | 內容 | |---|---| | CPU | AMD Ryzen 7 7730U（8 核 16 線程、Zen 3） | | GPU | CPU 內建 AMD Radeon Graphics（Barcelo、相當於 Vega 8） | | 記憶體 | 30GB（規格為 DDR4-3200 雙通道，實際機器未確認） | | GPU 記憶體 | 專用 VRAM 512MB＋共享記憶體（GTT）約 15.4GB。LM Studio 可用空間為 10.59GiB | | OS / 驅動程式 | 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.03GB） | | 載入設定 | 上下文長度 32768、同時處理數量 1 | ## 測量方法 - 向 LM Studio 的 API（`/api/v0/chat/completions`）發送相同提示詞，比較 CPU 與 GPU 的表現。 - 每種條件執行兩次。第二次使用快取中的已處理提示詞，因此**載入速度採用第一次的數值**。 - 生成速度以 LM Studio 回傳的 `tokens_per_second` 為準。 - 回應前的思考過程使用 `/no_think` 停止，`temperature` 設為 0。 - 測量完 GPU 後，冷卻 2 分鐘再測量 CPU。 - 腳本與記錄檔位於 Ubuntu 機器的 `~/bench/bench.py`、`~/bench/run.sh`、`~/bench/result.log`。 ## 結果 ### 比較摘要 | 內容 | 項目 | CPU | GPU | 差異 | |---|---|---|---|---| | 短提問（24 個 token）生成 256 個 token | 生成速度 | 7.3 token/秒 | 8.2 token/秒 | 1.13 倍 | | | 耗時 | 35.7 秒 | 31.4 秒 | | | 提示詞 921 個 token | 載入速度 | 30.5 token/秒 | 76.3 token/秒 | **2.5 倍** | | | 首字輸出時間 | 30.2 秒 | 12.1 秒 | | | | 生成速度 | 7.0 token/秒 | 8.0 token/秒 | 1.13 倍 | | 提示詞 3,621 個 token | 載入速度 | 35.4 token/秒 | 87.5 token/秒 | **2.5 倍** | | | 首字輸出時間 | 102.3 秒 | 41.4 秒 | | | | 生成速度 | 5.9 token/秒 | 7.2 token/秒 | 1.2 倍 | ### 測量詳情 | 方式 | 內容 | 次數 | 提示詞 | 生成 | 耗時 | 首字輸出時間 | 生成速度 | |---|---|---|---|---|---|---|---| | GPU | 短提問 | 1 | 24 | 256 | 31.4 秒 | 0.50 秒 | 8.26 | | GPU | 短提問 | 2 | 24 | 256 | 31.2 秒 | 0.12 秒 | 8.23 | | GPU | 提示詞約 1,000 | 1 | 921 | 32 | 16.0 秒 | 12.07 秒 | 7.97 | | GPU | 提示詞約 1,000（快取） | 2 | 921 | 32 | 4.0 秒 | 0.14 秒 | 7.98 | | GPU | 提示詞約 4,000 | 1 | 3,621 | 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倍，但這是錯誤的。當時對比的CPU值3.86令牌/秒，是bot2處理約14,000令牌提示詞時的數據。由於長提示詞會導致生成速度變慢，因此與短提問的數據比較是錯誤的。若在相同條件下比較，生成速度差僅為1.1至1.2倍。 ## 即使使用GPU，速度也未如預期般提升的原因 ### 1. 生成速度受限於記憶體傳輸速率 LLM在生成每個令牌時，都需要從記憶體中讀取整個模型的權重。生成速度的上限大致由「記憶體傳輸速率 ÷ 模型大小」決定。 | 項目 | 值 | |---|---| | 記憶體傳輸速率（理論值） | DDR4-3200雙通道約51GB/秒 | | 每個令牌讀取量 | 約5GB（整個模型） | | 理論生成速度上限 | 51 ÷ 5.03 ≒ **約10令牌/秒** | | 實測（GPU） | 8.2令牌/秒（上限的約8成） | | 實測（CPU） | 7.3令牌/秒（上限的約7成） | 內建GPU與CPU共用主記憶體，因此上限與CPU幾乎相同。即使使用GPU，也僅能接近上限1至2成的提升空間。 外接GPU擁有專用高速記憶體，因此此上限會高得多。 | GPU | 記憶體傳輸速率 | 與此Ubuntu機器的比率 | |---|---|---| | 此Ubuntu機器的內建GPU | 約51GB/秒（與CPU共用） | 1倍 | | RTX 4060 | 約272GB/秒 | 約5倍 | | RTX 4090 | 約1,008GB/秒 | 約20倍 | ### 2. 載入速度取決於計算量，但內建GPU的計算能力較弱 在提示詞載入階段，可批量處理大量令牌，因此速度主要由計算能力決定。GPU在此處效果明顯，實測提升達2.5倍。 然而，此GPU受以下限制，僅能達到2.5倍： | 設限項目 | 內容 | |---|---| | 計算單元數量少 | 僅8個。估計單精度性能約為2TFLOPS，僅為遊戲級GPU的數十分之一 | | 缺乏矩陣運算專用電路 | 缺少NVIDIA Tensor Core等專為AI設計的專用電路 | | 不支援ROCm | AMD的GPU計算平台未正式支援此內建GPU，僅能透過通用Vulkan運行 | 對於8B模型，處理每個令牌需約16GFLOP的計算量，若計算能力為約2TFLOPS，理論上限約為120令牌/秒。實測的76至88令牌/秒，相當於理論值的6至7成。 ### 3. 提示詞越長，速度越慢 隨著上下文變長，每個令牌需參考的過往令牌數增加，導致載入與生成均變慢。 | 條件 | 載入速度 | 生成速度 | |---|---|---| | GPU、提示詞約1,000令牌 | 76令牌/秒 | 8.0令牌/秒 | | GPU、提示詞約3,600令牌 | 88令牌/秒 | 7.2令牌/秒 | | GPU、OpenClaw（15,686令牌）前2,048令牌 | 78.7令牌/秒 | — | | GPU、OpenClaw（15,686令牌）整體平均值 | 44.1令牌/秒 | 5.1令牌/秒 | | CPU、OpenClaw（14,021令牌） | 約19.5令牌/秒 | 3.86令牌/秒 |在 3,600 個令牌以內，由於可處理的量增加，載入速度反而變快了。超過 15,000 個令牌後，末段速度降至每秒 46 個令牌。 ## 在 OpenClaw（bot2 めい）上的快取驗證 在驗證會話中，連續發送了兩次由 GPU 執行的 Qwen3。 | 項目 | 第一次 | 第二次 | |---|---|---| | 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 倍，智慧度亦提升 | 大小約為 18GB，超出 GPU 的 10.6GiB，部分需由 CPU 處理；未確認是否有未審查版本 | | 改用較小模型（Qwen3-4B） | 生成速度約提升 2 倍 | 智慧度下降 | | 使用投機性解碼 | 使用 Qwen3-0.6B 作為草稿模型，生成速度提升 1.3–2 倍 | 效果依內容而異 | | 進一步量化（如 Q3） | 改善 10–20% | 精度下降 | | 縮短指示文 | 首次與快取清除後的載入時間縮短 | 將導致功能削減 | 本表中的效果，除提示詞快取外，其餘均為估算，尚未實際測試。 ## 當前狀態（截至 2026-11-03） | 項目 | 狀態 | |---|---| | LM Studio | 已停止，自動啟動已禁用 | | 當前使用的執行時 | Vulkan（GPU） | | bot2（めい） | gpt-5.4-mini | | bot2 的傳輸端口 | 已停止，自動啟動已禁用 | | Qwen3 的 bot2 設定 | `~/.openclaw-bot2/openclaw.json.bak-qwen3-active-*` |