1台のGPUでローカルAIモデルを実行しながら動画をトランスコードできますか？

はい、ビデオエンジン、計算性能、VRAM、電力、ドライバーに十分な余裕があれば、1台のGPUでビデオトランスコードとローカルAIを同時に処理できる場合があります。

メディアのトランスコードでは専用のデコード／エンコードブロックを使用できる一方、AIモデルは主に行列演算または汎用計算を利用し、モデルの重みとコンテキストをVRAMに保持します。この分離により並行処理が可能になりますが、完全に独立しているわけではありません。フィルター、トーンマッピング、モデルの読み込み、メモリー圧迫、クロック、温度、共有ドライバーコンテキストによって、一方のワークロードが他方を妨げることがあります。実際のカードで段階的な同時実行テストを行い、判断してください。

各ワークロードが使用するGPUエンジンを確認する

まずハードウェアトランスコードを1つ実行し、デコード、エンコード、計算、メモリーコントローラー、VRAM、電力の使用状況を記録します。次にトランスコードを停止し、同じ測定項目で代表的なAIリクエストを1つ実行します。

メディアサーバーは固定機能のビデオエンジンを使用し、AIランタイムはCUDA、ROCm、oneAPIなどの計算経路を使用できます。これにより処理を重ね合わせられることが多いものの、字幕の焼き付け、スケーリング、トーンマッピングによって、ビデオパイプラインの一部が汎用計算に移る場合があります。

メディアセッションでCPUしか使用されていない場合は、共存テストの前にハードウェアトランスコードを修正してください。AIモデルがVRAMに収まらず、主にCPUで実行されている場合、共有GPUの問題はすでにシステムメモリーとCPU性能全体の問題になっています。

単一ワークロードで安定した基準値を確立する

メディアストリームだけを、起動、負荷の高いシーン、シーク、再開の各段階で測定します。トランスコード速度、バッファー状態、GPUエンジン負荷、VRAM、CPU使用率、電力を記録してください。

AIモデルは、実際に使用する量子化、コンテキストサイズ、バッチ、同時実行数で単独実行します。モデルの読み込み時間、1秒あたりのトークン数、最初のトークンが出るまでの時間、読み込み後のVRAM使用量、コンテキスト増加時のピークメモリーを記録します。Ollamaユーザーからは、GPUの一部オフロードが報告されているため、GPUに完全常駐する基準値と区別する必要があります。

ZimaSpaceのホームNAS向けGPU確認ガイドでは、同時実行テストの前に必要なハードウェアと電力の確認項目を解説しています。

モデルとビデオパイプラインの両方にVRAMを確保する

アイドル時のVRAM、モデル常駐時のVRAM、コンテキストの増加量、ビデオのデコード、フィルター、エンコード開始時に追加で割り当てられるメモリーを記録します。GPUの公称容量ぎりぎりで計画せず、意図的に余裕を残してください。

AIモデルはリクエスト後も常駐し、他のGPU処理を妨げる場合があります。Ollamaの課題では、別のアプリケーションがGPUを必要とした際、サービスを再起動するまでモデルがVRAMに残り続けた事例が説明されています。

合計ピーク使用量がVRAMの上限に近づく場合は、より小さい量子化、短いコンテキスト、低い並列度、短いキープアライブ時間、または小さいモデルを使用してください。システムメモリーへの退避を同等の容量として扱わないでください。レイテンシーが大幅に増加し、両方のサービスが不安定になる可能性があります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

段階的な同時負荷テストを実行する

AIモデルを起動して常駐状態にした後、通常のハードウェアトランスコードを1つ開始します。ビットレートの高いシーンで長いプロンプトまたは同時AIリクエストを追加し、数分間にわたって両方のサービスを観察します。

一度に増やす要素は1つだけにします。メディアストリームの追加、コンテキストの延長、AIリクエストの追加、字幕の焼き付け、HDRトーンマッピングなどです。トランスコード速度がリアルタイムを下回った時点、再生がバッファリングした時点、AIレイテンシーが急増した時点、またはGPUがリセットされた時点を記録します。

実用上の限界は、ダッシュボードに一時的に表示できるセッション数ではなく、起動時とピーク負荷時にも安定して動作する最後の組み合わせです。

ドライバーとコンテナコンテキストの障害に注意する

同じ物理GPUを両方のコンテナに意図的に公開し、デバイス識別子、ドライバーライブラリ、ランタイムのバージョン、権限を確認します。異なるレンダーノードを渡したり、一方のサービスからGPUを誤って隠したりしないでください。

共有アクセスは、何時間も正常に動作した後でも失敗することがあります。OllamaのDockerに関する報告では、CUDAコンテキストエラーが発生し、その後JellyfinがNVIDIAハードウェアトランスコードを利用できなくなり、コンテナの再起動が必要になりました。これは、サービス間のGPUコンテキスト障害を示しています。

AI、メディアサーバー、コンテナランタイム、カーネル、GPUドライバーのログを同じ時刻の範囲で取得します。1つのコンテナを再起動すれば復旧する場合もありますが、恒久的な修正は、共有障害を引き起こしたドライバー、ランタイム、モデルメモリー、または同時実行の境界に施す必要があります。

モデルの常駐、キューイング、サービスの優先度を制御する

モデルを終日読み込んだままにする必要があるのか、アイドル時間後にアンロードできるのかを決めます。常駐させると最初のトークンが出るまでの時間は短縮できますが、メディアサーバーが一時的に必要とするVRAMまで予約してしまいます。

複数のGPUアプリケーションは、技術的には1台のデバイスを共有できます。しかし、一方がメモリーのほぼ全容量を消費すると、破壊的な競合が発生します。NVIDIAコンテナのユーザーからは、一方のコンテナがGPUメモリーを飽和させるケースについて、別のワークロードも実行する必要がある状況が報告されています。

再生にはより厳しいサービス目標を設定します。AIの並列度を制限する、長時間の生成をキューに入れる、家族が視聴する時間帯の前に大きすぎるモデルをアンロードする、バッチ埋め込み処理をスケジュール実行に回す、といった方法があります。GPUメモリーや実行動作の制御を、一般的なコンテナのCPU優先度だけに頼らないでください。

ワークロードを分離すべきタイミングを知る

使用するモデルが余裕を持って収まり、通常のトランスコードがリアルタイムより速く、AIレイテンシーも許容範囲内で、障害がコンテナ間に波及しない場合は、1台のGPUを共有できます。テストしたモデル、コンテキスト、ストリーム数、フィルターパスを記録してください。

大規模モデルがVRAMのほぼ全容量を消費する場合、複数のユーザーが同時にトランスコードする場合、HDRや字幕フィルターが計算性能を必要とする場合、AIリクエストのレイテンシーが重要な場合、またはドライバーのメンテナンス中も一方のサービスを稼働させる必要がある場合は、ワークロードを分離してください。

ZimaSpaceのローカルAIの注意すべき兆候に関するチェックリストでは、共有計算リソースがサーバーの中核であるストレージとメディアの信頼性を低下させ始めた際の停止基準を確認できます。