中国のオープンソース モデルが制限された後、最初にフォークするのはバージョンと評価口径です。

このような制限が解除されると、通常、最初に問題になるのは、「まだダウンロードできるか?」ということではありません。しかし、「それでも同じスコアのセットに基づくことができるでしょうか?」

モデル自体はまだ存在しており、ミラーリングも同期できますが、問題は入り口から比較に移り始めます。現在正常に動作するバージョンでも、重みスライス、トークナイザーのバージョン、推論パラメーター、ミラーリングの遅延などにより、別のマシンでは若干の違いが生じる可能性があります。それぞれの出力を見ると、まだ動作しているように見えます。回帰セットに戻すと、曲線は広がり始めます。以前は、アップグレードするかどうかを決定するために合計スコアを確認するだけで済みましたが、現在では、最初に「この変更がモデルによるものなのか、サービス スタックによるものなのか」を明らかにする必要があります。

制限によって引き起こされる本当の問題は、ダウンロード操作自体にあるのではなく、比較関係が細断されることにあります。以前は、1 つのアップストリーム バージョンに注目するだけで済みましたが、現在では、多くの場合、公式ソース、ミラー ソース、内部キャッシュ、量子化バージョン、および一時ロールバック バージョンが同時に存在します。すべてのラインを実行できますが、結果は同じベースラインを共有しなくなります。評価セットがフォークされると、チームはすぐに共通言語を失います。R&D はこのバージョンは改善されたと言い、製品はオンライン エクスペリエンスは変わっていないと言います。トラブルシューティング担当者は、まずモデルが変更されたか、推論環境が変更されたかを確認する必要があります。

この種のフォークの最も厄介な点は、それがすぐには故障として現れないことです。初日、2 つの環境間の差はわずか 0.3 ポイントでした。 2日目、とある長文サンプルが漂い始めた。 3 日目にロールバックした後、古い結果を再現できないことがわかりました。この段階では、議論はもはや「モデルを入手できるかどうか」という話ではありません。しかし、「得られるものは同じかどうか」。

本当に最初にシャットダウンする必要があるのは、ダウンロードの入り口ではなく、ベースラインです。少なくとも次のことを確認する必要があります。

• モデル ファイルのハッシュ、トークナイザーのバージョン、量子化方法、および推論パラメーター。
• 評価セット、プロンプトワード、サンプリングパラメータ、後処理ロジック。
• オンライン サービスとオフライン回帰によって共有される推論カプセル化により、2 つの実装セットのドリフトを防止します。
• ロールバック時に、メモリの再構築に依存せずに、古いイメージとベースラインを保持します。

これらのことは些細なことのように思えるかもしれませんが、モデルへのアクセスが制限され始めると、本当に価値があるのはこの些細な層です。これらがなければ、チームは「今回は大丈夫そうだ」と次のアップグレードに賭けることしかできません。彼らを使用すると、問題がモデル、推論スタック、またはデータセット自体にあるのかどうかを少なくとも確認できます。

したがって、この問題が最終的にプロジェクトに委ねられると、判断は非常に簡単になります。モデルを取得できるかどうかは単なる始まりにすぎません。同じ入力のセット、同じパラメータのセット、同じサンプルのセットを同じライン上で継続的に実行できるかどうかで、安定して使用できるかどうかが決まります。比較可能な口径が残っている限り、モデルにはまだ操作の余地があります。口径が最初に発散すると、その後の交換、ロールバック、トラブルシューティングのコストが高くなります。