> ## Documentation Index > Fetch the complete documentation index at: https://docs.bigmodel.cn/llms.txt > Use this file to discover all available pages before exploring further. # 如何优化模型返回速度 大模型应用的整体延迟通常由多种原因造成： Description 不同业务场景的瓶颈并不完全相同，因此优化延迟时，不建议只关注单次模型调用速度，而应从**模型选择、Prompt 设计、上下文管理、调用链路和交互体验**等多个方面共同优化。 本文整理了几类常见的延迟优化方法，帮助开发者在保证回答质量的前提下，构建响应更快、体验更稳定的大模型应用。 ## 一、选择适合任务的模型和调用方式 不是所有任务都需要使用能力最强的模型。实际业务中，一次用户请求往往会拆分成多个子任务，例如意图识别、问题改写、知识库检索、结果判断、最终回答生成等。不同子任务对模型能力的要求不同，如果全部使用同一个高能力模型，可能会带来不必要的响应时间和成本开销。 ### 1. 选择适合的模型 对于边界清晰、输出简单的任务，可以优先选择轻量模型、高速模型或高性价比模型，例如： * 意图识别 * 文本分类 * 关键词抽取 * 格式转换 * 简单摘要 * 检索 Query 改写 * 规则明确的结构化信息提取 对于复杂推理、长文本生成、代码生成、多轮规划、复杂 Agent 执行等任务，则可以选择能力更强的模型，以保证任务完成质量。 ### 2. 设置模型思考参数 如果使用的模型支持思考模式相关参数，也可以根据任务复杂度进行控制。对于数学推理、复杂规划、多步骤分析等任务，可以开启更充分的思考；对于简单分类、固定格式抽取、短文本改写等任务，则可以关闭或减少不必要的深度思考，从而获得更快的响应。 建议开发者在设计链路时，先拆分任务类型，再为不同环节选择合适的模型，而不是默认将所有步骤都交给同一个模型完成。 ## 二、减少不必要的输出内容 在多数文本生成场景中，模型输出长度会显著影响整体响应时间。输出越长，模型需要生成的 Token 越多，用户等待完整结果的时间也越长。因此，减少不必要的输出，是最直接、最稳定的延迟优化方式之一。 可以从以下几个方面优化： ### 1. 控制输出长度 在多数生成场景中，输出内容越长，模型需要生成的 Token 越多，整体响应时间也会随之增加。因此，控制输出长度是降低延迟最直接的方法之一。 开发者可以从两个层面进行控制：一是在 **Prompt 中明确回答长度和结构**，二是在**接口参数中设置合理的最大输出长度**。前者用于引导模型生成更短、更聚焦的内容，后者用于避免模型输出超出业务预期。 例如，在智能客服、知识库问答、摘要生成等场景中，可以在 Prompt 中加入明确约束： ``` - 请用 3 条要点回答，每条不超过 30 字。 - 请直接给出结论，不需要解释推理过程。 - 请输出简洁版本，控制在 200 字以内。 ``` 相比“请详细回答”、“请完整说明”这类开放式指令，明确长度和结构的 Prompt 更容易让模型生成短而聚焦的结果。 对于输出形式比较固定的任务，还可以进一步限制模型只返回必要内容。例如： ``` 请只输出 true 或 false。 ``` 同时，在确定业务场景不需要长文本时，可以设置合理的最大输出 Token 数，避免模型继续生成不必要的内容。例如，分类、判断、标签抽取等任务通常只需要很短的输出；长文本摘要、报告生成等任务则可以根据实际展示空间和业务需要设置更高的上限。 需要注意的是，最大输出长度并不是越大越好。如果设置过大，模型可能生成超出预期的内容；如果设置过小，则可能导致回答被截断。实际使用中，建议根据任务类型、前端展示位置和用户需求设置合适范围。 ### 2. 避免重复生成固定模板 对于固定开头、固定结尾、标准说明、免责声明等内容，建议由业务系统拼接，而不是每次都让模型重新生成。 例如，客服场景中可以将固定话术放在前端或后端模板中，只让模型生成真正需要动态回答的部分。这样既能减少输出 Token，也能让内容风格更加稳定。 ### 3. 精简结构化输出字段 在一些业务场景中，模型的输出并不是直接展示给用户，而是供后端程序继续处理。 以智能客服场景为例。智能客服需要先判断用户意图，再决定是否进入退款流程、是否检索知识库、是否转人工。这类场景通常会要求模型输出 JSON，方便系统解析和执行后续动作。 此时，JSON 字段应尽量保持**简洁、稳定和必要**。字段过多、字段名过长，都会增加模型生成内容，也会提高后续解析和维护成本。 例如，用户输入： ``` 我想查一下退款什么时候到账。 ``` 模型可以只输出业务系统真正需要的字段： ``` { "intent": "refund_status", "need_search": true, "query": "退款到账时间查询" } ``` 其中，`intent` 用于识别用户意图，`need_search` 用于判断是否需要检索知识库或订单信息，`query` 用于生成后续检索关键词。相比让模型输出一大段解释，这种结构化结果更短、更稳定，也更适合程序直接读取。 如果字段只供系统内部使用，应避免加入不必要的说明性内容。例如，不建议让模型输出： ``` { "user_intent_description": "用户想要查询退款什么时候可以到账", "whether_knowledge_base_search_is_required": true, "rewritten_search_query_for_retrieval": "退款到账时间查询" } ``` 这类字段虽然更容易被人理解，但对程序解析并没有额外帮助，反而会增加输出长度。实际使用中，应根据业务需要保留必要字段即可。 ## 三、控制输入内容，减少无效上下文 输入内容越长，模型需要处理的信息越多。在长对话、知识库问答、文档分析和 Agent 场景中，如果每次请求都携带大量历史内容、无关材料或重复提示词，就会增加处理成本和响应延迟。 可以从以下几个方面优化输入内容。 ### 1. 清理无关历史对话 多轮对话中，不一定需要把全部历史消息都传给模型。可以根据当前问题，只保留与本轮任务相关的关键信息。 例如，用户连续咨询订单问题时，可以保留订单号、问题类型、已确认状态等信息，而不必完整保留所有寒暄、重复确认和无关上下文。 ### 2. 对长上下文进行摘要 对于较长的历史对话或文档内容，可以先沉淀为结构化摘要，再作为后续输入。 例如： ``` 用户背景： - 用户已购买企业版套餐 - 当前问题是无法查看用量明细 - 已确认账号权限正常 - 需要继续排查组织空间配置 ``` 这种方式比直接传入完整对话更短，也更方便模型抓住重点。 ### 3. 优化 RAG 检索结果 知识库问答场景中，常见问题不是模型能力不足，而是检索结果过多、过长或相关性不足。建议在进入模型前，对检索结果进行筛选和压缩。 可以考虑： * 控制 Top-K 数量 * 去除重复片段 * 优先保留与问题最相关的段落 * 删除网页导航、页脚、版权说明等无关内容 * 对长文档片段做摘要后再输入模型 RAG 场景中，输入内容的质量往往比长度更重要。少量高相关内容，通常优于大量低相关内容。 ### 4. 使用上下文缓存复用重复内容 如果业务中存在大量重复上下文，例如固定系统提示词、长期不变的工具说明、知识库说明、角色设定或历史对话片段，可以结合上下文缓存能力，减少重复内容带来的处理成本。 适合使用上下文缓存的场景包括： * 多轮对话中反复使用相同系统提示词 * 知识库问答中反复使用相同背景材料 * 批量处理任务中反复使用同一套分析规则 * 长文档问答中围绕同一份文档连续提问 为了提高缓存命中效果，开发者可以从以下几个方面优化： #### 4.1 将稳定内容放在 Prompt 前部 在组织 Prompt 时，建议将**长期不变、可复用的内容放在前部**，例如系统角色、回答规范、工具说明、业务规则等；将**每次请求都会变化的内容放在后部**，例如用户本轮问题、检索结果、时间、订单状态等。 例如，知识库问答场景可以按以下顺序组织： ``` 固定部分： - 你是一个企业知识库问答助手 - 回答要求：准确、简洁，不编造 - 如果资料不足，请说明无法确认 - 输出格式：先给结论，再补充依据 动态部分： - 用户本轮问题 - 本次检索到的知识库片段 ``` 这样做的好处是，前半部分在多次请求中保持稳定，更容易被缓存复用；后半部分虽然每次变化，但不会影响前面固定内容的复用效果。 #### 4.2 保持系统提示词稳定 如果希望系统提示词被反复缓存，就不要在每次请求中频繁改写它。即使只是增加时间戳、随机编号、临时说明，或者调整段落顺序，也可能降低缓存命中效果。 不建议这样写： ``` 你是一个客服助手。当前时间是 2026-06-08 14:32:10。 请根据用户问题回答。 ``` 如果时间不是模型判断所必需的信息，可以不要放入系统提示词；如果确实需要时间信息，可以放到用户问题或动态上下文中： ``` 系统提示词： 你是一个客服助手。请根据业务规则准确回答用户问题。 动态上下文： 当前日期：2026-06-08 用户问题：我的套餐什么时候到期？ ``` 这样可以让系统提示词保持稳定，同时保留必要的动态信息。 #### 4.3 把长文档、工具说明和业务规则做成固定模板 在 Agent、文档问答、代码审查等场景中，工具说明、任务规则、评分标准、输出格式往往很长。如果这些内容每次都需要传入，建议整理成稳定模板，避免每次请求临时拼接不同版本。 例如，代码审查场景中，不要每次都让系统随机生成审查标准，而是固定为一套稳定规则： ``` 你是一个代码审查助手，请从以下方面进行检查： 1. 代码可读性 2. 潜在 Bug 3. 性能问题 4. 安全风险 5. 可维护性建议 请按“问题 - 原因 - 修改建议”的格式输出。 ``` 后续每次只替换待审查代码即可 ``` 请审查以下代码： {{code_snippet}} ``` 这样可以让审查规则被反复复用，而真正变化的部分只保留在后面。 #### 4.4 对高频任务使用统一 Prompt 模板 如果同一个业务场景下有多个入口，例如 Web 端、控制台、客服后台都在调用同一个模型能力，建议共用同一套 Prompt 模板，而不是每个入口各写一份类似但不完全相同的提示词。 例如，企业知识库问答可以统一成： ``` 系统提示词： 你是一个企业知识库助手。请严格依据提供的资料回答问题。 如果资料中没有相关信息，请回答“当前资料中未找到明确说明”。 动态输入： 用户问题：{{user_question}} 检索资料：{{retrieved_context}} ``` 这样不仅有利于缓存复用，也方便后续统一维护和评估效果。 #### 4.5 将固定回复交给程序处理 上下文缓存可以减少重复上下文的处理成本，但并不意味着所有固定内容都要交给模型生成。对于高度固定的回复，建议直接由业务系统返回。 例如： ``` - “已收到您的反馈” - “请先登录后再操作” - “当前账号暂无权限” - “请补充订单号” - “系统繁忙，请稍后重试” ``` 这些内容可以在程序中硬编码，或提前配置为模板。只有当用户问题需要自然语言理解、上下文判断或个性化生成时，再调用模型。这样可以直接减少模型请求次数，比单纯依赖缓存更有效。 #### 4.6 观察缓存命中情况 接入上下文缓存后，建议不要只凭感觉判断效果，而是观察接口返回中的缓存命中信息，例如缓存命中的 Token 数、总输入 Token 数、响应时间变化等。 ## 四、减少串行模型调用 很多大模型应用的延迟并不来自单次模型调用，而是来自多个模型调用串行执行。比如一个请求需要先调用模型判断意图，再调用模型改写 Query，再调用模型判断是否检索，最后再调用模型生成回答。如果这些步骤全部串行执行，整体等待时间会被不断放大。 优化思路是：能合并的步骤尽量合并，能并行的步骤尽量并行，能用程序逻辑完成的步骤不要交给模型。 ### 1. 合并相近任务 在知识库问答、智能客服等场景中，用户的表达方式往往是不固定的。例如，下面几种问法本质上可能都在询问同一个问题： ``` - 企业版在哪里看每个人的用量明细？ - 团队成员各自用了多少 token，在哪里查？ - 管理员能不能看到每个成员的调用量？ ``` 如果系统要处理这类问题，通常需要先完成几件事：判断用户意图、判断是否需要检索知识库、把用户问题改写成更适合检索的关键词。 一种比较低效的方式是把这几个步骤拆成多次模型调用： * 第一次模型调用：判断用户意图 * 第二次模型调用：判断是否需要检索知识库 * 第三次模型调用：改写检索 Query 但这三个任务都依赖同一句用户输入，而且输出结果都比较简单，因此可以合并到一次模型调用中完成。 开发者可以提前定义好输出字段和可选意图类型，例如： ``` 请根据用户问题输出 JSON： - intent：用户意图，只能从 usage_detail_query、billing_query、technical_issue、other 中选择 - need_search：是否需要检索知识库 - search_query：如果需要检索，请生成适合知识库检索的关键词；如果不需要，则为空字符串 ``` 当用户输入： ``` 企业版在哪里看每个人的用量明细？ ``` 模型可以一次性输出： ``` { "intent": "usage_detail_query", "need_search": true, "search_query": "企业版 成员 用量明细 查看方式" } ``` 其中，`intent` 是模型从开发者预设的意图类型中选择出来的结果；`need_search` 是模型根据规则判断是否需要检索知识库；`search_query` 是模型对用户问题进行改写后生成的检索关键词。 这样，系统只需要调用一次模型，就能同时获得后续流程所需的信息。后端程序拿到这段 JSON 后，可以根据 need\_search 决定是否检索知识库，再用 search\_query 去查找相关文档，最后将检索结果交给模型生成回答。 这里的“一次模型调用”指的是：开发者在同一个 Prompt 中要求模型同时完成意图识别、检索判断和 Query 改写，并以同一个 JSON 返回结果。这样原本需要多次请求模型完成的轻量判断，可以合并为一次请求，从而减少串行调用带来的延迟。 优化后的链路可以变为： ``` 用户输入 ↓ 一次模型调用完成：意图识别 + 是否检索 + Query 改写 ↓ 必要时检索知识库 ↓ 生成最终回答 ``` 这种方式适合意图识别、检索判断、Query 改写、简单分类等轻量任务。对于复杂推理、长文本生成或需要多步判断的任务，则不建议强行合并，以免影响结果质量。 ### 2. 并行处理互不依赖的任务 如果多个任务之间没有强依赖关系，可以并行执行。 例如，在内容生成场景中，可以同时进行： * 敏感词检测 * 用户画像读取 * 知识库检索 * 历史摘要生成 等这些结果都准备好后，再进入最终回答生成环节。这样可以减少用户等待完整链路执行的时间。 ### 3. 用程序逻辑替代简单判断 有些任务并不需要模型完成，例如： * 判断字段是否为空 * 判断用户是否登录 * 判断订单状态是否存在 * 判断金额是否超过阈值 * 固定按钮文案生成 * 标准错误提示返回 这类任务应优先使用规则、函数、数据库查询或缓存完成。模型更适合处理自然语言理解、生成、推理和复杂判断，不应承担所有业务逻辑。 ## 五、使用流式输出降低用户等待感 在交互式场景中，用户感受到的延迟不只是“完整回答生成完毕的时间”，还包括“多久能看到第一段内容”。即使整体生成时间不变，如果用户能更早看到输出开始出现，等待体验也会明显改善。 因此，对于**聊天对话、智能客服、长文本生成、代码生成、Agent 执行**等场景，建议优先使用流式输出。 非流式输出会在模型完成全部生成后一次性返回结果，适合短文本、批处理、后台任务等场景。流式输出则可以在模型生成过程中持续返回内容，让前端实时展示生成结果，更适合实时交互。 例如： ``` { "model": "glm-5.1", "messages": [ { "role": "user", "content": "请帮我总结这篇文章的核心观点" } ], "stream": true } ``` 在前端体验上，也可以结合以下方式进一步降低等待感： * 显示“正在生成” * 实时展示已生成内容 * 对长任务展示阶段性状态 * 工具调用时展示“正在检索”“正在分析”“正在生成” * 对 Agent 多步骤任务展示执行进度 对于复杂任务，用户不一定要求每一步都立即完成，但需要知道任务正在推进。合理的流式输出和状态反馈，可以显著改善应用体验。 ## 六、避免默认使用大模型解决所有问题 大模型适合处理开放式、复杂性高、规则难以穷举的问题，但并不是所有问题都应该交给大模型。为了降低延迟和成本，开发者应优先判断任务是否真的需要模型参与。 以下任务通常可以不用模型完成： * 固定文案返回 * 表单字段校验 * 状态码解释 * 简单规则判断 * 数据库精确查询 * 用户权限判断 * 固定流程引导 * 常见问题的标准答案匹配 例如，用户问“如何修改密码”，如果系统已有标准帮助文档或固定流程，可以直接返回模板答案；只有当用户问题表达复杂、上下文不清晰或需要结合多条信息综合判断时，再交给模型处理。 这种方式不仅可以降低延迟，也能提升系统稳定性，避免模型在简单问题上产生不必要的不确定性。 ## 七、延迟优化检查清单 上线前，可以用以下问题检查应用是否还有优化空间： #### 模型选择 * 是否所有任务都使用了同一个模型？ * 简单分类、改写、抽取任务是否可以使用更轻量的模型？ * 复杂推理任务是否需要开启更强的思考能力？ * 简单任务是否可以关闭不必要的深度思考？ #### 输出控制 * 是否限制了回答长度？ * 是否设置了合理的最大输出 Token 数？ * 是否避免模型生成固定模板内容？ * JSON 字段是否足够简洁？ #### 输入控制 * 是否传入了无关历史对话？ * RAG 检索结果是否过多？ * 是否去除了重复、低相关或无效内容？ * 重复上下文是否可以使用缓存？ #### 调用链路 * 是否存在多个串行模型调用？ * 是否可以合并相近任务？ * 是否可以并行执行互不依赖的步骤？ * 是否有简单规则本可以用程序逻辑完成？ #### 用户体验 * 是否开启流式输出？ * 前端是否展示生成状态？ * 长任务是否展示阶段性进度？ * 工具调用或检索过程是否有反馈？ ## 总结 大模型应用的延迟优化，本质上是在模型能力、响应速度、调用成本和用户体验之间取得平衡。开发者可以结合具体业务链路，优先优化最影响等待体验的环节，让应用响应更快、交互更自然。