1台のホームサーバーの電源状態が変わると、分散推論が一時停止するのはなぜですか？

エヴァ・ウォン

IceWhale author

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

Why Does Distributed Inference Pause When One Home Server Changes Power State? - Zima Store Online

分散推論では、1台のホームサーバーが電源状態を変更すると一時停止が発生します。同期されたワーカーは、遅延または切断された参加者の処理速度までしか進めないためです。

テンソル並列、パイプライン並列、モデル並列による推論では、リクエスト全体の独立したコピーを作成するのではなく、1つのリクエストを複数のマシンに分割します。ノードが低電力状態に移行したり、デバイスクロックを変更したり、インターフェースをサスペンドしたり、スリープから復帰したりすると、次のアクティベーションやメッセージの到着が遅れます。他のステージではキューにある処理を使い果たして集合通信の待機状態に入り、1台のローカルな状態遷移が、全体から見える一時停止へと変わる可能性があります。

並列推論ではサーバー間の依存ポイントが生じる

テンソル並列では、各レイヤーの処理中にワーカー同士が部分的な結果を交換します。パイプライン並列では、下流ステージが上流ステージからのアクティベーションを必要とします。どちらの設計にも、1つの参加者からデータが届かないと有効な処理の進行が妨げられるポイントがあります。この違いは、後述する家庭環境でのテストでも確認できます。

モデル並列の集合通信設計では、Transformerの計算を複数のアクセラレーターに分割し、結果を結合するために集合通信を使用します。この構造から、同じモデル出力を維持したまま、1つのランクが遅いピアを単純にスキップできない理由が分かります。自動化に進む前に、中間結果を検証可能な状態に保つ必要があります。

リクエストのレプリカは異なる動作をします。別のレプリカが新しい処理を受け付けられる一方で、状態が遷移中のノードに紐付いた処理中のリクエストには、依然として再試行または再構築が必要です。冗長化は、部分的に完了した推論の継続よりも、処理の受付可用性を高めるのに適しています。

電源状態の遷移では計算と接続が同時に遅延する

サーバーがパフォーマンス状態を変更すると、CPUやアクセラレーターのクロックを下げたり、コアを休止させたり、デバイスをサスペンドしたり、イーサネットリンクを再ネゴシエーションしたりする場合があります。復帰時には、通常のスループットに戻る前に、ドライバー状態の再読み込み、メモリマッピングの復元、キャッシュのウォームアップ、通信チャネルの再確立も行われます。

パイプラインバブルに関する研究では、パイプライン実行を、順次分割されたパーティションをマイクロバッチが移動する処理としてモデル化しています。1つのステージが停止すると、キュー内のマイクロバッチが消費され、空いたスロットがバブルとしてパイプライン全体に波及します。この境界は、現実的な運用条件の下で個別に測定する必要があります。

クロックのみの変更であれば短時間のストラグラーが発生するだけかもしれませんが、スリープやリンクの切断では、ハートビートや集合通信のタイムアウトを超える可能性があります。その場合、サービング層がグループを再構築したり、リクエストを中断したりするため、物理的な状態遷移そのものより長い空白が生じます。

ストラグラーへの対応方針が一時停止を復旧処理に変える

厳密な同期では、最も遅い参加者を待ちます。タイムアウト方式のシステムでは、制限時間まで待機した後に失敗または再構成します。投機的または冗長な設計では、選択した処理を複製できますが、余剰容量と互換性のある状態が必要です。複数のソースが限られたコンテキストを奪い合うと、この実際的な影響が現れます。

分散ストラグラー同期の分析では、遅いワーカーを待つ場合と、古い状態または不完全な協調で処理を進める場合のトレードオフを説明しています。厳密な分散推論では、古いレイヤー出力は通常、現在のリクエストのアクティベーションと交換可能ではないため、許容範囲は狭くなります。

すべての一時停止を電源管理のせいにすることが、障害の境界になります。ネットワークの混雑、サーマルスロットリング、ガベージコレクション、ページフォールト、ストレージの読み取り、長いプロンプトでも、同じストラグラーのパターンが発生する可能性があります。クロックやリンクのイベントを、ランクごとのタイムラインと相関させてください。

-15% OFF

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

Single board computer zimaboard2

1つの電源イベントをすべての推論ランクにわたって追跡する

同期されたクロックを使い、固定リクエストを送信しながら、サーバーごとの電源状態、CPUとアクセラレーターのクロック、リンク状態、ハートビート、集合通信の所要時間、パイプラインのキュー深度、ランクごとのカーネル時間、タイムアウト、再試行、リクエスト完了を記録します。安定したベースラインを確立した後にのみ、低電力状態への制御された遷移を1回だけ発生させてください。

分散トレーシングを使用してローカルサービスのスパンを接続し、クロックの低下、インターフェースの省電力化、サスペンド、ノード全体の喪失を個別に比較します。「電源イベント」のような単一のラベルでは、実質的に異なる復旧経路が隠れてしまいます。この依存関係は、最終的なインターフェースでも明示したままにする必要があります。

変更されたノードで一時停止が始まり、別の場所にある想定された依存ポイントでその一時停止が現れれば、テストは合格です。重要なワーカーを適切な電源ポリシーに固定し、リンクを常時稼働させるか、計算、転送、復旧のどれが支配的かを特定した後にのみ、リクエストレベルの冗長化を追加してください。