CPU重回大模型推理主舞台

GPU 不是唯一答案，CPU 也不是简单打下手

Red Hat 近日重新讨论了 LLM 推理中的 CPU-GPU 分工：GPU 仍是模型计算主力，但把所有工作都塞进 GPU，已经不再是最优解。 随着上下文变长、并发请求增多，以及 Agent、多模态等复杂应用进入生产环境，推理瓶颈正从单纯的浮点算力，转向显存容量、内存带宽、请求调度和跨设备数据移动。

CPU-GPU 分工是指推理系统按照任务的并行度、访存特征和控制复杂度，将不同工作分配给 CPU 或 GPU。 传统方案通常让 CPU 负责接收请求和准备数据，再将尽可能多的模型计算交给 GPU；新的思路则是把 CPU 当作调度器、内存扩展层，甚至在特定条件下当作并行计算参与者。

这并不意味着 CPU 要取代 GPU。恰恰相反，真正值得警惕的是两种极端：一种是认为 GPU 足够快，CPU 随便配几个核心就行；另一种是看到 CPU 内存更大、更便宜，就试图把大量 Transformer 计算直接搬回 CPU。前者会让昂贵的 GPU 等待调度，后者则可能被内存带宽、向量计算能力和跨设备传输开销拖垮。

推理已经不是一次完整的前向计算

LLM 在线推理是一个由预填充、逐 Token 解码、KV 缓存管理和请求调度共同构成的持续服务过程。 它不像离线跑一次神经网络那样，把输入丢进 GPU、等待输出就结束，而是要同时维护数十乃至数千条长度不同、状态不同的请求。

预填充是模型并行处理全部输入 Token、建立 KV 缓存的阶段。 这一阶段通常包含规模较大的矩阵乘法，计算密度高、并行度好，因此非常适合 GPU。输入越长，预填充对首 Token 延迟，也就是 TTFT 的影响越明显。

解码是模型根据已有上下文逐个生成新 Token 的阶段。 每次解码只增加一个或少量 Token，单次计算规模比预填充小，却要反复读取不断增长的模型权重和 KV 缓存，因此更容易受内存带宽、批处理规模和调度效率影响。

KV 缓存是 Transformer 在生成过程中保存历史 Key、Value 张量的状态内存。 它避免模型在每一步重新计算全部上下文，但占用会随上下文长度和并发请求数增长。模型权重基本固定，KV 缓存却是动态的，这正是生产环境中显存最难规划的部分。

以 Llama 3 70B 为例，FP16 权重约需 140 GB 内存；当单个请求使用 128K Token 上下文时，KV 缓存还可能增加约 40 GB。即便模型权重勉强放入多张 GPU，几条长上下文请求也能迅速吃掉剩余显存。此时继续采购 GPU 当然能解决问题，但未必是单位成本最优的方案。

CPU 真正回归，是因为 GPU 经常在等

多 GPU 推理中的一个反直觉事实是，GPU 利用率不足不一定代表 GPU 数量不够，也可能代表 CPU 喂不饱 GPU。 CPU 需要完成词元化、批次组装、请求状态维护、页表与 KV Block 管理、设备间同步、网络收发以及输出后处理，任何一项跟不上，都可能让 GPU 计算流出现空洞。

2026 年出现的一项多 GPU LLM 推理研究进一步量化了这种 CPU 引起的减速。研究人员在 vLLM 服务环境中改变 CPU 核心配置，发现 CPU 资源充足时，长序列工作负载的延迟加速比可达到 1.36 倍至 5.40 倍。这不是 CPU 帮 GPU 多算了几层 Transformer，而是 CPU 更及时地完成调度和同步，使 GPU 不再频繁等待。

屏障同步是多 GPU 服务中容易放大 CPU 瓶颈的机制。 当一个调度线程、通信线程或请求处理线程未能按时到达同步点时，其他已经完成工作的设备也只能等待。单卡环境中几毫秒的 CPU 抖动，扩展到多卡后可能变成所有 GPU 的共同停顿。

词元化也不是可以忽略的廉价操作。 对普通聊天请求而言，Tokenizer 的开销常被 GPU 计算掩盖；但在高并发、长文本、结构化输入或多轮 Agent 工作流中，CPU 需要频繁解析和拼接上下文。模型越快、GPU 越强，前后处理在总延迟中的占比反而越高。

这也是当前部署配置中最容易犯的错误：预算集中给 GPU，CPU 只按最低规格配套。结果是账面上买到了更多 Tensor Core 和显存，线上却出现 TTFT 抖动、吞吐下降、超时增加，GPU 监控还显示利用率忽高忽低。

