
#Claude #Codex # ローカルLLMをRyzen Zen3 GPUで動かしてみた (Qwen3-8B Heretic CPUとGPUの性能比較と分析結果) 頑張れ、AMD、頑張れVulkan ゲーム用GPUだから大したことないと思ってたけど、その通りでした メモリバンド幅がネックだそうです(VRAMちっちゃいからメインメモリ使用、Mac M5 Studioに期待) 最新がAMDはZen6だから3世代前のCPU(GPU内蔵) ---- # Qwen3-8B Heretic CPUとGPUの性能比較と検討結果 測定日: 2026-11-02 / 対象: Ubuntu機 ## 結論 - **GPU(Radeon内蔵GPU)が速いのはプロンプトの読み込みで、CPUの約2.5倍です。** - **文章の生成はCPUの1.1〜1.2倍しか速くなりません。** 生成速度はメモリの転送速度で頭打ちになり、内蔵GPUはCPUと同じメモリを共有しているためです。 - OpenClawのように長い指示文を毎回送る使い方では、GPUよりも**プロンプトのキャッシュ**の効果が大きく、2通目以降は約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で比べました。 - 各条件を2回ずつ実行しました。2回目は処理済みのプロンプトがキャッシュから再利用されるため、**読み込み速度は1回目の値**を使っています。 - 生成速度は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トークン)で256トークン生成 | 生成速度 | 7.3トークン/秒 | 8.2トークン/秒 | 1.13倍 | | | 所要時間 | 35.7秒 | 31.4秒 | | | プロンプト921トークン | 読み込み速度 | 30.5トークン/秒 | 76.3トークン/秒 | **2.5倍** | | | 最初の文字まで | 30.2秒 | 12.1秒 | | | | 生成速度 | 7.0トークン/秒 | 8.0トークン/秒 | 1.13倍 | | プロンプト3,621トークン | 読み込み速度 | 35.4トークン/秒 | 87.5トークン/秒 | **2.5倍** | | | 最初の文字まで | 102.3秒 | 41.4秒 | | | | 生成速度 | 5.9トークン/秒 | 7.2トークン/秒 | 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は1トークンを生成するたびに、モデルの重みをすべてメモリから読み出します。生成速度の上限は、おおよそ「メモリの転送速度 ÷ モデルの大きさ」で決まります。 | 項目 | 値 | |---|---| | メモリの転送速度(理論値) | DDR4-3200のデュアルチャネルで約51GB/秒 | | 1トークンごとに読み出す量 | 約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の数十分の1 | | 行列演算専用の回路がない | NVIDIAのTensorコアのような、AI向けの専用回路がない | | ROCmが使えない | AMDのGPU向け計算基盤は、この内蔵GPUを正式にサポートしていない。汎用のVulkanで動かしている | 8Bモデルでは1トークンの処理に約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を使って2通続けて送りました。 | 項目 | 1通目 | 2通目 | |---|---|---| | 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は毎回、指示文の先頭を同じ内容で送るので、2通目は処理済みの部分(98%)がそのまま再利用されました。 - 2通目の待ち時間の大半は、約240トークンの思考です。`--thinking off`を指定しても思考は止まりませんでした。思考を止められれば、10秒前後になる見込みです。 - キャッシュは時間では消えません。消えるのは、モデルが外されたとき、別の処理が割り込んだとき(同時処理数1のため)、会話が圧縮されたときです。 ## 速くするための選択肢 メモリの転送速度は変えられないので、1トークンごとに読み出す量を減らすのが効果的です。 | 方法 | 見込める効果 | 注意点 | |---|---|---| | プロンプトのキャッシュを生かす | 2通目以降の読み込みが数秒になる(検証済み) | 割り込みや圧縮で消える | | Qwen3の思考を止める | 1通あたり約48秒の短縮 | 回答の質がやや下がることがある | | MoE型のQwen3-30B-A3Bに替える | 1トークンごとに使う重みは約3B分。生成は2〜3倍になる見込みで、賢さも上がる | 約18GBあり、GPUの10.6GiBに収まらないので一部はCPUで処理する。検閲解除版の有無は未確認 | | 小さいモデル(Qwen3-4B)にする | 生成は約2倍 | 賢さが下がる | | 投機的デコードを使う | Qwen3-0.6Bに下書きさせる。生成は1.3〜2倍 | 効果は内容でばらつく | | 量子化をさらに小さくする(Q3など) | 1〜2割の改善 | 精度が落ちる | | 指示文を短くする | 最初の1通とキャッシュが消えた後の読み込みが短くなる | 機能を削ることになる | この表の効果は、プロンプトのキャッシュ以外は見積もりで、実測していません。 ## 現在の状態(2026-11-03時点) | 項目 | 状態 | |---|---| | LM Studio | 停止。自動起動も無効 | | 選択中のランタイム | Vulkan(GPU) | | bot2(めい) | gpt-5.4-mini | | bot2用の転送口 | 停止。自動起動も無効 | | Qwen3用のbot2設定 | `~/.openclaw-bot2/openclaw.json.bak-qwen3-active-*` |