不同业务场景的瓶颈并不完全相同,因此优化延迟时,不建议只关注单次模型调用速度,而应从模型选择、Prompt 设计、上下文管理、调用链路和交互体验等多个方面共同优化。
本文整理了几类常见的延迟优化方法,帮助开发者在保证回答质量的前提下,构建响应更快、体验更稳定的大模型应用。
一、选择适合任务的模型和调用方式
不是所有任务都需要使用能力最强的模型。实际业务中,一次用户请求往往会拆分成多个子任务,例如意图识别、问题改写、知识库检索、结果判断、最终回答生成等。不同子任务对模型能力的要求不同,如果全部使用同一个高能力模型,可能会带来不必要的响应时间和成本开销。1. 选择适合的模型
对于边界清晰、输出简单的任务,可以优先选择轻量模型、高速模型或高性价比模型,例如:- 意图识别
- 文本分类
- 关键词抽取
- 格式转换
- 简单摘要
- 检索 Query 改写
- 规则明确的结构化信息提取
2. 设置模型思考参数
如果使用的模型支持思考模式相关参数,也可以根据任务复杂度进行控制。对于数学推理、复杂规划、多步骤分析等任务,可以开启更充分的思考;对于简单分类、固定格式抽取、短文本改写等任务,则可以关闭或减少不必要的深度思考,从而获得更快的响应。 建议开发者在设计链路时,先拆分任务类型,再为不同环节选择合适的模型,而不是默认将所有步骤都交给同一个模型完成。二、减少不必要的输出内容
在多数文本生成场景中,模型输出长度会显著影响整体响应时间。输出越长,模型需要生成的 Token 越多,用户等待完整结果的时间也越长。因此,减少不必要的输出,是最直接、最稳定的延迟优化方式之一。 可以从以下几个方面优化:1. 控制输出长度
在多数生成场景中,输出内容越长,模型需要生成的 Token 越多,整体响应时间也会随之增加。因此,控制输出长度是降低延迟最直接的方法之一。 开发者可以从两个层面进行控制:一是在 Prompt 中明确回答长度和结构,二是在接口参数中设置合理的最大输出长度。前者用于引导模型生成更短、更聚焦的内容,后者用于避免模型输出超出业务预期。 例如,在智能客服、知识库问答、摘要生成等场景中,可以在 Prompt 中加入明确约束:2. 避免重复生成固定模板
对于固定开头、固定结尾、标准说明、免责声明等内容,建议由业务系统拼接,而不是每次都让模型重新生成。 例如,客服场景中可以将固定话术放在前端或后端模板中,只让模型生成真正需要动态回答的部分。这样既能减少输出 Token,也能让内容风格更加稳定。3. 精简结构化输出字段
在一些业务场景中,模型的输出并不是直接展示给用户,而是供后端程序继续处理。 以智能客服场景为例。智能客服需要先判断用户意图,再决定是否进入退款流程、是否检索知识库、是否转人工。这类场景通常会要求模型输出 JSON,方便系统解析和执行后续动作。 此时,JSON 字段应尽量保持简洁、稳定和必要。字段过多、字段名过长,都会增加模型生成内容,也会提高后续解析和维护成本。 例如,用户输入:intent 用于识别用户意图,need_search 用于判断是否需要检索知识库或订单信息,query 用于生成后续检索关键词。相比让模型输出一大段解释,这种结构化结果更短、更稳定,也更适合程序直接读取。
如果字段只供系统内部使用,应避免加入不必要的说明性内容。例如,不建议让模型输出:
三、控制输入内容,减少无效上下文
输入内容越长,模型需要处理的信息越多。在长对话、知识库问答、文档分析和 Agent 场景中,如果每次请求都携带大量历史内容、无关材料或重复提示词,就会增加处理成本和响应延迟。 可以从以下几个方面优化输入内容。1. 清理无关历史对话
多轮对话中,不一定需要把全部历史消息都传给模型。可以根据当前问题,只保留与本轮任务相关的关键信息。 例如,用户连续咨询订单问题时,可以保留订单号、问题类型、已确认状态等信息,而不必完整保留所有寒暄、重复确认和无关上下文。2. 对长上下文进行摘要
对于较长的历史对话或文档内容,可以先沉淀为结构化摘要,再作为后续输入。 例如:3. 优化 RAG 检索结果
知识库问答场景中,常见问题不是模型能力不足,而是检索结果过多、过长或相关性不足。建议在进入模型前,对检索结果进行筛选和压缩。 可以考虑:- 控制 Top-K 数量
- 去除重复片段
- 优先保留与问题最相关的段落
- 删除网页导航、页脚、版权说明等无关内容
- 对长文档片段做摘要后再输入模型
4. 使用上下文缓存复用重复内容
如果业务中存在大量重复上下文,例如固定系统提示词、长期不变的工具说明、知识库说明、角色设定或历史对话片段,可以结合上下文缓存能力,减少重复内容带来的处理成本。 适合使用上下文缓存的场景包括:- 多轮对话中反复使用相同系统提示词
- 知识库问答中反复使用相同背景材料
- 批量处理任务中反复使用同一套分析规则
- 长文档问答中围绕同一份文档连续提问
4.1 将稳定内容放在 Prompt 前部
在组织 Prompt 时,建议将长期不变、可复用的内容放在前部,例如系统角色、回答规范、工具说明、业务规则等;将每次请求都会变化的内容放在后部,例如用户本轮问题、检索结果、时间、订单状态等。 例如,知识库问答场景可以按以下顺序组织:4.2 保持系统提示词稳定
如果希望系统提示词被反复缓存,就不要在每次请求中频繁改写它。即使只是增加时间戳、随机编号、临时说明,或者调整段落顺序,也可能降低缓存命中效果。 不建议这样写:4.3 把长文档、工具说明和业务规则做成固定模板
在 Agent、文档问答、代码审查等场景中,工具说明、任务规则、评分标准、输出格式往往很长。如果这些内容每次都需要传入,建议整理成稳定模板,避免每次请求临时拼接不同版本。 例如,代码审查场景中,不要每次都让系统随机生成审查标准,而是固定为一套稳定规则:4.4 对高频任务使用统一 Prompt 模板
如果同一个业务场景下有多个入口,例如 Web 端、控制台、客服后台都在调用同一个模型能力,建议共用同一套 Prompt 模板,而不是每个入口各写一份类似但不完全相同的提示词。 例如,企业知识库问答可以统一成:4.5 将固定回复交给程序处理
上下文缓存可以减少重复上下文的处理成本,但并不意味着所有固定内容都要交给模型生成。对于高度固定的回复,建议直接由业务系统返回。 例如:4.6 观察缓存命中情况
接入上下文缓存后,建议不要只凭感觉判断效果,而是观察接口返回中的缓存命中信息,例如缓存命中的 Token 数、总输入 Token 数、响应时间变化等。四、减少串行模型调用
很多大模型应用的延迟并不来自单次模型调用,而是来自多个模型调用串行执行。比如一个请求需要先调用模型判断意图,再调用模型改写 Query,再调用模型判断是否检索,最后再调用模型生成回答。如果这些步骤全部串行执行,整体等待时间会被不断放大。 优化思路是:能合并的步骤尽量合并,能并行的步骤尽量并行,能用程序逻辑完成的步骤不要交给模型。1. 合并相近任务
在知识库问答、智能客服等场景中,用户的表达方式往往是不固定的。例如,下面几种问法本质上可能都在询问同一个问题:- 第一次模型调用:判断用户意图
- 第二次模型调用:判断是否需要检索知识库
- 第三次模型调用:改写检索 Query
intent 是模型从开发者预设的意图类型中选择出来的结果;need_search 是模型根据规则判断是否需要检索知识库;search_query 是模型对用户问题进行改写后生成的检索关键词。
这样,系统只需要调用一次模型,就能同时获得后续流程所需的信息。后端程序拿到这段 JSON 后,可以根据 need_search 决定是否检索知识库,再用 search_query 去查找相关文档,最后将检索结果交给模型生成回答。
这里的“一次模型调用”指的是:开发者在同一个 Prompt 中要求模型同时完成意图识别、检索判断和 Query 改写,并以同一个 JSON 返回结果。这样原本需要多次请求模型完成的轻量判断,可以合并为一次请求,从而减少串行调用带来的延迟。
2. 并行处理互不依赖的任务
如果多个任务之间没有强依赖关系,可以并行执行。 例如,在内容生成场景中,可以同时进行:- 敏感词检测
- 用户画像读取
- 知识库检索
- 历史摘要生成
3. 用程序逻辑替代简单判断
有些任务并不需要模型完成,例如:- 判断字段是否为空
- 判断用户是否登录
- 判断订单状态是否存在
- 判断金额是否超过阈值
- 固定按钮文案生成
- 标准错误提示返回
五、使用流式输出降低用户等待感
在交互式场景中,用户感受到的延迟不只是“完整回答生成完毕的时间”,还包括“多久能看到第一段内容”。即使整体生成时间不变,如果用户能更早看到输出开始出现,等待体验也会明显改善。 因此,对于聊天对话、智能客服、长文本生成、代码生成、Agent 执行等场景,建议优先使用流式输出。 非流式输出会在模型完成全部生成后一次性返回结果,适合短文本、批处理、后台任务等场景。流式输出则可以在模型生成过程中持续返回内容,让前端实时展示生成结果,更适合实时交互。 例如:- 显示“正在生成”
- 实时展示已生成内容
- 对长任务展示阶段性状态
- 工具调用时展示“正在检索”“正在分析”“正在生成”
- 对 Agent 多步骤任务展示执行进度
六、避免默认使用大模型解决所有问题
大模型适合处理开放式、复杂性高、规则难以穷举的问题,但并不是所有问题都应该交给大模型。为了降低延迟和成本,开发者应优先判断任务是否真的需要模型参与。 以下任务通常可以不用模型完成:- 固定文案返回
- 表单字段校验
- 状态码解释
- 简单规则判断
- 数据库精确查询
- 用户权限判断
- 固定流程引导
- 常见问题的标准答案匹配
七、延迟优化检查清单
上线前,可以用以下问题检查应用是否还有优化空间:模型选择
- 是否所有任务都使用了同一个模型?
- 简单分类、改写、抽取任务是否可以使用更轻量的模型?
- 复杂推理任务是否需要开启更强的思考能力?
- 简单任务是否可以关闭不必要的深度思考?
输出控制
- 是否限制了回答长度?
- 是否设置了合理的最大输出 Token 数?
- 是否避免模型生成固定模板内容?
- JSON 字段是否足够简洁?
输入控制
- 是否传入了无关历史对话?
- RAG 检索结果是否过多?
- 是否去除了重复、低相关或无效内容?
- 重复上下文是否可以使用缓存?
调用链路
- 是否存在多个串行模型调用?
- 是否可以合并相近任务?
- 是否可以并行执行互不依赖的步骤?
- 是否有简单规则本可以用程序逻辑完成?
用户体验
- 是否开启流式输出?
- 前端是否展示生成状态?
- 长任务是否展示阶段性进度?
- 工具调用或检索过程是否有反馈?