1. 从"跑个Demo"到"扛住线上流量"：Agent推理硬件的真实门槛
很多人第一次接触Agent推理，是在自己笔记本上跑一个7B或13B的模型，看着终端里token一个个蹦出来，觉得"也就这样"。但当你把Agent真正放到业务链路里——比如让它调用工具、维护记忆、做多轮规划、并发处理几十上百个请求时，硬件这件事就会从"能跑就行"变成"每一步都在烧钱和烧时间"。
Agent推理和普通的大模型对话推理有一个本质区别：它不是一次前向传播就结束，而是一个"推理-决策-调用工具-再推理"的循环。这意味着同一个用户请求，可能触发3到10次甚至更多的模型调用，每次调用都要重新加载上下文、重新计算KV Cache。这种放大效应，直接决定了Agent推理对硬件的要求和单轮对话完全不是一个量级。
这篇文章想聊清楚一件事：当你决定认真做一个Agent项目时，硬件到底该怎么选、怎么配、怎么算账。我会从推理负载的本质特征讲起，拆解显存、算力、带宽、并发这四个维度的真实需求，然后给出从个人开发到小规模线上的几套配置方案，最后分享一些我在实际部署中踩过的坑和调优经验。不管你是刚入门想搭个本地Agent玩玩的开发者，还是正在为团队选型做技术调研的工程师，应该都能从中找到能直接用的东西。
先给一个结论性的判断：Agent推理的硬件瓶颈，90%的情况下不在算力，而在显存容量和显存带宽。很多人一上来就盯着TFLOPS看，结果买回来发现模型加载不进去，或者并发一上来就OOM。这个认知偏差，是后面所有选型错误的根源。
2. Agent推理的负载特征：为什么它比普通推理更吃硬件
2.1 多轮循环带来的调用放大效应
普通对话推理的流程很线性：用户输入一段话，模型生成一段回复，结束。整个过程中模型只被调用一次，KV Cache只维护一条序列。但Agent不一样，一个典型的Agent任务链路是这样的：接收用户指令 → 模型规划下一步动作 → 输出工具调用参数 → 执行工具 → 把工具结果拼回上下文 → 模型再次推理 → 可能再调用工具 → 直到任务完成。
我实测过一个简单的"查天气并推荐穿搭"的Agent，用户一句话输入，背后触发了4次模型调用：第一次解析意图，第二次决定调用天气API，第三次根据天气结果决定调用穿搭知识库，第四次生成最终回复。如果每次调用平均消耗1500个token的上下文，那总token消耗就是6000，是单轮对话的4倍。这个放大系数在复杂Agent里可以轻松到10倍以上。
这对硬件的直接影响是：你需要的不是"能跑一个模型"的硬件，而是"能在可接受延迟内跑完N次模型调用"的硬件。N越大，对单次推理速度的要求就越高，因为延迟是累加的。
2.2 上下文长度对显存的非线性吞噬
Agent的另一个特征是上下文特别长。因为它要维护对话历史、工具调用记录、中间结果、系统提示词，这些全部要放进context window。一个稍微像样点的Agent，上下文轻松到8K、16K甚至32K token。
这里有个很多人忽略的点：KV Cache的显存占用是随上下文长度线性增长的，但随并发数也是线性增长的。计算公式大致是：
KV Cache显存 = 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 并发数 × 精度字节数以一个13B模型为例，32层、40个头、头维度128、FP16精度，单条32K序列的KV Cache大约是：
2 × 32 × 40 × 128 × 32768 × 2字节 ≈ 21.5 GB这还只是一条序列。如果你要支持4路并发，光KV Cache就要86GB，加上模型权重本身占的26GB，总共超过110GB。这就是为什么很多人在24GB显存的卡上跑长上下文Agent会直接OOM——不是模型放不下，是KV Cache放不下。
2.3 工具调用的突发性对硬件调度的考验
Agent还有一个很讨厌的特性：它的负载是突发的、不均匀的。模型推理的时候GPU满载，执行工具调用的时候GPU空闲，等工具返回结果又突然满载。这种锯齿状的负载曲线，对硬件的调度和内存管理提出了更高要求。
如果你的Agent要调用外部API，那网络延迟可能比推理本身还长。这时候GPU就在那里空转等着，利用率可能只有30%。但你又不能不给它留足资源，因为一旦工具返回，推理请求会瞬间涌进来。这种"峰值决定配置"的逻辑，是Agent硬件成本居高不下的重要原因。
3. 显存、算力、带宽、并发：四个维度的真实需求拆解
3.1 显存容量：决定你能跑多大的模型和多长的上下文
显存是Agent推理的第一道门槛，没有之一。它要同时装下三样东西：模型权重、KV Cache、以及推理框架的运行时开销。
模型权重这块比较好算，看参数量和精度就行：
| 模型规模 | FP16权重 | INT8权重 | INT4权重 |
|---|---|---|---|
| 7B | 14 GB | 7 GB | 3.5 GB |
| 13B | 26 GB | 13 GB | 6.5 GB |
| 34B | 68 GB | 34 GB | 17 GB |
| 70B | 140 GB | 70 GB | 35 GB |
但KV Cache这块就麻烦了，它跟你的上下文长度和并发数直接挂钩。我的经验是，在规划显存时，KV Cache至少要预留和模型权重等量的空间。也就是说，你想跑13B模型做Agent，别按26GB去配，按50GB以上去配才稳妥。
提示：如果你用的是vLLM这类PagedAttention框架，KV Cache的显存利用率会高很多，因为它按块分配、按需增长，不会像朴素实现那样预留一大块连续内存。但即便如此，容量上限还是在那里，该不够还是不够。
3.2 算力：不是越高越好，而是要看推理场景
算力这个维度最容易被误导。厂商标的TFLOPS是理论峰值，实际推理中你能用到的可能只有30%到50%。而且Agent推理的算力需求分两个阶段：Prefill阶段是算力密集型，Decode阶段是带宽密集型。
Prefill阶段要处理整个输入序列，做大量的矩阵乘法，这时候算力越强越快。Decode阶段是逐token生成，每次只算一个token，但要把整个KV Cache读一遍，这时候显存带宽才是瓶颈。
对于Agent来说，因为上下文长、调用次数多，Prefill的占比会比普通对话高很多。所以算力不能太弱，但也没必要追求顶级。一张算力中等的卡，只要显存够大、带宽够高，跑Agent的体验可能比一张算力强但显存小的卡更好。
3.3 显存带宽：Decode阶段的隐形杀手
显存带宽这个参数，很多人在选卡时直接忽略，但它对Agent推理的token生成速度影响巨大。Decode阶段每生成一个token，都要把模型权重和KV Cache从显存读一遍。带宽不够，GPU算力再强也得等着数据。
举个直观的例子：一张带宽1.5TB/s的卡和一张带宽3TB/s的卡，跑同一个70B模型，后者的token生成速度理论上能快一倍。在Agent场景下，这意味着一个需要生成2000个token的任务，前者要40秒，后者只要20秒。多轮调用累加起来，用户体验差距非常明显。
3.4 并发能力：Agent扛并发的真正难点
Agent的并发和普通推理的并发不是一回事。普通推理的并发是"同时来N个请求"，Agent的并发是"同时有N个任务在循环执行"。每个任务可能处于不同的阶段——有的在推理，有的在等工具返回，有的在写记忆。
这就导致一个结果：你不能简单地按"同时推理的请求数"来配置硬件，而要按"同时活跃的任务数"来配置。一个活跃任务即使当前不在推理，它占用的KV Cache和上下文也不能释放，因为随时可能要继续推理。
我一般建议按活跃任务数的1.5倍来预留推理资源，因为总会有任务在同一时刻撞上推理阶段。这个系数在工具调用延迟高的场景下还要往上调。
4. 从个人开发到小规模线上：几套可落地的硬件配置方案
4.1 个人开发验证：单卡24GB的极限用法
如果你只是想在自己机器上搭个Agent做验证，预算有限，那24GB显存的卡（比如RTX 4090或3090）是性价比最高的选择。但要用好这24GB，得做一些取舍。
我的建议是：跑7B模型的INT4量化版本，上下文控制在8K以内，并发数设为1到2。这样模型权重占3.5GB，KV Cache在8K上下文下单条约5GB，两路并发10GB，加上框架开销2GB左右，总共15GB出头，还有余量。
具体操作上，用vLLM启动时加上这些参数：
python -m vllm.entrypoints.openai.api_server \ --model Qwen2.5-7B-Instruct-AWQ \ --quantization awq \ --max-model-len 8192 \ --gpu-memory-utilization 0.90 \ --max-num-seqs 2 \ --enable-prefix-caching--enable-prefix-caching这个参数对Agent特别有用，因为Agent的系统提示词和工具定义往往是固定的，开启前缀缓存后这部分不用重复计算，能省不少显存和算力。
注意：INT4量化会带来一定的精度损失，对于需要精确工具调用参数生成的Agent，建议先做一轮评测，确认量化后工具调用的准确率还能接受。我遇到过量化后模型开始乱编API参数的情况，这种就得换回INT8或者FP16。
4.2 小团队内部使用：双卡48GB的平衡点
当你的Agent要给团队几个人同时用，或者要跑13B级别的模型时，单卡24GB就不够了。这时候双卡48GB（比如两张4090）是一个比较舒服的配置。
双卡有两种用法：张量并行和流水线并行。对于Agent推理，我更推荐张量并行，因为它能把单次推理的延迟降下来。用vLLM的话，加一个--tensor-parallel-size 2就行。
python -m vllm.entrypoints.openai.api_server \ --model Qwen2.5-14B-Instruct \ --tensor-parallel-size 2 \ --max-model-len 16384 \ --gpu-memory-utilization 0.88 \ --max-num-seqs 4这套配置能跑14B模型的FP16版本，16K上下文，4路并发。实测下来，单次推理的首token延迟在300ms左右，生成速度约40 token/s。对于内部使用的Agent，这个体验已经相当流畅了。
但双卡有个坑：卡间通信带宽。如果你用的是消费级卡，没有NVLink，卡间通信走PCIe，张量并行的效率会打折扣。实测下来，双卡张量并行的加速比大概在1.6到1.7倍，而不是理想的2倍。这个损耗在Agent多轮调用场景下会被放大，需要心里有数。
4.3 小规模线上：专业卡或云端的取舍
如果要对外提供服务，哪怕只是小规模，消费级卡的稳定性和显存容量就开始捉襟见肘了。这时候有两个方向：买专业卡，或者用云端GPU。
专业卡（比如A100 40GB、L40S 48GB）的优势是显存大、带宽高、支持ECC、可以7x24稳定运行。一张A100 40GB能跑34B模型的INT8版本，或者70B模型的INT4版本，上下文给到16K，并发4到6路。对于日活几百到几千的Agent服务，这个配置基本够用。
云端GPU的优势是弹性，不用一次性投入大几万。但成本要算清楚：一张A100按小时计费，一个月跑满的话，费用可能够买半张卡了。所以云端适合负载波动大或者还在验证期的场景，长期稳定负载还是自建划算。
这里给一个粗略的成本对比，按跑70B INT4模型、日均1000次Agent任务、每次任务平均5轮调用估算：
| 方案 | 一次性投入 | 月运营成本 | 适用场景 |
|---|---|---|---|
| 自建双卡4090 | 约3万 | 电费约300元 | 内部使用、低并发 |
| 自建单卡A100 40GB | 约6万 | 电费约500元 | 小规模线上 |
| 云端A100按需 | 0 | 约8000元 | 验证期、波动负载 |
| 云端A100包月 | 0 | 约5000元 | 稳定中等负载 |
这个表只是量级参考，具体数字会随市场波动，但决策逻辑是清楚的：负载稳定且长期，自建；负载波动或短期，云端。
5. 那些选型时没人告诉你、但一定会踩的坑
5.1 显存够不等于跑得动：框架开销被严重低估
很多人算显存的时候只算模型权重和KV Cache，结果一跑就OOM。原因是忽略了推理框架本身的显存开销。CUDA context、cuDNN、PyTorch的缓存分配器、通信缓冲区，这些加起来轻松吃掉2到4GB。
我踩过最狠的一次，是在一张24GB卡上跑13B INT8模型，权重13GB，以为留11GB给KV Cache绰绰有余。结果框架开销吃了3GB，实际可用KV Cache只有8GB，上下文一上到8K就OOM。后来把--gpu-memory-utilization从默认的0.9调到0.85才稳住。
提示：规划显存时，按"模型权重 + KV Cache + 4GB框架开销"来算，别把卡塞满。留10%到15%的余量，能避免很多莫名其妙的OOM。
5.2 并发数不是越高越好：调度开销会反噬
vLLM的--max-num-seqs参数控制同时处理的序列数。很多人觉得调大点能提高吞吐，就设得很高。但在Agent场景下，并发数太高会导致每个请求分到的显存和算力变少，单次推理延迟上升。而Agent是多轮调用的，单次延迟上升会被轮数放大，最终端到端延迟反而更差。
我的经验值是：并发数不要超过显存能舒适支撑的KV Cache条数，同时要保证单次推理的延迟在可接受范围内。对于交互式Agent，单次推理延迟最好控制在500ms以内，超过1秒用户就能感觉到卡顿。
5.3 量化不是万能药：工具调用场景要格外小心
量化能省显存，这没错。但Agent对量化的敏感度比普通对话高，因为它要生成结构化的工具调用参数（JSON格式），这些参数对精度很敏感。INT4量化后，模型可能会生成格式错误或者参数值偏差的JSON，导致工具调用失败。
我建议的做法是：模型主体用INT8或INT4，但工具调用的关键层保持FP16。有些推理框架支持混合精度，可以按层配置。如果框架不支持，那就至少用INT8，别用INT4。实测下来，INT8对工具调用准确率的影响在可接受范围内，INT4就有点赌运气了。
5.4 长上下文的"最后一公里"：位置编码和注意力实现
当上下文超过8K时，很多模型的原生位置编码就不够用了，需要外推或者插值。不同推理框架对长上下文的支持程度不一样，有的需要额外配置RoPE scaling参数，有的干脆不支持。
我在部署一个需要16K上下文的Agent时，遇到过模型在8K以内表现正常，一超过8K就开始胡言乱语的情况。排查了半天才发现是位置编码没配对。后来在启动参数里加了--rope-scaling linear --rope-scaling-factor 2.0才解决。
这个坑的隐蔽性在于：它不会报错，只会让模型变傻。你以为是模型能力问题，其实是配置问题。所以长上下文场景下，一定要做针对性的评测，别只看能不能跑起来。
6. 把硬件用出性价比：几个实测有效的调优手段
6.1 前缀缓存：Agent场景的显存和算力双省器
Agent的系统提示词、工具定义、few-shot示例，这些内容在每次调用中都是重复的。开启前缀缓存后，这部分只计算一次，后续调用直接复用KV Cache。实测下来，在系统提示词占上下文30%的Agent里，开启前缀缓存能降低约25%的首token延迟，同时省下相应的KV Cache显存。
vLLM默认就支持前缀缓存，启动时加--enable-prefix-caching即可。但要注意，前缀缓存对显存的占用是额外的，如果显存本来就紧张，开了可能反而OOM。建议在显存有余量时开启。
6.2 分页注意力：让KV Cache不再需要连续内存
PagedAttention是vLLM的核心技术之一，它把KV Cache切成固定大小的块，按需分配，不需要连续的大块内存。这带来的好处是显存碎片大幅减少，同样的显存能支撑更多的并发和更长的上下文。
实测数据：在同样24GB显存下，朴素实现只能跑2路8K上下文，用PagedAttention能跑到4路。这个提升对Agent来说很实在，因为Agent的上下文长度和并发数需求都比普通对话高。
6.3 连续批处理：把GPU利用率从30%拉到70%
Agent的负载是突发的，如果按静态批处理，GPU经常在等最慢的那个请求，利用率很低。连续批处理（Continuous Batching）让新请求可以随时插入正在执行的批次，不用等当前批次全部完成。
这个技术对Agent特别友好，因为Agent的多个任务往往处于不同阶段，有的在推理有的在等工具。连续批处理能把这些任务的推理请求动态合并，把GPU利用率从30%左右拉到70%以上。vLLM默认就开启了连续批处理，这也是我推荐用vLLM而不是原生Transformers做Agent推理的重要原因。
6.4 投机解码：用一个小模型加速大模型
投机解码（Speculative Decoding）的思路是用一个小模型先草拟几个token，然后让大模型一次性验证。如果小模型猜得准，大模型就能一次生成多个token，速度提升明显。
在Agent场景下，投机解码的效果取决于任务类型。对于格式固定的工具调用参数生成，小模型猜中的概率高，加速比能到1.5到2倍。对于开放式推理，加速比就低一些。但总体来说，只要显存有余量放小模型，开启投机解码是划算的。
python -m vllm.entrypoints.openai.api_server \ --model Qwen2.5-14B-Instruct \ --speculative-model Qwen2.5-1.5B-Instruct \ --num-speculative-tokens 5 \ --tensor-parallel-size 2这套配置用1.5B模型给14B模型做投机，实测在工具调用场景下能提速约1.6倍。代价是多占约3GB显存放小模型，显存紧张的话要权衡。
7. 关于Agent推理硬件，我个人的几条经验判断
做了几个Agent项目之后，我对硬件选型有几个比较笃定的判断，分享出来供参考。
第一，显存容量永远比算力优先。宁可买一张显存大但算力中等的卡，也不要买算力强但显存小的卡。Agent的上下文和并发需求只会越来越大，显存不够是硬伤，算力不够还能靠量化、投机解码等手段补。
第二，别在开发阶段就追求线上配置。我见过太多人一开始就想着"要支持多少并发"，结果买回来的卡大部分时间在闲置。开发验证阶段，一张24GB卡足够跑通所有逻辑，等真正有负载了再按需扩容。硬件的钱要花在刀刃上。
第三，云端和自建不是二选一，可以组合。日常开发用本地卡，压测和峰值用云端，这样既控制了成本，又保证了弹性。我现在的做法是本地一张4090做开发和轻量测试，需要大规模压测时临时开云端实例，用完就关。
第四，关注推理框架的迭代，比关注硬件参数更重要。过去一年，vLLM、SGLang这些框架在显存利用率和吞吐上的提升，比换一张卡带来的收益还大。同样的硬件，换个框架可能性能翻倍。所以别急着堆硬件，先把框架用对。
最后说一个我踩过的坑：别用游戏卡做7x24的线上服务。消费级卡没有ECC，长时间高负载运行可能出现显存错误，导致推理结果异常。这种错误很隐蔽，不会崩溃，只会让模型输出变得莫名其妙。线上服务还是老老实实上专业卡，或者用云端实例，稳定性比省那点钱重要得多。
