Sarathi-Serve:chunked-prefills

将prefiling阶段的句子,和decoding阶段的句子,混合到一个batch里,为什么能增大throughput?

左图,Prefill阶段,因为是Compute-bound的,计算单元已经打满了,再增大batch也不会增大吞吐量了。

右图,Decode阶段,因为是Memory-bound的(实际是memory-latency-bound),增大batch几乎没有增大延迟,而计算单元远远没打满,因此可以随batch增大而线性增长。

将处于这2个阶段的句子,混合到同一个batch里,好处:

prefill搭上decode的便车,能用上decode阶段被浪费的算力。
decode搭上prefill的便车,合并数据的读取次数,做到1次读取,大家共享。

Chunked-prefills

将prefill阶段的句子,拆分成多个block,每个block包含一部分tokens的计算。

目的:

1. 单卡执行时,降低decode阶段的token的延迟。(如果和整个长句子的prefill阶段样本捆绑,则decode阶段的句子本token延迟显著增大;如果前者切分的短些,则后者延迟可显著减少)。

2. pipeline并行时,可减少气泡。

pp并行的气泡问题:

<think>嗯,用户遇到了API错误400,提示模型的最大上下文长度是65536个令牌,但他的请求用了174916个,明显超过了限制。我需要帮他解决这个问题。首先,我得理解问题所在。用户可能在发送的请求中包含了过长的消息或生成的令牌数设置太高,导致总令牌数超出模型限制。根据引用[2],提到了Dynamic SplitFuse和sarathi的思路,动态分解和融合prompt和生成的token,这可能是一个解决办法。另外,vLLM和Orca的处理方式可能也有参考价值。 接下来,我应该考虑如何减少输入的令牌数量。可能的方法包括文本截断、分块处理,或者使用更高效的编码方式。比如,用户的消息部分有166724个令牌,完成部分8192,显然消息部分太长。需要检查是否有冗余信息,或者是否可以分段处理。引用[2]中的分块处理方法,将长prompt分块多次处理,最后一次融合生成,这样可以避免一次性处理过长的输入。 另外,调整生成参数也是一个方向。比如减少max_tokens的值,或者使用流式生成,分多次请求逐步获取结果。引用[3]提到函数调用能力,可能可以通过转换请求为API调用或SQL查询,减少直接输入的文本量。比如,将问题转换为内部API调用,而不是发送大量文本。 还有,用户可能需要升级到支持更长上下文的模型。引用[4]提到Gemini Pro支持到200万token,但用户当前用的模型限制是65536,可能需要确认是否有更高版本的模型可用。不过用户的问题里没有提到是否可以更换模型,所以可能需要优先处理输入长度。 此外,优化输入内容的结构,比如移除重复内容、使用缩写或更简洁的表达,也能减少令牌数。利用系统消息进行预处理,或者分步骤处理问题,逐步缩小上下文范围。例如,先总结前文再处理后续内容。 最后,动态调整策略,如引用[2]中的动态分解和融合,确保每次处理的token数量在限制内,同时结合流式处理,可能有效解决长上下文的问题。需要综合这些方法,根据具体情况选择最合适的解决方案。</think>针对API请求中模型上下文长度超出限制的问题(错误400),可通过以下方法解决: ### 一、优化输入内容 1. **文本截断与压缩** - 删除重复/冗余信息,保留核心内容 - 使用`tiktoken`库计算token数量:`len(enc.encode(text))`[^1] - 示例代码: ```python from tiktoken import get_encoding enc = get_encoding("cl100k_base") tokens = enc.encode("您的文本") ``` 2. **分块处理** - 将长文本分割为多个小于65536 token的块 - 参考Dynamic SplitFuse方法[^2],对长prompt进行分块处理: $$ \text{总长度} = \sum_{i=1}^{n} \text{chunk}_i + \text{生成token} $$ ### 二、调整生成参数 1. **控制生成长度** - 设置`max_tokens=2048`等合理值 - 使用流式响应逐步获取结果 2. **优化prompt结构** - 使用函数调用转换自然语言请求[^3]: ```python functions=[ { "name": "sql_query", "parameters": {"type": "object", "properties": {"query": {"type": "string"}}} } ] ``` ### 三、技术方案升级 1. **使用长上下文模型** - Gemini Pro支持200万token上下文[^4] - GPT-4 Turbo支持128k上下文 2. **动态调度策略** - 采用vLLM的PagedAttention技术 - 实现prompt处理与token生成的动态平衡
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值