笔记-Lecture 05: Deployment

Only IRL do you see how your model actually works.

只有在真实环境中，你才能真正看到你的模型是如何运行的。

• 早部署，常部署
• 先保持简单，再加复杂。
  • 构建原型(prototype)
  • 分离 模型 与 UI
  • 学习 scale 的技巧
  • 当你”真的”需要 go fast 时，考虑将你的模型移动到边缘。

Step 1: 构建一个你和你的朋友能够交互的原型

Prototype deployment: bes practices

• 先有一个基础的UI
  • 要便于其他用户去尝试和给予反馈
  • Gradio & Streamlit are you friend have.
• 给你的后端一个web URL
  • 便于分享
  • Streamlit 和 huggingface 的云端版本在此处很有用。
• Dont stress too much.

这个过程中，哪里会出现失败？

• 受限的前端灵活度
• 无法扩展到太多的并发请求

模型成为瓶颈。

Model-in-service

• 优点：可复用已有的infra
• 缺点：
  1. Web server 可能是另一种语言编写的。
  2. 模型可能比服务器代码更频繁地改动。
  3. 大模型将会吞掉web server的资源。
  4. 服务器硬件可能不会为你的模型做优化（e.g. no GPUs)
  5. 模型 & 服务器可能扩展方式不同

Step2: 分离你的模型和 UI

选项 1：批次（Batch）预测

• 周期性地让你的模型在新数据上运行并将结果保存到数据库。
• 如果输入的范围相对较小，这种方法是有效的
  • 推荐系统
  • 市场(Market)自动化

数据处理/工作流 工具在此处将很好地工作

• 重运行预处理
• 加载模型
• 运行预测
• 保存预测结果
• 优点：
  1. 便于实现
  2. 易于扩展
  3. 在大规模生产系统中长期使用
  4. 能快速地检索预测结果
• 缺点：
  1. 不能扩展到复杂的输入类型
  2. 用户无法获取最 up-to-date 的预测结果
  3. 模型会变得"过时"或"陈旧"，而且这种情况很难被发现

选项2：Model-as-service

• 让你的模型在它自己的web server上运行
• 后端（或客户端本身）通过向模型服务器发送请求和接受响应的方式与模型交互
• 优点：
  1. 独立性：模型的 bugs 不太可能使 web app 崩溃
  2. 可扩展性：可以为模型选择最优硬件以及恰当地进行扩展
  3. 灵活性：易于在多个 apps 间复用模型
• 缺点：
  1. 会增加延迟
  2. 增加基础设施的复杂性
  3. 你必须运行一个 model service

Sweet spot for most ML-powered products!

构建 model service: the basics

• REST APIs
• 依赖管理
• 性能优化
• 水平（横向）扩展
• 发布/上线
• 托管服务选项