前阵子我们内部有个现象特别能说明问题一个分析型智能体Agent凌晨跑批调度器报告“GPU 用量异常飙升”几个正在训练的作业全被挤出去了。查日志才发现那个 Agent 只是把“写一份经营异常分析”拆成了二十多个子任务每个子任务又各自触发了好几次模型推理一个晚上烧掉的 token 比我们全组白天一周的对话量还多。这其实不是个例。未来 AI 智能体的发展方向很大程度上不是模型能力本身而是算力架构能不能接住 Agent 这种“没完没了调用模型”的消耗方式。作为架构师我认为当前最绕不开的是两大算力挑战一类是长程推理带来的“推理时计算”爆发另一类是上下文与记忆系统造成的存储和算力瓶颈。这篇文章就从这两个挑战展开谈谈它们的成因、具体表现以及我在工程实践里验证过的一些应对思路希望能给正在做 Agent 应用或推理服务的团队一些参考。1. Agent 的算力账单变了从“一次生成”到“一条推理事务链”想理解算力挑战得先换个计量单位。过去我们做 LLM 应用容量规划基本是看 QPS、并发数、平均生成 token 数模型像一台“自动售货机”投一个请求吐一段文本。Agent 场景完全不是这样。1.1 一次任务等于几十次模型调用而不是一次一个带工具的 Agent 要完成用户目标大致会走这样的循环理解用户意图、拆解子任务、调用工具、观察工具返回结果、判断结果是否符合预期、决定继续行动还是重试、最后整理输出。其中好几个环节都要模型参与而且都可能不止一次。我参与过的某内部 Agent 框架做过一次统计一个中等级别的数据分析任务平均触发约 13 到 18 次模型推理。如果任务中途发生工具执行异常Agent 进入自我反思和纠错这个数字会直接翻倍。问题是每次纠错不是“重新生成一句话”而是把此前累积的上下文重新读一遍、重新计算注意力、再生成新的行动方案。这就像开餐厅过去客户点一份饭厨师炒一次菜就完事现在客户说要办一场宴席从菜单设计、采购、试菜到现场出餐每个环节都要厨师重新思考一遍。这个转变让容量规划完全变了。过去我们问“每秒能处理多少次对话”现在要问“每天要处理多少个完整任务每个任务平均触发多少步、每步调用多少次模型、平均消耗多少 token”。1.2 传统 QPS 模型失效任务级算力估算是新基准我自己常用的估算公式是单任务估算 Token 消耗 任务步骤数 × 每步平均模型调用次数 × 平均输入/输出 Token 量我拿一个真实场景套进去某复盘类 Agent 一个任务约 20 步每步平均触发 2 次模型调用每次调用平均消耗 800 token 的输出那么光是输出就有约 32000 token。再加上每次调用要把系统提示、工具描述、当前状态塞进输入输入侧的消耗通常是输出的好几倍。这样一个任务的真实 token 消耗很可能在 10 万量级相当于几十上百次普通聊天请求。那些没做过 Agent 算力评估就贸然上线的团队往往一周内就会收到推理服务的高额账单。下面这张表是我用来和团队沟通的对照建议先收藏再看后续内容。对比维度传统 LLM 应用Agent 应用计量单位请求次数、QPS任务数、总 Token、模型调用次数容量规划方式峰值并发 × 单次平均 token任务量 × 步骤数 × 每步调用次数 × token主要瓶颈推理吞吐、显存并发容量长程推理时延、上下文 KV 开销、记忆访问链监控重点响应时间、QPS、GPU 利用率Token 消耗、KV Cache 命中率、步骤时延、有效算力利用率失败代价单请求失败整条推理链回滚或重试算力成倍浪费一旦把视角切到“任务级”你就会发现传统监控里的 GPU 利用率根本不等于有效产出。很多 Agent 集群看起来忙忙碌碌实际上大量算力都花在反复试错、重复读取上下文和跨 Agent 通信上了。理解了这一点下面的两大挑战才真正有了讨论基础。2. 第一大算力挑战长程推理链引发的“推理时计算”爆炸现在业界讨论 Agent 能力时越来越看重“推理时计算”这个说法。它指的是模型在回答用户问题之前或期间进行的大量内部推理计算而不是训练阶段消耗的算力。Agent 让推理时计算从“锦上添花”变成了“日常刚需”。2.1 规划、反思、纠错每个决策都可能是完整推理周期先看 Agent 几种常见的高频推理模式。规划模式Agent 把大目标拆成子步骤生成一份行动计划。这一步本质上是一次复杂的结构化生成。反思模式Agent 在获得工具返回结果后需要判断结果是否满足子目标如果不满足要分析原因并生成新的方案。纠错模式工具抛异常、结果为空、验证不通过时Agent 要回到之前的某个决策点重新生成。这一步最贵因为它往往要求模型重新“进入”之前的上下文。以“纠错模式”为例。某代码生成 Agent 执行一个脚本时遇到报错它会带着报错信息回到模型请求重新生成修复代码。修复一次通常需要把之前的错误代码、报错信息、当前环境状态全部重新打包进上下文。如果修复两三次原始的代码逻辑已经被修改了好几版上下文长度还被拉长每次推理的 prefill 成本都在增加。这类算力消耗在传统问答场景里几乎不存在但在 Agent 场景里是常态。2.2 Token 量级从 K 跳到百 K水位线瞬间击穿我做过一次量化对比单轮问答的输入加输出通常在 1K token 左右一个带反思的 Agent 任务哪怕只是执行四五个工具调用也很容易到 20K 到 50K token如果任务本身冗余、失败重试多破百 K 并不罕见。假设一次 Agent 任务触发 50 次模型调用每次平均输入 3000 token、输出 800 token那它的总处理量就是 50 × 3800 190K token。和普通单轮对话相比规模扩大了约两个数量级。如果产品每天承接 1 万个这样的 Agent 任务日处理量将达到 19 亿 token。这个数字落到硬件上直接决定了你是需要几十张推理卡还是几百张推理卡。更要命的是上下文变长之后单位生成速度也会下降。注意力机制要对当前 token 与所有前缀 token 做计算序列越长每一步生成的耗时越大。也就是说Agent 任务不但在总量上消耗更多 token还在单步延迟上“变慢”。两条曲线叠加算力压力会比你直觉估算的更大。2.3 堆 GPU 救不了串行推理链有效算力利用率才是关键很多团队的第一反应是“不够就加卡”。但长程推理链是强串行的下一步推理依赖上一步的输出不能像训练那样简单并行。多买 GPU 只能提升并发任务的总吞吐但对单个 Agent 任务的端到端延迟帮助有限。我观察到一个很典型的“假饱和”现象GPU 利用率显示 80% 以上但任务完成率却不高。原因是大量 Agent 推理调用处于“等待外部工具响应”或“等待前序步骤完成”的状态期间 GPU 显存被上下文占着计算单元却没有满载。这就像一排出租车排队等客车占着车道但引擎没在跑。有效算力利用率这个指标比单纯的 GPU 利用率更能反映 Agent 场景的真实健康度。所以长程推理带来的挑战不是一个纯硬件堆叠问题而是一个计算调度和任务编排问题。它要求架构师把“一条推理链”当成一个整体来设计而不是只关心单个推理请求的快慢。3. 第二大算力挑战上下文与记忆系统正在拖垮显存和算力如果说长程推理考验的是“算得慢”那上下文与记忆系统考验的则是“装不下”。Agent 和普通问答最不一样的地方在于它永远要“记住”自己刚才做过什么、工具返回了什么、计划进行到哪一步。这套记忆系统正在成为新的算力瓶颈。3.1 KV Cache注意力机制自带的“内存放大器”Agent 每次推理都要带上大量上下文模型每处理一个新 token都需要把之前所有 token 的中间 Key 和 Value 缓存下来这就是 KV Cache。KV Cache 在推理过程中是常驻显存的它会随序列长度线性增长。具体有多大我习惯用一个简化公式来估算KV Cache 大小 ≈ 2 × 层数 × 隐藏层维度 × 序列长度 × 精度字节数拿一个约 7B 参数的模型举例假设 32 层、隐藏层维度 4096、FP16 精度、序列长度 32768那么单条请求的 KV Cache 大约为 2 × 32 × 4096 × 32768 × 2 字节约 16GB。而模型本身权重可能也就 14GB 左右。也就是说当 Agent 任务的上下文达到 32K 时一条请求就要占接近 30GB 显存一张 80GB 的卡也只能同时处理两三个请求。上下文一旦继续延长显存会迅速被打满能并发处理的 Agent 数量就直线下降。KV Cache 带来的另一个成本是重复计算。Agent 任务里系统提示、工具定义、历史记录常常会在一次任务的不同步骤中反复出现。如果推理引擎没有做前缀缓存每一遍都要把这些公共前缀重新计算一遍浪费十分惊人。3.2 长期记忆不是“查库”每次召回都可能触发二次推理Agent 要真正有用不能只靠当前对话还要依赖长期记忆用户的历史偏好、过往任务的结论、领域知识库的片段。很多团队的实现方式是把相关内容通过向量检索找出来然后拼进上下文。但问题在于检索结果不是“拿来就用”那么简单。首先是相关性判断。检索出来的片段往往有噪音Agent 需要让模型判断哪段和当前目标真正相关这本身就是一次推理调用。然后是记忆的整理融合几段来自不同时间、不同格式的记忆往往需要模型重新组织成对当前任务有用的形式又是一次推理。这些“暗推理”很容易被算力盘点忽略但它们真实存在而且会在任务中被反复触发。我倾向于把 Agent 的记忆分为三层工作记忆是当前任务的推理状态它最贵因为它一直占着显存情节记忆是历史任务的关键结论通常在需要时才召回语义记忆是稳定知识适合做外部索引和缓存。架构师必须明确每一层记忆的访问成本和更新频率不能一股脑把“记忆”全堆在上下文中。3.3 多 Agent 协作通信即推理共识即算力再往上走一步就是多 Agent 架构。多个 Agent 协作完成任务时彼此之间要交换信息、确认目标、同步状态。问题是 Agent 之间传递消息接收方通常不是“结构化读取”而是“让模型理解并决定下一步行动”这意味着每条消息都可能触发一次完整推理。我做过一个多 Agent 分工的原型效果确实惊艳但算力账单也很惊人。三个 Agent 完成一个任务信息传递可能产生超过任务本身两倍的额外推理调用。尤其在全局状态同步上Agent 之间对“现在进行到哪一步”的理解不一致时就会出现重复执行或相互纠正算力成本呈指数级放大。这个现象很像人在团队里开会讨论本身不直接产生产出但不开会又没法对齐而每次“对齐”都要花时间。Agent 的“开会”花的就是推理算力。目前多 Agent 协作的效率协议还没有统一标准架构师能做的就是尽量把高频通信改成结构化消息减少“模型阅读自然语言消息再决策”的次数但彻底解决仍然很难。4. 架构师的应对工具箱让算力花在刀刃上理解了两大挑战下面聊聊我验证过比较有效的工程手段。核心思路不是“取消 Agent 能力”而是把算力消耗结构化让每一分钱都花在能产生用户价值的推理上。4.1 混合推理架构便宜的快速路径加上昂贵的关键路径第一个性价比最高的手段是别让所有步骤都使用同一个“重量级”模型。Agent 的很多中间操作比如解析工具返回结果、判断字段是否合法、生成简单模板文本完全可以用轻量模型甚至规则模板完成。真正需要强大推理能力的是“关键决策点”任务规划、异常归因、最终结论。具体落地时我会在 Agent 框架里加一个“推理路由器”。路由器依据当前步骤的复杂度、风险、不确定性打分低风险步骤直接走快速路径高风险步骤才进入主打模型。我做过一次数据对比同样完成一组业务分析任务混合推理架构能把总推理 token 成本压到原来的 40% 到 60%而输出质量几乎没有可感知的下降。这个思路看似简单执行起来最大的阻力来自“惯性”很多团队嫌麻烦宁可所有步骤都调用同一个大模型。但在 Agent 场景下步骤数量是传统对话的几十倍每一小步的浪费都会被放大。4.2 上下文工程化摘要、压缩、前缀缓存第二块重点治理上下文。这里有几个层次优先级从高到低。共享前缀缓存系统提示、工具定义、常用的知识片段如果保持不变就让推理引擎缓存它们的 KV 计算结果。这样新一轮推理可以直接复用省去大量 prefill 计算。我强烈建议所有 Agent 服务都开这个能力。滚动摘要把任务早期的大量对话压缩成结构化摘要只保留最近 N 轮原文。这能有效控制 KV Cache 增长。代价是摘要本身需要一次模型调用但相比保留全部原文仍然划算得多。记忆卸载不常用的长期记忆放进外部存储等到真正需要时再召回。召回时可以先检索再决定是否注入而不是无条件全塞进上下文。我在某内部 Agent 项目中做过一次对比实验不优化时一次长周期任务的上下文峰值能到 40K token做了滚动摘要和前缀缓存之后上下文峰值降到 8K 左右平均每次推理耗时下降约三成。这还只是显存压力这一个维度还没有算成本降低。4.3 批处理与投机采样提升吞吐不等于取消能力Agent 任务内部是串行的但多个 Agent 任务之间是天然并行的。推理引擎的连续批处理能把不同任务的计算交织在一起填满 GPU 的计算单元。这是不改变 Agent 逻辑就能提升吞吐的主流手段。我还会关注投机采样这类思路。它让一个更小的模型先生成草稿再由大模型做一次并行验证。如果草稿质量高等于用更少的解码步骤得到同样输出。在 Agent 场景里很多决策其实比较“常规”小模型草稿被接受的概率不低所以收益可观。这里要提醒一句这些手段解决的是“单位 token 的成本”解决不了“总 token 越来越多”的问题。所以它们必须和预算治理配合使用。4.4 给 Agent 发工资算力预算、Trace 和可观测性算力挑战的隐性难点是它很难被感知。一个 Agent 任务完成之后如果没有任何账单架构师只能靠运气优化。我的建议是把每个 Agent 任务当作一个分布式事务来治理必须为它生成一个完整算力账单记录任务 ID、总 token 消耗、每一步模型调用的输入/输出 token 数记录 KV Cache 命中率、上下文峰值长度记录记忆检索次数、多 Agent 消息条数最后汇总为“有效 token 占比”也就是真正产生用户可见产出的 token 占总 token 之比。我给某分析 Agent 加装这套观测之后发现有一类“生成报表草稿”的步骤经常反复调用高成本模型做无谓的润色。把它切到快速路径后整体 token 直接降了 17%。没有账单这些浪费永远发现不了。5. 一组算力账两个挑战在真实任务中各占多少为了让你更直观地判断自己的系统卡在哪我构造一个典型的企业经营分析 Agent 任务来拆账。这个任务是用户上传上月经营数据自动生成异常诊断报告。5.1 任务拆解与算力分布经过 Agent 框架的记录这个任务大约发生 13 次直接模型调用包括理解用户需求1 次生成数据查询计划1 次分析 SQL 查询结果1 次发现异常后深入验证3 次生成诊断结论1 次生成报表草稿2 次质量自检2 次修正报告2 次。假设每次调用平均输入 6000 token、输出 700 token再考虑一次失败重试带来的额外开销总消耗约 90K token。注意这个过程中上下文峰值出现在“修正报告”阶段因为前边的分析结论、报表草稿都要保留。这套算力账单可以按类别拆成三份长程推理的部分主要是反复验证、反思、修正带来的多次模型调用约占四成上下文与记忆的部分主要是 KV Cache、历史摘要、报告片段反复进入提示约占三成半通信与状态管理的部分主要是工具返回结果处理、任务状态切换和一次纠错的回退约占两成半。成本类别典型来源本任务占比首要优化手段长程推理计算规划、反思、纠错、重试约 40%混合推理路由、失败重试上限上下文与记忆KV Cache、长提示、历史摘要约 35%前缀缓存、滚动摘要、上下文压缩通信与状态管理工具结果解析、状态切换、消息传递约 25%结构化消息、批量状态同步这份分布和我的经验高度一致Agent 任务消耗的大头从来不是“最后生成答案那一下”而是中间反复确认、反复纠错、反复搬运上下文的过程。5.2 你的系统会先撞上哪个墙拿上面这套框架去判断你自己的业务通常看两个问题任务步骤多不多上下文长不长如果步骤多、调用次数多你大概率先遇到长程推理时延问题。典型表现是任务执行时间很长但 GPU 算力又没有真正饱和。这种情况优先做推理路由和重试控制别让 Agent 无限纠错。如果工具定义多、历史记录多、上下文长度经常在 20K 以上那你大概率先遇到显存和 KV Cache 瓶颈。典型表现是单任务还能跑一开并发就 OOM。这种情况优先做前缀缓存、滚动摘要和记忆卸载。最怕的是两个问题叠在一起长链路加上长上下文。这种场景下的算力账是所有团队都不愿意算的我见过一次深度研究型任务把整张 80GB 显卡的显存吃光任务还只完成一半。遇到这种需求务必要在架构层面做任务分段把一个超长任务拆成几个上下文相对独立的子任务分段释放 KV Cache而不是让上下文无节制地堆叠。6. 实战中容易踩的三个坑最后分享几个我在 Agent 算力优化过程中踩过的坑希望你能提前绕开。6.1 把所有优化都寄托在“优化提示词”我曾见过一个团队花两周时间压缩提示词把系统提示从 3000 token 压到 800 token结果整个 Agent 的规划能力明显下降。Agent 的 prompt 在算力上不是“越多越浪费”而是能力与消耗的权衡。真正高性价比的优化路径是框架层的路由、缓存、预算控制而不是去逐字抠提示词。6.2 只算模型调用不算记忆和通信上线前的算力评估最容易漏掉三样东西记忆检索触发的额外推理、多 Agent 消息解析、工具结果反复进入上下文带来的 KV 成本。漏掉它们会导致严重的容量预估偏差。我的建议是上线前先在真实业务数据上做一次全链路 Trace把所有算力消耗分类归账再去做容量规划。6.3 单任务优化得很好一上并发就崩还有一类问题是“局部优化陷阱”。某个 Agent 任务单跑时延迟压得很低可一旦同时进来上百个任务因为每个任务都占用大量 KV Cache显存瞬间见底批处理也调不起来系统直接雪崩。Agent 场景的容量规划一定要强烈关注并发和上下文的总和而不仅仅是单任务成本。关于这一点一个比较务实的做法是在接入层做“Agent 准入控制”。给不同类型的任务设置算力预算和并发上限预算耗尽的任务排队等待而不是让它们无限抢占共享算力。这就像给集群上了一层保险优先级高的任务永远能有算力可用。最后说点个人倾向如果资源有限又必须快速见效优先做两件事。一是给推理服务打开共享前缀缓存让 Agent 任务里反复出现的系统提示和工具描述不再重复计算收益几乎是零成本。二是搭建混合推理路由把关键决策留给大模型把杂活交给小模型。这两件事做完你会发现 Agent 的算力压力会下降一个肉眼可感知的台阶。至于更深度的优化比如多级记忆系统和多 Agent 通信协议标准化就等你先完成这两步再往前推。毕竟算力挑战背后的本质是让 Agent 把每一分计算都用在值得的地方。