ローカルLLM構築ハンズオン

▾ 目次 — 概要と前提 ハンズオン手順 1 GPU の確認 2 Ollama の導入 3 GPU を有効にする 4 モデルを動かす 5 速度を測る 6 Docker の導入 7 Open WebUI の起動 8 ブラウザから使う 9 再起動して確認 10 片付け A P P E N D I X 考 慮ポイント A 実行方式の選び方 B モデルの選び方 C コンテキスト長とメモリ D ネットワークと安全 E 運用・更新 F 他のハードウェア G つまずきやすい点 H ハンズオン運営のコツ 確認チェック

• #p3
• #p4
• #p5
• #p6
• #p7
• #p8
• #p9
• #p10
• #p11
• #p12
• #p13
• #p14
• #p15

HANDS-ON GUIDE ／ OLLAMA + OPEN WEBUI ローカルLLM構築ハンズオン 内蔵 GPU つきの小型 PC 1 台に、LLM の実行エンジン Ollama とチャット画面 Open WebUI を入 れ、ブラウザから日本語で会話できるところまでを組み立てます。手順はすべて実機で動作を確認 したものです。 所要時間 約 90 分（モデルのダウンロードを除く） 難易度 Linux のコマンド操作ができる方向け 動作確認 2026-09-28〜29 概要と前提 できあがる構成 Open WebUI Docker コンテナ／:8080（チャット画面） 手元の PC SSH トンネル → ブラウザで http:��localhost:8080 Ollama systemd サービス／127.0.0.1:11434（API） 内蔵 GPU（Radeon 780M） Vulkan（Mesa RADV）経由で使用 動作確認した環境 項目 内容 機種 MINISFORUM EliteMini（AMD Ryzen 7 255、8 コア 16 スレッド） GPU 内蔵 Radeon 780M 系（gfx1103）。VRAM 2GiB（BIOS 割り当て）＋ 共有メモリ （GTT）約 14.6GiB メモリ／ディス 32GB（OS から見えるのは 29GiB）／NVMe 1TB ク OS Ubuntu Server 24.04.5 LTS（カーネル 6.8） ソフトウェア Ollama 0.34.4、Open WebUI v0.11.4、Docker 29.1.3（Ubuntu 公式パッケージ） NVIDIA GPU 搭載機や GPU なしの機械でも、手順の大半はそのまま使えます。違いは付録 Fにま

• #p14

とめました。 始める前に • サーバーに SSH で入れ、 sudo が使えること。以降のコマンドは、特に断りがなければサー バー上で実行します。 • ディスクの空きが 30GB 以上あること（モデル 1 つで 5〜16GB 使います）。 • インターネットに出られること。モデルのダウンロードは 1 つ数 GB あるので、会場の回線 を全員で使う場合は付録 Hを参照してください。 • ファイアウォール（ufw）は有効にしておくことをおすすめします。この手順ではポートを外 に開けず、SSH トンネルで画面を見ます。 表記 <user> 、 <server> は各自の環境のユーザー名・サーバーのアドレスに置き換えてくださ い。手順ごとの「確認」欄はチェックを付けて進捗管理に使えます（チェックはこのブラウザ にだけ保存されます）。 GPU が認識されているか確認する まず、内蔵 GPU が OS にドライバ付きで認識されていることを確かめます。ここでは何も変更しま せん。 lspci -nnk | grep -A3 -Ei 'vga|display' コピー ls -l /dev/dri /dev/kfd sudo dmesg | grep -i amdgpu | tail -n 5 確認 Kernel driver in use: amdgpu と表示され、 /dev/dri/renderD128 と /dev/kfd が ある。dmesg に Initialized amdgpu が出ている。 次に、作業ユーザーが GPU のデバイスファイルを使えるよう render ・ video グループに入れま す。 sudo usermod -aG render,video $USER # 反映にはログインし直しが必要 exit コピー

• #p15

