LiteRT 代理

委托通过利用设备端加速器(例如 GPU 和数字信号处理器 [DSP])来实现 LiteRT 模型的硬件加速。

默认情况下,LiteRT 会利用针对 ARM Neon 指令集优化的 CPU 内核。不过,CPU 是一种多用途处理器,不一定针对机器学习模型中常见的繁重算术运算(例如,卷积层和密集层中涉及的矩阵数学运算)进行了优化。

另一方面,大多数现代手机都包含更擅长处理这些繁重操作的芯片。将它们用于神经网络操作可在延迟时间和能效方面带来巨大优势。例如,GPU 可将延迟时间缩短至原来的 1/5

每种加速器都有关联的 API,可实现自定义计算,例如用于移动 GPU 的 OpenCLOpenGL ES。通常,您必须编写大量自定义代码才能通过这些接口运行神经网络。考虑到每种加速器都有其优点和缺点,并且无法执行神经网络中的所有操作,情况会变得更加复杂。TensorFlow Lite 的 Delegate API 通过充当 TFLite 运行时与这些较低阶 API 之间的桥梁来解决此问题。

包含委托的运行时

选择委托

LiteRT 支持多个委托,每个委托都针对特定平台和特定类型的模型进行了优化。通常,根据两个主要标准,会有多个适用于您的使用情形的委托:您面向的平台(Android 还是 iOS?)以及您尝试加速的模型类型(浮点型还是量化型?)。

按平台划分的委托

跨平台(Android 和 iOS)

  • GPU 代理 - GPU 代理可在 Android 和 iOS 上使用。它经过优化,可在 GPU 可用的情况下运行基于 32 位和 16 位浮点数的模型。它还支持 8 位量化模型,并提供与浮点版本相当的 GPU 性能。如需详细了解 GPU 委托,请参阅 GPU 上的 LiteRT

iOS

  • 适用于新款 iPhone 和 iPad 的 Core ML 代理 - 对于配备 Neural Engine 的新款 iPhone 和 iPad,您可以使用 Core ML 代理来加速 32 位或 16 位浮点模型的推理。神经引擎适用于搭载 A12 SoC 或更高版本的 Apple 移动设备。如需查看 Core ML 代理的概览和分步说明,请参阅 LiteRT Core ML 代理

按模型类型划分的委托

每种加速器在设计时都考虑了特定的数据位宽。如果您向仅支持 8 位量化操作的委托提供浮点模型,该委托将拒绝其所有操作,并且模型将完全在 CPU 上运行。为避免出现此类意外情况,下表概述了基于模型类型的委托支持:

模型类型 GPU CoreML
浮点(32 位)
训练后 float16 量化
训练后动态范围量化
训练后整数量化
量化感知训练

验证效果

本部分中的信息可作为粗略的指南,帮助您过滤出可能有助于改进应用的委托。不过,请务必注意,每个委托都有其支持的预定义操作集,并且可能会根据模型和设备以不同的方式执行。因此,通常建议您执行一些基准比较,以评估委托对您的需求的实用程度。这也有助于证明与将委托附加到 LiteRT 运行时相关的二进制文件大小增加是合理的。

LiteRT 具有广泛的性能和准确性评估工具,可帮助开发者放心地在应用中使用委托。 下一部分将讨论这些工具。

评估工具

延迟和内存占用

LiteRT 的基准测试工具可与合适的参数搭配使用,以估计模型性能,包括平均推理延迟时间、初始化开销、内存占用空间等。此工具支持多个标志,可帮助您找出模型的最佳委托配置。例如,可以指定 --gpu_backend=gl--use_gpu 来衡量 GPU 的 OpenGL 执行情况。支持的委托参数的完整列表在详细文档中定义。

以下是通过 adb 运行量化模型的示例:

adb shell /data/local/tmp/benchmark_model \
  --graph=/data/local/tmp/mobilenet_v1_224_quant.tflite \
  --use_gpu=true

