ollama」タグアーカイブ

OpenClaw の Local LLM 設定と Vision モデルの変更方法

OpenClaw とは

OpenClaw はクラウドサービスではなく、自分の PC 上で走らせることができる AI エージェントです。インターフェースとして各種メッセージングツールを利用しているので、Slack や Discord、iMessage や LINE など、普段使い慣れているアプリでそのまま AI と対話することができます。PC でもスマートフォンでも、普段使ってるアプリがそのまま AI エージェントの窓口になるわけです。

OpenClaw のエージェントが従来の AI と異なっている点は、最初から直接 PC を操作できることです。例えばネット検索で情報集めを依頼した場合、正しい手順を踏む場合は Brave Search や Perplexity 検索サービス等の API Key が必要となります。

ところが OpenClaw のエージェントでは、これらのサービスが使えない場合でも代わりの方法を探し出そうとします。curl 系のコマンドで直接ページの取得を試みたり、Chrome ブラウザを起動して Google 検索を利用したりと、自分で解決策を求めて試行錯誤を行い目的を完遂しようとします。この動きは自動的に行われているので、依頼した人間は裏でどんな方法が使われていたのかを知る必要がありません。面倒なことは AI に任せて結果だけを受け取ればいいのです。

柔軟性が高く応用力に富む反面、当然ながら知らないうちに意図しない操作が行われてしまうリスクもあります。OpenClaw を使う場合は仮想マシンのような隔離したサンドボックス環境を使い、普段自分が使っている重要な情報満載の PC にはそのままインストールしないようにしてください。

OpenClaw のインストール方法などの手順は以下の Wiki の方にまとめています。逐次更新していますのでこちらも参照してください。

今回は OpenClaw で Local LLM を設定するための設定などを解説していきます。(Local LLM は自分の PC 上で走らせられる LLM のことです。Local LLM について詳しくはこちら)

OpenClaw インストーラーの Model の選択をスキップする方法

OpenClaw が使用する LLM (大規模言語モデル) は、インストール時に任意のサービスを選択することができます。Claude や OpenAI、Gemini など豊富なクラウド LLM の API を選択することが可能ですが、この選択肢には Local LLM 用のプロバイダが含まれていません。そのため Local LLM を使いたい場合はこの画面はとりあえず無難なものを選んでスキップし、あとから設定ファイルを書き換える必要があります。

スキップするためのおすすめの選択肢は以下の通りです。モデルの Provider 選択肢から

「Skip for now」→「openai」→「Keep current」

初回のインストーラーでモデル選択をスキップした場合でも、あとからモデルの選択だけやり直すことが可能なので安心してください。やり直す場合はコマンドラインから以下のように実行します。

openclaw configure --section model

もし openclaw コマンドが見つからないと言われた場合はまだパスが通っていないので、最初に「. ~/.bashrc」を実行してから上のコマンドを実行してください。「~」の文字が入力できない場合は「$HOME」に置き換えてください。

.  ~/.bashrc
openclaw configure --section model

OpenClaw の設定ファイルを書き換える方法

OpenClaw の設定ファイルは ~/.openclaw/openclaw.json にあります。使用する LLM の設定もこのファイルに記述することができます。

Local LLM 向けに設定を書き換える場合のポイントは以下の 2 点です。

  1. プロバイダを新規追加する場合は “ollama” のような既存の名前と重なるものを避けて “ollamalocalpc” のように別名にする。
  2. 書き換えたあとは必ず「 openclaw gateway restart 」を実行して Gateway (OpenClaw サーバー) を再起動する。

1. インストール時の選択肢には出てこないものの、OpenClaw には Ollama 向けのプロバイダがプリセットとして定義されています。このプリセットは localhost を見に行くので、baseUrl で IP ドレスを書き換えても反映されないことがあります。完全に新規の別名で追加した方が確実です。

2. openclaw status などのコマンドでは直接 openclaw.json を読み取っていますが、これが必ずしも Gateway に反映されているとは限らないようです。表示されているモデルと実際に使われているものが異なる場合があるので、openclaw.json を変更したら必ず「 openclaw gateway restart 」を実行するようにしてください。

以下は、別の PC 上で動いている LMStudio を使用する場合の設定例です。openclaw.json には他の設定も含まれているので、以下の “models” の項目を追加してください。(openclaw.json の前後の部分は省略しています)

