如何实现2000万QPS？Meta揭秘背后的AI平台MultiRay：日均处理8000亿次请求！

---

  新智元报道  

编辑：LRS

【新智元导读】大模型背后的基础设施该怎么建设才最划算？

想要性能强，模型除了「大」，还是「大」。

 

无论是自然语言处理、计算机视觉或是其他领域的研究，当下的深度学习研究范式通常采用非常大的模型架构，对海量的数据进行训练，然后将其用于一个特定的任务上，从而取得更佳的结果。

 

这种范式的好处是可以提升任务的性能指标，但由于其昂贵的训练成本，如果有大量的问题需要解决，那相应地就需要训练多个模型，运行成本也将急剧上升，甚至会达到无法实现的程度。

 

 

这也意味着在实践中，论文中提出的sota大模型只有很少一部分能够在生产环境中使用，真实世界的模型往往更小更简单。

 

为了提高人工智能系统的运行效率，Meta提出了一个人工智能平台MultiRay，可以运行大规模sota人工智能模型。

 

 

MultiRay上部署多个模型后，通过对相同的输入计算得到的embedding进行重用，即只计算一次，共享了大部分处理成本，所以分摊到每个模型上的计算成本就很小，从而可以优化所有AI任务执行的总成本。

 

并且开发者也会更加容易地引入AI加速器，因为整个公司的计算集中在一个单一的模型中，可以在公司级别的计算能力和存储之间进行权衡。

 

MultiRay 的通用模型经过训练后，能够在广泛的任务和领域中表现良好。这种万能的模型比之前使用的小得多的针对每个任务的专门模型提供了更好的质量。

 

通过使用 MultiRay，Meta 团队可以更快地改进和迭代机器学习(ML)模型应用于大量实际场景中，比如为帖子生成主题标签、仇恨语音检测等。与其他团队从头开始构建大型端到端模型相比，这些任务也可以以更高的效率和更少的人力完成。

 

有网友对MultiRay编了一个地狱笑话：「实在是太高效了，所以Meta选择开除一万名员工。」

 

 

相关论文

 

MultiRay是Meta宏伟的人工智能蓝图中的一部分，剑指AI领域的多项难题。

 

论文链接：https://proceedings.mlsys.org/paper/2022/file/ed3d2c21991e3bef5e069713af9fa6ca-Paper.pdf

 

《无监督的大规模跨语言表征学习》中，研究人员首次证明，在不牺牲每种语言性能的情况下，可以进行多语言建模。

 

论文链接：https://arxiv.org/abs/1911.02116

 

《从预训练语言模型的通用文本embedding中进行可扩展推理》中，研究人员演示了一种自然语言处理任务的解决方案，使用大规模的预训练的模型对同一文本执行多个任务，而计算成本可以下降很多。

 

论文链接：https://arxiv.org/abs/2004.14287

 

《多尺度视觉Transformer》和《带掩码的自编码器作为时空learners》中，展示了MultiRay技术在视频相关任务中的应用研究。

 

论文链接：https://arxiv.org/pdf/2104.11227.pdf

 

论文链接：https://arxiv.org/pdf/2205.09113.pdf

 

多模态、多任务

 

MultiRay的第一个模型 TextRay 自2020年起投入生产，支持文本理解应用程序，如检测不真实内容和改善用户的搜索体验。

 

但在现实世界中的应用场景下，仅能处理文本数据是远远不够的。

 

比如Facebook的推送中可能同时包含文本、图像和视频。为了理解一篇文章，模型需要分别分析其中的每一个字、每一张图，并在其他元素的上下文中进行分析。

 

 

但是这样做就意味着将几个已经计算密集型的模型组合成一个更大、更密集的模型，随之而来的就是计算量和功耗的增加，让更强大的机器学习模型无法有效投入到产品和服务中。

 

PostRay是MultiRay的第二个模型，可以将文本和图像理解集成到同一个模型中，比如跨Facebook和Instagram的帖子通常同时包含文本和图像数据，就可以使用PostRay。

 

 

通过使用PostRay，开发团队无需重复开发文本和图像理解的模型，PostRay已经用于Reels分类。

 

PostRay模型由于同时包含多个领域的尖端研究，因此训练、部署和维护起来更加复杂。通过使用 MultiRay，研究人员只需要执行一次，即可完成这些任务，整个公司都会从中受益。

 

一个集中的系统服务于一个万能的模型，使开发者能够直接与最前沿的研究团队合作，并在他们的研究成果发表后不久就将其投入生产。

 

MultiRay工作原理

 

MultiRay的主要目标是使 Meta的大规模基础模型的访问更加廉价，通过将模型集中执行在像GPU这样的加速器上，并使用缓存尽可能地节省重复计算的成本来实现的。

 

