「GPU搭載のLinuxサーバーを2台用意した。どうやって並列稼働させればよいかわからない」 そんな悩みを抱えているインフラエンジニアや情シス担当は多いはずです。この記事では、HAProxyを使って複数のOllamaインスタンスを束ね、同時リクエストへの応答スループットを向上させる負荷分散構成を、Ubuntu Serverで一から構築する手順を解説します。
ヘルスチェックによる障害ノードの自動除外、`hey` を使ったスループットの実測方法まで網羅しています。
前提として、Ollamaのインストールと基本動作は完了している状態を想定します（Ubuntu ServerでローカルLLMを構築する完全ガイドを参照）。
この記事のポイント
・HAProxyのhaproxy.cfgにfrontend/backendを定義して複数OllamaインスタンスをRound Robinで束ねる
・systemdのサービスユニットを複製してOLLAMA_HOSTを変えることで同一サーバーに複数インスタンスを立てられる
・`option httpchk GET /api/tags` とfall/rise設定でノード障害を自動検出・切り離し・自動復帰できる
・`hey -n 200 -c 20` で負荷前後のRequests/secを実測し、スループット改善を定量確認する
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜOllamaへの負荷分散が必要か
Ollamaはデフォルトでシングルプロセス動作です。複数のリクエストが同時に届いた場合、先行する推論が終わるまで後続のリクエストは待機キューに積まれます。環境変数 `OLLAMA_NUM_PARALLEL` で並列推論数を増やすことはできますが、増やした分だけVRAMを消費します。たとえば14Bモデル（q4_0で約8GB）を3並列にするには24GB以上のVRAMが必要です。上限はハードウェアの物理制約に当たります。
解決策は2方向あります。1つはGPUを増やして単一ノードのVRAMを拡張する垂直スケール。もう1つはサーバーを複数台追加して負荷を分散する水平スケールです。
水平スケールでは「リクエストをどのノードに振るか」を決めるロードバランサーが必要になります。HAProxyはL4/L7両対応の実績あるOSSで、バックエンドヘルスチェックと統計ダッシュボードが標準搭載されています。NginxのupstreamでもHTTPプロキシは組めますが、バックエンドの状態管理と可観測性という点でHAProxyのほうが設定の見通しが良いため、本記事ではHAProxyを採用します。
なお、チームでのローカルLLM導入における費用対効果やセキュリティの考え方については、機密データを守るローカルLLMという選択肢も参考にしてください。
前提環境と構成イメージ
本記事で構築する構成は以下の通りです。・OS: Ubuntu Server 22.04 LTS（または24.04 LTS）
・HAProxy: 2.4系以上（Ubuntu公式リポジトリ）
・Ollamaインスタンス: 同一サーバー上の11434番・11435番ポートで2プロセス起動
・クライアント: チームメンバーのPC（HAProxyの80番ポートへ接続）
リクエストの流れはシンプルです。クライアント→（port 80）→ HAProxy →（Round Robin）→ ollama:11434 / ollama:11435 という構成になります。
同一サーバー上に2インスタンスを立てる構成から始めますが、GPU搭載の別物理サーバーを追加したい場合はhaproxy.cfgのbackendセクションにIPアドレスを追記するだけで対応できます。構成の拡張はほぼゼロコストです。
同一サーバーに2インスタンスを立てるメリットは、CPUスレッドをフルに活用できる点です。GPUが1枚しかない場合、2つのインスタンスがGPUを時分割で使うことになりますが、CPUのみで動かす軽量モデル（Gemma 3 2Bなど）であればコア数が多いサーバーでインスタンスを増やすほど並列処理量が増えます。
一方、モデルが大きくVRAMに収まりきらない場合は2インスタンスで逆に遅くなることもあります。後述の負荷テストで必ず実測してから本番に展開してください。
HAProxyをUbuntu Serverにインストールする
1. パッケージのインストール
Ubuntu 22.04の公式リポジトリにはHAProxy 2.4系が含まれています。本記事の設定構文は2.4以降で動作します。Ubuntu 24.04 LTSでは2.8系が入りますが、どちらも同じ手順で動作します。# パッケージ情報を更新してインストール sudo apt update sudo apt install -y haproxy # インストールされたバージョンを確認 haproxy -v
HAProxy version 2.4.24-0ubuntu0.22.04.1 2023/10/31 - https://haproxy.org/ Status: long-term supported branch - will stop receiving fixes around Q2 2026.
2. 起動と自動起動の有効化
インストール直後はHAProxyがまだ起動していない環境もあります。systemdで管理状態を確認・設定します。# 自動起動を有効化して即時起動 sudo systemctl enable haproxy sudo systemctl start haproxy # 状態確認 sudo systemctl status haproxy
複数のOllamaインスタンスを異なるポートで起動する
OllamaはデフォルトでTCPポート11434でリッスンします。2つ目のインスタンスに11435番を割り当てるため、専用のsystemdサービスユニットを作成します。環境変数 `OLLAMA_HOST` でリッスンアドレスとポートを変更できます。1. サービスユニットファイルを複製する
# 既存のollamaサービスユニットをollama2としてコピー sudo cp /lib/systemd/system/ollama.service \ /etc/systemd/system/ollama2.service # コピーしたファイルを編集 sudo nano /etc/systemd/system/ollama2.service
# [Service] セクションに追記・変更する行（抜粋） [Service] Environment="OLLAMA_HOST=0.0.0.0:11435" Environment="OLLAMA_MODELS=/usr/share/ollama/.ollama/models" ExecStart=/usr/local/bin/ollama serve
2. 起動と疎通確認
sudo systemctl daemon-reload sudo systemctl enable ollama2 sudo systemctl start ollama2 # 両ポートがリッスンしていることを確認 ss -tlnp | grep -E '11434|11435'
LISTEN 0 4096 0.0.0.0:11434 0.0.0.0:* users:(("ollama",pid=12345,...)) LISTEN 0 4096 0.0.0.0:11435 0.0.0.0:* users:(("ollama",pid=12567,...))
# 1つ目のインスタンス（デフォルト） curl -s http://localhost:11434/api/tags | python3 -m json.tool | head -5 # 2つ目のインスタンス curl -s http://localhost:11435/api/tags | python3 -m json.tool | head -5
haproxy.cfgで負荷分散ルールを設定する
1. 設定ファイルのバックアップ
デフォルト設定を保存してから上書きします。sudo cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak sudo nano /etc/haproxy/haproxy.cfg
2. global・defaults・frontend・backendを定義する
以下の内容をファイル全体と差し替えます。global log /dev/log local0 log /dev/log local1 notice maxconn 4096 daemon defaults log global mode http option httplog option dontlognull timeout connect 10s timeout client 120s timeout server 120s timeout tunnel 3600s frontend ollama_front bind *:80 default_backend ollama_back backend ollama_back balance roundrobin option httpchk GET /api/tags server ollama1 127.0.0.1:11434 check inter 5s rise 2 fall 3 server ollama2 127.0.0.1:11435 check inter 5s rise 2 fall 3 listen stats bind *:8404 stats enable stats uri /stats stats refresh 10s stats show-node
・`balance roundrobin`: リクエストをollama1・ollama2に交互に振り分ける。接続数が偏る場合は `leastconn` に変更すると接続数が少ないインスタンスに優先的に振る
・`option httpchk GET /api/tags`: バックエンドに定期的にHTTP GETを送り、200が返れば正常と判断する
・`check inter 5s`: 5秒間隔でヘルスチェックを実行する
・`rise 2 fall 3`: 3回連続失敗でDOWN扱い、2回連続成功で復帰扱いにする
・`timeout tunnel 3600s`: ストリーミングレスポンスを使う場合に必要。この設定がないとストリーミング中にHAProxyが接続を強制切断する
設定の構文チェックを実行してから反映します。
# 構文チェック（エラーがなければ何も出力されない） haproxy -c -f /etc/haproxy/haproxy.cfg # 設定を反映（既存接続を維持したまま適用） sudo systemctl reload haproxy
ヘルスチェックで障害ノードを自動除外する
設定が正しく機能するか、インスタンスを意図的に停止して確認します。# ollama2を停止してフェイルオーバーを確認 sudo systemctl stop ollama2 # 統計ページでステータスをCSV形式で確認 curl -s "http://localhost:8404/stats;csv" | grep -E "svname|ollama"
pxname,svname,qcur,qmax,scur,smax,slim,stot,bin,bout,...,status,... ollama_back,ollama1,0,0,0,3,0,127,...,UP,... ollama_back,ollama2,0,0,0,2,0,73,...,DOWN,...
この挙動により、メンテナンスでインスタンスを停止している間も、残りのインスタンスがリクエストを処理し続けます。ユーザーからはサービスが継続して見えます。
ブラウザで `http://<サーバーIP>:8404/stats` にアクセスすると、各サーバーのリクエスト数・応答時間・ステータスをリアルタイムで視覚的に確認できます。スループット改善の定性確認にも役立ちます。
負荷テストでスループットの改善を実測する
設定前後を数値で比較するため、`hey` を使ってHTTP負荷テストを行います。`hey` はGoで書かれた軽量ツールで、Ubuntu公式リポジトリから入手できます。# heyのインストール sudo apt install -y hey # 2インスタンス構成での負荷テスト（20並列・200リクエスト） hey -n 200 -c 20 -m POST \ -H "Content-Type: application/json" \ -d '{"model":"mistral:7b-instruct-q4_0","prompt":"こんにちは","stream":false}' \ http://localhost:80/api/generate
2インスタンス構成と1インスタンス構成の数値を比較することで、負荷分散の実効性を定量的に確認できます。
知人のインフラエンジニアが同一サーバーにCPU推論の8Bモデルを2インスタンス立てて計測したところ、20並列時のスループットが1インスタンス時の約1.5～1.7倍になったと聞いています。GPUがある環境ではVRAM割り当てのバランスが重要で、モデルがVRAMに収まらずスワップが発生すると逆に遅くなるケースもあります。
必ず実測してからインスタンス数を決定してください。「理論上は速いはず」で本番展開するのが最も危険なパターンです。
よくある設定ミスとトラブル対処
1. 推論中にコネクションが切断される（timeout不足）
LLMの推論は大きなプロンプトや量子化の少ないモデルで数十秒かかる場合があります。`timeout server` を短くしていると推論途中でHAProxyが接続を切ります。ストリーミング（stream:true）利用時は特に `timeout tunnel` が必須です。# defaultsセクションにtimeout tunnelが存在するか確認 grep "timeout tunnel" /etc/haproxy/haproxy.cfg
2. ollama2が起動しない（ポート競合）
`OLLAMA_HOST` が正しく設定されていない場合、ollama2が11434番を取ろうとして失敗します。# 環境変数が正しく渡っているか確認 sudo systemctl show ollama2 --property=Environment # エラーログを確認 sudo journalctl -u ollama2 -n 30 --no-pager
# 11435番ポートを使用中のプロセスを確認 ss -tlnp | grep 11435
3. ヘルスチェックが常時DOWN扱いになる
OllamaがモデルをロードしていないアイドルStateや起動直後では `/api/tags` が期待するステータスを返さない場合があります。まず手動でエンドポイントを確認します。# ヘルスチェック対象エンドポイントのHTTPステータスを手動確認 curl -s -o /dev/null -w "%{http_code}" http://localhost:11434/api/tags curl -s -o /dev/null -w "%{http_code}" http://localhost:11435/api/tags
# backendセクションにhttp-check expectを追加 backend ollama_back balance roundrobin option httpchk GET /api/tags http-check expect status 200 server ollama1 127.0.0.1:11434 check inter 5s rise 2 fall 3 server ollama2 127.0.0.1:11435 check inter 5s rise 2 fall 3
まとめ
HAProxyを使ったOllamaの負荷分散構成の手順をまとめます。| 手順 | 主なコマンド・ファイル | ポイント |
|---|---|---|
| HAProxyインストール | sudo apt install -y haproxy | Ubuntu 22.04で2.4系、24.04で2.8系が入る |
| 2つ目のインスタンス用ユニット作成 | sudo cp /lib/systemd/system/ollama.service /etc/systemd/system/ollama2.service | OLLAMA_HOST=0.0.0.0:11435 で別ポートに割り当て |
| モデルファイル共有 | OLLAMA_MODELS を同一パスに設定 | モデルのディスク容量を2倍消費せずに済む |
| 負荷分散設定 | /etc/haproxy/haproxy.cfg | balance roundrobin + option httpchk GET /api/tags |
| 設定反映 | sudo systemctl reload haproxy | reload で既存コネクションを維持したまま適用 |
| ヘルスチェック確認 | curl "http://localhost:8404/stats;csv" | grep ollama | fall 3 でDOWN判定、rise 2 で自動復帰 |
| スループット計測 | hey -n 200 -c 20 -m POST … http://localhost:80/api/generate | シングル構成との比較でRequests/secを実測する |
Ollamaの基盤構築がまだの方は、Ubuntu ServerでローカルLLMを構築する方法から着手することを勧めます。単一インスタンスを安定稼働させてから水平スケールへ進むと、問題の切り分けがはるかに楽になります。
Ollamaの負荷分散構成を2日間のハンズオンで体験する
「設定ファイルは書けたが、並列リクエストを実際に流してスループット改善を手元で体感したい」という方向けに、「ローカルAIマスターセミナー」を開催しています。実機GPU環境で手を動かしながら、負荷分散・監視・RAG構成まで一気に習得できます。
少人数（最大8名）ZOOMハンズオン形式で実施しています。
・Ubuntu ServerでローカルLLMを構築する方法｜Ollamaで機密データを外に出さず業務AIを動かす完全ガイド
・社内でChatGPTが使えないときの代替手段｜機密データを守るローカルLLMという選択肢
・ローカルLLMのモデルを比較する方法｜Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：OllamaをGitのpre-commitフックに組み込む方法｜ローカルLLMでコードレビューとコミットメッセージ生成を自動化する
- この記事の属するカテゴリ：ローカルLLMへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます