top of page
logo.png

(続き)UGREEN DXP6800 Pro で Ollama を動かす — CUDAエラー地獄と、Zed からのローカルコーディング接続まで

  • ccf代表
  • 19 時間前
  • 読了時間: 7分

はじめに

前回、UGREEN DXP6800 Pro に eGPU 経由で RTX 2000 Ada を載せ、Docker から --gpus all でGPUを叩けるところまで持っていきました。今回はその続きで、本来の目的だった ローカルLLMをコーディングに使うところまでの記録です。

ゴールはこんな感じ:

  • NAS本体で Ollama を常時稼働させる

  • ブラウザからは Open WebUI で叩く

  • エディタ Zed からも繋いで、コーディング補助に使う

……が、これがまた一筋縄ではいかず、CUDAエラーで全モデルが起動しないという壁にぶつかりました。結論から言うと、原因は「Ollamaが新しすぎたこと」でした。同じ構成でハマっている人の役に立てば嬉しいです。

最終的に安定した構成はこちら:

UGREEN DXP6800 Pro
 └ NVIDIA Driver 535.261.03 (CUDA 12.2)
 └ RTX 2000 Ada (VRAM 16GB)
 └ Docker
    ├ ollama        … ollama/ollama:0.24.0  ← ここがキモ
    └ open-webui    … ghcr.io/open-webui/open-webui:main
 └ Zed (別PC) → http://<NASのIP>:11434

つまずき①：Open WebUI から叩くと全モデルが落ちる

Ollama と Open WebUI のコンテナを立てて、いざモデルを動かそうとしたら、チャット画面にこのエラーが出ました。

llama-server process has terminated: CUDA error
CUDA error: device kernel image is invalid: CUDA error
CUDA error: device kernel image is invalid

nvidia-smi は通るし、GPUもちゃんと認識している。なのにモデルを載せた瞬間に落ちる。qwen3:14b でも qwen3-coder:30b でもダメ。

nvidia-smi を見ると、GPUは完全にアイドルで No running processes found。つまりGPUメモリを確保する前に弾かれている = 容量オーバーではなく、CUDAカーネルそのものが噛み合っていない、という症状でした。


原因：Ollama v0.30 系の「llama.cpp ネイティブ化」と、ドライバー535の相性

調べていくと、Ollama公式リポジトリにドンピシャの報告がありました。

Ollama v0.30.0 で内部エンジンが GGML から llama.cpp ネイティブに切り替わった。その結果、ドライバー535 / CUDA 12.2 環境ではプリビルドのCUDAカーネルが合わず、モデルが起動しなくなった。v0.24.0以前は同じハードで正常だった。

エラーに出ていた llama-server が、まさにこの新エンジンの正体です。

前回あえて「安定重視で535を選んだ」のが、ここで裏目に出ました。535(CUDA 12.2)に対して、ollama:latest の新エンジンが要求するCUDAが新しすぎたわけです。前に llama3.2:3b だけは動いたように見えたのは、おそらくCPUにフォールバックしていただけでした。

選択肢は2つ:

  1. ドライバーを570系に上げる(latestのまま使える。ただし前回の悪夢再び=ブートが飛ぶリスク)

  2. Ollamaを旧エンジン版に固定する(ドライバーに触らない。低リスク)

前回さんざんブートを飛ばした身としては、迷わず②を選びました。


解決：Ollama を v0.24.0 に固定する

ダウンロード済みモデルはボリュームに残るので消えません。バージョンを明示してコンテナを作り直します。

docker network create ai 2>/dev/null
docker rm -f ollama
docker run -d \
  --gpus all \
  --network ai \
  -p 11434:11434 \
  -v ollama:/root/.ollama \
  --name ollama --restart unless-stopped \
  ollama/ollama:0.24.0

動作確認:

docker exec -it ollama ollama --version          # 0.24.0
docker exec -it ollama ollama run qwen3:14b "こんにちは"
docker exec -it ollama ollama ps

ollama ps の結果がこれ。

NAME         SIZE     PROCESSOR    CONTEXT    UNTIL
qwen3:14b    16 GB    100% GPU     40960      Forever

100% GPU。通った瞬間、また小さくガッツポーズしました。535のまま、旧エンジンでGPU推論が動く状態にやっとたどり着けました。

ポイント:ollama/ollama:latest は中身が動くので、docker run でバージョンを明示的にピン留めしておくのが安全です。再起動のたびに勝手に新エンジンに上がって、また同じ地獄を見ることになります。

つまずき②：Open WebUI が Ollama に繋がらない

Ollamaが動いても、Open WebUI側のログにこれが出ました。

Cannot connect to host ollama:11434 [Name or service not known]

ollama という名前を解決できていません。原因は、2つのコンテナが同じユーザー定義ネットワークに乗っていなかったこと。Dockerのデフォルトbridgeはコンテナ名でのDNS解決ができません。

両方を同じネットワーク ai に繋いで解決:

docker network connect ai ollama 2>/dev/null
docker network connect ai open-webui 2>/dev/null
docker restart open-webui

確認:

docker exec open-webui getent hosts ollama   # 行が返ればOK

Open WebUI 側の Ollama API URL は http://ollama:11434 を指定。これでモデル一覧が出るようになりました。

