CPU 基準測試將代理工具執行與模型推理分開
Tom's Hardware 概述了其首個針對代理式 AI 的 CPU 基準測試，在發布經驗證的處理器排名前，先將主機工作負載與模型推理分開。Tom's Hardware CPU benchmark 聚焦於一個特定問題：當 AI 代理爭用本機資源時，處理器能處理多少工作？其方法清楚區分了衡量硬件容量與預測實際用戶等候時間。
AI 代理是利用模型選擇行動、執行工具並評估結果的軟件。這些行動會產生文字生成以外的工作。處理器可能在模型決定下一步時執行測試、搜尋文件或協調工作。
核心張力在於受控測量與真實執行之間。MLCommons 已在其個人電腦基準測試 MLPerf Client 中納入代理工作負載，測量涵蓋模型執行與工具。隔離主機可提供另一種視角，但買家在將代理基準測試視為採購依據前，仍需要兩方面的觀點。
Tom's Hardware CPU Benchmark 實際引入了甚麼
在 10 月 29 日的專題中，分析師 Jake Roach 描述了一個原型：它記錄模型互動，並在工具於本機執行時重播回應。該刊物表示設計已經確立，但結果仍有待審視。因此，其 agentic CPU benchmark 引入的是一種測試方法，而非已定論的處理器排行榜。
真正重要的改變，是在檢視電腦執行周邊工作時，讓模型行為維持不變的方法。
推理，即產生模型回應的運算，會為硬件測試帶來另一個變數。即使其他運行條件相近，代理亦可能選擇不同的行動。若其決策與執行速度同時改變，便更難辨識成因。
記錄的回應為工作負載提供固定路徑。在這種安排下，較短的完成時間可對照更一致的行動序列來解讀。這讓實驗更易於檢視，但也收窄了結果所代表的範圍。
試想一項示例編程任務：代理搜尋專案、開啟原始碼檔案、套用修改並執行測試。即時模型在下一次嘗試時，可能選擇另一種搜尋方式或要求再做一次測試。比較這些嘗試，便會把硬件差異與實際工作內容的差異混在一起。
受控序列可減少這種含糊之處。實驗可探究不同系統如何高效執行可比較的工作，而非代理是否剛好選擇了同樣高效的方法。只要目標是比較硬件，這項分別便很重要。
這亦為標題主張設下限制。移除即時決策，意味測量無法證明模型在某款處理器上推理得更好。較短的重播時間也不代表正式環境中的代理必然更快完成工作。
這則消息值得注意，因為它明確界定了測量邊界。代理效能並非完全屬於模型、處理器或應用程式其中一方的單一特質。每一層均有貢獻，亦各自需要切合其角色的證據。
因此，較有用的解讀應保持狹窄而具體。此原型探索的是受控代理工作負載下的主機容量。這種容量能否預示更佳的應用程式效能，仍是另一個問題，需要與即時執行作比較。
無論結果最終在哪裡發布，這條界線都應保持清晰。否則，一項審慎限定的實驗可能被演變成過於廣泛的營銷主張。
硬件買家需要的不只是更快的模型
當前壓力主要落在硬件供應商和買家身上，他們需要把 AI 效能主張與特定工作負載連結起來。
電腦回答問題時所做的工作，並不等同於執行軟件修復時的工作。後者可能涉及本機程式、檔案及驗證。若只評估模型，這些依賴因素便會被排除於測量之外。
對開發者而言，實際問題在於工作於何處執行。遙距託管的模型仍可指示本機電腦完成工作。若測試在本機執行，改善遙距服務未必會自動縮短測試階段。
反過來也同樣重要。若本機工作只佔任務時間很小的部分，購買較快的處理器可能幾乎不會改變使用體驗。有用的基準測試必須揭示這種可能性，而非假定每個代理工作流程都需要更高的主機效能。
這為處理器供應商帶來不同的舉證責任。關於適合代理的籠統主張，應說明哪些工作得到改善、在甚麼條件下改善，以及為應用程式帶來甚麼效益。單靠容量測量無法回答所有部分。
電腦製造商亦面對相關問題。他們必須為目標用戶決定應配置多少處理器效能、記憶體及其他資源。當基準測試能協助區分這些需求，而非為相同配置再貼上一個標籤時，它才有價值。
對企業買家而言，並行工作增添了另一個維度。並行是指多項任務在重疊時段內保持活躍。一個系統單獨處理任務時綽綽有餘，但當同事或背景工作爭用資源時，表現可能截然不同。
吞吐量，即每個時間單位完成的工作量，反映了這種差異的一部分。延遲，即單項任務所需時間，則反映另一部分。一部電腦可提供更多總工作量，同時卻令個別用戶等候更久。
以一部共用開發主機為例，便能清楚說明這項分別。數個代理可能分別執行測試套件，同時開發者要求互動式搜尋。最大化已完成的測試數量，未必能維持搜尋操作的即時回應。
這正是代理式 AI 吞吐量需要訂明服務要求的原因。若沒有可接受等候時間的定義，最高完成率可能反而獎勵一個令用戶感到超負荷的配置。
知識工作流程也會提出類似問題，即時間實際花在哪裡。建立 可搜尋知識庫 的團隊，應先區分文件處理、檢索及答案生成，才把延遲歸因於硬件。
這些例子描述的是採購問題，而非該原型的實測發現。它們的價值在於顯示未來結果必須解釋甚麼。買家需要能把受控分數與其實際工作連結起來的證據。
因此，當前重點不在於立即宣布哪款處理器勝出，而在於要求更清楚交代代理效能主張究竟承諾了甚麼。
移除推理令主機更容易測量
原型的並行掃描會增加活躍工作者數目，並報告已完成工作階段。它區分峰值吞吐量與受較慢工作階段限制的運作點。在凍結重播期間，已記錄的模型回應不受 GPU 推理延遲影響，讓主機在沒有該等節奏限制下處理工作。
移除推理能改善隔離效果，但也會改變工作抵達處理器的方式。
這項取捨直接源於設計。當模型花時間產生回應，主機可能有機會完成其他工作。立即返回回應，便會改變下一項行動準備就緒的時間。
所得工作負載可揭示較慢的即時模型永遠不會提出的容量需求。這不代表測量沒有意義，而是代表它測量的是在特定工作供應下的效能。
這好比測試一個廚房時，先把員工要處理的訂單預備好。這項演練可顯示廚房能製作多少食物，卻無法獨立證明在點餐及送餐帶來額外延遲時，食客會多快收到餐點。
對代理軟件而言，缺少這種節奏控制很重要，因為行動依賴先前的結果。測試必須先完成，其輸出才能為下一個決策提供資訊；文件亦必須先處理，代理才能使用其內容。
固定這些決策有助比較，但時間假設仍需要解讀。買家應詢問基準測試是否近似其預期負載，還是刻意壓測超出該負載的邊界。
作業系統也提供另一個理由，說明為何不應只看完成數量。Linux 記錄了用以追蹤處理器、記憶體及輸入或輸出資源受限所引致停頓的 resource pressure 測量方式。其文件將資源競爭與延遲尖峰及吞吐量下降連結起來。
這些測量可提供有用的診斷背景。若代理工作負載變慢，輔助證據可幫助分辨問題是爭用處理器時間，還是在等待記憶體或儲存裝置。單一標題分數無法作出這種區分。
這是一項分析建議，並非聲稱該原型已報告所有診斷資料。更廣泛的一點是，主機容量始終是系統層面的特質。處理器會與記憶體、儲存裝置、軟件函式庫及作業系統政策一同運作。
因此，公平的硬件比較需要配置透明度。否則，讀者無法判斷表面上的處理器優勢是否依賴另一個元件或某項軟件設定。
同樣的審慎態度亦適用於基於處理器規格的解釋。更多核心意味著具有更高的平行工作潛力，但規格本身無法證明特定工作負載如何擴展。測量必須填補這個落差。
Tom's Hardware CPU benchmark 最適合作為此問題的受控觀察鏡頭。它可支援有關主機極限的問題，同時將即時應用程式時間留給互補實驗處理。
這種劃分讓評測者擁有更精確的詞彙。他們可以將執行容量與模型造成的延遲分開討論，而非將兩者壓縮成一個未加區分的 AI 分數。
MLPerf 與代理基準測試回答不同問題
重要的比較在於測量目標，而非爭論哪一種基準測試應取代其他測試。
MLCommons 表示，MLPerf Client 的代理測試涵蓋軟件工程及資料分析。其文件報告總任務時間，包括模型推理與工具執行，並按這兩個階段作出細分。
這種方法處理的是完整已配置系統的使用體驗。受控主機重播則回答較狹窄的元件問題。兩種方法的主題有所重疊，但其分數不應被視為可互換。
系統測試可以顯示某個配置較快完成，卻未必能完整解釋原因。元件測試可以釐清某一項優勢來源，卻未必能證實最終應用效益。兩者配合使用，能令硬件評測提供更多資訊。
MLCommons 亦區分基礎、延伸和實驗性元件。這些標籤相當重要，因為某功能的存在，並不代表每個配置或結果都有相同地位。讀者應查核特定工作負載所附的狀態。
代理能力基準測試帶來另一個維度。SWE-bench 透過套用生成的修補程式並執行儲存庫測試，評估軟件變更。其修補程式評估文件說明了旨在支援一致評估的容器化執行方式。
因此，SWE-bench 提供了一個有用的對照：完成執行序列，與解決軟件問題並不相同。快速的系統仍需要有效結果，而具能力的代理仍需要一個可執行工作的環境。
對開發自動化感興趣的買家，不應以其中一項指標取代另一項。能力與執行效能會互相影響，但兩者都不能同時代表兩者。
可靠性帶來另一項區分。原始的工具互動基準測試 tau-bench，評估代理如何使用領域工具並遵守政策要求。其作者將最終資料庫狀態與預期結果作比較，並檢視重複試驗之間的一致性。
該研究提供的是方法論上的提醒，而非直接批評這個原型。代理服務必須反覆執行正確操作。重播固定路徑，無法獨立證明實時模型能可靠地選擇該路徑。
這些方法構成一組有用且互補的問題。代理能否解決任務？它能否穩定做到？已配置的系統執行工作有多快，以及哪個元件限制了它？
沒有一項要求否定其他方法。錯誤在於將它們的答案壓縮成一個普遍主張：某部機器在代理方面就是更快。
對評測者而言，機會在於解釋不同量度之間的分歧。一部機器可能仍有閒置的主機容量，卻在其他環節受限。另一部機器可能迅速完成受控工作負載，但對另一種任務組合幾乎沒有優勢。
當量度邊界保持清晰時，這些都是可解讀的結果。只有當不同測試被呈現得彷彿量度同一件事時，它們才會令人困惑。
受控重播仍需要現實檢驗
Tom's Hardware 的 CPU 基準測試仍屬原型，其受控條件值得仔細審視。該刊物亦承認在更廣泛的平台覆蓋、對話式工作負載及框架方面存在限制。
可重複執行是比較硬件的必要條件，但單靠可重複性，並不能證明工作負載代表實際生產使用。
最值得質疑的問題在於所選路徑。記錄好的序列為每個系統提供可比較的工作，但其相關性取決於該序列能否準確反映目標應用。即使一致，也不能彌補工作負載不合適的問題。
一項示例文件任務說明了這個問題。從乾淨文件擷取文字，與處理需要光學字元辨識的掃描檔不同；後者會將影像中的文字轉換為機器可讀字元。偏重任何一種情況的基準測試，都可能呈現不同的主機需求圖景。
同一原則亦適用於軟件任務。搜尋小型專案與建置較大型的程式碼庫，對機器施加的要求並不相同。籠統的代理標籤，並不會令這些要求變得等同。
因此，讀者應在解讀整體分數前檢視任務組成。綜合結果需要足夠細節，以展示哪些因素構成結果。否則，工作負載組合便會成為隱形的購買假設。
正確性同樣需要重視。若實時工具產生意料之外的結果，基準測試必須區分有效執行，以及快速但無效的執行。若排除無效運行而不加說明，也可能掩蓋實際問題。
一份有用的報告應披露不成功運行，並列出成功量度。它應說明失敗是源於任務行為、配置、資源限制，還是測試系統本身。這個背景決定餘下分數是否代表正常運作。
重複量度亦需要清晰的起始狀態。保留自先前工作的檔案及其他資料，可能改變後續運行需要完成的工作。基準測試應說明其量度的是全新執行、重複執行，還是指定的組合。
這些是評估要求，並非證明該原型處理不當的證據。其目的在於確立讀者在以已發表數據選擇硬件前應要求的內容。
「CPU 基準測試」一詞還有另一個限制。工具執行可能取決於儲存裝置及其他系統資源。若這些依賴關係影響分數，讀者便需要足夠資訊，避免將每項差異都歸因於處理器。
同樣地，相對回應速度門檻需要背景說明。一個系統可以維持其自身基線行為，卻仍然在絕對時間上比另一個系統更慢。基線與負載下的效能同樣重要。
這正是審慎報道發揮作用之處。來源中沒有經驗證的排名可證明某個處理器家族在各類代理工作負載中勝出。可以站得住腳的結論，是關於所提出的方法，以及仍需要的證據。
當重播的範圍、有效性及其與實時工作負載的關係清晰可見時，它才會成為購買證據。在此之前，它最大的貢獻，是令一個困難的量度問題變得更具體。
留意重現、實時比較及更廣泛的工作負載
下一個里程碑，應是把受控主機量度與可獨立理解的應用行為連結起來的證據。
未來數月，首個值得留意的訊號，是可重現的工作負載套件，或同等程度的方法披露。讀者需要任務定義、軟件版本、配置細節、有效性規則，以及清楚說明分數如何計算。
這是觀察準則，不是已公布的發布時間表。若另一個團隊能在等同條件下重現行為，對該量度的信心便會提高。若結果依賴未披露的選擇，其實用性仍然有限。
重現亦應意味着理解結果的形態。在不同硬件條件下，獨立運行毋須得出完全相同的數字。它應提供足夠證據，解釋一致、差異或失敗。
第二個訊號，是凍結重播與實時推論之間的直接比較。這能展示當模型重新負責掌控工作節奏時，量度到的主機容量會在多大程度上影響完成時間。
若重播優勢延續至可比較的實時工作負載，便會加強其對該應用的相關性。若優勢大致消失，重播對容量分析仍然有用，但對升級的支持便較弱。
這些量度之間的差異本身亦具資訊價值。它可能顯示應用將時間花在其他地方，或改變時序會改變資源爭用。不論哪種結果，都比假設元件分數能預測一切更有用。
第三個訊號，是跨任務、框架及系統配置的更廣泛覆蓋。更有力的證據會展示結論在哪些情況成立、在哪些情況改變。相比一個普遍勝出者，清楚解釋工作負載敏感性更具資訊價值。
若排名在相關變化下仍然相似，對其更廣泛適用性的信心便會增加。若排名出現變動，讀者便有理由令硬件選擇更貼近其打算執行的工作。
買家應將這種敏感性視為資訊，而非基準測試失敗。代理軟件涵蓋不同活動，而這些活動未必偏好同一部機器。
目前，合理的回應是改善附於效能主張的問題。應問清楚哪些工作在本機執行、哪些因素維持固定、如何處理無效運行，以及計時是否包括模型。
在把 Tom's Hardware 的 CPU 基準測試視為購買指南前，先找出限制自己工作流程的階段。記錄時間是花在模型回應、文件處理、搜尋、建置還是驗證。然後，將未來結果與該工作負載比較，而不是與其代理標籤比較。要求同時提供成功完成率，以及在你預期負載下的等待時間。受控重播可以揭示有用的容量，而實時比較則顯示該容量是否真正惠及用戶。隨著這些量度發展而追蹤證據，並圍繞系統必須完成的工作作出購買決定。更快的處理器實際上能縮短哪一個階段？
