1. 从模型竞赛到智能体竞赛基础设施的叙事变了2026年开年到现在我接触了不下二十个做智能体落地的团队从几个人的创业小队到上千人的企业级AI平台组大家聊的话题跟两年前完全不是一回事。2024年那会儿所有人都在比谁的模型参数大、谁的榜单分数高到了2025年下半年风向彻底转了——大家开始比谁的智能体能稳定跑完一个长链路任务、谁的推理成本能压到每千次调用几毛钱、谁的系统在高峰期不崩。这个转变听起来像是应用层的事但真正卡脖子的地方全在基础设施上。我写这份东西的出发点很简单市面上讲智能体应用的文章铺天盖地讲怎么搭一个客服智能体怎么用框架做一个RAG流程的教程一抓一大把但很少有人把智能体对底层算力、调度、存储、网络的要求讲清楚。很多团队在Demo阶段跑得好好的一上生产就出问题——延迟抖动、成本失控、任务中途失败无法恢复、多智能体协作时状态丢失。这些问题的根因八成不在智能体框架本身而在基础设施没有为智能体的工作负载特征做适配。这篇内容适合三类人看一是正在做智能体产品、被成本和稳定性折磨的工程负责人二是负责AI平台建设、需要做技术选型和容量规划的基础设施工程师三是对智能体技术栈感兴趣、想搞清楚除了调API之外还需要什么的开发者。我会尽量把原理讲透同时给出可以直接参考的配置思路和踩坑经验。全文基于我自己的实践观察和行业公开信息整理涉及具体参数的地方会说明推算逻辑你根据自己团队的情况调整。2. 智能体到底给基础设施出了什么难题2.1 从一问一答到多步规划负载特征的根本变化传统的大模型推理服务负载特征相对简单用户发一个请求模型生成一段回复请求结束。这种模式下的优化目标很明确——提高吞吐、降低单次延迟、把GPU利用率拉满。批处理batching技术在这里非常有效因为请求之间相互独立可以攒一批一起算。智能体完全不是这个逻辑。一个典型的智能体任务比如帮我分析这份销售数据并生成周报它内部会拆成好几个步骤先理解任务、再规划子步骤、然后调用工具读文件、查数据库、跑计算、接着根据中间结果调整计划、最后汇总输出。每一步都是一次甚至多次模型调用而且步骤之间有严格的依赖关系——第二步的输入依赖第一步的输出你没法把不同步骤的请求攒在一起批处理。这就带来一个很现实的问题GPU利用率上不去。我见过一个团队他们的智能体服务在业务高峰期GPU利用率只有15%左右大部分时间GPU在等——等上一步的模型输出、等工具调用返回、等网络传输。这跟传统推理服务动辄70%以上的利用率完全没法比。你花大价钱买的算力大部分时间在空转。2.2 长尾延迟平均值骗人P99才是真相智能体任务的另一个特征是延迟分布极其不均匀。简单任务可能两三次模型调用就结束了几百毫秒搞定复杂任务可能涉及几十次调用、多次工具交互、甚至需要重试耗时几十秒甚至几分钟。如果你只看平均延迟会觉得系统表现还不错但用户体验是由P99决定的——那1%的慢请求会让用户觉得这东西时好时坏。更麻烦的是智能体的延迟不是简单叠加。因为步骤之间有依赖任何一步的延迟波动都会向后传导并放大。第一步多花了200毫秒可能导致后续的规划路径变化进而触发更多的工具调用最终延迟翻好几倍。这种延迟放大效应在传统推理服务里是不存在的。2.3 状态管理智能体不是无状态的传统推理服务基本可以当作无状态来处理——每个请求独立不需要保存上下文。智能体不行。一个长任务执行到一半中间状态已经完成了哪些步骤、当前在哪个分支、积累了哪些中间结果必须被可靠地保存下来。否则一旦某个环节失败整个任务就得从头再来成本直接翻倍。这就对存储层提出了新要求需要低延迟的状态读写每次步骤切换都要更新状态、需要支持事务性保证状态和实际执行进度一致、需要能快速恢复故障后能从最近的检查点继续。很多团队一开始用Redis存状态跑着跑着发现内存不够了或者持久化配置没做好宕机后状态全丢只能重跑。2.4 多智能体协作通信成了瓶颈当多个智能体需要协作完成一个任务时它们之间的通信开销会迅速上升。我实测过一个场景五个智能体协作完成一份市场分析报告每个智能体负责一个维度它们需要频繁交换中间结论、协调分工、解决冲突。在通信没有优化的情况下智能体之间的消息传递占用了整个任务30%以上的时间。这跟微服务架构早期遇到的问题很像——服务拆得越细网络通信开销越大。智能体协作也面临同样的权衡拆得越细单个智能体的职责越清晰但协调成本越高。基础设施需要提供高效的通信机制比如共享内存、消息队列、或者专门的状态同步服务。3. 算力层GPU不是唯一答案CPU正在回归3.1 智能体工作负载的算力构成分析很多人一提到AI基础设施就只想到GPU但智能体的算力需求比纯模型推理要复杂得多。我把一个典型智能体任务的算力消耗拆开来看环节主要算力类型占比经验值特征模型推理规划、生成GPU50%-70%突发性强对显存带宽敏感工具调用计算、检索CPU15%-30%持续性强对单核性能敏感状态管理读写、序列化CPU 内存5%-10%低延迟要求对内存带宽敏感通信与协调CPU 网络5%-15%多智能体场景下占比显著上升这个表说明一个关键问题CPU在智能体基础设施中的角色被严重低估了。工具调用、状态管理、通信协调这些环节全部跑在CPU上而且它们往往是延迟的主要来源。我见过一个团队GPU配置拉满但工具调用的响应时间占了整个任务耗时的40%因为他们的CPU单核性能不够Python工具函数的执行效率很低。3.2 GPU选型不要只看算力TOPS选GPU的时候很多人第一眼就看算力TOPS排行觉得数字越大越好。但智能体场景下有几个指标比峰值算力更重要显存容量和带宽。智能体任务经常需要处理长上下文——规划过程可能产生很长的思维链工具返回的结果可能很大。显存不够要么截断上下文影响效果要么频繁换入换出影响延迟。我建议做智能体服务的GPU显存至少48GB起步最好80GB。带宽方面HBM的带宽直接决定了模型推理的速度这个比算力TOPS更能反映实际体验。互联能力。如果你需要跑多卡推理或者多智能体共享模型GPU之间的互联带宽就很关键。NVLink和PCIe的差距在实际使用中非常明显。我实测过一个7B模型的多卡推理场景NVLink互联的吞吐比PCIe高了将近一倍。虚拟化和切分支持。智能体服务往往需要把GPU切分给多个任务使用或者做细粒度的资源隔离。支持MIG多实例GPU的卡在这方面有天然优势可以把一张卡切成多个独立实例每个实例跑不同的智能体任务互不干扰。3.3 CPU的回归为什么我开始重视单核性能前面说了智能体的很多环节跑在CPU上。这些环节的特点是单个任务的计算量不大但对延迟极其敏感。比如状态读写一次可能就几KB的数据但要求微秒级完成工具调用可能就是一个简单的数据转换但要求毫秒级返回。这种场景下CPU的单核性能比核心数更重要。我做过对比测试同样是用32核的服务器单核性能高的那台智能体任务的平均延迟低了25%以上。因为很多操作是串行的核心再多也帮不上忙单核快才是真的快。具体选型上我目前比较推荐的是高主频的服务器CPU基础频率3.5GHz以上睿频能到4.5GHz以上的型号。核心数32到64核足够再多的话除非你跑大量并行的工具调用否则收益递减。内存方面建议至少256GB起步因为状态管理和缓存很吃内存。注意不要用消费级CPU做智能体服务端。消费级CPU缺少ECC内存支持、PCIe通道数少、长时间高负载下稳定性差。我见过用桌面级平台跑生产服务跑了三个月后频繁出现莫名其妙的错误查了半天发现是内存位翻转导致的。3.4 算力租用vs自建一笔需要算清楚的账2026年这个时间点算力租用和自建的性价比对比跟两年前很不一样了。我帮几个团队算过账结论是中小规模日均推理调用低于50万次租用更划算大规模自建更可控。租用的优势在于弹性——业务高峰期临时扩容低谷期释放不用为闲置算力买单。但租用的问题也很明显网络延迟不可控、数据安全需要额外考虑、长期成本可能超过自建。我见过一个团队租了半年GPU算下来花的钱够买两台同配置的服务器了。自建的优势是可控性和长期成本。但自建的门槛不只是买硬件——你需要机房、电力、散热、运维人员。这些隐性成本很容易被低估。我的建议是如果你没有专门的运维团队或者业务量波动很大优先考虑租用如果你有稳定的负载和运维能力自建在18个月以上的周期内通常更划算。4. 调度与编排让智能体跑得稳比跑得快更难4.1 为什么传统调度器搞不定智能体Kubernetes是现在最主流的容器调度平台但它的调度逻辑是为无状态微服务设计的——按CPU和内存的请求量来分配Pod假设每个请求独立且可互换。智能体任务不满足这个假设。首先智能体任务是有状态的调度器需要知道哪个节点上有这个任务的状态数据尽量把任务调度到同一个节点或者能快速访问状态的节点。其次智能体任务的资源需求是动态变化的——规划阶段吃GPU工具调用阶段吃CPU状态同步阶段吃网络。静态的资源请求配置要么浪费资源要么导致任务被限流。第三智能体任务有优先级和依赖关系一个任务的输出可能是另一个任务的输入调度器需要理解这些依赖。我目前的实践是在Kubernetes之上加一层智能体感知的调度层。这一层负责维护任务的状态映射、动态调整资源配额、处理任务间的依赖关系。Kubernetes只负责底层的容器编排和资源隔离。4.2 状态检查点智能体容错的核心机制智能体任务跑一半失败了怎么办最简单的做法是重跑但成本太高。更好的做法是定期保存状态检查点失败后从最近的检查点恢复。检查点的设计有几个关键决策保存频率。保存太频繁开销大保存太少恢复时重跑的工作量大。我的经验是在每个不可逆步骤之后保存。什么叫不可逆步骤就是那些执行了就有副作用、重跑代价很高的步骤比如发送了邮件、写入了数据库、调用了付费API。对于纯计算步骤可以不保存失败了重算就行。保存内容。不是所有状态都需要保存。我通常只保存三类数据任务执行到哪一步了进度指针、已经产生的关键中间结果、以及后续步骤需要的上下文。那些可以从中间结果重新推导出来的数据不用保存。存储选型。检查点数据的特点是写入频繁、读取较少只在恢复时读、对延迟敏感。我目前用的是Redis加持久化后端热数据在Redis里定期刷到对象存储。这样恢复时先从Redis读读不到再从对象存储加载。4.3 多智能体通信共享内存比消息队列快在哪多智能体协作时通信机制的选择直接影响整体性能。我对比过三种方案消息队列如Kafka、RabbitMQ。优点是解耦彻底、可靠性高、支持异步。缺点是延迟高——消息从发送到被消费通常有几十毫秒的开销。对于需要频繁交互的智能体协作这个延迟累积起来很可观。RPC调用。优点是实时性好、编程模型简单。缺点是耦合度高、需要处理服务发现问题、同步调用容易阻塞。共享内存/共享状态。优点是延迟极低微秒级、编程模型简单直接读写。缺点是需要处理并发控制、不适合跨节点。我的实践结论是同节点内的智能体协作用共享内存跨节点的协作用消息队列。具体来说我会把需要频繁交互的智能体尽量调度到同一个节点它们之间通过共享内存通信跨节点的通信走消息队列接受一定的延迟换取可靠性。4.4 一个真实的调度踩坑案例去年我帮一个团队排查智能体服务不稳定的问题。现象是平时跑得好好的一到下午业务高峰期就频繁出现任务超时。他们一开始怀疑是GPU不够准备加卡。我让他们先别急着买硬件把监控数据拉出来看。看了数据发现几个问题第一GPU利用率在高峰期反而下降了从40%掉到20%——说明瓶颈不在GPU。第二CPU的等待I/O时间飙升从5%涨到35%——说明存储层扛不住了。第三网络重传率上升——说明节点间通信有问题。进一步排查发现他们的状态存储用的是单节点Redis没有做集群。高峰期大量智能体任务同时读写状态单节点Redis的CPU跑满了导致所有状态操作排队。状态操作一慢智能体任务就卡住GPU就闲着。解决方案分三步第一把Redis换成集群模式状态数据分片存储第二给状态读写加了本地缓存减少对Redis的直接访问第三把智能体任务按状态访问模式分组同一组的任务尽量调度到同一节点提高缓存命中率。改完之后高峰期GPU利用率回到了45%以上任务超时率从8%降到了0.5%以下。这个案例的教训是智能体服务的瓶颈往往不在你最关注的地方。GPU不够只是表象真正的问题可能在存储、在网络、在调度策略。排查的时候要从全局看不要只盯着一个指标。5. 存储与内存被忽视的性能杀手5.1 智能体对存储的三个核心需求智能体的存储需求跟传统应用很不一样我总结为三个核心需求低延迟。智能体在每一步操作前后都可能需要读写状态这些读写操作直接叠加在任务延迟上。如果每次状态读写要花10毫秒一个50步的任务就要多花1秒。所以状态存储的P99延迟要控制在毫秒级以内。高并发。一个智能体服务可能同时跑着成百上千个任务每个任务都在频繁读写状态。存储层要能扛住这种并发压力不能成为瓶颈。强一致。状态数据不能丢、不能错。如果状态和实际执行进度不一致恢复时就会出问题——要么重复执行已经完成的步骤要么跳过未完成的步骤。这两种情况都会导致任务失败或结果错误。5.2 内存数据库的选型对比我实际用过的几种状态存储方案对比如下方案延迟并发能力持久化适用场景Redis单节点亚毫秒中等可选小规模、开发测试Redis集群亚毫秒高可选中等规模生产内存网格如Hazelcast微秒级高支持大规模、低延迟要求本地内存定期快照纳秒级受限于单机快照单节点、可容忍少量丢失分布式KV如etcd毫秒级中等强配置管理、元数据我的建议是中小规模用Redis集群大规模且延迟敏感的场景考虑内存网格。本地内存加定期快照的方案适合对成本敏感、能容忍少量状态丢失的场景但不适合核心业务。5.3 上下文缓存省算力的关键手段智能体任务中很多模型调用是重复的或者高度相似的。比如规划阶段不同的任务可能产生相似的规划请求工具调用阶段相同的工具可能被不同的任务调用。如果每次都重新推理算力浪费很严重。上下文缓存也叫提示缓存、KV缓存是解决这个问题的关键手段。原理很简单把模型推理过程中产生的中间状态Key-Value对缓存起来下次遇到相同或相似的输入时直接复用不用重新计算。实测下来合理使用上下文缓存可以把模型推理的算力消耗降低30%到60%具体取决于任务的重复度。实现上我目前用的是两级缓存本地GPU显存缓存最近使用的KV对主机内存缓存更大范围的KV对。缓存命中时直接从显存或内存读取不用重新跑模型。提示上下文缓存的命中率高度依赖输入的相似度。如果你的智能体每次的输入差异很大缓存效果会很有限。这种情况下可以考虑对输入做归一化处理或者用语义相似度来匹配缓存。5.4 存储层的常见坑与规避方法坑一用对象存储做状态存储。对象存储如S3兼容的存储延迟在几十到几百毫秒完全不适合做智能体状态存储。我见过有团队图省事把状态直接写到对象存储结果任务延迟高得没法用。坑二忽略序列化开销。状态数据需要序列化后才能存储反序列化后才能使用。如果序列化格式选得不好比如用JSON存大对象序列化和反序列化的开销可能比存储本身还大。建议用高效的二进制格式比如Protobuf、MessagePack或者FlatBuffers。坑三没有做状态压缩。智能体的状态数据可能很大尤其是积累了多轮对话历史或者大量中间结果的情况下。不做压缩存储成本和网络传输成本都会很高。我通常会用zstd做压缩压缩比和速度比较平衡。坑四状态过期策略缺失。智能体任务完成后状态数据应该被清理否则存储会无限增长。但清理策略要小心设计——太激进可能误删还在用的状态太保守则存储成本失控。我的做法是给每个状态打上任务ID和过期时间任务完成后延迟一段时间再清理留出排查问题的时间窗口。6. 工程实践从Demo到生产的鸿沟怎么跨6.1 可观测性没有监控就是盲人摸象智能体服务的可观测性比传统服务复杂得多。传统服务看QPS、延迟、错误率就够了智能体服务还需要看每个任务的步骤数分布、每步的耗时分布、工具调用的成功率、状态读写的延迟、缓存命中率、GPU利用率的时间序列。我目前用的监控栈是Prometheus加Grafana配合OpenTelemetry做链路追踪。关键是要给每个智能体任务打上完整的标签任务类型、优先级、使用的模型、涉及的智能体数量。这样出问题的时候可以快速定位是某一类任务的问题还是全局问题。链路追踪尤其重要。一个智能体任务涉及多次模型调用、多次工具调用、多次状态读写没有链路追踪的话你根本不知道时间花在哪了。我通常会在每个步骤的开始和结束打点记录步骤名称、耗时、输入输出的大小。这些数据积累起来就能看出哪些步骤是瓶颈。6.2 成本控制每一分钱都要花在刀刃上智能体的成本控制是个系统工程。我从几个维度入手模型选择。不是所有步骤都需要用最大的模型。规划步骤可以用大模型保证质量简单的工具调用参数生成可以用小模型。我实测过把部分步骤换成小模型后整体成本降低了40%效果下降不到5%。缓存策略。前面说的上下文缓存是省算力的大头。除此之外工具调用的结果也可以缓存——相同的工具调用参数直接返回缓存结果不用重新执行。批处理。虽然智能体的步骤之间有依赖不好做批处理但有些场景是可以批的。比如多个智能体同时需要调用同一个工具可以把这些调用攒起来一起执行。或者多个任务的规划步骤可以合并成一个批次推理。资源回收。智能体任务完成后要及时释放占用的GPU、内存、连接等资源。我见过有团队忘记释放GPU显存跑了几十个任务后显存耗尽新任务全部失败。6.3 灰度发布与回滚智能体版本管理的特殊性智能体的版本管理比传统软件复杂。传统软件升级新旧版本的行为差异是确定的智能体升级行为差异可能是不确定的——换了模型、改了提示词、调整了工具集都可能导致输出风格和质量的显著变化。我的做法是每次变更都做灰度发布先放1%的流量观察关键指标任务成功率、平均步骤数、用户满意度没有异常后再逐步扩大。同时保留快速回滚的能力——一旦发现问题能在分钟级切回旧版本。回滚的时候要注意状态兼容性。如果新版本改变了状态的数据结构回滚后旧版本可能读不懂新版本写的状态。解决方案是状态数据结构做版本标记新旧版本都能识别并处理对方的格式或者升级时做状态迁移把旧格式转成新格式。6.4 安全与隔离多租户场景下的必答题如果智能体服务面向多个租户比如企业内部的不同部门或者SaaS产品的不同客户安全隔离就是必须解决的问题。隔离的维度包括计算隔离不同租户的任务不能互相干扰、数据隔离租户A不能访问租户B的状态和数据、网络隔离租户间的通信要受控。计算隔离我通常用容器加cgroup来实现给每个租户分配独立的资源配额。数据隔离靠命名空间和访问控制每个租户的状态数据打上租户ID访问时校验。网络隔离用网络策略默认拒绝跨租户的通信只开放必要的接口。还有一个容易被忽视的点工具调用的权限控制。智能体可以调用各种工具但不同租户能调用的工具应该不同。比如租户A只能读数据库租户B可以读写。这需要在工具调用层做权限校验不能只靠智能体自己判断。7. 2026年往后看几个值得关注的方向7.1 专用推理芯片的成熟度GPU目前是智能体推理的主力但专用推理芯片如各种NPU、ASIC正在快速成熟。这些芯片在特定模型架构上的能效比远高于GPU而且成本更低。我目前观察到的趋势是中小模型推理会逐渐向专用芯片迁移大模型和复杂推理仍然以GPU为主。对基础设施的影响是未来的算力池会是异构的——GPU、NPU、CPU混合部署。调度层需要理解不同芯片的能力和限制把合适的任务分配到合适的硬件上。这对调度器提出了更高要求。7.2 智能体原生的基础设施抽象现在的智能体基础设施很多是在传统云原生基础设施上打补丁。未来可能会出现智能体原生的基础设施抽象——把任务、状态、通信、算力这些概念直接作为一等公民来设计而不是用容器、Pod、Service这些传统概念来模拟。我期待看到的是声明式的智能体部署描述类似Kubernetes的YAML但描述的是智能体拓扑和依赖关系、内置的状态管理原语、智能体感知的自动扩缩容。这些能力目前需要自己拼装未来可能会成为平台的标准能力。7.3 边缘与云端的协同很多智能体场景对延迟极其敏感比如实时客服、工业控制、自动驾驶。这些场景下全部推理放在云端不现实——网络延迟就受不了。未来的架构会是边缘和云端协同轻量级的推理和决策在边缘完成复杂的规划和知识密集型任务在云端完成。这对基础设施的挑战是需要统一的管理平面来协调边缘和云端的资源需要高效的状态同步机制来保证边缘和云端的状态一致需要智能的任务分割策略来决定哪些步骤在边缘跑、哪些在云端跑。7.4 能效比成为核心指标随着智能体服务规模的扩大能耗成本在总成本中的占比越来越高。我算过一笔账一个中等规模的智能体服务电费加散热成本能占到总运营成本的20%到30%。未来选型的时候能效比每瓦特能处理的推理请求数会成为一个核心指标跟算力、延迟同等重要。这对芯片选型和数据中心设计都有影响。液冷、高密度部署、智能功耗管理这些技术会从可选变成必选。我目前看到的一些方案通过动态调整GPU频率和电压能在性能损失很小的情况下降低20%以上的功耗。8. 一些实操中攒下来的经验最后分享几条我在实际项目中攒下来的经验都是踩过坑之后总结的不一定对所有人都适用但至少能帮你少走点弯路。第一条先压测再上线压测要模拟真实的任务分布。很多团队压测的时候用均匀的请求但真实场景下任务复杂度差异很大。压测要覆盖简单任务、中等任务、复杂任务的比例还要模拟任务失败和重试的情况。我见过压测通过但上线就崩的案例就是因为压测没有覆盖长尾任务。第二条状态存储的容量规划要留足余量。智能体状态数据的大小很难精确预估因为任务复杂度不确定。我的经验是按平均任务状态大小的3到5倍来规划容量留出应对突发情况的余量。同时设置告警容量用到70%就开始关注80%就要准备扩容。第三条不要迷信单一指标。GPU利用率高不代表系统健康可能是任务排队导致的延迟低不代表体验好可能是任务被截断了。要看一组指标的组合利用率、延迟分布、成功率、成本。任何一个指标异常都要深入排查。第四条定期做故障演练。智能体服务的故障模式很复杂光靠看监控发现不了所有问题。我建议定期做故障演练手动杀掉某个节点、模拟网络分区、注入存储延迟看系统能不能自动恢复。演练中暴露的问题比生产环境出问题再排查要划算得多。第五条文档和配置要版本化。智能体服务的配置项很多——模型版本、提示词、工具集、调度策略、缓存配置。这些配置的变更要跟代码一样做版本管理每次变更记录清楚改了什么、为什么改、效果如何。否则出了问题根本不知道是哪个变更导致的。这些经验听起来都是常识但真正做起来会发现坚持执行比知道要执行难得多。我自己的团队也是在踩了几次大坑之后才把这些流程固化下来的。希望这些内容对你有用也欢迎交流你在智能体基础设施实践中遇到的问题和解决方案。