Cloudflare 推論最佳化令審查成本降低 68%，品質結果卻不平均
Cloudflare 表示，在每次審查的支出約增加一倍後，該公司透過最佳化將其 AI 程式碼審查工具的推論成本降低了 68%。推論是指已訓練模型在處理請求時所進行的運算。Cloudflare 於 10 月 19 日發表的推論最佳化報告，描述了成本更低、完成速度更快的審查，但品質結果並不一致。
根據該公司的推論最佳化分析，審查時間中位數由 4 分 9 秒降至 1 分 32 秒。約 40% 的節省來自程式碼改動，其餘則來自模型及推論力度的改動。這些數據由公司自行報告，並非經獨立驗證的量度結果。
核心的取捨在於減少不必要的運算，同時保留有價值的審視。Anthropic 的代理指引及 Google 的快取做法提供了背景參考，但兩者均未獨立驗證 Cloudflare 的成果。對工程主管而言，關鍵問題是：成本較低的審查，是否仍能發現值得關注的問題。
Cloudflare 推論最佳化改變了分析單位
有用的比較單位，是具備可接受覆蓋範圍的已完成審查，而非單一孤立的模型請求。
這個區別改變了讀者應如何理解推論帳單。模型請求是附加於中間操作的開支；審查則是開發人員實際使用的產品成果。
一個系統可以令個別請求更便宜，卻增加完成工作所需的請求數量。它亦可能產生較短的答案，卻令開發人員需要進行更多調查。兩種結果都未必改善整個工作流程的經濟效益。
以帳戶權限變更的示例審查為例。可見的輸出可能只是有關存取檢查的簡短警告。要產生該警告，系統可能需要閱讀程式碼、檢查周邊行為、比對專案規則，以及評估問題是否值得升級處理。
這些活動有不同目的。有些用於建立必要證據，另一些則用於協調流程。若將其合併成本視為沒有區分的模型開支，便難以分辨有成效的調查與行政上的重複工作。
這正是會計邊界重要的原因。審查產品的存在，是為了協助某人判斷在變更推進前，哪些事項需要留意。其經濟價值部分取決於它從那個人的日常工作中移除了多少工作。
一個需要大量核實的廉價答案，可能只是把開支轉移給開發人員。一個可防止嚴重缺陷的昂貴答案，則可能足以合理化其運算需求。單看帳單無法區分這些結果。
比較模型供應商時，同樣的推理也適用。公開的輸入價格只描述其中一項開支。它無法揭示模型會否經常要求額外證據、重複某項操作，或無法完成工作。
同樣地，更快的回應不代表更快完成。開發人員在意的是收到有用的結論、理解結論，以及決定需要作出甚麼變更。等待最初幾個字只是整個體驗的一部分。
因此，Cloudflare 所報告的低開支與較短審查時間組合，對採購以外的範疇亦有意義。它把焦點引向完整應用程式的行為，正是工程選擇與模型行為交會之處。
這亦帶來報道層面的含意。任何節省聲稱，只要分母保持明確，便更容易評估。按每項提交變更、每次完成審查及每項獲接納發現計算的開支，回答的是不同問題。
評估此案例的團隊應避免把標題數字轉化為普遍目標。它較持久的貢獻其實是一個會計問題：審查中哪些部分產生有用證據，哪些只是讓機制繼續運作？
這個問題直接引向架構壓力。一旦 AI 功能成為日常工具，周邊應用程式便需要與模型本身同樣嚴格的審視。
工程主管必須計算答案之間的工作
若應用程式反覆要求模型執行不必要的工作，模型的能力無法在經濟層面作出補償。
AI 代理是使用模型來選擇操作、以完成任務的軟件。其周邊控制迴圈決定可使用哪些工具、接收哪些資訊，以及何時結束執行。
在模型選擇進入討論前，這些決定已塑造了工作量。工具描述可能引導一項毫無用途的操作。缺乏背景資料可能需要再次請求。不清楚的停止條件可能延長已完成的任務。
這些都是具有直接財務後果的應用程式設計問題。即使模型由外部供應商提供，責任仍屬於建立該功能的團隊。
壓力尤其落在同時批准產品行為及基建開支的工程主管身上。採購決定無法解決低效的操作序列。提示調整亦無法判定該序列是否必要。
Anthropic 的歷史代理工作流程指引建議由簡單方案開始，並在有理據時才增加複雜度。它亦描述了路由，即把不同輸入導向專門的流程、提示、工具或模型。
這項指引為架構熱情提供了有用的制衡。將任務分配給專家可以改善聚焦程度，但每一次劃分都會引入協調成本。由此產生的系統需要證據，證明專門化所帶來的價值足以抵銷額外工作。
對程式碼審查工具而言，專門化具有直觀吸引力。安全性、效能及可維護性涉及不同問題。然而，經濟理據取決於分開調查是否產生不同價值。
一項示例安全審查可能需要追蹤不受信任的輸入如何到達敏感操作；格式檢查則可能只需進行狹窄範圍的檢視。讓兩項任務擁有相同的調查自由度，便會忽略它們對證據的不同需求。
相反的錯誤亦同樣可能發生。過於僵化而狹窄的流程，可能阻止安全審查者檢視周邊程式碼。屆時較低開支反映的，將是對有用工作的限制。
這令產品團隊肩負一項不能完全交由模型承擔的設計責任。他們必須定義每項任務需要甚麼證據，以及何謂完成。這些定義為評估效率提供基礎。
比較商業審查產品與內部系統時，買家亦面對相關問題。託管產品可以隱藏操作複雜性，但使用者仍需理解覆蓋範圍、失敗行為及審查限制。
內部系統提供更多控制，但擁有權亦帶來持續維護負擔。隨着應用程式改變，必須有人讓任務定義、評估範例及模型配置保持一致。
這使文件紀錄成為成本控制的一部分。團隊需要共同記錄，說明為何審查工具會接收某些證據，以及何時需要進行更深入的調查。一個可搜尋的知識庫可協助在工程交接之間保留這些決定。
更廣泛的含意在於組織，而非宣傳。推論開支涵蓋應用程式設計、評估及採購。若只將其歸於基建財務，便會把重要原因排除於討論之外。
提示快取獎勵一致性，但重複工作仍然重要
重用運算與消除不必要運算解決的是不同問題，因此健康的快取指標無法證明整體效率。
提示快取會重用先前已計算、且輸入內容相符的處理結果。前綴是請求的開頭部分，共用指令及其他穩定材料可以放在那裏。
Anthropic 的提示快取文件描述了自動快取及明確斷點。文件說明可圍繞相符前綴重用，而快取行為會受請求結構及支援的保留設定影響。
對應用程式而言，重要的分別在於語意相似與可重用輸入之間。指令對人而言可以意思相同，實際表述卻可能不同。圍繞精確比對設計的系統，需要在該表述層面保持一致。
一個示例文件助理可能會同時包含穩定的政策指令及會變動的專案識別碼。兩者都屬於請求的一部分，但重用特性不同。其放置位置會影響多少共用材料仍可供重用。
這令應用程式格式與基建開支之間形成不尋常的關係。請求建構不再只是外觀層面的考慮，而成為執行策略的一部分。
不過，重用並不會令重複操作本身變得有價值。若應用程式發出不必要的請求，快取可以降低其處理負擔，卻無法為該請求創造存在理由。
一個有用的比喻是經常查閱的參考文件。把它放在手邊可協助審查者有效率地查閱，但若沒有需要作出的決定，要求審查者反覆重讀仍會消耗注意力。
這個區別亦解釋了為何百分比需要背景。比例描述工作量中各類別之間的關係，卻無法證明工作量本身是否規模適當。
對產品團隊而言，這意味着營運報告除了比率外，還需要絕對活動量。所完成的工作量本身重要，與該工作被如何有利地分類無關。看似良好的重用指標，可以與不必要地複雜的流程並存。
Google 的情境快取方法提供了比較。Vertex AI 支援隱性重用及明確快取內容，兩者有不同的控制方式及儲存考慮。
Google 的文件將重複文件、程式碼及企業知識列為相關工作負載。這表明快取是跨供應商共有的基建議題，卻不代表其行為相同或經濟效益可以互換。
這在機構評估可攜性時尤其重要。應用程式可以在供應商之間搬移指令，卻保留不再適用的假設。在遷移過程中，重用行為值得獨立檢視。
因此，實際的競爭問題不僅是誰提供快取。買家需要了解其實際應用程式如何與供應商的機制互動。單有可用性並不能證明有效使用。
就這個故事而言，Cloudflare 提示快取應置於這個更大的區別之中。重用有助提升效率，而任務設計決定首先應進行多少工作。
兩種機制都不能取代評估。一個結構一致的請求，仍可能問錯問題、包含不足證據，或產生不可靠的結論。
模型路由令審查品質成為資源分配決策
模型路由的經濟理據，取決於識別哪些任務可接受較少運算，哪些則需要更深入的調查。
模型路由會按任務要求，將請求分派至不同模型或處理配置。它將模型選擇由一次性的採購決定，轉化為一項營運政策。
該政策需要界定何謂難度。請求長度可反映輸入規模，但未必能反映調查複雜度。一項簡短的授權規則修改，可能比冗長的機械式更新更值得仔細審查。
同樣地，一項看似熟悉的請求，也可能隱藏陌生的失效模式。倚賴表面訊號的路由器，可能會反覆為風險仍然隱蔽的任務選擇較經濟的路徑。
由 Isaac Ong 及合作者主導的 RouteLLM 研究，探討如何在較強與較弱模型之間進行學習式選擇。作者報告指出，在保留所量度回應品質的同時，於所評估的基準測試中降低了成本。
該論文為分配模型能力提供研究背景。它並未驗證 Cloudflare 的審查工具、其配置，或其發現的品質。基準測試結果與生產環境中的審查成果，仍屬不同證據。
這種區分很重要，因為對話偏好與缺陷偵測是不同目標。一個回應可以讀來流暢，卻忽略某項相依關係。一則警告可以聽來審慎，卻未能指出任何可採取行動的問題。
就程式碼審查而言，相關的分配決定不僅涉及生成答案，亦涉及蒐集證據。審查工具有時必須檢視周邊行為，才能判斷表面上的問題是否真實存在。
限制這類調查，可能產生看似乾淨的輸出。回應變短，是因為系統做了較少工作，但讀者無法看見被省略的查核。
反過來說，容許廣泛調查並不保證有價值。模型可能探索無關檔案、重複先前推理，或提出推測性的疑慮。更多活動需要有助於改善決策的理據。
理解 Cloudflare 模型路由的最佳方式，是將它放在這個資源分配問題之中。整體目標是將昂貴的調查保留給可提升審查實用性的地方。具體分配則必須依循工作負載的證據。
這使升級處理行為變得重要。較經濟的路徑需要有方法識別值得進一步檢查的不確定性。否則，這種架構便假設簡單與困難的任務總能在工作開始前分開。
這亦帶來產品層面的含意。會暗中改變審查程度的系統，可能令用戶誤以為覆蓋範圍一致。審查期望應反映系統實際檢查的內容。
工程團隊亦需要區分模型能力與其周邊配置。相同模型在獲得不同工具、證據、指示或運算額度時，行為可以不同。
若供應商比較同時改變所有這些條件，便無法分離改善的來源。它仍可識別有用的生產環境配置，但結論應保持恰當的範圍。
模型供應商面對的策略壓力正源於這項區分。評估完整任務的買家，會關注整個執行過程中的有效行為。每 token 的優惠費率只是該價值主張的一部分。
品質證據限制節省主張的含義
只有當最終審查仍符合其預定用途時，較低支出才足以支持效率主張。
Cloudflare 的品質發現將這項限定具體化。該公司表示，高投入程度下的程式碼品質仍保留大致相若的有用發現；中等投入程度的表現則遺漏了重要發現。安全性方面仍未明朗。
Cloudflare 亦承認，其整體節省的歸因並非受控實驗。其品質評估採用了開發人員編輯及模型評審，樣本群組較小，觀察期亦僅限於近期的一段短時間。
這些限制界定邊界，而非構成否定這項工作的理由。生產環境量度可揭示有價值的營運轉變，卻未必能回答每一個因果問題。錯誤在於把標題數字當作覆蓋範圍不變的證明。
開發人員行為是有用證據，因為它將警告與其後行動連結起來。然而，行動本身不能證實正確性。開發人員可能出於防衛性而修改程式碼、誤解警告，或作出無關的編輯。
相反的問題同樣重要。一則正確警告可能不會立即引發修改，因為問題早已被理解，或已安排稍後處理。沉默不一定表示該發現沒有價值。
自動化判斷提供另一個角度，但同樣需要審視。模型評審是用模型評估另一個系統輸出的做法。評審模型之間的一致性，是關於它們評估的證據，並非對每項底層缺陷的直接觀察。
最難量度的是遺漏的發現。檢視已發布的警告可以揭示誤報與被誇大的嚴重程度，但單憑這點，無法找出審查工具未曾提及的每一個問題。
因此，較安靜的系統帶來詮釋難題。它可能變得更具選擇性、更準確，或更不徹底。沒有額外證據，輸出數量無法區分這些解釋。
一個示例性的效能退化說明了覆蓋範圍的重要性。一項修改可以在局部看來合理，卻令經常執行的路徑成本更高。偵測這個問題可能需要編輯行以外的脈絡。
避免不必要探索的審查工具應獲肯定。在檢查相關行為前便停止的審查工具，則不應獲得同等評價。兩者在執行日誌中都可能顯得經濟。
因此，Cloudflare 推理最佳化應被視為依賴配置的結果。恰當的結論只適用於特定設定下的特定任務。它並未建立一條普遍規則，證明減少運算可保留品質。
這也改變團隊如何在內部討論節省。財務部門可能想要一個單一的減幅數字，工程團隊則需要結果分布。要結合這兩種觀點，便需要保留較經濟配置表現不佳的案例。
可信的評估應使這些失敗變得可見。否則，平均改善可能掩蓋最重要審查中的集中弱點。
業務風險在於工作或風險被轉移。開發人員可能要花更多時間核實不確定輸出，或缺陷可能獲得較少審查。兩種結果都應納入經濟討論。
觀察覆蓋範圍、持久性與有用發現的成本
下一步證據應顯示，在有用審查覆蓋範圍維持下，節省能否在一般工作負載中持續。
第一個訊號是就較高投入程度的效能及安全審查發布後續報告；Cloudflare 指出這些測試尚未完成。更強的有用發現將釐清額外運算在哪些地方值得付出成本。
這個結果將加強選擇性分配的理據。它會顯示，該架構可以在維持廣泛效率的同時，為脆弱的審查類別投入更多資源。持續的損失則會收窄所聲稱的效益。
相關發布需要將發現與其重要性及支持證據連結起來。單純增加警告數量，仍無法回答核心問題。更多輸出可能代表額外覆蓋範圍，也可能代表額外雜訊。
第二個訊號是以可比較的工作負載類別，進行更長時間的生產環境觀察。一個具持久性的結果，應能經受儲存庫活動、請求複雜度及提交工作組合的變化。
這並不要求生產環境條件完全靜止不變，而是需要足夠脈絡去理解系統以外還有甚麼改變。讀者應能區分配置效果與較簡單的輸入工作。
重複報告將提升對營運結果的信心。在不同工作負載下出現逆轉，將顯示配置需要調整的地方。兩種結果都比無限延伸原有標題更具資訊價值。
第三個訊號是獨立報告，將支出與有用的審查成果一同量度。由另一個機構重現結果，可測試底層方法能否延伸至 Cloudflare 應用程式及工程環境以外。
就 Cloudflare 模型路由而言，這代表以明確品質準則檢查完整任務。就 Cloudflare prompt caching 而言，則代表一併報告實際重用情況與工作負載行為。兩者均不應透過有利的孤立指標來評估。
獨立結果亦可釐清實施負擔。擁有專門基礎設施及評估資源的機構，能維持其他團隊難以維持的做法。營運投入應與推理支出並列考慮。
這些訊號不需要推測性的推出日期或承諾中的業界反應。它們是讀者可在後續工程報告中尋找的具體證據形式。若缺乏這些證據，目前結論便仍受限於現有案例研究。
對工程買家而言，眼前價值在於一組更精確的問題。審查工具會檢查甚麼？哪些配置會獲得更深入的調查？如何偵測遺漏的問題，又由誰維護評估？
這些問題同樣適用於其他 AI 工作流程。文件助理、研究系統或內部知識工具，都可能表面上很有效率，卻將驗證工作轉移給用戶。有用的完成結果仍然是有意義的商業成果。
在將 Cloudflare 推理最佳化用作預算目標前，應將這項主張與應用程式的實際目的比較。要求提供有關完成任務、相關失敗及人手跟進的證據。記錄哪些改變消除了重複工作，哪些限制了調查。保留額外審查改變決策的例子，因為這些案例揭示節省何時變得昂貴。在理解其覆蓋範圍前，應將較安靜的審查工具視為量度問題。然後評估完整工作流程，包括依賴它的人員。現在值得採取的行動，是讓這些結果可見：你的團隊能否證明，成本較低的 AI 審查仍能找出開發人員需要修正的問題？
