Meta研究：用于实时XR工作负载的多模型ML基准测试

　　基于机器学习的应用程序正变得越来越普遍。机器学习在视觉和语音识别任务中的成功推动了越来越复杂用例的发展。例如，元宇宙结合了多个单元用例(例如图像分类和语音识别)来创建更复杂的用例。

　　应用程序工程师越来越依赖于可组合性。他们不是为用例开发不同的大型模型，而是将多个较小而专的ML模型组合在一起来组成任务功能。在名为《XRBench: An Extended Reality Machine Learning Benchmark Suite for the Metaverse》的论文中，加州大学、Meta、乔治亚理工学院和哈佛大学的研究人员重点关注了这类机器学习的工作负载，即多任务多模型MTMM，特别是在元宇宙情景中。

　　团队开发了一个用于实时XR工作负载的多模型ML基准测试，并为每个模型提供了开源参考实现，从而支持广泛的采用和使用。另外，他们为XRBENCH建立了新的评分指标，从而捕获实时MTMM应用程序的关键需求并进行定量评估。XRBENCH目前已经作为一个开源项目托管至GitHub。

　　用于扩展现实的实时MTMM应用程序如图1所示。它描述了如何将数个MTMM模型级联和并发地操作，从而提供复杂的应用程序级功能。中心区域表明，处理吞吐量需求可能因使用场景而异。图右侧显示了如何为每个并发作业提供各种交错执行模式。

　　MTMM工作负载表现出模型异质性的和扩展的计算调度空间，以及与使用相关的实时约束，这使得它们与当今的单任务单模型STSM工作负载相比具有挑战性。

　　在研究中，他们确定了MTMM工作负载中出现的三个关键问题，而它们引出了有趣的系统级设计挑战。

　　第一是场景驱动行为。所有机器学习管道都以设定的每秒帧数处理速率运行，这取决于特定用例。场景有时甚至会对场景不需要的模型要求零FPS(即停用模型)。这种波动的FPS是因为基于情景的行为驱动系统资源利用率，这在设计底层DNN加速器时提出了一个障碍：异构工作负载使得难以采用传统的DNN专门化。

　　其次，MTMM工作负载表现出复杂的依赖关系。XR用例显示了跨模型的大量数据依赖和控制依赖。这种严重的模型依赖限制对底层硬件和软件调度空间产生了影响。特别是，控制流依赖关系使工作负载任务变得动态，从而增加了运行时调度的复杂性。

　　第三，XR工作负载具有严格的用户体验质量QoE要求。MTMM工作负载与STSM ML工作负载的一个关键区别因素是，理解如何在系统级别上跨并发ML任务量化聚合的QoE度量的重要性。由此产生的用户QoE超出了单个模型的计算性能，而这激发了对新指标的需求。像延迟和/或FPS这样的简单指标并不能捕获模型在不同场景下的复杂互动。

　　因此，行业需要一个全新的评分指标，从而捕获不同使用场景下MTMM工作负载的总体性能。评分度量必须综合考虑所有系统方面，包括模型准确性和与目标处理率相比的已实现处理率等等。

　　总的来说，这三个特性不仅给XR系统设计带来了挑战，而且给XR系统性能的基准测试和系统表征带来了挑战。遗憾的是，目前行业尚未完全理解与MTMM工作负载相关的诸多特征和系统级关注点。这在很大程度上是由于缺乏关于来自行业用例的MTMM工作负载的实际特征公共知识。换句话说，这种工作负载的机器学习系统设计领域有待探索。

　　另外，社区没有反映工业用例的MTMM工作负载的基准套件。大多数行业和学术基准套件几乎只关注STSM或MTMM，没有级联模型。为了解决这些不足，加州大学、Meta、乔治亚理工学院和哈佛大学的研究人员开发了XRBENCH。

　　这是一个实时多模型ML基准测试，具有针对实时MTMM工作负载量身定制的新指标。XRBENCH包括基于取自生产场景的真实工业用例的代理工作负载。代理工作负载在ML内核和系统级别封装了MTMM工作负载的端到端属性，从而可以研究巨大的设计空间。

　　XRBENCH包括ML用例的基于场景的FPS需求，这反映了在投资于XR的大型组织中驱动系统设计研究的应用程序中发现的复杂依赖关系。它同时为制定系统决策提供了有代表性的QoE需求。

　　XRBENCH由终端用户设备的诸多使用场景组成，结合了具有不同目标处理速率的各种单元ML模型，以反映MTMM工作负载的动态和实时特性。另外，为了使用XRBENCH对机器学习系统进行全面评估，团队提出并评估了新的评分指标，涵盖了实时MTMM应用程序的QoE的四个不同要求。

　　MTMM工作负载特征

