CTranslate2 内存增加

5t7ly7z5 于 2个月前发布在其他

关注(0)|答案(5)|浏览(44)

我使用了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并重新加载的。当我尝试时，卸载和加载需要几秒钟的时间。每隔几个请求这样做似乎效率不高。

谢谢。

CTranslate2

来源：https://github.com/OpenNMT/CTranslate2/issues/1488

5条答案

按热度按时间

v1uwarro1#

Load and unload per request. If you are using FastAPI, you can use BackgroundTask to do this efficiently.

def reload():
    model.unload()
    model.load()

@router.post('/query')
def query(...):
    result = model.generate(...)
    BackgroundTask.add_task(reload)
    return result

赞(0）回复(0）举报 2个月前

a7qyws3x2#

每次请求加载和卸载。
这不会增加巨大的延迟吗？

赞(0）回复(0）举报 2个月前

0sgqnhkj3#

这不会增加巨大的延迟吗？
BackgroundTask 是无阻塞的，所以如果每个请求都足够地分散开，应该没有明显的延迟。可能需要在生成之前添加一个检查，以检查模型是否已加载。这个问题可能与某个草稿PR有关，正在进行实施。在等待那个的时候，这可以是一个临时解决方案。
哦，当然你也可以在每几个请求之间这样做。

赞(0）回复(0）举报 2个月前

yx2lnoni4#

这是一个很大的"如果"...
显然存在内存泄漏，无论是在CTranslate2中还是更有可能在OP的应用代码中。

赞(0）回复(0）举报 2个月前

ktca8awb5#

可能有关联。SYSTRAN/faster-whisper#660

赞(0）回复(0）举报 2个月前