確認 SSH で入り直して id を実行すると render と video が含まれている。 ヘッドレス運用（モニター未接続）だと dmesg に Cannot find any crtc or sizes と出ます が、異常ではありません。 Ollama をインストールする Ollama はモデルのダウンロード・実行・API 提供をまとめて行うソフトです。公式のインストー ル用スクリプトをいったんファイルに保存し、中身を確認してから実行します。 curl -fsSL https:��ollama.com/install.sh -o ollama-install.sh less ollama-install.sh # 何をするスクリプトか⽬を通す sha256sum ollama-install.sh # 記録しておくと、あとで同じものか確かめられる コピー sudo sh ollama-install.sh スクリプトは次のものを作ります。 • 本体 /usr/local/bin/ollama とライブラリ /usr/local/lib/ollama/ （CPU・Vulkan・ ROCm・CUDA 用） • 専用ユーザー ollama （render・video グループ所属）と ollama.service （自動起動が有 効） • モデルの保存先 /usr/share/ollama/.ollama/models ollama ��version コピー systemctl status ollama ��no-pager journalctl -u ollama -b ��no-pager | grep -Ei 'gpu|vulkan|rocm|dropping' 確認 ollama.service が active (running) 。ログに dropping ROCm device — no rocblas support for gfx target gfx1103 のような行が出ていれば、この時点では CPU だけで動いています（想定どおり。次の手順で GPU を使えるようにします）。 Vulkan で GPU を使えるようにする Radeon 780M（gfx1103）は AMD の GPU 計算基盤 ROCm の公式サポート対象外です。そこで、 グラフィックス API の Vulkan 経由で GPU を使います。まず Vulkan のローダーと Mesa のドライ

グラフィックス

経由

を使います。まず

のローダーと

のドライ

バを入れます。
sudo apt-get update

コピー

sudo apt-get install -y ��no-install-recommends libvulkan1 mesa-vulkan-drivers vulkan-tools
vulkaninfo ��summary | grep -i devicename

確認

deviceName = AMD Radeon 780M Graphics (RADV PHOENIX) のように GPU 名が表示さ

れる。
この状態でも Ollama は内蔵 GPU を「使わない」扱いにします（ログに dropping integrated
GPU; to enable, set OLLAMA_IGPU_ENABLE=1 ）。systemd の上書き設定ファイル（drop-in）で

有効にします。
/etc/systemd/system/ollama.service.d/override.conf

sudo mkdir -p /etc/systemd/system/ollama.service.d

コピー

sudo tee /etc/systemd/system/ollama.service.d/override.conf >/dev/null ��'EOF'
[Service]
# 内蔵 GPU を Vulkan で使う（ROCm は gfx1103 ⾮対応）
Environment="OLLAMA_IGPU_ENABLE=1"
Environment="OLLAMA_VULKAN=1"
# 既定の 4096 では長めの会話や⽂書の読み込みに⾜りない
Environment="OLLAMA_CONTEXT_LENGTH=8192"
EOF
sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -u ollama -n 50 ��no-pager | grep -i 'library='

確認

ログに library=Vulkan type=iGPU total=16.6GiB のような行がある（GPU が使える
メモリ量は BIOS 設定や搭載メモリで変わります）。
待ち受けアドレスはここでは既定（127.0.0.1）のままにしています。ほかの PC から API を直接
使いたい場合は付録 Dを読んでから変えてください。

モデルを取得して動かす
最初の 1 つは軽めの qwen3:8b （約 5.2GB）で動作を確かめます。ふだん使いのおすすめは付録 B
を見てください。

• #p13
• #p12

ollama pull qwen3:8b

コピー

ollama run qwen3:8b "⽇本の首都はどこですか。⼀⽂で答えてください。" ��think=false
ollama ps

確認

回答が返ってきて、 ollama ps の PROCESSOR 欄が 100% GPU になっている。

注意

PROCESSOR が 48%/52% CPU/GPU のように分かれている場合、モデルが GPU のメモリに収

まりきっていません。生成が大きく遅くなります。小さいモデルにするか、コンテキスト長を
下げてください（付録 C）。

速度を測る
GPU が本当に効いているかを数字で確かめます。Ollama の API が返す処理時間から、入力の処理
速度と生成速度（tok/s）を計算するスクリプトです。
bench.sh

��/bin/bash

コピー

# 使い⽅: bash bench.sh <model> [回数]
# CPU のみで⽐べるとき: EXTRA=',"num_gpu":0' bash bench.sh qwen3:8b
MODEL=${1:-qwen3:8b}
N=${2:-3}
EXTRA=${EXTRA:-}
PROMPT="⽇本の四季について、それぞれの特徴を200字程度で説明してください。"
URL=http:��127.0.0.1:11434
# 1回⽬はモデルの読み込み時間を含むので、先に読み込んでおく

curl -s $URL/api/generate -d "{\"model\":\"$MODEL\",\"prompt\":\"hi\",\"stream\":false,\"thi
echo "model=$MODEL"
ollama ps
for i in $(seq 1 $N); do

