Google 智能体 AI CPU 需求让闲置算力受到审视

Google 表示，AI 智能体将带来新的 CPU 需求，即使其执行环境常常会长时间处于等待状态。因此，Google 智能体 AI CPU 需求涉及的问题，比单纯增加处理器更棘手：如何在不预留闲置硬件的情况下，持续提供可用的软件工作者。随着智能体不再只是生成答案、而开始操作软件，负责执行应用程序代码的通用处理器 CPU 将成为核心。

在 10 月 30 日接受 EE Times 采访时，Google Cloud 高管 Mark Lohmeyer 描述了智能体调用服务、浏览网站和运行代码的场景。这些活动扩大了模型周边的计算工作。擅长并行计算的 GPU，以及 Google 专为机器学习设计的 TPU，仍承担着大量模型计算；但外围应用同样需要自己的执行能力。

这给云平台和企业基础设施团队带来压力。围绕模型服务速度设计的系统，仍可能令用户失望：智能体可能等待工作区就绪、丢失会话状态，或不必要地预留资源。AWS 正在推进类似的执行服务，为买方提供了竞争性参照。核心竞争在于：是持续预留执行环境，还是在释放闲置算力的同时保留智能体的工作成果。

Google 智能体 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 的 agent 基础设施属于一场更广泛的转变：将执行环境作为 agent 应用的一部分进行管理。真正相关的竞争，不只是哪个提供商能提供更多处理器核心，而是哪项服务能够保留有价值的工作、处理恢复后的活动，并让资源消耗变得可理解。

对采购方而言，这一区别改变了评估问题。仅仅询问一个空环境启动得有多快并不够。更具说明力的问题是：一个包含依赖项和保留工作内容的真实工作区，在中断后恢复服务时表现如何。

更高的 agent 密度并不能确立 CPU 需求预测

能够合理解释额外 CPU 工作的存在，与证明市场将需要多少额外硬件，并不是一回事。

Google 的 agentic AI CPU 需求存在相互对冲的力量。更多 agent 任务会带来额外执行工作；更好的资源共享则会减少支撑既定 agent 数量所需的硬件。最终结果取决于采用规模、工作负载强度，以及基础设施改进的实际成效。

Google 自己的工程材料说明了这一区别为何重要。在 7 月 30 日发布的 agent 密度基准测试中，该公司在固定机器配置上测试了 OpenClaw 工作负载。它报告称，通过调整执行与资源管理方式，可以支持更多 agent。这些发现仅针对特定工作负载和配置。

它们不应被当作生产部署的通用倍数。不同 agent 保留的内存量不同，执行的软件不同，等待的时长也不同。安全配置同样会影响应用可获得的资源。密度测试结果必须结合其适用条件才有意义。

反过来，同样需要保持谨慎。CPU 工作量增长的预测，并不能证明处理器会成为每一个 agent 的限制性资源。有些应用会花更多时间等待模型响应；另一些则会遭遇外部服务限制或存储延迟。

因此，agent CPU 利用率应作为更广泛测量体系的一部分来使用。较高数值可能意味着高效执行，也可能伴随资源争用和任务延迟；较低数值可能意味着浪费，也可能反映有意预留的容量。解释这些数据需要结合应用的性能与可靠性数据。

商业计量单位同样重要。统计已启动的 agent，可能会美化一个几乎没有完成有用工作的服务；统计活跃会话，则可能掩盖反复失败或被放弃的任务。已完成且被接受的结果，才是判断基础设施改进是否真正惠及客户的更严格依据。

“agent”这个词本身还存在另一层不确定性。一次简短的代码执行请求和一个持续运行的浏览器工作区，都可能被称为 agent。它们对处理器和持久化的要求并不相同。将它们汇总为未经区分的需求类别，会掩盖决定实际资源需求的工作负载结构。

这也是为什么 CPU 叙事不应急于宣布某种架构胜出。Intel、AMD 和基于 Arm 的设计都在更广泛的服务配置中竞争。除处理器执行速度外，软件兼容性、内存容量和存储访问也会影响结果。应用层面的比较需要保持成功标准的一致性。

证据最充分的结论比市场预测更为有限。Google 已确认，常规执行工作是 agent 服务的重要组成部分。其产品方向旨在弥合持续会话与间歇性活动之间的缺口。由此产生的硬件需求规模，仍是一个需要实证检验的问题。

这为采用增长和效率提升都留下了空间。如果 agent 在更多工作流程中变得有用，即使资源共享有所改善，总执行量仍可能扩大；如果采用不及预期，仅靠基础设施改进并不会产生持续需求。该技术机制解释了一种机会，但并未确立其最终规模。

隔离必须经受住提升利用率的压力

回收闲置资源只有在平台能够保留客户所需的安全边界与工作状态时才会创造价值。

Agent 可以执行受到模型输出和外部信息影响的代码。这与仅运行由应用开发者编写和审查的软件形成了不同的信任关系。运行时必须考虑其运营者并未明确编写的操作。

