企业官网建设流程全解析

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 是 8（GQA），head_dim 是 128。每个 token 的 KV Cache 就是 2 × 40 × 8 × 128 × 2 = 163840 bytes，约 160KB。听起来不多对吧？但 32K 上下文就是 160KB × 32768 ≈ 5.2GB。这还只是一个会话。如果并发 10 个会话，光 KV Cache 就要 52GB 显存，加上模型权重本身 28GB（FP16），总共 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 显存容量怎么算才不翻车

先给一个实操的计算框架。你需要估算四个部分：

这个结果意味着一张 80GB 的卡不够，你需要两张 48GB 的卡做张量并行，或者用 INT8 量化把权重压到 14GB，KV 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.8ms，A100 需要 13.7ms，H100 需要 8.4ms。这个差距直接体现在吞吐上。

但这里有个反直觉的点：如果你用的是小模型（7B 以下）加上短上下文，消费卡的带宽其实够用，因为计算量小，瓶颈可能转移到 CPU 编排上。只有当模型大于 14B 或者上下文超过 16K 时，带宽差距才会被放大到不可忽视。

2.3 多卡互联：NVLink 不是必须但很香

Agent 推理如果单卡放不下，就要做张量并行或流水线并行。这时候卡间通信带宽就很重要。NVLink 的带宽是 PCIe 5.0 的 5 到 10 倍，在张量并行场景下差距非常明显。

我做过一个对比测试，两张 4090 通过 PCIe 做张量并行跑 32B 模型，相比两张 A6000 通过 NVLink 跑同样的模型，吞吐差了将近 2.3 倍。原因就是张量并行每层都要做 All-Reduce，PCIe 的带宽成了瓶颈。

但也不是所有场景都需要 NVLink。如果你用的是流水线并行，或者干脆用两张卡各跑各的实例做数据并行，PCIe 就够了。数据并行在 Agent 场景里其实很实用，因为每个 Agent 会话是独立的，天然适合分卡处理。

2.4 消费卡、专业卡、数据中心卡的真实差距

我把常见的几类卡在 Agent 推理场景下的表现整理成表：

选型的逻辑很简单：先算显存需求，再看带宽是否够，最后看互联需求。不要反过来先选卡再想办法塞模型。

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 存储：别忽视向量库的 IO

Agent 通常要接向量数据库做 RAG。如果向量库是本地部署的，存储的 IO 性能会影响检索速度。NVMe SSD 是必须的，SATA SSD 在并发检索时会出现明显的延迟抖动。

容量上，向量库的大小取决于你的知识库规模。一个百万级文档的向量库，用 768 维 FP32 存储，大约需要 3GB 到 5GB。加上索引文件，预留 50GB 到 100GB 的 NVMe 空间比较合理。

4. 不同规模 Agent 项目的硬件配置方案

理论讲完了，直接给几套可抄的配置。我按项目规模分三档，每档给出具体的硬件清单和适用场景。

4.1 个人开发与验证：单卡方案

这档适合个人开发者做 Agent 原型验证、学习、小规模测试。核心诉求是便宜、够用、能跑起来。

这套配置能跑什么：7B 到 14B 的量化模型，上下文 16K 到 32K，并发 3 到 5 个 Agent 会话。再往上就吃力了。

实操心得：个人开发阶段，模型量化是必须的。用 AWQ 量化把 14B 模型压到 8GB 左右，KV Cache 用 FP8 存储，能把 24GB 显存的利用率拉到 90% 以上。别硬跑 FP16，显存不够会频繁触发 offload，速度直接掉一个数量级。

4.2 小团队生产：双卡方案

这档适合小团队做正式产品，需要支撑几十个并发用户。核心诉求是稳定、可扩展、性价比合理。

这套配置能跑什么：14B FP16 或 32B 量化模型，上下文 32K，并发 15 到 25 个 Agent 会话。如果做数据并行，每个卡跑一个实例，并发能力翻倍但单实例上下文受限。

4.3 中型部署：四卡起步

这档适合有明确业务场景、需要支撑上百并发的团队。核心诉求是吞吐、稳定性、可运维性。

这套配置能跑什么：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.9，Agent 场景建议调到 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 awq

enable-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 单核瓶颈。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 推理的瓶颈在显存，不在算力。