分散AIエージェント環境構築ログ

前回はCoordinator側──FastAPI・Redis・PostgreSQLの基盤を作った。

Queueにタスクを積むところまでは動いていたが、処理する側がいなかった。

今回はその「Worker不在」を解消した記録だ。

やることはシンプルだった（はずだった）

ThinkCentreにOllamaを入れて、worker.pyを起動する。

それだけのはずだった。

実際には、いくつかのネットワーク設定が立ちはだかった。

Ollamaのインストールは1行で終わる

curl -fsSL https://ollama.com/install.sh | sh

systemdサービスも自動登録される。AMD GPUも検出された。

問題はその後だった。

「繋がらない」の原因は全部ネットワーク設定だった

AI-Core VMからThinkCentreのOllamaに繋ごうとしたら、接続できない。

原因は、OllamaのデフォルトがローカルホストのみListenしていること。

/etc/systemd/system/ollama.service.d/override.conf を作成して、

[Service]
Environment="OLLAMA_HOST=0.0.0.0"

を追記。daemon-reload して再起動で解決した。

続いてworker.pyを起動すると、今度はRedisに弾かれた。

Redis connection failed: Connection reset by peer

Redisの protected-mode yes が原因。パスワードなしの外部接続をデフォルトで拒否する設定だ。

/etc/redis/redis.conf で

protected-mode no
bind 0.0.0.0

に変更して再起動。

次はPostgreSQLが繋がらない。

connection to server at "192.168.0.10", port 5432 failed: Connection refused

listen_addresses がデフォルトでコメントアウトされており、localhostのみ有効な状態だった。

# postgresql.conf
listen_addresses = '*'

さらに pg_hba.conf にThinkCentreのIPを追加して、ようやく全部通った。

「動かない理由の大半は、ネットワーク設定だった」

ローカル環境でも、サービスをまたぐ設計にした瞬間にこういう壁が出てくる。

もう一つ、設計メモのIPが間違っていた

worker.pyのデフォルト値に 192.168.1.10 と書いていたが、AI-Core VMの実IPは 192.168.1.40 だった。

構築しながら記録が追いついていない典型例。

引継ぎサマリーを修正して続行した。

動いた瞬間

設定を全部直してworker.pyを起動すると、

Redis OK
Ollama OK
Waiting on queue 'tasks' ...

AI-Core VMから比較タスクを投入する。

{
  "prompt": "日本の首都はどこですか？",
  "models": [
    "hf.co/LiquidAI/LFM2.5-1.2B-JP-GGUF:Q4_K_M",
    "gemma3:1b"
  ]
}

数秒後、Workerのログに結果が流れた。

[compare] done model=LFM2.5-1.2B-JP 2110ms
[compare] done model=gemma3:1b 2709ms

APIで確認する。

{
  "progress": "2/2",
  "results": [
    {
      "model": "hf.co/LiquidAI/LFM2.5-1.2B-JP-GGUF:Q4_K_M",
      "status": "done",
      "response": "日本の首都は東京です。東京は日本の最大都市であり、経済・文化・交通の中心地として知られています。",
      "duration_ms": 2110
    },
    {
      "model": "gemma3:1b",
      "status": "done",
      "response": "日本の首都は東京です。",
      "duration_ms": 2709
    }
  ]
}

progress: 2/2。両モデルとも正答、duration_msも記録済み。

前回Queueに積んだまま眠っていたタスクが、初めて処理された瞬間だった。

systemdで自動起動化

動作確認ができたので、常時稼働させる。

/etc/systemd/system/ollama-worker.service を作成。

[Unit]
Description=Ollama Worker
After=network-online.target

[Service]
Type=simple
User=hogehoge
WorkingDirectory=/home/hogehoge
ExecStart=/home/hogehoge/worker/venv/bin/python /home/hogehoge/worker.py
Restart=always
RestartSec=5

[Install]
WantedBy=default.target

再起動後に systemctl status で active (running) を確認。

これでThinkCentreの電源を入れるだけで、Workerとして自動参加する構成になった。

現在の構成

ThinkPad P50（192.168.0.2）
  └─ Hyper-V
       └─ AI-Core VM（192.168.0.10）
            ├─ FastAPI Coordinator  :8000
            ├─ Redis               :6379
            └─ PostgreSQL          :5432

ThinkCentre moon（192.168.0.4）
  ├─ Ollama
  │    ├─ hf.co/LiquidAI/LFM2.5-1.2B-JP-GGUF:Q4_K_M
  │    └─ gemma3:1b
  └─ ollama-worker.service（常時稼働）

Coordinatorがタスクをキューに積み、Workerが拾って処理する。

構想段階で描いていた最小構成が、ようやく動き始めた。

次にやること

Workerはまだ1台。

次のステップは、

RTX 3070 Ti搭載PCをGPU Workerとして追加
重いモデルの処理をGPU側へ自動振り分け
Worker起動時のヘルスチェックと自動登録

複数のWorkerがそれぞれ得意な処理を担当する形に近づけていく。