用了很多分布式系统的思想。 在线更新推荐推理系统，优化了P2P的通信，而且考虑了模型更新的优先级和差模型对SLO的影响。 差模型的影响通过一个 inference model state manager 监控，它有一个几分钟前的baseline模型，它会接收部分的用户流量作为ground truth去评估现在的模型。 对模型的parameter分片传输，达到最终一致性，作者认为一个模型的不同参数版本不一致，对推理结果影响不大，只要最终一致就可以；用version vectors去做replica之间的P2P同步，物理时间+id作为一个parameter的version number。 用一个Dominator Version Vector去维护cache，保证大于Dominator Version Vector的版本都在cache里面，删除过期cache会更新Dominator Version Vector的计数 (merge)。 如果Version Vector比Dominator Version Vector大说明所有东西都在缓存中。 Shard Version是和replica绑定的，Shard Version少很多，是为了减少Version Vector做的二级数据结构；Shard Version大，Version Vector肯定大。 update priorities考虑的因素是freshness，gradient magnitude和request rates的多项式。 为每一个模型准备一个baseline模型，是几分钟前的模型参数，用于监控模型更新有没有变坏。 witness servers用于记录update，但是不会即时flush也没有update priorities，当infernece server需要rollback的时候才flush。

Kai Chen老师组和Xin Jin老师的工作，中了infocom21，然后扩刊TCC22。 感觉超分辨率比较适用于改善人眼观看的视频质量，不太适用于改善video analytics，很容易导致超分辨率重建的单帧比原来还模糊。 在训练超分辨率模型的时候把video analytics的模型接上，多算一个loss，这个loss还需要是特挑的small regions类的目标（比如只选单车之类的小物体，天空建筑这种就不选），但如果video analytics有多个或者一直在变怎么办？对这个领域不是很了解，感觉idea有点太简单了吧。 关于怎么确定frame-wise tail也很简单，就是看small regions占的比例有没有1%，如果没有就会产生很多误判，就属于tail frame，然而在实验结果中作用并不大。

workload白天和晚上不一样，不同的日子也不一样（例如双十一） 因为没有办法对workload估计得很准，云系统用户总是申请比所需要的多的资源，这些“slack”是一种浪费 Autopilot目标：减少slack的同时最小化OOM Autopilot操作：调整并行任务数，调整单个任务的资源使用量 scaling分为水平scaling和垂直scaling，水平scaling是调整并行任务数，垂直scaling是调整单个任务的资源使用量，这篇文章主要讨论内存的垂直scaling Preprocessing: 每秒记录一个usage数据点； CPU per-task histogram: 一个向量，每个分量表示在这个time window内每个usage buckets的usage数据点数量； memory per-task histogram: peak memory usage in a time window； per-job histogram: sum over per-task histogram； Moving window recommenders 希望需求上升时能很快上升，需求下降时能慢慢下降 提出了三种滑动窗口的方法，都比较保守，而且会在推荐值的基础上加一点余量 大概的思想是，不只根据数量去做平均，还要根据load的大小 (magnitude) 去做平均 max适合OOM最敏感的任务，Spj适合比较敏感的任务，Savg适合不敏感的任务 Recommenders based on machine learning 构造了一个损失函数包括过去采样的overrun，underrun，以及switching cost。 同时存在多个arg min的模型，它们的超参不一样，用的时候选择损失函数最小的。 这些模型是离线+A/B test调出来的，没有给具体方法，只有loss function。 horizontal 指定一个目标平均util，通过伸缩replica来维持这个值。 策略 实验结果是滑动窗口在减少OOM上更好，ML方法在减少slack上更好。 后面主要是讨论用户体验。 有一篇值得follow的工作：Hydra: a federated resource manager for data-center scale analytics，是微软的资源管理系统，在这篇论文之前。

通过一系列的检查，分析和验证，将不同厂商的SDN设备的配置说明转成一个Vendor-specific Device Model；然后用BERT，将不同厂商的SDN设备的Vendor-specific Device Model转成一个unified device model。 其中使用到的NLP技术是用BERT做一个SDN配置的语义匹配模型的任务，将Vendor-specific Device Model与unified device model的terms做匹配，如果人工检查觉得某些匹配不对，还可以提供其他的可能选项。

这是hkust Kai Chen老师组和北大Xin Jin老师的工作。如果把RL用在拥塞控制里，现有的做法是把算法的优化目标，比如吞吐率，延迟，丢包等作为reward。不同目标对应的权重是预先设置好的，但不同的应用会有不同的目标。这篇论文用了一个多目标的RL算法，除了网络状态之外，把reward的权重也作为RL的状态输入，期待网络能学到根据当前reward权重来选择对现在来说更好的action。reward的权重会随环境变化，计算reward的时候就用当前的权重。用的RL算法是PPO再加了一个entropy项的连续算法，预测下个时间发送速率的变化值。 感觉这个MORL是挺靠谱的，如果实际上训练时候的reward weight pattern不会太影响实际场景的预测的话。拥塞控制对机器资源的要求也没有做资源调度的多，只要有网络就可以在线训练。 离线训练先选几个点训练到收敛，然后找到一条最短路径，以此选择路径上的点对应的权重训练，每个点上的训练不必训练到收敛才去下一个点，而是一直遍历训练直到所有点都收敛。

分布式机器学习的梯度同步的通讯调度，先做前向传播的参数考虑先同步。 一个有限制的preemption。 用Bayesian Optimization去搜超参。