Cloudflare 如何將 AI 程式碼審查的推理成本降低 68%

亦刊載於 Iqraa.tech — 提供 Claude Code、AI Agent、雲端及系統設計的實作教學。

摘要

Cloudflare 將 AI 程式碼審查的推理成本由每次審查 $2.43 降至 $0.77，做法是移動一個提示詞快取斷點、刪除不必要的模型呼叫，並只在品質維持的情況下逐步降低模型等級及推理力度。

• 單是修正快取，就令首次請求的快取命中率由 14% 至 26% 提升至 91% 至 99.5%。
• 節省的 $1.67 中，約 40% 來自程式碼修改；60% 來自模型及推理力度的選擇。
• 審查時間中位數由 4 分鐘 9 秒降至 1 分鐘 32 秒，而每 1,000 次審查中獲採取行動的發現數目則由 229 升至 321。
• 品質測試框架發現唯一一個漏掉實際問題的審查器，讓削減推理成本得以安全進行。

Cloudflare 會讓每個合併請求經由一個由六個專門的 Claude Agent 組成的 AI 程式碼審查系統處理；到 2026 年 8 月下旬，該流程每次審查的費用已達 $2.46。團隊在 9 月從四個方向着手降低推理成本，以 $0.77 完成同一項工作，減幅達 68%；Ryan Skidmore 於 10 月 19 日在 Cloudflare blog 記錄了這套做法。任何按 token 支付 API 費用的團隊都可以借鑑這套做法。

一個 AI 審查器的單位經濟效益

審查器的計算單位是每個合併請求。2026 年 4 月，每次審查的平均成本為 $1.19。到 8 月底，同一流程的費用已達 $2.46；成本最高的兩週期間，平均費用為 $2.43。看不出有任何故障；費用只是一路增加。

三股因素疊加。8 月初將所有審查器改用 Anthropic 模型，令每項工作的成本由 $1.38 升至 $2.03。標準審查器改用 Claude Opus 4.7，令其每次審查的成本由 $0.25 升至 $0.88。同一時期，每次審查使用的 token 數量增至原來三倍以上，由 4 月的 0.91 million 增至 9 月的 2.99 million；整體快取命中率則由 85.7% 升至 97%。

推理成本增幅的大部分，來自程式碼品質審查器的 token 使用情況。優化前，它平均每次審查會呼叫模型 16.6 次、寫入 72,000 個快取 token，並讀取 1.08 million 個快取 token。單一審查器每個合併請求都要處理一百萬個 token 的上下文。

支出分佈顯示可着手優化之處。優化前，快取寫入佔支出的 43%，快取讀取佔 34%，即每 1 美元支出中有 77 美仙用於輸入端快取。大家最關注的輸出 token 只佔 23%。要認真降低推理成本，就要從快取前綴着手。

一個協調器、六個專家、一個共用前綴

每個合併請求都會交由協調器，按風險分為三個級別：全面審查、輕量審查或簡單審查。全面審查會分派給程式碼品質、安全性、效能、AGENTS.md 合規性、文件及標準等專項審查器。每個專項審查器都會作為獨立的 Agent 工作階段，呼叫 Anthropic API，並由開源 Agent OpenCode 協調。

Anthropic 的提示詞快取只會快取前綴，並按固定次序排列：工具、系統區塊，然後是訊息；每個請求最多設有四個斷點。Cloudflare 的審查器會先載入一個不依賴特定儲存庫的區塊，長度介乎 11,000 至 21,000 個 token，而且在不同儲存庫中逐個位元組完全相同。要維持內容完全一致並不容易：必須停用技能清單，並固定工具説明，因為快取命中要求內容逐個位元組完全吻合。共用前綴之後，才是審查專用內容、修補內容、已變更檔案，以及該專項審查器的指示。

上圖展示了整體架構：一個合併請求會產生多個工作階段，而每個工作階段的首次請求都會重用同一個已快取的開頭。整個系統的推理成本，關鍵就在於斷點的位置。

優化階梯：按各級節省的成本排名

Cloudflare 按時間先後嘗試了以下修正：快取、減少呼叫，然後是更換模型。若按節省的成本排名，次序便會顛倒；仿效者應以這個顛倒後的次序作考量。這些階段合計令推理成本減少 $1.67，從 $2.43 的高峯降至 $0.77。

第一級：為每個審查器選用成本最低而又能勝任的模型，可節省 $1.06

更換模型及調整推理力度帶來的節省最多。這些改動源於一個簡單的觀察：在相同或較低推理力度下，較新的模型所得的審查結果沒有可辨別的差異。協調器改為只採用一種模型與推理力度組合，令全規格工作快約 20%。中等推理力度的 Claude Opus 5.5 取代了 Opus 5，審查結果沒有可量度的差異。

10 月 3 日進行的分流測試，以每個 token 單價完全相同的 Sonnet 5.5 和 Sonnet 5 作比較：程式碼質素審查的成本降低 62%，效能審查降低 58%，安全審查降低 47%；全部節省都來自生成較少 token，而非單價較低。整個模型組合於 10 月 5 日轉用 5.5。