curl -s $URL/api/generate -d "{\"model\":\"$MODEL\",\"prompt\":\"$PROMPT\",\"stream\":fals
python3 -c '
import json,sys
r=json.load(sys.stdin)
pe=r.get("prompt_eval_count",0); ped=r.get("prompt_eval_duration",1)/1e9
ec=r.get("eval_count",0); ed=r.get("eval_duration",1)/1e9
print(f"prompt: {pe} tok {pe/ped:7.1f} tok/s | gen: {ec} tok {ec/ed:6.1f} tok/s")'

• #p12

print(f"prompt: {pe} tok {pe/ped:7.1f} tok/s | gen: {ec} tok {ec/ed:6.1f} tok/s")'
done

コピー

bash bench.sh qwen3:8b
EXTRA=',"num_gpu":0' bash bench.sh qwen3:8b

# ⽐較⽤: CPU のみ

確認

GPU の生成速度が CPU のみより明らかに速い。参考値（qwen3:8b）: Vulkan 16.0〜
16.6 tok/s、CPU のみ 10.0〜11.5 tok/s。
ほかの人が同時に Ollama を使っていると順番待ちになります（同時処理数は既定で 1）。計測前
に ollama ps で使用中のモデルがないことを確かめてください。

Docker を導入する
Open WebUI は Docker コンテナで動かします。追加のリポジトリが不要な Ubuntu 公式パッケー
ジを使います。
sudo apt-get install -y docker.io docker-compose-v2

コピー

sudo docker version ��format '{{.Server.Version}}'
sudo docker compose version

確認

Docker と Compose のバージョンが表示される。
作業ユーザーを docker グループには入れず、 sudo docker … で操作します。docker グループ
は実質 root 権限になるためです。

Open WebUI を起動する
compose ファイルを置いて起動します。コンテナはホストのネットワークをそのまま使う設定
（ network_mode: host ）にします。理由は付録 D にあります。
/opt/open-webui/compose.yaml

sudo mkdir -p /opt/open-webui
sudo tee /opt/open-webui/compose.yaml >/dev/null ��'EOF'
services:

コピー

• #p13

open-webui:
image: ghcr.io/open-webui/open-webui:v0.11.4

# タグは固定する

container_name: open-webui
network_mode: host

# ポート公開を使わない（ufw を素通りしない）

environment:
- OLLAMA_BASE_URL=http:��127.0.0.1:11434
- PORT=8080
- TZ=Asia/Tokyo
volumes:
- open-webui:/app/backend/data
restart: unless-stopped
volumes:
open-webui:
EOF
sudo docker compose -f /opt/open-webui/compose.yaml up -d

初回はイメージの取得と初期化に時間がかかります（実測で起動から約 85 秒）。準備ができたか
確かめます。
curl -s http:��127.0.0.1:8080/health

コピー

sudo docker exec open-webui python3 -c "import urllib.request,json; print([m['name'] for m i

確認

/health が {"status":true} を返し、コンテナから Ollama のモデル一覧

（ ['qwen3:8b'] ）が取れる。
起動ログに SAWarning: Table '_alembic_tmp_tag' … が出ることがありますが、データベース
移行時の警告で動作に影響はありません。

ブラウザから使う
手元の PCで SSH トンネルを張り、サーバーの 8080 番を手元の 8080 番につなぎます。
⼿元の PC で実⾏

ssh -N -L 8080:127.0.0.1:8080 <user>@<server>

コピー

ブラウザで http:��localhost:8080 を開き、次の順に進めます。
1. すぐに管理者アカウントを作る。Open WebUI は最初に登録したユーザーが管理者になりま
す。