目前，MultiRay在Meta 中支持超过125个用例，每秒支持多达2000万个查询(QPS) ，同时每天服务8000亿次查询。

 

什么是embedding

 

大规模基础模型的输出表示为高维向量空间中的一个点，这个点可以用来表征输入，也称为embedding

 

 

embedding是原始输入的一个更加机器学习友好的版本，与处理原始输入(如文本和图像)不同，任务特定的模型可以使用 MultiRay 中的embedding表征，这样处理起来要简单得多。

 

MultiRay 中部署的基础模型被优化为适用于各种任务，包括相似性和分类，这种通用性使得模型输出的embedding相当大(几千字节) ，用以便传递更多的信息。

 

集中模型开发——分摊多个团队的开销

 

大型模型和延迟限制要求在像 GPU 这样的加速器上执行。

 

GPU等专用加速硬件在Meta中的需求量很大，但即使有足够的GPU，最先进的模型也还是需要消耗大量的能量来训练和托管。MultiRay 的客户团队分摊了训练和托管这些大型模型的费用，因为相同的硬件和处理可以多次使用。

 

集中模型比每个团队单独托管的东西要大得多，质量也要高得多，在这种情况下，一加一实现了大于二。

 

 

并且集中模型也带来了更简单的开发和操作。

 

通常公司内部的多个团队只会负责他们自己的模型、基础设施和模型维护。而随着模型规模的增长，对每个团队进行培训和服务的操作负担越来越重，使得将复杂的优化技术应用到跨越多个团队的模型变得更加困难。

 

MultiRay使用几个大规模的集中模型，可以让单个团队处理大部分操作和优化。客户端团队拥有更小的、特定于任务的模型，这些模型更容易管理。这使得许多没有足够资源来训练、部署和管理尖端人工智能的团队能够使用这项技术。

 

提升GPU效率：交叉请求一批数据

 

加速器硬件在并行处理聚合的一组（批, batch）请求时效率最高。将请求合理地分配到batch中能够增加服务的吞吐量，而不会造成不必要的延迟。但batch结构增加了内部客户的复杂性，理想的batch可以随着新的硬件或模型而改变。

 

为了简化用户的负担，MultiRay的外部API一次只针对一个请求，然后在内部使用交叉请求批逻辑（cross-request batch logic）将跨客户端的许多并发请求聚合到一个批中。

 

用户可以编写逻辑来调整batch size，以便为模型和硬件创建理想大小的批。这种批处理设置对于发送请求的客户机来说是完全隐藏的，可以随硬件性能进行动态调整，比如迁移到新一代 GPU 加速器硬件时使用了更大的批处理大小。

 

缓存: 权衡计算和存储

 

MultiRay 利用缓存尽可能地节省重新计算的成本，使用多层缓存实现最小成本和低延迟，每一层都会带来更高的命中率，但以较低的速度为代价。

 

这些层从每个 MultiRay 服务器的 RAM 中的一个快速但较小的主机本地缓存开始，最后以一个较慢但较大的全局分布式闪存缓存结束。

 

MultiRay模型很大，并且它们会生成高维度的embedding来保持通用性。对于文本理解来说，这些embedding要比输入本身大得多。

 

 

从高速缓存中embedding所需的电量比重新计算所需的电量要少，但不可能是零。由于可用的缓存存储空间是有限的，因此也不可能在缓存中长时间缓存结果。

 

MultiRay会测量客户端之间的请求模式，以确定最佳缓存设置(大小、生存时间、更新策略) ，从而降低服务的总成本。

 

比如说使用这些测量数据来模拟各种缓存生命周期设置所需的能量，在GPU加速器上重新计算请求的成本与从缓存服务请求的成本之间进行权衡。这个反馈循环可以在客户端行为不断变化的情况下提高 MultiRay 的效率。

 

没有免费的午餐

 

这种集中式的服务也带来了许多挑战。其中一些难题比如客户端管理、quotas和成本归属等，被认为是数据库等大型系统已经解决的问题，但需要将算法适应于人工智能领域。

 

此外，只有在集中模型被广泛使用的情况下，才能分担更高质量、更昂贵的 MultiRay 模型的费用，这也就要求模型在许多用例中提供最先进的质量。

 

这个不断变化的目标意味着MultiRay需要在模型更新(版本控制，升级到新版本，废弃旧版本)和创新新的模型架构和训练流程上投入大量资金，以减少从研究到生产时间，从而让MultiRay的用户使用上最新的技术。

参考资料：

https://ai.facebook.com/blog/multiray-large-scale-AI-models/