零侵入、极简适配！飞桨CINN实现类CUDA硬件“即插即用”
简介
继飞桨框架3.1版本推出“插件式 CUDA兼容类硬件接入方案”（飞桨实现插件式硬件图接入方案，模型推理加速2.2倍），实现运行时（Runtime）与算子（Kernel）的高效复用后，飞桨成功打通了PaddleCustomDevice仓硬件使用神经网络编译器CINN（Compiler Infrastructure for Neural Networks）的链路。新方案通过C接口隔离与动态链接机制，实现了CINN编译器与硬件底层编译工具链的彻底解耦。CUDA兼容类硬件（如天数、沐曦等）仅需实现标准化接口，即可“即插即用”地接入CINN，充分享受飞桨框架编译器带来的图优化与算子自动生成等核心技术红利（即：彻底告别手写底层代码，不仅实现模型端到端训练提速27.4%，更在科学计算的微分方程求解场景下，取得了比PyTorch快115%的压倒性优势统一多场景自动编译加速——支持动态shape场景，一套架构搞定训推需求）。
飞桨多硬件统一适配方案
01
整体架构概览：分层解耦，动态挂载
本方案在架构设计上延续了飞桨CustomDevice插件式接入的核心思想，将整个链路严格划分为“CinnCustomDevicePlugin 框架接口层”、“C_CinnInterface C接口桥接层”、与“C_DeviceInterface厂商插件层”。
CINN编译器实现CUDA兼容类硬件插件式接入方案
02
核心实现：框架与插件的“双向奔赴”
为了实现上述架构，飞桨核心仓与PaddleCustomDevice硬件插件仓进行了清晰的分工与接口对齐。
01
框架侧（Paddle Repo）：定义标准与抽象封装
框架侧通过抽象接口定义了标准的设备交互规范，消除了对任何特定硬件后端的依赖。
核心接口定义(C_CinnInterface)：定义了三大类跨语言C接口：
Compiler Toolchain（编译工具链）：包含compile()用于调用外部编译器，get_runtime_source()获取设备端运行时源码。
Runtime Strategy（运行时策略）：包含module_load/unload()用于加载和卸载编译后的模块，get_kernel_address()寻址函数，以及launch_kernel()启动执行。
Compile Strategy（编译优化）：提供apply_custom_pass()允许厂商应用自定义的IR（中间表示）优化Pass。
C++抽象接口与桥接层：在custom_device_backend_api.h中，定义了 CustomCompilerToolchain 和 CustomRuntimeStrategy 等高层抽象类。通过 CinnCustomDevicePlugin 获取插件实例，并在桥接层将框架的 C++ 调用安全地转换为对 C 接口的调用。
02
插件侧（PaddleCustomDevice Repo）：动态注册与能力映射
硬件厂商（以类CUDA硬件为例）只需在自定义插件仓中实现对应的逻辑，并通过动态库的形式供飞桨加载。
插件入口动态注册：在InitPlugin()中不仅填充设备管理、显存、通信等基础接口，还通过调用InitCinnInterface()将底层实现挂载到C_CinnInterface上。
编译器与运行时实现：
编译阶段：通过实现CustomDeviceCompile，调用厂商自研编译器（如天数的IXCC,沐曦的MXCC）将源码编译为二进制格式。同时注入设备端需要的Runtime Source（如特定的math函数或reduce原语）。
运行阶段：完美兼容CUDA Driver API范式。例如CustomDeviceModuleLoad底层直接映射为加载编译模块（类似cuModuleLoad），CustomDeviceLaunchKernel映射为执行（类似cuLaunchKernel）。
03
一览全景：模型执行的调用链路
当用户模型在支持CINN的环境下运行时，一条清晰的调用链路被瞬间激活，数据与指令在框架与硬件之间高效流转：
01
编译期(CINN Compiler)：
首先是编译期的深度优化与底层代码生成。飞桨框架的前端在完成基础的图优化后，会首先进入由硬件主导的深度定制阶段。此时，框架会调用compile_strategy->ApplyCustomPass，触发名为apply_custom_pass的C接口。通过该接口，系统动态加载并执行硬件厂商自定义的IR Pass（中间表示优化）与Schedule（调度编排）策略，充分针对特定硬件的寄存器与访存层级进行极致的算力压榨。
在经历层层定制优化后，系统进入Codegen（代码生成）环节，将优化后的中间表示转化为结构化的底层代码。最后，框架获取对应的编译工具链并调用Compile方法，进而触发compile C接口，直接唤醒硬件厂商自研的底层编译器（例如天数的IXCC和沐曦的MXCC），由它负责将这些代码最终翻译成目标硬件能懂的高效二进制机器码。
02
加载期：
紧接着进入加载期。机器码生成后，框架的运行时策略模块会主动调用LoadModule方法，这会向下触发module_load这一C接口。该接口的作用是指示底层驱动将刚刚编译好的二进制模块妥善载入设备的显存空间，其底层行为完全对标并兼容CUDA中的cuModuleLoad操作。
03
执行期(Engine)：
最后是真正的执行期。当模型运行到具体的计算节点时，飞桨的执行器会先从加载好的模块中精准寻址，提取出对应的函数指针。随后，框架调用LaunchKernel方法，该调用最终被映射到底层的launch_kernelC接口上，在物理硬件层面上真正拉起计算内核的执行（如同执行cuLaunchKernel）。
04
适配成本与代码量对比
基于本方案，对于CINN编译器的硬件适配，研发门槛和代码开发量实现了显著降低。以往采用内置侵入式方案，需要直接修改飞桨核心代码仓，初次跑通往往需要在核心框架内硬编码数千行C++代码。而目前沐曦、天数智芯等厂商已采用全新插件式接入方案，硬件后端与飞桨主仓解耦。厂商仅需利用自有编译器（如天数智芯的IXCC、沐曦的MXCC），在PaddleCustomDevice独立仓中实现数十行纯C接口的映射挂载和几百行对应实现，即可沿用CINN的基础Schedule、Pass和Codegen逻辑，激活CINN基本访存密集型算子融合能力。相比之下，该方案能极大降低编译器底层的技术壁垒，大幅加速新硬件生态落地飞桨。在真实的工程落地中，底层编译适配工作实现了从“月级”到“周级”的跨越。如今（以天数智芯和沐曦为例）无需侵入式修改Paddle仓，仅需不到一周即可完成基本接入。
以沐曦为例：/work/PaddleCustomDevice/backends/metax_gpu/cinn/cinn_interface.cc中
#include "cinn_interface.h"namespace paddle {namespace custom_device {namespace metax {// ============================================================// 外部函数声明 (External Function Declarations)// 这些函数需要在对应的子目录文件中实现 (.cc)// ============================================================// --- 来自 compiler/compiler.cc ---// 负责调用 mxcc 将 CINN 生成的源代码编译为二进制extern C_Status MetaxCompile(void* dev_ptr, const char* code, char* out_path, size_t len);// 负责提供沐曦 GPU 运行时的基础源码 (类似 cuda_device_runtime.cu)extern const char* MetaxGetRuntimeSource(void* dev_ptr);// --- 来自 runtime/cinn_runtime.cc ---// 负责加载编译好的二进制模块 (.mx / .so)extern C_Status MetaxModuleLoad(void* dev_ptr, const char* path, void** mod_out);// 负责卸载模块extern C_Status MetaxModuleUnload(void* dev_ptr, void* module_handle);// 负责从模块中查找核函数地址extern C_Status MetaxGetKernelAddress(void* dev_ptr, void* module_handle, const char* func_name, void** func_out);// 负责启动核函数 (Launch Kernel)extern C_Status MetaxLaunchKernel(void* dev_ptr, void* func_ptr, void** args, int num_args, int gx, int gy, int gz, int bx, int by, int bz, int shm, void* stream);// --- 来自 passes/pass_manager.cc ---// 负责应用自定义的图优化 Pass（由框架在遇到未知 Pass 名时回调）extern C_Status MetaxApplyCustomPass(void* dev_ptr, const char* pass_name, void* ir_module);// 返回 MetaX GPU 的有序 Pass 执行列表extern C_Status MetaxQueryPassPipeline(void* dev_ptr, char pass_names[][128], int* count);// ============================================================// 接口初始化实现 (Interface Initialization)// ============================================================static C_CinnInterface metax_cinn_impl;void InitCinnInterface(C_DeviceInterface* device_interface) { // 1. 安全起见，先清零 std::memset(&metax_cinn_impl, 0, sizeof(C_CinnInterface)); // 2. 设置结构体大小 (用于版本校验) metax_cinn_impl.size = sizeof(C_CinnInterface); // 3. 设置上下文指针 (可选) // 如果你的实现需要全局状态，可以指向一个结构体；否则设为 nullptr metax_cinn_impl.dev_ptr = nullptr; // 4. 挂载 Compiler Toolchain 接口 metax_cinn_impl.compile = MetaxCompile; metax_cinn_impl.get_runtime_source = MetaxGetRuntimeSource; // 5. 挂载 Runtime Strategy 接口 metax_cinn_impl.module_load = MetaxModuleLoad; metax_cinn_impl.module_unload = MetaxModuleUnload; metax_cinn_impl.get_kernel_address = MetaxGetKernelAddress; metax_cinn_impl.launch_kernel = MetaxLaunchKernel; // 6. 挂载 Compile Strategy 接口 metax_cinn_impl.apply_custom_pass = MetaxApplyCustomPass; metax_cinn_impl.query_pass_pipeline = MetaxQueryPassPipeline; // 7. 将填好的表挂载到 Paddle 主设备接口上 if (device_interface) { device_interface->cinn_interface = &metax_cinn_impl; VLOG(3) << "[MetaX] CINN Interface initialized successfully."; } else { std::cerr << "[MetaX] Error: device_interface is null during CINN init." << std::endl; }}} // namespace metax} // namespace custom_device} // namespace paddle通过插件式方案，硬件厂商可以“免费”继承飞桨沉淀多年的前沿技术——无论是复杂的计算图优化、访存密集型算子融合，还是未来针对大模型生成的动态Shape优化。彻底省去了深入理解飞桨CINN前后端复杂IR机制的工作，只需专注打磨自身的闭源编译器引擎。飞桨将持续深化这套异构计算底座，让每一片国产芯片都能以极低的门槛接入顶级AI生态，共同释放大模型时代的澎湃算力！
总结
CINN编译器插件式接入方案的落地，标志着飞桨在多硬件适配的深度与广度上迈出了坚实的一步。这种设计不仅解耦了Paddle核心与厂商底层的实现细节，更让国产硬件生态能够以极低的门槛接入飞桨编译器的核心能力体系，共同为开发者带来极致的性能体验。未来，飞桨将继续携手广大硬件生态伙伴，基于此方案探索更深度的动态Shape优化与算子定制，为开发者提供更高效、更灵活的AI基础设施。
关注【飞桨PaddlePaddle】公众号
获取更多技术内容~