Open WebUIでOllamaを快適に使う＋Gemma 3を3サイズ比較してわかったM4 Airでの最適解

前回の記事ではMacBook Air M4にOllamaをインストールし、Gemma 3 27Bを動かすところまでを解説しました。本記事ではその続編として、ChatGPT風のUIでOllamaを使える「Open WebUI」をDockerで導入する手順と、Gemma 3を4B/12B/27Bの3サイズで実測比較した結果を紹介します。実測データから、M4 Airで現実的に使えるモデルサイズが見えてきました。

本記事で扱う内容

  • Open WebUIをDockerで導入する手順
  • 起動済みのOllama（gemma3:27b）との連携
  • Gemma 3を4B/12B/27Bの3サイズで実測比較
  • 「生成速度」と「体感速度」が一致しない発見
  • M4 Airでの現実的な運用方針

Open WebUIとは

Open WebUIは、Ollamaなどのローカル/リモートLLMをChatGPT風のWebインターフェースから利用できるオープンソースツールです。CLIでの対話と違い、会話履歴の保存、複数モデルの切り替え、ファイルアップロードによるRAG、複数モデルの同時実行による比較など、ブラウザ上でリッチな操作が可能になります。

Dockerで起動するのが公式推奨で、コンテナ化されているため環境を汚さず、不要になれば削除も簡単です。

動作環境

  • MacBook Air M4
  • メモリ 32GB
  • Ollamaインストール済み（前回記事参照）
  • Docker Desktopインストール済み

ポートの空き状況を確認する

Open WebUIはデフォルトでホスト側の3000番ポートを使う構成が一般的です。すでに何か使っていないか確認します。

lsof -i :3000

何も表示されなければ3000番は空いています。すでに何かのアプリで使っている場合は、後述のコマンドで別ポート（例: 8090）に変更可能です。

なお筆者の環境ではポート8080は別アプリで使用していたため、コンテナ内部の8080番をホスト側の3000番に転送する構成にしました。

Open WebUIをDockerで起動する

以下のコマンドでOpen WebUIのコンテナを起動します。

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

各オプションの意味は以下のとおりです。

  • -d … バックグラウンド実行
  • -p 3000:8080 … ホストの3000番をコンテナの8080番に転送
  • --add-host=host.docker.internal:host-gateway … コンテナからホストのOllama（localhost:11434）に接続するための設定
  • -v open-webui:/app/backend/data … 設定やチャット履歴を永続化するDockerボリューム
  • --name open-webui … コンテナ名
  • --restart always … Docker起動時に自動で立ち上がる

ポート3000が使用済みの場合は、-p 8090:8080 のようにホスト側のポート番号を変更してください。コンテナ内部の8080番はOpen WebUI本体が待ち受けているため固定です。

初回はイメージのダウンロードに時間がかかります。完了するとコンテナIDが表示されます。

ブラウザでアクセスして初期設定

ブラウザで以下のURLを開きます。

http://localhost:3000

初回アクセス時は管理者アカウントの作成画面が表示されます。名前・メールアドレス・パスワードを入力するとログインできます。これらの情報はローカルのDockerボリューム内に保存され、外部には送信されません。

ログインするとChatGPT風のUIが開き、左上のモデル選択欄に、すでにOllamaにダウンロード済みのモデル（gemma3:27bなど）が自動的に認識されて表示されます。--add-host=host.docker.internal:host-gateway を指定したことで、コンテナ内からホストのOllama APIに自動接続される仕組みです。

モデル名の下に表示される「デフォルトに設定」をクリックしておくと、新規チャット時に毎回そのモデルが選ばれるようになります。

コンテナの管理コマンド

Open WebUIコンテナの基本操作は以下のとおりです。

# 停止
docker stop open-webui

# 再開
docker start open-webui

# ログ確認
docker logs open-webui

# コンテナ削除（データはボリュームに残る）
docker rm open-webui

--restart always を付けているため、Mac再起動後もDocker Desktopが起動すれば自動的に立ち上がります。

3サイズのGemma 3を比較する

Open WebUIで27Bを使ってみたところ、操作感はChatGPTと遜色ない一方で、応答速度が明確に遅いと感じました。そこでGemma 3の他のサイズも導入して比較することにします。

# 12B（約8GB）
ollama pull gemma3:12b

# 4B（約3GB）
ollama pull gemma3:4b

ダウンロード後、ollama list で3つのモデルが揃っていることを確認できます。Open WebUIのモデル選択欄にも自動で追加されます。

ベンチマークの取り方

Ollamaには --verbose オプションがあり、回答の終わりに実行時の統計情報が表示されます。

ollama run gemma3:12b --verbose