隔离限制执行环境能够访问的范围。授权则决定某个身份被允许执行哪些操作。这两类控制解决的是相关但不同的问题。隔离环境仍可能滥用系统正当授予它的访问权限。

这一区别避免了常见的类别错误。安全的执行边界并不能证明 agent 正确理解了请求，也不能证明每项获准操作都符合用户意图。基础设施控制约束执行，而应用控制则治理任务本身。

效率讨论必须保留这两个层面。将更多工作整合到共享硬件上，会提高可靠隔离的重要性。保留会话则引出关于保留数据和访问权限到期的问题。恢复工作区时，不应悄然恢复已不再适当的权限。

设想一个读取内部文档并准备简报的企业研究 agent。该 agent 需要足够的连续性来保留其进展，但其访问权限仍应反映当前用户权限。已保存的工作区和授权决策不应被视为可以互换的记录。

这一例子也将基础设施设计与信息质量联系起来。只有当系统保留了正确的来源和工作材料时，保留进程才有帮助。构建 可搜索知识库的团队面临相关的组织挑战：让技术证据能在持续工作中被检索。这一关注点补充了运行时持久化，但不能取代它。

运营韧性同样值得关注。一个在正常条件下能够正确恢复的环境，在写入中断或连接失败后可能表现不同。采购方需要了解暂停后哪些内容会保留、哪些内容必须由应用重新创建。否则，看似连续的体验可能掩盖不完整的恢复。

同一原则也适用于清理。停止工作的 agent 最终应依据明确的保留策略释放资源。无限期保留所有内容会带来不必要的责任；删除得过于激进，则会损害基础设施原本要支持的持续体验。

这些都是应当仔细审视 Google 主张的理由，但不意味着应否定其底层设计。公司文档解释了预期的边界和行为；独立测试与运营经验则揭示这些功能在真实应用条件下如何表现。二者不应相互替代。

采购层面的含义很具体：应一并评估隔离、连续性和资源效率。一项服务如果优化了其中一个维度，却让其他维度仍不明确，就没有解决完整的基础设施问题。真正相关的结果，是在可接受的安全和运营模式下交付有用工作。

下一阶段的证据应来自访问权限、工作负载和结果

这一故事的下一阶段取决于客户可见的执行行为，而不是更多关于 agent 需要 CPU 的断言。

第一个信号是 Agent Compute Engine 的实际可用性。Google 10 月的公告指出，预览版将在未来几个月推出。未来数月内，公开的访问条件、支持的配置和运营限制，将显示客户能够如何评估这一架构。

预览版将通过把讨论转向可观察的服务行为来增强这一论述。有限访问仍可提供有用证据，但会限制比较范围。文档应清楚说明这些边界，而不是让读者从 Google 内部使用情况的描述中自行推断。

第二个信号是具有代表性的工作负载测试。有价值的比较应在同一任务中涵盖活跃执行、等待、中断和恢复。启动很快但恢复表现不佳的环境，并不能提供一致的连续性。同样，如果反复状态切换会干扰工作，高效的闲置状态也就没那么重要。

这类测试应披露工作负载及其周边条件。内存要求、保留文件、并发量和隔离设置都会影响解释。当比较在等效的应用要求下纳入 AWS 或其他相关执行服务时，信息价值会更高。

如果改进后的资源管理能够保持完成率和响应速度，这些证据将强化 Google 的论点；如果节省成本需要以不可接受的延迟或更狭窄的应用兼容性为代价，则会削弱其商业价值。无论哪种结果，都比孤立的处理器基准测试提供更多信息。

第三个信号是客户围绕已完成工作的报告。企业部署能够揭示：在模型选型之后，执行基础设施是否仍是重要约束；它们也能显示，持久化环境是否能显著提升任务完成度，从而证明其运营复杂性是合理的。

这些报告应区分模型问题和运行时问题。一个选择了错误操作的 agent，与一个无法恢复的环境，属于不同类型的失败。将两者合并为单一成功指标，会使基础设施难以评估。将其分开有助于采购方理解哪些改进真正重要。

当这些信号同时出现时，Google 的 agentic AI CPU 需求将更容易评估。服务访问说明客户能使用什么；代表性测试说明执行过程如何运行；客户结果则说明最终系统是否产生了足以支持持续部署的价值。

目前的报道支持一个明确的重心变化。Agent 应用需要关注模型周围的软件执行，包括该执行停止的时期。CPU 对这项工作依然至关重要，而持久化与资源管理决定平台以多高效率提供这些能力。

从贵组织确实希望 agent 完成的工作流程开始。识别哪些阶段执行代码、哪些阶段等待，以及哪些阶段需要保留文件或权限。要求潜在提供商以相同任务和验收标准演示这些状态转换。让评估聚焦于已完成的工作、可恢复的状态和可理解的资源消耗。随着新服务变得可用，这种方法能让开发者和采购方以务实的方式评估 Google 的论点。关键并不在于接受一个宽泛的 CPU 需求预测，而在于确认某个平台是否能够以经济的方式支持持续的 agent 体验。当 agent 无事可做时，它的计算机将发生什么？