导读 在如今 AI 赋能百业的时代，丰富的场景带来了多样的部署端需求。为了契合业务发展，推动 AI 业务落地，商汤基于高性能计算背景，自研了 PPL 推理框架、高性能神经网络算子库、图像处理和代数计算库等加速引擎，希望能为智能手机、安防、金融、互动娱乐等业务线输出多平台、高性能的部署能力。

PPL 作为商汤科技自研的推理部署平台，是商汤 AI 大装置平台层重要的推理组件。其特点在于：针对目前支持的所有可编程架构，采取从底层算子到上层框架的全自研方案，充分发挥出产品在部署侧的竞争力。自 2015 年开始发展，除了支持基础计算平台，更是进一步拓展支持了 NV GPU，以及云侧、端侧 AI 加速器等。

本次老师分享的内容为面向全平台的深度学习部署工具包 PPL，主要介绍：

1. 深度学习部署工具 PPL

2. PPL 全平台应用支持

3. PPL CUDA 技术实践

4. PPL 技术展望

---

分享嘉宾｜李天健博士 商汤科技 高级系统研究员

编辑整理｜王剑芬 觅谷科技

出品社区｜DataFun

---

01/深度学习部署工具 PPL

首先介绍一下 PPL 部署工具包。

1. PPL 部署工具包

随着深度学习算法在智慧城市、智慧医疗、元宇宙、自动驾驶等领域的应用越来越广泛，深度学习模型也越来越丰富。为了应对越来越多的部署诉求，商汤自主研发了针对全平台的部署工具包 PPL。PPL 部署平台主要包含三个模块：工具链层 包括量化工具链以及模型转换工具链；引擎层 是面向不同平台的 PPL.NN 推理引擎框架；算子层是多后端的高性能算子库，支持 NN 算子、CV 算子以及一些领域专用的算子等。

接下来我们逐一介绍 PPL 的各个组件。

2. PPL.NN AI 推理引擎

PPL.NN 推理引擎是部署工具包的最核心模块，特点是非常简单易用，支持 C++、Python 等各种接口以及超过 200+ 的 Caffe 和 ONNX 算子，覆盖分类、检测、分割、超分等多种场景的推理部署需求。同时内建了对 OpenMMLab 算法平台的算子高性能实现，能够支持 OpenMMLab 模型的快速部署。PPL.NN 推理引擎覆盖的计算后端平台超过 20 种。

除此之外，PPL.NN 推理引擎做了很多核心 Feature 的开发。

（1）支持多推理实例共享模型，减少模型内存占用。

（2）支持计算图拆分异构并行，发挥异构算力。

（3）支持灵活的 PlugIn 插入方式，可以更好地去做扩展。

（4）支持 NN 的动态图特性，应对更复杂的模型支持。

3. PPQ AI 推理量化工具

目前，深度学习量化是在端上部署时非常常见且有效的一种优化手段。

（1）PPL 推出 PPQ AI 推理量化工具，支持多种常见业务场景中的模型低比特量化，包括 int4、int8、int16 以及 fp16、fp32 等混合精度量化。

（2）PPQ 融合了目前业界最主流的 SOTA 量化算法，例如 weight equalize、ada-round、LSQ 等，可保证量化后的模型在实际部署到硬件后端后，精度依旧满足业务组的需求。

（3）PPQ 支持非常多的推理后端，除了自研的 PPL.NN 之外，还支持了 NCNN、TensorRT、OpenVINO 等。

（4）值得一提的是，PPQ 的自研量化前馈仿真、量化误差传递等算子库具备 CUDA 加速功能，相比原生 PyTorch 的量化算子，具备 3~10 倍的性能提升，并在公司内部的业务应用中得到了大量的实践的支持。

4. PPL.CV 图像处理算子库 PPQ

