Docker で AMD GPU を使う: Aiming Off のブログ

2022 年にコンテナで GUI / GPU を使うという記事を書いたが、その後だいぶ状況は変わってきている
当時は AMD GPU でできることが限られていたが、現在は ROCm のレベルが上がってきており NVIDIA じゃなければダメ…とは言えなくなってきている
改めて現時点で AMD GPU でできることをおさらいしておく（今 GPU やメモリが高騰しているしね…）

ここでは以下のような環境を前提にしている。

ホスト OS: Debian 13 (trixie)
Kernal: 6.18.5 (trixie-backports)

参考: 2026年のローカルLLM事情を整理してみた

Ollama

Ollama は手軽にオープンソース大規模言語モデル（LLM）を起動・管理できるプラットフォーム

【2026-04-21 追記】
「Ollama」には多数の問題点があるという GIGAZINE の記事を読む限り、 良識のある者は Ollama は使わないほうが良い と思います

オフィシャルの Docker image を使ってもいいし GitHub に置いた ollama-docker を使ってもいい

私は GLM-OCR を試すために Ollama を使ってみたが、非常に簡単に使うことができた
ollama-docker を使うならば以下のようにすればすぐに使える

$ docker compose exec ollama ollama run glm-ocr

llama.cpp

llama.cpp は Ollama よりは使い勝手が良くないが、チューニングをすることで Ollama よりも高速にオープンソース大規模言語モデル（LLM）を実行できる

オフィシャルの Docker image に ROCm 版があるのでそのまま使うこともできるが、多少使い勝手を改善したものを GitHub の llama-cpp-docker に置いた

Ollama では GPU の VRAM 容量により実行できるモデルに制限を受けるが、 llama.cpp は CPU MeE Offloading により限られた VRAM でも大規模 MoE モデルを実用的な速度で動かすことができる
ローカルLLMを試すに NVIDIA GPU を使った例が出ている

私も同様のことを試したが、自分の環境は APU と dGPU の両方が搭載されており、ちょっと違う状況がになった

元々 APU は VRAM ではなく CPU 側のメモリを扱えるようになっているため、 --cpu-moe や --n-cpu-moe を指定するとかえって効率が落ちてしまう結果となった
--split-mode を none にして dGPU だけで処理するようにすると想定した動きをしているように見える

試行回数が少ないので性能的なところははっきりしないが、 MoE を使わず遅い APU 側の負荷が大きくなっても遜色ない性能が出ているようには見える
ここで試したモデルは gpt-oss-20b なので、もっと大容量の VRAM を必要とするモデルならば差が出てくるかもしれない

MoE 関連パラメタ無し

[ Prompt: 188.9 t/s | Generation: 25.1 t/s ]

| memory breakdown [MiB] | total    free     self   model   context   compute       unaccounted |
|   - ROCm0 (RX 6600M)   |  8176 =  2118 + ( 5760 =  3454 +    1030 +    1276) +            297 |
|   - ROCm1 (680M)       | 15683 = 12867 + (10491 =  7495 +    2060 +     935) + 17592186036740 |
|   - Host               |                   1628 =   586 +       0 +    1041                   |

`--cpu-moe` (`LLAMA_ARG_CPU_MOE=1`)

[ Prompt: 105.9 t/s | Generation: 17.9 t/s ]

| memory breakdown [MiB] | total    free     self   model   context   compute       unaccounted |
|   - ROCm0 (RX 6600M)   |  8176 =  6146 + ( 1734 =   245 +    1031 +     456) +            295 |
|   - ROCm1 (680M)       | 15683 = 18944 + ( 3453 =   996 +    2058 +     398) + 17592186037701 |
|   - Host               |                  11218 = 10949 +       0 +     268                   |

`--n-cpu-moe 12` (`LLAMA_ARG_N_CPU_MOE=12`)

[ Prompt: 99.6 t/s | Generation: 19.7 t/s ]

| memory breakdown [MiB] | total    free    self   model   context   compute       unaccounted |
|   - ROCm0 (RX 6600M)   |  8176 =  6174 + (1705 =   218 +    1030 +     456) +            296 |
|   - ROCm1 (680M)       | 15683 = 16112 + (8335 =  5877 +    2060 +     398) + 17592186035651 |
|   - Host               |                  6036 =  5768 +       0 +     268                   |

