阿里云第十代ECS：基于AMD第六代EPYC，Agent算力升级

越来越多的工作正被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。

围绕Agent工作流、数据和工具链，第十代ECS企业级实例做了系统性升级。Agent编码场景中，它的性能比九代实例提升约30%；搜索推荐等传统场景提升约23%；整体性价比提升约25%。此外，第十代ECS企业级实例还联合Alibaba Cloud Linux 4，在操作系统层面对Agent任务做了专项优化，并借CIPU提高云盘、网卡等设备的接入密度，从硬件、系统软件到I/O，为Agent的大规模并行任务提供全栈支撑。

Agent的大规模落地让CPU重新回到舞台中心

AI系统里始终有CPU的位置。前几年，行业目光主要放在大模型训练和推理上，矩阵计算最密集的部分交给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 场景做优化。它搭载 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。目录价同时下调约 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 企业级实例，走的就是这条路。

当然，这些优化最后还得拿到实际业务里检验。企业在意的不只是处理器换了几代、参数涨了多少，而是任务能不能更快完成、能同时处理多少任务、整体成本能不能压下来。对云厂商而言，能不能把新一代算力变成这些看得见的业务变化，才是接下来真正要回答的问题。