哪些计算应该留在 GPU，哪些可以交给 CPU

判断任务归属的核心不是它能否在 CPU 上运行，而是它在哪一侧能以更低的数据移动成本完成。 GPU 擅长规则、密集、可批量并行的计算；CPU 擅长分支复杂、状态离散、需要频繁控制和系统调用的工作。

| 推理任务 | 更合适的执行位置 | 主要原因 | 迁移条件或例外 | |---|---|---|---| | 大规模矩阵乘法 | GPU | 算术密度高，可利用大规模并行单元 | 小模型、极低并发或无 GPU 环境可使用 CPU | | Prefill 阶段 | GPU | 长序列可形成较大的计算批次 | 显存不足时可分块或异构执行 | | Decode 阶段主干计算 | GPU | 仍需反复读取权重并执行 Transformer 层 | 批量过小会降低 GPU 利用率 | | 请求调度与 Continuous Batching | CPU | 分支多、状态变化频繁 | 调度器不足会直接造成 GPU 空转 | | 词元化与文本后处理 | CPU | 字符串处理和控制逻辑更适合通用核心 | 高并发时需要独立线程池或服务化 | | KV 缓存管理 | CPU 与 GPU 协同 | GPU 负责高速访问，CPU 管理映射与容量扩展 | 长上下文下可将冷数据卸载到主存 | | 部分 Attention 计算 | 视容量和并发决定 | 可利用 CPU 内存容纳更多请求 | 只有隐藏传输与计算开销后才值得做 | | Agent 工具调用与工作流编排 | CPU | 包含网络、数据库、代码执行和大量等待 | GPU 应在等待期间服务其他批次 | | 图像、音频预处理 | CPU 或专用加速器 | 解码、缩放、采样不一定适合占用 GPU | 批量张量变换可继续放在 GPU |

GPU 优先仍然是普通 LLM 推理的正确默认值。 2025 年发布的并行 CPU-GPU 推理研究指出，如果 GPU 显存能够容纳全部新请求的 KV 缓存，让 CPU 参与 Attention 通常没有收益，因为 GPU 的计算能力明显更强。

CPU 计算只有在解决实际容量瓶颈时才有价值。 同一项研究的实验显示，当分配给 CPU 处理的请求数量至少达到 GPU 请求数量的 8 倍 时，CPU Attention 带来的吞吐收益才足以覆盖调度、同步和数据移动开销。这个数字不是可直接套用到所有硬件的固定阈值，却说明了一个关键问题：异构执行需要足够多的并行工作，不能只把一两个请求随手扔给 CPU。

该研究采用的思路也不是让 GPU 原地等待 CPU。GPU 在检查某一层的 CPU 任务尚未完成时，会继续处理当前迭代中的其他请求，并在后续迭代再次检查。其本质类似于餐厅后厨：慢工序不该堵住整个出餐口，而应由调度器安排其他订单先向前推进。

KV 缓存卸载，比搬运模型权重更现实

KV 缓存卸载是把部分不活跃或暂时用不到的 KV 数据从 GPU 显存移动到 CPU 内存，并在需要时取回。 与完整迁移模型层相比，KV 缓存天然按请求和 Token 分块，更容易根据冷热程度、上下文位置和服务优先级管理。

CPU 内存的容量通常远大于单张 GPU 显存，因此适合作为 KV 缓存的容量层。对于长上下文请求，可以把近期高频访问的数据留在 GPU，把较冷的历史块放到主存；对于暂停等待工具结果的 Agent 请求，也可以暂时释放其 GPU KV 空间，让其他活跃请求进入批次。

KV 缓存卸载的最大风险是传输延迟抵消容量收益。 如果每生成一个 Token 都要跨 PCIe 频繁搬运大量数据，GPU 会不断等待总线，系统虽然不再显存溢出，吞吐却可能更差。因此，卸载策略需要按块迁移、提前预取，并尽量把数据移动与 GPU 计算重叠。

Grace Hopper 和 Grace Blackwell 这类 CPU-GPU 紧耦合架构进一步改变了边界。以 GH200 为例，CPU 内存最高可达 480 GB，GPU 显存最高可达 144 GB；NVLink-C2C 提供内存一致性和统一地址空间，使 CPU 与 GPU 可以访问同一套内存映射，减少显式复制和重复分配。这不等于 CPU 内存拥有与 HBM 相同的性能，但会让超出显存容量的模型和 KV 缓存更容易管理。