Local LLM プロバイダとモデルの定義

  "models": {
    "providers": {
      "lmstudiolocalpc": {
        "baseUrl": "http://<PC-IP-ADDRESS>:1234/v1",
        "apiKey": "lmstudio",
        "api": "openai-completions",
        "models": [
          {
            "id": "openai/gpt-oss-120b",
            "name": "openai/gpt-oss-120b",
            "reasoning": true,
            "input": [
              "text"
            ],
            "cost": {
              "input": 0,
              "output": 0,
              "cacheRead": 0,
              "cacheWrite": 0
            },
            "contextWindow": 65536,
            "maxTokens": 32768
          }
        ]
      }
    }
  },

<PC-IP-ADDRESS> の部分は LMStudio が動いている PC のアドレスに置き換えます。OpenClaw と LMStudio が同じPC 上で動いている場合は 127.0.0.1 で構いません。

モデルの指定

このモデルを実際に使用する場合は agents.defaults.model.primary に指定します。

  "agents": {
    "defaults": {
    
    
      "model": {
        "primary": "lmstudiolocalpc/openai/gpt-oss-120b"
      },
      
      
      "workspace": "/home/<USERNAME>/.openclaw/workspace",
      "compaction": {
        "mode": "safeguard"
      },
      "timeoutSeconds": 1800,
      "maxConcurrent": 4,
      "subagents": {
        "maxConcurrent": 8
      }
    }
  },

<USERNAME> の部分は自分のユーザー名が最初から入っているはずです。

Ollama を使う場合も同じように設定できます。以下のページ Ollama を含めたさまざまな設定例を置いてあるのでこちらも参照してください。

画像認識用モデルの設定

OpenClaw は画像の認識を行うことができます。Slack や Discord へ投稿した画像はもちろんですが、ローカル PC 上に保存したファイルの認識もしてくれます。この場合は LLM (VLM) を使った認識が行われます。

Claude や GPT-5, Gemini 3 などの商用の推奨モデルは最初からマルチモーダルなので画像の認識が可能です。ですが Local LLM を使用する場合は対応していないことが多いので、OpenClaw では画像識別用に別途 VLM を設定する機能があります。

以下のように、agents.defaults.model.primary とは別に画像認識用の VLM を agents.defaults.imageModel.primary に設定します。以下の例では「 qwen3-vl-8b 」を設定しています。

  "agents": {
    "defaults": {
 
      "model": {
        "primary": "lmstudiolocalpc/openai/gpt-oss-120b"
      },

 
      "imageModel": {
        "primary": "lmstudiolocalpc/qwen/qwen3-vl-8b"
      },


      "workspace": "/home/<USERNAME>/.openclaw/workspace",
      "compaction": {
        "mode": "safeguard"
      },
      "timeoutSeconds": 1800,
      "maxConcurrent": 4,
      "subagents": {
        "maxConcurrent": 8
      }
    }
  },

qwen3-vl-8b を含めたプロバイダ側のモデルの定義は以下のとおりです。qwen3-vl-8b 側の input の項目 ( models.providers.lmstudiolocalpc.models[1].input ) に “image” を追加しており、これで画像を受け取れるようにします。

  "models": {
    "providers": {
      "lmstudiolocalpc": {
        "baseUrl": "http://<PC-IP-ADDRESS>:1234/v1",
        "apiKey": "lmstudio",
        "api": "openai-completions",
        "models": [
          {
            "id": "openai/gpt-oss-120b",
            "name": "openai/gpt-oss-120b",
            "reasoning": true,
            "input": [
              "text"
            ],
            "cost": {
              "input": 0,
              "output": 0,
              "cacheRead": 0,
              "cacheWrite": 0
            },
            "contextWindow": 65536,
            "maxTokens": 32768
          },
          {
            "id": "qwen/qwen3-vl-8b",
            "name": "qwen/qwen3-vl-8b",
            "reasoning": true,
            "input": [
              "text",
              "image"
            ],
            "cost": {
              "input": 0,
              "output": 0,
              "cacheRead": 0,
              "cacheWrite": 0
            },
            "contextWindow": 32768,
            "maxTokens": 32768
          }
        ]
      }
    }
  },

これで画像認識非対応の Local LLM 利用時でも画像の識別ができるようになります。また GLM-5 などのクラウドモデルで Vision に対応していない場合にも、画像認識を Local LLM で補うことができるようになります。

商用 API などの既存のモデルが image 入力に対応しているかどうかは、以下のコマンドで確認することができます。

openclaw models list --all

OpenClaw で Local LLM を使う場合の注意点