在业务部署过程中，除了 NN 推理之外，图像处理的算子也是非常重要的。PPL.CV 图像处理算子库是专门针对常用的图像前后处理进行针对性高度优化的图像库，在接口上完全对齐 OpenCV，支持的后端比 OpenCV 更完善，支持的算子数量也更多。

目前 PPL.CV 已经开源，希望在整个部署链条中能去做更多的优化工作。

5. PPL 领域专用加速库

除了 CV 算子之外，很多领域专用的算法也需要特殊的算子加速库，包括激光雷达感知、图像感知、构图定位等。PPL 针对不同领域构建了专门的加速库，去优化整个部署的 pipeline，保证能够最大化的发挥整个硬件和后台的性能。

6. 后端支持汇总

目前 PPL 累计支持 CPU、GPU、DSP、DSA 多种主流后端架构。

（1）CPU：支持的 CPU 包括了目前主流的 ARM、X86、MIPS、RISC-V 等。

（2）GPU：支持 Nvidia GPU 还有移动端的 Mobile 的 GPU。

（3）DSP：支持的包含有 Cadence、CEVA、高通、TI 等等。

（4）DSA：目前支持的种类也越来越多，包括有华为 Ascend 等 NPU 平台。

02/PPL 全平台应用支持

下面给大家介绍一下这些核心模块在一些比较重点平台中优化的实践。

1. PPL- 基础算力平台（Mobile ARM/Mobile GPU）

首先介绍 PPL 在基础算力平台上的优化，主要是 MobileARM 和 Mobile GPU。基础算力平台的特点是可编程能力强、功能完善，针对基础算力平台，PPL 进行大量优化使其发挥非常极致的性能。

以 ARM 为例，ARM 的 CPU 是 PPL 支持最完善的平台之一。

（1）模型支持：支持超过 6000+ 的模型，包括人脸检测/识别、超分、活体检测等。

（2）指令集支持：基本支持全部的指令集，包括 ARM V7、ARM V8、ARM V8.2、ARM V9 等。

（3）覆盖主流 ARM 架构：主流的 ARM 框架也是支持的，包括 Cortex-A 全系列、Neoverse 全系列等。

（4）技术优势：

① 针对不同的目标平台定制化的算法 tunning 的工作，充分发挥硬件性能。

② 针对 ARM 的微架构，对主要计算 Kernel 在汇编指令级别进行调优。

③ 针对网络的特性做了大量的图优化以及数据排布方面的优化，保证充分发挥 CPU 的性能。

在 Mobile GPU 上，PPL 的应用也非常广泛。

（1）模型支持：支持超过 1000+ 的模型，包括人脸检测/识别、超分、活体检测等。

（2）覆盖主流 OpenCL 标准：支持 OpenCL 1.0～1.2 以及 OpenCL 2.0～2.2。

（3）支持数十款移动 GPU：支持包括高通、Mali、PowerVR 等各种架构的 GPU。

（4）技术优势：

**① 算子调优：**结合硬件架构特征实现了核心算子的深度调优。

**② 框架调优：**支持图融合优化，并充分利用 image 内存的 cache 友好性等特性做了优化。

**③ 预处理优化：**通过离线算法选择与 Binary Cache 机制，最大化地降低整个模型初始化的时间。

从上图可以看出，无论是在 ARM 还是移动端的 GPU 上，PPL 相对与其他竞品有比较大的性能优势。

作为一个通用计算平台，PPL 部署工具包针对 ARM 和 GPU 都做了大量的支持，也积累了大量模型层面以及算子层面、算法层面的优化经验。

2. PPL-DSP 加速平台

DSP 加速平台也是目前应用比较广泛的平台之一，除了手机端，车载 SoC 上对 DSP 的诉求也是越来越高。

**（1）全自研：**针对 DSP 平台，PPL 全自研处理框架去做适配，包括底层算子、执行和调度的 runtime，以及量化方案等。

**（2）低占用：**结合内存的高度复用，降低内存的占用。

