オープンソース モデルに実際に最初に加わるのは、サプライ チェーンの問題です。

ひとたびこうした話題が「封印」と書かれると、あまりにドラマチックな絵に注目が集まってしまう。プロジェクトのより一般的な変更はそれほど劇的ではありません。パブリック ダウンロード ソースが不安定になり、ミラー サイトが出現し始め、特定のバージョンが棚から削除され、継続的な更新のリズムが中断され、チームの手中にある推論チェーンが突然保持されなければならなくなります。

ホスティング層が最初にプレッシャーを受ける

オープンソース モデルについて議論すればするほど、あることが明確に見えてきます。ポリシー、輸出規制、プラットフォーム ルールによって直接影響を受ける可能性があるのは、多くの場合、配布された重み付けされた文書ではなく、パブリック ホスティング、オンライン推論、バージョン配布、およびデフォルトの入り口です。

これは、「封鎖された」ように感じても、実際に遮断されるパスは、多くの場合、最も容易なパスであることを意味します。これまでは、URL を取得し、ホスティング インターフェイスを設定し、それを呼び出すという単純なプロセスであったものが、イメージの検索、署名の追加、ハッシュの確認、ライセンスの確認、ロールバック バージョンの確認に突然変わりました。アクションは小さく見えるかもしれませんが、それらがつながると完全なサプライ チェーンが形成されます。

バージョンがフォークされると、名前だけでは問題が説明されなくなります。

オープンソース モデルの最も難しい部分は、決して「存在するかどうか」ではありません。重みが複数のイメージ、複数の組織ウェアハウス、および複数の微調整ブランチに広がると、同じ名前の下で異なる動作が増加することになります。

現時点では、「モデルがまだ存在するかどうか」を議論するだけではもはや十分ではありません。より厄介な問題は、どれが本線で、どれが単なる鏡像で、どれが 2 回訓練され、どれがまだ元の推論動作を保持しているかということです。名前は依然として同じプロジェクトを指すことができますが、出力は分岐し始めています。この時点でチームがまだ「同じ名前」を「同じもの」とみなしているのであれば、遅かれ早かれオンラインでの結果は乖離することになるだろう。

これは、オープンソース モデルとクローズド ソース API の最大の違いでもあります。クローズド ソース API は接続されていないため、パフォーマンスは非常に簡単です。オープン ソース モデルは分岐しており、表面上はサービスがまだ実行されていますが、舞台裏ではバージョン、依存関係、および動作の境界が変更されています。本当に不安になるのは、失敗ではなく、「まだ機能しているように見える」ことです。

本当に修正する必要があるのは、ソース、ロールバック、およびオフラインの繰り返しです。

プロジェクトにこの種の変更が生じた場合、最初に埋め合わせなければならないのは感情ではなく、ソース、ロールバック、オフライン再発の 3 つです。

ソースは、特定の倉庫、特定の提出物、特定の重量書類まで追跡可能である必要があります。ロールバックでは、名前だけでなく、動作を以前のバージョンに戻すことができる必要があります。オフライン再生では、ネットワークがジッタリングしている場合、ミラーが失われた場合、またはアップストリーム パケットが削除された場合に、同じラウンドの実験を再度実行できなければなりません。

多くのチームは通常、これらのことは自分たちから遠いものだと感じています。ある日、アップストリームの更新によって出力スタイルが変更されたり、特定の画像の同期が遅くなったりするまで、問題はモデルの機能にまったくあるのではなく、依存関係チェーンが第一級市民として管理されていないことにあることがわかります。モデルがオープンソースであればあるほど、これはより明白になります。なぜなら、オープンソースがもたらすのは、常に安定した「無料の入り口」ではなく、サプライチェーンがますます長くなるからです。

最も物理的な部分は通常、モデルの本体ではありません。

運用環境に関しては、通常、最も問題が発生する可能性が高いのは重みオントロジーではなく、デフォルトのエントリ、自動更新、および暗黙的な依存関係です。

チームが特定のオンライン ポータルを唯一のソースとみなしている場合、今日はそのポータルに電話をかけることができますが、明日は一時的に代わりのポータルを見つけなければならない可能性があります。ミラー ステーションをデフォルトの真実と見なす場合、バージョン ドリフトはトレーニングと評価に静かに忍び込みます。更新のリズムが厳しすぎると、今日の動作の安定性が不明確になり、明日の新しいバージョンがオンラインになるでしょう。

したがって、この種の問題は国際政治のように見えますが、エンジニアリングに関しては、サプライチェーンのガバナンスのように見えます。誰がエントリを管理するか、誰が署名を担当するか、誰がロールバックを定義するか、誰が古いバージョンを保存するか、誰がオフラインで再構築できるか、これらは配信に影響を与える境界となります。モデル自体が公開されると、外部のアクションのために残されるスペースは小さくなります。チームが独自のレッスンを組み立てるために残されるスペースがさらに大きくなります。

オープンソース モデルが「封印」されるかどうかは、少し狭い問題です。より現実的な判断は、オープンソースになればなるほど、1 回のアクションでそれを抑えるのが難しくなる、ということです。しかし、オープンソースになればなるほど、バージョン、ソース、ロールバック、オフラインでの繰り返しの管理が必要になります。このサプライチェーンが封じ込められないと、外部変動が増幅されて「模範事故」のような事故が発生してしまいます。