OpenClaw のエージェントは自律的な動作を行うのでさまざまなリスクがあります。例えばネットから得た情報には悪意を持ったプロンプトが含まれている可能性があります。偽の指示に騙されないようにするためには、ある程度パラメータ数の多い LLM が必要です。

OpenClaw ではサンドボックスなしにネットアクセスを許可する場合 300b 以上のモデルを推奨しているようで、パラメータ数が少ないモデルの場合は openclaw status 等のコマンド実行時に警告が表示されます。OpenClaw のインストーラーに Local LLM の選択肢が含まれていないのも、このあたりの事情によるものではないかと思われます。

そのため今回の説明では gpt-oss 120b を例に上げていますが、実際に使う場合はもっとパラメータ数が多いモデルを使うことをお勧めします。パラメータ数が少ない Local LLM をエージェントとして使ってみると、なかなか思い通りに動かなかったりと割と暴走しがちです。より上位モデルを使うと安定したりします。

もちろんサンドボックスなどクローズドな環境で動作テストに使う場合は利用できますので、テスト時のトークン数節約目的とか、いろいろと応用できるのではないかと思います。

APU 内蔵 GPU でもローカル LLM を走らせてみる

以前 ROCm 非対応の Radeon RX 6400 でも、環境変数の設定だけで ROCm 版の ollama を走らせることができました。同じ方法で APU の内蔵 GPU でもローカル LLM を実行できるので実際に試してみました。

今回使用した CPU 内蔵 GPU は以下の 2つです。いずれも DDR5-5600 を使用しています。

CPU (APU)内蔵 GPUアーキテクチャCUspfp32 FLOPS
Ryzen 7 9700XRadeon 610M RDNA2 gfx10372 CU128 sp486.4 GFLOPS
Ryzen 7 7840HSRadeon 780MRDNA3 gfx110312 CU768 sp8294.4 GFLOPS

インストール方法など

事前に UEFI (BIOS) 設定で、内蔵 GPU のフレームバッファの割当をできるだけ増やしておいてください。今回は Ryzen 7 9700X では 16GB、Ryzen 7 7840HS では 8GB に設定しています。

  1. OS は Linux を直接インストールしています
    • Ubuntu 24.04LTS (Desktop 版最小構成)
  2. ollama をインストールします
    • 公式手順どおりです
    • curl -fsSL https://ollama.com/install.sh | sh
  3. ollama の起動設定ファイルを開きます
    • sudo systemctl edit ollama.service
  4. エディタが起動したら 3行目からの空行に以下の 2行を挿入します
    • Ryzen 7 9700X (RDNA2) の場合
      • [Service]
        Environment="HSA_OVERRIDE_GFX_VERSION=10.3.0"
    • Ryzen 7 7840HS (RDNA3) の場合
      • [Service]
        Environment="HSA_OVERRIDE_GFX_VERSION=11.0.2"
  5. 保存して終了したら以下のコマンドを実行します
    • sudo systemctl daemon-reload
    • sudo systemctl restart ollama

実行方法

  1. コマンドラインから直接モデル名を指定して実行します
    • ollama run gemma2:9b
  2. あとは質問などをコンソールから入力できます

もし詳細 (token/s など) を表示させたい場合は質問の前に「/set verbose [ENTER]」を入力しておきます。終了は Ctrl-D です。

実行中に別のターミナルを開いて、コマンドラインから ollama ps を実行することで GPU への割当状況を確認することができます。100% GPU になっていれば OK です。

oga@ub24llm:~$ ollama ps
NAME         ID              SIZE      PROCESSOR    UNTIL
gemma2:9b    ff02c3702f32    9.4 GB    100% GPU     4 minutes from now

実行結果

実際に試した結果は以下のとおりです。CPU のみの場合と比べています。

9b model (gemma2:9b) の場合

CPUGPUGPU割合使用メモリtoken/s
Ryzen 7 9700Xなし0%7.7 GB8.71 tps
Ryzen 7 9700XRadeon 610M100%7.3 GB5.88 tps
Ryzen 7 7840HSなし0%9.0 GB9.02 tps
Ryzen 7 7840HSRadeon 780M100%7.3 GB12.89 tps

Ryzen 7 9700X では GPU Radeon 610M を使用した方が速度が落ちているのは予想通りです。この GPU は 2CU 128sp しかなく CPU よりも演算性能が劣ります。Ryzen 7 9700X の Zen5 は AVX512 命令が同時に 2命令走るため 8 core でも 256sp 相当、クロック差を考慮すると CPU の方が 4倍以上演算能力が高いことになります。

