Vision Brokerを作り、Vision Playgroundを修正する

あまり使用率は高くありませんが、画像を扱うAI処理も少しあります。

GPUサーバーには2枚のGPUが挿されていて、1枚は文書生成用、もう1枚は画像用としていますが、小さなVRAMを効率よく使うために、GPUのアクセスを制御したいと思い、画像処理用GPUへのアクセスをキューイングすることにしました。つまり、一度に1つのGPUアクセスしか発生しないという形です。

そのために開発したのがVision Broker。

画像解析用のVisionモデルや、画像生成用のDiffusionモデルを、アクセスプロフィールに応じてロードして実行するブローカーです。

開発したVision Brokerは本番機のGPUサーバーに配備。（上のスクリーンショット）

Vision PlaygroundをOllama + Visionモデルを使う構成から、Vision Brokerのプロフィールを使う構成（内部ではTransformersを使用）に修正しました。このアプリケーションは画像の説明文を生成します。

これがGPUサーバーのnvtop画面。

小さなモデルを使っているので、VRAM使用量は5GB以内の収まっています。

Vision PlaygroundとVision Brokerの関係はこんな感じ。

この程度の処理なら、

• PCIe 4.0 x 4接続
• Quadro RTX 4000 8GB VRAM
• Qwen3-VL:2b-instructモデル

という古い構成でも、文章生成は瞬時に行われます。

Qwen3-VL:4b-instructモデルを使うと、VRAM使用量が8GBを超えるので、開発環境では動くものの本番環境では動きません。

LLM Brokerも、このVision BrokerもLLM RunnerとGPUを抽象化して、アプリケーションからは計算資源を意識しないで済むように、システムコンポーネントとして容易にGPUを差し替えられるようにしています。

次は画像生成系のアプリケーション Vibe Playground をVision Broker対応にします。

Vibe Playgroundは環境データから場の雰囲気モデル = Vibe ModelをAIで生成して画像化する実験的なアプリケーションです。

Vibeモデル および Vibe Playground 技術白書