FlashProve 係 Anthropic 推出的開源研究原型，目標係令 AI 推論「有證可查」：服務提供者先承諾使用某一組模型權重，再為回應產生密碼學證明，讓用戶核對指定字詞是否符合該模型權重下的約定規則，而毋須取得模型權重。 1029

不過，呢個證明有明確範圍：佢證明的是指定字詞層面的主張，唔係證明模型安全、服務部署每個環節都誠實，亦唔係證明所有隨機抽樣輸出都按聲稱方式產生。 1029

可以查到模型身份，但唔等於安全認證

如果服務聲稱使用某個模型，FlashProve 可以讓用戶按指定的權重承諾核對回應，而唔只係相信服務顯示的模型名稱。若回應無法通過預期承諾的驗證，便可以拒收；這或有助揭穿模型偷換，亦可能令部分聊天劫持更難得逞。Anthropic 亦提到，安全評估者可用類似方法核對測試時與正式提供服務時用的是不是同一模型。 1040

但用戶仍要知道應該信任哪一個承諾。證明只會核對用戶提供的承諾及公開檔案，唔會自行證明該承諾確實屬於服務聲稱的模型。即使模型身份無誤，模型仍可能答錯或產生有害內容；驗證身份唔等於安全認證。 3032

運作方式：先承諾權重，再逐次證明回應

一、離線承諾。 提供者用 FlashProve 的 committer 處理模型權重，發布承諾資料。承諾包含一個 32-byte 指紋，稱為 commitment ID，用來將證明綁定到特定一組權重；權重本身毋須公開。 3039

二、逐次產生證明。 每次回應，提供者都可為經檢查的字詞產生證明，確認它們符合已承諾權重下的驗收規則。預設的 exact-match（完全吻合） 規則，要求每個受檢字詞都係模型當下會選出的 greedy 選項。另一種 clipped-gap 規則，檢查字詞分數是否符合指定的分差條件；這同「證明字詞係按指定隨機分佈誠實抽樣」係兩回事。 2032

三、用戶端驗證。 用戶端以 CPU 核對證明，所需資料包括預期的 commitment ID、相關公開承諾檔案，以及要檢查的請求、字詞主張和驗收規則。驗證毋須取得私有模型權重，亦唔需要 GPU。 293034

呢種設計對封閉模型提供者可能有用：提供者可以讓客戶核對特定推論主張，同時保留模型參數。但這只係可能的應用，唔代表已有商業服務部署 FlashProve。 1629

Llama 4 Maverick 測試數據，應該點理解？

FlashProve 曾以 Meta 的 Llama 4 Maverick 作示範。呢個係約 4,000 億參數的混合專家模型（mixture-of-experts，MoE）。留意，公布的速度係一批請求的總吞吐量，唔係單一用戶聊天時每秒可收到的字數。 37

• 證明吞吐量： 一張 Nvidia H100 約每秒處理 110 個 token；測試批次有 24 個請求，每個使用 1,024-token 視窗，整批約需 223 秒。 17
• 證明大小： 每個 1,024-token 請求約 18.78 MB，通常約寫成 19 MB。 17
• 驗證時間： 公布測試中，以 24 條 CPU 執行緒約需 17 秒；單執行緒約需 21 秒。 119
• 一次性承諾： 公布的離線承諾階段約需 39 分鐘，發布的承諾資料約 6.5 MB。 713

專案亦提供 Lean 驗證器及機器檢查的可靠性結果，但保證範圍要分清楚：文件描述的 Lean 可靠性主張，針對指定假設下的 Lean 驗證器及 exact-match 主張；clipped-gap 支持的是較窄的主張。不能因此推論所有實作、部署方式或解碼模式都受到同一保證。 3233

限制：證明成本高、視窗短，抽樣保證亦有限

產生證明耗用大量 GPU 資源。 公布的測試估算，證明所需 GPU 時間約為一般 vLLM 推論的 70 至 95 倍。對一個希望為回應附上證據的系統而言，呢個成本相當可觀。 18

示範只涵蓋 1,024 個 token。 專案列出的全尺寸示範使用 1,024-token context window，未能由此證明系統支援更長上下文。 23

批次吞吐量唔等於即時體驗。 約每秒 110 個 token 係 24 個請求合計的速度，而整批處理約需 223 秒；實際服務若要等候湊齊一批請求，等候時間亦可能增加用戶延遲。 1

解碼規則有其邊界。 Exact-match 核對的是 greedy 選擇；clipped-gap 並唔證明字詞係按某個指定隨機抽樣分佈誠實抽出。兩種規則都唔會證明答案安全、真確或有用。 2032

開發團隊、授權與現時狀態

FlashProve 由 Anthropic 的 Frontier Red Team 與 EPFL、MIT 及 StarkWare 的合作研究者共同開發。列出的作者包括 Anthropic 研究員 Roy Rinberg、Alex Allain，以及密碼學研究者 Alessandro Chiesa 等人。 1031

程式碼以 Apache 2.0 授權發布；但 GitHub 專案同時標明，FlashProve 係「不再維護、亦不接受貢獻」的研究成果。因此，開源授權唔代表專案仍會維護，亦唔代表團隊正招募外部程式碼貢獻。 213135

報道指 Anthropic 暫無計劃在公司內或其他地方部署 FlashProve。連同專案的維護聲明來看，現階段較適合將佢理解為探索可驗證 AI 推論的研究原型，而唔係已完成的產品或有支援的生產服務。 1535

