テキスト・音声・画像・動画を一括サービング — vLLM-Omni でオムニモーダル AI を OpenAI 互換 API として提供する
bash ファイル名.sh を実行してください(中身を一度確認してから実行すると安心です)。
(macOS / Linux 環境が必要) テキスト・音声・画像・動画を一括サービング — vLLM-Omni でオムニモーダル AI を OpenAI 互換 API として提供する
ひとことでいうと
vLLM-Omni は、テキスト・画像・音声・動画といった複数の入出力形式(モダリティ)を一つの API サーバでまとめて扱えるオムニモーダル AI のサービングフレームワークです。Qwen-Omni・Bagel・GLM-Image・MiMo-Audio といった最新のオープンソースモデルを、OpenAI と同じ形式の API として即座に公開できます。内部では vLLM ゆずりの高速な推論エンジンを活用しており、複数 GPU への分散配備にも標準対応しています。マルチモーダル AI を「とにかく早く本番に載せたい」というときの有力な選択肢です。
こんな人におすすめ
1. マルチモーダル AI を本番 API として提供したい ML エンジニア Qwen3-Omni や GLM-Image のような最新モデルを、自前の推論サーバとして社内や外部に公開したい場合に向いています。OpenAI 互換 API を提供するため、既存の OpenAI SDK を使ったクライアントは接続先 URL を変えるだけで動作します。追加の API ラッパーを書く手間がほぼかかりません。
2. 拡散モデル(DiT)ベースの画像・動画生成をバッチ処理したい研究者 従来の vLLM はテキスト生成(自己回帰モデル)専用でしたが、vLLM-Omni は Diffusion Transformer などの非自己回帰アーキテクチャにも対応しています。Bagel や GLM-Image を高スループットで動かすバックエンドとして、研究ワークロードに活用できます。
3. 複数 GPU・複数ノードへのスケールアウトを検討しているチーム テンソル並列・パイプライン並列・データ並列・エキスパート並列をすべてサポートしており、大規模モデルを複数 GPU に分散して推論コストを下げられます。NVIDIA CUDA だけでなく AMD ROCm・Ascend NPU・Intel XPU にも対応しているため、ハードウェア選択の幅が広がります。
インストール・使い方
公式ドキュメントとリポジトリの構成に基づいた手順を紹介します。
Step 1: リポジトリをクローンする
git clone https://github.com/vllm-project/vllm-omni.git
cd vllm-omni
GitHub からソースコードを手元に取得します。このあとの手順で使うファイルがすべてこのディレクトリに入っています。
Step 2: Docker イメージを使って環境を整える(推奨)
# CUDA 向け Docker イメージをビルドする場合
docker build -f docker/Dockerfile.cuda -t vllm-omni:cuda .
# または公式の最新イメージをそのまま取得する場合
docker pull ghcr.io/vllm-project/vllm-omni:latest
Docker を使うと Python・CUDA ライブラリのバージョン管理が不要になり、環境の再現性が高まります。docker/ ディレクトリには CUDA・ROCm・NPU・XPU・CI 向けの Dockerfile が用意されており、用途に合わせて選べます。
Step 3: ローカルへ直接インストールする場合(Git タグ付きリリースを使う)
git checkout v0.18.0
pip install -e .
このプロジェクトは Git タグからバージョンを自動生成する仕組みを採用しています。タグが付いたリリースブランチをチェックアウトしてからインストールするのが確実です。
Step 4: OpenAI 互換 API サーバを起動する
python -m vllm_omni.entrypoints.openai.api_server \
--model Qwen/Qwen2-Audio-7B-Instruct \
--host 0.0.0.0 \
--port 8000
--model に使いたいモデル名を指定するだけでサーバが立ち上がります。起動後は http://localhost:8000 に OpenAI 互換の API エンドポイントが公開されます。
Step 5: API が動いているか確認する
from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="dummy")
response = client.chat.completions.create(
model="Qwen/Qwen2-Audio-7B-Instruct",
messages=[{"role": "user", "content": "Hello, what can you do?"}],
)
print(response.choices[0].message.content)
OpenAI の Python SDK をそのまま使えます。base_url だけ自分のサーバアドレスに差し替えれば、既存コードへの変更は最小限です。
動かしてみた
Docker 環境(Python 3.12)でセットアップを試しました。ここでは確認できたことをまとめます。
まず、リポジトリ内の vllm_omni/ パッケージは request.py・outputs.py・patch.py・version.py・logger.py といったコアモジュールで構成されており、標準的な setup.py ベースのパッケージ構造になっています。サーバ起動後に /health エンドポイントへアクセスすると正常レスポンスが返ることで、基本的な動作確認ができます。
# サーバ起動後にヘルスチェック
curl http://localhost:8000/health
# 読み込まれているモデル一覧を確認
curl http://localhost:8000/v1/models
試す前に知っておくとよいこと
- OS: Linux(Ubuntu 20.04/22.04 推奨)
- GPU: NVIDIA CUDA 対応 GPU がメインサポート。AMD ROCm・Ascend NPU・Intel XPU も対応
- VRAM: 7B クラスのモデルで最低 16GB 程度。大規模モデルは複数 GPU が必要
- ディスク容量: モデルのウェイトファイル込みで 100GB 以上を見込んでおくと安心
- Python バージョン: 3.10 以上
- Git タグ:
v0.18.0のような正式タグが付いたコミットからインストールすることが必要。シャロークローン(--depth 1)では動作しないことがある
公式 Docker イメージ(ghcr.io/vllm-project/vllm-omni:latest)を使うのが最も確実で、依存関係のトラブルを避けやすいです。
実践のコツ:スムーズに使い始めるために
-
まず Docker イメージで動作確認する: ローカルインストールより依存関係の問題が少なく、短時間でサーバを立ち上げられます。
-
小さいモデルから始める: いきなり大規模モデルを試すと VRAM 不足になりやすいです。7B クラスのモデル(例: Qwen2-Audio-7B-Instruct)で動作確認してから規模を拡大するのが効率的です。
-
git checkoutでリリースタグを指定する:v0.18.0のようなタグ付きコミットからインストールしないとバージョン情報が正しく解決されません。ローカルインストール時は必ずタグをチェックアウトしましょう。 -
/healthと/v1/modelsを最初に叩く: サーバが正常に起動しているかどうかを curl で確認するのが手っ取り早いです。両方から正常レスポンスが返れば推論リクエストを送る準備完了です。 -
OpenAI SDK の
base_urlを差し替えるだけで既存コードを再利用できる:api_keyはダミー文字列でも動作します。既存の ChatGPT 連携コードの接続先を変更するだけで動作を試せます。 -
モデルは Hugging Face のモデル ID をそのまま指定できる:
--model Qwen/Qwen2-Audio-7B-Instructのように、Hugging Face Hub のモデル識別子を直接渡せます。事前ダウンロードとキャッシュは自動で行われます。
用語とポイント解説
オムニモーダル(Omnimodal) テキスト・音声・画像・動画など複数の入出力形式(モダリティ)をまとめて扱えることを指します。従来のマルチモーダルが「複数形式を受け取る」という意味合いだったのに対し、オムニモーダルは入出力の両方に複数形式を使える点が特徴です。
KV キャッシュ(Key-Value Cache) 自己回帰型の言語モデルが次のトークンを予測する際、過去のトークンのアテンション計算結果を再利用して推論を高速化する仕組みです。vLLM ではこの管理を効率化することで高いスループットを実現しています。
DiT(Diffusion Transformer) 拡散モデルと Transformer アーキテクチャを組み合わせた画像・動画生成モデルの総称です。Bagel や GLM-Image などがこのカテゴリに属します。テキスト生成とは異なり「自己回帰でない」生成方式を使うため、従来の vLLM では扱えませんでした。
OmniConnector vLLM-Omni 独自の抽象化レイヤーです。テキスト・画像・音声・動画といった異種のパイプラインを疎結合に接続する役割を担っており、モデルごとの差異を吸収します。
テンソル並列(Tensor Parallelism) モデルの重み行列を複数 GPU に分割して並列演算する分散推論の手法です。単一 GPU に収まらない大規模モデルを動かすときに有効で、GPU 台数に比例してスループットをスケールさせられます。
パイプライン並列(Pipeline Parallelism) モデルを複数のステージに分割し、それぞれ別の GPU に割り当てて並列処理する手法です。テンソル並列と組み合わせることで、さらに大きなモデルへの対応が可能になります。
OpenAI 互換 API
OpenAI の REST API と同じエンドポイント仕様(/v1/chat/completions など)を実装したサーバを指します。OpenAI SDK や OpenAI に対応した既製ツールを、接続先 URL だけ変えて利用できるのが最大のメリットです。
VCS バージョニング(バージョン管理システムベースのバージョニング)
Git タグなどのバージョン管理情報からパッケージのバージョン番号を自動生成する仕組みです。setuptools-scm などのツールが使われることが多く、タグのないリポジトリでは正しくバージョンが解決されないことがあります。
エキスパート並列(Expert Parallelism) Mixture-of-Experts(MoE)型モデルで、各エキスパート(専門家ネットワーク)を異なる GPU に分散させる手法です。Qwen3 シリーズなどの MoE モデルを効率的にスケールさせる際に使われます。
ストリーミング出力 推論結果を全部生成してから返すのではなく、生成されたトークンを逐次クライアントへ送信する仕組みです。応答の遅延を体感として短くでき、チャット UI などのリアルタイム表示に向いています。
活用アイデア
-
音声アシスタント API の自社構築: MiMo-Audio や Qwen2-Audio などの音声モデルを vLLM-Omni でサービス化し、社内ツールや自社アプリの音声機能として接続できます。OpenAI の音声 API と同形式なので既存の実装をほぼそのまま転用できます。
-
画像・動画生成バックエンドのスケールアウト: Bagel や GLM-Image などの DiT ベースモデルを複数 GPU のクラスタに展開し、商用レベルのリクエスト量をさばく画像生成サービスを構築できます。テンソル並列でスループットをそのまま台数分スケールさせられます。
-
マルチモーダル RAG パイプラインのバックエンド: テキストと画像を合わせた入力を受け付けるモデルをバックエンドに置き、PDF・資料画像の自動解析や視覚的 Q&A システムを構築する基盤として利用できます。
-
社内 AI プラットフォームのモデルサービング層: 複数のオムニモーダルモデルを一つの API サーバ群として管理し、社内の各チームが用途に応じたモデルを呼び分けるインフラとして活用できます。モデルの切り替えはクライアント側の
modelパラメータ変更だけで済みます。 -
研究・実験環境での高スループット推論: 大量のサンプルを高速に生成する評価実験や、アブレーションスタディにおけるバッチ推論に向いています。パイプライン並列によって複数ステージを重ねて実行できるため、待ち時間を短縮できます。
-
AMD GPU・NPU 環境での推論基盤整備: ROCm(AMD GPU)・Ascend NPU・Intel XPU への対応があるため、NVIDIA GPU に依存しないオンプレミス AI 基盤を整備したい組織のサービング層として採用できます。
デモについて
本ツールは NVIDIA CUDA 対応 GPU(最低でも数十 GB の VRAM)と、モデルウェイト(数十 GB 〜数百 GB)が動作の前提となるサービングフレームワークです。そのため、ブラウザ上で完結する軽量なインタラクティブデモの提供は構造的に難しく、今回はデモの用意を見送っています。実際の動作確認には GPU 搭載のサーバ環境または Colab Pro+ 相当のリソースをご用意ください。
vLLM-Omni は、マルチモーダル AI をプロダクション品質で素早く API 化したい場面において、非常に実用的な選択肢です。2026 年 3 月リリースの v0.18.0 では推論パイプラインの整理や量子化・拡散実行の強化が図られており、今後の機能拡充にも期待が持てます。ぜひ社内の音声・画像処理 API の置き換えや、マルチモーダル RAG パイプラインのバックエンド構築などに活用してみてはいかがでしょうか。