最近圈子里讨论最多的话题之一就是CPU在Agent时代重新站到了C位。前几天看到鲲鹏把面向Agent的集群一路扩到4096节点说实话我的第一反应是不意外——我自己在压测Agent类服务时就有很强烈的体感真正把服务拖垮的往往不是GPU的浮点算力而是CPU的并发调度能力、内存带宽和整机的吞吐上限。一个是给模型算答案的引擎一个是给Agent过日子的底盘两者根本不是一回事。这篇文章我想以从业者的视角拆透这件事Agent负载到底对硬件提出了什么新要求为什么CPU集群反而在这轮胜出鲲鹏在芯片和互联层面的哪些设计踩中了痛点以及从一台机器扩到4096台机器中间到底要跨过哪些工程坎。最后我会把自己跑过的一套部署路径和踩坑记录整理出来给正在做Agent基础设施选型的团队一个参考。1. Agent这道新负载为什么会把CPU推回C位1.1 训练和推理根本不是一回事别用买显卡的思维解决所有问题前两年大模型火了之后很多人形成了一种条件反射聊AI就是聊GPU看算力就是看卡的数量。这个思维在训练场景没错因为训练的本质是超大矩阵乘法需要极高的FLOPS而GPU恰好把晶体管堆在了并行计算上。但Agent场景完全不一样。Agent的核心工作负载是大模型推理 工具调用 多轮规划的组合体。一个典型的Agent请求长什么样用户输入一段话Agent理解意图拆解成若干子任务依次调用搜索、数据库查询、代码执行等工具每调一次工具模型就要做一次推理。这种链路的特点是单个请求的计算量不大但请求数量巨大、并发极高、每路请求的上下文还要在内存里长期驻留。用买显卡的思维去扛这种流量结果就是GPU利用率低得可怜。你想想一张A100的FP16算力接近312 TFLOPS而Agent链路里大量的小批次推理根本喂不满它。实测下来很多Agent服务的GPU利用率长期在10%到20%之间晃荡钱花了大半活儿没干多少。CPU集群在这种场景下是另一种逻辑单核算力弱但核心数量多、线程调度灵活、内存容量大非常适合大量互不依赖的小任务并行推进的负载形态。1.2 Agent场景真正吃紧的三个指标并发、内存带宽、单位成本如果把Agent服务的关键性能指标拉一张表你会发现GPU最引以为傲的FLOPS其实排不进前三指标为什么对Agent生死攸关并发路数每个Agent会话在运行期间会不断发起推理和工具调用是一条长期存活的链路并发路数直接决定在线用户规模上限内存带宽CPU推理小模型时瓶颈不在算力而在权重和KV Cache的搬运速度内存带宽决定了每秒能生成多少Token单位会话成本Agent是长Run、多轮交互的成本按Token和按会话算不能像训练那样一次性摊平我自己做压测时有个很直观的对比在单台64核的CPU服务器上用量化后的7B模型扛300路并发Agent会话每路响应时延2秒左右整机稳得不行同样的流量丢到单张GPU上因为显存里要塞KV Cache一张卡扛不到100路就开始排队。这个对比很说明问题——Agent的瓶颈在并发调度和内存容量不在单次推理速度。1.3 一个反直觉的计算7B模型在CPU上跑得并不慢很多人一听到CPU推理就摇头觉得那是慢的代名词。这里有个被忽略的计算逻辑。以常见的7B对话模型为例INT8量化后权重大概7GB左右这正好是CPU内存带宽的舒适区。比如一台配置了8通道DDR4内存的服务器理论内存带宽能到190GB/s以上刨掉访存损耗和访存模式差异实际有效带宽按25%到50%算每秒也能吞吐50GB到90GB的数据量。这个数据量除以7GB权重意味着理论上每秒能处理7到12次完整的权重搬运。用大白话说单台CPU服务器在小模型推理场景下跑出每秒20到40个Token的生成速度是完全可行的。对于Agent内部规划、意图识别、工具返回结果总结这类短文本生成任务这个速度已经足够用了。更关键的是CPU集群拼的是整体的吞吐盘子——4096个节点各干各的活总量算出来就是个巨额数字。GPU确实单卡推理快但这个场景不是百米冲刺而是一万台出租车同时接单。2. 鲲鹏硬件底子里的哪些设计恰好踩中了Agent的痛点2.1 多核和内存通道为多路细粒度请求准备的吞吐架构鲲鹏处理器给我的第一印象其实不是它的ARM指令集身份而是它对吞吐型负载的理解。以鲲鹏920为样本来看单颗处理器集成64个物理核双路服务器轻松上百核。这是什么概念每个Agent会话的推理任务可以理解成一条独立的出租车订单上百核意味着上百个订单可以同时行进互不抢占。更关键的是内存通道。鲲鹏920支持8通道DDR4内存配合服务器整机的大内存配置可以把单节点的内存容量推到512GB甚至1TB级别。这点对Agent负载的重要程度怎么说都不为过——Agent长对话的KV Cache、工具调用的中间状态、多轮规划的记忆片段全都是吃内存的大户。我见过不少团队在GPU集群上为KV Cache挤占显存而头疼而在CPU集群上这个问题换成了内存够大、随便造的宽松模式。2.2 片上互联与一致性横向扩张的基础单节点再强也终究有限Agent级别的并发量必须要横向扩展。鲲鹏在互联设计上有一套自己的逻辑核心思路是多路CPU之间保持缓存一致性也就是说多个处理器在硬件层面就可以组成一台对称多处理系统共享同一份内存视图。对于Agent这种需要频繁访问共享状态的负载来说这种一致性设计能极大降低软件的复杂度。到了机群层面4096个节点靠什么握手无外乎高速网络和分布式软件栈。硬件上提供高速SerDes、支持RoCE和分布式存储协议软件上可以叠加Kubernetes、Ray这样的生态组件。鲲鹏起家的优势在于它完整支持ARMv8.2指令集这意味着主流的、针对ARM优化的推理框架和运行时都能直接跑不用像以前那样大改代码。生态顺手横向扩展才有现实意义。2.3 单节点能干什么我给Agent负载做的最小区分单元聊硬件参数容易虚我给一个可以落地参考的单节点基准单元一台双路鲲鹏920服务器配备128物理核、512GB内存、一块高性能NVMe阵列跑CPU版本的推理后端比如llama.cpp或者支持ARM的ONNX Runtime加上容器化部署环境。这台机器能扛什么量级按我压测的经验如果是7B量化模型稳定并发在250到400路之间如果换成13B模型并发减半但轮询和工具调用的体验依然在线。关键是它可以作为一个非常干净的扩容单元——把这样的节点从1台加到64台就能形成一个小型分区再加到4096台就是一套完整的Agent超级计算机。鲲鹏整个4096节点的路线本质上就是把这种单节点能力通过高速网络和平滑调度变成了一个统一的资源池。3. 4096节点集群真正难的不是买机器而是这几件事3.1 网络分区与拓扑规划不能让4096个节点互相广播把4096台服务器摆在一起第一件事不是装系统而是规划网络拓扑。如果所有节点都在一个广播域里光ARP请求和路由抖动就能让网络先瘫掉。我的做法是分区分舱把4096个节点按一定规律切成若干分区每个分区内部采用较为紧密的汇聚拓扑分区之间通过核心交换机走L3路由。拿我常用的设计来说以64个节点为一个Pod这里借用了容器里的概念但指的硬件舱段每个Pod内部做到万兆甚至更高速率的互联Pod与Pod之间通过Spine-Leaf结构连通。这样做有三个好处故障爆发半径被限制在Pod内调度器可以优先在同Pod内分配相近任务网络拥塞控制的范围可控。4096节点的集群真正跑起来不是把所有机器当一盘棋而是把几十个Pod非常协调地拼成棋盘。3.2 两级调度全局大脑和分区大脑怎么分工节点多了调度是最大的脑力活。一个全局调度器直面几千个节点不仅要处理资源匹配还要应对不断发生的Pod调度、任务伸缩和故障迁移单点大脑必然成为瓶颈和单点故障源。我的经验是做两级调度。全局调度器只管到Pod这一层把一批Agent任务Batch下发到哪个Pod、这批任务对总核数和总内存的期望是多少。Pod内部的调度器再去做细活把任务分到具体节点、具体核、处理NUMA亲和性。这样全局大脑只处理分钟级别的总量决策压力极小分区大脑负责秒级甚至毫秒级的任务排布效率极高。层与层之间通过消息队列异步通信不阻塞不回调Agent任务推到哪一层都能落位。3.3 状态管理Agent一崩溃任务不能丢Agent任务和普通无状态微服务的最大区别就是它有状态。一个Agent会话运行到第五轮已经产生了规划链、已调用的工具结果和累积的上下文这时候如果承载它的节点宕了任务就断了。4096节点的集群里节点宕机不是如果而是什么时候的问题所以状态管理必须从第一天就设计进去。我采用的方法是三层状态落盘第一层是会话级检查点每轮关键工具调用后把Agent状态快照到分布式对象存储第二层是KV Cache的持久化策略对长会话做增量存储第三层是任务级重放机制如果节点故障调度器从检查点拉起任务让Agent从上一步继续跑而不是从头再来。这套机制写起来不复杂但能救命——当某个Pod出现大规模断电场景时其他Pod能自动接管用户无感知。3.4 故障域与滚动升级2000个进程同时重启的场景4096节点的运维难点在变更管理。很多人以为重启是一个简单的命令但在几千台机器上一个命令下去可能引发2000个Agent进程同时重新连接控制面这把控制面打挂的事情我亲眼见过。应对办法是分批滚动和故障域隔离。任何批量操作都按Pod粒度分波次执行每波次控制在总规模的5%以内做完一波观察指标恢复再继续。同时要保证同一个Agent任务的职责线程和备份线程落在不同的故障域里这样就算一个Pod全挂任务也能由其他域接住。这里的核心原则是变更速度永远服从于监控反馈速度宁可慢一点不能出一锅端的事故。3.5 软硬件成本账CPU集群为什么在这个规模下划算到了这个规模不谈钱是不现实的。算一笔简单的账同样支持1万路Agent在线会话的方案GPU方案需要多少张卡如果是100张H系列级别的大卡单卡显存按80GB算总共8TB显存而CPU方案需要多少内存按每路会话平均占用1GB计算1万路需要10TB内存分摊到512GB内存节点的CPU集群也就是20台节点。当然GPU方案也带CPU和内存但整体采购和运维成本高出一个数量级。更重要的运营成本是利用率GPU集群的闲置浪费是刚性的而CPU集群的算力天然适合做高密度容器化混部——白天跑Agent在线任务低峰期还能把空闲算力调给离线数据分析、代码构建、日志处理。说实话这种一鸡多吃的灵活性让CPU方案在财务模型和资源效率上都很能打。4. 从1台到4096台一套可以照着做的落地路径4.1 第一步单节点压测把基线钉死别一上来就规划4096节点的大盘子先把单节点的性能基线钉死。我在评估一个新集群方案时会先在单台鲲鹏节点上做三组压测第一组是小模型短文本推理测吞吐上限第二组是模拟Agent多轮对话的混合负载测内存和调度稳定性第三组是故障演练相关的前置测试比如杀掉几个推理进程看并发下降的斜率。为什么要先做单节点因为单节点的能力边界决定了整个集群的资源冗余策略。比如我测得单机7B模型稳定扛350路并发那规划4096节点时就可以按平均200路并发的安全水位去预估容量——留出50%以上的冗余给突发流量和故障转移腾出空间而不是把4096节点的纸面理论值算满。4.2 第二步分区建集群复现局部故障单节点验证通过后先建一个64节点的Pod把真正的Agent业务跑起来然后刻意制造故障断网、断电、杀进程、模拟节点卡死。这个阶段的目的是验证之前设计的故障转移逻辑是否真的生效。我特别推荐做两次混乱测试第一次在业务低峰期第二次在压测高峰期。高峰期故障才是真正的考验——当300路并发正在Pod里跑着你突然摘掉1个节点这个节点的会话能不能被其他节点秒级接管调度队列会不会雪崩状态检查点会不会丢失。这些问题在64节点上暴露得越早在4096节点上就越安全。4.3 第三步统一控制和观测面节点规模上来以后最容易出问题的不是机器而是看不见。4096个节点意味着上万个容器进程靠SSH到每台机器上查日志那是原始人干法。必须有一套统一的控制面和观测面。控制面我用的是Kubernetes加私有镜像仓库配合多租户的配额管理观测面则统一了指标、日志、链路追踪三件套。Agent场景有一个非常实用的观测指标——链路存活率即一个Agent任务从调度开始到完整跑完的生命周期成功率。这个指标能同时反映网络、调度、模型推理、状态存储的健康度比单看CPU利用率强得多。4.4 一组经过调优的参考配置我把在鲲鹏集群上跑Agent负载时验证过的一些关键配置列出来供参考# 内核参数针对高并发短连接优化 vm.swappiness 10 net.core.rmem_max 67108864 net.core.wmem_max 67108864 net.ipv4.tcp_fin_timeout 30 net.ipv4.tcp_tw_reuse 1 net.ipv4.ip_local_port_range 1024 65535 fs.file-max 2097152容器侧建议给每个Agent推理容器设置明确的CPU限额和内存上限。CPU限额按核分配内存预留1.5倍于模型权重加预估KV Cache的大小避免OOM。调度上开启CPU绑核把进程固定在物理核心上尽量避免跨NUMA访问内存。5. 不是所有Agent任务都该上CPU两套负载的分工逻辑5.1 划分标杆上下文多长、生成多大、实时性多强聊到这里必须泼一盆冷水CPU集群不是万能的别把所有的Agent任务都无脑往CPU上堆。我的划分标准有三个维度上下文长度、单次生成规模、实时性要求。CPU集群适合的画像很清晰上下文在8K以下、单轮生成不超过500个Token、对首Token时延要求不那么苛刻的任务比如意图识别、工具编排、简单的总结归类。这些任务占了Agent场景的大头用CPU性价比最高。而长文档分析、复杂代码生成、超大上下文多跳推理这类任务模型规模大、生成序列长、对时延敏感CPU的算力劣势就会暴露出来该上GPU就不要犹豫。5.2 推荐混合架构CPU集群扛大并发GPU集群处理重计算我在实际项目中跑通并推荐的架构是CPU为主、GPU为辅的混合编排用户请求先打到统一的API网关上网关根据请求的复杂度和上下文长度做路由分发。轻量级规划任务进入CPU集群用7B或13B模型快速响应重度的复杂推理请求转发给GPU小集群由大模型负责产出高质量结果。这套混合架构在两边的负载都不会浪费CPU集群负责把并发盘子撑大GPU集群负责把单请求的质量和深度做好。它们之间通过异步消息队列连接GPU返回结果后再由CPU上的编排器整合。4096节点的CPU航母编队加上一小簇GPU精锐突击队比单纯堆任何一种硬件都划算也更贴合Agent的真实工作形态。6. 我踩过的坑写下来帮大家省时间6.1 NUMA绑核和不绑核性能差一半第一个踩的坑就是NUMA。跑的推理服务时发现随机出现一些节点性能骤降排查了半天最后发现是没绑NUMA导致的线程跨内存节点访问。多路服务器的CPU核分布在两个物理处理器上各自挂着独立的内存控制器。线程在两个处理器之间飘来飘去内存访问就要跨节点带宽直接砍半。解决方式很直接把推理线程组固定在一个NUMA节点内让它访问自己的本地内存。容器编排工具里设置CPU亲和性策略或者直接用numactl绑核。这里注意不是绑一个核而是要绑一组核绑对应内存两件事一起做才算数。做完之后实测性能恢复同样配置下吞吐提升了45%以上。6.2 超线程、OOM和内存水位第二个坑和超线程有关。Agent推理是典型的计算和内存混合负载超线程在这样的负载下不仅不加速反而因为两个线程共享执行单元和一级缓存形成了资源竞争。我们压测时发现开启超线程后整机吞吐反而下降8%到12%。后来的经验是对Agent推理节点建议在BIOS层关闭超线程多出来的核数不值得为了纸面好看而牺牲实际性能。内存水位也是大坑。Agent的KV Cache是动态增长的多个Agent共享一台节点时如果不做内存水位监控就会出现某个长会话把节点内存吃满然后OOM Killer随机杀进程的情况。现在的做法是给每个会话记录内存增长曲线设定硬上限超限时主动触发会话压缩或迁移而不是等系统被动杀进程。6.3 网络参数的细节会吞掉你的并发网络调优的坑更隐蔽。Agent服务很多是短连接形态一下涌进来几千路请求时常规内核参数很容易把端口和TIME_WAIT耗光。我上面给的net.ipv4.ip_local_port_range和tcp_tw_reuse参数就是因为踩了坑才沉淀下来的。另外如果是RoCE这类高速网络环境一定要确认网络设备的ECN和PFC机制是打开的否则当网络出现瞬时拥塞时丢包会导致推理请求集体超时重试雪崩就是这么来的。网络参数的测试不能只在实验室里做要放到4096节点真实跑流量的场景里去验证。6.4 操作习惯批量变更之前先看监控最后一个建议是操作习惯层面的。4096节点集群的每一次批量变更都要当成一次手术来做——先看全景监控、再看分区健康、然后小批量试变更、最后全量推进。不要相信自己在小集群里验证过的脚本在上万容器规模的集群里也一定听话实际执行中总会遇到版本不一致、部分节点硬件亚健康之类的意外。我自己定的规矩是任何批量操作分三个波次每波次执行完必须核对四类指标任务成功率、平均时延、错误码分布、节点心跳异常数。四项全绿才允许继续下一波。遇到任何一项指标波动立刻停止变更先定位明白再说。这个习惯在4096节点的规模下救过我很多次算是这些项目里最值钱的一条经验。算下来CPU在Agent场景的这个回潮本质上是负载形态变了之后硬件价值的一次重新定价。Agent让算力需求从集中式训练转向分布式在线服务而鲲鹏这样的大规模CPU集群恰好把成本、并发和扩展性几个维度同时拉满了。我这套从单节点到多级调度再到混合编排的思路也是一路踩坑踩出来的分享出来供大家在规划自己Agent基础设施时参考。