　　为了帮助XR系统研究实时MTMM工作负载，研究人员定义了一个基于工业元宇宙数据库MTMM用例的基准套件。他们首先定义MTMM分类和实际MTMM工作负载的特征，即级联的和并发的MTMM。

　　与STSM工作负载不同，MTMM工作负载包括诸多模型，从而导致构建工作负载实例的多个模型组织选择。所以，他们定义了三个主要类别:

　　级联MTMM(cas-MTMM)：连续运行多个模型以启用一个复杂功能，例如图1中的音频管道。

　　并发MTMM((con-MTMM)：同时独立运行多个模型以启用多个单元功能，例如运行Mask R-CNN 和PointNet。

　　级联和并发MTMM：cas-MTMM和con-MTMM的混合，通过背靠背连接多个模型来实现一个复杂的ML管道，并为其他功能部署多个模型。

　　除了模型组织风格之外，模型执行图可以是静态的或动态的，这取决于为工作负载定义的单元管道。

　　如图1所示，如果手部检测模型没有检测到手，则可以停用手部追踪。在最近包含扩展现实的应用中，可以观察到动态和实时的cascon-MTMM风格的工作负载，它们代表了当今最复杂的ML推理工作负载。

　　尽管这种动态和实时的cascon-MTMM风格的工作负载正在出现，但我们缺乏动态cascon-MTMM工作负载的基准套件。因此，对动态cascon-MTMM的特征和挑战没有深入的了解。

　　级联和并发的MTMM工作负载是一类新兴的机器学习推理任务。它们具有传统ML工作负载中不存在的独特功能和问题。

　　元宇宙工作负载必须考虑使用场景，以确定应该包括什么单元任务。诸多现有的基于机器学习的应用程序通常使用单一模型推理来输入，例如图像或文本。相反，为了提供持续的用户体验，虚拟设备经常需要持续执行一组模型的推理，例如用户开玩VR游戏1小时。由于推理运行有助于用户体验，因此需要高质量的用户驱动体验(QoE)。在多模态推理情景中，QoE可以用处理速率或处理期限来表示，因此引入了实时处理需求。

　　所以，就像ML基准测试必须满足结果质量的一定程度的准确性一样，XR基准测试也必须提供目标处理速率。

　　元宇宙应用程序通常使用诸多模型。例如，基于双手的交互功能可以通过级联的手部检测和手部追踪模型来实现。这样的模型通常是级联形式，并且这样的级联模型描述为模型的管道。

　　图1给出了三个ML管道示例。它们需要转换为跨模型的数据依赖关系，而这需要在调度计算时考虑。MTMM ML管道可以根据上游模型的结果停用一个或多个下游模型。例如，当没有检测到手时，手部追踪管道不会启动下游手部追踪模型。这种动态方面给调度计算带来了另一个问题。

　　另外，元宇宙数据库基准测试必须包含反映元数据库工作负载动态特性的不同使用场景。

　　元宇宙设备的可穿戴外形因素使得热容和电池成为用户体验的重中之重。例如，如果过高，可能会导致皮肤不适或灼伤。长续航至关重要，因为可穿戴设备需要全天连续使用，但型抓鬼呢参数进一步限制了电池尺寸。

　　资源消耗必须是元宇宙终端用户设备的首要优化优先级。所有的需求都转化为能量限制。因此，基准测试需要包含能量目标，以确保设备提供出色的用户体验。由于所讨论的特征和障碍，用于元宇宙的实时cascon-MTMM工作负载是独特的。所以，与传统的模型级基准测试相比，这个领域需要一种定义基准测试的新方法。

　　XRBENCH

　　为了系统地指导MTMM基准的设计，团队重点关注了所述基准的关键要求:

　　使用场景：必须定义一组基于生产用例的实际使用场景，以及为每个使用场景运行的模型列表。

　　模型依赖关系：由于特定ML模型是级联的，必须指定跨任务的模型依赖关系，以研究资源分配和调度效果。

　　目标处理率：为每个使用场景中的每个模型提供有意义且适用的实时需求和处理率，从而建立应用程序行为和系统性能预期。

　　使用场景的变体：为了反映模型执行的动态特性并实现比较，基准测试必须为每个模型提供具有不同活动时间窗口的众多场景。

　　基于在XR领域的经验，团队定义了第一个反映元宇宙用例的动态cascon-MTMM基准。XRBENCH中有三个主要的任务类别，如表1所示：实时用户交互、理解用户情景和世界锁定。这种分类基于真实世界的工业用例。对于每个单元任务，从公共领域中选择一个具有代表性的参考模型。在选择模型时，考虑两个方面:模型性能和效率。另外，研究人员列出了每个单元任务的数据集和精度要求。

　　至于实时用户交互，这个任务使用户能够使用各种输入方法控制元宇宙设备，包括手部动作、眼睛注视和语音输入。因此，团队包含了相应的ML模型管道：手管道(端到端模型执行手部检测和追踪)、眼管道(ES和GE)和语音管道(KD和SR)。

　　至于用户情景理解，情景理解任务使用多模式或单模式输入来检测用户周围的情景，以便虚拟设备可以提供适当的用户服务。例如，当一个元宇宙设备检测到用户进入了一条徒步旅行路线时，它可以为用户提供气象信息。情景理解模型包括场景理解和音频情景理解。

　　至于世界锁定，为了在显示器上描绘增强现实对象，虚拟设备必须理解到现实世界表面和遮挡的距离。这种任务由世界锁定类别中的模型处理，其中包括深度估计模型、深度细化模型和平面检测模型。深度模型用于计算增强现实对象的正确尺寸，而平面检测模型用于识别可用于描述虚拟对象的真实世界表面。

　　为了反映不同的使用场景和目标处理速率特征，研究人员选择了五个现实的虚拟场景：社交;户外;AR助手;AR游戏;VR游戏。

　　即便在相同的使用场景中，由于cascon-MTMM工作负载的动态特性，活动模型都可能有所不同。例如，在户外活动的使用场景中，当用户休息并尝试使用AR设备进行导航时，与之前的徒步旅行场景不同，手部追踪模型这时将被激活。

　　为了对传感器进行建模，使用表3中列出的设置作为表1中的单元模型。摄像头是计算机视觉模型使用的图像输入源。激光雷达传感器利用RGBd数据为深度细化模型提供稀疏深度图。麦克风接收语音模型的音频输入。

　　实际系统中输入数据的到达时间可能与基于流速率的预测时间略有不同，这取决于多种情况。在许多研究分析中，抖动经常被忽略。但在真正的生产使用环境中，抖动可能会导致零星的帧丢失，从而降低QoE。

　　为了进行表征，对每个数据帧应用抖动，如表3所示，并相应地改变推理请求的注入时间。

　　XRBENCH要求用户完成一定数量的运行，这等于在设定的持续时间(默认:1秒)内的目标处理速率，从而确保满足实时需求。XRBENCH为每个使用场景中的模型提供了一个简单的latencygreedy或一个roundbin风格的调度器。用户可以替换调度器和图2中黄色框中突出显示的其他组件，以建模其运行时或系统软件的行为。

　　就像在传统的机器学习系统或机器学习基准测试中一样，优化软件堆栈对硬件的成功至关重要，XRBENCH鼓励这种优化。为了阐明XRBENCH中每个部分的角色，图3为表2中的“Social Interaction A”使用场景提供了一个示例执行时间轴。

　　左边的执行图显示了活动模型、它们的处理速率和模型依赖关系。右侧对应于场景的示例执行时间轴。最上面的部分表示表3中列出的来自相关输入源的输入流。每个输入源可以有不同的初始延迟和抖动。计算引擎只有在能够访问输入数据时才能执行模型推断。在本例中，团队对一个简单的调度器建模，假设只有在输入数据准备好时才能开始推断。

　　因此，一旦图像第0帧的输入数据检索结束，就开始第0帧的眼睛分割(ES)和注视估计(GE)。另外，GE在ES之后运行以满足它们的依赖关系。

　　接收图像和深度点输入后，执行多模态深度细化(DR)模型。由于DR的目标处理速率为30fps，而深度点输入速率为60fps，因此只使用其他输入。由于手部追踪(HT)同样以30帧/秒的速度运行，它会跳过每一个其他图像帧。

　　DR输出用于针对显示的AR对象渲染。因此，DR结果必须在一定的时间内交付，在本例中是30 FPS的截止时间。在执行时间轴中，有效地支持使用场景，并达到所需的处理速率。

　　然而，ET和HT的结果都超过了预期的截止时间(分别为1/60帧和1/30帧秒)。这表明在本例中，HT和ET延迟必须进一步减少。但延迟本身并不总是用作优化目标，因为超过最后期限的延迟减少可能不会改善用户体验。

　　即使是零延迟推理都不能将任务的有效处理速率提高到超过输入数据流速率的水平，因为没有它们，未来的数据就无法处理。这就提出了一个问题：应该如何通过考虑用户的实际结果质量来量化实时MTMM系统的性能?

　　团队展示了使用图3中的示例对实时MTMM工作负载的系统进行评估是非常重要的。例如，如果每个任务的处理速率受输入数据流速率的限制，较低的推理延迟并不总能改善用户体验。

　　在为实时XR工作负载评估系统时，我们需要捕获所述方面。因此，研究人员定义了一个新的评分指标，XRBENCH SCORE。它考虑到前文讨论的所有方面，并建议将其用作XRBENCH中的整体性能指标。

　　基于XR工作负载的独特特性，他们列出了基准测试的以下分数要求：

　　实时：如果延迟超过使用场景所需的性能限制(即错过截止时间)，分数应该包括惩罚。

　　低能耗：评分应该优先考虑低功耗设计，因为头显是能量受限型设备。

　　模型质量：分数应该捕获从运行所有模型交付给用户的输出质量。

　　QoE要求：如果FPS低于目标FPS，分数应该包括惩罚以维持QoE。

　　便于细分分析，每个分数都被限制在[0,1]范围内。他们将单位分数相乘以反映其所有方面，同时将结果保持在[0,1]范围内。团队使用平均值来总结一个模型在不同帧上运行的多个推理的分数，一个使用场景中的多个模型等等。

　　为了对实时需求进行建模，考虑以下观察结果：

　　对超出截止时间的推理延迟进行过多优化不会导致更高的处理速率。

　　减少延迟依然可以帮助调度其他模型。

　　违反最后期限逐渐破坏用户体验。

　　基于所述观察，他们寻找这样一个函数:(1)在截止日期附近逐渐奖励/惩罚减少/增加的延迟，(2)如果延迟远远超过(例如，10ms的截止日期为0.5ms)或在截止日期内，分别输出0和1。

　　图4说明了团队如何将各个阶段(单元、每个推理、每个模型、每个使用场景)的分数组合起来，并最终生成总体XRBENCH SCORE。

　　他们首先通过将实时性、能量和准确性分数相乘来计算每个推理分数。QoE分数在这里不适用，因为帧掉率只能在使用场景级别定义，FPS要求根据使用场景而变化。

　　使用每个推理分数，通过计算所有处理帧的平均值来构建每个模型分数。他们没有包括掉帧，因为它们将被考虑在QoE得分中。

　　为了计算每个使用场景得分，计算一个使用场景中所有模型的每个模型得分和QoE得分的乘积的平均值。基于讨论的方法，表4方框1和方框2形式化了得分指标。

　　评估

　　图5展示了评估结果，其中显示了运行每个使用场景的每种加速器样式的分数分解。综合分析实时评分用于量化违反截止时间的程度。实时分数越高越好。然而，高实时分数本身并不能保证理想的系统性能。例如，使用8K pe运行户外活动B(图5，(d))的加速器A的实时得分为1.0。然而，加速器A丢失了10.0%的帧，并且能耗高，比最节能的设计的加速器C高34.1%。评分指标包含了所有方面，包括帧丢失的QoE分数和能耗的能量分数，它报告的总分为0.49，比最佳加速器(I)低42.9%。

　　另一个例子是，在4K加速器系统上的AR游戏场景(图5，(g))。加速器G的QoE得分最高，为0.91，能量得分最高，为0.76。然而，由于严重错过最后期限，它的实时得分为零。换句话说，尽管帧率总体上接近目标，但用户将体验到严重的输出滞后，这会降低实时体验。

　　实时评分捕获到了这一点，并导致该加速器的总得分为零。硬件利用率通常用作加速器工作负载的关键指标，因为它可以通过将利用率乘以加速器的峰值性能直接转换为加速器性能。然而，团队不认为硬件利用率是实时MTMM应用程序的正确指标，因此不将其包括在总体评分指标中。

　　利用率不考虑帧丢失或周期性工作负载注入。例如，图6显示了4K和8K PE版本的加速器j的执行时间线。8K PE时间线(图6，(b))比4K PE时间线有更多的间隙，这意味着加速器的总体利用率低于4K PE加速器(图6，(a))，使得4K PE加速器似乎是更好的选择。然而，4K-PE加速器丢失了47.1%的帧，完全无法运行PD模型，而8K-PE加速器仅丢失了2.3%的帧。

　　与单独的利用率不同，团队提出的评分指标正确地捕获了实时需求和QoE方面。4K和8K PE加速器的丢帧率分别为0.53和0.97。另外，4K PE加速器中PD模型的大量截止时间违规导致实时得分为0。将单元得分合并到总分XRBENCH Score中，可以观察到得分为0和0.51，这为考虑所有因素的XR系统的综合性能提供了更直观的感受。

　　总的来说，元宇宙用例需要复杂的ML基准工作负载，这对于公平和有用地分析现有和未来的系统性能至关重要，但这样的工作负载超出了现有基准套件的能力。团队提出的XR基准基于行业经验，并捕获了新兴的基于ML的MTMM工作负载的多样性和复杂性特征。

　　他们表示，相信XRBENCH将促进以XR为重点的新机器学习系统研究。