1. Agent 推理到底在算什么先把账算清楚再谈硬件很多人一上来就问“跑 Agent 要什么显卡”这个问题本身就问偏了。Agent 推理和传统的大模型对话推理在硬件消耗结构上完全是两码事。你如果拿跑 Chatbot 的经验去配 Agent 的机器大概率会出现两种情况要么花了大价钱买了用不上的算力要么在并发一上来的时候直接卡死。我先把这个账拆开。Agent 推理的负载可以分成三块模型前向计算、上下文管理、工具调用与编排。第一块是大家最熟悉的就是 Transformer 的推理吃的是 GPU 算力和显存带宽。第二块是 Agent 特有的因为 Agent 要维护记忆、要拼接历史、要做 RAG 检索上下文长度往往是普通对话的好几倍KV Cache 的显存占用会非常夸张。第三块是编排层包括任务规划、工具选择、结果解析、循环控制这部分主要吃 CPU 单核性能和内存延迟。一个常见的误区以为 Agent 推理就是“更大的模型”。实际上很多 Agent 场景用的是 7B 到 14B 的模型但因为上下文长、调用轮次多整体硬件压力反而比单次跑 70B 模型更大。我拿一个具体的例子来说明。假设你做一个客服 Agent底层用 Qwen2.5-14B上下文窗口开到 32K平均每个用户会话要调用 5 次工具查订单、查物流、改地址等每次工具调用前后都要重新做一次前向计算。那么单个会话的实际推理次数不是 1 次而是 10 次以上。如果同时有 20 个用户在对话你面对的就是 200 次并发推理请求而且每次请求的上下文都在 8K 到 32K 之间浮动。这个负载特征决定了硬件选型的核心矛盾显存容量和显存带宽比纯算力更重要。因为 Agent 推理是典型的 memory-bound 场景不是 compute-bound。你堆再多的 Tensor Core如果显存不够放 KV Cache照样跑不起来。1.1 为什么 Agent 推理是显存杀手KV Cache 的计算公式其实不复杂。以 FP16 精度为例每个 token 的 KV Cache 占用大约是2 × num_layers × num_kv_heads × head_dim × 2 bytes拿 Qwen2.5-14B 来说40 层num_kv_heads 是 8GQAhead_dim 是 128。每个 token 的 KV Cache 就是 2 × 40 × 8 × 128 × 2 163840 bytes约 160KB。听起来不多对吧但 32K 上下文就是 160KB × 32768 ≈ 5.2GB。这还只是一个会话。如果并发 10 个会话光 KV Cache 就要 52GB 显存加上模型权重本身 28GBFP16总共 80GB 打底。一张 80GB 的卡刚好卡在临界点上没有任何余量。这就是为什么很多团队在 Agent 项目上翻车他们按模型大小选卡14B 模型觉得一张 24GB 的 4090 就够了结果一上并发和长上下文直接 OOM。1.2 编排层的硬件需求被严重低估大家聊 Agent 硬件都在聊 GPU但编排层的 CPU 和内存同样关键。Agent 的循环控制、工具调用、JSON 解析、RAG 检索这些操作全部跑在 CPU 上。如果 CPU 单核性能不够或者内存延迟高会出现一种很诡异的现象GPU 利用率只有 30%但整体吞吐上不去。因为 GPU 在等 CPU 把下一次推理请求拼好。我实测过一个对比同样的 GPU 配置CPU 从一颗老款 8 核换成新款高主频 16 核Agent 的整体吞吐提升了将近 40%。这个数字在纯对话推理场景里是不可想象的但在 Agent 场景里非常正常因为编排层的开销占比太高了。所以回答“Agent 推理需要什么硬件”这个问题不能只盯着显卡。下面我按模块拆开讲每个模块给出具体的选型逻辑和参数依据。2. GPU 选型显存容量、带宽和互联的实际取舍GPU 是 Agent 推理硬件里最贵的一块也是最容易选错的一块。我见过太多人要么盲目上 H100要么拿消费卡硬扛最后都不太满意。选型的核心就三个维度显存容量、显存带宽、卡间互联。算力反而排在第四位。2.1 显存容量怎么算才不翻车先给一个实操的计算框架。你需要估算四个部分占用项计算方式典型值14B 模型32K 上下文10 并发模型权重参数量 × 精度字节数14B × 2 28GBFP16KV Cache每 token 占用 × 上下文长度 × 并发数160KB × 32768 × 10 ≈ 52GB激活值约模型权重的 5% 到 10%约 2GB框架开销CUDA Context、通信缓冲等2GB 到 4GB合计约 84GB 到 86GB这个结果意味着一张 80GB 的卡不够你需要两张 48GB 的卡做张量并行或者用 INT8 量化把权重压到 14GBKV Cache 压到 26GB总共约 45GB一张 48GB 的卡就能扛。实操心得量化对 Agent 场景的收益比对话场景更大因为省下来的显存可以直接换成更长的上下文或更高的并发。但要注意量化会轻微影响工具调用的准确率尤其是需要精确输出 JSON 的场景建议用 AWQ 或 GPTQ 而不是粗暴的 INT4。2.2 显存带宽为什么比算力更关键Agent 推理的 decode 阶段是逐 token 生成的每生成一个 token 都要把整个模型权重读一遍。这个过程是典型的 memory-bound瓶颈在显存带宽而不是算力。举个例子。一张 RTX 4090 的显存带宽是 1008 GB/s一张 A100 80GB 是 2039 GB/s一张 H100 SXM 是 3350 GB/s。跑 14B 模型 FP16权重 28GB理论上 4090 每生成一个 token 需要 28GB / 1008GB/s ≈ 27.8msA100 需要 13.7msH100 需要 8.4ms。这个差距直接体现在吞吐上。但这里有个反直觉的点如果你用的是小模型7B 以下加上短上下文消费卡的带宽其实够用因为计算量小瓶颈可能转移到 CPU 编排上。只有当模型大于 14B 或者上下文超过 16K 时带宽差距才会被放大到不可忽视。2.3 多卡互联NVLink 不是必须但很香Agent 推理如果单卡放不下就要做张量并行或流水线并行。这时候卡间通信带宽就很重要。NVLink 的带宽是 PCIe 5.0 的 5 到 10 倍在张量并行场景下差距非常明显。我做过一个对比测试两张 4090 通过 PCIe 做张量并行跑 32B 模型相比两张 A6000 通过 NVLink 跑同样的模型吞吐差了将近 2.3 倍。原因就是张量并行每层都要做 All-ReducePCIe 的带宽成了瓶颈。但也不是所有场景都需要 NVLink。如果你用的是流水线并行或者干脆用两张卡各跑各的实例做数据并行PCIe 就够了。数据并行在 Agent 场景里其实很实用因为每个 Agent 会话是独立的天然适合分卡处理。2.4 消费卡、专业卡、数据中心卡的真实差距我把常见的几类卡在 Agent 推理场景下的表现整理成表卡型显存带宽多卡互联适合场景坑点RTX 409024GB1008 GB/s无 NVLink7B 到 14B 量化模型低并发显存太小长上下文直接爆RTX 509032GB约 1800 GB/s无 NVLink14B 量化中等并发功耗高多卡机箱要求高A6000 Ada48GB960 GB/s有 NVLink14B FP16中等并发带宽相对低decode 偏慢L40S48GB864 GB/s无 NVLink推理优化卡性价比不错带宽是短板A100 80GB80GB2039 GB/s有 NVLink32B 以上高并发价格高功耗高H100 80GB80GB3350 GB/s有 NVLink大模型高并发贵对中小团队过剩选型的逻辑很简单先算显存需求再看带宽是否够最后看互联需求。不要反过来先选卡再想办法塞模型。3. CPU 与内存Agent 编排层的隐形瓶颈GPU 选完了不代表硬件就配好了。Agent 推理和普通推理最大的区别在于它有大量的 CPU 侧工作。这部分如果配不好GPU 再强也白搭。3.1 编排层到底在干什么一个典型的 Agent 循环是这样的接收用户输入拼接系统提示和历史对话调用模型做规划解析模型输出的工具调用指令执行工具把工具结果拼回上下文再次调用模型直到任务完成或达到最大轮次。这里面 CPU 要干的活包括字符串拼接、JSON 解析、正则匹配、向量检索、HTTP 请求、状态管理。每一步看起来都不重但累加起来非常可观。尤其是 JSON 解析和向量检索在大并发下会成为明显的瓶颈。我实测过一个数据在一个 20 并发的 Agent 服务里CPU 侧的处理时间占端到端延迟的 35% 到 45%。也就是说用户等 10 秒有 4 秒是在等 CPU 干活GPU 在那段时间是空闲的。3.2 CPU 选型高主频优先于多核基于上面的负载特征CPU 选型的核心是高主频而不是堆核心数。因为 Agent 编排的很多操作是单线程的比如 JSON 解析、正则匹配、Python GIL 限制下的逻辑处理。你给 64 个核但每个核频率只有 2.0GHz实际表现可能不如 16 核 4.5GHz。我的建议是主频 3.5GHz 起步最好 4.0GHz 以上核心数 16 到 32 核足够。AMD 的 Ryzen 9 系列或者 Intel 的 i9 系列在性价比上比 Xeon 更适合中小规模部署。如果是大规模集群再考虑 Xeon 或 EPYC但也要选高主频型号。踩过的坑曾经用一颗 32 核 2.1GHz 的服务器 CPU 跑 Agent 编排GPU 是 A100结果整体吞吐还不如 16 核 4.2GHz 的消费级平台。GPU 利用率长期在 40% 以下钱全浪费了。3.3 内存容量与延迟内存这块有两个指标容量和延迟。容量决定了你能同时跑多少个 Agent 会话延迟决定了编排层的响应速度。容量方面我的经验公式是每并发会话预留 500MB 到 1GB 内存。20 并发就是 10GB 到 20GB加上操作系统和框架本身的开销32GB 是起步64GB 比较稳妥128GB 可以跑得很舒服。延迟方面DDR5 比 DDR4 在 Agent 编排场景下有肉眼可见的提升。因为向量检索和上下文拼接都是内存密集型操作DDR5 的高带宽和低延迟能直接转化为吞吐提升。我实测过 DDR4 3200 和 DDR5 5600 的对比在同样的 CPU 和 GPU 下Agent 端到端延迟降低了约 18%。3.4 存储别忽视向量库的 IOAgent 通常要接向量数据库做 RAG。如果向量库是本地部署的存储的 IO 性能会影响检索速度。NVMe SSD 是必须的SATA SSD 在并发检索时会出现明显的延迟抖动。容量上向量库的大小取决于你的知识库规模。一个百万级文档的向量库用 768 维 FP32 存储大约需要 3GB 到 5GB。加上索引文件预留 50GB 到 100GB 的 NVMe 空间比较合理。4. 不同规模 Agent 项目的硬件配置方案理论讲完了直接给几套可抄的配置。我按项目规模分三档每档给出具体的硬件清单和适用场景。4.1 个人开发与验证单卡方案这档适合个人开发者做 Agent 原型验证、学习、小规模测试。核心诉求是便宜、够用、能跑起来。部件推荐配置说明GPURTX 4090 24GB 或 RTX 5090 32GB5090 显存更大更适合长上下文CPURyzen 9 7950X 或 i9-14900K高主频16 核以上内存64GB DDR5 560032GB 会紧张64GB 舒服存储1TB NVMe SSD系统和模型分开存更好电源1000W 金牌4090 峰值功耗高留余量这套配置能跑什么7B 到 14B 的量化模型上下文 16K 到 32K并发 3 到 5 个 Agent 会话。再往上就吃力了。实操心得个人开发阶段模型量化是必须的。用 AWQ 量化把 14B 模型压到 8GB 左右KV Cache 用 FP8 存储能把 24GB 显存的利用率拉到 90% 以上。别硬跑 FP16显存不够会频繁触发 offload速度直接掉一个数量级。4.2 小团队生产双卡方案这档适合小团队做正式产品需要支撑几十个并发用户。核心诉求是稳定、可扩展、性价比合理。部件推荐配置说明GPU2 × A6000 Ada 48GB 或 2 × L40S 48GB双卡做张量并行或数据并行CPUThreadripper 7960X 或 Xeon w7-2495X24 核以上主频 3.5GHz内存128GB DDR5 5600并发 20 到 30 个会话存储2TB NVMe SSD RAID 1向量库和模型分开电源1600W 铂金双卡功耗高这套配置能跑什么14B FP16 或 32B 量化模型上下文 32K并发 15 到 25 个 Agent 会话。如果做数据并行每个卡跑一个实例并发能力翻倍但单实例上下文受限。4.3 中型部署四卡起步这档适合有明确业务场景、需要支撑上百并发的团队。核心诉求是吞吐、稳定性、可运维性。部件推荐配置说明GPU4 × A100 80GB 或 4 × H100 80GBNVLink 互联张量并行CPU双路 EPYC 9354 或 Xeon Platinum64 核以上主频 3.0GHz内存512GB DDR5大规模并发和向量库存储4TB NVMe SSD RAID 10高 IO 需求网络25GbE 以上如果做分布式部署这套配置能跑什么32B 到 72B 模型上下文 64K 到 128K并发 50 到 100 个 Agent 会话。具体数字取决于模型大小和上下文长度需要实际压测。注意四卡以上的配置散热和供电是大事。我见过太多机器因为散热设计不到位GPU 降频运行实际性能只有标称的 60%。机箱风道、风扇转速曲线、环境温度这些都要提前规划。5. 推理引擎选型硬件之外的软件变量硬件配好了推理引擎选不对性能照样上不去。Agent 推理对推理引擎有特殊要求不是随便拿个 vLLM 就能跑好的。5.1 vLLM 在 Agent 场景的适配与调优vLLM 是目前最主流的推理引擎PagedAttention 对 KV Cache 的管理非常高效天然适合 Agent 的长上下文场景。但默认配置不一定适合 Agent需要调几个关键参数。第一个是max_model_len要设成你实际需要的最大上下文长度。设太大浪费显存设太小会截断。第二个是gpu_memory_utilization默认 0.9Agent 场景建议调到 0.85 到 0.88给编排层留一点显存余量。第三个是max_num_seqs控制并发序列数要根据显存和上下文长度算。python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-14B-Instruct \ --max-model-len 32768 \ --gpu-memory-utilization 0.86 \ --max-num-seqs 16 \ --enable-prefix-caching \ --quantization awqenable-prefix-caching对 Agent 场景特别有用因为 Agent 的系统提示和工具定义通常是固定的prefix caching 可以避免重复计算能省 20% 到 30% 的算力。5.2 流式推理管线对硬件的影响Agent 场景经常需要流式输出因为用户要看到 Agent 的思考过程。流式推理对硬件的压力和批量推理不同它更考验单次 decode 的延迟稳定性。如果硬件带宽不够流式输出会出现明显的卡顿token 之间的间隔不均匀。这在用户体验上是致命的。所以做流式 Agent 的话显存带宽的优先级要再提高一档。5.3 端侧 Agent 的硬件考量如果 Agent 要部署在端侧设备上比如嵌入式硬件或者手机硬件选型逻辑完全不同。端侧的核心约束是功耗和散热算力反而是次要的。端侧 Agent 通常用 3B 以下的模型配合 INT4 量化跑在 NPU 或者移动 GPU 上。内存方面LPDDR5 的带宽和容量是关键建议 12GB 起步。存储要留足模型和向量库的空间UFS 4.0 比 UFS 3.1 在加载速度上有明显优势。踩过的坑端侧 Agent 最容易忽视的是散热。跑几分钟后芯片降频推理速度直接腰斩。如果做端侧产品散热设计要和硬件选型同步考虑别等样机出来才发现烫手。6. 常见问题与排查技巧实录这一节整理我在 Agent 硬件部署中实际遇到过的问题以及排查思路。都是真金白银换来的经验。6.1 GPU 利用率低但吞吐上不去这是最常见的问题。现象是 GPU 利用率长期在 30% 到 50%但请求排队严重。排查顺序如下排查项检查方法可能原因解决方向CPU 单核占用top 看单核是否跑满编排层单线程瓶颈换高主频 CPU 或优化代码内存带宽看内存频率和通道数内存带宽不足加通道或换 DDR5PCIe 带宽看 GPU 数据传输量数据搬运瓶颈减少 CPU-GPU 数据拷贝请求批大小看推理引擎日志批太小GPU 吃不饱调大 max_num_seqsKV Cache 碎片看显存碎片率PagedAttention 配置不当调 block_size我遇到最多的是 CPU 单核瓶颈。Agent 的编排逻辑如果是 Python 写的GIL 会让多核优势发挥不出来。解决办法要么用多进程要么把关键路径用 Rust 或 C 重写。6.2 长上下文下显存溢出Agent 跑到第 5 轮对话时突然 OOM这是 KV Cache 累积导致的。排查思路先算理论 KV Cache 占用和实际显存使用对比。如果实际远大于理论可能是碎片问题。vLLM 的 PagedAttention 能缓解碎片但 block_size 设大了会浪费设小了管理开销高。建议从 16 开始试。另一个原因是并发数设太高。max_num_seqs设成 32但每个序列上下文 32K显存根本放不下。这时候要么降并发要么降上下文要么加卡。6.3 工具调用延迟高Agent 调用外部工具时延迟高不一定是网络问题。排查方向工具调用的序列化/反序列化开销JSON 解析在大 payload 下很慢向量检索的索引结构HNSW 比 IVF 快但内存占用高工具本身的执行时间比如数据库查询没加索引我遇到过一个案例Agent 调用一个内部 API 平均要 2 秒排查发现是 API 返回的 JSON 有 500KB解析就花了 800ms。后来让 API 只返回必要字段延迟降到 200ms。6.4 多卡并行效率低双卡做张量并行理论吞吐应该是单卡的 1.8 倍左右但实际只有 1.2 倍。原因通常是卡间通信瓶颈。检查 PCIe 拓扑确保两张卡挂在同一个 PCIe Root Complex 下而不是跨 NUMA 节点。如果是 NVLink检查 NVLink 是否正常工作。软件层面检查张量并行的切分策略有些层不适合切分强行切分反而增加通信量。实操心得Agent 场景其实更适合数据并行而不是张量并行。因为每个 Agent 会话独立数据并行天然适配。两张卡各跑一个实例前面加个负载均衡比张量并行的扩展性好得多而且没有通信开销。7. 硬件选型的决策框架与经验总结聊了这么多具体配置最后给一个决策框架。你拿到一个 Agent 项目按这个顺序走基本不会选错。第一步确定模型大小和精度。7B 以下用消费卡14B 到 32B 用专业卡72B 以上用数据中心卡。量化能降一档。第二步确定上下文长度和并发数。这两个参数决定了 KV Cache 的大小是显存需求的主要来源。上下文 8K 和 32K显存需求差 4 倍。第三步算显存总需求。模型权重 KV Cache 激活值 框架开销留 15% 余量。第四步看显存带宽是否匹配。如果 decode 速度是瓶颈优先选高带宽的卡。第五步配 CPU 和内存。CPU 高主频优先内存容量按并发数算DDR5 优先。第六步选推理引擎并调参。vLLM 是默认选择根据场景调 max_model_len、gpu_memory_utilization、max_num_seqs。这套框架我在多个项目上验证过基本能覆盖 80% 的场景。剩下的 20% 需要根据具体业务做定制比如超长上下文、超高并发、端侧部署等。我个人在实际操作中的体会是Agent 推理的硬件选型最怕的不是买贵了而是买错了。一张 H100 跑 7B 模型性能可能还不如一张 4090因为小模型吃不满 H100 的算力反而受限于单次 decode 的延迟。反过来用 4090 硬扛 32B 模型的长上下文OOM 会让你怀疑人生。所以选型之前先把模型大小、上下文长度、并发数这三个数确定下来再按上面的框架走基本不会翻车。最后分享一个小技巧如果预算有限优先保显存容量其次保显存带宽最后才考虑算力。Agent 推理是 memory-bound 的场景这个优先级顺序和训练完全相反。我见过太多人按训练的思维配推理机器结果钱花了不少性能却不达标。记住Agent 推理的瓶颈在显存不在算力。