仅用于站内搜索，没有排版格式，具体信息请跳转上方微信公众号内链接
QWen3-32B推理上下文，一般是配置为8K、16K、32K，但是通过YaRN技术，将rope外推至128K的上下文，虽然说是对性能有一定的损耗，但效果还是不错的。
以vllm-ascend作为推理引擎，以如下参数为例，支持tool-call、128k的长文本：
官方的文档提到：如果平均上下文长度不超过32,768个token，我们不建议在这种情况下启用YaRN，因为它可能会潜在地降低模型性能。
看了下vllm日志，这里的性能应该就是在吞吐量了，如下：
图一是，不启用rope外推技术，直接启动vllm的日志输出，可以看到最关键的是在blocks的分配数与request的请求处理并发数。
从逻辑上来说，的确是这样的，短文本的请求，并发会更大；长文本的请求，并发会差一点。因此如果有长文本的需求，需要酌情的处理rope外推。
当然如果有足够的显存资源，这个是不用考虑的。但如果有长文本需求，而不需要外推到128K，只需要到96K这样子，也是可以的。
官方文档的描述：
Qwen3本身支持长达32,768个tokens的上下文长度。对于总长度（包括输入和输出）远超此限制的对话，我们建议使用RoPE扩展技术来有效处理长文本。我们已经通过YaRN方法验证了模型在高达131,072个tokens的上下文长度上的性能。
当然这是从日志的角度来看，而从另外的显存占用来看，也是有另外的发现。
图一是默认启动后的显存占用，图二是rope外推后的显存占用。
从显存来看，开了长文本的显存占用竟然更低，可能是为了后续的request预留空间的，毕竟vllm内部会根据上下文长度计算blocks的预留空间大小。而请求的过程中，会缓存kvcache，对于长文本内容可能会缓存更多的kvcache，而输出的内容也会更多更长，因此需要尽量的减少启动后的现存占用。
当然如上是我自己根据实际的情况下的推测，具体的还是要看代码。
官方说明：https ://www. modelscope.cn/models/Qwen/Qwen3-32B/summary