**（3）高性能：**针对不同厂商的 DSP，深入到汇编级别去做底层指令级的优化，最大化的发挥平台的能力。

**（4）端到端：**完善支持神经网络的推理，图像处理的加速以及领域计算加速。

（5）轻量级：不依赖于第三方库，整个 runtime 是非常轻量级的。

目前 PPL 已经支持了高通、Cadence、TI，还有 CEVA 的 DSP。

上图是 PPL 在高通 DSP 上的一些结果，在初始化时间、推理性能、CPU 以及内存的占用等 4 个维度，PPL 相对主要竞品有比较大的优势。

03/PPL CUDA 技术实践

1. PPL.CUDA 计算平台

接下来介绍一下 PPL.CUDA 在针对端上平台的优化实践。

CUDA 平台有以下主要的特点：

**（1）复杂的应用场景：**CUDA 支持的应用场景非常多样，包括科学计算、医疗、机器人、VR 等，基本所有的应用都可以用 CUDA 通用计算平台来支持。

**（2）多种计算平台：**计算平台也是多种多样，包括桌面端的 GeForce、车载的 Orin、云端的 Tesla 的芯片、嵌入式的 Jetson、加速器的 DLA 等。

**（3）软件栈：**CUDA 提供的软件栈非常丰富。为了支持上层更多的应用，提供了非常完善的 SDK 工具包，包括了一个 CUDA 的编程环境。利用 CUDA 软件生态，自研开发 PPL.CUDA 推理引擎去支持更多的AI部署的加速功能。

2. PPL.NN 部署流程图

下面简单介绍一下 PPL.CUDA 的部署流程，首先把训练好的模型导入到 PPL 的推理引擎中，PPL Optimizer 会对模型完成图优化工作，包括常量展开、图融合、算子的消除/合并等等。接下来我们可以走两条路径。

**（1）路径一：**序列化一个 PMX Model 的格式，把离线优化的结果保存到中间文件。然后轻量级的 Runtime 去加载解析中间文件，部署到不同的平台上。

**（2）路径二：**通过 On-Line 的形式，直接把推理引擎优化的结果导入 Runtime 中，不经过中间文件的格式，然后去做部署。可以部署在云端、PC 端或车载等各种不同的芯片上。

3. PPL.NN Optimizer

端侧部署有四个特点：

（1）推理性能：极高的推理性能需求。

（2）初始化时间：极短的初始化时间。

（3）运行库体积：极小的安装包。

（4）部署灵活性：安装包可以部署在不同的 GPU 的后端上。

针对这些特点，PPL 分别在 Optimizer 阶段、Runtime 阶段去做技术研发，提升端侧部署的能力。

4. PPL.NN Optimizer -Auto Tuning

神经网络模型的推理性能主要受计算密集型算子的影响，主要包括卷积、矩阵运算等。下面以卷积为例，介绍一下优化以及 tuning 的过程。

上图描述了一个简单的卷积的实现过程，如果把它映射到矩阵计算上，比较常见的是一个 Im2col 的过程。矩阵运算是可以非常高效地利用 GPU 上的计算资源，包括 TensorCore 和 CUDA Core，都非常适合去做矩阵运算的应用。

但是 im2col 会存在一个明显的问题，需要一个显示的过程去把 feature map 做展开。这样就可能导致：一是需要额外的显存空间；二是需要一个显示的转换过程，会带来一定的额外开销。

除了一些卷积计算的加速算法（比如 Winograd、FFT 等），CUDA 平台还有一个主流的实现算法，就是隐式矩阵乘法（Implicit-GEMM）。该算法利用 GPU 的存储结构中的 Share memory、local memory 或者 cache 等去做一个隐式的展开，完成 Im2col 的过程。顾名思义就是把这个转换的过程通过数据读取的方式，把它隐式的展开。目前 TensorRT、CUDNN、CUTLASS 都采用这个算法。

