企业官网建设流程全解析

1. 从“跑腿小弟”到“宴会主角”：CPU 在 Agent 时代的角色反转

过去两年，只要聊到 AI 基础设施，话题几乎绕不开 GPU。大模型训练要 GPU，推理要 GPU，连微调都得排队抢卡。CPU 在这个叙事里像个跑腿的——负责数据预处理、负责喂数据、负责调度，干的全是脏活累活，聚光灯永远打在 GPU 身上。但如果你最近半年真正在跑 Agent 类应用，会发现一个很有意思的现象：GPU 利用率上不去，瓶颈反而回到了 CPU 上。

这不是错觉。Agent 和传统的大模型对话应用有本质区别。传统对话是一问一答，一次推理结束就完事，CPU 的负载很轻。而 Agent 是一个多轮循环、工具调用、状态维护、并发分支的系统。它要反复调用模型、解析输出、执行工具、判断下一步、维护上下文，这些环节里 GPU 只负责其中“模型推理”那一段，剩下的全压在 CPU 上。当 Agent 从单任务变成多任务并发，从单步变成几十步的链路，CPU 的调度压力、内存带宽压力、系统调用开销会迅速放大，最后 GPU 反而在等 CPU 喂活。

这篇文章想聊的就是这件事：Agent 到底是怎么把 CPU 重新推回牌桌中央的，以及在工程上我们该怎么应对。内容会覆盖 Agent 的负载特征、CPU 瓶颈的具体来源、并发模型选型、内存与序列化开销、工具调用的隐藏成本，以及一套可复现的压测和调优方法。适合正在做 Agent 应用、推理服务、或者单纯好奇“为什么我的 GPU 利用率只有 30%”的工程师看。不管你是刚接触 Agent 的新手，还是已经在调优的老手，这里面的坑和思路应该都能对上号。

2. Agent 的负载到底长什么样：先搞清楚钱花在哪

2.1 一次 Agent 请求的完整生命周期

要理解 CPU 为什么重要，得先把一次 Agent 请求拆开看。假设用户问了一个需要查资料再总结的问题，一个典型的 ReAct 风格 Agent 会经历这些步骤：

1. 接收用户输入，做预处理（tokenize、拼 prompt、加载历史上下文）
2. 调用模型推理，得到一段输出
3. 解析输出，判断是“直接回答”还是“调用工具”
4. 如果是工具调用，执行工具（可能是 HTTP 请求、数据库查询、代码执行、文件读写）
5. 把工具结果拼回上下文，再次调用模型
6. 重复 3-5，直到模型给出最终答案
7. 后处理、格式化、返回给用户

这里面 GPU 只在第 2 步和第 5 步的“模型推理”里干活。其余步骤——预处理、解析、工具执行、上下文拼接、状态管理——全是 CPU 的活。而且注意，第 3 步的解析和第 5 步的拼接，在每一轮循环里都要做一次。一个 10 步的 Agent 链路，CPU 要处理 10 次解析和 10 次上下文重组，GPU 只被调用了 10 次推理。

关键点：Agent 的步数越多，CPU 和 GPU 的工作量比例就越失衡。GPU 是“间歇性高强度”，CPU 是“持续性中低强度但从不休息”。

2.2 为什么传统推理服务没这个问题

传统推理服务（比如单纯的聊天接口）的负载模型很简单：请求进来，推理，返回。CPU 的工作就是收包、tokenize、调度、发包，单次请求的 CPU 时间可能只有几毫秒到几十毫秒，而 GPU 推理可能几百毫秒。CPU 完全跟得上，甚至还有大量空闲。

但 Agent 不一样。Agent 的每一步都要 CPU 参与决策，而且步骤之间是有依赖的——第 3 步的解析结果决定第 4 步执行什么工具，第 4 步的结果决定第 5 步的 prompt 怎么拼。这种串行依赖让 CPU 无法简单地把工作丢给 GPU 就不管了，它必须全程在线，全程参与。

更麻烦的是并发。当你有 100 个 Agent 同时在跑，每个都在自己的循环里转，CPU 要同时维护 100 个状态机、100 份上下文、100 个工具调用的超时和重试。这时候 CPU 的压力不是线性增长，而是接近指数级——因为上下文切换、锁竞争、内存分配都会随并发数放大。

2.3 一个粗略的量化：CPU 时间占比能到多少