您可以点击此处下载适用于 Android、64 位 ARM 架构的此工具的预构建版本(更多详情)。

准确性和正确性

委托通常以不同于其 CPU 对等的精度执行计算。因此,使用委托进行硬件加速会带来(通常是微小的)准确性方面的权衡。请注意,这并非总是如此;例如,由于 GPU 使用浮点精度来运行量化模型,因此精度可能会略有提高(例如,在 ILSVRC 图片分类任务中,前 5 名的准确率提升不到 1%。

LiteRT 有两种工具来衡量委托针对给定模型的行为准确性:基于任务与任务无关。本部分中描述的所有工具都支持上一部分中的基准比较工具使用的高级委托参数。请注意,以下子部分侧重于委托评估(委托是否与 CPU 执行相同操作?),而不是模型评估(模型本身是否适合相应任务?)。

基于任务的评估

LiteRT 提供了相关工具,可用于评估以下两项基于图像的任务的正确性:

这些工具(Android,64 位 ARM 架构)的预构建二进制文件以及相关文档可在此处找到:

以下示例展示了在 Pixel 4 上使用 GPU 进行图片分类评估

adb shell /data/local/tmp/run_eval \
  --model_file=/data/local/tmp/mobilenet_quant_v1_224.tflite \
  --ground_truth_images_path=/data/local/tmp/ilsvrc_images \
  --ground_truth_labels=/data/local/tmp/ilsvrc_validation_labels.txt \
  --model_output_labels=/data/local/tmp/model_output_labels.txt \
  --output_file_path=/data/local/tmp/accuracy_output.txt \
  --num_images=0 # Run on all images. \
  --use_gpu=true

预期输出是 1 到 10 的 Top-K 指标列表:

Top-1 Accuracy: 0.733333
Top-2 Accuracy: 0.826667
Top-3 Accuracy: 0.856667
Top-4 Accuracy: 0.87
Top-5 Accuracy: 0.89
Top-6 Accuracy: 0.903333
Top-7 Accuracy: 0.906667
Top-8 Accuracy: 0.913333
Top-9 Accuracy: 0.92
Top-10 Accuracy: 0.923333

与任务无关的评估

对于没有成熟的设备端评估工具的任务,或者如果您正在尝试使用自定义模型,LiteRT 提供了推理差异工具。(Android,64 位 ARM 二进制架构二进制文件,请点击此处

推理差异比较了两种设置下的 LiteRT 执行情况(在延迟时间和输出值偏差方面):

  • 单线程 CPU 推理
  • 用户定义的推理 - 由这些参数定义

为此,该工具会生成随机高斯数据,并将其传递给两个 TFLite 解释器,一个运行单线程 CPU 内核,另一个由用户的实参进行参数化。

它会测量两者的延迟时间,以及每个 Interpreter 的输出张量之间的绝对差值(按元素计算)。

对于具有单个输出张量的模型,输出可能如下所示:

Num evaluation runs: 50
Reference run latency: avg=84364.2(us), std_dev=12525(us)
Test run latency: avg=7281.64(us), std_dev=2089(us)
OutputDiff[0]: avg_error=1.96277e-05, std_dev=6.95767e-06

这意味着,对于索引为 0 的输出张量,CPU 输出与委托输出之间的元素平均差异为 1.96e-05

请注意,解读这些数字需要深入了解模型以及每个输出张量所代表的含义。如果它是确定某种得分或嵌入的简单回归,则差值应较小(否则,委托存在错误)。不过,像 SSD 模型中的“检测类”这样的输出就有点难以解读。例如,该工具可能会显示差异,但这并不一定意味着委托存在严重错误:假设有两个(虚假)类:“电视(ID:10)”和“显示器(ID:20)” - 如果委托与真实结果略有偏差,显示的是显示器而不是电视,则此张量的输出差异可能高达 20-10 = 10。