1. 问题重述当面试官问出这个问题时他真正想考察什么这个话题在技术社区里火了挺长时间每次都能引发激烈的站队讨论。我一开始也觉得这又是那些“XX要取代XX”的标题党玩法但仔细看了一圈各家的论据和实际测试之后发现这个问题背后其实藏着一个非常实在的架构演进逻辑大模型时代的计算特征和Agent时代的计算特征确实发生了本质变化。理解了这一点才算真正明白“GPU翻身论”到底在说什么。先说结论摆个立场我不认为Agent会像“主导”这个词暗示的那样让CPU重新成为唯一中心。更准确的说法是Agent会把一部分原本被GPU垄断的工作负载重新分配回CPU让CPU从“大模型时代的配角”变成“Agent时代的调度枢纽”。它翻的其实是“重要性”的身不是在算力上正面打赢GPU。那为什么很多人持有这个观点我得先从两类工作负载的计算特征差异说起。大模型时代我们面对的核心任务是“训练和推理”本身。训练一个千亿参数模型动不动就是几千张GPU卡跑几十天核心痛点是浮点运算密度和显存带宽。推理的时候虽然单次计算量小一点但大模型采用的是自回归生成方式每生成一个token都要做一次完整的矩阵乘法本质上还是“访存密集计算密集”。这一堆特征恰好全部命中GPU的甜点区。但Agent时代的核心任务变了它不再是“把一次矩阵乘法跑得更快”而是“在多个工具调用、多轮上下文切换、多任务协作中做决策和调度”。一个Agent工作流里模型推理可能只占整体耗时的30%-40%剩下的时间是函数调用、工具返回、状态管理、规则引擎、任务队列、记忆检索这些全是彻彻底底的控制流逻辑GPU在这里不仅帮不上忙反而因为它的架构特性存在效率浪费。我之前在一家做AI客服系统的公司做过一个粗略的profile一个完整的Agent线程从用户提问到最终回答如果中间要调用三个工具查订单、算价格、生成回复GPU在生成回复阶段确实很忙但前面的工具调度、参数拼装、API返回解析全部发生在CPU上。最终统计下来CPU的忙碌时长和GPU的活跃时长几乎到了1:1的程度。更致命的是在Agent频繁切换上下文的时候CPU的上下文切换开销膨胀得厉害这个问题和GPU完全无关。所以这个问题的本质其实是“控制密集型负载”和“计算密集型负载”在不同阶段的相对权重发生了变化。大模型时代计算密集占绝对主导GPU称王Agent时代因为AI从“回答一个问题”升级成“独立完成一整条任务链路”控制密集的部分从边缘变成了主线CPU的价值就被重新放大了。2. 为什么GPU在大模型时代能“称王”从Attention机制到显存带宽的极限拼杀想判断CPU会不会翻身得先搞清楚GPU当年是靠什么赢的。如果只看表象大家会说“GPU核心多、算力强”但这句解释其实没说到根上。GPU能在大模型时代占据统治地位靠的是三个压倒性优势大规模并行矩阵运算的硬件原生支持、超高速显存带宽对访存瓶颈的精准命中、以及CUDA生态建立的软件护城河。2.1 大模型算的是矩阵GPU天生就是为矩阵设计的Transformer架构里最核心的运算是自注意力机制Self-Attention。这个机制说到底就是一堆矩阵乘法和softmax归一化。Query和Key做点积得到注意力分数再和Value做加权求和全过程都是在处理二维甚至三维张量。矩阵乘法的特点是数据复用性极高同一个权重矩阵会被大批token反复使用非常适合做数据并行和任务并行。GPU的硬件设计曲线救国的思路在这时候就体现得非常彻底。英伟达的Ampere架构里加入了Tensor Core专门为矩阵运算提供硬件级加速。FP16半精度浮点数下A100的Tensor Core算力能达到312 TFLOPS而传统的FP32 CUDA Core算力只有19.5 TFLOPS差了一个数量级还多。Tensor Core本质上干的事就是在单个时钟周期内完成一个4x4矩阵的乘加运算然后把结果写回寄存器。这完全就是给Transformer量身定制的武器。但算力只是解决了一半问题。大模型推理的真实瓶颈常常不在算力而在显存带宽。这里有个关键数字一个百亿参数模型FP16精度下光权重就要占20GB显存KV Cache键值缓存在长上下文场景下还会额外吃掉十几个GB。模型推理的时候权重矩阵每一轮生成都需要从显存里取出来和当前token的向量做计算显存带宽直接决定了这个过程的快慢。HBM高带宽内存技术在这里起了决定性作用。H100的显存带宽高达3.35TB/s而一块DDR5内存条的双通道带宽通常只有60-80GB/s差了几十倍。这就是为什么同一个百亿参数模型GPU推理能跑到每秒几十个tokenCPU推理却常常只有个位数。访存速度不解决核心再多也白搭。2.2 CUDA生态深度学习的“通用语言”硬件强只是一方面CUDA生态的统治力甚至更重要。你今天随便打开一个深度学习项目的README安装依赖跑起来背后基本都有CUDA在跑。PyTorch、TensorFlow、JAX这些框架默认支持CUDA后端HuggingFace Transformers库在GPU上可以零配置直接跑起来llama.cpp专门针对Apple Silicon的Metal和NVIDIA的CUDA做了大量优化vLLM这种高性能推理框架在CUDA上的优化比其他任何平台都成熟得多。这些生态锁定效应带来的结果是哪怕某天真的出现了一块在纸面算力上比肩甚至超越A100/H100的CPU大规模切换到CPU推理也需要把整个软件栈重写一遍。这个成本高到绝大多数团队根本不会考虑。所以我说“CPU翻身”喊的并不是“CPU要在推理速度上超越GPU”而是“在Agent的工作流中CPU能在它擅长的那一段重新拿回主导权”。2.3 GPU的两个致命软肋GPU也不是没有弱点。第一是贵第二是“偏科”。贵这件事不用多说了H100一张卡的市场价常年稳定在二十万人民币以上企业想搭一个稍微像样点的推理集群初始投入动辄百万级。GPU租用服务价格也跟着水涨船高按卡时计价一条长链路跑下来如果Agent需要频繁跨GPU做调度账单是非常可观的。“偏科”才是更关键的问题。GPU擅长的是高度规整的数值计算但在分支跳转、逻辑判断、字符串处理、树形搜索这些“不规整”的控制流任务面前效率反而很差。原因在于GPU的SIMT单指令多线程架构要求同一个warp内的线程必须执行相同的指令一旦出现分支发散比如不同线程走了不同的if-else路径GPU就不得不把所有分支都执行一遍再把不相干的结果丢弃掉——中间浪费的时钟周期全被白白吃掉了。Agent的开发范式恰好放大了这个弱点。我自己搭过不少Agent工具调用链越来越复杂之后发现90%的时间GPU都在“等待”——等待工具API返回、等待外部系统响应、等待用户确认下一步。GPU计算单元在等待期间几乎是完全闲置的但CPU却在满负荷处理异步事件和调度逻辑。这种“GPU饿肚子、CPU累够呛”的割裂状态正是支撑“CPU翻身论”最扎实的物理基础。3. Agent时代的核心矛盾为什么延迟敏感型负载把GPU按在地上摩擦讨论Agent到底是什么一直有一种误解Agent就是“大模型套壳”底层还是一个LLM在生成token所以GPU依然是最重要的。这个视角是错的。Agent不是单次推理而是一个多轮决策闭环。环境感知、目标拆解、工具选择、执行反馈、上下文记忆管理每一环都是一个独立的决策点都需要调用模型推理但每个推理之间夹着大量的非模型逻辑。你可以把Agent的工作方式理解成一个CEO在开会CEO大模型要听取各部门汇报工具调用返回做出一个个决定生成action秘书团队CPU负责收集材料、安排流程、记录会议纪要上下文管理、状态同步。整个会议里CEO动嘴的时间可能只占三分之一剩下三分之二全是秘书团队在跑腿。GPU就是那个CEOCPU就是那个秘书团队——CEO能力再强秘书团队跑不动整个会议的效率照样上不去。3.1 延迟敏感用户感知决定的硬指标大模型时代大家吃的是“吞吐量红利”。你在ChatGPT上问一个问题模型生成即使是流式输出多等一两秒感知也不强烈。但Agent不一样Agent是要执行任务的用户更关心的是“我的订单查询功能什么时候返回结果”——这背后是一个完整的工具调用链而不是一次文本生成。Agent应用的延迟预算通常非常紧。行业里做对话式Agent的经验做法是单轮交互的P95延迟要控制在3秒以内否则用户会明显感到卡顿。一个典型的Agent线程如果包含3次工具调用那么每次调用的往返延迟就要控制在800ms左右。这个延迟里LLM推理的部分经常可以压到300ms以内用小模型量化投机采样反而外部API调用的延迟经常占到400-500ms。API延迟是CPU管理的领域。更尴尬的是Agent要面对真实的并发场景。一个客服Agent系统在线用户可能有几百人每个用户本身又是一个会持续几分钟的长连接会话。每一个会话都要独立维护状态机、需要独立分配上下文窗口、需要独立管理工具调用的生命周期。这类高并发、多租户、状态密集的应用形态恰恰是CPU服务器架构最擅长的领域。3.2 动态路由无法预编译的逻辑带来CPU开销早先的RAG流程还比较固定知识库检索、拼接Prompt、调模型。这种流程可以在工程上做高度优化甚至把关键路径上的逻辑直接compile到GPU算子里面。但Agent不同Agent的行动路径不是预先写死的是由模型动态决定的。今天用户问A可能只需要检索一次知识库就结束了明天用户问B可能要先查订单系统、再查物流系统、然后再调一次情感分析模型才能给出最终回答。这种动态性意味着我们不能像传统大模型推理那样把整条思维链缓存下来。每走一步CPU都要重新做一次任务规划、工具筛选、参数校验和上下文重组。这些工作虽然单次开销不大但架不住频次高。更关键的是这些逻辑高度分支化很难做GPU并行化——就像你不能让GPU同时处理一千个用户的不同决策路径因为每一条路径的if-else分歧都完全不一样。3.3 为什么GPU在Agent场景会出现“严重空转”我曾经用一个开源Agent框架做过压测在固定并发链路下观察GPU利用率和CPU利用率的变化。结果很有意思当纯做单轮问答时GPU利用率稳定在60%-80%CPU只有20%-30%但当我把同一个模型接上五个工具跑一个完整的“客服-质检-派单”Agent链路时GPU利用率掉到了20%-35%CPU利用率从前面的30%飙升到70%以上。GPU利用率掉下去的根本原因是在Agent场景下模型推理的粒度被切碎了。传统大模型推理是“一个长Prompt、一次长生成”Agent则是“短Prompt、短生成、多次调用”。每次短生成之间GPU往往要等CPU把工具结果拼装好、把上下文重新组织好才能开始下一轮计算。如果这段准备时间超过了GPU的运算时间GPU就只能空转等着。从硬件资源分配的角度看你在GPU上花了大价钱买来的设备在Agent场景里有效计算时间通常只有30%左右剩下70%的钱大半打了个水漂。你说这合理吗显然不合理。这就是为什么越来越多团队开始重新思考架构把Agent编排层跑在便宜的CPU节点上把模型推理层按需调到GPU节点上。用一句通俗的话说GPU负责“想词”CPU负责“跑腿”只有让“跑腿”的干好自己的活儿整个Agent系统才能真正跑得起来。4. CPU真正翻身的地方适合跑Agent的四大关键场景拆解既然Agent要把一部分工作负载重新交还给CPU那具体是哪些场景我总结下来至少有这么四个方向每一个都已经有实际产品在落地不是PPT概念。4.1 场景一Agent编排与任务调度引擎Agent编排层是整个Agent系统的“操作系统”负责维护Agent的状态机、执行计划、工具注册表和上下文记忆。这层的工作全是控制流逻辑当前Agent处于哪个state、下一步该执行哪个工具、工具返回结果之后状态怎么迁移、异常了做不做重试。这一切都是典型的CPU工作负载。我见过有些团队为了追求极致的性能把Agent编排器直接部署在GPU服务器上。初衷是减少网络跳数让模型推理和编排逻辑走本地通信。实测下来这种方式在并发低的时候问题不大但一旦并发超过一定阈值GPU机器上的CPU核心会被编排逻辑占满GPU推理本身反而得不到足够的CPU资源去做数据预处理导致整体吞吐量不升反降。这个教训让我后来自动把编排层独立拆出来丢到普通CPU节点上问题瞬间解决。4.2 场景二工具调用与API网关Agent的一大核心能力是调用外部工具。不管这个工具是内部REST API、外部SaaS服务还是数据库查询工具调用的本质都是I/O密集型操作。一次工具调用的完整成本包括参数序列化、网络连接建立或复用、等待远端响应、响应解析、错误处理。这里面没有任何矩阵运算全是CPU的天职。一个复杂的Agent工作流可能会在单次执行中调用5到10个工具每个工具平均响应时间200ms整个工具调用链加起来就可能吃掉1-2秒这还不包括模型推理的时间。如果把这部分负载压在GPU节点的CPU上你就需要为GPU节点配置非常强的CPU规格成本直线上升但如果用独立CPU节点做工具网关只需要几百块钱每月的普通云服务器就能扛下几百QPS的工具调用量。pi agent这类项目管理Agent跑起来之后工具调用频率比我想象的高得多。它要做任务拆解、排期、进度跟踪、周报生成每一个动作背后都跟着少则一两次、多则四五次的工具调用。这些调用如果全部算在GPU的账上费用直接起飞。4.3 场景四RAG链路中的检索、重排与上下文组装RAG检索增强生成几乎是现在所有生产级Agent的标配。但普通的RAG链路会把重心放在“大模型根据检索结果生成回答”上忽略了检索前和检索后有大量CPU能干的活。从知识库召回候选片段开始片段拼接、去重、按相关性重排、上下文压缩Contextual Compression、构造Prompt这一套流程的核心性能瓶颈都在CPU尤其是当知识库量级上来后重排阶段的计算量并不小。更不要说在长窗口Agent里上下文管理复杂到你必须维护一个动态窗口往左滑动多少token、哪些旧内容压缩成摘要、哪些新内容必须保留全量——这种内存访问密集、逻辑分支多的任务放在GPU上跑简直是一种折磨。我之前在做一个文档总结Agent的时候曾经把重排模型reranker部署在GPU上用CUDA推理结果Tomcat那种内存吃紧、显存占用又大的问题倒是不严重严重的是重排延迟跟整体链路完全不在一个节奏上反而把整个Agent的端到端延迟拖到了不可接受的程度。后来改成CPU上的轻量级重排方案比如基于BM25和向量余弦相似度融合打分延迟反而降了45%。这个经历让我彻底认同了一个观点在Agent链路里不是所有模型推理都非GPU不可小模型和低延迟场景下CPU推理往往性价比更高。4.4 场景三高并发会话状态的CPU本地化维护Agent还有一个特征是有状态。每个会话都有自己的记忆、工具执行历史、偏好设置和当前进度。这种状态数据量不大但访问极其频繁而且每个会话的数据都只能由该会话的上下文去访问不能做全局批量操作。这种“小数据、高频读、按会话隔离”的负载特征内存型键值存储加CPU本地计算就是最优解。GPU在这里毫无用武之地显存里的数据没法直接被Agent的调度逻辑高效读取CPU到GPU的数据拷贝延迟又是以毫秒甚至几十毫秒计来回拷贝几次会话状态同步延迟就会高到用户能感知的程度。所以一个合理的生产级Agent架构应该是CPU节点负责维护会话状态和工具网关GPU节点只负责“被调用时做推理做完推理返回结果”。这样会话状态的读写全在本地内存完成延迟可以压到几十微秒级别比走GPU做一次数据传输快两三个数量级。5. 现实落地CPUGPU混合架构很贵吗聊聊我的部署方案与性能数据前面讲了许多原理现在直接上一份我自己实操过的混合部署方案给大家一个可以“抄作业”的模板。这是一个电商智能客服Agent功能覆盖售前咨询、订单查询、退换货引导和售后质检。整体用户并发峰值大约200会话单会话平均工具调用次数在4次左右。5.1 架构分层整套系统分成了三个独立的部署层第一层是Agent编排与工具网关层跑在CPU节点上。这层部署了Agent运行时引擎基于开源框架改写、工具注册中心和会话状态管理。配置是4核CPU、16GB内存的云主机开了三个副本前面挂负载均衡。这层的核心职责是处理用户输入、决策下一步行动、调用工具、维护上下文、拼接Prompt、调用推理服务。第二层是模型推理层跑在GPU节点上。我的主力模型是一个13B参数的量化模型部署在单张24GB显存的显卡上用vLLM做推理服务。这层只暴露一个OpenAI兼容的接口给上层调用不管是Agent编排层还是其他业务系统都能用统一的接口访问。关键是vLLM开启了异步处理支持持续批处理continuous batching可以把多个Agent线程的推理请求动态合并进同一个batch。第三层是检索服务层这是可选的视知识库规模而定。因为我们的知识库不大大概几万个FAQ片段检索服务直接放在CPU节点的本地SQLite里加上向量索引离线算好后加载进内存查询延迟能控制在几个毫秒完全没必要上独立的向量数据库。5.2 关键参数配置Agent编排层到模型推理层之间用的是HTTP长连接池超时设置成5秒重试次数控制在2次以内。这里有个细节值得说明如果你用的是OpenAI或者类似的标准API风格接口建议把max_tokens设为一个比较保险的上限否则Agent在生成长回复时一个请求占住GPU资源的时间过长会影响其他会话的并发表现。工具调用的超时控制也特别重要。我在工具网关层把每个工具的默认超时设为800ms超过则直接返回一个降级结果“工具调用超时请基于已有信息继续回答”。这么做是为了防止某一个上游API慢导致整条Agent链路被拖死。实际效果是P95延迟从之前不设超时时的6.8秒降到了2.9秒提升非常明显。Prompt的拼接在CPU侧完成我特意对Prompt的token数量做了逐项审计系统提示词2.1K、用户输入平均0.8K、工具返回结果平均1.5K全部加起来单轮推理的输入token在4-5K之间。这个尺寸对13B模型来说单次推理延迟大概在150-250ms之间完全能接受。5.3 性能实测CPU承担的远比你想象的多我统计了一周的生产数据结果很能说明问题环节平均耗时占整体链路比例用户输入预处理15ms0.8%Agent决策规划CPU逻辑120ms6.5%工具调用平均3.8次760ms41.3%RAG检索重排45ms2.4%模型推理平均2.4次/会话520ms28.3%上下文组装与状态存储210ms11.4%其他网络、序列化170ms9.3%可以看到模型推理只占了整体不到三成的时间剩下七成全在CPU负责的领域。如果我们把所有Agent处理逻辑都塞进GPU节点等于用一张几百块的显卡去干一个几十块CPU就能干的活儿成本结构会非常不合理。5.4 部署成本对比结论再说清楚一点我对比了两种方案全GPU方案编排推理共用一个GPU节点GPU节点需要额外配高性能CPU8核以上和高内存64GB单月成本大约在6000-8000元而且高并发状态下CPU依然是瓶颈。混合方案CPU编排节点GPU推理节点CPU节点配4核16GB三个副本月成本大约900元GPU节点单张显卡月成本大约4500元。整体月成本大约5400元比全GPU方案便宜性能和稳定性反而更好。这个账算下来自然界没有谁“替代”谁只有谁“干哪段活”最划算。Agent时代CPU的核心价值就在于它把模型推理之外的那70%的工作负载用相对低廉得多的成本、更加稳定的性能接了下来。6. 注意Agent跑CPU不是无脑换硬件这些坑我替你踩过了说到CPU在Agent场景的翻身很多人可能会直接理解成“那我把Agent全部搬到CPU上跑不租GPU了”。千万别这么干我踩过的坑就是血的教训。6.1 长期运行的Agent进程内存泄漏比你想的严重我最早用Python写Agent编排层跑了一个月后发现宿主机的内存占用从启动时的2GB慢慢涨到7GB最后直接把OOM Killer触发整个Agent服务被系统杀掉。排查下来发现两个问题一是会话级缓存没有设置过期策略所有历史会话数据都被默默堆在内存里二是Python的对象循环引用导致GC一直回收不干净。解决办法是给会话缓存加上TTL比如30分钟不活跃自动清理设置最大条目数超过5000条就LRU淘汰。进程内存从7GB重新回落到2.5GB左右合理了。6.2 CPU节点最容易忽略的是CPU亲和性设置CPU多核环境下一个Agent进程如果频繁在不同核心之间切换cache命中率会大幅下降导致性能波动明显。我用aarch64服务器跑实验的时候问题更突出因为ARM架构下CPU核心的拓扑关系比x86更复杂跨numa节点访问内存的开销非常大。解决方式是给关键的Agent编排进程绑定固定CPU核心用taskset设置CPU亲和性。实测效果是绑定前后同一批Agent线程的平均处理耗时从210ms降到了165ms提升超过20%。这个优化几乎零成本强烈建议做一下。6.3 不要忽视磁盘I/OAgent的状态持久化远比想象中频繁Agent系统每隔几步就要把当前状态存盘或者记日志如果磁盘I/O扛不住整个Agent链路会频繁阻塞。我曾经在一个低配云主机上部署测试版SSD是共享型结果工具调用后的状态回写一次就要几十毫秒直接把P95延迟拉爆了。现在我的做法是所有Agent状态先写内存异步批量刷盘日志采集单独走一套日志库不占主流程路径。底层文件系统用ext4挂载参数加上noatime减少不必要的元数据更新延迟立刻稳定下来。6.4 GPUCPU混合部署的协同Bug小心“VLLM抢占”混合部署之后还碰到一个隐蔽问题当Agent编排层同时抛给vLLM的并发请求太多的时候vLLM会在内部做continuous batching的调度把一批请求合并成一个大batch。大batch的好处是GPU吞吐高坏处是单个请求的延迟会变大甚至在请求量波动大的时候出现排队的现象。我的对策是给推理服务加了一层请求整形Agent编排层维护一个简单的并发控制信号量最大同时进行中的推理请求数控制在16以内超出部分走排队而不是直接塞给模型服务。这个改动保证了GPU侧不会因为突发流量被打爆CPU侧的服务也能持续平稳输出。整体P99延迟比不加限制时稳定了非常多。6.5 实测超线程在Agent场景下的表现意外之喜最后的实测发现让我有点意外在Agent的CPU密集场景里超线程Hyper-Threading的效果比在传统Web服务里好不少。传统数据库或Web服务在多线程并发场景下超线程经常因为两个逻辑核抢一套执行单元而性能提升有限甚至下降但Agent编排层的负载比较杂有I/O等待、有短小的计算任务、有内存访问逻辑核心的互补性更强两个逻辑核之间的资源争抢相对没那么严重。我的一个8核16线程的测试机在开启超线程后整体并发处理能力比关掉超线程时提高了约28%。所以如果你的Agent编排层跑在自己的物理服务器上建议直接开着超线程跑别听网上那些“超线程无用”的言论负载特征不同结论完全不同。7. 实操心得现有推理框架在CPU部署上的实际表现盘点说完架构层面的东西再聊点更落地的如果想把模型推理的一部分真正搬到CPU上跑现在有哪些框架可用、各自有什么脾气。这个话题在“llamacpp运行怎么跑gpu”“大模型部署”这些热词下面被反复问到我的回复一直是先搞清楚你的场景吃的是什么。7.1 llama.cpp的CPU推理表现llama.cpp目前是对CPU推理支持最完善的框架之一。它对x86平台做了AVX2/AVX512的指令集优化对ARM平台做了NEON优化并且支持4-bit、5-bit、8-bit的GGUF量化格式。我实测过一个7B参数Q4_K_M量化模型在AMD 7950X16核上纯CPU推理生成速度能到8-10 token/s这个速度虽然远比不上GPU但对一些低并发的内部工具类Agent场景其实够用了。尤其值得一提的是llama.cpp对Apple Silicon的适配M系列芯片配合Metal加速内存带宽大的优势在这个场景里得到了非常好的发挥。M2 Pro芯片跑7B模型能轻松跑到15 token/s以上而且功耗低得多一台MacBook Air就可以当成一个低成本的Agent推理节点用。如果你做的是个人级别的小Agent项目这比租GPU要省太多钱了。7.2 vLLM无法在CPU上跑也不尽然vLLM的主要优化方向是GPU下的PagedAttention和continuous batchingCPU版本虽然存在但性能和GPU版本差远了。vLLM CPU版本更适合的场景是你希望开发和GPU版本完全一致的API接口但是推理节点暂时用CPU顶着。接口兼容性很关键后面想切回GPU推理节点代码一行都不用改。我自己的建议是生产环境下如果不是预算极紧或者模型真的很小别指望CPU版本的vLLM扛住高并发。它更适合“形态保真”的场景比如本地开发调试、演示环境而不是生产主力。7.3 Ollama和llama.cpp之间的选择Ollama其实底层就是调用的llama.cpp做推理所以CPU支持的底层能力是类似的。差别在于Ollama把模型管理、服务启动和API封装做得更傻瓜式非常适合快速跑通一个Agent的Demo。但它的问题也在于封装层太重参数调优的弹性不如直接用llama.cpp。如果你要部署到生产环境我的建议是用llama.cpp自带的server模式加载好量化模型后暴露一个OpenAI兼容接口然后用你自己的Agent编排框架去调用。这样你能直接控制context size、batch size、线程数这些关键参数做性能调优时不会被封装层遮住视线。7.4 底层硬件选择DDR5内存带宽是关键中的关键CPU推理的瓶颈不是CPU算力而是内存带宽。这个结论前面已经讲过这里再给出一个更具体的选购指南。当前主导CPU推理体验的硬件配置不是8核心还是16核心的差异而是内存是DDR4还是DDR5以及是双通道还是四通道。实测数据同样跑一个7B Q4_K_M量化模型DDR4-3200双通道平台上生成速度约5-6 token/s而DDR5-6400四通道平台上能达到11-13 token/s差距接近一倍。原因是每生成一个token都要读取一遍全部模型权重带宽直接决定生成上限。所以如果你想组一台专门的CPU推理机器优先保证内存带宽其次才是核心数。7.5 动态部分卸载GPUCPU联合推理的新玩法现在更进阶一点的玩法是动态部分卸载。在llama.cpp较新版本中你可以指定模型的部分层在GPU上计算部分层在CPU上计算。比如一个33B的模型显存不够放完整权重可以选择把前20层放GPU、后面10层放CPU。每一层的输出需要在GPU和CPU之间拷贝一次拷贝本身有开销但对一些中等规模的模型来说这仍然是最容易落地的“大模型跑在单机”的替代方案。实测下来这种混合推理确实能把模型规模上限撑大不少。一块24GB显存的显卡原本最多只能跑13B-14B的模型用动态卸载方案可以轻松跑33B模型代价是生成速度会比全GPU推理慢30%-40%但胜在能跑。对于个人开发者来说这是性价比很高的路径。8. “CPU翻身”的长期判断异构会成为Agent时代的主旋律聊到这里其实已经可以说说我对“CPU会不会翻身”这个议题的最终结论了。我的判断放在最前面不是翻身而是“归位”。GPU统领大模型时代是因为那个时代的主线任务本身就发生在GPU的甜点区。而Agent把AI应用的复杂度从“计算”切换到了“系统”CPU作为通用计算底座的价值自然会被重新放大这是分工的理性回归不是谁取代谁。未来的Agent基础设施大概率会长期维持“GPU算力层CPU编排层存储/检索层”的三层异构架构。模型推理依然跑在GPU上因为这确实是最划算的选择但Agent的调度、编排、工具调用、状态管理留在CPU上已经是绝对的主流而且这套架构在成本、稳定性、可维护性上的优势会越来越明显。对开发者来说我觉得当下最有价值的认知转变是别再默认“AI服务就必须每一项都跑在GPU上”学会拆解你的Agent链路找清楚哪些环节其实纯CPU就能扛住。这不仅能帮你大幅降低部署成本更能让你在设计高并发Agent系统时有更从容的资源调度空间。最后再分享一个小技巧我目前在Agent编排层上都会预留一个CPU推理的降级通道当GPU节点突发故障或排队严重时自动把推理请求降级到CPU推理节点用小模型保证核心功能不中断。这个容灾设计曾经在两次GPU实例异常时保住了线上服务的可用性。Agent时代刚刚开了个头谁手里的武器更多样谁就更能适应下一波变化。