`--split-mode none --main-gpu 0 --n-cpu-moe 12`
(`LLAMA_ARG_SPLIT_MODE=none LLAMA_ARG_MAIN_GPU=0 LLAMA_ARG_N_CPU_MOE=12`)

[ Prompt: 198.3 t/s | Generation: 29.9 t/s ]

| memory breakdown [MiB] | total   free    self   model   context   compute    unaccounted |
|   - ROCm0 (RX 6600M)   |  8176 =  930 + (6950 =  6095 +     456 +     398) +         295 |
|   - Host               |                 5817 =  5768 +       0 +      49                |

追試

やはりモデルによっては圧倒的に dGPU で MoE を使った方が速い

最初に試した Qwen3-30B-A3B:Q8_0 では:

MoE 無し: モデルロード時にエラー
--cpu-moe : モデルロードには成功するが、プロンプト入力後システムが激重になって動作不能
恐らく MoE も APU も同じメモリ資源をピンポンしていて swap 出まくりになったと思われる (--cpu-moe を調べる価値は無さそう)

     model      |                   no MoE                     | --split-mode none --main-gpu 0 --n-cpu-moe 12
Qwen3-8B:Q8_0   | [ Prompt: 215.1 t/s | Generation:  9.0 t/s ] |          モデルロード時にエラー
Qwen3-8B:Q4_K_M | [ Prompt: 196.7 t/s | Generation: 13.2 t/s ] | [ Prompt: 427.8 t/s | Generation: 34.5 t/s ]
Qwen3-4B:Q8_0   | [ Prompt: 266.6 t/s | Generation: 16.3 t/s ] | [ Prompt: 864.0 t/s | Generation: 40.5 t/s ]

PyTorch on ROCm

pyTorch もオフィシャルで ROCm 対応が進んでいるので、割といろんなものが動かせるようになっている

オフィシャルの Docker image を使う手もあるが、このイメージでは pyTorch が /opt/venv という扱いにくい場所にインストールされている（pip で Python パッケージを追加インストールする際にも Docker インスタンス内の /opt/venv 配下に入れることになる）ため、以前書いた ROCm-docker 上で pyTorch をインストールする方がベター

ROCm-docker を使う場合には以下のようにして pyTorch をインストールする

$ docker compose run --rm devterm

$ ROCM_VER=7.1
$ GFX_ARCH=gfx103X-dgpu
$ python3 -m venv torch
$ . torch/bin/activate
(torch) $ pip install uv
(torch) $ uv pip install torch torchvision torchaudio \
        --index-url https://download.pytorch.org/whl/rocm${ROCM_VER} \
        --extra-index-url https://rocm.nightlies.amd.com/v2/${GFX_ARCH}

【追記】現在の私の ROCm-docker はマルチステージ Dockerfile に変更するとともに uv コマンドを devterm service のコンテナイメージに含めている
uv を使う場合には以下のようにすればいい

$ ROCM_VER=7.1
$ GFX_ARCH=gfx103X-dgpu
$ uv venv torch
$ . torch/bin/activate
(torch) $ uv pip install torch torchvision torchaudio \
        --index-url https://download.pytorch.org/whl/rocm${ROCM_VER} \
        --extra-index-url https://rocm.nightlies.amd.com/v2/${GFX_ARCH}

ROCM_VER と GFX_ARCH はバージョンや環境に合わせて変更する
GFX_ARCH はオフィシャルの pyTorch でサポートしていない GPU のために追加するコンポーネントであり、どういう種類のものがあるかは https://rocm.nightlies.amd.com/v2/ を参照
自分の環境の AMD GPU のアーキが何であるかは rocminfo コマンドで確認できる

$ rocminfo | grep gfx
  Name:                    gfx1031                            
      Name:                    amdgcn-amd-amdhsa--gfx1031

オフィシャルの pyTorch でサポートしている GPU アーキであれば GFX_ARCH の指定や --extra-index-url の指定は必要ない
そうでない場合は表示されたものに近い GPU アーキのものを指定する

Aiming Off のブログ

オッサンの IT ライフ

2026-02-11