同一个 LLM：知识库（RAG）场景 QPS 为何比纯对话低一个数量级？

导读：文章通过同一自部署 LLM 在纯对话与知识库（RAG）两个场景的压测对比，揭示"加一个检索链路、QPS 掉一个数量级"：纯对话单节点稳定 QPS 120+、单问题约 1 秒输出，而 RAG 仅约 2–3 QPS、耗时 20 余秒，差距约 40–60 倍；原因分析聚焦利特尔定律与"向量检索 + 上下文组装 + Rerank + 长上下文解码"整条链路，并给出检索缓存、上下文裁剪、检索与生成服务解耦等优化方向。适合负责 LLM 容量评估、性能压测或 RAG 架构优化的工程师阅读。

分类：性能测试 ｜ 标签：RAG、大模型评测、压测

背景

团队自部署了一套 LLM 服务，对外提供通用 OpenAI 兼容接口 /v1/chat/completions。同一个模型，在两种业务场景下被调用：

• 纯对话：用户提问，模型直接流式生成回答；
• 知识库 / RAG：先根据问题检索知识库中的相关片段，再把候选片段拼进上下文，最终由模型基于检索结果生成回答。

为了评估容量与稳定性，我们对两个场景分别做了压测：由本地施压机发起请求，按 1、10、30、50、70、80、90、100、120、150 个虚拟用户（VU）逐档加压，每档运行 3 分钟，记录成功率、平均响应时间、P90 响应时间、QPS（吞吐量）与是否出现服务端报错。结论差异悬殊：同一个自部署 LLM，从纯对话切到知识库场景后，单节点稳定 QPS 大约低了一个数量级。

数据：两个场景的实测结果

以下两张表的数据均来自压测记录原文（吞吐量保持原始口径，/min 与 /s 混用未统一换算；响应时间单位为毫秒）。纯对话在线上环境压测 5 个并发档位；知识库场景分别在测试环境（9 个档位）与线上环境（5 个档位）各测一轮。

表一：纯对话场景（线上环境，单节点）

原文结论：单节点接口最大稳定 QPS > 120，单个问题约 1 秒内流式输出完成。按 120 QPS 估算，1 分钟可支撑约 7200 人次提问（120 × 60 = 7200）。

表二：知识库 / RAG 场景（测试环境与线上环境，单节点）

原文结论：

• 测试环境：单节点最大稳定 QPS 约 2.0 ~ 2.5；QPS 超过 2.5 系统开始不稳定甚至失败；勉强跑到 4.2 QPS 时成功率降至约 87%。单个问题约 30 秒内流式输出完成，按 2.5 QPS 估算 1 分钟约可支撑 150 人次。
• 线上环境：单节点最大稳定约 3.1 QPS，单个问题约 20 秒内流式输出完成，1 分钟约可支撑 180 ~ 186 人次。

跨场景对照（换算口径同上表）：

• 纯对话（线上）vs 知识库（线上）：稳定 QPS 为 120+ 对 3.1，差距约 40 倍；单问题流式输出约 1 s 对约 20 s。
• 纯对话（线上）vs 知识库（测试）：120+ 对 2.0 ~ 2.5，差距约 48 ~ 60 倍。
• 1 分钟可支撑人次：约 7200 对约 150 ~ 186，同样差一个数量级。

分析：为什么 RAG 的 QPS 低了一个数量级？（推测）

从数据可以提炼出两条主线：

1. 单请求占用的时间变长，直接决定了吞吐上限。 纯对话的响应在几百毫秒到 1 秒级，知识库场景在约 13 ~ 33 秒级，长了一个数量级。在并发数固定的前提下（利特尔定律 Little's Law：QPS ≈ 并发数 ÷ 平均响应时间），服务时间被拉长意味着吞吐量同步下降——这一数量级关系基本可以解释 QPS 的差距。于是真正的问题变成：为什么单个 RAG 请求会慢一个数量级？

2. RAG 在"生成"之前多了一大段检索链路（以下均为推测，需结合链路各环节的耗时数据逐一验证）：

• 向量检索：每个问题都要先做语义向量化，再到向量库中检索候选片段（ANN 索引检索、相似度计算、打分排序）。纯对话没有这一步，且检索耗时与知识库规模、索引参数、召回策略直接相关。
• 文档切分与上下文组装：命中片段需要实时读取、切分、拼接，还要做相关性截断与 prompt 组装（可能涉及重读知识库文档的 IO 开销）。知识库文档越多、命中越多，这个环节越重。
• Rerank 精排：为提升召回质量，常对候选片段再做一次精排打分，相当于链路中多了一次模型推理，串行叠加在总延迟里。
• 长上下文生成：检索片段拼进上下文后，输入 token 数大幅增加。长上下文的 KV Cache 占用更大、单 token 解码成本更高，解码总耗时被拉长——直观体现就是"流式输出从约 1 s 变成约 20 ~ 30 s"。
• 缓存命中率低：纯对话可以复用前缀缓存或常见问答缓存；RAG 的上下文高度依赖"问题 × 知识库命中片段"，缓存几乎不可复用。
• 并发下的放大效应：长请求占用连接、显存的时间更久，并发一上去就容易出现排队与超时，服务端报错随之出现——测试环境从 90 VU 起开始报错、成功率下滑，与这一推断吻合。

另外值得注意：知识库场景测试环境稳定 QPS 为 2.0 ~ 2.5、线上为 3.1，线上硬件更强但仍停留在同一数量级，说明瓶颈不在于单机算力级别，而在于链路设计本身。

结论与建议

1. RAG 场景必须单独压测、单独做容量评估。 同一个模型，纯对话可以按 120+ QPS（约 7200 人次/分钟）规划容量，知识库只能按 2 ~ 3 QPS（约 150 ~ 186 人次/分钟）规划——直接拿纯对话指标套用，容量会差出约 40 倍，上线即被打爆。
2. 容量评估以 RAG 场景自己的压测数据为准，覆盖多档并发、不同知识库规模与长稳场景，明确"稳定 QPS"与"可接受的失败率"边界。
3. 架构与性能优化方向（结合上述推测逐项排查）：
   • 检索层：向量索引参数调优、检索结果缓存、热问题/常见问答缓存；
   • 组装层：命中片段的切分与拼接结果缓存、上下文裁剪（滑动窗口、按相关性截断）；
   • 生成层：长上下文生成优化（KV Cache、并行解码、量化/蒸馏），优先流式输出以降低首包等待；
   • 部署层：检索服务与生成服务解耦、独立扩缩容，为 RAG 场景单独配置限流与排队机制，检索失败时降级为纯对话兜底。

一句话总结：同一个 LLM，"能跑多快"在纯对话场景由解码速度决定，在 RAG 场景则是由"检索 + 组装 + 长上下文解码"整条链路决定。加一个知识库环节，QPS 掉一个数量级，是 RAG 架构的真实成本，容量规划必须按 RAG 自己的数据来。

说明：本文数据来自内部压测记录，已按脱敏要求处理，仅保留数量级口径，供技术方案参考。