逆に Ryzen 7 7840HS の場合は 768sp × 2ALU の GPU を搭載しており、GPU の方が何倍も演算能力が高いことになります。ですが LLM の場合は演算能力だけでなくメモリ速度の影響を強く受けます。APU ではメモリ帯域で頭打ちになるため、あまりパフォーマンスが変わらないのではないかと思ってましたが少々予想外でした。この結果だけ見るとGPU の方が 40% ほど速くなっています。なお NPU は未使用です。

以下他のモデルでの結果です

14b model (phi4:14b)

CPUGPUGPU割合使用メモリtoken/s
Ryzen 7 9700Xなし0%10 GB5.73 tps
Ryzen 7 9700XRadeon 610M100%12 GB1.96 tps
Ryzen 7 7840HSなし0%11 GB6.22 tps
Ryzen 7 7840HSRadeon 780M80%10 GB6.59 tps

14b のモデルではフレームバッファ割当 8GB の Radeon 780M では VRAM 領域にすべて載りませんでした。そのため 20% は CPU が用いられており CPU と GPU の差は小さくなっています。

他のモデルや他の GPU 利用時の結果は↓こちらのページにまとめています。Wiki なので逐次更新しています。

CPU の速度差

上の結果を見ると CPU 利用時は Ryzen 7 9700X よりも Ryzen 7 7840HS の方がパフォーマンスが高いように見えます。でも実際は演算性能は Zen5 の 9700X の方が上で、Desktop 向けなので電力&冷却も 9700X の方が有利です。

これまでの表の結果を見ると動作時の使用メモリ容量が 7.7GB と 9.0GB で異なっているので、走っている ollama の runner が異なっている可能性があります。runnner によって使用する CPU 命令に違いがあり、最適化方法が異なっている可能性があります。また動作プラットフォームを変えると逆転することがあるため、計測環境の不一致も考えられます。どちらが速い、等の結論を出すにはまだ早いようです。

以下は異なる OS 下での ollama による違い調べたものです。token/s が大きい順に並べています。WSL2 の結果を見ると 9700X の方が速くなっています。

9b (gemma2:9b) CPUのみ

OSCPU使用メモリtoken/s
Windows11 + WSL2Ryzen 7 9700X7.7 GB9.46 tps
LinuxRyzen 7 7840HS9.0 GB9.02 tps
LinuxRyzen 7 9700X7.7 GB8.71 tps
Windows11Ryzen 7 9700X7.7 GB8.66 tps
Windows 11 + WSL2Ryzen 7 7840HS9.0 GB8.59 tps

演算能力で大きく異なるはずの 9700X と 7840HS でも結果としてはあまり違いが生じない結果となっています。使用している RAM の速度が同一なので、メモリ帯域による限界ではないかと思われます。

まとめなど

さまざまな GPU で試した結果を見ても、やはりメモリ速度が非常に重要であることがわかります。CPU 内蔵 GPU (APU) ではメモリ帯域に制限があるため、いくら演算能力が高くても外付け GPU ほどの大幅な高速化は期待できません。それでも Ryzen 7 7840HS は GPU の方が速度が出ていますので、使えるケースでは活用していきたいところです。

関連ページ

ローカル LLM と VRAM メモリ速度

パラメータ数とメモリ帯域

LLM はパラメータ数が多い方が性能が高いですがその分多くの RAM を必要とします。例えばパラメータ数が 32b の LLM モデルの場合、単純に考えるとパラメータだけでも fp32 で 128GB、fp16 でも 64GB の規模感です。4bit に量子化できたと仮定しても最低 16GB 以上、実際には 18GB 程度のメモリが必要です。

これらのパラメータは演算を行うたびに毎回メモリから読み込まれます。そのため LLM の推論にはパラメータを格納するメモリ容量に応じたメモリの転送速度 (メモリ帯域) が必要になることがわかります。

例えば PC 用メモリの DDR4-3200 2ch (128bit) の転送レートはピークで 51.2GB/s です。この場合 4bit 量子化した 18GB のパラメータを最大レートで読み込めたとしても秒間 2.8回しか読み込むことができません。1 Token 生成するたびに全パラメータが 1回だけロードされると仮定しても、最大で 2.8 token/s の速度しか期待できないことになります。実際に DDR4-3200 を搭載した CPU Ryzen 9 3950X での 32b モデルの推論結果は 2.16 token/s で、この数値を下回っていました。

