FlashProve 可驗證推論：模型身分能證明，110 tokens／秒代表什麼？（2026）

2026 年 11 月 2 日，Anthropic Frontier Red Team 與學術合作者在官網發布了 〈Progress on provable inference for large language models〉，公開 FlashProve 可驗證推論研究原型。它問的不是 AI 答得好不好，而是：你付費指定的模型，究竟能不能拿出證據，說明眼前的輸出與那一組權重相符？

這是一個值得重視的進展，但最吸睛的「每秒約 110 tokens」有特定分母；通過證明也有特定範圍。下面先拆解原文的信任問題，再對照公開文件的數字與限制，最後判斷它對模型採購、評測與治理真正增加了什麼。

一、FlashProve 可驗證推論：把模型名稱變成可核對的承諾

想像你訂了一份指定配方的餐點。外盒貼對標籤、吃起來也不錯，仍不足以確認廚房使用了哪份食譜。模型 API 的名稱也有類似問題：它是服務端回傳的身分敘述，與可檢查的運算證據是兩層資訊。

這個疑問有獨立研究背景。Gao、Liang 與 Guestrin 的 Model Equality Testing，在研究的 2024 年夏季樣本中，發現四種 Llama 模型的 31 個商業端點裡，有 11 個輸出分布與 Meta 參考權重不同。那是統計差異，可能來自量化、微調或其他服務改動，不能直接翻成 11 家業者蓄意掉包；它說明的是，光看名稱，仍有待核對的空間。

FlashProve 選擇另一條路。依 技術報告第 1 節，供應者先對權重做 commitment，可理解成具有隱藏與綁定性質的承諾；之後交付與該承諾相連的運算證明。驗證者持有輸入、輸出與承諾，檢查指定運算是否成立，毋須自己取得整份權重再跑一次大型模型。

The committed model produces these output tokens when evaluated.

中文：被承諾的模型，在執行運算時會產生這些輸出 tokens。

Anthropic，原文〈Our system: FlashProve〉

這句話的主詞是「被承諾的模型」。它不是「答案符合事實」，也不是「模型品牌已獲認證」。例如一個模型照其權重算出錯誤的歷史年份，運算關係仍可能完全正確；內容品質要另用考題與資料查核判斷。

二、承諾從哪裡來，決定了「這是哪個模型」的答案

公開程式庫的 Known limits 對這點比宣傳摘要更直接：供應者可以選擇自己要承諾的權重，一個通過結果本身並不告訴你，那組權重屬於誰、實際對應哪個模型。文件因此要求，從可信任的一方取得 commitment ID，並同樣保存與核對配置檔，而不是照單接收待查伺服器附上的身分。

假設供應者一開始就對較小模型做承諾，之後每次都忠實使用它，證明可以自洽。要把它接成「這就是我購買的版本」，仍須讓可信任的發布者或審核者，建立公開版本與 commitment 的對應。密碼學把承諾後的運算綁緊；誰替最初的對應背書，仍是制度與交付流程要回答的問題。

這也補充了 檔案指紋與產物驗收 的觀念：固定同一份材料很有用，還要知道固定的是什麼、它是否符合購買或評測的要求。對未公開權重的模型，這一層來源關係尤其值得列成採購欄位。

三、110 tokens／秒怎麼算？它不是新答案的認證速度

原文報告單張 H100 的結果；進一步核對 Performance 文件，24 個請求一批的穩態平均為 111.23 ± 0.92 tokens／秒，來自三次研究團隊的計時。條件是 Llama 4 Maverick 的第三方公開 4-bit 轉換、1,024-token 提示、單張 H100 80 GB 與 24 個主機 CPU 核心。這些是作者提供的量測，AlphaLab 本次沒有執行 GPU 重現。

These are steady prefill rates

中文：這些數字是穩態的 prefill 處理速率。

FlashProve，Performance 文件

分子計入每個請求的 1,024 個提示 tokens；這組測試並未生成新文字，每份證明陳述的是下一個 token。把 24×1,024 除以約 223 秒，便會得到約 110。它有助理解大型模型的證明工作量，但若讀成「每秒證明 110 個新回答 tokens」，就換了考題。

同一份文件列出，24 請求批次從開始到交出證明，後續批次約需 220.7 至 225.9 秒；這還沒加上對外服務流程中的驗證時間。吞吐量是許多請求分攤後的速率，單一客戶等待多久則是另一個問題。一次性承諾、啟動、排隊、證明、驗證，應分欄計算。

70–95 倍也要這樣讀：文件按每張 GPU 換算，24 請求批次的證明，相對 vLLM 處理 24 個提示約慢 71.4 倍；相對 vLLM 所測最高負載的 prefill 約慢 93.0 倍。參考 vLLM 跑的是八張 H100 上的 FP8 版本，證明端是整數化的 4-bit 路徑，且穩態比較排除了啟動與承諾成本。這不是同一套一般聊天服務「帳單只要乘幾倍」的完整成本模型。

zkML 也不是從這次才開始。Sun、Li 與 Zhang 的 zkLLM 原始研究，2024 年已針對大型語言模型的非算術運算與注意力提出零知識證明方法。不同研究的模型、證明範圍、硬體與安全設定各異；本篇因此不替跨系統數字排一張「最快」榜。