FlashProve 係 Anthropic 推出的開源研究原型，目標係令 AI 推論「有證可查」：服務提供者先承諾使用某一組模型權重，再為回應產生密碼學證明，讓用戶核對指定字詞是否符合該模型權重下的約定規則，而毋須取得模型權重。 1029

不過，呢個證明有明確範圍：佢證明的是指定字詞層面的主張，唔係證明模型安全、服務部署每個環節都誠實，亦唔係證明所有隨機抽樣輸出都按聲稱方式產生。 1029

可以查到模型身份，但唔等於安全認證

如果服務聲稱使用某個模型，FlashProve 可以讓用戶按指定的權重承諾核對回應，而唔只係相信服務顯示的模型名稱。若回應無法通過預期承諾的驗證，便可以拒收；這或有助揭穿模型偷換，亦可能令部分聊天劫持更難得逞。Anthropic 亦提到，安全評估者可用類似方法核對測試時與正式提供服務時用的是不是同一模型。 1040

但用戶仍要知道應該信任哪一個承諾。證明只會核對用戶提供的承諾及公開檔案，唔會自行證明該承諾確實屬於服務聲稱的模型。即使模型身份無誤，模型仍可能答錯或產生有害內容；驗證身份唔等於安全認證。 3032

運作方式：先承諾權重，再逐次證明回應

一、離線承諾。 提供者用 FlashProve 的 committer 處理模型權重，發布承諾資料。承諾包含一個 32-byte 指紋，稱為 commitment ID，用來將證明綁定到特定一組權重；權重本身毋須公開。 3039

二、逐次產生證明。 每次回應，提供者都可為經檢查的字詞產生證明，確認它們符合已承諾權重下的驗收規則。預設的 exact-match（完全吻合） 規則，要求每個受檢字詞都係模型當下會選出的 greedy 選項。另一種 clipped-gap 規則，檢查字詞分數是否符合指定的分差條件；這同「證明字詞係按指定隨機分佈誠實抽樣」係兩回事。 2032

三、用戶端驗證。 用戶端以 CPU 核對證明，所需資料包括預期的 commitment ID、相關公開承諾檔案，以及要檢查的請求、字詞主張和驗收規則。驗證毋須取得私有模型權重，亦唔需要 GPU。 293034

呢種設計對封閉模型提供者可能有用：提供者可以讓客戶核對特定推論主張，同時保留模型參數。但這只係可能的應用，唔代表已有商業服務部署 FlashProve。 1629

Llama 4 Maverick 測試數據，應該點理解？

FlashProve 曾以 Meta 的 Llama 4 Maverick 作示範。呢個係約 4,000 億參數的混合專家模型（mixture-of-experts，MoE）。留意，公布的速度係一批請求的總吞吐量，唔係單一用戶聊天時每秒可收到的字數。 37

• 證明吞吐量： 一張 Nvidia H100 約每秒處理 110 個 token；測試批次有 24 個請求，每個使用 1,024-token 視窗，整批約需 223 秒。 17
• 證明大小： 每個 1,024-token 請求約 18.78 MB，通常約寫成 19 MB。 17
• 驗證時間： 公布測試中，以 24 條 CPU 執行緒約需 17 秒；單執行緒約需 21 秒。 119
• 一次性承諾： 公布的離線承諾階段約需 39 分鐘，發布的承諾資料約 6.5 MB。 713

專案亦提供 Lean 驗證器及機器檢查的可靠性結果，但保證範圍要分清楚：文件描述的 Lean 可靠性主張，針對指定假設下的 Lean 驗證器及 exact-match 主張；clipped-gap 支持的是較窄的主張。不能因此推論所有實作、部署方式或解碼模式都受到同一保證。 3233

限制：證明成本高、視窗短，抽樣保證亦有限

產生證明耗用大量 GPU 資源。 公布的測試估算，證明所需 GPU 時間約為一般 vLLM 推論的 70 至 95 倍。對一個希望為回應附上證據的系統而言，呢個成本相當可觀。 18

示範只涵蓋 1,024 個 token。 專案列出的全尺寸示範使用 1,024-token context window，未能由此證明系統支援更長上下文。 23

批次吞吐量唔等於即時體驗。 約每秒 110 個 token 係 24 個請求合計的速度，而整批處理約需 223 秒；實際服務若要等候湊齊一批請求，等候時間亦可能增加用戶延遲。 1

解碼規則有其邊界。 Exact-match 核對的是 greedy 選擇；clipped-gap 並唔證明字詞係按某個指定隨機抽樣分佈誠實抽出。兩種規則都唔會證明答案安全、真確或有用。 2032

開發團隊、授權與現時狀態

FlashProve 由 Anthropic 的 Frontier Red Team 與 EPFL、MIT 及 StarkWare 的合作研究者共同開發。列出的作者包括 Anthropic 研究員 Roy Rinberg、Alex Allain，以及密碼學研究者 Alessandro Chiesa 等人。 1031

程式碼以 Apache 2.0 授權發布；但 GitHub 專案同時標明，FlashProve 係「不再維護、亦不接受貢獻」的研究成果。因此，開源授權唔代表專案仍會維護，亦唔代表團隊正招募外部程式碼貢獻。 213135

報道指 Anthropic 暫無計劃在公司內或其他地方部署 FlashProve。連同專案的維護聲明來看，現階段較適合將佢理解為探索可驗證 AI 推論的研究原型，而唔係已完成的產品或有支援的生產服務。 1535