推理力度也需要單獨測量。程式碼質素審查平均呼叫模型 6.2 次；採用中等推理力度後，平均降至 1.7 次，而且超過一半隻需呼叫一次；高推理力度則平均為 3.4 次。不過，5.5 採用高推理力度時，檢出的嚴重及警告級別問題多 58%，每次執行的成本亦高 61%，每次審查約多花兩美分，因此程式碼質素審查改回高推理力度。

第二級：令共用前綴可供快取，可節省 $0.45

原本的提示詞配置把環境資料和日期放在第一個系統區塊內，而唯一的快取斷點則位於提示詞最末端。快取鍵涵蓋斷點之前的所有內容，因此，如果前綴一開始就包含會因儲存庫和日期而變動的位元組，就永遠無法產生共用快取命中。儘管開頭有超過 11,000 個 token 在所有儲存庫中完全相同，首次請求的快取命中率仍只有 14% 至 26%。

9 月 16 日的修正是在標記處拆分區塊，並在共用內容之後立即設置斷點。首次請求的快取命中率隨即升至 91% 至 99.5%。同一輪改動亦把標準審查器的參考資料、標準表、技能檔案和參考資料清單移入提示詞，令每次審查的模型呼叫次數由 15.9 降至 9.6，成本則由 $1.12 降至 $0.72。

審查器並沒有變得更聰明，只是不再以全價重讀自己的參考資料。這些改動合共令每次審查的推理成本由 $2.47 降至 $2.02。

Anthropic 的提示詞快取如何計價？

根據 Anthropic 的提示詞快取文件，快取費用按基本輸入 token 價格的倍數計算。本文每項修正背後的推理成本計算，都由以下倍數決定：

每次讀取快取內容時，五分鐘 TTL 都會免費刷新；計時從請求開始時啟動，因此生成所需時間也會計算在內。快取斷點只可按固定次序設於前綴：工具、系統，然後是訊息；每個請求最多設四個，而且命中快取要求此前所有位元組 100% 完全一致。5.5 系列可快取提示詞的最低長度為 512 個 token，而 Opus 4.7 的最低長度為 2,048 個 token。

套用到 Cloudflare 的提示詞，在九月修正後，快取路徑依次為：固定不變的工具定義、在其後設有斷點的共用系統區塊、儲存庫上下文和日期，最後是審核內容。幾分鐘後到達的第二位審核器，會按快取讀取費率重讀前兩個部分，而非支付完整輸入價格。

有兩項快取失效規則直接影響了 Cloudflare。任何工具定義變更都會令整個快取失效，因此工具説明必須固定不變。更改思考或 effort 設定則會令訊息部分失效，當你開始為每位審核器測試不同 effort 等級時，這一點便十分重要。因此，9 月 16 日的修正著眼於結構，而非措辭微調：它把可快取邊界移到位元組不再變動的位置。

第三級：停止為無用功付費，節省約 $0.20

9 月 21 日至 23 日期間，團隊移除了不會改變任何判定的工作。每項改動都很小，但合起來便能在每項工作中發揮作用。

取消工作這一列掩蓋了最大的一項浪費。runner 在 GitLab 上使用 Kubernetes executor，而它不會發出取消訊號，因此即使開發者按下取消，仍要為完整審核付費，直至 runner 開始輪詢狀態。

推理成本削減對速度和質素的影響

成本降低，速度也更快。審核時間中位數由 4 分 9 秒降至 1 分 32 秒，第 99 百分位則由 15 分 20 秒降至 4 分 41 秒。審核時間超過五分鐘的比例由 37.9% 暴跌至 0.7%，這改變了審核器的用途：五分鐘時，你是在等它完成；90 秒時，你會直接閲讀結果。

質素有升有跌，方向是經過量度確認，而非憑空假設。程式碼質素問題的採納率，即作者在下一次推送中修改被標記程式碼行的比例，由34%升至59%。所有審查員每1,000次審查中獲採納的發現數目，由229增至321；與此同時，程式碼質素類別的相關數目則由145降至132。嚴重程度高估的情況減少70%，每次審查中被高估嚴重程度的發現由0.46項降至0.14項。程式碼質素類別的嚴重及警告級發現減少40%，安全類別減少56%，效能類別減少71%。

令削減措施安全的評估框架

上述任何一項削減措施，都不能在毫無根據的情況下安全實施。Cloudflare 以兩種方法量度審查質素，而且兩種方法都可供其他人採用。第一種方法計算作者有否採納某項發現：如果被標記的程式碼行在下一次推送中有所修改，該發現便計作已採納。為校準標準，團隊亦抽樣檢查距離任何發現30至40行的程式碼行，結果約有15%的未被標記程式碼行仍然有所變動。這個偶然變動的基準，是可信的採納率必須超越的水平；59%遠高於這個基準。

