1. 先搞清楚多 Agent 并发到底在消耗什么资源很多人一上来就问16 核 32G 能扛多少个 Agent这个问题本身就问错了。Agent 的资源消耗跟传统 Web 服务的并发模型完全不是一回事。一个 HTTP 接口的并发瓶颈通常在 CPU 和连接数上请求进来、查库、返回生命周期短则几毫秒长则几百毫秒。但一个 AI Agent 的一次运行可能包含十几轮 LLM 调用、若干次工具执行、向量检索、文件读写生命周期从几十秒到几分钟不等。这意味着你不能用QPS那套思路来估算 Agent 的并发容量。你得先拆开看一个 Agent 实例在运行期间到底占着哪些资源、占多久、什么时候释放。1.1 Agent 运行时的四类资源占用我把一个典型 Agent以 FastAPI LangChain/LangGraph 这类技术栈为例运行时的资源占用拆成四块第一块是进程本身的基础内存。一个 Python 进程加载完 LangChain、向量库客户端、各种工具依赖之后常驻内存通常在 300MB 到 800MB 之间。这个数字跟你的依赖有多重直接相关——如果你还引入了 PyTorch 做本地 embedding那基础内存直接飙到 2GB 以上。这部分内存是每个进程都要付的固定成本跟并发量无关。第二块是单次 Agent 运行的工作内存。对话历史、中间推理步骤、工具返回结果、检索到的文档片段这些都存在内存里。一次复杂任务的上下文可能累积到几十 KB 到几 MB 的文本。如果 Agent 会处理图片、PDF那内存占用还要再上一个量级。第三块是 LLM 调用的等待时间。这是最容易被忽略的。Agent 在等模型返回的时候CPU 是空闲的但连接、上下文、内存都还占着。一个 Agent 一次运行如果有 10 轮 LLM 调用每轮等 3 到 8 秒那光等待就占了一分钟。这段时间里你的进程资源被锁住了但没干活。第四块是工具执行时的突发资源。比如 Agent 调用代码解释器跑一段 Python或者调用浏览器工具抓页面或者做一次本地向量检索。这些操作会瞬间拉高 CPU 或内存然后又降下来。把这四块想清楚你才能理解为什么16C32G 支持多少并发没有标准答案——它取决于你的 Agent 是重推理轻工具还是轻推理重工具取决于 LLM 是走 API 还是本地部署取决于单次任务的平均时长。1.2 为什么传统并发估算方法在这里失效传统 Web 服务估算并发用的是利特尔法则并发数 到达率 × 平均处理时间。这套公式在 Agent 场景下依然成立但问题在于平均处理时间这个变量极不稳定。一个客服 Agent 回答退货政策是什么可能 5 秒就结束。同一个 Agent 处理帮我对比这三份合同里的违约条款可能要跑 3 分钟中间调用十几次模型、读好几个文件。如果你按平均值去规划资源高峰期一定会被打爆。更麻烦的是Agent 的并发不是请求-响应式的短连接而是会话-任务式的长生命周期。一个用户可能同时开着三个 Agent 会话每个会话都在跑不同的任务。这时候你的并发单位不是请求数而是活跃任务数。我自己的经验是规划 Agent 服务器资源先别算并发数先算同时活跃的任务数和单任务的平均资源占用曲线。这两个数据拿到手容量规划才有意义。1.3 一个真实的资源画像示例举个我实际测过的例子。一个基于 FastAPI LangGraph 的文档分析 Agent走的是云端 LLM API本地只做向量检索和文件解析。单进程配置如下资源项空闲状态单任务运行中峰值常驻内存420MB650MB1.1GBCPU 占用1%15%60%解析大文件时网络连接2812单任务时长-45 秒180 秒从这个画像能看出来内存是主要约束CPU 反而很闲。因为大部分时间在等 LLM 返回。这种情况下一台 32G 内存的机器扣掉系统和预留大概能跑 20 到 25 个并发任务而不是按 CPU 核数去算。但如果你的 Agent 做本地 embedding、本地 rerank甚至本地跑小模型那 CPU 和 GPU 立刻变成瓶颈结论完全反过来。所以下面必须分开讨论。2. 内存才是第一约束Agent 并发规划的核心账我见过太多团队在 Agent 项目上翻车不是因为 CPU 不够而是因为内存被吃爆进程被 OOM Killer 干掉。Agent 场景的内存问题比传统服务更隐蔽因为它不是线性增长的。2.1 常驻内存与工作内存要分开算规划内存时一定要把每个进程的固定开销和每个任务的浮动开销分开。固定开销包括Python 解释器、框架代码、依赖库、连接池、模型客户端。这部分不管你跑不跑任务都在。假设单进程固定开销是 500MB。浮动开销包括对话上下文、检索结果、工具中间产物、序列化缓冲。这部分随任务复杂度变化。假设单任务平均浮动开销是 300MB峰值能到 800MB。那么 N 个并发任务的内存需求大致是总内存 进程数 × 固定开销 活跃任务数 × 平均浮动开销 安全余量注意这里进程数和活跃任务数不一定相等。如果你用多进程模型比如 Gunicorn 多 worker每个 worker 是一个独立进程各自有固定开销。如果你用单进程异步模型asyncio那固定开销只付一次但所有任务共享一个进程的内存空间一个任务内存泄漏会拖垮全部。提示异步模型省内存但隔离性差多进程模型隔离性好但固定开销翻倍。这个取舍在 Agent 场景下尤其关键因为 Agent 任务时长差异极大一个卡住的任务可能拖累整个进程。2.2 上下文累积是内存的隐形杀手Agent 跟普通接口最大的区别是它会累积上下文。一次多轮对话历史消息不断追加一次多步推理中间结果不断堆叠。如果你不做上下文裁剪内存会随任务时长持续上涨。我踩过的一个坑一个 Agent 处理长文档时把整篇文档切块后全部塞进上下文结果单任务内存从 400MB 涨到 3GB。后来改成滑动窗口 摘要压缩同样的任务内存稳定在 600MB 左右。具体做法有这么几种按效果排序滑动窗口只保留最近 N 轮对话最省内存但会丢失早期信息。摘要压缩把早期对话用 LLM 总结成一段话兼顾内存和信息保留。外部存储把历史消息存到 Redis 或数据库需要时按需加载内存占用最低但增加 IO。向量检索替代全量上下文不把所有内容塞进 prompt而是检索最相关的片段。这几种可以组合用。我的建议是默认用滑动窗口 外部存储对信息保留要求高的场景再加摘要压缩。全量上下文只在任务很短、文档很小的时候才用。2.3 内存泄漏在长生命周期 Agent 里会被放大普通 Web 服务进程定期重启内存泄漏影响有限。但 Agent 任务动辄跑几分钟如果每个任务泄漏几 MB跑几十个任务后进程就危险了。常见的泄漏点全局字典缓存了任务对象任务结束后没清理。事件监听器注册了没注销。异步任务创建了没 await异常被吞掉。第三方库尤其是向量库客户端、HTTP 客户端的连接没关闭。排查手段我常用这几个用tracemalloc抓内存快照对比用objgraph看对象引用链或者直接上memory_profiler逐行看。生产环境更简单粗暴的办法是给进程设内存上限超了就重启配合任务队列保证不丢任务。注意Agent 进程重启成本比普通服务高因为可能有正在跑的长任务。所以重启策略要配合任务状态持久化重启后能恢复。2.4 一个可落地的内存容量计算公式综合上面几点我给一个实操中能用的公式可承载并发任务数 (总内存 - 系统预留 - 进程固定开销 × 进程数) / 单任务峰值内存举例32G 内存的机器系统预留 4G单进程固定开销 500MB跑 4 个 worker 进程单任务峰值内存 800MB。(32 - 4 - 0.5 × 4) / 0.8 (32 - 4 - 2) / 0.8 26 / 0.8 ≈ 32理论上能跑 32 个并发任务。但这是峰值内存实际运行中不可能所有任务同时达到峰值。所以可以再乘一个经验系数 0.7 到 0.8得到 22 到 26 个并发任务比较稳妥。这个数字比16C32G 支持多少并发这种拍脑袋答案靠谱得多因为它是从你自己的资源画像推出来的。3. CPU 与 GPU什么时候它们才是真正的瓶颈内存算完接下来看计算资源。Agent 场景下 CPU 和 GPU 的角色取决于你的 Agent 是调用型还是本地推理型。3.1 纯 API 调用型 AgentCPU 基本不是瓶颈如果你的 Agent 所有 LLM 调用都走云端 API本地只做编排、工具调用、轻量检索那 CPU 占用会低得让你意外。我实测过一个编排型 Agent单任务 CPU 占用平均 10% 到 15%峰值也就 40% 到 60%而且峰值只出现在文件解析、JSON 序列化这种瞬间操作上。这种情况下CPU 核数不是主要约束网络 IO 和连接数才是。因为每个 Agent 任务可能同时持有多个到 LLM API 的 HTTP 连接连接池配置不当会导致任务排队等待。我的配置经验HTTP 连接池大小设为预期并发任务数的 1.5 到 2 倍。设置合理的超时连接超时 5 秒读取超时按模型最长响应时间设通常 60 到 120 秒。开启 keep-alive 复用连接减少握手开销。对 LLM API 做限流和重试避免瞬时打爆配额。CPU 方面4 到 8 核足够支撑几十个编排型 Agent 任务。真正吃 CPU 的是本地 embedding、rerank、文件解析这些操作如果这些量大再单独加核。3.2 本地推理型 AgentGPU 显存决定一切一旦你的 Agent 需要本地跑模型——不管是 embedding、rerank还是完整的小参数 LLM——GPU 就成了核心约束而且约束的是显存不是算力。显存占用分三块模型权重7B 模型 FP16 大约 14GBINT8 量化约 7GBINT4 约 4GB。KV Cache跟并发数和上下文长度成正比。上下文越长、并发越高KV Cache 越大。中间激活跟 batch size 相关。很多人只算模型权重忽略了 KV Cache结果一上并发就爆显存。KV Cache 的估算公式大致是KV Cache 大小 ≈ 2 × 层数 × 注意力头维度 × 序列长度 × 并发数 × 精度字节数这个公式不用背你只要记住一个结论并发数翻倍KV Cache 翻倍上下文长度翻倍KV Cache 也翻倍。所以本地推理型 Agent 的并发容量是被显存死死卡住的。举个例子一张 24GB 显存的卡跑 INT4 量化的 7B 模型权重占 4GB剩 20GB 给 KV Cache 和其他开销。如果单任务上下文 4K那大概能支撑 8 到 12 个并发。上下文拉到 16K并发直接掉到 2 到 3 个。3.3 GPU 租用与自建的取舍本地推理型 Agent 面临一个现实问题GPU 从哪来。自建要考虑采购成本、机房、散热、运维租用要考虑单价、可用性、数据合规。我的判断逻辑是这样的任务量稳定且大自建或长期租用更划算单位成本低。任务量波动大按需租用用多少付多少。数据敏感必须本地部署租用也要选合规的私有环境。只是验证阶段先用云端 API 跑通逻辑别急着上 GPU。这里有个容易忽略的点GPU 租用的计费通常按小时但 Agent 任务可能几分钟就结束。如果你的任务稀疏GPU 大部分时间在空转成本反而比 API 高。所以稀疏任务优先用 API密集任务才考虑本地 GPU。3.4 混合架构把合适的活分给合适的资源实际生产里最经济的方案往往是混合的高频、短上下文的任务走云端 API。低频、长上下文、数据敏感的任务走本地 GPU。embedding 和 rerank 用本地小模型省 API 调用成本。复杂推理用大模型 API保证质量。这种架构下资源规划要分两套账一套算 API 的并发配额和成本一套算本地 GPU 的显存和吞吐。两套账分开管别混在一起算。4. 并发模型选型进程、线程还是异步资源算清楚了接下来是并发模型。这个选择直接决定了你的资源利用率和稳定性。4.1 三种模型的适用场景对比模型内存开销隔离性适合场景坑多进程高每进程独立强CPU 密集、需要隔离固定开销翻倍进程间通信麻烦多线程中弱IO 密集、共享状态多GIL 限制Agent 场景收益低异步低弱IO 密集、高并发一个阻塞拖垮全部调试难Agent 场景下因为大量时间在等 LLM 返回IO 等待异步模型理论上最省资源。但异步的坑也很明显任何一处同步阻塞调用比如用了同步的 HTTP 库、同步的文件读写都会卡住整个事件循环。我的实际选择是异步为主关键路径上用多进程做隔离。具体来说用 FastAPI asyncio 处理请求编排把重 CPU 的操作文件解析、本地推理丢到独立的进程池或任务队列里避免阻塞主事件循环。4.2 异步模型下最容易踩的阻塞坑异步 Agent 最常见的性能问题就是某个环节偷偷用了同步调用。我列几个高频的用了requests而不是httpx.AsyncClient调 LLM API。用了同步的数据库驱动比如pymysql而不是asyncmy。文件读写用了open()而不是aiofiles。向量库客户端是同步的检索时阻塞事件循环。日志、序列化用了重 CPU 的库。排查办法在事件循环里加一个监控定期检查 loop 的延迟。如果延迟突然飙高说明有阻塞。Python 3.11 之后可以用asyncio的调试模式会打印慢回调的警告。提示不确定某个库是不是异步安全的最稳妥的办法是把它丢到run_in_executor里跑用线程池隔离。虽然多了一点开销但不会拖垮主循环。4.3 任务队列把长任务从请求链路里剥离Agent 任务时长差异大如果全部同步处理一个长任务会占着连接不放用户体验差资源也浪费。更好的做法是引入任务队列。架构大致是请求进来创建一个任务丢进队列立即返回任务 ID后台 worker 从队列取任务执行客户端通过任务 ID 轮询或订阅结果。这样带来的好处请求链路短连接快速释放。任务可以排队、重试、优先级调度。worker 数量可以独立于 Web 进程调整。长任务不会拖垮 Web 层。队列选型上轻量用 Redis RQ 或 Celery重一点用 RabbitMQ 或 Kafka。Agent 场景我倾向 Redis 系因为部署简单而且 Agent 本身可能已经在用 Redis 做缓存。4.4 并发数控制别让 Agent 无限扩张异步模型有个危险你可以轻松创建成千上万个协程但它们会一起抢资源最后谁都跑不动。所以必须做并发控制。控制手段有两层信号量Semaphore限制同时运行的任务数超过就等待。队列长度限制队列满了就拒绝新任务返回系统繁忙。信号量的值怎么定回到第 2 章的内存公式算出可承载并发任务数信号量就设这个值。比如算出 25信号量就设 25。这样保证不会因为任务过多导致 OOM。队列长度可以设成信号量的 3 到 5 倍给突发流量一点缓冲。超过就拒绝保护系统。5. 监控与压测让容量规划有数据支撑前面讲的都是估算真正上线前必须压测上线后必须监控。没有数据的容量规划都是耍流氓。5.1 压测 Agent 和压测接口是两回事用 JMeter 压普通接口那套方法直接搬到 Agent 上会失真。因为 Agent 任务时长不稳定、资源占用非线性、还依赖外部 LLM API。压测 Agent 要注意几点模拟真实任务分布别只用一种任务压要按生产环境的任务类型比例混合。控制外部依赖LLM API 要么 mock要么用真实但限速的调用否则压测结果被 API 限流干扰。观察资源曲线不光看响应时间要看内存、CPU、连接数的变化曲线。压到崩溃为止找到系统的真实上限而不是压到看起来还行就停。我一般会做阶梯压测从 5 并发开始每 5 分钟加 5 个并发观察资源曲线和错误率。找到错误率开始上升、内存接近上限的那个点就是容量上限。实际部署时留 30% 余量。5.2 必须监控的几个关键指标Agent 服务的监控除了常规的 CPU、内存、网络还要加几个特有的活跃任务数当前正在运行的任务数量这是最核心的指标。任务队列长度排队等待的任务数反映系统压力。单任务时长分布P50、P95、P99看长尾有多长。LLM 调用延迟和错误率外部依赖的健康度。单任务内存峰值找出内存大户。进程重启次数频繁重启说明有泄漏或 OOM。这些指标用 Prometheus Grafana 就能搭起来。关键是设好告警阈值比如活跃任务数超过容量的 80% 就告警内存超过 85% 就告警。5.3 从监控数据反推容量规划监控跑一段时间后你会拿到真实的资源曲线。用这些数据反推容量比任何估算都准。具体做法取一周的峰值时段数据看活跃任务数、内存占用、CPU 占用的关系。如果发现内存是瓶颈就按内存算容量如果发现 CPU 是瓶颈就按 CPU 算。然后根据业务增长预期预留扩容空间。我自己的习惯是每月复盘一次容量数据看看是否需要调整信号量、worker 数量、队列长度。Agent 业务变化快容量规划不是一次性的是持续迭代的。6. 几个实操中反复踩到的坑最后分享几个我在 Agent 并发场景下反复踩到的坑都是文档里不会写、但实际会要命的。6.1 连接池配置不当导致的假死有一次线上 Agent 突然大面积超时CPU 内存都正常就是任务卡住不动。排查半天发现是 HTTP 连接池太小所有连接都被长任务占着新任务拿不到连接一直等。表现就是假死——资源没满但服务不可用。解决办法连接池大小要大于并发任务数并且设置连接获取超时拿不到连接就快速失败而不是无限等待。6.2 上下文没裁剪导致的内存缓慢上涨Agent 跑得越久内存越高重启后恢复。这是典型的上下文累积问题。解决办法就是第 2 章讲的裁剪策略。我的经验是任何进入上下文的文本都要问一句这个真的需要一直留着吗。大部分时候答案是不需要。6.3 本地模型和 API 混用时的资源争抢混合架构下本地 GPU 推理和 CPU 密集操作可能互相争抢资源。比如 embedding 在 GPU 上跑文件解析在 CPU 上跑如果调度不当两者会互相拖慢。解决办法是给不同类型的任务分配独立的资源池或者用优先级队列保证关键任务优先。6.4 任务没有超时控制导致的资源泄漏Agent 任务如果卡在某个环节比如 LLM API 不返回、工具执行死循环没有超时控制的话这个任务会一直占着资源。跑多了资源就耗尽了。解决办法给每个任务设总超时给每个 LLM 调用设单次超时给每个工具执行设超时。超时就终止任务释放资源记录日志。6.5 日志和追踪本身也是资源消耗Agent 任务步骤多如果每步都打详细日志、都做全链路追踪日志量和追踪开销会非常可观。我见过一个案例日志写入占了 20% 的 CPU。解决办法分级日志生产环境只打关键节点追踪采样不是每个任务都全量追踪日志异步写入别阻塞主流程。这些坑的共同点是它们不会在低并发时暴露一旦并发上来就集中爆发。所以容量规划不只是算资源还要把这些工程细节都考虑进去。真正稳定的 Agent 服务是资源规划 并发模型 监控告警 工程细节共同作用的结果缺一不可。