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 に、次を設定:
-
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 を開くだけで、
文章添削・献立相談・技術質問などを同じモデルに対して行える。
- iPad や PC から http://家のAI:3000 を開くだけで、
-
GPUリソースを有効活用
- 既に持っている RTX 3060 12GB×2 を最大限活かし、
7Bモデルを快適に、13Bも将来を見据えて試せる。
- 既に持っている RTX 3060 12GB×2 を最大限活かし、
-
運用の柔軟性
-
LM Studio 側でモデルを入れ替えれば、Open WebUI からは自動的に新モデルが見える。
-
Ubuntu Budgie 24.04 の快適なデスクトップ環境を利用しつつ、systemd+Docker でサーバーとしても安定して動かせる。
-