单个机柜到底能跑多少个 Agent？答案不在 GPU 身上

过去几个月，大厂接连发布了新一代基础模型。Claude Fable 5.1、Gemini 3.8 Flash 与 GPT-6 Astra 等层出不穷。 不难看出，这些模型几乎都在追求 Agent 的适配能力，让整个推理时间更长，工具调用更顺，决策链条也更稳。 这也让 Agent 加速进入企业端。数据显示，2026—2027 年，中国企业场景中的活跃智能体（Agent）数量单年同比增长超 200%，到 2031 年预计可达到 3.5 亿个。 值得注意的是，这种全民狂欢的背后，数据中心正面临巨大的挑战。 现有数据中心基础设施，基本都是为大模型单次推理调用的吞吐量而设计的，并未真正考虑过 Agent 那种高频、突发、有状态，并且工具调用穿插其中的工作负载。 谷歌最近的调研提出，近 83% 的企业高管认为基础设施需要为 Agent 时代重新调整。前不久，AMD 也表示 CPU 和 GPU 的配比要重新调整；8 月，AWS 和 NVIDIA 更是宣布，要联手搞下一代 AI 基础设施。 然而，这些说法更多是围绕输入端的能力参数——比如有多少核心、多少带宽、在功率上限下能运行多少节点。 英特尔在 8 月发布的一份白皮书中，却表明了不同的立场。英特尔提出，对数据中心进行优化的关键，并不在于提升理论参数值，而是考虑它在实际应用场景下，满足延迟承诺时，能够维持多少 Agent 的任务量。 一句话说就是：“去计算数据中心的实际工作量，而不是理论的性能上限。” 这是一个系统级的论点。对于还在摸索 Agent 生产到底需要什么基础设施的行业来说，不失为值得认真对待的思路。 预告：在 9 月 22 日～23 日，英特尔将会在苏州举办 2026 年 Intel Connection 大会，会上会展示最新的 DCG 产品，以及面向企业 AI 应用落地场景的对应产品。那里或许也有行业所寻求的解决方案。 一、任务越多，隐藏的等待越长 过去的思路很简单。GPU 越快，大模型回答就会越快。 但 Agent 并不是一次推理调用。它的整个执行过程，包括规划、推理、调用工具、观察与规划、再推理等。每一轮下来，都可能要调代码沙盒、查数据库、跑检索需求，甚至还会调用子 Agent 进行处理。 所以，GPU 的算力再猛，也不能解决所有问题。Agent 的任务量一旦增长，模型推理之外的其他细分任务的延时就会不断暴露。 要看透这个问题，就要先理清楚一轮 Agent 任务请求的时间到底都去哪了。 英特尔的白皮书将这个过程进行了详细拆解。其中最大的一块就是模型调用（预填充加解码等），大概占总任务时间的 40%，主要跑在 GPU 上；剩下的 60% 全部都在主机（Host）端，主要跑在 CPU 上，包括工具执行占 35%，数据服务（检索、向量搜索）占 10%，状态搬运（KV 缓存传输、TLS 等）约 8%，编排调度占到 7%。 值得注意的是，35% 的工具执行是主机端最大的一项单项开销。而这个时间的背后离不开一个东西——沙箱。 沙箱的出场率和重要性越来越高。一个代码 Agent 跑单元测试、执行脚本或验证构建时，主机端 CPU 就会开启一个隔离环境，在里面跑任务，然后给沙盒状态打快照，也就是记录数据状态，好让下一轮的任务可以在其基础上继续执行。 现在，随着模型能力的上升，Agent 的任务能力也水涨船高。很多时候，数据中心在处理 Agent 的任务时，根本不是一个沙盒的事，而是一个节点上会同时跑几百个沙盒。 这几百个沙盒，会带来算力密度的难题。每个沙盒的生命周期都需要一连串 CPU 密集操作：快照数据的压缩、恢复时的解压、新镜像的内存分配等。而且这些操作在 CPU 核心上往往需要线性排队。这意味着，如果快照的压缩解压慢一毫秒，其他所有任务都会多等一毫秒，叠加几百个并发会话，沙箱的时间开销将会成为主要的延迟。 事实上，这种并发的需求是最让数据中心头疼的地方。有一项对 739 次匿名化 Claude Code 对话的测量，专门研究在涵盖多轮代理、代码生成与工具调用执行的总时间里，主机端 CPU 耗时占了多少比例。 结果显示，单个请求任务时，这一比例几乎看不出来。上下文长度 1K 到 1 百万 token 时，在端到端延迟中仅占 0.4～0.6%。但是并发到 32 个会话时，这个比例突然跳到了 11%～15%，其中大约 94% 的增长都是来自调度与队列排队，而不是实际的计算。 具体来说，32 个会话时，每个请求占用主机端 CPU 的时间是单独跑的时候的 20 倍以上。这意味着，数据中心的性能优化，以及 CPU 与 GPU 之间的协同设计，本质上是如何更好地调度，而不仅仅是提升算力。 这种排队所导致的 CPU 的处理等待，也会殃及到另一个身价不菲的芯片——GPU。工具在跑的时候，不管是 SQL 查询、沙箱测试还是检索调用等，都会让被分配的 GPU 先等着。主机端 CPU 核心的运算速度，也解决不了多出来的 94% 的排队问题。 即便沙箱构建完了，GPU 还会继续等待下一个提示。例如并发太多，导致显存满了，之前很多会话的 KV Cache 缓存不得不在 GPU 空窗等待阶段被释放。GPU 等到任务时，又要重新填充，导致慢上加慢，越来越慢。 统计数据显示，这种编码 Agent 的任务执行中，GPU 估算仅有 50% 到 60% 的时间在真正干活。 可以说，数据基础设施即便发展到今天，也依然没有逃脱“阿姆达尔定律”。简言之，就是系统加速中必然会受限于最慢的串行环节。 Agent 的出现，只是让这个环节变成了新的：沙箱快照排队、状态重建、调度争用等。 二、从交付量倒推，重新分配系统资源 这也意味着，数据中心基础设施的发展，仍然处于早期阶段，至少对 Agentic 时代而言，是如此。 这表现在，行业仍是先集中精力处理单点问题。例如单核性能有多快，或者固定功率下预计能跑多少吞吐量等。 英伟达的早期逻辑就是 Agent 的循环本质是串行处理，是线性的，这意味着单核速度越快，就能决定整个循环的速度有多快。 AMD 的看法略有不同。它将整机柜的功率作为锚点，然后去思考在 100 千瓦的预算下，能够实现多大的总吞吐量。按照 AMD 的几何估值估算，Vera 为 1.0，Xeon 6980P 为 1.46，EPYC Turin 为 3.37，256 核的 Venice 则为 3.30。 但不得不承认，理论容量并不等于实际产出。英特尔指出，这种仅仅从输出端参数去考虑的方式，并不能决定单个机柜究竟能干多少活。 而且随着企业级应用不断落地，成本已成为客户绕不开的考虑。如今企业真正关心的是在服务水平达标的情况下，能稳定提供多少服务交付。 为了把理论跟实际结合到一起，英特尔提供了一个衡量单个机柜实际工作量的公式： 每机柜可交付智能体数 = 理论每机柜智能体数 × 调度有效性 × 资源平衡度 × 计算卸载效益 公式中，每一个乘数都对应生产环境中影响实际交付量的一项关键因素。 调度有效性说的就是前文提到的调度问题。通过路由器可以对每个节点做采样：CPU、内存、I/O、加速器占用率、缓存状态，以及每个会话的上下文和 KV 状态的存储位置等。 只有采样到位，才能让调度跟着状态走，并把 Agent