图中右侧的代码就是隐式矩阵乘一个简单实现。外面两个循环就是对输出通道和 featue map 去做循环，这两个维度可以在 GPU 上很好的并行。核心计算就是内部的循环，就是在 FH × FW × IC 这个通道去做累加。通过索引计算省去了 Im2col 的操作，从而避免开辟临时空间。

利用卷积计算的规范性，可以通过提前计算索引的方式，把索引的结果保存在 Look-Up-Table 里面，进一步优化算法实现。整个 Kernel 的实现过程中是通过查表的方式来得到索引的计算，尽量减少 index 的计算，来保证整个核心计算部分只有 mma 的计算指令以及访存的指令，最大化地发挥整个 GPU 的性能。

GPU 的核心计算单元完成内部的核心循环，核心循环需要对 FH × FW × IC 去做累加，这个累加的顺序也会对性能产生较大的影响。

目前主要有以下三种常见的累加顺序：

**（1）Channel-last 滑窗顺序。**这种滑窗顺序的优点是有更好的数据复用，滑窗在 FH/FW 维度的移动可以复用相邻 OH/OW 点的读取数据。缺点是访存不连续，会造成访存带宽的降低。例如当滑窗到下一个 FH 或 IC 时，特征图的数据会在较远的地址存放，造成访存的不连续。特别地，当孔洞卷积大于 1 时，滑窗在 FW 维度的访存也是不连续的。

**（2）Channel-first 滑窗顺序。**它的优点是有更好的访存带宽。由于采用 NHWC 的排布格式，IC 维度是连续存储的，channel-first 的滑窗顺序可以保证通道维度是连续读取的。然而这种滑窗顺序的缺点是数据局部性较差，滑窗在 IC 维度的移动无法复用相邻 OH/OW 点的读取数据。

**（3）Channel-interleaved 滑窗顺序。**Channel-interleaved 滑窗顺序结合了Channel-first 和 Channel-last 两种滑窗顺序的优点，既可以有效利用窗口滑动时的数据复用，又可以保证访存数据是连续读取的。

除了卷积算法，卷积配置本身也会对算法的实现有些影响。根据卷积参数的变化特征和 Tensor Core 的计算特点，OpenPPL 将卷积大致分为大图小通道、小图大通道、大图大通道这三类，并根据这三种分类设计了相应的卷积算法。

5. 大图小通道 -IDXN 算法

大图少通道类型的特点，

（1）OH/OW 很大，可以生成足够多的线程块来使用 GPU 的硬件资源，可以保证 GPU 的 SM 利用率非常高。

（2）输入通道 K 比较小，特别是小于 mma.MxNxK (1688/8816) 中的 K，需要显示地填充 0 去适配 TensorCore，导致整体的利用率较低。

为了解决这个问题，我们对 implicit gemm 算法做了部分修改。

**（1）使用动态生成索引的方式。**如图，我们可以按照 feature map 里真实 channel=2 的顺序去读取，而不用一定去读这 8 个 K 出来，而是通过 feature map 的其他位置去拼凑出这 8 个数据来，这样可以保证最大化的发挥 TensorCore 的能力，减少一些冗余的数据读取。

（2）不使用 Shared Memory 进行暂存数据，K的维度较小，循环次数很少，使用 share memory 进行缓存和 double buffer 带来的收益较少，还会增加数据读取的延迟。可以直接把数据 load 到寄存器中，减少通过 Share Memory 的数据缓存带来的延迟。

6. 小图大通道 -2SPK 算法/大图大通道 -Swizzle 算法

小图大通道类型的特点：OH/OW 尺寸小，传统分块导致 Block 数量少，SM 占用率低。

（1）为了提升 SM 的占用率，PPL 提出双层规约的算法，就是在传统的 implicit gemm 基础上，加了一个 Inter-Block 和 Intra -Block 的规约。我们可以在 block 内部做 warp 级别的规约，就 warp1 和 warp2 进行做规约，也可以在 block 级别之间在 global memory 上去做规约，这样可以最大化的提升整个 SM 的利用率。

