You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Concurrency / thread safety Issue with Python TrT-LLM example 聽#225
However, in out python TensorRT GenerationSession2, it seems like we are using the same ExecutionContext 34 for a single GenerationSession.
This would make calling GenerationSession::decode function in concurrent manner unsafe.
Would there be a new GenerationSession where new ExecutionContext is created for each call to decode?
Please let me know if my understanding is incorrect.
As to your question, currently GenerationSession is not thread-safe and to ensure thread safety, different GenerationSession instances need to be created.
There are several reasons why it is designed in such a way:
Based on our past experience, very limited Python users will use multi-thread for GPU inference, due to the impact of GIL.
There is TensorRT-LLM C++ runtime provided which does support thread-safe inference and it is the currently suggested way for users due to performance consideration.
@juney-nvidia Hi, thanks for your response! I have a couple of questions:
The GenerationSession encapsulates both the trt.ICudaEngine instance and the trt.IExecutionContext instances used for inference. My understanding is that the trt.ICudaEngine instance can be reused across threads, and that thread-safe execution can be accomplished by creating separatetrt.IExecutionContext instances for each thread. Is that correct?
If we create multiple GenerationSession instances, then we would also be loading duplicate trt.ICudaEngine instances, effectively loading the model weights into GPU memory multiple times. If we are using multi-threading for GPU inference in Python, it seems our best bet would be to create a separate ThreadSafeGenerationSession class that decouples the trt.ICudaEngine instance from the trt.IExecutionContext instances so that thetrt.ICudaEngine instance can be reused across multiple instances of said class. Does this approach seem reasonable?
Though, I'd like to understand the usage better here, due to python GIL, I think the multiple threading in python is not real multithread, so what's the benefit here would be? If there is large perf differences here, we can consider to enhance the thread safety here.
Activity
juney-nvidia commentedon Nov 1, 2023
@hchoi-moveworks Hi, thanks for your interest in our work!
As to your question, currently
GenerationSessionis not thread-safe and to ensure thread safety, differentGenerationSessioninstances need to be created.There are several reasons why it is designed in such a way:
Thanks
June
cody-moveworks commentedon Nov 1, 2023
@juney-nvidia Hi, thanks for your response! I have a couple of questions:
GenerationSessionencapsulates both thetrt.ICudaEngineinstance and thetrt.IExecutionContextinstances used for inference. My understanding is that thetrt.ICudaEngineinstance can be reused across threads, and that thread-safe execution can be accomplished by creating separatetrt.IExecutionContextinstances for each thread. Is that correct?GenerationSessioninstances, then we would also be loading duplicatetrt.ICudaEngineinstances, effectively loading the model weights into GPU memory multiple times. If we are using multi-threading for GPU inference in Python, it seems our best bet would be to create a separateThreadSafeGenerationSessionclass that decouples thetrt.ICudaEngineinstance from thetrt.IExecutionContextinstances so that thetrt.ICudaEngineinstance can be reused across multiple instances of said class. Does this approach seem reasonable?litaotju commentedon Nov 3, 2023
@cody-moveworks
Though, I'd like to understand the usage better here, due to python GIL, I think the multiple threading in python is not real multithread, so what's the benefit here would be? If there is large perf differences here, we can consider to enhance the thread safety here.
litaotju commentedon Dec 5, 2023
I am closing this issue, since no update after my last comment. Pls re-open if you disagree. Thanks.