本文主要是为ML inference进行serverless的适配。设计点有以下
- batch处理时的速率讨论
- 基于五元组和distinct operator的性能预测
- 贪心解决带约束多项式的调度NP问题
- 两个不同时间尺度直方图加权来预测pre-warm和keep alive时间
基于openfaas，开源：https://github.com/TankLabTJU/INFless/
background
现有的问题
- High latency：在aws做了实验，小内存跑得很慢，大内存也不快
- Batching在commercial平台上没用
- resource over-provisioning：CPU-Memory的这种配制方法让那些CPU intensive的应用浪费了memory
- one-to-one mapping在ML过程中可能会导致因为bursty的workload起过多的instance
- OTP batching只能够产生有限的提升，因为没有关于batch config- uration, instance scheduling and resource allocation的设计
Design
Workflow
整个工作流程
- 部署函数
- 根据DAG建立performance prediction model
- 为了建立performance prediction model，还需要事先profile operator
- 用户发送请求
- 到达的请求打包成内置的批次，并分配给相应的实例
- 如果工作负载或集群资源状态发生变化，自动扩展引擎会通过从优化的批次-资源决策中挑选出非统一的扩展策略来自适应地调整新的实例配置
- 使用LSTH避免冷启动
built-in, non-uniformed batching
解释：
- built-in：内置在平台内的
- non-uniformed：每个instance有自己的batching queue，batch size和resource quotas都是独立配置的
本节的design点： batch有严格的速率限制，既要不丢包，又要不违反SLO（在队列里等太久）
combined operator profiling
虽然有很多的call，但是distinct operator，因此采用5-tuple based profiling进行预测，并combine不同的operator
- p：输入数据大小
- b：batch size
- c：cpu相关资源配置
- g：gpu相关资源配置
- t：完成时间
scheduling
这是一个带约束多项式的NP问题。最后用贪心去做。
managing cold start with lsth
负载的两个特点：
- 长期周期性(LTP)：请求负载总体上呈现出昼夜交替的用户访问模式
- 短期爆发性(STB)：在短时间内有许多突然变化（包括增加和减少）。
解决方法：
- 维护两个窗口，一个是long-term（1天），一个是short-term（一小时）。
- 5th作为prewarm，99th作为keep alive。
- long-term和short-term加权得到一个值