す。 2. 画面上部のモデル選択で qwen3:8b を選び、日本語で話しかける。 3. （任意）管理者設定 → モデル → 既定のモデル で、新しいチャットで最初に選ばれるモデル を決める。 確認 ブラウザで回答が流れるように表示される。回答中にサーバーで ollama ps を実行する と 100% GPU 。 2 人目以降の登録は、管理者が承認するまで保留（pending）になります（Open WebUI の既定動 作）。 再起動しても動くか確認する サービスが自動で立ち上がることを確かめます。ハンズオンの仕上げとしておすすめです。 sudo reboot コピー # ⼊り直してから systemctl is-enabled ollama docker journalctl -u ollama -b ��no-pager | grep -i 'library=' sudo docker ps ��format '{{.Names}} {{.Status}}' curl -s http:��127.0.0.1:8080/health bash bench.sh qwen3:8b 1 確認 両サービスが enabled 、ログに library=Vulkan 、 open-webui が Up 、計測で 100% GPU と再起動前と同程度の速度が出る。 片付け（元に戻す） ハンズオン用の機械を元に戻すときの手順です。上から順に、必要なところまで実行します。 # Open WebUI（会話履歴などのデータも消す場合は down -v） sudo docker compose -f /opt/open-webui/compose.yaml down # Docker sudo apt-get purge -y docker.io docker-compose-v2 containerd runc sudo rm -rf /var/lib/docker /var/lib/containerd # Ollama（モデルも消える） sudo systemctl disable ��now ollama コピー

sudo systemctl disable ��now ollama sudo rm -rf /etc/systemd/system/ollama.service /etc/systemd/system/ollama.service.d \ /usr/local/bin/ollama /usr/local/lib/ollama sudo userdel -r ollama; sudo groupdel ollama sudo systemctl daemon-reload # Vulkan sudo apt-get purge -y libvulkan1 mesa-vulkan-drivers vulkan-tools �� sudo apt-get autoremove # グループ sudo gpasswd -d $USER render �� sudo gpasswd -d $USER video モデルだけ消す場合は ollama rm <モデル名> で足ります。 APPENDIX 考慮ポイント 手順の中で「なぜそうしたか」と、環境を変えるときに判断が必要になる点をまとめます。数値は 前述の動作確認環境での実測です。 実行方式の選び方 Ollama か llama.cpp か Ollama は内部で llama.cpp 系の推論エンジンを使い、モデル管理・API・サービス化まで面倒を見 てくれます。今回は使いやすさを優先して Ollama を選び、GPU を活かせるかを計測して判断しま した。細かい調整（量子化の選択、起動オプション）をしたい場合は llama.cpp を直接使う手もあ ります。 Vulkan・ROCm・CPU の比較（qwen3:8b、Q4_K_M） 方式 設定 Vulkan（採 OLLAMA_IGPU_ENABLE=1 用） OLLAMA_VULKAN=1 ROCm 上記＋ OLLAMA_VULKAN=0 ⼊力処理（短） 600 tok/s ⼊力処理（ ） ⽣成 290 tok/s 16.0–16.6 tok/s 570 tok/s 387 tok/s 15.1–15.9 tok/s HSA_OVERRIDE_GFX_VERSION=11.0 .2 CPU のみ num_gpu: 0 420 tok/s 78 tok/s 10.0–11.5

tok/s • チャットの体感に効くのは生成速度で、Vulkan が最も速い。 • ROCm は gfx1103 を別の GPU（gfx1102）と偽って動かす非公式な使い方です。Ollama や ROCm の更新で壊れるおそれがあります。 • 長い入力の処理は ROCm が約 3 割速いものの、1800 トークンで 4.7 秒と 6.3 秒の差にとど まります。 • GPU が使えるメモリは Vulkan 16.6GiB／ROCm 14.6GiB で、Vulkan の方が大きなモデルを 載せられます。 速度の上限はメモリ帯域で決まる 生成速度は、1 トークンごとにモデルの重みをメモリから読み出す速さでほぼ決まります。内蔵 GPU はメインメモリを共有するので、大きなモデルほど遅くなります（目安として 14B クラスは 8B の半分程度）。例外が次の MoE モデルです。 モデルの選び方 5 つのモデルを、速度と日本語の 5 課題（説明・計算・要約・コード・ビジネス文書）で比べた結 果です。条件は temperature 0、コンテキスト 8192、思考（thinking）は無効（gpt-oss のみ最も 軽い low ）。 モデル 種類 サイズ 割り当て 読み込み gemma4:26b- MoE 16GB 15GB 11.7s 回答の質（主観） 27.3 日本語が最も自然。思考なしだと計 tok/s 算を一度間違える a4b-it-qat gpt-oss:20b ⽣成 MoE 14GB 12GB 9.7s 20.3 計算・コードが最も確実 tok/s 通常 qwen3:8b 5.2GB 6.3GB 4.6s 16.5 ビジネス文書の敬語が不自然 tok/s qwen3.5:9b 通常 6.6GB 5.7GB 5.2s 14.8 計算で誤答（10+10=18） tok/s gemma4:12b- 通常 7.2GB 8.0GB 6.2s 10.8 文章は丁寧だが遅い tok/s it-qat • ふだん使いは 、計算・コードは という使い分けに しました。 （Mixture of Experts）は トークンごとに 部のパラメータしか使わないため、サイズ

