我注意到的第一件事，是有一個模型上傳看起來成功了，但沒有出現在註冊表裏。SDK 返回了成功信息。文件哈希也是正確的。但當我查詢可用模型時，它並不在其中。

我當時以爲這是傳播延遲。這個解釋聽起來很合理。去中心化的註冊表需要時間來更新。

這是第一次不一致。

上傳已經完成了。模型已經存儲了。但註冊步驟——把文件哈希綁定到模型 ID 的鏈上交易——還沒有被確認結算。網絡確認了存儲。只是還沒確認註冊。

存儲 ≠ 可用。

路徑看起來很直接：

上傳 → 存儲 → 註冊 → 傳播 → 可用性 → 執行

但每一步都是獨立的交易。存儲發生在 Walrus 上。註冊發生在 OpenGradient 註冊表上。模型存在於一個地方，卻在另一個地方不可被發現，直到結算最終完成。

我反覆想到的是這個隱藏依賴：元數據校驗。註冊表不僅存儲文件哈希。它還存儲血緣關係——哪個版本產生了哪些輸出。模型在對請求提供服務之前，必須先驗證這些元數據。所以一個模型可以已經被存儲、已經付費、也準備好運行，但仍然對用戶不可見，因爲註冊交易仍在等待。

我仍然不知道網絡在大規模情況下如何處理。已經部署了超過 4,400 個模型。每一個都經歷了同樣的兩步流程。也許有批處理機制。也許沒有。

我無法確定的是：存儲與註冊的分離是否會在高併發上傳時造成盲區。如果在一分鐘內上傳了 100 個模型，註冊表會按順序處理嗎？它會丟請求嗎？還是會把請求排隊？

表面的問題是缺少了某個模型。真正的問題是，存在性與可發現性是被分別結算的。

當一個模型在某個活動中被緊急需要，但它的註冊卻卡在其他 50 個上傳之後時，會發生什麼？

#opg $OPG