• 基本
  • 难点
  • 目标
  • 基本原则
• 推断框架
  • 框架任务
  • 选择框架
  • TF Serving简介
• 微服务
  • 介绍
  • 为何选择微服务
  • 微服务部署AI的基本原则

---

基本

难点

• 结构复杂，模块繁多（需要清楚每个模块的影响）
• 大量算力，涉及GPU/TPU/FPGA（需要了解不同硬件的特点）
• DL框架依赖十分复杂，配置环境困难（cuda会重新编译整个内核）

目标

• 不要崩
• 不出大的问题
• 保证合适的效率（框架重写、增加算力）
• 尽可能少的入侵

基本原则

• 采用微服务框架（方便：Docker避免入侵；稳定：Kubernetes）
• 采用合适的硬件（CPU和GPU混合）
• 以Profiler为导向进行优化（往往是基础模块而非计算量大的地方）
• 推断服务应该用同一个框架和线程，TPU除外（避免cache miss和显存污染。TPU不存在这个问题）
• 部署是项目初期就要考虑，制定完善的计划，并注重和客户的沟通（预算。避免改变部署方案）

---

推断框架

TensorFlow或PyTorch并非为持续推断而设计的框架，性能有所损失，所以需要其他推断框架。

框架任务

• 读取模型、提供REST接口
• 调用不同的硬件资源
• 对推断过程做一定处理，最重要的是批处理

评价点

• 生态圈
• 易用性（是否能接受其他框架的输入、模型）和文档完整性
• 对不同硬件的支持程度（最好：只通过配置选择）
• 功能是否强大（模型之间的切换、异常捕获、恢复、调整策略）
• 推断速度

TF Serving

• TF Serving支持GPU/CPU/TPU，TensorRT只支持NVIDIA
• 生态圈比TensorFlow好很多，能和PyTorch交互
• 一个Serving提供多个推断

---

微服务

介绍

主要元件：

• Docker - 非常轻量的虚拟机
• Kubernetes - Container Orchestration，容器管理。
  • 自动重启
  • singeleton
  • 负载均衡
  • 路由
• Istio - Sidecar，网络层面的优化。例如：灰度上线时网络的逐步流入

原因

• 入侵性小
• 稳定性高
• 功能强大

基本原则

• 一个节点（计算元件）只部署一个docker（TPU除外）
• Kubernetes必备，因为docker很容易崩溃
• 其他：
  • 错误恢复
  • 灰度上线
  • Kafka（负责计算推断的后端需要batch处理（推断、查库））
  • Actor（轻量级的线程工具，可以应对前端上百万个窗口，类似如Spring Cloud）
  • 其他功能（logging，probe，monitor）