4. なぜ LM Studio と Open WebUI を組み合わせたか

ローカルLLMのフロントエンドとしては、LM Studio 単体でもチャットUIを持っていますが、次の理由から LM Studio（モデルエンジン）＋Open WebUI（Webフロント）の二段構成にしました。

LM Studio の強み
- モデルのダウンロード管理や量子化設定がとても分かりやすい。
- Windows/Mac/Linux で動き、OpenAI互換APIサーバー機能を持つ。
Open WebUI の強み
- ブラウザからアクセスできる、マルチユーザー向けのチャットUI。
- Dockerで動かせるので、家内LAN内のどの端末からも同じ画面にアクセスできる。

複数モデルの切り替え、プロンプトテンプレート、Web検索連携など拡張性が高い。

役割分担
- LM Studio：RTX 3060×2 を使って LLM を回す「エンジン」
- Open WebUI：家族も iPad からアクセスできる「家内クラウドの窓口」

この構成にすると、

「サーバーの中身（モデル管理やGPU構成）は自分がLinux上で面倒を見る」
「家族は iPad の Safari から http://家のAI:3000 を開くだけで会話できる」

という役割分担がきれいにできます。

5. LM Studio を Ubuntu Budgie 24.04 で動かす手順とハマりどころ

5-1. NVIDIAドライバと CUDA 環境

Ubuntu 24.04 上でまずやったこと：

sudo apt update
sudo ubuntu-drivers autoinstall
sudo reboot

再起動後に nvidia-smi で RTX 3060 が2枚見えていることを確認。

5-2. LM Studio AppImage の導入

LM Studio の Linux 用 AppImage をダウンロードし、~/apps に保存。

実行権限を付ける：

chmod +x LM_Studio-*.AppImage

一度GUIで起動し、

1.モデル（例：elyza-japanese-llama-2-7b）をダウンロード

2.「Local Server」機能でポート 1234 を使う設定を確認

3.Ubuntu 24.04 では、Electron の制限で --no-sandbox が必要なケースもあるという報告がありますが、今回は通常起動で問題なく動作しました。

5-3. CLI（lms）と systemd サービス化

LM Studio は lms という CLI を持っており、headless サーバー運用向けの手順が公式に用意されています。

サービスファイル：

# /etc/systemd/system/lmstudio.service
[Unit]
Description=LM Studio Server

[Service]
Type=oneshot
RemainAfterExit=yes
User=tao
Environment="HOME=/home/tao"
ExecStartPre=/home/tao/.lmstudio/bin/lms daemon up
ExecStart=/home/tao/.lmstudio/bin/lms server start
ExecStop=/home/tao/.lmstudio/bin/lms daemon down

[Install]
WantedBy=multi-user.target

有効化：

sudo systemctl daemon-reload
sudo systemctl enable lmstudio
sudo systemctl start lmstudio
sudo systemctl status lmstudio

ここで一度つまずいたのが、

最初は ExecStartPre で lms load openai/gpt-oss-20b --yes を書いてしまい、
3060 12GB では gpt‑oss‑20b のロードが失敗 → サービス全体がエラーで止まる

というパターンでした。ログには「Failed to load model」とだけ出るので、
まずはモデル自動ロードを外して、サーバーだけ立てるのが大事だと痛感しました。

正常起動後は：

curl http://localhost:1234/v1/models

で

{"data":[
  {"id":"openai/gpt-oss-20b", ...},
  {"id":"elyza-japanese-llama-2-7b", ...},
  {"id":"text-embedding-nomic-embed-text-v1.5", ...}
], "object":"list"}

が返ってきて、OpenAI互換APIとして問題なく動作していることを確認できました。

6. Open WebUI を Docker で立て、LM Studio に繋ぐ

6-1. Docker で Open WebUI コンテナ

Ubuntu 側で Docker を準備し、次で WebUI を起動：

sudo apt install -y docker.io docker-compose
sudo systemctl enable docker --now

docker run -d \
  -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui \
  --restart always \
  ghcr.io/open-webui/open-webui:main

これで http://localhost:3000 にブラウザでアクセスすると、Open WebUI の初期画面が出ます。

途中で遭遇したトラブルとしては：

既に存在するコンテナ名 /open-webui が邪魔して docker run に失敗
→ docker ps -a で古いコンテナを確認し、docker rm open-webui で削除してから再実行。

6-2. Open WebUI の「接続」設定で LM Studio を登録

Open WebUI の管理画面 → 「設定」→「接続」→ OpenAI API に、次を設定：

URL：http://host.docker.internal:1234/v1
Provider Type：OpenAI
API Type：Chat Completions
認証：Bearer（APIキーは空またはダミー）

ここで見落としがちなポイント：

Ollama 用の接続がデフォルトで有効になっており、11434番ポートへの接続エラーがログに出る
→ Ollama を使わない場合はトグルをオフにする。

さらに、最初は LM Studio 側が 127.0.0.1:1234 しか listen しておらず、

コンテナ側の host.docker.internal:1234 から接続すると Connection refused になる、という落とし穴がありました。

今回最終的には、

LM Studio はローカルホストで listen（127.0.0.1:1234）のまま
それでも host.docker.internal から届く形になり、
モデル一覧に openai/gpt-oss-20b, elyza-japanese-llama-2-7b, text-embedding-nomic-embed-text-v1.5 が表示されるところまで確認できました。

Open WebUI のモデルプルダウンに同名モデルが並んだときは、正直ちょっと感動しました。

7. まとめ：家内クラウドとしての優位性

この構成で得られた「家内クラウドAIサーバー」のメリットを整理すると：

データが家から出ない
- 会話ログや文章はすべて Node 804 内で完結し、クラウドに送られない。
家族全員が同じ“頭脳”を共有できる
- iPad や PC から http://家のAI:3000 を開くだけで、
  文章添削・献立相談・技術質問などを同じモデルに対して行える。
GPUリソースを有効活用
- 既に持っている RTX 3060 12GB×2 を最大限活かし、
  7Bモデルを快適に、13Bも将来を見据えて試せる。
運用の柔軟性
- LM Studio 側でモデルを入れ替えれば、Open WebUI からは自動的に新モデルが見える。
- Ubuntu Budgie 24.04 の快適なデスクトップ環境を利用しつつ、systemd＋Docker でサーバーとしても安定して動かせる。