• MoE（Mixture of Experts）は 1 トークンごとに一部のパラメータしか使わないため、サイズ が大きくても通常のモデルより速く生成できます。メモリ帯域が細い内蔵 GPU と相性がよい 方式です。 • ただしサイズ自体は大きいので、GPU メモリを大きく占めます。gemma4:26b を読み込ん でいる間は、ほかのモデルを同時に読み込めません。 • 評価は少数の課題による主観です。用途が決まっているなら、自分の業務に近い課題で比べ 直してください。思考を有効にしたときの質と速度は未評価です。 コンテキスト長とメモリ コンテキスト長（一度に扱えるトークン数）を増やすと、その分のメモリ（KV キャッシュ）を確 保します。GPU に収まらない分は CPU にはみ出し、速度が落ちます。 • Ollama の既定は 4096 で、Web UI での長めの会話や文書の読み込みには短いため、全体の 既定を OLLAMA_CONTEXT_LENGTH=8192 にしました。 • 64k に広げた場合の試験結果: モデル 64k での割り当て gpt-oss:20b 12GB、100% GPU ⽣成 読み込み 20.4 tok/ 9.5s s gemma4:26b-a4b-it- 16GB、CPU 13% / GPU 87% 30.3s s qat qwen3:8b 25.3 tok/ 11GB、100% GPU（モデル上限の 40960 に切り — — 詰め） • 長いコンテキストが必要な用途（エージェントなど）があっても、全体の既定値は上げず、 Model�le でそのモデルだけ長いコンテキストの派生版を作る方が安全です。全体を上げる と、ほかのモデルが CPU にはみ出します。 printf 'FROM gpt-oss:20b\nPARAMETER num_ctx 65536\n' > Modelfile コピー ollama create gpt-oss-64k -f Modelfile • 入力の処理は 200〜400 tok/s 程度なので、長い入力では 1 回の応答に数十秒〜1 分半かか ります。 • BIOS の UMA Frame Buffer Size で VRAM を増やせる機種もありますが、Vulkan は共有メ モリ（GTT）も使えるので必須ではありません。

ネットワークと安全 Ollama の API には認証がない Ollama の API に届く人は誰でも、推論だけでなくモデルの取得・削除までできます。既定の待ち 受け（127.0.0.1）のままなら、外からは届きません。ほかの PC から API を使うため OLLAMA_HOST=0.0.0.0:11434 にする場合は、ファイアウォールなどで届く範囲を必ず絞ってくだ さい。 Docker のポート公開は ufw を素通りする ports: - "8080:8080" で公開すると、Docker が iptables に直接ルールを入れるため ufw の設 定が効きません。この手順では network_mode: host にしてポート公開を使わないことで、8080 番も ufw の管理下に置いています。ホストの Ollama に 127.0.0.1 でつなげる利点もあります。 Tailscale を使う場合 Tailscale はファイアウォールの先頭に自分のルール（ ts-input ）を入れ、tailnet からの通信を すべて許可します。つまり tailnet 内の端末からは ufw に関係なく全ポートに届きます。SSH トン ネルなしで Web UI を使えて便利ですが、Ollama API も tailnet 全体に開くことになるので、必要 に応じて Tailscale の ACL で絞ってください。 Open WebUI のアカウント • 最初に登録したユーザーが管理者になります。サービスを外に見せたら、すぐ管理者を作っ てください。 • 2 人目以降は管理者の承認待ちになります。複数人で使う場合は承認の運用を決めておきま す。 インストール用スクリプト curl … | sh で直接流さず、保存して中身を読み、ハッシュを記録してから実行しました。い つ・どの版を入れたかを後から確認できます。 運用・更新 • Ollama の更新: インストール用スクリプトを再実行します。drop-in の override.conf は 残ります。 新後 と速度を確かめます（ 対応や内蔵

