Agent 正在接手越来越多的工作，一场发生在模型之外的算力升级也悄然开始。
2026 年 9 月，Meta 发布个人 AI 智能体 Muse，仅用了十余天，下载量就突破 250 万，一度登顶美国 App Store 免费榜，并快速霸占全球各大科技热榜头条。但这仅仅是浪潮的起点。9 月底，OpenAI 发布了常驻于 Codex 的助手 dots；10 月，Google Cloud 推出面向工作场景的 Gemini Agent；11 月初，Perplexity 也推出了主打复杂任务协同的 Teammates。从 Personal Agent 到 Work Agent，AI 智能体正以惊人的速度向实际工作场景渗透，并成为当下 VC 圈最密集、最核心的押注方向。
浪潮之下，外行看热闹，内行看的是，谁的 Agent 能更好地把活干完。这背后比的不只是模型本身的能力，还有模型之外的那部分能力。
原因在于，传统 ChatBot 的特点是一问一答，主要依靠模型理解问题、生成回复。Agent 不同，它完成一项任务，不会只向大模型提问一次。以完成一次竞品分析为例，它要先拆解任务，再打开浏览器搜索资料、读取数据库、运行代码、调用企业软件。如果网页打不开或代码执行失败，还要退回上一步重新规划，最后核对结果是否可信。
在这条链路里，模型推理通常由 GPU 完成，但浏览器、数据库、代码环境、权限检查和结果验证等大量工作，仍要运行在 CPU 上。任务越长、调用工具越多、同时在线的 Agent 越多，模型之外的那部分计算，就越重要。
这也是为什么，到了 Agent 时代，企业对先进算力的需求越来越迫切。需求的变化，也让云厂商开始加快新一代处理器的引入速度。从最近几代 ECS 实例来看，阿里云一直在缩短新一代处理器从芯片发布到云上算力可用的时间，让企业能够更快用上最新的 CPU 算力。
阿里云近期发布的第十代 ECS 企业级实例，搭载的就是 AMD 刚刚在 11 月初正式发布的最新处理器——第六代 EPYC™ 9006（代号 Venice）处理器。这颗处理器采用 Zen 6/Zen 6c 架构和台积电 2nm 工艺，单路最高支持 256 核、512 线程，内存通道从上一代的 12 条增加到最高 16 条，并支持 12.8 GT/s MRDIMM。
第十代 ECS 企业级实例还围绕 Agent 工作流、数据和工具链进行了系统性升级。相比九代实例，第十代 ECS 企业级实例在 Agent 编码场景中的性能提升约 30%，在搜索推荐等传统场景中的性能提升约 23%，整体性价比提升约 25%。 同时，第十代 ECS 企业级实例结合 Alibaba Cloud Linux 4 在操作系统层针对 Agent 任务进行了专项优化，并通过 CIPU 提升云盘、网卡等设备的接入密度，为 Agent 的大规模并行任务提供从硬件、系统软件到 I/O 的全栈支撑。
Agent 的大规模落地让 CPU 重新回到舞台中心
CPU 从来没有离开过 AI 系统。过去几年，行业关注点集中在大模型训练和推理，GPU 承担最密集的矩阵计算，CPU 主要负责主机侧调度、数据准备、网络和存储 I/O。
到了 Agent 时代，CPU 承担的任务明显变多了。
以一次“生成一份市场分析报告”为例，模型负责在几个关键节点做判断、执行推理步骤，但在这些步骤之间，Agent 还要完成大量实际执行工作：抓取网页、解析文件、查询数据库、运行 Python 程序、生成图表并检查输出。这些任务很多并不需要 GPU，却会持续占用 CPU、内存、网络和存储资源。单个 Agent 的消耗或许并不突出，但当成百上千个 Agent 并发运行，执行侧就会形成独立的算力池。
AMD 在其 Agentic AI 基础设施示例中，对这种变化给出过一个更直观的描述：传统生成式 AI 服务器通常由 1 颗 CPU 作为头节点，搭配 4-8 张 GPU；到了 Agentic AI 时代，CPU 与 GPU 的配置正在向 1:1 靠近，在一些负载中，CPU 的比重可能还会更高。
不过，“CPU 需求增加”并不等于简单增加核心数。Agent 本身就是一组差异很大的工作负载，不同工作负载卡在不同地方：有些任务更看重单核性能和响应延迟，有些则受内存容量、带宽和 I/O 影响。当大量 Agent 同时运行沙箱、执行代码和调用工具时，核心与线程密度又直接影响一台机器能够承载多少并发任务。这也是为什么，AMD 将 Agentic AI 描述为一条由不同计算特征组成的完整工作流，而不是一种单一的 CPU workload。
所以，判断一套 Agent 基础设施是否高效，至少要同时看四类指标：单步任务的响应时间、单位机器可并发的任务数、CPU 等待数据的比例，以及单位任务的综合成本。如果只比较 CPU 核数或单项跑分，很难回答真实业务问题。
十代实例，围绕 Agent 工作流的系统性升级
第十代 ECS 企业级实例不是一次简单的 CPU 更新，而是围绕 Agent 工作流、数据和工具链进行的系统性升级，并以此回答四个问题：一台服务器能同时跑多少任务，CPU 能多快拿到数据，能同时启动多少隔离执行环境，以及如何减少任务运行开销？
更多并行能力：减少任务排队
当大量 Agent 同时打开浏览器、运行代码或处理文件时，核心与线程密度会直接影响一台服务器能够承载的并发任务量。但核心越多，不代表性能一定按比例增长；如果任务受单线程、内存或 I/O 限制，继续加核可能只会让更多核心一起等待。因此，对 Agent 场景更有意义的指标，是完成同一批任务需要多长时间，或者单位时间能够完成多少任务。
第十代 ECS 企业级实例搭载的 AMD 第六代 EPYC™ 9006 处理器拥有更高的核心密度，单路最高 256 核、512 线程，为一台服务器同时运行更多任务提供了条件，吞吐性能较上一代 192 核旗舰 EPYC™ 9965 提升约 78%。相当于，一台服务器里，能同时干的活更多了，任务完成时间也更快。
更高内存带宽：减少数据等待
CPU 的计算能力提高后，内存能否及时提供数据，也变得更加重要。AMD 第六代 EPYC™ 9006 处理器把内存能力往上推了一大截，扩展到最高 16 通道。 内存通道可以理解为 CPU 与内存之间的数据车道：车道更多，多个核心同时读取特征、索引和中间结果时，更不容易堵车。这对搜索推荐、数据库扫描、数据预处理和高并发 Agent 任务尤其重要。
AMD EPYC™ 9006 系列服务器 CPU 是针对智能体 AI、云、企业、高性能计算和通用计算解决方案产品组合中的一部分。这部分能力也直接延续到了第十代 ECS 企业级实例。据悉，第十代 ECS 企业级实例内存带宽相比上一代提升了 60% 以上。
更高执行环境密度：解决 Sandbox 数量受限
Agent 的执行环境不仅消耗 CPU 和内存，还会使用网络、存储和虚拟设备。当一台服务器上同时运行大量隔离环境时，弹性网卡、云盘、网络连接和 I/O 吞吐，也可能成为继续提高 Agent 并发任务的限制因素。
阿里云在第九代 ECS 中，就已经通过 CIPU 承担虚拟化、网络和存储 I/O 等底层工作，减少这些任务对主 CPU 的占用。到了第十代，CIPU 的能力进一步优化。据阿里云披露，新一代 CIPU 进一步提升了云盘、网卡等设备的挂载密度，为大规模并行任务提供支持。
这对 Agent Runtime 来说格外重要。过去衡量服务器的运行密度，讨论最多的是“单机能放多少核”。但对于 Agent Runtime 来说，Sandbox 还需要网络、存储等资源。当大量 Sandbox 同时运行时，云盘、网卡等设备的挂载能力，也会影响一台物理机能够承载多少隔离执行环境。阿里云此次对 CIPU 的优化，能进一步提高设备挂载密度，为更多 Sandbox 并行运行、承载更多 Agent 任务提供支持。
操作系统协同：减少任务运行开销
除了硬件，第十代 ECS 企业级实例在操作系统层面也继续往 Agent 场景做了优化。第十代 ECS 企业级实例搭载 Alibaba Cloud Linux 4，并针对 Agent 任务继续做专项优化。相比九代实例，第十代 ECS 企业级实例在 Agent 编码场景中的性能提升约 30%。
这类优化的价值，在于能降低 Agent 运行过程中的系统开销。一次 Agent 任务往往涉及多个环节，随着任务执行时间延长、并发规模扩大，开销也会不断累积。减少这些消耗，有助于提升任务执行效率，降低运行成本。
从处理器、内存，到 CIPU 和操作系统，第十代 ECS 企业级实例实际上完成的是一轮系统升级。新一代 CPU 提供更高的计算能力，阿里云提供的，是如何让用户更快、更充分地用上这些先进算力。这一思路，也体现在阿里云此前发布的几代实例上。
以去年阿里云推出的九代 AMD 实例为例，旗舰型 g9ae 和通用型 u2a 均基于当时最新的 AMD Zen 5 架构“Turin”处理器，面向不同场景需求。当时一个很明显的产品思路是，根据负载而不是只根据规格大小来组织算力。
AI 时代，CPU 的舞台不止 Agent 运行时
具体来说，这两款实例对应的是三种不同的算力取向。其中，旗舰型 g9ae 基于高核心密度的 Turin Dense 架构，单颗 CPU 核心数可达 192 核，并采用“物理核”设计，交付给客户的是一个独占的、不受其他线程争抢缓存及指令的物理核心。它的价值，可以从三类典型负载中看出来。
第一类是搜索推荐，这也是 CPU 长期承担重负载的典型场景。
一次搜索或推荐请求背后，要在很短时间内完成大量特征处理、召回和排序。随着大语言模型逐渐被引入搜索推荐系统，召回、粗排、精排、甚至 Query 阶段就开始“大模型化”。但基于 Transform 的自回归架构，参数规模的增加、特征的语义化，同时还要维持在线业务对响应速度的要求，对算力的需求数量级的往上涨。针对这类负载，g9ae 在算力、内存带宽上进一步加强。 在端到端的搜推业务中，相比第八代 AMD 实例取得了约 37% 的性能提升。
第二类是中小语音模型。 随着 7B、14B 等中小模型在部分垂直任务上的能力提升，一部分推理开始有机会放到 CPU 上，比如语音交互就是其中一类。这里有几个问题不容忽视：延迟、并发，以及成本。g9ae 在满足单路任务延迟要求的同时，也可以在一台机器上并行承载更多任务，让 CPU 推理的成本进一步摊薄。
第三类是 Agent 带来的新型执行负载。 对于这类负载，g9ae 通过减少物理核争抢、提高内存带宽，提升吞吐，减少 GPU 等待。 训练侧也类似。Agent 做强化学习时，需要通过 Rollout 跑出大量任务路径，这些交互型负载也可以跑在 CPU 上，g9ae 强大的计算能力和内存带宽，大幅提高了这部分执行吞吐。
当然，并不是所有业务都需要这样的算力配置。不同企业对计算性能、响应速度和成本的要求各不相同，算力选型也需要更加贴近实际业务。阿里云去年同期推出了 u2a，满足用户对算力普惠的需求。
u2a 主打“低成本 + 高性价比”，是企业“算力普惠”的首选，相较于上一代 u1 实例，其性能基线提升 20%，并支持额外 15% 的算力突发；网络带宽从 10 Gbps 提升至 16 Gbps，并可突发至 25 Gbps。同时，u2a 目录价降低约 10%，综合性价比提升高达 50%。对于希望控制基础设施投入、又需要更高性能的企业来说，这意味着能够以更低成本获得新一代 CPU 算力，把更多资源投入业务创新。
从去年阿里云与 AMD 联合发布的这 2 款实例来看，两家行业巨头对“AI 时代算力应如何构成”这一核心问题，已经做出了体系化回应：既要满足高吞吐、高性能的计算任务，也要兼顾企业对成本的要求，让 CPU 的性能更好地匹配实际负载。
在第十代 ECS 企业级实例中，同样能看到这一思路。针对 Agent 等新型负载，阿里云将优化范围进一步覆盖内存、CIPU 和操作系统，并搭载了 AMD 最新处理器，让用户能够更快获得最新一代 CPU 算力。
企业选型时，可以先问四个问题
不过，对于准备部署 Agent 的企业来说，判断一款产品是否合适，不能只看“是不是最新一代”。更实用的方法，是先定位任务链路中的“等待”究竟发生在哪里：
如果 GPU 利用率不高、经常等数据，要先检查主机侧的数据预处理、CPU 处理能力、内存带宽以及网络和存储 I/O。瓶颈如果出在 GPU 之外，单纯增加 GPU 并不能解决问题。
如果大量 Agent 任务排队，要看单任务平均占用多少 CPU、峰值并发数和任务持续时间，再决定是提高单机核心密度，还是通过弹性伸缩增加实例数量。
如果 CPU 利用率不高、吞吐却上不去，还要继续检查内存带宽、缓存、NUMA 和 I/O。“CPU 没跑满”并不意味着计算平台没有瓶颈。
如果沙箱启动数上不去，要同时检查内存、网卡、云盘、容器限制和安全策略。此时，设备挂载密度与 CIPU 能力可能比单纯增加 CPU 核更关键。
此外，所有性能数字都应该被翻译成业务指标：是让一次任务更快完成，还是让一台机器同时跑更多任务，或者让每个任务成本更低？只有把吞吐、时延、成功率和成本放在一起，所谓“Agent 友好”才不是一个抽象标签。
重新审视模型之外的计算
当越来越多的 Agent 进入企业承担真实工作，CPU 的作用将会更加突出，计算能力、执行效率等等，都会直接影响 Agent 完成任务的速度。
这对云厂商也提出了新的要求。既要让用户尽快用上最新一代 CPU 算力，也要做好 CPU、内存、网络、存储和操作系统之间的协同，让新硬件的性能在实际业务中得到充分发挥。第十代 ECS 企业级实例，正是沿着这一方向展开。
当然，这些优化最终还是要回到实际业务中检验。企业关心的不是处理器换了多少代、参数提升了多少，而是任务能不能更快完成，能同时处理多少任务，以及整体成本能不能降下来。对于云厂商来说，能否把新一代算力转化为这些看得见的业务变化，才是接下来真正需要回答的问题。