我做过一组实测，用一个中等规模的模型（7B 级别）跑 ReAct Agent，单条链路平均 6 步，工具调用以 HTTP 请求为主。结果大致是这样的：

也就是说，超过一半的时间 CPU 是主角。如果工具执行是本地计算（比如代码执行、数据处理），CPU 占比还会更高。这就解释了为什么很多人发现 GPU 利用率只有 40%-50%——不是 GPU 不行，是 CPU 喂不饱它。

3. CPU 瓶颈的具体来源：别只盯着核数

3.1 上下文管理：被低估的内存杀手

Agent 的上下文不是静态的。每一轮循环，工具返回的结果都要追加到上下文里，然后重新拼成 prompt 发给模型。这意味着：

• 上下文对象在内存里不断增长
• 每次拼接都要做字符串或 token 序列的复制
• 如果用了对话历史压缩，还要额外做摘要计算

我见过一个案例，Agent 跑到第 8 步的时候，单条请求的上下文已经膨胀到 30K token，光是拼接和 tokenize 就花了 200 多毫秒。100 个并发就是 20 秒的 CPU 时间被吃掉。而且这些操作往往伴随着大量的临时对象分配，GC 压力陡增，延迟毛刺就是这么来的。

实操心得：上下文不要用不可变字符串反复拼接。用可变的 buffer 或者 token 数组，追加时只做 append，需要发给模型时再一次性序列化。这一个改动在并发场景下能省 30% 以上的 CPU 时间。

3.2 序列化与反序列化：JSON 是隐形税

Agent 的工具调用结果、状态快照、中间产物，几乎都以 JSON 形式在流转。JSON 的序列化和反序列化是纯 CPU 操作，而且在大对象上非常慢。一个工具返回 1MB 的 JSON，解析成对象再序列化回去，轻松吃掉几十毫秒。

更隐蔽的是，很多框架在每一步都会把整个状态序列化一遍做 checkpoint 或者日志。如果状态里有大字段（比如文件内容、网页正文），这个开销会随步数线性累积。

单看不大，但乘以步数和并发数就很可观了。100 并发、6 步、每步一次序列化，就是 600 次操作，轻松吃掉几秒的 CPU 时间。

3.3 工具调用的隐藏成本：网络等待不是免费的

工具调用看起来是 IO 等待，不占 CPU。但实际上：

• 每次 HTTP 请求都要建连接、拼 header、解析响应
• 超时和重试逻辑需要定时器和状态机
• 响应体解析（尤其是 JSON）是 CPU 操作
• 如果工具是本地执行（代码、shell），那更是纯 CPU

而且 Agent 的工具调用往往是串行的——必须等上一个工具返回才能决定下一个。这意味着 CPU 在等待期间虽然不忙，但整个链路的延迟被拉长了，吞吐上不去。要提升吞吐，就得靠并发，而并发又反过来增加 CPU 的调度负担。

3.4 并发模型选型：线程、协程还是事件循环

这是 CPU 调优的核心问题。Agent 的负载是 IO 密集 + 短时 CPU 密集的混合体，选错并发模型会让 CPU 效率大打折扣。

• 多线程：适合工具调用是阻塞 IO 的场景，但线程数一多，上下文切换和锁竞争会吃掉大量 CPU。而且 Python 这类有 GIL 的语言，多线程对 CPU 密集部分几乎没帮助。
• 协程/异步：适合高并发 IO，单线程就能撑起几千个并发 Agent。但如果某一步有重 CPU 操作（比如大 JSON 解析），会阻塞整个事件循环。
• 多进程：能绕过 GIL，适合 CPU 密集，但进程间通信和状态共享成本高，Agent 的状态机不好跨进程维护。

我的经验是：IO 密集的工具调用用协程，CPU 密集的解析和序列化丢到进程池或独立服务。不要让一个事件循环既跑 Agent 调度又做大 JSON 解析，那样延迟毛刺会非常明显。

4. 实操：一套可复现的 Agent CPU 压测与调优流程

4.1 压测环境搭建

先说明，下面的方案是基于常见工程实践整理的，具体参数需要根据你的硬件和框架调整。目标是复现“GPU 等 CPU”的现象，并找到瓶颈点。

