我使用了Ctranslate2-量化版的fastchat-t5(https://huggingface.co/limcheekin/fastchat-t5-3b-ct2)作为问答系统的语言模型。问答系统被封装在REST API中。这个模型运行得非常好。但我注意到的一个问题是,随着时间(请求)的推移,GPU内存占用增加,最终导致OOM错误。
在我的情况下,我设置了max_batch_size=1, max_input_size=2048, max_decoding_size=1024。GPU是L4,拥有24GB RAM(对于只加载一次就占用3GB的模型来说,应该足够了)。
我在考虑以下解决方案。你能提供一些建议吗?
将LLM与QA系统分开,为LLM启动一个REST API,并在QA系统中调用API端点。这是因为我注意到许多托管服务(如vLLM)声称在处理吞吐量方面表现更好。CTranslate2模型是否会从这样做中受益?
我在OpenNMT-py RESTAPI服务器中注意到,模型是根据定时器卸载到CPU并重新加载的。当我尝试时,卸载和加载需要几秒钟的时间。每隔几个请求这样做似乎效率不高。
谢谢。
5条答案
按热度按时间v1uwarro1#
Load and unload per request. If you are using FastAPI, you can use BackgroundTask to do this efficiently.
a7qyws3x2#
每次请求加载和卸载。
这不会增加巨大的延迟吗?
0sgqnhkj3#
这不会增加巨大的延迟吗?
BackgroundTask
是无阻塞的,所以如果每个请求都足够地分散开,应该没有明显的延迟。可能需要在生成之前添加一个检查,以检查模型是否已加载。这个问题可能与某个草稿PR有关,正在进行实施。在等待那个的时候,这可以是一个临时解决方案。哦,当然你也可以在每几个请求之间这样做。
yx2lnoni4#
这是一个很大的"如果"...
显然存在内存泄漏,无论是在CTranslate2中还是更有可能在OP的应用代码中。
ktca8awb5#
可能有关联。SYSTRAN/faster-whisper#660