高并发RAG系统延迟优化：召回与生成阶段性能提升策略

高并发场景下的Agent系统，延迟问题往往不是某个单点慢，而是处处都慢一点，最终叠加成用户不可接受的等待。一个典型的RAG Agent请求链路可能是这样的：用户提问 → Query改写 → 向量检索 → 重排序 → Prompt组装 → LLM生成 → 后处理返回。每个环节各花几百毫秒，串联起来就是好几秒。当并发量上去以后，资源竞争和排队效应还会让这些延迟进一步恶化。面试官问这道题，想考察的是你能不能从召回和生成这两个最重的环节切入，拿出系统性的优化方案，而不是只知道加缓存或换小模型这种表面操作。

我们按请求链路的顺序，先拆召回阶段，再拆生成阶段，最后看系统层面怎么把两者串起来做全局优化。

1.1 召回阶段

召回阶段的延迟主要花在三个地方：Query预处理（改写、扩展）、向量检索本身、以及检索后的重排序。高并发场景下，这三步的优化思路差异很大。

向量检索的性能瓶颈，核心在于ANN（近似最近邻）索引的选型和调参。不同的索引算法在延迟、召回率和内存占用之间有截然不同的取舍。IVF类索引通过聚类把向量分成若干桶，检索时只扫描最近的几个桶，速度快但召回率取决于nprobe参数——设太小会漏掉相关文档，设太大又慢回去了。HNSW是目前工程中最常用的索引，它构建一个多层的近邻图，检索时沿着图结构跳转逼近目标，延迟和召回率的平衡最好，但内存开销大，因为要把整个图结构常驻内存。对于数据量特别大（亿级以上）的场景，可以考虑IVF-PQ这种量化压缩方案，用精度换内存和速度。

实际项目中一个容易被忽略的优化点是分区检索。把向量库按业务维度（比如文档类型、租户ID、时间范围）做分区，查询时先根据元数据过滤定位到相关分区，再在分区内做ANN检索。这样做的好处不仅是缩小了搜索空间从而加速，更重要的是在多租户高并发场景下，不同租户的查询落在不同分区，天然减少了资源争抢。Milvus的Partition功能和Qdrant的Payload Index都支持这种用法。

重排序的性能问题是另一个痛点。粗召回拿回Top-100之后，用Cross-Encoder做精排可以显著提升相关性，但Cross-Encoder需要把query和每个候选文档拼接后逐一过模型打分，计算量是O(N)的。当并发上来以后，精排很容易变成瓶颈。优化思路有两个方向：一是减少进入精排的候选数量，在粗召回和精排之间加一层轻量级的预过滤（比如用ColBERT这种late interaction模型做快速初筛，它的token级向量可以预计算，推理时只做向量交互，比Cross-Encoder快一个数量级）；二是精排请求做batching，把多个并发用户的精排请求攒成一批统一送GPU推理，提高硬件利用率。

还有一个经常被忽视的优化方向是混合检索。纯向量检索对语义相似度敏感，但对精确匹配（如专有名词、编号、代码片段）不够好；BM25等稀疏检索则相反。把两者并行执行、结果融合（常用Reciprocal Rank Fusion），不仅召回质量更好，而且两路检索可以并行，总延迟取决于较慢的那一路而非两者之和。

1.2 生成阶段

生成阶段的延迟优化，比召回更复杂，因为LLM推理本身是一个计算密集型任务，而且自回归生成天然是串行的——每个token的生成都依赖前一个token。

KV Cache是生成加速的基石。LLM在自回归解码时，每生成一个新token都需要对之前所有token做Attention计算。如果每次都从头算，计算量随序列长度平方增长，完全不可接受。KV Cache的做法是把之前token在每一层Attention中计算出的Key和Value缓存下来，生成新token时直接复用，避免重复计算。这已经是所有推理框架的标配，但在高并发场景下，KV Cache的内存管理变成了一个新问题——每个请求都需要独立的KV Cache空间，并发量一大，GPU显存很快被撑满。

vLLM提出的PagedAttention机制是目前解决这个问题最优雅的方案。它借鉴了操作系统虚拟内存的思路，把KV Cache按固定大小的“页”来分配和管理，而不是给每个请求预分配一大块连续内存。这样做有两个好处：一是消除了内存碎片，显存利用率可以接近100%；二是支持了KV Cache在不同请求之间的共享——如果多个请求有相同的System Prompt前缀（在Agent系统中这非常常见），它们可以共享这部分KV Cache的物理页，大幅节省显存。显存省下来了，能同时处理的并发请求就多了，排队延迟自然就下来了。

