vLLMがNVDECのマルチGPUテストを公開、動画キャプション生成のスループットはCPUデコード方式の2倍超に

vLLMは9月18日、マルチGPUによる動画キャプション生成のデプロイ検証結果を公開した。PyNvVideoCodec経由でNVIDIAのNVDECハードウェアデコーダーを使用し、8基のH100でGPUごとに1つのサービスレプリカを稼働させたところ、CPUデコード方式の2倍を超えるスループットを達成した。今回公開されたのはスケーリングテストとデプロイ方法であり、記事の日付を、この機能が初めてライブラリに導入された日付とみなすことはできない。[技術記事](https://vllm.ai/blog/2026-09-18-pynvvideocodec)

この種の処理では、視覚言語モデルを用いて約100〜200トークンの短いキャプションを生成することが多い。モデルの出力は速い一方、動画のデコードに多くの時間がかかる。同じホスト上でGPUレプリカを増やすと、デコード処理によってCPUの処理能力が先に限界に達する可能性がある。したがって、性能向上はデータ準備のボトルネックを取り除いた結果であり、モデル自体の計算が2倍に高速化したと直接解釈することはできない。[テスト条件](https://vllm.ai/blog/2026-09-18-pynvvideocodec)

実装には、引き続きGPUとホスト間のデータ転送が含まれている。ソースコードによると、デコード後のフレームはページロックされたホストメモリにコピーされ、その後マルチモーダル前処理に渡される。また、デコーダースロットを保持し、動画の切り替え時には既存オブジェクトの再設定を優先することで、パーサーやバッファーを繰り返し作成するコストを削減している。この処理経路は、全工程でデータをGPU上に保持するゼロコピーパイプラインにはまだなっていない。[デコード実装](https://github.com/vllm-project/vllm/blob/main/vllm/multimodal/video.py)

デプロイ時にはメディアパラメーターで`backend=pynvvideocodec`を指定できるが、API側のデコードプロセスとモデルエンジンがGPUを共有するため、事前にCUDA MPSを起動する必要がある。ドキュメントでは、`--mm-ipc-gpu-memory-gb`に正の値を設定することも求めている。このメモリ予算の分だけKVキャッシュに使用できる領域が減り、予算を使い切るとデコード処理は待機する必要がある。各APIプロセスはデフォルトで2つのハードウェアデコーダースロットを確保し、スロット数を増やすとGPUメモリの予約量も増加する。[デプロイドキュメント](https://docs.vllm.ai/en/latest/features/multimodal_inputs/)

技術検証の次の段階では、動画形式、サンプリングするフレーム数、出力長を固定し、GPUを1基から8基まで増やした際のスループット、CPU使用率、テールレイテンシを比較すべきだ。公式の数値は特定のキャプション生成ワークロードに基づくもので、今回は独立した再現検証の結果を得られていない。長い出力や大規模モデルを扱うサービス、あるいはKVキャッシュがすでに満杯のサービスでは、効果が異なる可能性がある。また、ドキュメントではストリーミング動画にDeepStreamバックエンドを推奨しており、今回のファイルデコード用の構成をそのまま適用することはできない。[適用範囲](https://docs.vllm.ai/en/latest/features/multimodal_inputs/)