rag系列文章目录

前言

在大模型应用中，常会遇到的问题，就是大模型慢。这里一般是受限于GPU资源问题。大模型慢，一般有两种情况，一个是首token慢，二是token流速慢。第一种情况，更难于让人接受，所以优化大模型首token时间，很有必要。

一、解决方案

在一个全流程的大模型应用中，一般会使用到好几次大模型接口，以rag场景为例，首先需要调用意图识别，然后调用query改写，然后再调用大模型输出答案，整个流程是线性的。

在正式调用大模型输出结果之前，调用大模型的接口，是非流式的，需要等待的，而且时间是叠加在一起的，比如一次query改写需要花费0.8s，而意图识别花费0.7s，那么调用大模型流式输出之前，就需要消耗1.5s，大模型流式输出首token一般也需要2-3s，那么客户在看到数据的时候，一般就4-5s了。

这里不细讲优化单次大模型调用首token的优化，而是讨论全流程的首token时间优化，那么很自然的思路就是，能否优化前两次调用的大模型时间。

目前有两种解决方案。
一是前两次模型调用使用小模型，速度快。但是缺点也很明显，就是需要单独部署小模型，而且小模型效果不一定比大模型好。

二是使用prefix cache加速。简而言之，就是有相同前缀的query，前缀会被缓存，从而加速推理。为什么可行呢，因为query改写，意图识别这种大模型调用方式，一般prompt变化很小，而且变化内容可以放到最后，这样就可以使用前缀缓存。

二、Prefix cache介绍

Prefix Caching的核心目标是：
• 当多个请求共享同样的 prompt（或者部分前缀相同），避免重复计算前缀的 attention key/value (KV 缓存)。
• 通过复用 KV cache，大幅提升吞吐量和降低延迟。
举个例子：
• Prompt A: What is the capital of France?
• Prompt B: What is the capital of France? Please explain in detail.
两者前面一部分是相同的，vLLM 会将 What is the capital of France? 计算好的 KV 缓存起来，后续 B 在推理时直接复用这部分缓存，只需要计算额外的 token。

在 vLLM 中，Prefix Cache 依赖 KV Cache 管理机制（PagedAttention + Block Management），PagedAttention，借鉴了“分页内存管理”的思想，把 KV Cache 切分成固定大小的 block 来存储。

一个 block等于一段连续的 KV Cache 存储单元。每个 block 可以容纳若干个 token 的 KV（比如 16 或 32 个 token，具体由配置决定）。不同请求的 KV Cache 会映射到不同的 block，但如果有相同前缀，它们可以直接引用同一个 block（而不是复制）。也就是说前缀缓存，是以block为单位的。

三、首token评测

优化大模型性能指标，一般需要基准测试，没有基准也就没有参考价值。
使用vllm推理框架，可以使用工具（参考文档）测试，如下图所示：

使用华为mindie，可以使用评测工具（参考文档）

benchmark \
--DatasetPath "/{数据集路径}/GSM8K" \
--DatasetType "gsm8k" \
--ModelName "llama3-70b" \
--ModelPath "/{模型路径}/llama3-70b" \
--TestType client \
--Http https://{ipAddress}:{port} \
--ManagementHttp https://{managementIpAddress}:{managementPort} \
--Concurrency 1000 \
--MaxOutputLen 512 \

总结

在很多大模型应用中，都是基于prompt模版调用大模型，prompt变化的部分很小，这样可以基于prefix cache优化模型响应速度。