作者 | 白默
过去几个月，大厂接连发布了新一代基础模型。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 的任务送到合适的节点上。与此同时，英特尔的至强产品线还设计了不同的核心类型（性能核与能效核），覆盖不同的执行画像。例如，单线程的性能核适合跑串行编排循环，开启了超线程的性能核可以跑 SQL 和向量检索这类数据服务，AMX 在主机端可以做嵌入和重排序；高密度的能效核则能跑几百个并行沙盒和子代理。
简单说，就是通过更适配的调度与分工让等待排队的时间不断减少。正如管理的哲学，不是让某一个人的效率达到最大，而是让所有的人都能充分发挥自己的潜力与价值。
资源平衡度强调的是带宽与内存问题。
行业里经常把这两件事混为一谈。带宽决定的是数据的运输有多快，单位是 GB/s，本质是个吞吐问题。内存则是个驻留问题，决定了两个推理之间能保留多少会话和 KV 缓存，免去下一次调用的重复计算。
业内有很多处理方式仅仅是做取舍。例如为了给每个核心更多的带宽，而把容量减少一点，这虽然会让线程跑得更快，但却会增加很多不必要的计算。
英特尔的做法是在至强上，通过 Flat Memory 模式，把 CXL 扩展内存和原生 DDR5 合成一个地址空间，直接由 CPU 硬件侧管理。这样不必由操作系统搬数据，也不必一次搬运大量数据，数据可以直接按照缓存行粒度的标准进行搬运。
数据显示，在英特尔与 SAP 的联合测试中，这种 CXL 卡配合原生 DDR5 的模式，在大规模内存 OLAP 数据库上跑出了全 DDR5 性能的 96%，内存成本也降低了 25%。
这意味着，存储越来越贵的当下，同样的钱将获得更多的 KV 缓存停留，整体 Agent 的任务运行时长与成本也会大幅下降。
最后一个公式因子是计算卸载效益。与前两个因子侧重于减少损耗或瓶颈不同，它带来的是正向的加成效果，可以通过把卸载的活干到位，直接提升整个系统的工作量。
具体来说，就是可以把原来由 CPU 内核执行的一些杂活卸载到专用的硬件加速器来执行，这样不仅效率可能更优，还能释放更多 CPU 内存来执行更重要的任务。英特尔在这方面给出的解法，就是在至强 CPU 中集成了多种硬件加速引擎，例如 QAT 可以做 TLS 和压缩解压缩，DSA 做数据搬运，IAA 做分析原语和 KV 压缩加速。
实测数据显示，在使用 IAA 对沙箱快照做压缩后，沙箱快照的恢复时延对比不做压缩的方案可降低 38%—42%，这一收益还会随着并发规模的持续扩大而进一步提升。这表明压缩和解压缩的任务被卸载到专用加速引擎上后，就不再消耗 CPU 内核的资源，进而能让 CPU 在应用性能持平甚至提升的情况下塞下更多 Agent 处理任务。
值得注意的是，这三个乘数之间的效果会相互叠加，叠加的效果甚至会超过那些在理论性能上更强的服务器。
英特尔的白皮书中举了这样一个例子：理论容量高出 33% 的单个机柜，综合调度有效性、资源平衡度和计算卸载效益的影响后，实际交付反而落后 23%。另一个理论容量较低，但转换效率更好的单个机柜，最终交付的 Agent 为 1.1 个单位，超过理论领先者的 0.85。
简单概括，英特尔的策略就是：该分出去的活及时分出去，该留住的数据尽量留住，让更专业的工具或组件去处理更对口的事。这样一来，整个机柜在任务处理中就能少等一会儿、少重新计算一次，整套系统也能更快往前推进一步。
实际交付能力，将成为行业的共同考题
这套方案的效果可以用一条曲线来说明。
在白皮书中，英特尔展示了一个典型场景：随着单节点上活跃 Agent 数量增加，系统先受算力约束，再受带宽约束，最后被排队延迟主导——p99 延迟在前段保持平稳，直到某个临界点突然拐头向上。
这个临界点，可以称之为“膝点”。膝点之前，系统还能在延迟目标内正常交付；膝点之后，每多塞一个 Agent，延迟就开始失控。
前文提到的更优调度、Flat Memory 模式、专用引擎做部分任务卸载，本质上都是在做同一件事：把膝点往右推。白皮书的示意图中，经过自适应运行时优化后，膝点从 235 个并发 Agent 推到了 300 个，同一 p99 目标下提升 28%。
这个数字本身或许并不惊人。真正值得注意的是它背后的含义——提升并非来自更强的 GPU、CPU 芯片或更大的显存与内存，而是来自对系统内部“转换损耗”的压缩。
事实上，这正在成为整个行业无法回避的共同考题。
过去两年，围绕 AI 基础设施的竞争，主战场一直在计算承载平台的参数比拼上：核心数、带宽、功耗比、理论吞吐量。但 Agent 工作负载的特殊性在于，理论参数和实际交付之间存在一段显著的落差——就是那些在调度、搬运、排队中被吃掉的效率。
谁的落差小，谁就能在同样的硬件投入下多跑 Agent。这不是某一家厂商的技术选择，而是所有做数据中心生意的人都要回答的问题。
AMD 在押注核心密度，256 核的 Venice 追求的是固定功率下的理论吞吐上限。英伟达的逻辑围绕单核速度，认为 Agent 循环的串行本质决定了单线程性能是第一优先级。这些路线各有道理，但都还停留在上文提及公式的“理论每机柜智能体数”上。
而企业端的采购决策正在发生变化。当 Agent 从实验室走向生产环境，客户不再只看跑分和峰值吞吐。他们会追问：在多少并发下测的？目标延迟是多少？排队损耗算进去了没有？
换句话说，买家正在学会用“交付量”而不是“理论量”来比价。这把尺子一旦被行业接受，竞争的维度就会从“谁的芯片参数更高”转向“谁的系统转换效率更好”——包括调度策略、内存架构、软硬件协同，以及那些不写在产品发布会 PPT 上的工程细节。
这并不意味着算力本身不重要。更准确地说，算力是必要条件，但从理论算力到实际交付之间的转换效率，正在成为新的胜负手。
9 月 22 日将在苏州开幕的 2026 年 Intel Connection（英特尔技术创新与产业生态大会），某种程度上就是英特尔对这个问题的一次集中作答。这个活动的算力中枢展区会展示所有基于英特尔架构并针对智能体时代数据中心和 AI 基础设施推出的创新硬件设备与平台，其中就包括面向智能体的高密度高能效 CPU 整机柜方案；企业 AI 展区则会集中展示英特尔牵头开发的、能把硬件能力更充分转化为 Agent 交付量的各种软硬件协同优化方案。这些方案会涉及路由、调度、状态管理，集中在 Agent 沙箱的加速与保护，以及 KV Cache 的卸载和加速等领域。如果你对这些话题或方向感兴趣，这将是一次难得的充电刷新机会。
本文从单个机柜层面的问题出发——你的 Agent 到底能跑多少个？那里或许会有最具体的回答。
热门跟贴