GPUメモリがいっぱいになったとき、ローカルAIサービスはCPUにフェイルオーバーできますか？

はい。ただし、信頼性の高いCPUフェイルオーバーはGPUメモリが枯渇する前に設計しておく必要があります。ほとんどの推論プロセスは、予期しないOOMから透過的に復旧できません。

ホームAIサーバーは、長いプロンプト、大きなバッチ、画像リクエスト、または2つ目のモデルが残りのVRAMを消費するまでは、GPU上ですばやく応答できる場合があります。システムRAMとCPUがアイドル状態でも、次のメモリ割り当てに失敗することがあります。リクエストが処理を継続できるかどうかはランタイムによって異なります。最初から重みをCPUに配置できるものもあれば、別のCPUワーカーと、安全に再試行するルーターが必要なものもあります。

CPUオフロードとCPUフェイルオーバーは異なる問題を解決する

CPUオフロードは、モデルの配置戦略です。選択したレイヤー、テンソル、またはパイプラインのコンポーネントをシステムRAMに置き、必要に応じてアクセラレーターへ移動させることで、通常のリクエストに必要なVRAMを削減します。CPUフェイルオーバーはサービスの動作です。GPU経路が利用できない、またはリクエストを拒否した場合に、別のワーカーがリクエストを受け入れ、ジョブを失わずにCPU互換モデルを実行します。

Hugging Face Accelerateは、CPUオフロード方式を提供し、モデルの状態をCPUメモリと実行デバイスの間で意図的に移動させます。これは、任意のCUDA状態が失敗した後の緊急対応ではなく、計画された異種デバイス実行です。モデル、デバイスマップ、フック、メモリ予算は、推論開始前に準備されます。

部分的にオフロードされたモデルは、すでにCPUを使用していても、すべてのトークンでGPUに依存している場合があります。GPUに障害が発生した場合、そのプロセスが中断されたトークンからCPU上で処理を継続できるとは限りません。真のフェイルオーバーでは通常、CPU対応ワーカー上でリクエストを再起動します。この違いがあるため、アプリケーションがCPU対応をうたっていても、現在のリクエストを完了せずOOMエラーを返すことがあります。

モデルの読み込みに成功した後でもVRAMは枯渇する

モデルの重みは、メモリ予算の一部にすぎません。キー・バリューキャッシュはアクティブなシーケンス長と同時実行数に応じて増加し、一時的なカーネルにはワークスペースが必要です。さらに、画像や音声のエンコーダーがテンソルを追加し、メモリアロケーターが再利用のためにブロックを予約することもあります。そのため、起動時には収まるモデルでも、長いコンテキストや複数ユーザーからの同時リクエストで失敗する可能性があります。

PyTorchはキャッシングメモリアロケーターを使用するため、予約済みとして報告されるメモリは、使用中のテンソルメモリと同一ではありません。断片化やフレームワーク外で行われるメモリ割り当てによって、利用可能な余裕がさらに減ることもあります。フェイルオーバーのトリガーは、1つのダッシュボード上の数値やモデルの読み込みに成功した事実から安全性を推測するのではなく、拒否されたメモリ割り当てとワーカーの健全性を監視すべきです。

このため、「モデルサイズがVRAMを下回っている」という静的なルールだけでは不十分です。サービスは、コンテキスト上限を低く設定したり、同時シーケンス数を制限したり、ランタイムのメモリ割り当てを保護するためにVRAMの一定割合を未使用のまま残したりできます。これらの制御は、GPUプロセスを既知の状態に保ち、受け入れたリクエストのレイテンシーを予測可能にするため、反応的なCPU切り替えよりも多くの障害を防ぎます。

自動再試行が安全なのは、リクエストを再実行できる場合だけ

OOM発生後、ルーターはGPUワーカーを不健全とマークし、解放または再起動してから、元のリクエストをCPUワーカーで再実行できます。外部の副作用が発生していない通常のテキスト生成では、これは機能します。ストリーミング応答、乱数シードを使用する画像パイプライン、またはすでにツールを呼び出した可能性のあるエージェントでは、より難しくなります。

フレームワークによっては、大規模モデルを最初から複数のデバイスに分散することもできます。Accelerateの大規模モデル推論は、モデルが1台のデバイスを超える場合に、デバイスマップとCPUまたはディスクへの配置をサポートします。この方法なら、1つの計画済み実行グラフ内でリクエストを継続できる場合がありますが、容量と引き換えに速度が低下します。また、失敗したリクエストを別のサービスへルーティングすることと混同してはいけません。

CPUに十分なRAMがない場合、ランタイムに互換性のあるCPUカーネルがない場合、リクエストがすでに取り消せない操作を実行した場合、または予想されるCPUレイテンシーがクライアントのタイムアウトを超える場合、フェイルオーバーの前提は成り立ちません。そのような場合は、制御された容量エラーを返すか、リクエストをキューに入れます。無言で再試行すると、副作用が重複したり、インターフェースが約束する時間を大幅に超えてユーザーを待たせたりする可能性があります。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

意図的なメモリテストでフェイルオーバーを検証する

ルーターの背後でGPUワーカーを1つとCPUワーカーを1つ稼働させ、システムRAMを超えない範囲でGPUのプロファイルを超えるリクエストを送信します。最初の失敗、再試行の判断、CPUでの処理開始時刻、最終出力、クライアント接続が維持されたかどうかを記録します。まずストリーミングを無効にして繰り返し、その後、キャンセル、同時トラフィック、モックしたツールを使うエージェントリクエストをテストします。

部分的なGPU実行は有用な基準になります。llama.cpp推論などのランタイムは、モデル処理の設定可能な一部をアクセラレーターに配置しながら、CPUでの実行を維持できるためです。GPU常駐、計画的なCPU/GPU分割、独立したCPUフォールバックの各プロファイルを比較します。ハイブリッドAIワークロードモデルは、容量不足時のフォールバックと通常のクラウドルーティングを切り分けるのに役立ちます。

再試行が1回だけ完了し、リクエストの識別情報が維持され、ツール操作が重複せず、無関係なジョブを失うことなくGPUワーカーが復旧した場合にのみ、その設計を信頼できるものと判断します。CPUでの完了が遅すぎる場合は、対話処理と同等の経路ではなく、キューを維持する安全策として使用します。運用上の目標は、CPUとGPUのサービスレベルが交換可能だと見せかけることではなく、適切に性能を低下させることです。

よくある質問

GPUキャッシュを消去すればフェイルオーバーになりますか？

いいえ。キャッシュの解放によって未使用の予約済みブロックが利用可能になることはありますが、CPUでの実行が可能になるわけではなく、破損したリクエスト状態が修復されたり、次の割り当てに十分な連続メモリが保証されたりするわけでもありません。

CPUフォールバックでは同じ回答が生成されますか？

同じ重み、精度、プロンプト、トークナイザー、サンプリング状態を使用すれば、同じ回答になる可能性があります。ただし、異なるカーネル、量子化、シード、またはストリーミング状態の再起動によって、出力が完全に同一にならない場合があります。

CPUフェイルオーバーより小さいモデルのほうがよいですか？

対話型サービスでは、小さいGPUモデルのほうが適していることが多いです。小さいGPUモデルは予測可能なレイテンシーを提供でき、CPUフェイルオーバーは例外的なリクエストに対する可用性を守ります。2つの仕組みは異なるサービス目標を解決するものであり、組み合わせて使用できます。