Oumigo — ローカルGPUフリートでAIエージェントを構築

By /

Oumigoは、GPUフリートを実行・管理するための垂直統合ツールキットである。複数台のGPUサーバーを一つのLLM推論基盤としてまとめ、アプリケーションからはOpenAI互換Web APIとして扱えるようにする。

アーキテクチャ：マネージャーとワーカー

　サーバーのロールは二つある。フリートを統括するマネージャーノードが1台、その配下にGPUワーカーノードがN台という形である。マネージャー、ワーカーはローカルLAN上で動く。

Oumigoアーキテクチャ図：エージェントアプリケーション、Oumigoマネージャー（データプレーン・制御プレーン・プロビジョニング・ダッシュボード）、およびvLLM／TransformerバックエンドのGPUワーカーN台
図1：Oumigoのアーキテクチャ。マネージャー1台がGPUワーカーN台を束ね、単一のエンドポイントとして提供する。

　マネージャーは内部が役割ごとの層に分かれている。制御プレーンは、ワーカーの登録と状態を追跡してライフサイクルを管理する。データプレーンは、リクエストを受けてワーカーへ推論呼び出しを転送する。

　ワーカーは、コーディネーターが常駐で稼働し、LLMサーバープロセスを起動・管理する。ワーカーは自らマネージャーに登録し、ヘルス状態を送り続ける。

　マネージャーはこのほか、性能監視のためのダッシュボード層と、ワーカーをどう起動するかを担うプロビジョニング層（開発予定）を持つ。

主な機能

  • フリートのライフサイクル管理：複数のGPUインスタンスを動的に起動・停止する。vLLMとTransformersの両バックエンドに対応する。
  • 統合ルーティング：データインターフェースと制御インターフェースを一本化し、実行時に健全なワーカーへリクエストを振り分ける。
  • OpenAI互換API：/v1/chat/completions、/v1/completions、/v1/models、およびSSEストリーミングに対応する。
  • Python API：Agent(tools) → Chat → requestという流れで、Agentループ、ツール呼び出し、ストリーミングと非ストリーミングの応答一致、推論内容（reasoning content）の取り出しを備える。
  • ガードレール：エージェント層のインターセプタ連鎖。Guardプロトコルを狭い接点として、ルールベースからモデルベースまで段階的な拡張を、フリート内部に手を入れずに書ける。
  • 性能監視：フリート全体のメトリクス収集と診断。

既存のコードを書き換えずに使える

　データプレーンがOpenAI APIで通信できるため、OpenAI互換のWeb APIに対応したツールであれば、追加開発せずにそのまま接続できる。向き先をマネージャーのルーターにするだけで、フリート全体が一つのURLエンドポイントとして見える。これにより、多くの汎用エージェントパッケージと追加手間なしで連携できる。

Base URL:  http://<manager-host>:<router-port>/v1
Model:     GET /v1/models で取得したモデルID
API key:   空文字列でなければ何でもよい（データプレーンは検証しない）

　例えばopenaiのPythonクライアントであれば、接続先を差し替えるだけで済む。

from openai import OpenAI

client = OpenAI(
    base_url="http://<manager-host>:<router-port>/v1",
    api_key="oumigo",          # 空でなければ何でもよい
)

response = client.chat.completions.create(
    model="<GET /v1/models で得たモデルID>",
    messages=[{"role": "user", "content": "こんにちは"}],
)
print(response.choices[0].message.content)

　編集やコーディングを支援するエージェントでの動作も確認しており、OpenAI APIのSDKやツールであれば同様に扱える。

クイックスタート

　PyPIで公開している。ノードの役割に合わせて、対応するextraを入れる。

$ pip install "oumigo[manager]"    # マネージャー機
$ pip install "oumigo[worker]"     # GPUワーカー機（vLLM + Transformers）
$ oumigo version

　GPUワーカー機ではtorchを個別に入れないこと。vLLMがバージョンを固定しており、対応するCUDAホイールを依存として引いてくるためである。

　詳細はリポジトリのドキュメントを参照されたい。

現在のステータス

項目内容
提供元GotoAI株式会社
バージョンv0.2.0
ライセンスMIT（オープンソース）
バックエンドvLLM、Transformers
対応LLMvLLMまたはHugging Faceが対応するLLM。主要なオープンウェイトモデルはほぼすべて対応可能。
– vLLM対応LLM：https://docs.vllm.ai/en/latest/models/supported_models/
– Hugging Face対応LLM：https://huggingface.co/models
サーバー環境構成StaticProvider（LAN。ワーカーを手動で起動し、自己登録させる構成）
今後開発予定ConoHaやOpenStack系のクラウド環境構成を、同じProviderプロトコルの実装として追加予定

　現時点のプロビジョニングはStaticProvider、つまり手元のGPUマシンをLAN内で立ち上げて使う構成に限られる。クラウド上でワーカーを自動的に確保する実装は、同じProviderプロトコルの上に載る形でこれから追加していく。

リポジトリ

　ソースコード、ドキュメント、Issueはすべてリポジトリにある。フィードバックや不具合の報告を歓迎する。

Scroll to Top