A Case for Managed and Model-less Inference Serving

[gaocegege]

https://dl.acm.org/citation.cfm?id=3321443&dl=ACM&coll=DL

HotOS'19 From @wydwww in #152

[gaocegege]

https://blog.acolyer.org/2019/06/14/a-case-for-managed-and-model-less-inference-serving/

毕业后暂时还不知道如何下载 ACM 论文，惨

[gaocegege]

这篇文章是对 #152 的 motivation 的一个更加细致的解释，我个人觉得比 #152 更值得一读。因为它罗列了一些 challenge 和观察，而 #152 是提出了一个 solution。#152 中的 solution 其实非常直接，就是瞄准这篇里的问题提的。但实际上应该我们可以想到更合适工业界落地的解决方案。所以不管怎么样，问题还是提的很好的。

问题一共是有这些，首先就是因为缺乏一个 One for All 的模型，导致不同优化下的模型适用于不同场景。

这使得用户在用的时候，会涉及优化方案的选择。 #152 提出的解决方案更像是用户把优化方案的 meta data 告诉系统，系统根据额外的这些信息去做 variant 选择。但是真正落地的话，其实最难的问题是如何获得这些优化方案 的吞吐量和 latency 这些 meta data。所以 #152 那篇论文并没有真正地解决这个问题，只是在假设最难的问题被解决了以后提出了一个自动选择的策略。

第二个问题，Heterogeneous hardware architectures。

这个问题，在作者分析下来，得到这样一个期望：The choice of hardware should be hidden behind the same high level API for users. The system should select the right hardware type(s) to use at any point in time for meeting performance and cost SLOs.

这个期望有点太高了，个人觉得不现实。起码当下，非常不现实。这个问题不仅要考虑 SLA，还要考虑资源的利用率。但是能做到这样的话，很 promising。

第三个问题，是 query pattern 的不同导致资源需求的多样性。比如推荐系统和 CV 领域的模型的推理就对资源有不同的需求。作者提到了一些期望的方式来提高资源利用率，比如共享一个硬件。这个 TensorRT Inference Server 做的还不错了。还有多用户共享一个模型，这个个人觉得根本不可能。公共的模型不可能真正拿来用，用户用自己数据训练的模型，不可能想共享给其他用户使用。第三个根据使用率去做 auto scale 这个现在工业界已经可以做到了。

第四个问题是关于 Start-up latency 的。作者认为在启动时候的 latency 来自两个方面，一个是把模型 load 到硬件的内存里（内存，显存）；一个是做模型的优化构建。这个按道理应该是在 inference 之前就做好的，online 去做 optimization 不现实。作者提出的期望是，服务提供商不需要一直运行推理实例，不敢苟同。这个之前有一些厂商在 dockerized web 服务上做过。没启动时候的 latency 接受不了。以及还有一个很大的坑，就是 model download 的策略也有很大影响。如果在运行的时候 model 不在了，那下载下来再 serve，latency 会爆炸。

[xplorld]

share model 的话，也可以是一个客户同时跑好几个 inference of different input 不？

[gaocegege]

那就不是 user 间 share 了，是客户自己的策略了

[wydwww]

优化方案 (variant) 的 metadata 看起来是来自 generate variant 时候的 profile, 在用户 register model 时提供的 validationSet 上。这样得到的 meta data 在实际用会有什么问题吗？