SkyPilot: An Intercloud Broker for Sky Computing 论文阅读 | return 0;

[HeRaNO]

https://herano.github.io/2023/05/15/SkyPilot-An-Intercloud-Broker-for-Sky-Computing-%E8%AE%BA%E6%96%87%E9%98%85%E8%AF%BB/

我就说 Sky Computing 怎么没在 Skyplane 上写，原来搁这儿呢。

[AL-Cui]

博客写的不错。有几点问题想探讨下： 1、skyPilot这个东西搞了这么久了，是不是因为找了几个典型用户所以才发了论文来说自己多牛逼 2、skyPilot这个项目是不是没有太多技术含量。收集各云提供的实例信息，协助用户购买用Ray集群去跑。Skypilot不感知容量信息，是否推荐的方案经常买不到 3、算力网要不要考虑算力发布？如果买了算力不是用来运行批处理业务，那算力网能做啥

[HeRaNO]

博客写的不错。有几点问题想探讨下： 1、skyPilot这个东西搞了这么久了，是不是因为找了几个典型用户所以才发了论文来说自己多牛逼 2、skyPilot这个项目是不是没有太多技术含量。收集各云提供的实例信息，协助用户购买用Ray集群去跑。Skypilot不感知容量信息，是否推荐的方案经常买不到 3、算力网要不要考虑算力发布？如果买了算力不是用来运行批处理业务，那算力网能做啥

关于 Skypilot 整体，我其实不是很确定这个模式会不会十分有效，也就是云服务商会不会愿意参与。因为 Sky Computing 确实会分云厂商的蛋糕，在目前相对大厂垄断的现状来说，厂商进行一些 QoS 策略调整，提供一些改进的 SLA 可能就可以让租户放心了。云企业用户担心的 vendor lock-in，区域合规等等问题都存在一些不需要 Sky Computing 的方案来解决，采用 Sky Computing 是否有足够的动力是我在考虑的。当然，对于算力网来说采用 Sky Computing 我认为更倾向于采用这种思想，毕竟不算商业，是政府推进的算力基础设施项目，其中一些对商业化的妥协完全可以通过强制力进行。

对于第一个问题，是的，据我所知目前还是个实验室产品，并不是（那种有公司运营，目前已有收益的）商业化产品。

对于第二个问题的前半段，网络测量和配置规划这里在我看来确实是没啥技术含量，因为我不懂网络测量，配置规划也只是一个简单的 01 规划转线性规划模型，并且直接调求解器就可解了，没有什么新算法。从文章的表述来看网络带宽测量还是比较简单的，毕竟只需要定期 iperf 一下就好了，但是实际是不是应该考虑更多一些事情就不太清楚了。

第二个问题后一半和第三个问题的云实例信息，算力发布这一点是比较重要的，文章中的云实例信息好像是直接从云厂商 API 爬取的，虽然更新时间粒度可能比较粗，但是根据云厂商的调度和云厂商总会超售的特点，出现买不到某个配置的实例的情况感觉还是有点难度，经常买不到应该不会发生。当然这个是云服务的情况，算力网内部确实应当做算力发布并做统一规划调度的，我个人觉得可以理解成算力在计划和市场两种因素下的不同配置方式。

[AL-Cui]

@HeRaNO

博客写的不错。有几点问题想探讨下： 1、skyPilot这个东西搞了这么久了，是不是因为找了几个典型用户所以才发了论文来说自己多牛逼 2、skyPilot这个项目是不是没有太多技术含量。收集各云提供的实例信息，协助用户购买用Ray集群去跑。Skypilot不感知容量信息，是否推荐的方案经常买不到 3、算力网要不要考虑算力发布？如果买了算力不是用来运行批处理业务，那算力网能做啥

关于 Skypilot 整体，我其实不是很确定这个模式会不会十分有效，也就是云服务商会不会愿意参与。因为 Sky Computing 确实会分云厂商的蛋糕，在目前相对大厂垄断的现状来说，厂商进行一些 QoS 策略调整，提供一些改进的 SLA 可能就可以让租户放心了。云企业用户担心的 vendor lock-in，区域合规等等问题都存在一些不需要 Sky Computing 的方案来解决，采用 Sky Computing 是否有足够的动力是我在考虑的。当然，对于算力网来说采用 Sky Computing 我认为更倾向于采用这种思想，毕竟不算商业，是政府推进的算力基础设施项目，其中一些对商业化的妥协完全可以通过强制力进行。

对于第一个问题，是的，据我所知目前还是个实验室产品，并不是（那种有公司运营，目前已有收益的）商业化产品。

对于第二个问题的前半段，网络测量和配置规划这里在我看来确实是没啥技术含量，因为我不懂网络测量，配置规划也只是一个简单的 01 规划转线性规划模型，并且直接调求解器就可解了，没有什么新算法。从文章的表述来看网络带宽测量还是比较简单的，毕竟只需要定期 iperf 一下就好了，但是实际是不是应该考虑更多一些事情就不太清楚了。

第二个问题后一半和第三个问题的云实例信息，算力发布这一点是比较重要的，文章中的云实例信息好像是直接从云厂商 API 爬取的，虽然更新时间粒度可能比较粗，但是根据云厂商的调度和云厂商总会超售的特点，出现买不到某个配置的实例的情况感觉还是有点难度，经常买不到应该不会发生。当然这个是云服务的情况，算力网内部确实应当做算力发布并做统一规划调度的，我个人觉得可以理解成算力在计划和市场两种因素下的不同配置方式。

受教了，老哥在这个方向理解还是精辟。以后多交流，读论文的博客常更新哈，看了几篇都不错，那篇severless深有同感。很多论文感觉都是在强行在serverless上做研究，很多使用场景其实不适用serverless。在解决冷启动，serverless容器重复利用上倒是不错的角度