gaocegege
commented
5 years ago 这篇文章虽然是 short paper，但是非常值得一读。文章介绍了微软内部的深度学习推理服务的大致架构以及少数的细节。
微软的模型服务共分为三个主要的功能： provisioning,routing, and model execution。其中 Model Master 是一个类似调度器的存在，它会调度所有的 Model Servers，确保它们可以运行。Model Servers 有两个作用，一个是路由，MS receives an incoming request from a client and efficiently routes it to another MS hosting an instance of the requested model。还有就是模型服务。
调度
对于调度，MM 是会知道集群的一些信息，比如 CPU 指令集，还有 GPU 相关的信息等等，这些都是为了更好的调度。以及在模型真正部署之前，会先进行 validation test，确保模型的资源需求可以被满足。
同时为了管理异构的集群，微软引入了一个概念，machine configuration model (MCM）。这是个周期运行的程序。 For example, an MCM may run every ten minutes, installing a GPU driver, resetting GPU clock speed, and verifying overall GPU health。老实说没太 get 到必要性，有点像 K8s daemonset。
模型服务
微软支持两种不同的模型，Linux Model 和 Windows Model。不太熟悉微软内部，可能微软有某些 framework 只支持在 Windows 下进行推理吧。Linux Model 是用 Docker Container 进行资源隔离的，Windows Model 是用内部的容器进行隔离的。
微软对三个层面的隔离看的很重：processor affinity, NUMA affinity (when hardware supportsit), and memory restrictions。前者可以使得数据能保持在处理器缓存里，NUMA 可以保证 模型不需要 cross memory banks。内存限制可以保证模型不需要访问硬盘。这里的意思应该是给多内存，保证模型完全在内存里吧。
同时，为了保证 Server 与 Model 之间的通信速度，Linux Model 是用基于 UDP的通信做的，Windows Model 是用共享内存做的，这里介绍非常少。
流量管理
微软说自己的模型会面临爆发的流量，因此流量管理很重要。因为流量的突发性，预测是很困难的，LSTM之类的时序预测对爆发性的流量也不太准确。因此微软的路由器支持 Backup 请求。比如在第一个请求 过去 5ms 后发送第二个备份请求。或者在第一个请求过了 95% 模型延迟后还没有完成，发送第二个备份请求。
但是备份请求还是不能解决问题。比如请求的 SLA 是 15ms，current 95th-percentile model latency 是 10ms，平均的 model latency 是 8ms。系统在 10ms 后发了备份请求，但是预计要过 8ms 才会完成，也就是一共花费了 18ms。同时过早发送备份请求虽然可以解决这个问题，但是会使得服务器压力变大。为了解决这个问题，微软引入了跨服务器的请求取消机制。Jeff Dean 在 12 年提出的一个 Achieving Rapid Response Times in Large Online Services 的解决方案。 In this mode, MS will send backup requests earlier. When a server dequeues the request,it will notify the other server to abandon that request.
https://www.usenix.org/system/files/opml19papers-soifer.pdf
OpML'19