简介：随着智能体工作负载从模型训练走向任务执行，CPU不再是AI系统中的附属配件，而是承担规划、工具调用、状态校验与系统编排的关键角色。本文围绕“通用计算与加速计算在智能体时代的分工与选型”展开，从架构差异、性能边界、成本结构、适用场景和迁移注意事项等维度进行系统对比，帮助技术负责人与开发者在AI基础设施规划中做出更合理的判断。
过去几年，AI基础设施建设的焦点几乎全部集中在加速计算上。训练大模型需要海量矩阵运算，导致采购清单里最受关注的是高性能加速卡，而CPU往往被看作“必须搭配但优先级不高”的组件。彼时的典型架构是：加速卡负责密集计算，CPU只承担数据搬运、任务调度和基础I/O处理，甚至在一些大规模训练集群中，CPU的规格选择主要取决于它能否“喂饱”加速卡。
但进入智能体应用阶段后，情况发生了明显变化。智能体不再只是一次性的模型推理，而是一个需要反复规划、调用外部工具、读取数据库、创建隔离执行环境、校验中间结果并决定下一步动作的复杂工作流。这类负载的特征是高并发、多分支、长链路、强交互，且混合了计算、内存访问、网络通信与状态管理。它更接近传统的在线事务处理与分布式系统编排，而不是单纯的矩阵加速。
与此同时，CPU供应出现紧张，部分厂商公开表示产能只能覆盖一部分客户需求。这种短缺并非简单的产能波动，而是需求结构变化的结果：当智能体任务从“GPU密集”转向“CPU密集的系统性执行”时，CPU重新成为影响整体吞吐和稳定性的关键资源。
因此，本文要对比的核心对象可以抽象为：
需要说明的是，本文不比较某一款具体处理器或加速卡，而是比较两类计算资源在智能体时代的定位、能力边界与选型逻辑。
通用计算能力依托CPU实现，其核心特征是：
在智能体场景中，通用计算能力负责的是“执行框架”本身。例如，一个智能体要完成“查询订单状态并生成退款建议”的任务，它需要先解析用户意图，再调用订单数据库，之后根据返回结果判断是否需要进入人工审批分支，最后再调用另一个内部接口完成操作。这个过程中，真正的模型推理时间可能只占很小一部分，大部分时间消耗在CPU执行业务逻辑、等待数据返回和维持会话状态上。
加速计算能力通常由GPU或类似专用处理器提供，其核心特征是：
在智能体链路中，加速计算主要用于两类位置：一是模型推理，即根据当前上下文生成下一步的动作或回答；二是辅助计算，例如向量检索后的相似度计算、图像或语音输入的特征提取等。这些任务可以在较短时间内完成，但通常要求批量、低延迟或高并发。
在大模型训练时代，加速计算是绝对主角，通用计算处于从属地位。但在智能体时代，一个完整任务往往要跨越模型调用、工具执行、数据访问和系统调度多个环节，两类计算能力必须频繁交互。CPU需要决定何时调用模型、如何组织上下文、是否重试、是否回退；GPU则需要在收到请求后尽快完成计算并返回结果。这种协作模式下，CPU的调度能力会直接影响加速资源的利用率，而加速资源的响应速度也会反作用于整体任务延迟。
在讨论差异之前，有必要先明确两类计算能力的共同点。
无论智能体架构如何简化，至少需要以下三类能力：模型推理、任务编排和外部交互。模型推理离不开并行计算资源，任务编排天然适合CPU执行，外部交互则需要网络、存储和接口调用，而这些又主要由CPU主导。任何试图完全省略某一侧的做法都很难成立。
智能体应用通常面向在线业务，用户等待时间直接影响体验。无论是CPU上的规划逻辑，还是加速卡上的推理计算，都需要在延迟和吞吐之间取得平衡。同时，智能体任务往往包含多次串行调用，任何一个环节的抖动都会被链路放大。
CPU和GPU都存在资源浪费的问题。CPU侧可能出现大量线程等待I/O或锁竞争，GPU侧可能出现批处理大小不合理、显存碎片或空转。如何提高资源利用率，是两类计算资源共同面对的问题。
智能体任务通常需要访问向量库、关系型数据库、对象存储和内部API。无论哪类计算资源，最终都会受限于内存容量、存储I/O和网络延迟。因此，讨论CPU与GPU差异时，不能脱离系统整体架构。
这是最本质的区别。CPU擅长处理不规则、分支多、依赖复杂的任务。一个智能体在运行过程中，可能会经历“判断意图—选择工具—解析返回—发现异常—重试—再判断”等多轮逻辑，这些逻辑的执行路径高度动态，很难预先批量排布。
GPU则擅长规则、重复、可并行的数值运算。模型推理虽然也有分支，但总体上仍以矩阵计算为主。将大量分支密集的任务交给GPU，不仅无法发挥并行优势，还可能因为频繁的线程发散和调度开销而降低整体效率。
CPU上的调度粒度很细，可以精确到线程、进程和容器级别。操作系统能够根据优先级、资源占用和等待状态随时切换任务，适合大量小请求并发到达的场景。
GPU的调度粒度通常更粗。虽然现代GPU也支持多流并发，但在实际部署中，为了保证吞吐，往往会把多个推理请求合并成批次一起执行。这种粗粒度调度在处理大量低延迟小请求时，可能引入额外的排队延迟和资源碎片。
CPU拥有成熟的多级缓存和可扩展内存体系，可以灵活配置从几十GB到数TB的内存，适合缓存智能体的会话状态、工具结果和业务数据。
GPU虽然也有大容量显存，但单位成本更高，且显存与系统内存之间的数据传输需要经过互连总线。对于需要频繁访问外部数据库或对象存储的智能体任务来说，数据往往先在CPU侧落地，再按需传输到GPU侧计算。如果任务逻辑需要大量随机内存访问，CPU的缓存体系更有优势。
CPU扩展方式较为成熟，通常通过增加核心数、内存通道和服务器节点来线性扩展整体处理能力。对于智能体这种高并发任务，可以通过水平扩展CPU节点来提高系统吞吐。
GPU扩展则更依赖单机内部的多卡互连和节点间高速网络。单卡算力很强，但多卡协同对通信带宽要求高，成本也显著上升。在智能体场景中，如果模型调用频次不是极高，完全没有必要为每一台CPU节点都配置大比例加速卡。
CPU相关成本通常包括服务器、内存、存储和网络设备，采购和运维都较为成熟，单位算力成本相对可控。GPU相关成本则集中在加速卡本身以及配套的高带宽互连、大功率电源和散热系统上，单卡成本高，且需要专门的运维保障。
智能体应用的成本评估需要关注一个关键指标：在一次完整任务中，模型推理时间占比多少？如果占比低于30%，说明大部分时间消耗在CPU侧的逻辑处理和数据等待上，此时过度配置GPU并不会显著改善端到端延迟，反而会增加成本。
| 对比维度 | 通用计算能力 | 加速计算能力 |
|---|---|---|
| 核心适合任务 | 规划、工具调用、数据访问、状态管理、系统编排 | 模型推理、批处理数值计算、特征提取 |
| 任务特征 | 分支密集、依赖复杂、动态性强 | 数值密集、规则性强、可并行度高 |
| 调度粒度 | 细粒度，可精确到线程和进程，适合高并发小请求 | 粗粒度，通常需要批处理，适合吞吐优先场景 |
| 内存体系 | 灵活通用，容量可扩展，缓存成熟 | 高带宽专用，容量成本高，与主存交互有额外开销 |
| 扩展方式 | 以节点水平扩展为主，生态成熟 | 以单机多卡和节点间高速互连为主，成本较高 |
| 稳定性表现 | 单点故障影响相对可控，可快速迁移任务 | 对驱动、显存、热设计敏感，故障恢复更复杂 |
| 运维复杂度 | 通用运维技能即可覆盖，监控与工具链成熟 | 需要专用监控、资源池化和任务调度能力 |
| 成本结构 | 单位算力成本低，适合大规模水平扩展 | 单卡成本高，适合集中承载数值计算负载 |
| 智能体中的定位 | 执行框架与系统大脑 | 模型服务与数值加速引擎 |
当智能体任务具备以下特征时，应优先保障CPU资源：
例如，企业内部的工单处理智能体、订单查询助手、审批流自动化agent等，通常CPU需求远高于GPU需求。
当任务具备以下特征时，加速计算资源的优先级更高：
大多数生产级智能体应用都介于两者之间。典型做法是：CPU节点负责接入层、调度层和工具执行层，GPU节点以独立模型服务形式提供推理能力。CPU节点可以根据请求量灵活扩缩，GPU节点则根据模型调用频率和单请求算力需求配置。
在规划智能体基础设施时，不要直接套用“模型越大、GPU越多”的思路。建议先在测试环境中对完整任务链路进行分解，统计各环节耗时：模型推理、工具调用、数据读取、逻辑判断、网络传输各占多少。只有拿到实际数据，才能判断瓶颈在哪一侧。
智能体经常需要多步执行，每一步都涉及一次或多次模型调用。如果单任务平均需要十次模型调用，每次推理延迟50毫秒，则仅模型侧累计延迟就达到500毫秒。此时，即使CPU侧优化得再好，总延迟也很难下降。反之，如果大部分步骤只是数据库查询和条件判断，模型调用仅一两次，那么CPU侧的优化收益会远大于GPU扩容。
在智能体架构中，CPU不应只被看作“运行代码的地方”，而应被设计为整个系统的调度中枢。它需要管理请求队列、维护会话状态、控制并发度、执行超时重试、记录审计日志，并与模型服务之间保持高效的通信协议。CPU核心数、内存带宽和网络吞吐的配置，都会直接影响这些能力。
GPU适合批处理，但智能体请求往往具有突发性和低延迟要求。如果为了追求GPU利用率而把批处理窗口设得过大，会增加请求排队延迟。建议根据实际请求到达率动态调整批处理窗口，并对超时请求提供降级策略，例如切换到较小模型或返回缓存结果。
如果团队正在从“训练导向”的基础设施向“智能体服务导向”迁移，需要重点关注以下几点。
训练阶段的容量规划通常以吞吐为核心，单次任务耗时长、可排队。智能体阶段则更关注P95延迟和并发数，容量模型从“每小时处理多少样本”变为“每秒钟完成多少任务”。两者的容量计算方法差异较大，需要重新建立监控指标和压测方案。
智能体任务常常跨多个服务和多次模型调用，状态管理变得复杂。如果某个步骤失败，需要决定是整体回滚、局部重试还是人工介入。CPU侧需要承担大部分状态管理工作，因此在存储选型、缓存策略和日志审计上要提前规划。
在混合架构中，CPU与GPU之间的交互延迟可能成为隐藏瓶颈。尽量复用已建立的连接，避免频繁冷启动模型会话；对高频调用的小请求，考虑在CPU侧做预处理和结果缓存；对批量任务，设计合理的扇入扇出策略，减少互连总线上的无效传输。
智能体通常需要访问内部接口和业务数据，涉及身份认证、权限校验和数据脱敏。CPU侧是权限控制的主要执行点，需要与统一的身份系统和审计系统对接。GPU服务往往以内部接口形式暴露，同样需要做访问控制和流量限制，避免被越权调用。
CPU节点的水平扩展相对成熟，可以使用通用的容器平台和自动伸缩能力。GPU资源因为成本高、供给紧，更适合通过资源池化和配额管理来提高利用率。在容灾设计上，CPU服务可以快速跨节点切换，GPU服务则需要考虑模型加载成本和显存占用，提前制定降级预案。
智能体时代的到来，正在改变AI基础设施的资源配置逻辑。训练阶段强调单个模型在固定数据集上的收敛速度，而智能体阶段强调系统如何在复杂工作流中稳定、低延迟地完成端到端任务。这种变化让CPU重新回到核心位置，但它不再是与GPU对立的“传统算力”，而是与GPU形成明确分工的协作单元。
通用计算能力的优势在于细粒度调度、复杂逻辑处理、数据访问和系统编排，适合承担智能体的“大脑”和“执行框架”。加速计算能力的优势在于高并行数值计算，适合承担模型推理和批处理特征计算。两者并不是替代关系，而是需要在不同场景下重新平衡配比。
对于技术团队而言，最重要的事情不是追逐某类硬件，而是回到实际业务链路中，测量每一类资源的真实消耗，理解延迟从哪里产生，再据此决定CPU与GPU之间的比例、调度方式和容灾策略。只有把对比建立在真实负载之上，才能避免在供应紧张和叙事变化中做出昂贵但低效的选择。