四、FlashProve 可驗證推論有兩種「通過」，要看清楚是哪一種

The proof is about an integer model under greedy decoding.

中文：這項證明針對採貪婪解碼的整數模型。

Anthropic，原文〈Limitations〉

這個限制在 What is proved 被進一步拆開。exact match 要求所檢查的輸出 token 是整數模型的最高分選擇；浮點計算、量化或抽樣生成，則可能得到不同序列。數值接近，並不自動表示每一步選到同一個字。

為了處理這類落差，文件另列 clipped-gap policy：允許輸出在設定的分數成本範圍內。這種模式顯示的 WITHIN LIMITS，證明的是「符合該政策」，語意弱於「與模型選擇完全相符」。限制若放寬、分數很接近或權重退化，允許通過的輸出也會變多。兩種通過都可能以結束碼 0 返回，因此驗證紀錄應保存實際結果文字與政策。

A pass covers only checked tokens.

中文：通過結果只涵蓋實際檢查的 tokens。

FlashProve，Known limits 文件

如果一段回答有數百個 tokens，卻只驗其中指定位置，就應把範圍寫出來；抽驗可以形成稽核策略，但不能把那一次通過擴寫成整段每一步都已驗過。對評測者而言，請求範圍、完整輸出與覆蓋位置，應由自己的流程保存與對照。

五、Lean 證明增加了什麼？定理、政策與可執行程式要逐層對齊

研究團隊把協定與安全性陳述寫進 Lean，並公開 定理與條件。這讓讀者有機會檢查數學敘述，而不是只相信作者說「安全」。不過，形式化範圍文件 明確區分：Lean 驗證器的 soundness 證明、協定的 completeness 與零知識結果，以及日常使用的 C++ 驗證器與 CUDA 證明器。後兩者以遵循協定為目標並做測試，程式本身未獲相同的形式化證明。

零知識的意義也應綁定條件：協定旨在讓證明不額外洩露私有權重，但形式化結果有隨機遮罩、配置、請求與批次範圍等前提；實際部署還要處理公開檔案與側通道。把「某個定理已機器檢查」推成「整個服務任何情境都不洩密」，會跨過這些邊界。

發布本身仍有價值。程式庫 README 把它列為研究產物、Apache 2.0 授權，並提供程式、文件與驗證路徑；模型權重則有其上游授權。公開材料讓別人能檢查與改進，卻不會單靠「開源」二字，消除實作、測試或版本對應的缺口。

六、AlphaLab 的判讀：把信任問題切小，才有可用的保證

1. 最有價值的改變，是讓「相信誰」變得更精確

我同意 FlashProve 指向的方向：客戶可以要求與承諾相連的證據，逐步減少只靠服務端自述的環節。它沒有讓信任憑空消失，而是把責任集中到可檢查的位置：初始身分對應、協定假設、驗證器與覆蓋範圍。這比籠統宣稱「可信 AI」更容易訂出驗收條件。

2. 事後證明適合稽核，但證明不能倒寫歷史

一份事後產生的證明，可以說明指定權重在指定輸入下滿足某種輸出關係；它本身未必回答，當時哪台機器先產生了那段文字、何時產生，或所有未抽到的請求都做了什麼。若要查模型替換，還應把不可任意挑選的抽樣、時間與請求紀錄接進稽核設計。這是從保證範圍推導的部署要求，並非本篇聲稱已測出某項欺騙。

3. 能證明做過推論，仍不足以包辦整體治理

原文把模型核准、內部防竄改、文字來源與 AI 發展節奏列為可能用途。這些是應用方向，不能當成部署完成的清單。例如一批合格推論的證明，即使有效，也不能單獨盤點公司所有算力的其他用途。治理者要查什麼，就得另訂與那個問題一致的證據範圍。

4. 成本高，反而迫使人先說清楚哪裡值得驗

在這個研究階段，我會優先考慮高價值評測、合約抽驗與重要版本交付等候選場景，再衡量可接受的延遲與抽樣覆蓋；這是取捨建議，不是已驗證的商業效益。若每個普通請求都要多付大量證明工作，必須先量出新增保證是否值得那些 GPU、CPU、記憶體與傳輸成本。

我同意的是，把「誰回答」變成可驗證的研究目標；我存疑的是，將單一原型的穩態數字、形式化協定與一般聊天服務的全面保證畫上等號。下一次進展最值得看的，不只是速率變大，而是同樣清楚的保證範圍，能否以更低總成本、更完整的覆蓋交付。

七、下一步：向供應者要一張能對帳的驗證單

• 身分：版本、量化設定、commitment ID 與配置檔，由誰建立可信對應？
• 範圍：輸入與輸出如何固定？覆蓋全部還是指定位置？如何避免只挑成功案例？
• 政策：驗的是 exact match，還是 clipped gap？通過結果、限制值與使用的驗證器版本是什麼？
• 成本：把啟動、承諾、排隊、證明、驗證與傳輸分開記，並量實際等待時間。
• 品質：再用自己的任務考內容是否正確、有用；來源完整性與答案品質各留一張成績單。

如果你正在建立評測流程，可接著讀 AI Evals 的驗收方法；想先理解 token、權重與模型輸出，從 大型語言模型的運作原理 和 AI 模型如何學習 開始。研究型證明要解的問題愈具體，就愈容易判斷它該放進哪一段工作。