ローカルAIサービスでGPUからCPUへのフェイルオーバーを可能にする機能とは?

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

GPUからCPUへのフェイルオーバーは、メモリ不足によってアクティブなリクエストが中断される前に、サービスが互換性のある二次実行経路を用意している場合にのみ機能します。

家庭用AIサーバーでは、長いプロンプトによってメモリ使用量が安全な上限を超えるまで、1つのアクセラレーター上で文字起こし、画像検索、LLMを実行できる場合があります。単にメモリ不足エラーを捕捉するだけでは、モデルの状態に一貫性がなくなった後では手遅れです。信頼性の高いフェイルオーバーには、アドミッション制御、互換性のあるCPU用重み、転送可能なリクエスト状態、上限付きキュー、ヘルスシグナル、明確な縮退サービス方針が必要です。

アドミッション制御で割り当て失敗前に逼迫を検知する

ゲートウェイは、GPUリクエストを受け付ける前に、モデルの重み、KVキャッシュの増加量、一時テンソル、バッチサイズ、メモリの断片化を見積もります。予約済みの余裕領域でカーネルと同時実行中のワークロードを保護し、逼迫度のしきい値に基づいて、リクエストを遅延、縮小、オフロード、または別経路へルーティングするかを決定します。

ページ化KVメモリはGPUメモリをページ単位のブロックとして扱い、サービング時の断片化を抑え、KVキャッシュ容量をより効率的に共有できるようにします。これにより安全な動作上限は引き上げられますが、無限のメモリが生まれるわけではなく、明示的なオーバーフロー経路の代替にもなりません。

実際のフェイルオーバー判断では、予測値と観測値の両方を使用します。空きメモリの値だけでは誤解を招くことがあります。キャッシュ型アロケーター、実行待ちのカーネル、別サービスの予約領域によって、チェック後から次の割り当てまでの間にメモリが消費される可能性があるためです。

CPU経路では互換性のあるモデル状態を再構築する必要がある

CPU実行では、GPU経路と同じトークナイザー、モデルリビジョン、量子化の動作、プロンプトテンプレート、サンプリング設定、停止ルールが必要です。サービスは、復旧時間の予算に応じて、CPUレプリカをウォーム状態で保持したり、重みをメモリマップしたり、必要に応じてロードしたりできます。

CPUとGPUのハイブリッド推論は、コンシューマー向けハードウェア上で、CPUとGPUにまたがる予測可能な活性化のスパース性を活用するハイブリッド推論を示しています。この設計からは、CPUの参加を緊急時の代替コピーとしてのみ扱うのではなく、実行モードとして計画できることが分かります。

すでにトークンを生成したリクエストは、KVキャッシュと乱数状態を転送または再計算する必要があるため、移行がより困難です。そのため、多くの家庭向けサービスでは、シームレスなトークン途中の移行を約束するのではなく、リクエスト境界でフェイルオーバーし、冪等性を保って再試行するべきです。

ヘルスチェック、キュー、縮退モードで影響を抑える

サーキットブレーカーは、割り当て障害、ドライバーのリセット、ヘルスチェックの失敗が繰り返された場合にGPUを利用不可として扱います。新しい処理は、同時実行数を減らし、コンテキスト上限を短くするか、小さなフォールバックモデルを使用する別のCPUキューに入れ、処理の遅いリクエストによってホスト全体が機能不全に陥らないようにします。

階層型推論配置は、CPU、GPU、ストレージへの配置を調整し、アクセラレーターのメモリを超えるモデルを実行します。結果からは、高速メモリに収まる場合と低速な階層に依存する場合との間に大きなレイテンシー差があることが分かります。この違いは、その後の家庭環境でのテストでも確認できます。

失敗につながるのは、CPUフェイルオーバーによって同じサービスレベルが維持されると偽ることです。GPUで20秒かかるモデルがCPUでは数分かかる場合があり、対応していないカーネルはまったく実行できない可能性もあります。インターフェースには、フォールバックモデル、制限、推定遅延、キャンセル機能を表示し、処理を黙って停止させないようにするべきです。

制御されたメモリ逼迫下でフェイルオーバーを検証する

短いプロンプト、長いプロンプト、同時実行リクエスト、別のGPUワークロードを再現しながら、利用可能なメモリを徐々に減らします。受付前のルーティング、生成前の割り当て失敗、ドライバーのリセット、CPUキューでのキャンセルを発生させます。自動化を進める前に、中間結果を検査できなければなりません。

結果を、GPUメモリのフォールバックに示されているフォールバック境界と比較します。成功率、重複した副作用、期待される場合のトークン同等性、p95レイテンシー、キュー滞留時間、ホストRAM、復旧時間、ユーザーに縮退モードの状態が表示されたかどうかを記録します。

受け付けたリクエストが1件も消失せず、CPUへのルーティングによってシステムメモリを使い果たさない場合にのみ合格とします。リクエスト途中の移行によって出力が変わったり、ツールの操作が繰り返されたりする場合は、フェイルオーバーを安全なチェックポイントに限定し、それ以外は再開可能なエラーを返します。

テック&AIハブ

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.