ちなみにこの過程で一度、Open WebUI のコンテナを作り直してログインできなくなりました。Open WebUIは初回が「ログイン」ではなく「サインアップ(新規登録)」で、最初に作ったアカウントが管理者になります。データを残したいときは -v open-webui:/app/backend/data のように名前付きボリュームを必ず付けること。

Zed から繋ぐ

ここまで来れば、エディタからも使えます。Zed はOllamaにネイティブ対応しているので、settings.json に接続先を書くだけ。ポートは Ollama 標準の 11434 です。

{
  "language_models": {
    "ollama": {
      "api_url": "http://<NASのIP>:11434"
    }
  }
}

  • Zedが別PCで動くなら、localhostではなくNASのIPを指定(hostname -I で確認)

  • 疎通確認は curl http://<NASのIP>:11434/api/tags でモデル一覧JSONが返ればOK

モデル選択に qwen3:14b などが出てくれば成功です。


つまずき③：30Bモデルがメモリ不足で載らない

調子に乗って、コーディング用に qwen3-coder:30b(MoE・アクティブ3.3B)を Zed から呼んだら、今度はこれ。

500 Internal Server Error
model requires more system memory (27.6 GiB) than is available (14.6 GiB)

  • 27.6 GiB 必要 = 重み約18GB + 大きなコンテキスト用のKVキャッシュ

  • 14.6 GiB しかない = NAS本体の空きRAM

ここで大事な切り分け。ollama ps で qwen3:14b は 100% GPU で動いている = GPU自体は正常。問題は本体のRAMが足りないことでした。

そして勘違いしていたのが、「eGPUは外付けだからメモリ増設できないのでは?」という点。これは別物でした。

種類

場所

増設

VRAM 16GB

外付けeGPU内の RTX 2000 Ada

❌ 固定(GPU交換しかない)

システムRAM

NAS本体のSODIMMスロット

✅ 可能

調べると UGREEN DXP6800 Pro は DDR5 SODIMM × 2スロット、最大64GB。eGPUが外付けかどうかとは無関係に、本体RAMは増やせます。

つまり今の構成では:

  • 16GB VRAM にフル搭載できる 14Bクラスが、GPU完結で快適に動く上限

  • 30Bクラスは、RAMを増やしてGPU+RAMオフロードで動かす(MoEなのでアクティブ3.3B、実用速度は出やすい)

ということで、64GB(32GB×2)のRAMを発注することにしました。SODIMM・DDR5-4800・Non-ECC・Unbuffered のキットを、ペアでデュアルチャネルに。


今回のキモになったポイント

  1. ollama:latest は535には新しすぎる。 v0.30系のllama.cpp化で device kernel image is invalid が出るなら、迷わず ollama/ollama:0.24.0 にピン留め。ドライバーを上げるより安全。

  2. GPUが効いているかは ollama ps で確認。 100% GPU でなければ、それはCPUで動いているだけ。

  3. コンテナ間通信はユーザー定義ネットワークで。 デフォルトbridgeはコンテナ名解決ができない。docker network connect で揃える。

  4. Zed接続はポート11434 + api_url にNASのIP。 localhostではない。

  5. VRAMとシステムRAMは別物。 16GB VRAMは固定、本体RAMは最大64GBまで増設可能。14Bは今すぐGPUで快適、30Bはメモリ増設後の宿題。


おわりに

前回はGPUを認識させるだけで心が折れかけましたが、今回は「Ollamaが新しすぎる」という、ある意味あっけない原因でした。とはいえ、535を維持したまま、旧エンジン版にピン留めしてGPU推論を通すという落とし所に気づくまでが長かったです。

現状、qwen3:14b が Zed からGPUで快適に動く、十分実用的な環境になりました。次回は 64GBへのメモリ増設後に、qwen3-coder:30b をどこまで実用的に回せるかを試してみます。

NAS一台で、ストレージもローカルLLMもコーディング補助も完結する——やっぱり夢がありますね。続きはまた別の記事で。

最後まで読んでいただき、ありがとうございました。


追伸）

qwen3:14bをZedでつないで、以下のプロンプトを投げました。 まぁそれっぽいです。将来的にはメモリを増設する予定なので、その影響を定量的に測定したいですね。 

このアプリ全体の解析をお願いしたいです。

**プロジェクトの概要**
- **目的**: XXXの**機能を維持しながら不具合を修正し**、さらに**UIの刷新**を行う。
- **開発フロー**:
  - **1 PR = 1 Issue** の原則を採用
  - **Codexレビュー（AIによるコードレビュー）** の実施
  - **GitHub Actions** を用いた CI/CD
  - **Azure** 上でのデプロイ（リソースグループ `mgh-althea-2026`）
・
・
・
🐳 **技術スタックの概要**
- **言語**: Java, RPG, CL, VB（現行システム）→ 後継はおそらく TypeScript/JavaScript（`services/todo` が Azure で稼働中）
- **フレームワーク**: Prisma（SQL Server 採用）
- **DB**: SQL Server
- **CI/CD**: GitHub Actions（Trivy によるスキャン、gitleaks 検出、PR本文Lint）
- **インフラ**: Azure（リソースグループ `xxx`）
・
・
・
🛡️ **セキュリティと品質管理**
- **gitleaks**: シークレット漏洩の検出（`.gitleaks.toml` 設定）
- **Trivy**: ソースコードの脆弱性スキャン（`tools/` 配下のスクリプトも対象）
- **Codex レビュー**: AIによるコード品質の確認（移行起因バグや権限漏れの検出）


コメント

bottom of page