前晚翻@OpenGradient 文檔的時候，兩組數字讓我反覆看了好幾遍。官方寫得明明白白：ZKML的開銷是普通推理的1000到10000倍。什麼概念？一個原本50毫秒的推理，用ZKML驗證可能要花50秒到8分鐘。Modulus Labs的報告也印證了這個數據——zkML比常規計算慢1000倍。
這不是工程優化能解決的問題，這是密碼學證明本身的數學代價。
更讓我在意的是模型兼容性。OpenGradient的ZKML推理依賴EZKL庫，但支持的ONNX算子集僅限於opset 9到18。2026年的主流模型用的算子版本早已超出這個範圍。想跑ZKML？先得把模型降級到幾年前的標準——這相當於讓一輛2026年的電動車去適配2018年的充電樁。大多數開發者面對這種限制，答案只會是兩個字：算了。
再說HACA架構的設計。官方文檔寫得很清楚：執行和驗證是兩條獨立的時間線。推理節點先返回結果，證明異步提交、驗證、上鍊。這中間存在一個信任窗口——惡意節點返回錯誤結果後，在證明被駁回之前完全可能逃逸。對於高頻交易、實時風控這類場景，這個延遲可能是致命的。
文檔也承認，LLM推理全部使用TEE驗證。大模型場景下，ZKML已經被默認放棄了。OpenGradient的核心賣點是“可驗證”，但開發者面對10000倍的性能代價和opset限制，最終只能選擇TEE或Vanilla——“可驗證”變成了“可選的驗證”。
#opg $OPG
這不是工程優化能解決的問題，這是密碼學證明本身的數學代價。
更讓我在意的是模型兼容性。OpenGradient的ZKML推理依賴EZKL庫，但支持的ONNX算子集僅限於opset 9到18。2026年的主流模型用的算子版本早已超出這個範圍。想跑ZKML？先得把模型降級到幾年前的標準——這相當於讓一輛2026年的電動車去適配2018年的充電樁。大多數開發者面對這種限制，答案只會是兩個字：算了。
再說HACA架構的設計。官方文檔寫得很清楚：執行和驗證是兩條獨立的時間線。推理節點先返回結果，證明異步提交、驗證、上鍊。這中間存在一個信任窗口——惡意節點返回錯誤結果後，在證明被駁回之前完全可能逃逸。對於高頻交易、實時風控這類場景，這個延遲可能是致命的。
文檔也承認，LLM推理全部使用TEE驗證。大模型場景下，ZKML已經被默認放棄了。OpenGradient的核心賣點是“可驗證”，但開發者面對10000倍的性能代價和opset限制，最終只能選擇TEE或Vanilla——“可驗證”變成了“可選的驗證”。
#opg $OPG