统一内存解决的是可访问性问题，而不是自动解决性能问题。 一块数据能被 GPU 透明访问，不代表它位于最合适的位置。缺页迁移、访问局部性和带宽差异仍会影响延迟，生产系统依然需要明确热数据驻留策略。

Agent 和多模态让 CPU 变得更重要

Agent 推理是一种模型生成与外部工具执行交替发生的工作负载。 模型可能生成几十个 Token 后暂停，等待搜索、数据库查询、浏览器操作或代码执行，拿到结果后再继续推理。这会产生大量短周期、状态化、不可预测的请求。

传统的静态批处理很难适应 Agent。一个请求暂停时，其 KV 缓存仍占用显存；如果系统不支持抢占、换出和恢复，GPU 容量会被大量等待中的会话占据。CPU 此时不仅负责工具编排，也应负责会话状态、优先级、缓存换入换出和失败重试。

多模态推理会进一步增加 CPU 侧的预处理与数据编排。 图片需要解码和缩放，音频需要重采样和切片，视频需要抽帧，文档需要解析版面。把这些任务无差别放到 GPU，可能挤占真正用于模型推理的显存和计算队列；全部放在单个 CPU 线程上，又可能成为新的入口瓶颈。

更合理的系统不是固定宣称某类数据归 CPU 或 GPU，而是为任务建立成本模型：数据当前在哪里、搬运需要多久、GPU 队列是否拥堵、CPU 是否有空闲核心、请求的延迟目标是多少。只有调度器能看到这些信息，异构硬件的总吞吐才有可能超过单纯堆 GPU。

开发者该怎么重新配机器

LLM 部署应从 GPU 单点选型转向整机级容量规划。 显卡型号和数量仍然重要，但 CPU 核心数、内存容量、NUMA 拓扑、PCIe 通道、网卡位置和线程绑定，同样会决定最终性能。

建议至少分四步排查：

1. 先区分计算受限与容量受限。 如果 GPU 计算单元长期接近满载，增加 CPU 通常不会提高主干计算吞吐；如果 GPU 利用率不高却出现请求排队，就要检查调度和数据供应。
2. 分别记录 TTFT、TPOT 和端到端延迟。 TTFT 是首个 Token 时间，TPOT 是后续每个 Token 的平均间隔；前者更容易受预填充和排队影响，后者更能反映解码与 KV 访问效率。
3. 按 CPU 核心数做阶梯测试。 不要只测试一种云主机规格，应逐步增加可用核心并固定 GPU、模型、上下文和并发数，观察吞吐何时停止增长。
4. 检查 NUMA 与设备亲和性。 当负责某张 GPU 的 CPU 线程和内存位于另一个 NUMA 节点时，请求会绕行跨插槽互联，延迟和抖动都可能上升。
5. 最后再决定是否启用 CPU Offload。 卸载是显存容量不足时的工程手段，不是默认的性能优化开关；必须用真实请求分布验证，而不是只看模型能否成功加载。

CPU 配置不足和 CPU 卸载是两个不同问题。 前者意味着 CPU 连调度、词元化和通信都来不及完成，应该优先补足核心和内存带宽；后者意味着系统主动让 CPU 承担缓存或计算，以换取更大的并发容量。不能因为系统存在 CPU 瓶颈，就推导出应该把更多模型算子迁到 CPU。

结论：分工边界正在变成动态调度问题

LLM 推理的新共识不是 CPU 重新战胜 GPU，而是固定分工正在失效。 GPU 依旧应该承担矩阵乘法、Prefill 和大多数 Decode 计算，CPU 则必须拥有足够资源处理服务调度、词元化、缓存管理、网络通信和 Agent 编排。

只有在显存容量限制并发、CPU 工作可与 GPU 计算重叠时，部分 Attention 或 KV 缓存卸载才真正有意义。 如果数据必须在设备之间高频往返，或者 GPU 本身还能容纳全部请求，CPU 参与计算大概率只会增加复杂度和延迟。

Red Hat 这次重新审视 CPU-GPU 分工，真正有价值的地方不在于提出了一个新的硬件口号，而在于提醒开发者：推理性能属于整个系统，而不是某一张加速卡。下一阶段的竞争，也不会只是比较 GPU 峰值算力，而是比较谁能让计算、内存和调度在正确的时间出现在正确的位置。

参考来源

• vLLM GitHub 仓库：高吞吐 LLM 推理与服务框架，包含 PagedAttention、连续批处理等关键实现。
• LLM 原生的硬件计算架构：掌握控制权：讨论 AI 时代 CPU、GPU 与软件栈分工边界的重构。
• Hugging Face 上的 vLLM 组织页面：可查看 vLLM 社区公开的模型与相关资源。