[Performance] Optimize get_seqs
#7051
Conversation
|
👋 Hi! Thank you for contributing to the vLLM project. Once the PR is approved and ready to go, please make sure to run full CI as it is required to merge (or just use auto-merge). To run full CI, you can do one of these:
🚀 |
| @@ -458,25 +459,24 @@ def __init__( | |||
| self.prompt_adapter_request = prompt_adapter_request | |||
| self.encoder_seq = encoder_seq | |||
| self.trace_headers = trace_headers | |||
| self._first_seq = next(iter(self.seqs_dict.values())) | |||
There was a problem hiding this comment.
I think you can still keep self._first_seq = seqs[0] , and use it to replace self.seqs[0]
There was a problem hiding this comment.
I think it doesn't hurt much to use seqs[0] without caching it? _first_seq was introduced to avoid the overhead of retrieving a value from the dictionary. I believe the overhead of seqs[0] will be negligible even if it's Python.
Also, since the sequence can be removed, I feel more comfortable with self.seqs[0] than caching the sequence.
This PR optimizes the overhead of
seq_group.get_seqs(), which was reported by @youkaichao.The solution is simple: We maintain
seqs: List[Sequence]in addition toseqs_dict: Dict[int, Sequence], and useseqsfor allget_seqscalls.This leads to small performance boost (llama3 8B, 1xH100)
Throughput: 23.98 requests/s, 9914.65 tokens/sThroughput: 24.52 requests/s, 10138.92 tokens/s