@OpenGradient
モデルが失敗したとき、問題は発生しませんでした。
モデルが回復したときに発生しました。
出力は正常に戻り、レイテンシは安定しました。多くのユーザーは次に進みましたが、いくつかの推論記録は依然として新しいリリースを指していました。不具合のあった期間中に、すでに一部のエージェントは振る舞いを適応させていました。誤ったバージョンが稼働している間に、支払いが決済されました。
モデルは戻ってきました。
しかし、信頼は戻りませんでした。
それで私は、OpenGradient の中でのロールバックについて別の考え方をする必要があるのだと気づきました。
重みのロールバックはおそらく最も簡単な部分です。難しいのは、ミスの周辺に関する履歴を保持することです。
どのモデルバージョンが実際にリクエストに応答したのか？
どの Blob ID が出力を生成したのか？
どのプローフパスが推論を検証したのか？
不具合のあったリリース中に、どのエージェントが振る舞いを変えたのか？
新しいバージョンがアクティブだった間に、どの支払いが決済されたのか？
ネットワークが単に古いモデルを復元して、失敗したリリースを隠すだけなら、技術的な問題は消えますが、信頼の問題は残ります。
失敗したバージョンは今も重要です。
監査証跡は重要です。
決済履歴は重要です。
分散型の AI ネットワークは、正しいモデルを提供する責任を負うだけではありません。誤ったものの記録も保持しなければなりません。
だからこそ、OpenGradient におけるロールバックは、従来のソフトウェア更新とは感覚が違います。目的は単に動作する状態に戻すことではありません。目的は、後戻りした経路を完全に可視化することです。
分散型 AI では、古いモデルが再び有効になること自体は本質的な問題ではありません。
本当の問題は次のとおりです：
ネットワークは、不在の間に何が起きたのかを、正確に証明できるのか？
エージェント、証明、支払い、ルーティングがすべて悪いリリースの間も動き続けるなら、ロールバックはコードの問題というより信頼の問題になります。
戻すのは簡単です。
信頼できるほどに、はっきりとした痕跡を残すことが難しい部分です。
#opg #DeAI #OpenGradient $OPG
コミュニティへの質問：
モデルのロールバックが起きた場合、ユーザーにとって最も重要視されるべきなのは何でしょうか。より速い復旧、完全な監査履歴、それとも「各推論がどのバージョンから生成されたか」を正確に示す証明でしょうか？