就是通过流式提升可感知的响应
Posted: Mon Apr 21, 2025 4:00 am
否则用户会觉得慢 成本：GPU集群并不容易获得且成本高昂。在初期我们甚至不得不为产品测试设定时间表因为测试会消耗太多tokens并阻止开发人员工作。 端到端流式传输：一个完整的答案可能需要几分钟才能完成因此我们让所有请求进行流式传输以减少感知到的延迟。
更重要的是我们实际上在流程内部实现了端到端的流式传输。例如大语言模型LLM的响应会逐步解析出应调用的API并在参数准备好后立即发起API调用而无需等待完整的LLM响应。最终合成的响应也会通过我们的实时消息传递基础设施进行流式传输并对信任/负责任的AI分类等内容进行增量处理直至到达客户端。
注：就是通过流式提升可感知的响应速度非流式会导致你等半天突然所有结果出来了 异步非阻塞管道：由于LLM调用可能需要很长时间来处理我们通过构建一个完全异步非阻塞的管道来优化服务吞吐量该管道不会 奥地利电话号码列表 因I/O阻塞的线程而浪费资源。
这些因素之间有时会产生有趣的相互作用。举个例子我们最初只限制了首个Token响应时间TimeToFirstToken, TTFT因为这对于我们初期产品延迟有直接影响。然而随着我们解决幻觉问题并且思维链Chain of Thought, CoT在我们的提示词中变得突出如果我们忽略了Token间响应时间TimeBetweenTokens, TBT会对我们造成更大的伤害因为任何“推理”token都会增加产品的延迟例如对于一个200个tokens的推理步骤即使是10毫秒的TBT增加也意味着额外的2秒延迟。
这会导致我们公共平台上的某些任务突然发出超时警告我们不得不迅速增加算力以缓解这一问题。 还在死磕的事： 将更简单的任务转移到内部进行并使用微调后的自己的模型进行处理。注：潜在意思是专门化的模型要和通用大模型进行搭配 为大语言模型LLM部署构建更可预测的基础设施。
更重要的是我们实际上在流程内部实现了端到端的流式传输。例如大语言模型LLM的响应会逐步解析出应调用的API并在参数准备好后立即发起API调用而无需等待完整的LLM响应。最终合成的响应也会通过我们的实时消息传递基础设施进行流式传输并对信任/负责任的AI分类等内容进行增量处理直至到达客户端。
注：就是通过流式提升可感知的响应速度非流式会导致你等半天突然所有结果出来了 异步非阻塞管道：由于LLM调用可能需要很长时间来处理我们通过构建一个完全异步非阻塞的管道来优化服务吞吐量该管道不会 奥地利电话号码列表 因I/O阻塞的线程而浪费资源。
这些因素之间有时会产生有趣的相互作用。举个例子我们最初只限制了首个Token响应时间TimeToFirstToken, TTFT因为这对于我们初期产品延迟有直接影响。然而随着我们解决幻觉问题并且思维链Chain of Thought, CoT在我们的提示词中变得突出如果我们忽略了Token间响应时间TimeBetweenTokens, TBT会对我们造成更大的伤害因为任何“推理”token都会增加产品的延迟例如对于一个200个tokens的推理步骤即使是10毫秒的TBT增加也意味着额外的2秒延迟。
这会导致我们公共平台上的某些任务突然发出超时警告我们不得不迅速增加算力以缓解这一问题。 还在死磕的事： 将更简单的任务转移到内部进行并使用微调后的自己的模型进行处理。注：潜在意思是专门化的模型要和通用大模型进行搭配 为大语言模型LLM部署构建更可预测的基础设施。