残ります。更新後は bench.sh で 100% GPU と速度を確かめます（Vulkan 対応や内蔵 GPU の扱いは版によって変わることがあります）。 • Open WebUI の更新: compose ファイルのイメージタグを書き換えて up -d 。 latest で はなくタグを固定しておくと、意図しない更新を防げ、戻すのも簡単です。 • バックアップ: 会話履歴・ユーザー・設定は Docker ボリューム open-webui 内の webui.db （SQLite）にあります。更新前にボリュームごと控えておきます。 • 設定の保存先: Open WebUI は管理画面で変えた設定をデータベースに保存し、そちらを優 先します。一度データベースに値が入ると、compose の環境変数（例: DEFAULT_MODELS ） を変えても反映されません。設定は管理画面から変えるのが確実です。 • 同時利用: 同時に処理するリクエストは既定で 1 件です。複数人で使うと順番待ちになり、大 きなモデル同士は同時にメモリに載りません。 • ディスク: モデルは 1 つ 5〜16GB あります。評価が済んで使わないモデルは ollama rm で 消します。 他のハードウェアでの違い 環境 手順 3 の代わりにやること 注意 AMD 内蔵 GPU（今 Vulkan ドライバを入れ、 使える GPU メモリはメインメモリ 回） OLLAMA_IGPU_ENABLE=1 と の搭載量に左右される OLLAMA_VULKAN=1 AMD 単体 GPU ROCm で動くことが多い。ログの library= 対応表に載っていない機種は （ROCm 対応機種） で確認 Vulkan を試す NVIDIA GPU NVIDIA ドライバを入れれば CUDA で自動的に nvidia-smi が動くことを先に確 使われる 認。VRAM に収まるモデルを選ぶ 不要（CPU で動く） 生成は 8B で 10 tok/s 前後が目 GPU なし 安。小さめのモデルか MoE を選ぶ どの環境でも、確認方法は同じです。 journalctl -u ollama の library= の行と、 ollama ps の PROCESSOR 欄を見ます。 つまずきやすい点 症状・ログ 原因 対処 dropping ROCm device — no ROCm がこの GPU に対 手順 3 で Vulkan を使う 応していない

rocblas support for gfx target 応していない gfx1103 Vulkan の GPU が見つからない Vulkan ローダー・Mesa libvulkan1 mesa-vulkan-drivers を ドライバ未導入 入れ、 vulkaninfo で確認 dropping integrated GPU; to 内蔵 GPU は既定で使わ drop-in に OLLAMA_IGPU_ENABLE=1 enable, set OLLAMA_IGPU_ENABLE=1 ない扱い ollama ps が CPU/GPU 混在 GPU メモリ不足 小さいモデル、短いコンテキスト、ほか のモデルの解放 /dev/kfd などに権限がない グループ未所属、または 手順 1 のあと SSH で入り直す ログインし直していない 計測の所要時間がばらつく ほかのリクエストと順番 Ollama 内部の処理時間 待ちになっている （ eval_duration など）で計算する。 計測前に ollama ps SSH が切れたら ollama pull が止 SSH セッションに処理が 長いダウンロードはサーバー側で切り離 まった／残った ぶら下がっている して実行（下記） sudo systemd-run ��unit=ollama-pull-models ��uid=$USER ��setenv=HOME=$HOME \ コピー bash -c 'for m in gpt-oss:20b gemma4:26b-a4b-it-qat; do ollama pull $m; done' journalctl -u ollama-pull-models -f # 進み具合を⾒る ハンズオン運営のコツ • モデルは事前に配る。実測のダウンロード速度は 10〜12MB/s で、qwen3.5:9b（6.6GB） に約 10 分、gemma4:26b（16GB）に約 22 分かかりました。参加者全員が会場の回線で同 時に取ると、さらに遅くなります。事前に各自で ollama pull してもらうか、取得済みの 機械を用意してください。 • 当日のモデルは小さいものから。まず qwen3:8b で手順 4〜8 を通し、時間が余ったら MoE モデルに差し替えると、待ち時間で止まりません。 • 機材を揃えるなら GPU の世代を確認。同じ「Radeon 内蔵」でも世代で ROCm・Vulkan の 対応が違います。手順 1 の lspci と /sys/class/kfd の gfx_target_version で事前に 確かめておきます。 • サーバーを共有する場合は役割を決める。Open WebUI の管理者は講師が先に作り、参加者 は登録後に承認する流れにすると混乱しません。Ollama は同時に 1 件ずつ処理するので、全 員が同時に投げると待ちが出ることを先に伝えておきます。 • 作業記録を残す。実行したコマンド・配置したファイル・確認結果・戻し方を作業単位で残

しておくと、トラブル時の切り分けと、次回の資料づくりがずっと楽になります。