もちろん実際にはもっと多くの帯域が必要になるかもしれませんし、逆に MoE のようにモデル構造によっては推論に必要なメモリが少なく済む可能性があります。

GPU と VRAM 速度

GPU は並列演算に特化しており、同時に大量のデータを扱うことができます。そのため高性能な GPU には、性能に見合うだけのより高速な専用メモリが VRAM として搭載されています。

一般的に CPU よりも GPU の方が演算能力が高く VRAM 速度も速いので、パラメータをできるだけ VRAM に載せ、GPU 上で動作させることが高速化に繋がります。

例えば GeForce RTX 2080Ti はメモリ帯域は 616 GB/s と高速です。CPU (DDR4-3200) と比べると 12倍も速く、仮に 18GB のモデルがすべて VRAM に収まったと仮定すると 1秒に 34回読み出せる計算になります。ただし実際は VRAM 容量が 11GB と少ないため残念ながら 18GB のパラメータは VRAM から溢れます。PC 向けのビデオカードでは VRAM 容量が小さいことが多く、大きな制限となっています。

ollama のマルチ GPU 推論と VRAM

ollama では複数のビデオカードを併用することで、大きなモデルも分割して VRAM に載せることができるようになります。1台では入り切らない大きなモデルも複数台集めれば高速な VRAM 上で走らせられるようになるわけです。ですが残念ながらすべての GPU が同時に動いているわけではありません。パラメータはレイヤー毎に分割されるので、前段レイヤーの出力を受け取ってから次のレイヤーの演算が走ります。GPU も前の GPU の結果が出るまで待つことになります。

よって現時点では、ビデオカードを複数台接続しても時間あたりの演算能力が増えるわけでは無いようです。将来的には別の方法が登場するかもしれませんが、今のところビデオカード複数台使う目的は GPU の並列化や演算能力の増強ではなく、あくまでトータルの VRAM 容量を増やすことにあります。

  • 1台分の VRAM に収まる小さいモデルはビデオカードを増やしても速度が変わらない
  • 直列動作なので異なる性能のビデオカードでも組み合わせられる
  • 台数が増えればそれだけ GPU が休んでいる時間が増え稼働率は下がる

そのため家に眠っていた旧世代のビデオカードを再利用することができますし、ビデオカードを 5台つないだからといって必ずしも消費電力が 5倍になるわけではありません。

メモリ速度からの推論速度の上限を大雑把に計算してみる

少々乱暴ですが、GPU のメモリ速度とメモリ使用量から推論の限界速度がどれくらいなのか割り出してみました。あくまでメモリ速度への依存度が高いことが前提となっています。

先程も例に上げた GeForce RTX 2080Ti の場合 616 GB/s で、かつ 14b (phi4:14b) 実行時の使用メモリ容量は 10GB となっています。よって 1秒間に 61.6 回読み込める計算なので、メモリ速度から見た推論速度の予測上限値は 61.6 になります。実際の推論速度は 51.33 tps でした。

GPUメモリ速度メモリ使用量token/s予測上限値
RTX 2080Ti616 GB/s10GB51.33 tps61.60

複数台の GPU に分散される場合は、それぞれの GPU に割り当てられるメモリ容量から個別に求めて加算します。

予測上限値 = ( 1 / ∑ (GPU毎の使用メモリサイズ / GPU のメモリ速度) )

VRAM に乗らず GPU にも分散される場合は、CPU の割合からメモリ使用量を求めてから同じように加算しています。

予測上限値 = (1/( (CPUの使用メモリサイズ / CPU メモリ速度) + ∑ (GPU毎の使用メモリサイズ / GPU のメモリ速度)))

今まで集めたケースそれぞれで予測値を計算して、まとめページの表に追加してみました。こちらのページで右端にある「mpr」がメモリ速度から求めた予測上限値となります。

以下の表は上のページからの抜粋です。複数 GPU のケースがわかりやすいように 70b (llama3.3:70b) のデータを選びました。

GPUVRAM合計メモリ使用量GPU割合token/s予測上限値
RTX4060Ti16GB46GB35%1.65 tps2.57
RTX4060Ti
RTX2080Ti
27GB48GB57%2.22 tps3.28
RTX4060Ti x2
RTX2070S
40GB49GB83%3.08 tps3.40
RTX4060Ti x2
RTX2070S
GTX1080
48GB51GB94%4.25 tps4.68
RTX4060Ti x2
RTX2070S
GTX1080
GTX1070
56GB55GB100%5.10 tps5.50