対話モードに入ったら、各モデルに同じプロンプトを投げて統計を比較します。今回使用したプロンプトは以下のとおりです。

日本の四季それぞれの特徴と代表的な行事を、外国人観光客向けに400字程度で説明してください。

回答が終わると、以下のような統計が表示されます。

total duration:       38.085309375s
load duration:        153.003625ms
prompt eval count:    33 token(s)
prompt eval duration: 487.892625ms
prompt eval rate:     67.64 tokens/s
eval count:           381 token(s)
eval duration:        37.320852034s
eval rate:            10.21 tokens/s

各項目の意味は以下のとおりです。

  • total duration: 合計処理時間
  • load duration: モデルをメモリに読み込む時間（2回目以降は短くなる）
  • prompt eval rate: プロンプト処理速度（入力トークンを処理する速度）
  • eval count: 出力トークン数
  • eval rate: 生成速度（1秒あたりに出力されるトークン数）

LLMの体感速度を決める最も重要な指標が eval rate です。

3モデルの実測結果

同じプロンプトを各モデルに投げて取得した実測値は以下のとおりです。

モデルサイズプロンプト処理生成速度出力長合計時間
gemma3:4b3.3GB158.54 tok/s28.19 tok/s473 tokens17.36秒
gemma3:12b8.1GB67.64 tok/s10.21 tok/s381 tokens38.09秒
gemma3:27b17GB16.03 tok/s2.55 tok/s297 tokens1分59.7秒

結果から見えてきたこと

パラメータサイズと速度の関係が明確

生成速度はモデルサイズに反比例して落ちていきます。

  • 4B → 12B: パラメータ約3倍 → 生成速度は約1/3
  • 12B → 27B: パラメータ約2.3倍 → 生成速度は約1/4

27Bは12Bの約4倍遅く、4Bと比べると11倍遅いという結果になりました。

大きいモデルほど簡潔に答える

出力トークン数を比較すると、興味深い傾向が見えます。

  • 4B: 473 tokens（最も冗長）
  • 12B: 381 tokens
  • 27B: 297 tokens（最も簡潔）

パラメータ数が多いモデルほど、無駄のない簡潔な回答を生成する傾向があります。これはおそらく、文脈理解と要約能力が高いことで「必要十分な情報量」を判断できているためと考えられます。

「生成速度」と「体感速度」は別物

筆者は最初にOpen WebUIで4Bと12Bを使った時、**「12Bの方が速く感じる」**という印象を持ちました。実測値を見れば4Bの方が圧倒的に速いのに、です。

考えられる理由は以下のとおりです。

  • 4Bは冗長な回答を出すため、読み手の認知負荷が高い
  • 12Bは的確な回答を返すため、目的の情報に早くたどり着ける
  • 「速く読み終わる」と「速く理解できる」は別の体験

加えて、12Bは質問の意図や前提を汲み取った回答をする傾向が強く、「察してくれる」感覚があります。これはtok/sでは測れない、大きいモデルの本質的な強みです。

27Bは常用不可レベル

生成速度2.55 tok/sは明確に「待ちが辛い」領域です。400字程度の回答に2分かかるのは、対話型UIとして使うにはストレスが大きすぎます。M4 Airで27Bを動かす場合は「品質確認用」「バッチ処理用」と割り切るのが現実的です。

M4 Airでの運用方針

実測結果を踏まえた、用途別のおすすめモデルは以下のとおりです。

用途おすすめモデル理由
常用の対話gemma3:12b品質と速度のバランス、意図を汲む回答
高速応答が必要なタスクgemma3:4b単純なタスクなら品質も十分、爆速
品質最優先（バッチ処理）gemma3:27b待てるなら最高品質、対話には不向き

メモリ32GBのMacBook Air M4では、gemma3:12bがスイートスポットという結論になりました。

まとめ

本記事では以下の内容を扱いました。

  • Open WebUIをDockerで導入し、ChatGPT風のUIでOllamaを利用できるようにした
  • Gemma 3を4B/12B/27Bの3サイズで実測比較した
  • 生成速度（tok/s）と体感速度は必ずしも一致しないことを確認した
  • M4 Airではgemma3:12bが品質と速度のバランスに最も優れる

ローカルLLMを選ぶ際、モデルサイズの数字や生成速度の数値だけで判断するのではなく、実際に同じプロンプトを投げて体感を比較することが重要だと実感しました。Open WebUIで複数モデルを横断的に試せる環境が整ったので、今後は他のモデル（Qwen、Llama、日本語特化モデルなど）も同じ手法で比較していけます。

Apple Silicon搭載のMacでローカルLLMを検討している方の参考になれば幸いです。

スポンサーリンク

コメント

タイトルとURLをコピーしました