当前市面上有非常多的AI问答产品，自带AI问答甚至成立产品不可或缺的能力，当我们在实际使用中，我们会发现有的问答机器人2秒就开始回答问题，而有的机器人要8秒、9秒才开始回答。
同样是问答产品，甚至同样是RAG产品，为什么回答的速度会差距如此之大呢？
今天这篇文章，从我过去的实战优化经验，给大家分享一下AI产品回复速度的几种优化方案。
要知道如何优化，首先我们要知道两件事情：
- AI产品回复为什么会慢？慢在哪里？
- AI产品要提速，能提到多少？AI产品的回复速度上限是多少？
AI产品回复到底慢在哪里
花开两朵，各表一枝。
我们先来说一下，AI产品回复慢，是慢在哪里？
- 慢在大模型节点太多
当前真正落地的AI产品中，基本上都是使用workflow（工作流）实现的，而workflow中几乎都使用到了多处AI节点。
每处AI节点都会有大模型的推理耗时，多个节点凑到一起，积少成多，自然就慢了。
- 慢在大模型推理耗时
在每个大模型节点进行推理时，不控制上下文，不控制输入输出。导致大模型推理输出的太多的废话，导致大模型节点耗时过长。
针对这部分，我们的优化逻辑是优化workflow节点、优化大模型提示词，控制输入输出，以此来控制耗时。
优化workflow节点
优化workflow节点，遵循两个原则：程序优先原则和最小提示词原则来做到优化workflow节点。
程序优先原则
能用程序判断的内容就不要用大模型去判断。
例如：我们使用大模型判断用户是否完成信息输入（例如“用户是否提供了所有必要字段？”）
如果场景中用户输入是完全随机的，那么用大模型进行判断时没问题的。
但是在一些用户输入拥有明确字段的场景中，用户的输入是完全可以使用程序进行字段完整性检查就能做到，那么此时就不需要使用大模型了。
有很多人会在实际应用中，搞错边界，忽略掉原本程序的解决能力才是更快更稳定的这件事。
切记：在考虑使用大模型处理之前，一定要先考虑用程序是否可以处理。
最小提示词原则
能合并成一套提示词处理的就不要用两套提示词处理。
例如：我们的售前机器人实战专栏中，为了应对用户query中存在多个意图的情况，我们对用户的query进行了拆分，然后对拆分的query进行分别的意图匹配。
用户提问：你们的A产品和B产品分别卖多少钱呢？
问题拆分：你们的A产品卖多少钱？、你们的B产品卖多少钱？
然后两个问题分别在执行workflow时，进行意图匹配。
这个流程就执行了两次大模型：问题拆分 和 意图匹配。
所以，为了优化这个点：我们把两个提示词合并，同时进行问题拆分和意图匹配
最终得到的拆分结果是：[{query:"你们的A产品卖多少钱？",intent:"产品介绍",name:"A产品"}{query:"你们的B产品卖多少钱？",intent:"产品介绍",name:"B产品"}]
优化提示词
大模型的推理时长、首tokens响应时长都是跟大模型提示词长度挂钩的，所以需要让我们的提示词工程师，刻意且有效的控制提示词的输入、输出长度。
- 控制提示词输入的长度
提示词的输入长度影响到的是： 大模型的首token延迟。
以火山方舟的doubao-1.5-pro-32k为例：
2000tokens的输入时，首token延迟大约在0.6s-1.8s左右。
20000tokens的输入时，首token延迟大约在2.2s-4s左右。
- 控制提示词输出的长度
提示词的输出长度影响到的是：大模型节点任务完成的时间。
同样以火山方舟的doubao-1.5-pro-32k为例：
输出速度通常是30tokens/s左右，如果我们控制输出的内容在30个tokens以内，那么我们就可以控制这部分的耗时在1s内。
厂商优化
我使用的是火山方舟提供的的上下文缓存（Context API）
先看效果：
| 指标 | 提升比例 | 案例（前 → 后） |
|---|---|---|
| 速度 | +27% | 4秒 → 2.9秒 |
| 费用 | -70% | 10万/年 → 3万/年 |
实测下来，基本上可以做到提升 27% 的响应速度和 减免70% 的费用消耗。
原本我们需要四秒响应，现在只需要不到三秒就可以，70%的费用减免可以从原本的十万每年一下降到三万每年。
上下文缓存（Context API）是火山方舟提供的一个高效的缓存机制，旨在优化生成式AI在不同交互场景下的性能和成本。它通过缓存部分上下文数据，减少重复加载或处理，提高响应速度和一致性。
在方舟中目前存在session 缓存和前缀缓存两种缓存方式：
- session 缓存：保留初始信息，同时自动管理上下文，在动态对话尤其是超长轮次对话场景的可用性更强，搭配模型使用，可以获得高性能和低成本。
- 前缀缓存：保留初始信息，适合静态Prompt模板的反复使用场景。
session缓存和前缀缓存支持的模型不一样,按照我们常用的模型来说：session缓存支持doubao-1.5，前缀缓存支持doubao-1.5和deepseek v3、deepseek r1。
使用这些模型时，可以考虑使用上下文缓存的能力。
AI产品的回复速度上限是多少
AI产品回复速度的优化方案，基本上就是上面这几种。
不过我们既然要优化回复速度，首先就要知道：什么样的回复速度算好？
截止到当前（2025年6月），AI问答系统的用户教育其实已经完成的差不多了。
在用户的心智模型中，这类系统4-6秒的响应延迟已经是完全能够接受了。
但是4-6s是我们的回复速度上限么？
是也不是，这得让我们具体来看一下发生了什么？
我们优化后，一个大模型节点的首包延迟，通常控制在1.5s以内，再加上SSE简历链接，workflow流程中内容或者外部API的调用、查库等等操作。
两个大模节点的workflow通常就要3-4秒才有首包响应了。
所以如果我们的workflow流程中有三个大模型节点，4-6s的回复速度的确是我们的上限了。
但是这里还有一个优化方案，就是利用知识库。
有时候，为了追求回复速度，我会把许多原本是走接口查库请求的内容，到做一份放到知识库中，当然这部分数据要选择时效性不高的内容，否则更新数据会是一个大问题
知识库的查询时间通常是300ms左右，再加上优化过的相关性验证大模型，基本上可以让这部分数据保持2s左右的回复速度。
用户侧优化
我们真正的响应时间无法继续降低之后，我们就要做下一件事：让用户觉得我们比较快。
对于这一点，我们的核心逻辑是：重置用户的等待感。
- 可以使用前端使用延迟。
有研究表示：人类对于等待的感知，通常是要达到300ms之后，才会出现明显的等待感。
所以我们可以利用这300ms，来重置用户的等待感。
表现效果是，用户点击发送按钮后，先发送请求，再体现对话界面的交互动画，整个时长设置不要超过300ms。
这样就给我们争取到了300ms的时间。
- 增强前端用户的等待体验，降低用户的等待感。
对于AI产品来说，尽量不要再用单纯的loading动画了，用户会很无聊的...
可以采用两种方式：
- 有意思的动画
有意思的动画是指：可以转移用户注意力，让用户观察的动画，通常由三帧以上的连贯动画组成。
- 告知用户当前再做什么
把loading动画，换成不断变化的AI工作进度，让用户知道AI当前在干什么，也可以显著降低用户的等待感。
结语
AI产品在落地前，领导对于回复速度的要求基本上每个负责人都会遇到的问题。
特别是拿deepseek这类原生模型进行对比的，大家平常心面对，跟领导逐步交流就好。
目前4-6s的心智模型基本上是成立的，在特殊场景比如生图、生视频，用户的心智模型中等待时间会更长。
这就是AI产品的特性，逐渐会接受的。
我们需要考虑的是，在产品中对回复速度和回复质量做好权衡
要知道在一套workflow中，不同的大模型节点，选择速度还是选择质量都是不统一的。
最简单的例子，我们上线前会做提示词安全的限制，防止提示词泄露一类的。
但是这部分限制我们只需要做到workflow中最后一个输出内容的大模型节点就可以，流程中的其他节点是完全不需要考虑的。
加油，共勉！
☺️你好，我是华洛，如果你对程序员转型AI产品负责人感兴趣，请给我点个赞。
你可以在这里联系我👉www.yuque.com/hualuo-fztn…
已入驻公众号【华洛AI转型纪实】，欢迎大家围观，后续会分享大量最近三年来的经验和踩过的坑。
专栏文章
# 从0到1打造企业级AI售前机器人——实战指南三：RAG工程的超级优化
# 从0到1打造企业级AI售前机器人——实战指南二：RAG工程落地之数据处理篇🧐