GPU が複数台接続されている場合は、それぞれの VRAM 容量に応じて均等にメモリが割り当てられているものとみなしています。実際の VRAM 割り当てを見ているわけではないのでモデルサイズが小さい場合は誤差が生じます。例えば小さいモデルが速い GPU の VRAM にすべて収まるような場合でも、遅い VRAM の GPU と平均化されてしまうため予測値が実測値よりも低くなることがあります。

以下の表はシングル GPU (+CPU) のケースで 14b (phi4:14b) の結果です。

GPUVRAM合計メモリ使用量GPU割合token/s予測上限値
RX76008GB10GB80%11.43 tps15.72
RTX2070S8GB10GB76%14.67 tps22.86
RTX4060Ti16GB12GB100%27.92 tps24.00
RTX2080Ti11GB10GB100%51.33 tps61.60

大半は token/s として予測未満の値が出ているように見えますが、GeForce RTX 4060 Ti では予測した上限値よりも高いスコアが出ています。RTX 3000 のデータがないのでわかりませんが、RTX 4000/5000 などの新しい世代では必ずしも計算が合わないかもしれません。おそらく使用メモリには必ずしも毎回ロードされないパラメータ領域があるか、またはキャッシュが効きやすい短時間に何度も参照される領域も含まれているのだと考えられます。

まとめなど

ビデオカードを追加する場合にどの程度の速度向上が見込めるかをある程度予想できるので、無駄な投資をしなくて済むのではないかと思って計算してみました。ただし新しい世代の GPU では予想よりも速くなる可能性があるため、必ずしもこの通りの結果にはならないようです。 RTX の 4000 世代ではキャッシュメモリが増加しているので、もっとモデルの構造やアルゴリズムも考慮しないといけなかったのかもしれません。

関連ページ

ビデオカード RADEON を複数台使ってローカル LLM を動かす

GeForce だけでなく RADEON でもビデオカードを複数台使ってローカル LLM を走らせてみました。自分だけの Chat AI として使えますし、もちろんパラメータ数が同じなら蒸留版 DeepSeek R1 も動きます。

インストール手順

RADEON Vega 64/56 は VM への GPU パススルーができないこともあり、PC には Linux を直接インストールしています。

  1. RADEON を複数枚差した PC に Ubuntu 24.04 をネイティブインストール
    • 通常の Desktop 版を最小インストール
  2. ログインして OS の更新
    • sudo apt update; sudo apt upgrade -y
  3. ollama Linux 版インストーラーを公式の手順に従い実行
    • curl -fsSL https://ollama.com/install.sh | sh
  4. テストするためののモデルのダウンロード
    • ollama pull llama3.3:70b
    • ollama pull qwen2.5:32b
    • ollama pull gemma2:27b
    • ollama pull phi4:14b
    • ollama pull gemma2:9b
    • ollama pull gemma2:2b
  5. 実行
    • 例: ollama run gemma2:27b

特にドライバなどのインストールは不要で、ollama のインストールだけで GPU が認識されます。ただし使用可能な GPU は GCN の場合 Vega 56/64 以降、RDNA2 の場合は RX6800 以上、RDNA3 は RX7600 以上となります。APU は含まれません。

RADEON の推論速度の比較 (27b)

以下は gemma2 27b の結果です。token/s の数値が大きいほど高速に出力できることを意味しています。VRAM 8GB でもビデオカード 3枚使うことで GPU が 100%、14.55 token/s と CPU の 5.7倍の速度で実行できるようになりました。

VRAM合計GPU / CPU必要RAMGPUの割合token/s
なしRyzen 9 3950X18GB0%2.54
8GBRyzen 9 3950X
RX 7600
18GB45%3.52
8GBRyzen 7 9700XX
RX Vega 64
18GB45%4.36
16GB (2台)Ryzen 9 3950X
RX 7600
RX Vega 64
21GB78%6.00
16GB (2台)Ryzen 7 9700X
RX Vega 64
RX Vega 56
21GB79%7.45
24GB (3台)Ryzen 9 3950X
RX 7600
RX Vega 64
RX Vega 56
23GB100%14.55
gemma2 27b の推論速度

RADEON RX7600 (RDNA3) と Vega 64/56 (GCN5) の組み合わせでもきちんと動作しています。GeForce と同じように、異なる世代の混在でも複数の GPU を認識し、マルチ GPU のローカル LLM 推論に使えることがわかりました。

