Google Agentic AI CPU 需求令閒置運算資源受關注
Google 表示，AI 代理將帶來新的 CPU 需求，即使其執行環境長時間處於等候狀態亦然。因此，Google agentic AI 的 CPU 需求涉及的難題，不僅是增加處理器，而是如何讓持久運行的軟件工作者隨時可用，同時毋須為閒置硬件預留資源。當代理不再只生成答案、開始操作軟件時，CPU 這類執行應用程式程式碼的通用處理器便成為核心。
在 10 月 30 日接受 EE Times 訪問時，Google Cloud 高層 Mark Lohmeyer 描述了代理如何呼叫服務、瀏覽網站及運行程式碼。這些活動增加了模型周邊的運算工作。GPU 是針對平行運算最佳化的處理器，而 Google 的 TPU 則是專門用於機器學習的晶片，兩者仍處理大部分模型運算；周邊應用程式則需要自身的執行能力。
這為雲端平台及企業基礎設施團隊帶來壓力。一個圍繞模型服務速度而設計的系統，若代理要等待工作空間、遺失工作階段狀態，或不必要地預留資源，仍可能令人失望。AWS 正推進類似的執行服務，為買家提供競爭性的參考。核心競爭在於持續預留的環境，以及能在釋放非活躍運算資源之餘保留代理工作內容的基礎設施之間。
Google agentic AI CPU 需求不止於模型服務
Google 的論點聚焦於 AI 模型周邊的基礎設施，而非取代專用 AI 處理器。
Google AI 與運算基礎設施副總裁兼總經理 Lohmeyer 在代理工作負載討論中說明了這項區別。據 EE Times 報道，代理會將用戶請求拆分為涉及一般軟件執行的子任務。由此產生的工作負載具間歇性，對處理器、儲存及資源管理提出不同要求。
關鍵在於模型選擇一項行動後會發生甚麼。產生看似合理的指令，與完成該指令所要求的任務，消耗的是不同資源。瀏覽器必須載入頁面、程式必須執行，而應用程式必須回傳結果。為決策加入智能，並不會免除這些操作。
代理，即使用模型選擇並執行行動以達成目標的軟件，將這些階段串連起來。它的實用性取決於整個流程。若下一個執行環境要花太長時間才可使用，模型再快的回應亦價值有限。
這有助解釋為何除了模型服務能力外，CPU 需求亦值得關注。模型服務是指運行已訓練模型以產生輸出。代理的整體執行包含該操作，也涵蓋其周邊的程式碼及服務。只衡量模型，便會令部分應用程式不在效能評估範圍之內。
該訪問亦未確立一種通用處理器贏家。Lohmeyer 表示 Google Cloud 同時採用 Intel 和 AMD 處理器，以及其基於 Arm 的 Axion 晶片。Arm 與 x86 是處理器指令集家族，決定軟件所執行的機器指令。不同代理工作負載，可能偏好不同的核心效能、核心數量及連接儲存組合。
這項區別對理解標題至關重要。更多代理活動並不代表每個 CPU 類別都會同樣受惠。以程式執行為主的工作負載，與以等待外部服務為主的工作負載不同。買家仍需了解自己實際運行的工作。
Google 的代理基礎設施如今讓這個論點更具體。10 月 22 日，Google 推出了 Agent Compute Engine，並表示該服務已支援 Gemini 工作任務。公告指出，它將在未來數月向客戶提供預覽版。截至 11 月 1 日，這種表述不應被理解為正式全面推出。
這一連串發展為訪問提供了具體背景。Google 一邊籌備旨在解決問題的商業服務，一邊闡述執行層面的難題。這令其工程說法具參考價值，同時亦讓讀者有理由區分已記錄的架構與預期的客戶效益。
基礎設施團隊承擔等候的成本
眼前壓力落在負責於有用工作間歇期間，讓代理環境保持就緒的團隊身上。
持久環境會在互動之間保留工作材料，其中可包括檔案、已安裝軟件及應用程式狀態。持久性令代理能在延長的任務期間保持實用，但也令資源管理更複雜。讓資訊可用與保持處理器獲分配，是兩項不同要求。
以處理程式庫修改的編碼助手為例。它會讀取檔案、運行程式、等待模型輸出，並向開發人員要求批准。在這些停頓期間，工作空間仍然重要；但處理器未必需要在整段期間持續保留。
這是一種說明性的工作負載，而非經量度的客戶部署。它顯示，工作階段經過的時間可能無法準確反映實際執行需求。工作階段即使處於非活躍狀態，仍可能具價值。將每個開啟中的工作階段視為持續繁忙，會掩蓋這項區別。
其後果延伸至應用程式商業模式。購買代理體驗的買家，希望獲得完成的工作及可靠的延續性。基礎設施供應商必須提供這些成果，同時決定要預留多少硬件。分配不佳可能在未改善用戶結果的情況下增加營運開支。
代理 CPU 使用率，即可用處理器容量中用於執行工作的比例，在此變得相關。然而，平均使用率數字無法描述整個體驗。平台即使顯示較低平均使用量，當許多等候中的代理同時恢復活躍時，仍可能面對困難。
這造成彼此競爭的營運要求。供應商希望有效共享容量，而用戶期望工作恢復時可即時存取。只有系統能夠處理重新活躍的需求，緊密配置環境才有幫助。繁忙時段的延誤，可能抵銷讓工作階段保持可用的好處。
Google 在 9 月 15 日對 Agent Substrate 的描述，明確處理閒置執行環境及活動突發的問題。該公司描述了一套把代理執行與底層機器管理分離的軟件，亦提供不同隔離方案，反映工作負載並不具有完全相同的安全要求。
壓力亦延伸至企業採購。容量討論如今需包括代理如何暫停、保留工作及恢復。單靠處理器規格無法回答這些問題。服務在執行間歇之間的行為，成為所購買產品的一部分。
這亦改變內部問責方式。應用程式團隊可以選擇代理框架，而平台團隊則管理其運行時，即執行其軟件的環境。若兩個團隊都沒有量度非活躍資源分配，不必要的消耗便可能落在職責之間。最終問題會反映在基礎設施帳單上，而非模型評估中。
對開發人員而言，實際含意在於架構設計。長時間持續的用戶體驗，不應自動要求同樣長時間的處理器預留。平台能否將兩者的生命週期分離，決定一個有用的原型能否順暢擴展為服務。
持久工作空間挑戰持續預留的運算資源
核心設計問題在於，代理能否在保留工作環境的同時，交還暫時不需要的硬件。
傳統應用程式早已處理閒置時段，因此底層問題已有先例。代理工作負載則因結合可能不受信任的程式碼與個人化、持續運作的工作空間，而令問題更突出。環境必須能跨越中斷繼續發揮作用，同時不成為不必要的永久分配。
微型虛擬機（microVM）是使用硬件虛擬化來隔離執行環境的精簡虛擬機。沙盒是旨在容納程式碼並限制其存取權限的受限環境。這些概念在代理平台中有所重疊，但描述的是不同事物：一者是實作機制，另一者是安全目的。
單靠機制並不能解決經濟效益問題。小型隔離機器即使甚麼也不做，仍可能預留資源。效率取決於服務如何管理其整個生命週期。啟動、暫停、保留、還原及刪除環境，全部都成為相關操作。
快照，即執行狀態的已儲存表示，提供了一種保存延續性的方式。還原該狀態可避免從頭重建環境。然而，儲存及還原同樣涉及儲存與資料移動。將工作負載移出活躍記憶體，只是把需求轉移到其他地方。
這令 CPU 規劃與儲存規劃不可分割。若還原環境帶來長時間延遲，釋放處理器的幫助便會減少。同樣地，無限期保留所有內容可能形成不斷增加的儲存負擔。完整設計除了活躍執行外，亦需要為保留狀態制定政策。
Google 對持久代理環境的技術說明，描述了如何為非活躍工作階段建立檢查點，同時保留檔案及記憶體。建立檢查點是指儲存可復原的執行狀態。Google 亦描述將長期憑證保留在客體環境以外，並透過受控閘道轉送請求。這些屬於該公司對其設計的描述，並非獨立安全研究結果。
更廣泛的分析重點是，延續性成為一項系統屬性。用戶把代理體驗為持續進行的任務，而底層基礎設施則可經歷不同資源狀態。成功的實作會隱藏這些轉換，同時避免遺失工作或削弱存取控制。
AWS 在 6 月 22 日推出 Lambda MicroVMs時，提供了有用比較。AWS 描述了用於用戶編寫或 AI 生成程式碼的隔離環境，具備直接生命週期控制及保留狀態。其實作建基於 Firecracker，即該公司的輕量級虛擬化技術。
這項比較支持存在共同基礎設施問題的說法，但並不證明 Google 與 AWS 的服務效能相同、支援相同工作負載，或帶來等同的營運限制。它們已公開的描述提供了評估起點，而非完成的比較。
因此，Google 的代理基礎設施屬於更大轉變的一部分：將執行環境管理納入代理應用程式之中。相關競爭不僅是誰能提供更多處理器核心，而是哪種服務能保留有用的工作內容、處理重新恢復的活動，並讓資源消耗變得易於理解。
對買家而言，這個分別改變了評估問題。只問空白環境啟動得有多快並不足夠。更具啟發性的問題是：一個帶有依賴項目及保留工作內容的真實工作空間，在中斷後能否恢復服務。
更高的代理密度並不能確立 CPU 需求預測
對額外 CPU 工作量作出可信解釋，與證明市場將需要多少額外硬件，是兩回事。
Google 的代理式 AI CPU 需求存在相互拉扯的力量。更多代理任務會帶來額外執行工作；更佳的資源共享則會減少支援既定代理數量所需的硬件。最終結果取決於採用情況、工作負載強度，以及基礎設施改進的成效。
Google 自身的工程資料說明了為何這個分別重要。在 7 月 30 日的 代理密度基準測試中，公司在固定機器配置上測試 OpenClaw 工作負載。它表示，透過改變執行及資源管理方式，可支援更多代理。這些發現只涉及特定工作負載及設定。
它們不應被視為可套用至生產部署的通用倍數。不同代理保留的記憶體數量不同、執行的軟件不同，等待時間亦不同。安全配置同樣會影響應用程式可使用的資源。密度結果必須連同其適用條件理解，才有意義。
同樣的審慎態度亦適用於相反方向。預測 CPU 工作量會擴大，並不能證明處理器會成為每個代理的限制資源。有些應用程式會花更多時間等待模型回應；另一些則會遇到外部服務限制或儲存延遲。
因此，代理的 CPU 使用率應作為更廣泛衡量指標的一部分。高數值可以反映有效執行，也可能伴隨資源爭用及任務延遲。低數值可以反映浪費，也可能反映刻意預留的容量。詮釋時需要參考應用程式的效能及可靠性資料。
商業衡量單位亦很重要。計算已啟動的代理數量，可能令完成很少有用工作的服務看起來表現出色。計算活躍工作階段，則可能掩蓋重複失敗或被放棄的任務。已完成並獲接納的成果，才是評估基礎設施改進是否惠及客戶的更嚴格依據。
「代理」一詞還有另一重不確定性。一次簡短的程式碼執行請求，以及一個持續運作的瀏覽器工作空間，都可以被稱為代理；兩者對處理器及持續保存的要求並不相同。將它們匯集成未作區分的需求類別，會掩蓋決定實際資源需要的工作負載組合。
這就是為何 CPU 的論述不應宣稱某種架構勝出。Intel、AMD 及以 Arm 為基礎的設計，都在更廣泛的服務配置中競爭。軟件兼容性、記憶體容量及儲存存取，都可能與處理器執行速度一樣影響結果。應用程式層面的比較需要採用一致的成功標準。
最有力、且有證據支持的結論，比市場預測更為收窄。Google 已將一般執行工作識別為代理服務的重要組成部分。其產品方向旨在處理持續工作階段與間歇活動之間的落差。由此產生的硬件需求規模，仍是一個實證問題。
這讓採用增加及效率改善都有空間。如果代理在更多工作流程中變得實用，即使資源共享更佳，整體執行量仍可擴大。若採用情況令人失望，單靠改善基礎設施不會帶來持續需求。技術機制解釋了一項機遇，卻不能確定其最終規模。
隔離必須經得起提升使用率的壓力
回收閒置資源只有在平台保留客戶所需的安全邊界及工作狀態時才會創造價值。
代理可執行受模型輸出及外部資訊影響的程式碼。這與只執行由應用程式開發人員編寫及審核的軟件，形成不同的信任關係。執行環境必須考慮營運者未有明確編寫的操作。
隔離限制執行環境可接觸的範圍。授權則決定某個身分可獲准執行哪些操作。兩種控制措施處理的是相關但不同的問題。即使環境已隔離，仍可能濫用系統合法授予它的存取權。
這個分別避免了一種常見的分類錯誤。安全的執行邊界並不能證明代理正確理解請求，也不能證明每個獲准操作都符合用戶意圖。基礎設施控制用於遏制執行，而應用程式控制則規管任務。
效率討論必須同時保留這兩個層面。將更多工作整合至共用硬件，會提高可靠隔離的重要性。保留工作階段會引發關於保留資料及存取權到期的問題。恢復工作空間時，不應悄然還原已不再合適的權限。
試想一個企業研究代理，它會閱讀內部文件並準備簡報。代理需要足夠的延續性以保留進度，但其存取權仍需反映目前的用戶權限。已儲存的工作空間與授權決定，不應被視為可以互換的紀錄。
這個例子亦將基礎設施設計與資訊質素連繫起來。只有當系統保留正確來源及工作材料時，保存程序才有幫助。建立可搜尋知識庫的團隊，面對一項相關的組織挑戰：在持續工作中，讓技術證據維持可檢索。這項考量補充了執行環境的持續保存，而非取代它。
營運韌性同樣值得重視。在正常情況下可正確恢復的環境，在寫入中斷或連線失敗後可能表現不同。買家需要了解暫停後哪些內容會保留，以及應用程式必須重建哪些內容。否則，表面上的延續性可能掩蓋不完整的復原。
同一原則亦適用於清理工作。停止運作的代理，最終應按照明確的保留政策釋放資源。無限期保留一切會帶來不必要的責任；過度積極刪除，則會削弱基礎設施原本要支援的持續體驗。
這些都是應仔細檢視 Google 主張的理由，但不代表應否定其背後設計。公司文件說明預期的邊界及行為；獨立測試及營運經驗則可確立這些功能在實際應用程式條件下的表現。兩者不應互相取代。
採購上的含意很具體：應一併評估隔離、延續性及資源效率。若服務只優化其中一個面向，卻令其他面向不明確，便未有解決完整的基礎設施問題。相關成果是：在可接受的安全及營運模式下交付有用工作。
下一批證據應來自存取、工作負載及成果
這個故事的下一階段，取決於客戶可觀察到的執行行為，而非進一步聲稱代理需要 CPU。
第一個訊號是實際存取 Agent Compute Engine。Google 在 10 月的公告指出，未來數月將提供預覽版。在接下來數月，已公布的存取條件、支援的配置及營運限制，將顯示客戶如何評估這種架構。
預覽版會透過將討論轉向可觀察的服務行為，強化這個論述。有限存取仍可提供有用證據，但會限制比較範圍。文件應清楚說明這些界限，而非讓讀者從 Google 對內部使用情況的描述中自行推斷。
第二個訊號是具代表性的工作負載測試。有用的比較應在同一任務中涵蓋活躍執行、等待、中斷及復原。啟動迅速但恢復表現欠佳的環境，無法提供一致的延續性。同樣地，若重複轉換會干擾工作，高效的閒置狀態便沒那麼重要。
這類測試應披露工作負載及其相關條件。記憶體要求、保留檔案、並行度及隔離設定都會影響詮釋。當比較納入 AWS 或其他相關執行服務，並採用等同的應用程式要求時，結果會更具參考價值。
若改善資源管理同時保留完成率及回應速度，這些證據便會強化 Google 的論點。若節省成本需要以不可接受的延遲或更窄的應用程式兼容性為代價，商業理據便會被削弱。無論結果如何，都比孤立的處理器基準測試提供更多資訊。
第三個訊號是客戶對已完成工作的報告。企業部署可揭示，在模型選擇之後，執行基礎設施是否仍是重要限制。它們亦可顯示，持續保存環境是否足以改善任務完成情況，從而值得承擔其營運複雜性。
這些報告應區分模型問題與執行環境問題。選擇錯誤操作的代理，與無法恢復的環境，屬於不同類型的失敗。將兩者合併為單一成功數字，會令基礎設施難以評估。將其分開，有助買家了解哪些改進真正重要。
當這些訊號一同出現時，Google 的代理式 AI CPU 需求將更容易評估。服務存取界定客戶可使用的內容；具代表性的測試界定執行行為；客戶成果則界定系統是否創造足夠價值，以支持持續部署。
目前的報道支持一項清晰的重點轉變。代理應用程式需要關注模型周邊的軟件執行，包括該執行停止期間的情況。CPU 仍是這項工作不可或缺的一部分，而持續保存及資源管理決定平台提供它們的效率。
先從你的機構真正希望代理完成的工作流程開始。找出哪些階段會執行程式碼、哪些會等待，以及哪些需要保留檔案或權限。要求潛在供應商以相同任務及驗收標準示範這些轉換。讓評估聚焦於已完成工作、可復原狀態及可理解的資源消耗。隨着新服務變得可用，這種做法可讓開發人員及買家以實際方式評估 Google 的論點。決策重點不在於接受廣泛的 CPU 需求預測，而在於確立某平台能否以經濟方式支援持續的代理體驗。當你的代理沒有事情可做時，它的電腦會發生甚麼事？
