这一两年凡是跑过 Agent 生产环境的人大概都有一种感觉模型能力越来越强但真正卡住你的往往不是模型本身而是底座。我在华为全联接大会 2026 期间跟几个做 Agent 基础设施的同行聊了一整天大家的共识是算力竞争已经进入下半场——单卡跑分不再有意义谁能把算力变成 Agent 用得起的“水电煤”谁才是新底座。这篇文章想把我们对新底座的理解拆开聊透也把评估算力的方法、精度取舍和踩坑经验一并放进来适合做 Agent 开发、平台工程和算力运营的朋友参考。1. 大会风向变了算力叙事从“单卡跑分”转向“系统智能”1.1 大家开始关心“有效算力”而不是峰值过去两年大模型厂商的发布会基本都围绕一个核心动作晒卡。多少张加速卡、多少 P 的集群峰值算力、训练了多少万亿参数。这些东西当然重要但只有真正运营过推理服务的人才知道峰值算力和“有效算力”之间可能隔着一条鸿沟。华为全联接大会 2026 上有一个很明显的信号厂商们不再只强调峰值而是把重点放在了集群利用率、单位 Token 成本、故障恢复时间和能耗效率这些运营指标上。原因并不难理解。训练阶段可以把集群跑满任务排队也能接受但 Agent 服务是面向用户场景的在线系统用户等不了几分钟才得到一个响应。一个推理集群如果只有 30% 的利用率哪怕单卡峰值再高实际能支撑的 Agent 并发会话数也非常有限。算力竞争进入下半场比拼的不是“有多少算力”而是“同样的算力能产出多少有效服务”。我特别注意到大会上几场关于 AI 基础设施的讨论几乎都在讲同一件事算力底座必须从“能跑模型的机器群”进化为“可运营的智能体服务系统”。这个转变意味着你做底座选型时不能再盯着单卡显存和 TFLOPS 看了要盯着更上层的指标端到端延迟、并发会话数、每次交互的算力成本。1.2 “面向 Agent 的基础设施”成为产业主轴早些年聊算力底座默认就是三件套GPU 集群、高速网络、并行存储。但 Agent 大规模落地之后底座的边界被撑大了。Agent 不是一个简单的“请求-响应”服务它有记忆、有工具调用、有多步推理、有多智能体协作于是底座里至少要多出几样东西记忆存储与检索、沙箱运行环境、调度与编排层、可观测性系统。大会上一个反复出现的词是“智能体基础设施”Agentic Infrastructure。围绕这个词各家给出的方案不太一样但思路是统一的把算力、数据、模型、Agent 四层耦合在一起让开发者不需要关心底层资源细节就能把 Agent 跑起来。这跟我做平台这两年观察到的情况完全一致。早期大家搭 Agent 就是“模型 API 一个框架”跑 Demo 没问题一上线就崩。崩在哪儿不是模型不聪明而是底层没有一个能扛住 Agent 行为模式的底座上下文太长把显存吃光、多 Agent 并发把模型服务打满、工具调用失败后重试导致 Token 消耗爆炸。新底座要解决的就是这些问题。1.3 算力评价指标正在换血维度传统关注点新底座关注点算力单卡 FLOPS、显存大小单位 Token 成本、有效算力利用率集群卡数、总算力可支撑并发会话数、故障恢复时间能耗整机功耗PUE、单位 Token 能耗网络带宽峰值长上下文传输效率、多机协同延迟稳定性可用性 99%沙箱隔离能力、自动化恢复能力这张表值得做 Agent 平台的同学保存下来。你评估一个底座好不好不要问“它有多少算力”要问“跑我的 Agent 场景每 1 万 Token 要花多少钱、P99 延迟是多少、并发一上来会不会互相挤兑”。评价指标换了选型逻辑才跟得上。2. Agent 的真实算力账单不是把模型跑起来那么简单2.1 长上下文把注意力成本变成二次方黑洞Agent 和普通 ChatBot 最大的差别之一是上下文长度。普通的单轮问答上下文可能只有几千 Token一个 Agent 会话经过多轮工具调用、多步推理、记忆注入之后上下文轻易就能到几万甚至十几万 Token。很多人低估了上下文变长对算力的影响。Transformer 自注意力的计算量跟序列长度是平方关系。粗略算一个 32K 上下文的 Agent 会话单次前向计算里注意力部分的开销是一个 2K 上下文会话的 256 倍。虽然实际工程里有 FlashAttention、稀疏注意力等手段把计算量压下来但 KV Cache 的显存占用仍然随上下文线性增长这个躲不掉。我给一个可以复算的例子一个 7B 级别的模型假设 32 层 Transformer按常见配置估算每多一个 Token 的 KV Cache 大约占 0.5MB 显存不同架构差异很大。64K 上下文单会话的 KV Cache 就要 32GB 左右这还没算模型权重本身。也就是说一台 80GB 显存的卡塞下 64K 上下文的 7B 模型之后基本只能服务一两个并发会话。注意用长上下文模型跑 Agent不要只看“能不能处理 128K Token”要看你的显卡能不能同时给多少个会话维持 128K 的 KV Cache。显存不够时要么降并发要么缩短上下文要么上上下文缓存/压缩没有第三种选择。2.2 多 Agent 协作并发压力是乘法级的单 Agent 已经把上下文拉得够长了多 Agent 协作还得再乘一个并发系数。一个“规划者 两个执行者”的简单结构规划者需要把各执行者的结果汇总后再推理Token 消耗不是简单相加而是形成了一棵推理树。每一个分支都是一次独立的模型调用每个调用的上下文都包含前置结果。我去年帮一个团队优化过一个市场分析 Agent结构是“研究规划 → 并行搜索 → 汇总写作”。三到四个子任务并行跑总 Token 消耗大约是单一 Agent 的 2.5 倍。这不是 Agent 框架的问题而是协作模式本身的信息开销。所以评估底座的并发能力时不能只看单路推理吞吐要看“多个 Agent 实例同时推进、共享同一批基础模型服务”时显存和带宽能不能顶住。这也是为什么越来越多的底座设计强调 PagedAttention 和共享前缀缓存——不同 Agent 会话之间往往有系统提示词、工具描述这些公共前缀把这些前缀的 KV Cache 共享掉能节省大量显存。2.3 记忆系统隐藏的读写开销Agent 的记忆系统是另一个容易被低估的算力消耗点。每次读写长期记忆都要把用户当前的上下文向量化去向量数据库里检索最相关的若干条记忆再把命中结果拼回上下文。第一次跑的时候感觉不到会话一多向量化和检索的请求就把 CPU 和内存带宽吃满了。我自己团队的实测经验是记忆检索带来的额外开销能让单轮交互的端到端延迟增加 30% 到 50%如果检索设计得不好比如召回条数太多、向量维度太高延迟甚至翻倍。新底座里记忆不应该是一个独立的 Redis 或向量库而应该做进推理流程和 KV Cache 放在一起管理检索结果直接命中显存避免反复进出内存和磁盘。2.4 沙箱与安全不算不知道的一笔账Agent 要执行工具、跑代码、操作文件就必须有沙箱隔离。沙箱听起来只是安全组件实际上它也在消耗算力每次工具调用要拉起一个隔离环境环境里要装依赖、要分配内存和 CPU执行完还要回收。如果沙箱和推理服务不在同一套资源池里跨环境的数据传输又是一笔不小的开销。有段时间我们线上频繁报错就是热搜词里那种“agent execution terminated due to error”。当时排查了很久发现根本不是 Agent 逻辑的问题而是沙箱里的临时磁盘被写满了内存配额耗尽执行直接被系统杀掉。后来我们把沙箱资源从 2GB 内存提到 4GB、给临时目录挂了独立磁盘配额错误率立刻降了一半。3. 新底座的第一块积木异构算力与统一调度3.1 算力集群的典型构成与架构聊 Agent 底座绕不开算力集群。目前主流的 AI 算力集群一般分四层计算层各种加速卡、网络层高速互联负责卡与卡、机与机之间的数据交换、存储层并行文件系统承载训练数据和 Agent 记忆数据、调度层把任务分配到底层资源上。你可以把集群想象成一个大型写字楼调度系统是物业公司算力节点是出租的办公室网络是电梯和走廊存储是仓库。对 Agent 场景来说这套架构里最需要重新思考的是调度层。传统训练任务的调度粒度是“一次大任务占一堆卡跑几小时”Agent 服务的调度粒度是“一个会话的一步推理该放哪张卡”。粒度细了之后调度决策的频率高了一个数量级没有一套智能调度系统再多的卡也撑不起几十上百个并发 Agent 会话。3.2 调度系统才是真正的“操作系统”我见过不少团队买了一堆高性能卡结果 Agent 服务上线之后实际吞吐只有理论值的四成。问题基本出在调度上有的卡已经满载有的卡在闲置请求没有排队策略高峰期全部挤在同一批卡上把延迟拉得老高。好的调度系统至少要管三件事一是算力调度决定每个 Agent 会话的推理请求给哪张卡二是内存调度管理 KV Cache 的分配与回收避免显存碎片化三是数据调度让 Agent 要读取的记忆、工具返回的结果尽可能靠近计算节点减少跨机传输。这三个“调度”叠在一起本质上就是底座的操作系统。前两年大家关注的是单卡性能好不好但从华为全联接大会 2026 释放的信号来看后面比拼的重点是调度系统能让算力资源发挥出几成效率。这就像同样配置的电脑Windows 调度不好照样卡顿换个思路调优之后却能流畅跑大任务。3.3 训推一体与异构协同Agent 部署还有一个容易被忽视的点它既有推理负载也有持续的微调和增量学习需求。如果一个团队既要跑 Agent 推理又要定期用新数据微调底座模型分两套资源池会很浪费。训推一体的架构能让一套集群按时间段灵活切换白天高峰跑推理夜间低峰跑训练和评估。异构算力在这个框架下意味着什么简单说不要让所有负载都挤在加速卡上。工具的解析、文本的预处理、记忆的向量化、Agent 的编排逻辑这些用 CPU 处理完全够只有真正的模型前向推理才需要加速卡。如果把这些区分开一张算力卡能服务的 Agent 并发数会明显提升。我在实际项目里的做法是推理模型独占加速卡调度器、沙箱、向量检索跑在 CPU 节点上越过 PCIe 和 RDMA 直接交换数据。这样从表面看多了一层架构实际上把通路的瓶颈解开了整体吞吐涨了大约四成。4. 精度不是越高越好int8/fp16/fp32/fp64 背后的算力账4.1 四种精度的算力需求对照最近不少人拿着“int8、fp16、fp32、fp64 的区别和算力需求”来问我这确实是个值得掰开揉碎讲的问题。很多刚入门的同学会觉得“精度越高越好”其实算力世界里精度和成本是严格挂钩的。精度位宽典型用途算力开销显存/带宽占用适用场景fp6464 位科学计算、数值模拟最高最高物理仿真、气象计算fp3232 位传统深度学习训练、精确基准高高早期模型训练、科研验证fp16/bf1616 位大模型训练、混合精度中中LLM 训练与推理主流精度int88 位推理量化加速低低在线推理、边缘部署对 Agent 推理来说绝大多数场景用 fp16 或 int8 就够了。原因在于Agent 的推理链路长反复调用模型如果每一步都用 fp32算力成本会变成天文数字。而 int8 量化后显存占用砍半推理吞吐能翻一倍只要精度损失可控性价比非常划算。4.2 量化掉点怎么评估、怎么补救当然量化不可能零损失。我之前把一套基于 70B 模型的 Agent 服务从 fp16 压到 int8显存确实降了一大截并发能力也上去了但在长上下文场景下明显感觉输出质量变差尤其是在需要精确引用数据、多步推理的 Agent 任务里错误率涨了几个点。后来我们换了策略不全量量化做分模块量化。Attention 层保留 fp16Feed-Forward 层用 int8。这样显存省了 30% 左右但关键路径上的精度保住了跑了几轮评测之后效果基本和 fp16 持平。建议每个想靠量化省算力的团队都建立一份“量化回归测试集”把你 Agent 最典型的 200 条交互记录收集起来分别跑量化前后的模型对比任务成功率、关键指标误差、平均 Token 数。没有这份测试集量化省下来的算力迟早会在线上变成事故赔回去。4.3 用算法结构换算力蒸馏、MoE 与投机采样除了精度算法结构也是换算力的重要杠杆。蒸馏是把大模型的能力压缩到小模型里小模型跑 Agent 的日常推理遇到高难度任务再升级到大模型这是 Agent 底座常见的多模型路由方案。MoE 用多个专家网络替代单个稠密网络同样参数规模下推理消耗更小。投机采样则用一个小草稿模型先生成候选 Token再由大模型一次验证多个 Token实际吞吐能提升两三倍。这些技术都不需要换硬件纯粹是软件层面的算力优化。我建议在买更多算力之前先把这些“软”手段试一遍。很多时候瓶颈不在硬件不够而在模型服务方式太浪费。5. 算力约束下的资源配置建模在有限算力里喂出更强的 Agent5.1 先估算再扩容一个可套用的算力评估模型“如何评估需要的算力”是每个 Agent 项目启动时都会问的问题。我的建议是先建模再买东西不要凭感觉加卡。下面这套估算方法不依赖具体硬件型号套的是业务参数。第一步算每日 Token 消耗。日 Token 消耗 D 日活会话数 × 平均会话轮数 × 平均每轮 Token 数。第二步算峰值吞吐需求。峰值 R D × 高峰系数 ÷ 有效在线时长。第三步算节点数。节点数 N R ÷ 单节点可支撑吞吐。举一个真实的估算例子。假设日活会话 1 万每个会话平均 20 轮每轮输入输出合计 2000 Token那么日消耗 D 10000 × 20 × 2000 4 亿 Token。高峰系数取 3有效在线时长按 8 小时算峰值需求 R 4 亿 × 3 ÷ (8 × 3600) ≈ 41666 Token/秒。如果单节点 8 卡能稳定支撑 1500 Token/秒那么大约需要 28 个节点。这套模型的关键不是算得精准而是让你先知道量级。任何底座选型、预算申请都应该从这样一笔账开始。5.2 用压测数据校准配置估算只是起点真实配置要靠压测来校准。Agent 服务的压测和普通 Web 服务的压测不一样普通 Web 关注 QPSAgent 服务要关注的是“并发会话数、每会话 Token 吞吐、P99 延迟”三个指标。做法不复杂准备一批有代表性的 Agent 交互脚本用压测工具模拟不同数量的并发会话观察三件事——模型服务的吞吐上限、KV Cache 是否溢出、工具调用密集时沙箱是否成为瓶颈。我建议至少测三档日常负载、1.5 倍负载、2 倍负载找出哪个环节先崩。大多数情况下先崩的不是模型而是沙箱或者调度器的任务排队时间。5.3 成本优化实例把 Agent 服务成本压下去我们团队曾经把一个 Agent 服务的成本压缩了 30%没降效果靠的是两个手段。第一个是缩扩容策略。白天用户活跃推理节点全开晚上流量低把节点缩到三分之一低峰期的批量任务比如夜间记忆整理、数据回放安排在缩容后的大节点上跑。第二个是前缀缓存。所有 Agent 会话共享一段系统提示词和工具说明这部分 KV Cache 只需要算一遍后续会话直接命中。这两个改动加起来月成本从 48 万降到 33 万左右效果指标没有回退。这类工作本质上就是热搜词里那句话——“算力约束下提升大语言模型能力的资源配置建模”。别把它想得多玄乎核心就是把每一份算力花在刀刃上建模、压测、优化反复迭代。6. 给 Agent 开发者的底座选型清单与实践心得6.1 框架与编排先想清楚谁在调度谁Agent 框架怎么选是团队里最常见的争论。LangGraph、AutoGen、CrewAI 各有拥趸但我觉得技术选型之前先想清楚一个更根本的问题你希望谁能控制 Agent 的执行流程。框架给的是“写 Agent 逻辑的 API”编排平台给的是“运行和调度 Agent 的底座”两者不能混为一谈。就像热搜词里问的“harness 和 agent 区别”——harness 是那套承载执行的环境和作业平台agent 是里面做决策的主体。一个合格的底座应该把这两层解耦Agent 只负责决策和工具调用harness 负责资源隔离、状态管理、失败重试和监控。如果框架里全是业务逻辑又把底层资源管理混在一起项目一复杂就乱成一锅粥。6.2 部署测试与可观测性别等上线才想监控Agent 部署测试比普通后端服务麻烦得多因为它涉及沙箱、工具调用、多步状态。我见过太多项目在本地跑得好好的一上线就出问题原因就是测试环境和生产环境的沙箱配置不一致。Agent 部署至少要有三层测试本地函数测试工具逻辑是否正确、沙箱集成测试依赖和权限是否完备、灰度发布用少量真实流量跑一轮观察。可观测性方面Agent 有几个独有的监控点Token 消耗量、工具调用成功率、Agent 单次的推理步数、循环检测Agent 反复做同一件事不退出、按会话维度的成本追踪。不要指望通用 APM 能覆盖这些必须自己埋点。查到“codex 无法发送消息显示更新 agent 沙盒”这类报错时第一反应不是重启而是去看沙盒日志和资源水位问题往往出在没有什么人注意到的内存配额上。6.3 我踩过的坑和一条务实的搭建路线最后分享几个我被问过最多的问题背后踩过的坑。第一个坑是高估显存。买卡之前只看了模型权重大小忽略了 KV Cache上线后并发一高直接 OOM。现在我的习惯是先算 KV Cache 再算权重两者相加才是真正的显存需求。第二个坑是把记忆系统做得太重。第一版方案上了大而全的记忆图谱结果推理链路过长延迟直线上升。后来砍到“只记忆结论、不记忆过程”检索效率立刻改善Agent 效果反而更好。第三个坑是调度器初期追求极致平衡、忽略局部性。后来发现 Agent 的上下文经常跨请求复用如果每次都把相同前缀的请求调度到不同卡上前缀缓存的命中率会非常难看。现在我们的调度策略是“优先复用前缀缓存其次才考虑负载均衡”。如果从零开始搭建 Agent 底座我的建议是走这条路先用单模型、单 Agent、无记忆的最小架构跑通业务然后加工具调用配上沙箱再加短期记忆和一个简单的检索等业务量上来了再考虑多 Agent 协作和完整调度系统。每一步控制在两周内落地不要一上来就追求大而全。我个人这两年最深的体会是Agent 底座不一定要豪华但一定要可观测、可回滚、可压测。算力竞争进入下半场之后决定胜负的往往不是谁手里的卡多而是谁能把卡的每一分算力都精准地用在一个又一个真实 Agent 会话上。先把自己手头的资源配置算清楚比什么都重要。