AI开发者倡导者开发者倡导者 在过去的三年中，图形处理单元（GPU）主导了大型语言模型（LLM）讨论。在传统的聊天机器人应用中，中央处理单元（CPU）为每个请求提供总计算量的一小部分，而GPU则承担了繁重的计算任务。然而，推理并不是单一模型回答单一问题。对工具调用、多步骤推理和在小型专用模型之间进行编排的日益依赖，改变了计算资源的分配方式。英特尔指出，这一变化表明，CPU与GPU的比例正从训练工作负载中的1:8转变为1:1，在某些情况下甚至是4:1，在智能部署中也是如此。在这里，我们将探讨为什么使GPU成为LLM推理明显选择的假设正在被重新评估，推动CPU基于服务的新需求的原因，以及数据对产业走向的说明。 CPU擅长什么 从本质上（并无双关）看，CPU和GPU解决的根本问题截然不同。现代GPU包含数万个核心，旨在同时对成千上万的数据元素执行相同的操作。这使得它们在推理过程中占主导地位的稠密矩阵乘法方面极其快速。在训练期间，以及在高并发批量推理期间，这种并行性直接转化为吞吐量：每秒更大的令牌数(TPS)和每美元计算提供更多请求。相对而言，现代CPU的核心数从一个到数百个不等，优化了顺序、条件和分支逻辑。它们在复杂决策树中移动单个操作时特别快速。它们可以直接访问主系统内存，是包装任何模型的编排层的自然执行环境。工具分发、代码执行、Python运行时、沙盒、输入/输出（I/O）以及智能循环控制流都在CPU上。这些架构虽然本质上不同，但并不是竞争对手；它们最佳的工作方式是相辅相成。真正的问题不是哪种架构更好，而是工作负载应该放在哪里。这种劳动分工取决于我们如何衡量它们的工作：浮点每秒运算（FLOPS）与指令延迟。GPU的生死与浮点运算每秒（FLOPS）息息相关。由于AI模型是被相乘和相加的数字的巨大网络，GPU的任务就是同时进行万亿次这样的矩阵计算。它完全是为原始数学吞吐量而构建的。相比之下，CPU在指令延迟方面专精。指令延迟测量单个核心执行不可预测的一系列多样化命令的速度。CPU核心在解析JavaScript对象表示法（JSON）、处理网络I/O或检查安全权限方面表现出色。如果强行让GPU运行一个混乱的Python运行时，其巨大的FLOP能力就会闲置，因为被不断的任务切换所阻塞。如果强迫CPU处理LLM的数学，它也能完美工作，但由于缺乏巨大的并行管道而耗时很长。GPU是数学引擎；CPU是控制演出的逻辑引擎。 传统推理栈：CPU的角色 当我们考虑传统的推理栈时，我们会想到聊天机器人服务应用。在这里，CPU通常扮演支持角色。请求到达API服务器时，CPU进行标记化处理并调度请求。CPU处理所有这些初始任务。然后将请求交给GPU进行前向传播，这占据了计算预算。GPU运行注意力机制，传递前馈层，并通过简短的CPU同步获取并更新调度程序来采样下一个令牌。然后，它重复这个过程，直到发出序列结束令牌。最后，CPU收集输出并返回以结束会话。在这一模型中，CPU类似于接待员，进行协调和组织工作，而GPU则进行计算上的繁重负担。AI数据中心在训练时代的CPU与GPU的比例反映了这一点：每8个GPU大约有1到2个CPU，而这个比例更多是由GPU的吞吐量而不是CPU的需求决定的。团队配置CPU是为了保证GPU的顺利运行。这种设置正在逐渐偏离这一事实标准，随着CPU推理的进步提高了全球效率。 第一个驱动因素：代理如何改变工作负载 随着智能AI的兴起，出现了新的推理模型，扩大了对CPU特定计算需求的需求。“智能AI”的出现让人联想到集成速度，如Hermes和Openclaw，以及与编码助手紧密联系的众多代理。虽然这些用例日益流行，但智能AI并不像乍一看那样小众。事实上，许多人并没有使用“传统”的查询聊天机器人的过程。流行的AI助手如Claude和ChatGPT背后都有庞大的模型，这些模型常常结合了“推理”。