在限定成本和QoS的情况下，找出最优的异构配置，最大化系统吞吐量
先前的工作是利用异构性来提升系统性能，而未在有限成本的下优化异构配置的性能
Kairos解决的问题是在满足QoS约束和成本运算的条件下，快速地找到一个高吞吐量的异构配置，并且智能地将不同批量大小的查询分配到不同的云计算实例上
两点关键的解决方法：
- 查询分配机制：Kairos将该问题转化为二分匹配问题，根据不同的异构配置，将不同批量大小的请求智能地分配到不同的云计算实例上，从而最大化吞吐量。
- 吞吐量估计：为快速找到一个优秀的异构配置，并且不需要在线探索评估其吞吐量，Kairos利用了一个吞吐量上界近似的方法，从搜索空间中筛选出具有高上界的候选配置，然后通过聚合的方式输出一个最终配置
查询分配：
异构配置比同构配置的优点在于在处理不同的批次时，选择一个便宜且刚好能满足小批次处理QoS的实例可能比同构实例更具成本效益，防止性能过剩。
问题：这些批处理是如何形成的？时间间隔？QoS？
当推理请求到达时，中央控制器会估计请求的延迟，并使用其估计的服务器剩余时间来构建??矩阵，用于求解公式4和5，从而得到最优的请求-实例匹配方案。
文中定义了异构实例的异构系数C，设定以一个能满足查询QoS的最低服务延迟时间（性能最强），其系数为1，其余异构实例的服务延迟与其服务时间的比值即为异构系数，C的范围为(0,1]
吞吐量上界估计
一个实例一次只会服务一个查询批处理，没有任何资源竞争，因此认为处理延迟是可预测的
推理延迟与查询批量大小高度相关：延迟和批量大小之间的皮尔逊相关系数在第七节中的所有模型和实例类型上都大于0.99。Kairos用一些查询在线地建模，而不需要任何事先的知识或工具。Kairos从一个线性模型开始，但是它不依赖于模型的准确性，因为它会在处理更多的查询后迅速转变为一个查找表
Kairos做了一个简单的观察，即估计吞吐量上界就像估计在一个不切实际的情况下的最大可能的吞吐量。在这个不切实际的情况下，所有的查询都在一开始就可用，而且我们可以控制每个查询的到达时间，这样就不需要担心队列延迟的影响。
Kairos的查询分配机制能够有效地处理实际的情况，即我们无法控制查询的到达时间：查询可能需要在队列中等待，而实例可能会空闲地等待查询。与实际的情况相比，我们的上界计算方法确保查询不会因为在队列中等待而错过QoS（服务质量），而且实例不会浪费空闲的周期，而本来可以用来处理更多的查询。
作者首先用一个简单的例子来说明如何计算吞吐量上界，即一个基础实例（例如GPU）和一个辅助实例（例如CPU）的异构配置。作者的直觉是确定在一个混合的查询（不同批量大小）中，哪种实例类型是瓶颈，然后由瓶颈实例类型决定我们可以达到的最大可能的吞吐量。
只有两种可能的结果决定了我们可以达到的最大吞吐量：（1）基础实例是瓶颈，（2）辅助实例是瓶颈。
随后通过计算基础实例和辅助实例之间的比值与请求数量大于s的批与小于s批的比值的关系，可以推导得出异构实例的吞吐量上界
Kairos认为上界最高并不意味着吞吐量最高，然后采用了一种基于相似度的方法，首先从前三中检查是否有相同的基准实例数量，如果是，则选择上界最高的配置；反之就对每一个前十的配置，计算它与其他九个配置的平方欧氏距离，然后求和，选择距离和最小的配置。该方法常用于聚类分析。
Kairos会根据历史数据来获取查询请求的分布情况
Kairos+是Kairos的变体，该变体的搜索过程通过上界估计的方法来指导，它在线评估了较少配置，缩小了搜索空间。思路是贪心地从上界最高的配置开始评估，并且如果配置X1可以通过增加实例形成配置X2，那么X1就为子配置，所有的子配置都会被削减
通过一个中央控制器来智能地分配和调度不同大小的推理请求，中央控制器是一个客户端，它通过gRPC协议 [63] 将优化后的推理请求发送给各个计算实例（作为服务器）。与传统的负载均衡器不同，中央控制器能够感知服务器的异构性，并尝试避免QoS的违反。当推理请求到达时，中央控制器会估计请求的延迟，并使用其估计的服务器剩余时间来构建??矩阵，用于求解公式4和5，从而得到最优的请求-实例匹配方案。