过去几个月，各大厂密集发布了新一代基础模型。Claude Fable 5.1、Gemini 3.8 Flash、GPT-6 Astra 接连亮相，几乎都在围绕一个共同方向发力：追求Agent的适配能力，让推理链条拉得更长、工具调用更顺滑、决策路径也更稳健。
这一趋势推动 Agent 加速落地企业场景。数据显示，2026 至 2027 年，中国企业场景中活跃的智能体数量单年同比增长超过 200%，预计到 2031 年将达到 3.5 亿个。
值得注意的是，这场狂欢的背后，数据中心正承受着巨大的压力。
现有数据中心基础设施，大多是为大模型单次推理调用的吞吐量而设计的，并没有真正考虑过 Agent 那种高频、突发、有状态，且工具调用穿插其中的工作负载。Google 最近的调研显示，近 83% 的企业高管认为基础设施需要为 Agent 时代重新调整。前不久，AMD 也表示 CPU 和 GPU 的配比需要重新调整；8 月，AWS 与 NVIDIA 更是宣布联手打造下一代 AI 基础设施。
不过，这些说法大多围绕输入端的能力参数展开——比如核心数量、带宽大小、功率上限下能跑多少节点。
英特尔在 8 月发布的一份白皮书却给出了不同立场。英特尔认为，优化数据中心的关键并非提升理论参数，而是看它在实际场景中、满足延迟承诺的前提下，能稳定维持多少 Agent 任务量。
一句话概括就是：“去计算数据中心的实际工作量，而不是理论的性能上限。”
这是一个系统级的论点。对于仍在摸索 Agent 生产到底需要什么基础设施的行业来说，值得认真对待。
任务越多，隐藏的等待越长
过去的思路很简单：GPU 越快，大模型回答就越快。
但 Agent 并不是一次推理调用。它的执行过程包括规划、推理、调用工具、观察结果、再规划、再推理等多个环节。每一轮下来，都可能要调代码沙盒、查数据库、执行检索，甚至调用子 Agent 来处理。
所以 GPU 算力再强，也无法解决所有问题。Agent 任务量一旦增长，模型推理之外的细分任务延迟就会持续暴露。
要看清这个问题，先得理清一轮 Agent 任务请求的时间究竟花在了哪里。
英特尔白皮书对这一过程做了详细拆解。最大的一块是模型调用（预填充加解码），约占总任务时间的 40%，主要跑在 GPU 上；其余 60% 都发生在主机端，主要落在 CPU 上——其中工具执行占 35%，数据服务（检索、向量搜索）占 10%，状态搬运（KV 缓存传输、TLS 等）约 8%，编排调度占 7%。
值得注意的是，占 35% 的工具执行是主机端最大的单项开销，而这项开销的背后离不开沙箱。
沙箱的出场率和重要性正在持续上升。一个代码 Agent 跑单元测试、执行脚本或验证构建时，主机端 CPU 会拉起一个隔离环境，在里面执行任务，随后对沙盒状态打快照——即记录数据状态，以便下一轮任务在此基础上继续执行。
如今，随着模型能力提升，Agent 的任务复杂度也水涨船高。很多时候，数据中心在处理 Agent 任务时，已经不是跑一个沙盒那么简单，而是一个节点上同时运行数百个沙盒。
数百个沙盒同时运行，带来了算力密度的难题。每个沙盒的生命周期都需要一连串 CPU 密集型操作：快照数据压缩、恢复时解压、新镜像的内存分配等。这些操作在 CPU 核心上往往线性排队——如果快照的压缩解压慢 1 毫秒，其他所有任务都会多等 1 毫秒。叠加数百个并发会话后，沙箱的时间开销就会成为主要延迟来源。
事实上，这种并发需求正是数据中心最头疼的地方。一项针对 739 次匿名化 Claude Code 对话的测量专门研究了这个问题：在涵盖多轮代理、代码生成与工具调用执行的总时长中，主机端 CPU 耗时究竟占多少。
结果显示，单请求场景下，这一占比几乎可以忽略。上下文长度从 1K 到 100 万 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%。另一个理论容量较低但转换效率更高的单机柜，最终交付 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 到底能跑多少个？英特尔或许会在那里给出更具体的回答。查看白皮书： https://www.intel.com/content/www/us/en/newsroom/opinion/count-the-work-not-just-the-cores.html
发表于 半小时前
|
查看: 3|
回复: 0