マザーボード上には PCIe x16 スロットが 2つしか無いので、ビデオカードの 3枚目は外部接続です。SSD 用の M.2 スロットに OCulink 変換カードを差し込み、OCulink ケーブル経由で MINISFORUM の DEG1 に接続しています。

RADEON の推論速度の比較 (14b)

14b の結果です。こちらは 8GB のビデオカード 2枚で VRAM に載っています。

VRAM合計GPU / CPU必要RAMGPUの割合token/s
なしRyzen 9 3950X18GB0%4.63
8GBRyzen 9 3950X
RX 7600
10GB82%11.43
8GBRyzen 7 9700XX
RX Vega 64
18GB82%13.97
16GB (2台)Ryzen 9 3950X
RX 7600
RX Vega 64
14GB100%18.00
16GB (2台)Ryzen 7 9700X
RX Vega 64
RX Vega 56
14GB100%22.71
phi4 14b の推論速度

テスト時の PC が異なるので公平な比較とは言えませんが、Vega 64/56 は古い GPU ながらメモリが高速なので RX7600 よりも LLM の推論速度が速いようです。以下は今回使用した GPU のスペックです。

GPUArchspfp32 GflopsVRAMmem b/w
RX 7600RDNA32048 sp217508GB288 GB/s
RX 6400RDNA2768 sp35654GB128 GB/s
RX Vega 64GCN54096 sp126658GB484 GB/s
RX Vega 56GCN53584 sp105448GB410 GB/s

より多くのモデルの結果及び GeForce 含めた結果は以下のページにまとめています。

RADEON RX 6400 (6500XT) でも LLM を使えるようにする

RADEON RX 6400 は RDNA2 世代の下位グレードの GPU です。VRAM 4GB に 12CU 768sp と性能もかなり控えめで、APU 内蔵の GPU に近いスペックです。そのかわり補助電源不要で Low Profile PCI 版のビデオカードも存在します。

公式でも ROCm には非対応ですが、ollama のドキュメントには対応方法が書いてあるので試してみました。なおドキュメント(以下のリンク)には 2025/02/15 現在 RX 5400 と書かれていますが、gfx1034 のことを差しているので RX 6400 (または 6500XT) の間違いだと思われます。

方法: ollama の環境変数 HSA_OVERRIDE_GFX_VERSION に “10.3.0” を設定します。

  1. sudo systemctl edit ollama.service
    • 使用するエディタを指定したい場合は以下のようにする
    • sudo EDITOR=vi systemctl edit ollama.service
  2. エディタが起動したら 3行目からの空行に以下の 2行を挿入する
    • [Service]
    • Environment=”HSA_OVERRIDE_GFX_VERSION=10.3.0″
  3. 保存して終了したら以下のコマンドを実行する
    • sudo systemctl daemon-reload
    • sudo systemctl restart ollama

この設定で RX 6400 でも GPU を使って走らせることができるようになりました。VRAM が 4GB しかないので限界はありますが、小さいモデル限定なら CPU よりは速度が出ています。ただし VRAM 容量や速度を考えると使用できるのは 7b くらいまでになるかと思います。

また同じ世代の GPU 同士に限りますが RX 6400 を複数台使用した場合でもきちんと動作しました。ドキュメントには “HSA_OVERRIDE_GFX_VERSION_番号=10.3.0” のように、環境変数名にデバイス番号を指定することで異なる世代の RADEON を組み合わせられるように記載されていますが、残念ながらうまく動きませんでした。

RX 6400 による推論時間は以下のとおりです。2枚使用した場合と CPU のみの結果も載せています。

model RX6400 x2 (合計 8GB)
token/s
RX6400 (4GB)
Token/s
CPUのみ
Token/s
llama3.3:70b1.05 (16%)1.03 (8%)1.01
qwen2.5:32b2.42 (34%)2.29 (17%)2.16
gemma2:27b2.87 (38%)2.70 (21%)2.54
phi4:14b6.94 (72%)5.60 (39%)4.63
gemma2:9b11.70 (85%)8.52 (51%)6.94
qwen2.5:7b18.52 (100%)13.05 (69%)9.27
gemma2:2b40.60 (100%)46.33 (100%)19.73
RADEON RX 6400 を使った各種モデルの推論時間の比較

関連ページ

普通の PC に GPU 5枚繋いで Llama 70b を動かしてみる

最近は一般の PC でも LLM (Large Language Model) を走らせることができるようになっています。いわゆる ChatGPU のローカル版で、自分の PC 上で動くため API 利用料金などを気にせずに使うことが可能です。ただし動作可能な LLM の規模はビデオカードの VRAM 容量に依存します。