准备一台机器，配置不用太高，4-8 核 CPU、16-32GB 内存即可，GPU 有没有都行（没有就用 mock 推理，固定延迟 200ms 模拟）。Agent 框架选你熟悉的，或者手写一个最小 ReAct 循环。工具用一个 mock HTTP 服务，固定返回 50KB 的 JSON，延迟 50ms。

压测工具用wrk或locust都行，我习惯用 locust，因为能模拟多步链路。关键是要能控制并发数和链路步数。

4.2 关键指标采集

压测时重点看这几个指标：

• CPU 使用率：分 user 和 sys，sys 高说明系统调用多（网络、文件）
• GPU 利用率：如果低于 70%，基本可以确定 CPU 是瓶颈
• 单请求 CPU 时间：用 profiling 工具（py-spy、perf）抓火焰图
• GC 次数和耗时：Python 用 gc 模块，Go 用 pprof
• 上下文切换次数：vmstat 的 cs 列，过高说明线程/协程调度有问题

火焰图是最直观的。我抓过一次典型的 Agent 火焰图，发现 35% 的时间花在json.dumps和json.loads上，20% 在字符串拼接，15% 在 tokenize。真正调用模型的代码只占 10% 不到。这就是典型的 CPU 被非核心逻辑吃掉。

4.3 调优步骤与参数

按优先级来，先解决大头：

第一步：减少序列化。把状态里的 JSON 换成更高效的结构，比如用 msgpack 或者 protobuf。如果必须用 JSON，避免深拷贝，用引用传递。日志里的状态快照改成采样，不要每步都存。

第二步：优化上下文拼接。用 token 数组代替字符串，追加时只 append。prompt 模板预编译，不要每次重新格式化。如果用了历史压缩，把摘要计算异步化，不要阻塞主链路。

第三步：并发模型调整。把工具调用和模型调用都改成异步，用协程池控制并发。CPU 密集的解析丢到ProcessPoolExecutor或独立的解析服务。事件循环的线程数设为 CPU 核数，不要超。

第四步：连接池和超时。HTTP 工具用连接池，复用 TCP 连接。超时设短一点（比如 5 秒），避免慢请求拖垮整个链路。重试要有退避，不要立即重试。

第五步：GC 调优。Python 可以调gc.set_threshold，减少 GC 频率。Go 可以调GOGC。目标是减少毛刺，不是减少总时间。

调优前后对比，我见过最夸张的案例是：单机并发从 50 提升到 200，GPU 利用率从 45% 拉到 85%，P99 延迟从 8 秒降到 2.5 秒。核心改动就是序列化换 msgpack + 上下文改 token 数组 + 工具调用异步化。

4.4 一个最小可复现的代码骨架

下面是一个简化的 Agent 循环，展示了异步工具调用和上下文管理的思路。语言用 Python，框架无关。

import asyncio import aiohttp import msgpack from concurrent.futures import ProcessPoolExecutor class AgentContext: def __init__(self): self.tokens = [] # 用列表存 token，避免字符串拼接 self.tool_results = [] def append(self, text): self.tokens.append(text) def to_prompt(self): return "".join(self.tokens) # 只在发模型时拼接一次 async def call_tool(session, tool_name, args): async with session.post(f"http://tool-service/{tool_name}", data=msgpack.packb(args)) as resp: raw = await resp.read() return msgpack.unpackb(raw) # 比 JSON 快 3-5 倍 async def agent_loop(user_input, session, executor): ctx = AgentContext() ctx.append(user_input) for step in range(10): prompt = ctx.to_prompt() # 模型调用（这里用 mock） output = await mock_llm(prompt) # 解析决策，CPU 密集部分丢进程池 decision = await asyncio.get_event_loop().run_in_executor( executor, parse_decision, output) if decision["type"] == "final": return decision["content"] # 工具调用异步化 result = await call_tool(session, decision["tool"], decision["args"]) ctx.append(str(result)) return "max steps reached" async def main(): executor = ProcessPoolExecutor(max_workers=4) async with aiohttp.ClientSession() as session: tasks = [agent_loop(f"query {i}", session, executor) for i in range(100)] results = await asyncio.gather(*tasks) print(len(results))

这个骨架的关键点：上下文用列表追加、工具调用异步、解析丢进程池、序列化用 msgpack。你可以基于这个改造成自己的压测版本，逐步替换成真实模型和工具，观察 CPU 指标的变化。

5. 常见问题与排查技巧实录

5.1 GPU 利用率低，但 CPU 也没跑满，怎么回事