（2）除了对于通道层 IC 进行划分外，也可以对卷积核 FH × FW 进行划分，可以产出更多的分块，更充分地利用 GPU 的并行硬件资源。比如 3 × 3 卷积核，可以划分成 9 个，在 9 个层面去做规约，进一步提升整个 GPU 的利用率。当 GPU 的计算资源比较丰富，但模型又很小的时候，利用这个方式是可以明显的提升整个推理的性能。

大图大通道类型的特点：OH/OW 尺寸大，输入输出通道也很大，属于计算密集型的任务。

根据它的特点，PPL 也做了两种优化方案。

（1）Swizzle，通过任务分块重映射，形成一个虚拟的更大的 block，相当于在更宏观的层面上去利用数据的局部性，最大化地发挥计算密集型在 GPU 上的效果。

（2）当大图大通道的时候，卷积核通道相对于 feature map 来说其实小很多，可以尽量把 Filter 的数据保存在 cache 上去做优化。

7. PPL.NN Optimizer-Auto Tuning

GPU 是一个非规范化的计算资源，可以做大量模块化的设计，保证有足够量的 Kernel 去覆盖更多的卷积 case。我们对 Warp、Block、K 纬度、Pipeline Stage 等进行了分块，同时可以根据这些分块的参数生成不同的 Kernel。

定义卷积计算解空间

（1）Warp 分块：Per-Warp。

（2）Block 分块：Per-CTA 分块。

（3）K 维度分块：K/S 表示 Block 内规约的倍数。

（4）Pipeline stage 分块：double buffer 的使用。

（5）解 R：（B_m，B_n，W_m，W_n，K，S，pipe）。

选择 Resnet34 模型为例，分析各种卷积算法的性能。可以看到无论在单 batch 还是多 batch 的情况下，PPL 相比于 CUTLASS 、cuDNN、TRT 都有一定的性能优势。可以看到因为 PPL 有多种算法的加成，在不同的配置上会得到一些性能的提升。

8. PPL.NN Optimizer

以上是在 Tesla T4 上的一个测试结果，可以看出 PPL 在模型层面也有一定的性能优势。

9. PPL.NN Runtime-Runtime Compiling

端侧除了注重推理性能之外，对初始化的时间、计算库的体积以及整个部署的灵活性都有一定的要求。为了配合前面提到的分块，包括 auto tuning 的过程，PPL 设计了 runtime compiling 的机制，去保证在端上或者在嵌入式设备上去做部署。

整个过程是非常的简单，上图中左侧分别是，

（1）2D Convolution 就是一个传统的卷积的定义。

（2）Param templates 就是一些对不同算法做的分块的结果。这里面可以定义一些templates 来表示，比如说 B_m、B_n 表示 Block 的分块，W_m、W_n 表示 Warp 的分块，K 和 S 分别表示内部循环的分块和 stage 的信息，pipe 表示一些 double buffer 的信息等等。

（3）同时加入了一些 algo templates 的定义。algo 就代表需要对索引的重新计算，以及对 data prefetch 去做一些修改。Swizzle 可能需要对前处理，需要对任务的重映射去做一些处理。2SPK 可能需要对后处理，需要添加一些 block 级别或者 warp 级别的 reduce 等等。

**第一步，**在这个框架里面 PPL 实现一个 CostModel，它的输入就是 feature map 的信息，包括卷积的参数。其中 hardware 的 information 就是这个 device 的信息，比如说是 T4 或者是 Orin 的硬件信息。利用上述信息，内部的 CostModel 会得到一些最优配置的结果。

第二步就是一个 generator 的过程。它可以根据我们 candidates 里面的这些 param templates 去生成不同模块的 templates。比如说 mma 计算模块的 templates，拷贝数据 fetch 的 templates，包括从 share memory 或者从 global memory 到寄存器的 load 的过程。包括这个算法相关的 templates 是否需要去做 reduce，还是否需要去做任务的 remap 等。最终通过一个代码的封装器，它可以去把这些 templates 封装成一个完整的 kernel。