第二種方法是使用兩家不同供應商的模型，為657項盲測樣本評分，再由第三個模型裁決平局。每項發現均獲標示為重要、輕微、重複、錯誤或無法核實，並接受嚴重程度評估，判定為恰當、過高或過低。每組樣本數介乎35至66項，而最終比較時段只有一天，因此這些變化幅度反映的是方向，而非定論。

各階段的比較亦是以每次變更前後的平日工時作比較，而非受控實驗；Cloudflare 對此直言不諱。這份坦誠也揭示了實際損失：效能審查員識別到的重要發現減少約64%，相當於每24次完整審查少識別約一項真正發現。中等工作量的程式碼質素審查員，獲採納的發現數目比高工作量時少約四分之三。安全類別則下降約25%，仍在雜訊範圍內。

不過，所有審查員的可靠性指標都朝相反方向改善。安全審查的重試率由3.5%降至0.04%，未有得出判斷便結束的審查比例則由0.79%降至0.27%。平台也持續演進：從頭重寫的 OpenCode v2 在影子模式下，98%的批准決策與 v1 相同；完整級別審查的速度則快約13%，並於10月初接替 v1。實驗清單上的下一項，是透過 pi-durable 執行階段，在 Cloudflare Durable Objects 上執行審查員。

Cloudflare 如何分辨真正發現與雜訊？

採納率的計算方法還有一項值得留意的改良。由於約15%的未被標記程式碼行仍會有所變動，審查員若標記經常變動的程式碼，便可能意外累積不少已採納的發現。將採納率與這個基準比較，而非與零比較，才能分辨真正訊號與程式碼變動造成的雜訊；所需資料只有差異內容（diff）和推送時間戳記。

盲評補上了實際採納率看不到的細節：哪些發現重複、哪些有誤，以及嚴重程度評級是否過高。按這些指標計算，每次審查的重要發現數維持在 0.28 至 0.30 之間，而每次審查中嚴重程度評級過高的發現，則由 0.46 降至 0.14。三個 Sonnet 審查器的嚴重和警告級發現數減少，合規審查器則增加；不過，每次審查中被採納的發現數上升，這反映的是評論更少但更切中要點，而非審查器變得沉默。Cloudflare 最後提出的建議也值得列入其中：確認每個工作階段的第一個請求都是由快取提供，而非使用新的輸入內容；並確認審查器在你付費購買的投入程度下，仍能找出真正的缺陷。

成本下降時，哪些審查器的表現退步？

性能審查器受影響最大：嚴重和警告級發現減少 71%，重要發現則減少約 64%，相當於每 24 次完整審查少找出一項真正的問題。安全性發現減少約 25%，但 Cloudflare 表示這個差異在統計上並不顯著。中等投入程度下的程式碼品質審查器，其被採納的發現數比高投入程度時少了約四分之三，因此該審查器的投入程度又調高了。

即使如此，改用 Sonnet 5.5 後，程式碼品質審查的成本已先降低 62%；之後調高至高投入程度，每次審查的成本才增加約兩美仙。這些差異在整體成本數字中都看不出來；只有查看各審查器的細分數據才會發現。任何要照着這套做法實行的人，都必須量度到這個層面。九月份的 token 數量勾勒出整個層級變化：快取讀取量減少 82%，快取寫入量減少 54%，輸出 token 數量減少 67%。

這些技巧適用於自行託管的 vLLM 技術堆疊嗎？

推理成本的倍數關係並不適用，因為自行託管的叢集是按 GPU 秒數而非 token 計費。不過，前綴管理的做法仍然適用。vLLM 的自動前綴快取功能透過 enable_prefix_caching=True 啟用，可在多個請求之間重用共用提示詞前綴的 KV 快取。因此，一組代理程式若以相同的 11,000-token 系統提示詞區塊開啟工作，只需支付一次預填充計算成本，而非每個工作階段各付一次。vLLM 文件列出的，正是 Cloudflare 利用的兩種模式：對同一份長文件重複查詢，以及多輪對話。

兩種架構都有相同的限制。前綴快取只會加快預填充，因此答案很長、解碼工作量大的工作負載獲益不多；請求之間沒有共用前綴，則完全沒有幫助。這最後一個條件，正是 Cloudflare 遇到的失效斷點在自行託管環境中的對應情況：輸入的位元組完全相同，計算便可重用。減少呼叫次數和取消操作的做法無須修改便能沿用，因為代理程式若把一個回合耗在無法使用的工具上，無論使用租用 GPU，還是按 token 計費的 API，都會增加推理成本。量度方法最容易沿用：檢查前綴是否重用，以及發現是否真實，在任何技術堆疊上都無須成本。

系統現在以 token 經濟效益為最佳化目標：重複的位元組一律快取，不會改變判斷的呼叫一律刪除，只有在量度所得的品質差異足以證明價格合理時，才採用更強的模型。每次審查的推理成本下降 68%，由 $2.43 降至 $0.77；審查速度加快，發現也更精確。代價是需要投入工程人力，因為建立量度框架比任何單一修正都更費工；若沒有這套框架，同樣的削減措施就會在不知不覺間令審查品質變差。