#opg $OPG
カジュアルに;-

OpenGradientのルーティングシナリオをテストしていたとき、あるリクエストがレイテンシ目標を常に外し続けることがありました。スケジューラは想定どおりの動きをしました。つまり、最も近い推論ノードを選んだのです。紙の上ではそれが明らかな最適解でした。ところが現実には、そのノードはモデルの準備ができていませんでした。少し遠いノードが暖かい状態でほとんどアイドルなのに対し、近いノードはモデルを引っ張り始めます。短いネットワーク経路が、結局は遅い実行経路になってしまったのです。

それが最初の驚きでした。

私は、ノードの配置を地理パズルのように考えていました。つまり、ユーザーに近い場所にノードを置けばレイテンシが改善する、という発想です。ですが実際には、地理は単に要因の一つに過ぎない、調整（コーディネーション）の問題です。距離は確かに重要です。しかし、それだけではなく、GPUの能力、現在のキュー圧、モデルがウォームかコールドか、そしてプライマリが苦戦したときのフォールバックの挙動も影響します。見た目の地図は均等に配分されているように見えても、裏側の依存関係グラフはそうでないことがよくあります。

もう一つのひねりとして、別々の都市にある2つのノードでも、同じクラウドプロバイダや運用者、地域ネットワークを共有していることがあります。そうした共有の依存関係があると、相関した障害が起きやすくなります。フルノードと推論ノードは、また別のゲームをしています。フルノードは、証明の伝播と、地域の障害からの独立性に関するものです。一方、推論ノードは、モデルのローカリティと応答時間をより重視します。そしてデータノードも混ぜると、今度はユーザーへの近さより、データソースへの近さのほうが重要になることすらあります。

施設配置（ファシリティ・ロケーション）モデルは、こうしたトレードオフを分かりやすくしてくれるので有用ですが、インセンティブの問題は解決しません。事業者（オペレータ）にとって、実際にユーザーに見えるレイテンシと共有された障害モードを減らす場所へノードを追加する動機は何なのでしょうか？

本当の試験は地図そのものではありません。次にどのノードが展開されるか、そしてそれがユーザーが体感する遅延や相関障害を、測定可能な形で本当に減らせるかどうかです。配置判断を左右すべきなのは、単に地理の見た目ではなく、この指標です。@OpenGradient