**第三步，**这里是一段伪代码，就是把这些不同的 templates 封装到一起，最终形成一个 kernel。

**第四步，**可以调用 NVRTC（CUDA 提供的 RTC 工具）工具去把 Kernel 在线地编成一个 Cubin 或者其他的格式，然后存储到 PMX Model 文件。当然也可以在线地直接交给 Runtime。针对端侧，它可以存储到 PMX Model 里面。然后端侧的 Runtime 在部署的时候，可以直接 load 这个 PMX Model。里面就包含模型的信息，也包含这些 Kernel 的信息。这个机制可以保证整个 Runtime 是非常轻量级的，它不再依赖于计算库，只需要包含了模型的信息和整个 Kernel 的信息。在端侧设备上，比如说在 pc 端的一些 app 的应用，就是非常适用于这种机制的。

运行时编译优势及性能对比：

**（1）计算库体积：**运用运行时编译的计算库体积非常小，如果采用静态编译，因为算子数量非常多以及代码生成的量也非常大，整个静态编译的计算库体积非常庞大。

**（2）初始化时间：**以 Resnet50/Batch=32 为例，运行时编译需要 200 秒左右。当 Batch=1 的情况下，这个时间会非常的短。去掉离线代码的生成时间，初始化时间会更短，可能是一个毫秒级别的时间。如果是静态编译的话，因为整个代码生成库里面包含了算法的 templates 非常多，可能会导致整个算法选择的时间很长。

**（3）部署灵活性：**采用运行时编译机制，部署的 Package 只包含一些 Runtime 的信息，部署的灵活性非常高。如果采用静态编译生成中间文件的话，就导致不同的设备需要不同的中间文件，会增加模型管理的复杂度。

**（4）推理性能：**在推理性能方面，运行时编译也有一定的优势，相比静态编译有 5% 的性能提升。尤其在比较大的模型中，templates 的代码在静态编译的情况下，可能需要卷积去把后面的 activation、concact 的算子去做融合，就导致整个代码的体积非常大。但是在运行时编译的时候，代码里面就只包含实际融合的算子，这样就可以保证寄存器的利用率会更高。

04/PPL 技术展望

1. 技术展望

（1）完善国产化支持生态。芯片的国产化是需要大家共同努力去推进的一个过程。PPL 对国产化芯片的支持是比较完善的，在 CPU 上已经对 ARM、X86、RISC-V、MIPS 等做了支持。在 GPU 上已经支持了海光的 DCU， 其他厂商的正在做适配。在 NPU 上也对华为 Ascend 做了支持，其他的也会陆续引入。

（2）超大模型训练推理。目前已经针对云端的一些平台研发了训练的算子库。同时 PPL 也在 CUDA 层面，做了分布式推理的支持，已经支持了目前业界所有主流的以及公司内部的 CV 层面的超大模型。

（3）深度学习编译。PPL 支持的后端数量越来越多，我们希望能够把目前深度学习编译的技术应用到更多的后端支持上，一方面可以提升整个芯片支持的效率，另一方面也能够节省一部分的人力资源。同时也希望可以把我们的一些专家优化的经验能与深度学习编译相结合，去生成一些质量更优的代码的实现。另外，也是希望能够在非 AI 领域应用深度学习编译技术。

（4）AI For Science。除了常见的推理之外，我们也在关注 AI For Science 领域。AI For Science 可以从以下两个方面入手，一方面用 AI 去替代 Science 中的某一些模块，比如说 AlphaFold 等。目前我们做了大量的工作，已经完善支持了 AlphaFold 的一些推理。另一方面在 science 的领域，我们希望能够深入地了解科学计算的一些真实痛点，结合 HPC 领域的知识去做更好的支持。

以上就是我们后续的一些计划。

05