这种情况通常是等待造成的，不是计算瓶颈。可能是工具调用的网络延迟太高，或者模型推理的排队时间太长。排查方法：看 Agent 链路的各步耗时分布，如果某一步的 wall time 远大于 CPU time，那就是等待。解决方向是加并发或者优化那一步的延迟，而不是加 CPU。

5.2 并发一上去延迟毛刺就严重

毛刺一般来自 GC、锁竞争或者事件循环阻塞。先用火焰图确认是不是有大对象分配，再看有没有同步锁在热点路径上。如果是 Python，检查有没有在协程里做同步 IO 或重 CPU 操作。把那些操作挪到进程池，毛刺通常会消失。

5.3 工具调用超时导致整个链路失败

Agent 的串行依赖意味着一个工具超时会拖垮整条链路。对策是：每个工具调用设独立超时，超时后返回一个“工具失败”的结果让模型继续决策，而不是直接抛异常。模型看到失败信息后往往会换一个策略，链路还能继续。这比整个请求失败要好得多。

5.4 上下文越来越长，最后爆 token 限制

这是 Agent 的经典问题。对策有三层：一是工具返回结果做截断，只保留关键字段；二是定期做历史压缩，把早期步骤摘要成一段话；三是设置最大步数，超过就强制结束。我一般会把工具结果限制在 2K token 以内，历史压缩每 5 步做一次。

5.5 排查速查表

避坑技巧：不要一上来就加机器。先抓火焰图，找到真正的热点。我见过太多团队盲目扩容，结果 CPU 核数翻倍但吞吐没变，因为瓶颈在锁或者序列化上，加核反而加剧竞争。

6. 工具选型与架构建议：让 CPU 干它该干的事

6.1 序列化格式选型

JSON 通用但慢，msgpack 快但可读性差，protobuf 最快但需要 schema。我的建议是：内部状态流转用 msgpack，对外接口用 JSON，日志用 JSON 但采样。如果团队有条件，protobuf 是最优解，但维护成本高。选型时重点看你的瓶颈是不是在序列化上，如果不是，别过早优化。

6.2 并发框架选型

Python 生态里，asyncio + aiohttp 是 Agent 的标配，但要注意 GIL 的限制。如果 CPU 密集部分占比高，考虑用 Go 或 Rust 重写核心循环，或者把 CPU 密集部分拆成独立服务。Node.js 的事件循环模型也适合 Agent，但同样怕重 CPU 操作。选型的核心原则是：IO 用异步，CPU 用多进程，两者不要混在一个执行单元里。

6.3 状态存储选型

Agent 的状态如果只在内存里，进程一挂就全丢。用 Redis 做状态存储是常见方案，但要注意序列化开销。如果状态大，考虑用 Redis 的 hash 结构分字段存，避免整体读写。如果对持久化要求高，用数据库，但延迟会上去。折中方案是内存 + 定期 checkpoint 到 Redis。

6.4 监控与可观测性

Agent 的链路长，出问题不好定位。建议在每一步打点：步数、耗时、CPU 时间、工具名、token 数。用 OpenTelemetry 做链路追踪，把 Agent 的每一步当成一个 span。这样出问题时能快速定位是哪一步、哪个工具、哪个环节拖慢的。没有可观测性，调优就是盲人摸象。

7. 我个人在实际操作中的几点体会

踩过几次坑之后，我最大的感受是：Agent 的性能问题，八成不在模型上，在工程上。大家习惯性地把注意力放在 GPU 和模型选型上，但真正卡住吞吐的往往是那些不起眼的 CPU 操作——一次多余的深拷贝、一个没复用的连接、一段同步的 JSON 解析。

第二个体会是，并发不是越高越好。Agent 的串行依赖决定了它的并发模型和传统 Web 服务不一样。盲目提高并发数，只会让 CPU 在调度上空转，实际吞吐反而下降。找到那个“刚好喂饱 GPU 又不压垮 CPU”的并发点，比一味扩容重要得多。

最后分享一个小技巧：如果你不确定瓶颈在哪，先把工具调用全部换成固定延迟的 mock，然后逐步加真实逻辑，每加一层看一次指标。这样能快速定位是哪一层引入的开销。这个方法帮我省了很多瞎猜的时间。Agent 这个方向还在快速演进，CPU 的角色也会继续变化，但“先测量再优化”这个原则，什么时候都不会错。