【问题标题】:How to RAM efficiently load spacy models into fastapi with gunicorn?如何使用 gunicorn 有效地将 spacy 模型加载到 fastapi 中?
【发布时间】:2023-03-13 11:45:01
【问题描述】:

我的 fastapi 服务器在更新为使用小型模型中的 spacy_en_core_web_lg 后内存不足。

在运行 fastapi 时,会产生 4 个 gunicorn 工作人员,并且根据内存使用情况,我认为每个工作人员都在加载模型。有没有办法可以在工作人员之间共享模型,所以我不需要在每个工作人员中加载它?

【问题讨论】:

  • 为模型创建一个单独的线程或其他任何内容,并让每个人都与它交谈。如果这很复杂,请使用模型和一个工作人员设置一个单独的服务器,并让每个人都与之交谈。
  • 是的,我正在考虑为模型配备一个专用服务器——这肯定会让事情变得复杂

标签: gunicorn spacy fastapi


【解决方案1】:

以下内容对我的情况有所帮助。 YMMV,特别是因为我没有直接使用 Spacy,而是 PyTorch。

我在这里写了一篇关于这个主题的长篇文章:http://www.streppone.it/cosimo/blog/2021/08/deploying-large-deep-learning-models-in-production/

总结如下:

  • 使用 gunicorn preload_app = True 选项,让 gunicorn 在工作人员fork()之前加载您的应用程序
  • 在创建 FastAPI 应用程序之前加载模型
  • 如果模型基于 PyTorch,请使用 model.eval()model.share_memory()。在此处查看更多文档:https://pytorch.org/docs/stable/multiprocessing.html
  • 限制工人的数量(您已经在这样做)。三个工人最适合我。四个似乎也合理,这真的取决于你的项目和要求
  • 通过 gunicorn max_requests 限制每个工人的生命周期。就我而言,我注意到一段时间后每个工作人员的内存使用量急剧增加,因此此选项可以抑制这种行为。

我提到的帖子中的更多链接和阅读。我会对有关这些提示的反馈非常感兴趣,因为到目前为止我还没有在网上找到任何好的参考资料。

【讨论】:

  • 使用max_requests 用于泄漏内存的长时间运行的spacy 模型来限制worker 生命周期的好主意!查看 gunicorn 文档,我已将 preload 设置为 true,它已经有所帮助!
  • 太棒了!很高兴我能帮上忙@swartchris8
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2023-03-30
  • 1970-01-01
  • 2018-06-20
相关资源
最近更新 更多