Ollama は複数の GPU に対応しており、前回 VRAM 8GB の GeForce GTX でも十分戦力になることがわかったので更にいろいろと台数をやしてみました。

結果、llama 70b のモデルを GPU 上で走らせるために必要だったビデオカードは 5台で合計 VRAM は 56GB、最終的な速度は 4 tps。CPU よりは数倍速いですが、少々実用には厳しいようです。

使用したビデオカードは以下の通りです。

70b の生成速度のまとめ

ビデオカードの種類や枚数毎の llama 70b の生成速度の違いを表にまとめました。下に行くほどビデオカードの台数が増えています。

VRAM合計GPU / CPU必要RAMCPUの割合GPUの割合token/s
なしRyzen 7 9700X46GB100%1.02
8GBRyzen 7 9700X
GTX 1080
47GB83%17%1.32
8GBRyzen 7 9700X
RX Vega 64
47GB83%17%1.34
16GB (2台)Ryzen 7 9700X
GTX 1080
GTX 1070
48GB67%33%1.45
16GB (2台)Ryzen 7 9700X
RX Vega 64
RX Vega 56
48GB65%35%1.55
32GB (2台)Ryzen 9 3950X
RTX 4060Ti
RTX 4060Ti
47GB32%68%2.22
40GB (3台)Ryzen 9 3950X
RTX 4060Ti
RTX 4060Ti
RTX 2070S
49GB17%83%3.08
48GB (4台)Ryzen 9 3950X
RTX 4060Ti
RTX 4060Ti
RTX 2070S
GTX 1080
51GB5%95%3.94
56GB (5台)RTX 4060Ti
RTX 4060Ti
RTX 2070S
GTX 1080
GTX 1070
55GB100%4.09
llama 70b の推論速度

表にある必要 RAM 及び CPU/GPU の割合はそれぞれ実行時に ollama ps コマンドで表示される数値です。複数のビデオカードに分割できるとはいえ、台数が増えれば増えるほど必要 RAM が増えており、メモリ効率も悪くなっていることがわかります。

枚数を増やすほど消費メモリが増え、ますますビデオカードを増やす必要が生じてしまいます。5台使用時の必要メモリは CPU 単体のみの場合と比べて 10GB ほど増えおりあまり効率はよくありません。やはり VRAM は多ければ多い方が良いです。

動作環境など

マザー上には PCIe x16 スロットが 2つしか無いのでそれ以外の GPU は外付けです。SSD 用の M.2 (PCIe x4) とマザーボード上の PCIe x1 スロットを利用して外部に 3台のビデオカードを繋いでいます。

↓動作時の様子。一番上が MINISFORUM DEG1 (OCulink 接続) に載った GeForce RTX 2070 Super、床に立ててあるのが PCIe x1 接続の GeForce GTX 1080 と GTX 1070。

前回Proxmox 上の VM にパススルーしていましたが、少しでも性能を上げるために今回は SSD に直接 Ubuntu をインストールしています。M.2 スロットはすべて GPU の接続に使用したため SATA SSD を使用しています。

前回は VM だったので RADEON RX Vega 64/56 をパススルーできなかったのですが、OS を直接インストールしたことで Vega でも動くようになりました。Ollama が対応しているのは Vega 56/64 以降なので残念ながら RADEON RX 480 (Polalis) は使用できませんでした。とりあえず手持ちの RADEON でも複数台使用した動作を確認することができました。

GPU 台数とモデルサイズの関係

複数台 GPU を使用した場合に VRAM に 100% 載るモデルサイズの目安は以下のとおりです。

VRAM の組み合わせ合計 VRAM 容量モデルサイズ(Q4)モデルの例
8GB + 8GB16GB14bphi4:14b など
8GB + 8GB + 8GB24GB27bgemma2:27b など
16GB + 8GB24GB32bqwen2.5:32b など

組み合わせの例。

VRAM の組み合わせ合計 VRAM 容量モデルtoken/s
GeForce GTX 1080
GeForce GTX 1070
16GBphi4:14b16.19
RADEON RX Vega 64
RADEON RX Vega 56
16GBphi4:14b22.71
GeForce RTX 2070 Super
GeForce GTX 1080
GeForce GTX 1070
24GBgemma2:27b12.89
GeForce RTX 2070 Super
GeForce RTX 4060Ti
24GBqwen2.5:32b13.56

より詳しい数値は以下のページにまとめています。

関連ページ