NVENCが起動しないとき：モデルで埋まったGPUと、フォールバックするレンダラー
動画
当社のビデオレンダラーは、スクリプトを生成する言語モデルと同じマシンで動作しています。ある夜、ハードウェアエンコーダーが起動しなくなりました。「CUDA_ERROR_OUT_OF_MEMORY: out of memory」、続いて「No capable devices found」と表示されました。
何が起きたか
マシンはNVIDIA GB10デスクトップで、CPUとGPUがメモリプールを共有しています。ローカルモデルはvLLM経由で提供し、Studioは同じマシン上でffmpegを使い、可能であればNVENCでレンダリングします。テスト実行中、エンコーダーはCUDAコンテキストの作成に失敗しました。失敗は数秒以内に現れて消えました。短いNVENCプローブは成功しましたが、直後のレンダリングは失敗しました。次の実行ではプローブ自体が失敗し、その次の実行ではプローブとレンダリングの両方がNVENCで正常に完了しました。
なぜか
vLLMは起動時にモデルとそのキャッシュ用にGPUメモリの固定分を確保します。NVENCはセッションごとのCUDAコンテキスト用に少量のメモリを必要とします。モデルサーバーや他のジョブがメモリをすべて使い切ると、エンコーダーはチップ上の別エンジンであり、GPUの計算能力をほとんど消費しないにもかかわらず、起動できなくなります。
対策：プローブ時ではなく、エンコード時に判断する
起動時のプローブは、NVENCが直前に動作したことを示すだけで、次のファイルでも動作するとは限りません。そのためStudioは、レンダリングごとにNVENCを試行し、ffmpegが失敗した場合は同じフィルターグラフをlibx264で再実行します。ライブチャンネルでは、開始前にライブ設定で0.5秒間のテストエンコードを実行し、NVENCが失敗した場合はlibx264を使用します。配信途中でNVENCまたはCUDAのエラーが発生した場合は、次の開始時にlibx264へ切り替えます。完成した動画ごとに使用したエンコーダーが記録されるため、フォールバックが発生した場合はジョブファイルに反映され、見逃されることはありません。
フォールバックのコスト
予想より少なかったです。同じマシンの20コアArm CPUで、カメラワーク、焼き込み字幕、ラウドネス正規化を含む1080p動画12秒を、libx264は7.6秒でレンダリングしました。1日1回程度の短い動画であれば、CPUは十分なエンコーダーです。GPUはエンコードよりも画像モデルにとって重要度が高いです。
まとめ
共有マシンでは、GPUエンコーダーをオプションとして扱ってください。利用可能なら使用し、そうでなければフォールバックし、どちらを使ったかをログに残します。モデルサーバーがすでにメモリをほぼ占有しているマシンで、独自のメモリを必要とするGPU機能にも同じことが言えます。Studioでは、この動作がデフォルトで有効になっています。