Serverless GPU (弹性 GPU 服务)的前世今生
当Serverless GPU 不使用时，它会关闭。这意味着第一次使用它时，它需要启动，这可能需要几秒钟到几分钟，具体取决于模型大小。如果您正在运行实时应用，这可能是一个问题。在云数据中心内，用户需要部署各种各样的大模型推理服务，占用海量GPU资源。为了减少GPU资源的使用，许多云服务提供商正在探索使用服务器无感知计算的范式来运行大模型推理服务。此时，当针对一种模型的请求到来时，系统才会为该模型分配资源并加载到对应GPU上，以此来提高资源利用率。然而，由于预训练的大模型往往具有GB至TB量级的大小，所以加载模型的过程会消耗相当长的时间，导致推理服务无法真正部署。使用预留实例的方案可以解决此问题，但是预留实例会消耗大量GPU资源，失去服务器无感知计算的优势。另一种将模型缓存在内存里的解决方案只适用于小模型，因为以大模型的规模，它们往往无法被全部放入内存。
定义 Serverless
大家对于 Function as a Service 函数即服务应该都比较熟悉，例如腾讯的 SCF，Azure Functions 和 AWS Lambda 等等，这些服务中，你可以将一段代码（通常是无状态的应用代码）上传到云端，之后基于 API 调用或者配置触发器等方式，随时在云端执行你上传的代码。很棒的一点是，FaaS 服务是按需付费的，根据执行时间和调用次数计费。
那么对于 Backend as a Service 后端即服务，相信大家也都听说过，但并不了解 BaaS 的准确含义。其中的一个重要原因是，BaaS 这个词对于不同的人来说含义也不同，对我们来说，BaaS 是和 FaaS 相对应的概念，其中“即服务”指的是不以“服务器”的方式来提供服务。例如腾讯云的 COS 对象存储服务，AWS DynamoDB 等，都算做是后端即服务。
从定义可以看出，FaaS 和 BaaS 的特点相互呼应和紧密结合，例如 FaaS 是无状态的，而 BaaS 是有状态的；FaaS 基本上可以支持所有运行时的代码，而 BaaS 对编程模型的限制更严格，或者几乎不涉及编程模型，例如对象存储服务。但可以看到，双方的相同点在于弹性伸缩和按需付费。
可以认为 Serverless Computing 是一种用云的简化方式。我们可以用下面这张图来说明。从最底下开始，在最底层你需要硬件，要有 CPU，网络，存储，和一些加速器（如 GPU 或者机器学习的加速器），在这之上云通过虚拟化技术提供了抽象层，硬件服务器被分隔成了多个互相隔离的虚拟机/虚拟私有网络，这一层的服务形态和底层架构是类似的，对于应用层面来说使用起来也有一些复杂，所以出现了 Serverless 的概念，在这一层中 Serverless 化的服务让调用基础设施变得更加简单。
接下来我们可以看下，为什么说传统的服务器托管比较复杂呢？主要是因为有太多方面需要考虑，即使对于一个简单的应用而言，你也要考虑下面这些方面：可用性，多地域部署，扩缩容，监控告警和排障，系统升级和安全漏洞，迁移策略等等。
有个非常经典的案例可以说明传统和 Serverless 架构的区别。在这个例子中，希望实现非常简单的功能：上传图片，对图片做压缩后，提取并存储图片的点赞和路径等信息到数据库等。如果你要用服务器来做，则需要非常长的处理和搭建流程；但是如果用 Serverless 架构来做，则只需要负责 FaaS 的代码处理逻辑即可。但是这里要强调的是，该应用的实现不只需要 FaaS 的处理，也同样需要 BaaS 服务的配合，才能实现完整的 Serverless 架构。
总结起来，在 UC Berkeley 我们认为 Serverless 需要满足下面三个关键特性：
- 隐藏了服务器的概念。虽然服务器依然存在，但开发者不感知，也无需针对服务器进行繁琐开发和运维操作
- 提供了一种按需付费的计费模型，并且在资源空闲时不收费
- 提供极致的弹性伸缩能力，从而让资源的提供完美适配业务需求
如果举例说明，可以将传统服务器和 Serverless 用租车和打车来做对比。（不展开）
云计算的进化历程可以从资源的分配和收费模型中看出，在传统的硬件时代，需要预分配物理资源来承载业务；而在服务器时代，则需要通过粒度较粗的服务器实例来进行扩缩容和计费，用于承载业务；在 Serverless 时代，才能真正做到极致弹性和按需付费。
因此，在 Berkeley 我们认为 Serverless 是云计算的下一个阶段，不仅因为弹性伸缩和按需付费的特点，还有个重要原因是，我们认为 Serverless 改变了人和电脑协作的方式。
在云计算的第一阶段，极大的简化了系统管理员的职责，人们可以通过 API 的方式获得服务器，无需自建机房。这种获取资源的方式十分简单，开发者都可以轻易的实现资源的购买和配置。而在这一阶段，云服务商则负责管理并保证这些资源的稳定性。
在云计算的第二阶段，在运维/管理员之外，进一步简化了开发者的职责。开发者不需要关心复杂的资源分配/运维逻辑，只需要写好原生业务逻辑，上传到云端后就可以执行，无需担心扩缩容的问题。而云服务商则承担了系统管理员和资源管理的角色。在这阶段，云计算对开发者编程模式的改变，就好像十年前的第一阶段中，云计算对系统管理员的职责转变一样，是十分重大的转折。这一转变也极大的激励了开发者，拓展了他们的能力边界，开发者可以专注于业务实现，无需担心底层资源的运维。
Serverless 研究成果和亮点
在第二部分，我想分享一些 Berkeley 最近的研究成果。我们发现，Serverless 中 FaaS 部分很难解决所有问题，因为函数即服务从平台层面有诸多限制：
首先是运行时间的限制，当前各云平台对于 FaaS 的运行时间都有 10-15分钟的限制，这种限制影响了许多场景的实现，尤其是一些强状态依赖的场景，例如长时间保持数据库连接的情况等。
此外，FaaS 平台只能支持短暂的有状态性（Ephemeral State），没有磁盘可以存储或者永久保存状态信息。
第三点，当前不能直接和函数服务进行网络通信，函数即服务可以提供外访能力，但对于入流量的支持不够友好，例如在你开发的应用中，获取到函数中的一些数据会比较困难，从而可能会影响软件原本的开发方式，需要做额外的适配。
最后一个限制是在硬件层面的，例如一个机器学习方面的应用利用了 GPU 硬件，在当前的 Serverless 计算层面是难以提供 Serverless GPU 计算资源的。
当新的技术趋势出现时，学术界往往非常活跃，从近几年的对 Serverless 方向研究的论文数就可以看出。如下图所示，最近几年来，Serverless 方向的论文数每年都在翻倍增长，在 2020 年，已发表+计划发表的论文将继续翻倍，达到近 300 篇。
在分享一些具体研究成果之前，我想先简单介绍下几种不同的 Serverless 研究方向：
- 具体应用的抽象：选取一个场景，将其 Serverless 化，不会做太多通用层面的抽象。例如针对大数据检索并生成报表等，只要用 Serverless 解决该场景下的问题即可。
- 通用的抽象：我认为这个层面的研究最有意思，并且自己也在做这方面的研究。即通过满足一些条件，即可让任意业务适配 Serverless 架构。本质上说，这就涉及到怎样针对分布式系统进行开发模式的简化。
- 实现层面：当函数即服务刚推出的时候，在效率等方面有很多待提升的地方。目前虽然已经有一些改善，但从学术层面依然有非常多可深入优化的地方，例如 FaaS 平台将不断追求更低的延迟，更好地状态共享，租户隔离，极致的弹性扩展等方面。
接下来我将分享 Berkeley 近期在以下五个方面的研究成果，分别是 Serverless 机器学习，以及用于支持机器学习的 GPU 相关的内核即服务，之后会分享状态性相关的云函数文件系统和 Starburst，最后会通过展望 Serverless 数据中心来收尾。
第一个是机器学习方面的研究，当前其实在云端已经提供了应用层面的 Serverless 机器学习服务，例如 AWS 的 Sagemaker 服务，用户只要输入数据，设置好模型，Sagemaker 就会帮忙做训练，并按照模型的训练时间来计费。但这个服务仅是针对机器学习这个特定场景的，并不具备普适性，此外，对于模型有定制化需求，或者训练步骤有改动场景（例如 Berkeley 的一些新的训练算法），这个服务并不能完全满足需求。
那么是否可以推出更加通用的机器学习解决方案呢？例如把数据或者代码作为函数的输入，并将其运行在 AWS Lambda 函数服务及 Cirrus 上进行机器学习训练。因此团队开发了 Cirrus 的机器学习库，可以让用户方便的在 Lambda 上端到端地进行机器学习训练，满足定制化需求。
Cirrus 团队在 FaaS 平台上做了很多尝试，也遇到了非常多平台的限制，例如内存过小，上传的代码包大小有限制，不支持 P2P (peer to peer) 点对点传输，没有快速的存储介质，实例的生命周期有限，会被回收和重启等。
但是根据右边的实验结果可以看出，在越短的执行时间内，Cirrus 的性能表现越好，甚至优于其他几种机器学习技术。因此你可以根据自己的训练模型和需求选择要不要使用 Cirrus 作为 Serverless 机器学习的训练方案。
参考文献：
- ucbrise/cirrus
- [Cirrus: a Serverless Framework for End-to-end ML Workflows]https://people.eecs.berkeley.edu/~joao/p13-Carreira.pdf)
第二个研究课题是关于机器学习作为容器即服务 (Kernel as a Service) 的。大家都知道当前 FaaS 主要运行在 CPU 的硬件上，而在机器学习领域，GPU 针对许多算法和工作流提供了非常重要的加速作用。因此 Berkeley 团队希望提供一种方案，将 GPU 和 Serverless 计算更好地结合在一起。
由于成本/价格原因，目前商业化的云函数服务不提供 GPU 函数。因为 GPU 服务器价格高昂，需要针对机器利用率做进一步优化后才能真正进行商业化使用。因此，我们提出了 KaaS 容器即服务的概念，和 FaaS 的 Node.js 和 Python 等运行时一样，只不过 KaaS 中运行时支持的是面向 GPU 的语言如 CUDA 或 OpenCL。但当前研究的挑战在于，是否可以完全通过纯GPU 语言来编写 KaaS 服务，完全摆脱对 CPU 代码的依赖呢？
下图可以进一步解释这个理念，一种方式是在函数平台中同时提供 CPU 和 GPU 的支持，即每个函数的底层架构中既有 CPU、内存卡，也有 GPU 加速器。
但是有挑战的地方在于，是否可以像下图一样，提供一个 GPU-only 的纯 GPU 底层来运行函数呢？这样可以彻底区分 CPU/内存型函数和 GPU 型函数，由于当前从通讯模式上还比较难将 CPU 和 GPU 从硬件上彻底分开，这将是研究中比较大的一个挑战。
参考文献：PyPlover: A System for GPU-enabled Serverless Instances
第三个研究课题主要是 Serverless 文件系统 —— 状态性方面的优化，也是非常有价值的一个方向。
下面的图可以解释当前 Serverless 计算的状态共享/存储模式。当前有两个层面，在计算层，主要通过 FaaS 提供服务，其特点是实例之间相互隔离，并且只有短暂的状态性。短暂的状态性指的是 FaaS 服务运行完毕后，实例销毁，状态也随之销毁。如果希望永久存储，则需要持续的写入到存储层（例如对象存储、K-V 存储等）即 BaaS 服务中，实现状态信息的长期存储和共享。
但当前这样的模式面临两个主要的问题：（26:31）
一方面是延迟问题，也是许多 BaaS 服务目前存在的问题；另一方面，对象存储或者 K-V 存储是通过 API 进行服务的，并不能感知到底层的存储情况，因此在开发应用或迁移时难以信任这些存储资源（改变了以往的开发使用方式）。所以我们的诉求很简单，是否可以提供类似本地磁盘一样的存储能力，区别只是在云端呢？
这就是 Serverless 云函数文件系统（CFFS, Cloud Function File System）所要提供的能力。该文件系统有以下几个特点：
- 基于标准 POSIX API 的文件系统，提供持久化的存储能力。
- CFFS 提供了透明传输机制，也就是在函数启动时，CFFS 也随之启动一个传输；而当函数销毁时，这个传输会被提交。这样做可以获取到函数执行过程中的许多状态信息。
- 虽然通常情况下传输会对性能有影响，但如果能够积极利用本地状态和缓存，这种方式相比传统的文件存储系统，对性能有很好的提升。
下面是 CFFS 的架构图，可以看出 CFFS 在云服务商的 FaaS 环境中运行，在前端通过标准的 POSIX API 进行调用，后端的存储系统则利用缓存等，专为云函数 FaaS 设计并提供服务。
参考文献：
第四个研究课题 Cloudburst 也是致力于解决 Serverless 中状态问题的项目。 Cloudburst 更侧重于怎样将 Serverless 应用在状态敏感、延时敏感的应用场景中。例如社交网络、游戏、机器学习预测等。
Cloudburst 主要基于 Python 环境，能够低延迟的获取共享可变状态（shared mutable state）,和 CFFS 类似， Cloudburst 也在函数执行器中利用了数据缓存来提升性能，但和 CFFS 不同的是，Cloudburst 可以保证因果一致性（Causal Consistency）来达到更好的性能。
实验结果上也表明 Cloudburst 有很强的性能优势。在相同条件下，用了 DynamoDB（K-V 数据库）服务的 Lambda 函数约有 239 ms 的延迟，但用 Cloudburst 的延迟低于 10 ms。
参考文献：
最后一个研究课题是 Serverless 数据中心。当我们思考服务器的组成时，一般会想到 CPU，内存，有时候还有 GPU 和硬盘这些基本硬件。而千千万万这些硬件组合在一起，之后进行网络连接，就成了数据中心。像个人电脑、服务器集群等都是通过这样的方式构建的。
但是从应用层的角度，这样的组合方式并不是唯一的。所以有一种新的概念叫做分布式集群（distributed datecenter），也叫 Warehouse-scale computer，思路是将同类型的硬件元素（例如 CPU、内容）组合在一起，当应用用到对应的资源时，例如需要 GPU 加速时，才会分配对应的资源。同理，可以用在硬盘或者一些自定义的加速器上面。这个概念类似于将一个数据中心看做一台计算机，来提升资源的利用率。
针对 Warehouse-scale computer 的硬件开发已经在持续进行中了，因此 Serverless 也应该考虑下在这种集群模式下，怎样适配和使用这种集群模式。而且这也将对当前针对单机的应用开发模式做出改变。
参考文献：
- https://www.usenix.org/conference/fast14/technical-sessions/presentation/keynote
- https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf
Serverless 方向预测
接下来，我将阐述下 Berkeley 对 Serverless 计算未来方向的预测。早在 2009 年，Berkeley 就对云计算的未来做过一次预测。回看当时的分析，发现有些预测是正确的，例如无限大的资源池，无需为前期使用付费等。同时，有一些预测并不那么准确，因为当时的我们并没有看到云计算将进入第二阶段，即 Serverless 阶段。
以下是我们对 Serverless 计算的预测：
- 特定应用场景及通用场景将会成为使用 Serverless 计算的主流。如下图所示，云服务商负责的是粉色区域的部分，而用户只关心粉色区域的上层。在特定应用场景下，你可以在弹性伸缩的平台中实现特定的操作，例如写数据库、实时数据队列、或者机器学习等。这些场景中，用户业务代码需要在遵循平台限制，例如运行环境、运行时长、没有 GPU 加速等，当然这些限制也会随着技术成熟而逐步放宽，从而更好地支持这些场景。
- 另一种则是更通用的 Serverless 架构，在这种场景下，你的 FaaS 函数会被其他 BaaS 服务所拓展，例如 Starburst、缓存等服务；并且有对象存储或文件存储可以用于长期存储状态信息。之后，在此基础上，用户可以自定义一些软件服务，例如提供 SQL 的能力等，并且将对应的应用运行在上面，从而实现流数据处理、机器学习等各种场景。
通用的 Serverless 几乎能够支持任何应用场景，从底层架构上来看，所有能运行在服务器上的场景，都可以被视为通用 Serverless 场景支持。
- 我们认为在未来，Serverless 架构比服务器在成本上会更有竞争力，当你用了 serverless 架构时，就已经获得了高可靠，弹性扩缩容的能力。此外，Serverless 的计费模式会更加精确，资源利用率也将逐步提升，确保做到真正的按需使用和付费。因此相比预留资源，在价格上会更有竞争力，更多的人也会因此选择 Serverless 架构。
- 此外，云服务商会针对机器学习场景做优化，包括性能、效率和可靠性等方面。云服务商会提供一些类似工作流调度，环境配置等能力来实现该场景的支持（例如预置内存）。通过这些上下游能力，也可以进一步帮助通用场景下的平台性能得到提升。
- 最后，是各类硬件方面的发展。当前云计算已经强依赖 X86 架构，但 Serverless 可以考虑引入新的架构，从而让用户或云服务商自行选择最适合的硬件来处理任务，从而实现更高的利用率和更强的性能。
总结
首先，我们认为 Serverless 计算是云计算的下一个阶段。而 Serverless 最重要的三个特征是：隐藏了服务器的复杂概念、按需付费和弹性伸缩。此外 Serverless 的实现是由 FaaS 和 BaaS 共同组成的（参考上面的经典案例）。直观来说，Serverless 带来的转变就像租车到打车一样。
此外，还分享了几个当前学术界针对 Serverless 的研究方向。包括效率提升（性能、可用性等）、具体应用的抽象（例如机器学习，数据处理等），和通用层面的抽象（让 Serverless 支持更加通用的场景）。
Serverless 计算可能会改变我们对计算机的看法，摆脱了本机硬件的限制，你可以直接从云端获取无限的资源，随取随用。
Serverless GPU (弹性 GPU 服务)的前世今生