Continuous Batching（连续批处理）是高并发场景下的另一个关键优化。传统的静态batching会等一批请求全部生成完毕才开始处理下一批，这意味着短请求要等长请求——如果一批里有一个请求生成了500个token，其他只需要50个token的请求也得跟着等。Continuous Batching改成了“即完即走”的策略：某个请求生成结束后，它的GPU计算槽位立即释放给排队中的新请求。这种调度机制让GPU始终保持在高利用率状态，吞吐量可以提升2-5倍。vLLM、TGI（Text Generation Inference）、TensorRT-LLM都默认支持这个特性。

推测解码（Speculative Decoding）是从生成算法层面加速的方案。核心思想是用一个小而快的Draft Model先“猜”出若干候选token，然后用大模型一次性并行验证这些候选token是否正确。如果猜对了，就相当于大模型一次前向传播生成了多个token；猜错了，从错误位置开始重新生成，也不会比原来更慢。这种方法在大模型和小模型输出分布比较接近的场景下效果很好，可以实现2-3倍的解码加速，且不影响输出质量（数学上可以证明输出分布和纯大模型完全一致）。

1.3 模型层面的取舍

除了推理框架层面的优化，模型本身也有很多降低延迟的手段。

模型量化是最直接的。把模型权重从FP16量化到INT8或INT4，模型体积缩小到原来的一半甚至四分之一，推理速度相应提升。GPTQ、AWQ等量化方案在大部分任务上的精度损失很小（通常在1-2%以内），性价比极高。特别是在高并发场景下，量化后的模型在同样的GPU上能服务更多并发请求，相当于变相降低了每个请求的排队时间。

模型路由（Model Routing）是一种更精细的策略。不是所有请求都需要最大的模型来回答——简单的问题用小模型足够，复杂的问题才需要大模型。在请求进来时先做一次快速分类（可以用规则、也可以用一个轻量分类器），把简单请求路由到小模型（响应快、成本低），复杂请求路由到大模型（质量高、但更慢）。在实际系统中，往往60-70%的请求都是简单问题，光是把这部分流量卸载到小模型就能大幅降低大模型的排队压力。

1.4 系统架构层面的全局优化

单独优化召回或生成都不够，真正把延迟降到极致还需要从系统架构层面做文章。

召回与生成的流水线并行是一个效果很明显的优化。传统做法是先完成全部检索，再把结果拼进Prompt送去生成——这是串行的。但其实可以做成流水线：检索结果分批返回，第一批结果到了就开始组装Prompt并触发LLM生成（用Streaming方式），后续的检索结果如果拿到了更好的内容，可以在生成过程中动态追加或在下一轮对话中补充。这种方式让用户在检索还没完全结束时就已经看到生成内容在逐步出现，感知延迟大幅降低。

语义缓存（Semantic Cache）是高并发场景下的杀手级优化。传统缓存只能处理完全相同的请求，但用户的提问往往换个说法就miss了。语义缓存的思路是：把历史请求的query embedding和对应的回答存起来，新请求进来时先把query转成embedding，在缓存中做相似度检索，如果找到语义相似度超过阈值的历史请求，直接返回缓存的回答。这种缓存在高并发场景下命中率出乎意料地高——因为大量用户其实在问同类问题。GPTCache就是这类工具的代表。需要注意的是阈值调参很关键：太低会返回不相关的缓存结果，太高又没什么命中。

异步预加载和预热也值得一提。在Agent系统中，很多场景下是可以预判用户下一步行为的。比如用户进入某个业务场景时，可以提前把该场景最可能用到的知识库分区加载到内存、预热相关的KV Cache前缀。当用户真正提问时，检索和生成都从一个“热”的状态开始，而不是冷启动。

最后一个容易被低估的优化是输出长度控制。LLM生成的延迟和输出token数量成正比。在很多Agent场景中，模型倾向于生成冗长的回答，但用户其实只需要一个简短的结论或操作指令。通过Prompt约束（如“用一句话回答”、“直接给出操作步骤”）或设置合理的max_tokens，可以让生成长度缩短50%以上，延迟随之减半。这个优化看起来最不起眼，但在实际项目中效果往往立竿见影。

2. 参考回答

高并发Agent系统的延迟优化，我会从召回、生成、系统架构三个层面来讲。

召回阶段，工程上我们选HNSW索引做底座，多租户场景下按业务维度做分区检索缩小搜索空间，重排序用ColBERT做快速初筛控制进入Cross-Encoder精排的候选量，再配合向量+BM25的混合检索并行执行、RRF融合，召回的延迟和质量都能兼顾。

生成阶段，核心是推理框架的优化——vLLM的PagedAttention消除KV Cache显存碎片并支持前缀共享，Continuous Batching让短请求即完即走不被长请求拖累，模型用AWQ量化到INT4基本不损精度但速度翻倍。我们还做了模型路由，简单请求走小模型，大部分流量都不需要过大模型。

最后在系统层把两者串起来做全局优化，语义缓存把历史query embedding和回答缓存起来做相似度匹配，高并发下命中率很高；召回和生成做流水线并行，第一批检索结果到了就触发Streaming生成，用户感知延迟大幅下降。