仅用于站内搜索，没有排版格式，具体信息请跳转上方微信公众号内链接
简介
飞桨框架自发布之初就考虑了多硬件适配的需求，历经多轮架构迭代与技术演进，在飞桨框架3.0版本中打造出业界领先的多硬件统一适配方案。该体系以“分层解耦、多元接入”为设计理念，构建起四维创新优势：
接口抽象层革新
通过硬件接口抽象，降低硬件适配成本。涵盖设备管理、计算执行、分布式通信等核心模块。以昇腾芯片适配为例，初步跑通所需适配接口数比PyTorch方案减少56%，适配代码量减少80%。
插件式架构设计
基于标准化适配接口构建松耦合架构，实现“即插即用”的硬件接入模式。各类芯片仅需完成标准化接口的实现封装，即可无缝融入飞桨后端。这种模块化设计大幅简化接入流程。
多元化接入方式
针对不同硬件栈的成熟度差异，飞桨提供了丰富多样的接入方式，涵盖算子开发、算子映射、图接入、编译器接入等。
生态协同机制
与芯片厂商建立协同创新模式：官方代码合入通道保障技术演进，持续集成测试体系筑牢质量根基，例行发版实现快速迭代。配合每日功能与精度监控机制，为开发者提供生产级稳定保障。
飞桨多硬件统一适配方案
在一些场景（如OCR场景）下，模型中部分结构的算子数量较多，但运算量较少，CPU调度操作频繁，造成资源浪费。对这类问题，硬件厂商通常会对其中的图结构进行自定义的编译优化，以降低资源损耗。为了让开发者更好地使用硬件厂商的这一能力，飞桨框架3.0基于新一代中间表示（PIR），升级扩展了图引擎接口，并创新推出了插件式硬件图接入方案。该方案支持硬件厂商高效实现自定义的图优化，充分利用硬件在图执行上的优势，提升模型的训练和推理性能。更重要的是，通过这种插件式的适配方式，硬件厂商可以更加灵活地实现功能分离，显著降低与飞桨协同开发的成本。
插件式硬件图接入方案介绍
PART01
方案设计思路
模型训练和推理过程可以抽象为计算图的结构。在这个结构中，各个节点代表具体的操作，而边则描绘了数据在这些操作之间的流动路径（如张量在神经网络层间的传输）。如图所示，一个模型中拥有不同的OP，图接入方案需要支持将其中的部分OP融合为一个子图OP，以提高模型的执行效率。这个子图OP随后会被交付给硬件进行处理，完成一系列构建、编译和优化等操作，最终生成可执行的硬件kernel文件。当模型在实际运行时，它就可以调用这个硬件kernel来完成原本需要多个步骤才能完成的计算任务。
PART02
硬件与框架主仓的链接方式
如图所示，飞桨通过加载动态链接库的方式，将硬件厂商实现的硬件运行时方法和图优化方法链接到飞桨调度执行模块中：
图中绿色是自定义运行时相关方法与主仓的链接接口，通过LoadCustomRuntimeLib将CustomDevice仓库定义的硬件启动/管理、内存分配管理、分布式通信、流启动管理方法接入到主仓；
图中橘色是自定义图优化相关方法与主仓的链接接口，通过LoadCustomEngineLib将CustomDevice仓库定义的IR转换、子图构造、子图执行、子图OP注册方法接入到主仓。
自定义图优化方法属于可选项，硬件厂商可以根据需求实现对应方法。实现后相关方法后，按照pass执行先后顺序传递给环境变量FLAGS_enable_custom_engine=”translate_pass1,translate_pass2”在运行模型时开启子图功能。
PART03
硬件厂商适配工作
硬件厂商在CustomDevice仓库中实现图优化方法以供飞桨加载调用，开发内容主要包括图注册管理体系和图编译执行体系两个部分。
图注册管理体系
定义用于描述硬件的子图的xxx_engine_op相关方法，实现register_custom_engine_op()接口，完成子图OP注册（该函数会在初始化硬件时执行）。
实现translate_pass支持pir_program中的图处理功能，实现将飞桨OP转换成xxx_engine_op的功能（该pass会在飞桨静态图执行器前处理中通过Flag控制调用）。
图编译执行体系
PART04
适配后的图执行流程
硬件厂商适配上述方法后，模型执行中使用图优化执行流程如下：
在飞桨初始化时，会将硬件厂商定义的子图OP注册到飞桨IR体系中，使得能够在PIRProgram中构建该OP；
模型训练通过动转静方式，推理通过模型文件加载的方式得到未经过图优化的静态图的PIRProgram，飞桨执行器调用硬件厂商定义translatePass将硬件可识别的OP圈定为子图OP（custom_engine_op）；
更多细节请参见
https ://github.com/PaddlePaddle/PaddleCustomDevice/blob/develop/Guides/pir_plugin_subgraph.md
方案收益介绍-以燧原GCU为例
PART01
性能收益表现
燧原是首个通过本方案接入其图引擎优化能力的硬件厂商，以ch_ppocr_mobile_v2.0_cls_infer模型推理为例，采用图优化执行方案较传统无图优化方案每秒推理次数（IPS）提升了2.2倍。
测试样例
测试结果
PART02
性能收益来源
Host层
由于子图机制将多个OP融合为一个OP（OP数量从551个下降到8个），大幅减少了CPU启动硬件kernel的次数，有效减少CPU调度硬件OP的开销。
Device层
对于一个融合后的OP，真正执行时需要多个硬件kernel完成，厂商通过kernel融合技术将部分硬件kernel融为一个，减少了engine_op内部的硬件kernel数量（从159个下降到58个)，从而减少了硬件调度开销和kernel执行的IO开销。
对于融合后的硬件kernel，硬件厂商可以采用加载已有kernel动态库，或即时生成高性能kernel并编译的方式完成单个kernel的运行。其中kernel内可以结合硬件的配置进行向量化，循环融合等优化方法获得高性能。
PART03
持续优化
后续仍可基于图执行机制扩展更多的应用场景，进行持续的优化，可优化方向如下：
子图支持更多OP，使得子图中容纳更多OP，进一步减少框架调度开销。
优化硬件kernel融合能力，支持更多硬件kernel融合，进一步降低硬件IO开销，提高内存复用率。
子图动态shape优化，扩展不同输入shape情况下的性能优化能力。
致谢
感谢燧原研发工程师（githubID：wanx7130、wzjseu）在该方案的制定过程中，提供了宝贵的意见。
关注【飞桨PaddlePaddle】公众号
获取更多技术内容~