问答环节

Q1：PPL 支持动态 shape 吗？

A1：目前 PPL 对动态 shape 和动态图都是有做比较好的支持。

对于动态 shape，在推理之前我们会有一套 infer shape，infer type 的机制来保证可以根据不同的 shape 去做相应的调整。同时在我们的框架里面有动态内存池的概念，不仅可以支持动态 shape，也可以去支持动态图的特性，具体的 OpenPPL 里有相关的介绍，大家可以去关注一下。

Q2：隐式 GEMM 会不会为了算 index 导致耗时边长变多？

A2：我们可以通过一些离线计算的方式提前把索引计算给完成，然后存在一个 Look-Up-Table 中。在实际的卷积的 Kernel 里面，其实这个索引计算已经不再耗时了，而只是从这个 Look-Up-Table 中把对应的索引取出来，做一些非常简单的增量计算就可以保证我们完成这些索引的计算。所以这个是不耗时的。

尽量地简化核心循环里面的指令数量，保证核心循环里边只有 mma 的指令以及访存指令。

Q3：PPL.NN 在设计上是怎么屏蔽不同设备厂商的类型以及设备的型号的？

A3：PPL 的前端 Parser 是通用的，包括 IR 阶段是通用的。后端针对不同的架构完成 Runtime 的处理。所以不同的架构是分开的，模块化是非常明显的。所以能够很好的去处理不同设备厂商的类型以及设备的型号。

Q4：PPL 推理框架是否支持 torch script 模型？

A4：目前我们开源的 PPL 主要是以 ONNX 作为统一的接口，因为不想绑定任何一个训练框架。不同的前端接入到 PPL 的 IR 其实是非常简单的，内部也在评估是否要去接入更多的这种前端设计。目前我们开源出来的主要是对接 ONNX，还有 Caffe。我们也是提供了一个把不同的模型转到 ONNX 的接口，希望能够支持更多的模型。后续的话，我们会有一个更宏大的统一的计算平台的概念出来，这样我们这个 IR 的概念会更完善一些。

Q5：CUDA 的优化技术也有应用到移动端的 GPU 吗？

A5：优化的算法本身是可以在不同的平台之间相互借鉴的，但优化的细节可能是不同的。比如说 tuning 的过程以及模块化的过程，包括分块这些是可以相互借鉴的。但里面内部优化的一些技巧可能是不同的，包括 memory hierarchy 的不同，计算访存比的不同。但整个优化的技术思路是可以应用到移动端的 GPU 的。我们内部不同架构层面之间的交流也是非常多，不同的优化算法之间也是可以用到不同的后端的。

Q6：很多设备厂商，比如 Ascend、寒武纪都有自己的深度学习框架，PPL 会跟它们对标性能吗？

A6：我们跟它们肯定不是竞争的关系。目前厂商推出的这些深度学习框架，或者推理框架，更多的是面向一些通用的模型，通用的网络或者通用的算子，它并不能完善地支持所有的模型。尤其公司内部的一些业务模型其实是非常复杂的，我们很难把所有的模型都直接部署到厂商推出的深度学习框架。所以针对不同的应用场景，结合公司的一些诉求，PPL 自主研发针对不同平台的推理框架。我们也希望能够跟更多的厂商去合作，去共建这个生态。

当然因为目前算法发展地越来越快，很多半导体厂商们做的框架也会越来越完善。我们也会尽可能地去吸收他们的优点，同时也会在上面做一些自研的工作，来保证最大化的发挥他们的硬件性能。

今天的分享就到这里，谢谢大家。

▌2023数据智能创新与实践大会

数据架构/数据效能/智能应用/算法创新......

4大体系，专业解构数据智能

16个主题论坛，覆盖当下热点与趋势

70+演讲，兼具创新与最佳实践

1000+专业观众，内行人的技术盛会

点击下方链接了解详情：

DataFunCon2023（北京站）：数据智能创新与实践大会