这两年PyTorch转TensorRT的部署路径我踩过的坑比写过的代码还多。早先做推理优化最头疼的就是手写插件和TensorRT的C API一个模型能从周四调到下周一。后来NVIDIA把Torch-TensorRT提出来宣称“PyTorch模型直接编译成TensorRT engine”我第一反应是这东西怕不是又一个脚本玩具。直到有次项目里要压一个YOLO类的检测模型实在没时间折腾ONNX导出再手动修动态shape硬着头皮把Torch-TensorRT接进管线结果这套静态编译工程把整个部署流程缩短了一大半我才重新审视它。这次评测我自己拉了源码数了数仓库里全部文件——整整5393个源文件含第三方依赖和测试生成、转换、libtorch扩展、运行时全链路都在里面。这篇文章我会从源码工程角度拆解Torch-TensorRT的静态编译机制讲清楚它是怎么把PyTorch的模型从libtorch的图表示一步步翻译成TensorRT能执行的engine也会把我在Ubuntu上编译、集成、踩坑的完整过程写出来。适合正在做Torch模型上线TensorRT的算法工程师或者想理解编译器型推理引擎内部结构、准备自己改一版的同学参考。1. 内容整体设计与思路拆解1.1 为什么Torch-TensorRT不按ONNX那条路走先聊设计思路。常见的PyTorch推理加速路线是torch.onnx.export导出ONNX再用trtexec或TensorRT Python API转engine。早期我也是这么干的但问题很明显——导出ONNX这个过程是动态的需要模型跑一遍trace遇到if分支、动态循环、某些python控制流trace结果跟实际推理行为可能对不上而且很多PyTorch算子导出来是一大堆小算子拼出来的TensorRT优化器再聪明也拼不回一个高效的融合内核。Torch-TensorRT的思路完全不同。它直接在PyTorch模型的torch::jit::Graph层面介入这个Graph是libtorch的静态图表示包含aten、prim等算子的指令序列。Torch-TensorRT做的是把Graph里能被TensorRT支持的子图识别出来用TensorRT的NetworkDefinition重新描述编译成engine然后嵌入回原Graph里变成一个自研的TensorRTEngine节点剩下的PyTorch节点继续走libtorch执行。这种方案有几个好处不用折腾ONNX导出精度损失少因为是图和图之间的转换能保留PyTorch的动态shape信息还可以利用libtorch的自动求导和TensorRT的层融合形成混合执行。所以它的整体设计不是为了替代TensorRT C手写网络而是让已经有PyTorch模型、又不想重构推理代码的人用最小代价拿到TensorRT的加速收益。1.2 5393个源文件到底多不多里面都是什么我拉的是rel-5.0左右的taggit ls-files | wc -l数下来是5393。不少人看到这个数字会懵觉得一个编译插件而已怎么会有五千多个文件。其实这五千多个文件是“仓库全量”包括三块Torch-TensorRT自己的核心代码、随仓库一起管理的第三方头文件googletest、pybind11、half等、C和Python的单元测试与工具脚本。剥掉第三方的代码Torch-TensorRT自己的源码文件大概在几百个量级但即便如此对于一个“编译器”来说这个规模不算夸张——毕竟它内部要做算子解析、图切分、类型推断、TensorRT网络构建每一块都得有对应的实现。我自己统计了一下源码部分的结构分布目录 / 模块大致文件数作用core50分区规划、编译配置、执行上下文、插件基础conversion300PyTorch算子到TensorRT层的转换器包括aten和prim的lowercompiler100图切分、连接器、输入输出张量处理runtime20engine执行、TensorRTContext、Profilinglogging10日志、Verbose级别控制cpp/api30对外C APItorch_tensorrt::Compile等py40Python绑定和工具入口tests200C和Python的测试用例含第三方测试基础设施这里最核心的是conversion目录它决定了一个operator能不能被转换以及转成什么样的TensorRT层。而compiler目录则是整个编译器的“调度中心”算子能不能切分、怎么拼成子图都是这里定的。1.3 静态工程评测的含义标题里说的“静态工程评测”指的是我从源码角度去做一次“编译期工程体检”不是只跑个benchmark然后告诉你“快了多少倍”。一个部署工具能不能在真实项目里站稳要看它能不能被可靠地编译出来能不能在升级PyTorch或TensorRT时稳定构建出问题的时候能不能通过分析源码快速定位。这些都需要把整个工程的构建逻辑、符号依赖、ABI边界搞清楚。问题是绝大多数用Torch-TensorRT的人只用了Python接口torch_tensorrt.compile(...)一行调用完事完全看不到背后发生了什么。而当你开始要集成到C服务、或要裁剪掉不需要的算子、或要静态链接进一个不能带额外APT依赖的生产镜像时就必须回头啃源码工程。这也是我写这篇评测的原因把“从PyTorch到TensorRT的编译之路”从口号变成可操作的工程路径。2. 核心细节解析与实操要点2.1 顶层构建脚本与依赖关系Torch-TensorRT的编译和很多C项目不太一样它同时使用了CMake和Python的setuptools两套体系。CMake负责构建核心库libtorchtrt和运行时libtorchtrt_runtimePython绑定则通过py/setup.py来调用CMake生成.whl包。顶层CMakeLists.txt里有几个关键依赖检查find_package(Torch REQUIRED) find_package(CUDA REQUIRED) find_package(TensorRT REQUIRED)这三个缺一个都会直接失败。需要注意find_package(Torch)依赖的是你已经安装好libtorch也就是PyTorch的C分发单独的Python torch包并不能直接满足它。TensorRT也是一样需要把/opt/TensorRT-*/的路径设置到TensorRT_ROOT环境变量或CMake缓存里否则找到的可能是系统自带的旧版本。这里有个我自己踩过的坑如果同时装过多个Conda环境且用Conda装了pyTorchfind_package(Torch)可能会命中某一个环境的libtorch但Python解释器却是另一个环境导致编译出来的扩展模块链接到了不对的libstdc运行时就报undefined symbol。后来我统一用同一个Conda环境并且把-DCMAKE_PREFIX_PATH显式指到当前环境这个问题才算彻底解决。2.2 converter是怎么把PyTorch算子变成TensorRT层的转换器是整个工程里最能体现“编译思维”的部分。Torch-TensorRT在conversion/converters/下为每个支持的PyTorch算子注册一个convert函数核心接口长这样struct OpConverter { bool operator()(ConversionCtx* ctx, const torch::jit::Node* n, args args) const; };编译过程中Graph里每个节点都会被送到AlterContext、Tokenize等阶段然后根据节点的kind如aten::relu、aten::conv2d索引到对应的OpConverter。转换器要做的事情不只是1:1映射而是尽量把PyTorch里的张量格式转换成TensorRT能理解的格式。比如aten::conv2d在PyTorch里权重是[out_channel, in_channel, kh, kw]TensorRT的Convolution层也是一样的布局可以直接填但aten::max_pool2d就需要把ceil_mode、padding这些参数解析成TensorRT的PoolingDescription。更复杂的是aten::reshape这种PyTorch对shape有自动推断TensorRT层必须显式指定输出维度所以converter里专门有符号shape相关的计算逻辑。这类转换的坑在于不少PyTorch算子有多种重载比如slicing、advanced indexing哪怕converters里写了支持某些输入情况下仍然会走到fallback分支。我建议在编译前先用torch_tensorrt.compile的enabled_precisions和torch_executed_ops参数控制转换范围避免某些冷门算子把整个子图都拖成PyTorch执行。2.3 图切分和连接器不是所有节点都能编译一个Graph从头到尾全转TensorRT是不现实的。算子不全是小事更麻烦的是某些节点的输出需要多个下游节点消费切分没切好就破坏数据流。Torch-TensorRT采用了一种基于段的算法它先标记可以被转换的节点然后按照拓扑顺序把连续可转节点聚合成段Segment每个段内部变成一个TensorRTEngine节点段与段之间的张量通过TensorRTCustomPlugin或GPU显存拷贝衔接。这里有一个关键设计Segment节点里保存了编译好的engine、输入输出张量的名称和类型信息在运行时它就是一个普通的JIT节点libtorch调度到它时引擎就执行。所以编译产物实际上是一个混合的torch::jit::Module带上了若干TensorRT的engine。这个设计让我第一次觉得Torch-TensorRT的工程化程度不低。因为编译器生成的engine可以在推理进程中串起来用也可以序列化保存下次加载直接跑。连接器部分还处理了一件容易被忽略的事engine的输入输出张量shape需要对齐libtorch的shape动态shape模式下要用OptimizationProfile来设置最小、最大、最优尺寸。2.4 Python绑定与C API的差异Torch-TensorRT同时提供了torch_tensorrt.compile的Python接口和torch_tensorrt::Compile的C接口。两者的核心逻辑完全一致都是走compile流程但Python接口对使用者更友好可以传inputs为torch.Size或torch_tensorrt.Input对象指定动态shape范围可以设置enabled_precisions{torch.float16}开启FP16可以设置workspace_size。C接口的优势在生产环境更明显不需要启动Python解释器内存占用低引擎可以打包到C服务里。我在一个OCR服务里就用了C API直接把compile出来的torch::jit::Module塞进Triton后端省掉了一层Python进程间通信。不过在写C代码时要注意头文件的包含顺序和链接库下面是一个最小示例#include torch_tensorrt/torch_tensorrt.h #include torch/script.h auto mod torch::jit::load(model.ts); std::vectortorch_tensorrt::Input inputs; inputs.push_back(torch_tensorrt::Input({1, 3, 640, 640})); auto trt_mod torch_tensorrt::Compile(mod, {inputs}, torch_tensorrt::CompileSpec()); torch::jit::save(trt_mod, model_trt.ts);这里有个细节CompileSpec如果不设置torch_tensorrt::Type默认会编译成FP32如果想用FP16要在CompileSpec里加一行spec.enabled_precisions {torch_tensorrt::DataType::kHalf};2.5 静态编译的产物形态编译成功后Torch-TensorRT生成的还是一个torch::jit::Module内部藏了TensorRT engine。序列化时engine会被以自定义格式塞进zip归档。反序列化时Torch-TensorRT的JIT扩展会识别出这些节点并恢复engine。这里需要注意ABI兼容问题序列化的engine跟TensorRT版本强绑定你用TensorRT 8.6编译出来的.engine到TensorRT 9.0环境里不一定能直接加载。Torch-TensorRT也会做版本检查但我在实测中碰到过只给警告、还能跑的也碰到过直接报Unrecognized Engine Format的。这提醒我们Triton或生产镜像里的TensorRT版本要和编译环境保持一致最保守的做法是把TensorRT的so一起打进镜像。3. 实操过程与核心环节实现3.1 环境准备别用最新版强行组合写这篇评测时我用的是这套组合算是比较稳定组件版本操作系统Ubuntu 22.04CUDA11.8cuDNN8.6.0TensorRT8.6.1PyTorch2.1.0Torch-TensorRTrel-5.0GCC11.4这里想多说一句PyTorch 2.x以后libtorch的C ABI变化较大Torch-TensorRT官方也说要按release分支匹配对应PyTorch版本。与其整天追新不如锁一套组合。编译时尽量用conda环境避免系统Python干扰。我的创建命令是conda create -n trt python3.10 conda activate trt conda install cmake ninja pip install torch2.1.0 tensorrt8.6.1TensorRT的Python包和C库是分开的Python包装完不代表C库可用。我是从NVIDIA官网下载TensorRT 8.6.1的tar包解压到/opt/TensorRT-8.6.1然后设环境变量export TensorRT_ROOT/opt/TensorRT-8.6.1 export LD_LIBRARY_PATH$TensorRT_ROOT/lib:$LD_LIBRARY_PATHlibtorch的路径则由torch.utils.cpp_extension自动探测大家也可以直接用下面命令确认python -c import torch; print(torch.utils.cmake_prefix_path)如果打印出来是空说明PyTorch安装有问题CMAKE_PREFIX_PATH必须手动指向包含share/cmake/Torch的目录。3.2 从源码构建Torch-TensorRT的完整步骤先克隆仓库并切换taggit clone https://github.com/pytorch/TensorRT.git cd TensorRT git checkout rel-5.0 git submodule update --init --recursive第三步绝对不能省。仓库里的third_party和部分测试依赖是通过submodule管理的不拉全会出现编译头文件缺失、甚至pybind11都找不到。接下来用CMake直接构建mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease \ -DCMAKE_PREFIX_PATH$(python -c import torch; print(torch.utils.cmake_prefix_path)) \ -DTORCH_TENSORRT_DIR$(pwd)/.. \ -DCMAKE_EXPORT_COMPILE_COMMANDSON make -j$(nproc)这样做出来的只是libtorchtrt.so和libtorchtrt_runtime.so。想拿到Python包还需要在py目录下构建cd ../py python setup.py installsetup.py会自动调用CMake并把生成的so拷到torch_tensorrt的包目录。我之前遇到过一个坑如果在py目录里没有把TensorRT_ROOT设对setup.py能找到TensorRT Python包但找不到C库最后报错是Could NOT find TensorRT。解决办法是执行前重新export一次。整个编译过程16核的机器大概需要10到15分钟首次编译会包含大量模板和protobuf代码如果改成-j2可能跑半小时以上耐心等就行。3.3 关键CMake开关解析Torch-TensorRT的CMake提供了很多可配置项这里挑几个常用的说明选项默认用途TORCH_TENSORRT_BUILD_PLUGINSON是否构建自定义插件一般保持ONTORCH_TENSORRT_BUILD_RUNTIMEON是否构建运行时库部署时一般ONTORCH_TENSORRT_BUILD_TESTSON构建测试用例评测时可开生产可关TORCH_TENSORRT_USE_GPU_FOR_METALOFF某些算子用GPU辅助实现可忽略CMAKE_BUILD_TYPERelease用ReleaseDebug编译出的库体积大且慢CUDA_ARCH_LIST空指定目标显卡架构如8.6、8.9默认会探测但可能不准构建精简版时我建议至少关掉testscmake .. -DTORCH_TENSORRT_BUILD_TESTSOFF -DTORCH_TENSORRT_BUILD_BENCHMARKSOFF这样能省不少编译时间。3.4 实测编译一个模型的效果选了一个ResNet50和YOLOv8s做实测。先用PyTorch导出TorchScriptpython traces/export_resnet.py然后用Python API编译FP16版本import torch import torch_tensorrt as trt model torch.jit.load(resnet50.ts) inputs [trt.Input((1, 3, 224, 224))] compiled trt.compile(model, inputsinputs, enabled_precisions{torch.float16}) compiled.save(resnet50_trt.ts)之后加载推理对比精度compiled torch.jit.load(resnet50_trt.ts) warmup torch.rand(1, 3, 224, 224).half() for _ in range(10): compiled(warmup) print(compiled(warmup).detach().cpu().float())实测FP16相比PyTorch的FP32在批量1下ResNet50能到1.8到2.3倍加速YOLOv8s能到1.5到1.9倍具体取决于显卡。这里提醒一下如果你的模型里有非TensorRT支持的算子比如一些高级的index_put、scatter操作可以用torch_executed_ops参数指定让这些算子继续用PyTorch执行compiled trt.compile(model, inputsinputs, enabled_precisions{torch.float16}, torch_executed_ops{aten::index_put})我把这种编译方式理解为“混合编译”。它在工程上很有用不需要因为一两个冷门算子就放弃整张图的TensorRT优化。3.5 C推理端接入实际部署时我用C侧加载编译好的module。整体代码和加载普通TorchScript没区别唯一要注意的是必须链接torchtrt_runtime并且初始化时调用一下torch_tensorrt::torch_tensorrt_init()#include torch_tensorrt/torch_tensorrt.h int main() { torch_tensorrt::torch_tensorrt_init(); auto mod torch::jit::load(resnet50_trt.ts); torch::Tensor input torch::randn({1, 3, 224, 224}).to(torch::kHalf).to(at::kCUDA); auto output mod.forward({input}).toTensor(); return 0; }这里有个看起来不起眼、但特别容易出问题的地方输入张量的dtype和device必须和编译时一致否则引擎会拒绝执行或静默做一次host-device拷贝性能直接崩掉。我之前就因为在Python里编译时用的是FP16C端忘了to(at::kHalf)跑出来的延迟是正常情况的3倍后来在Nsight Systems里才发现有大量H2D拷贝。4. 常见问题与排查技巧实录4.1 编译时报TensorRT头文件找不到错误信息类似Could NOT find TensorRT (missing: TensorRT_INCLUDE_DIR TensorRT_LIBRARY)排查思路就三步。先检查TensorRT_ROOT是否正确echo $TensorRT_ROOT ls $TensorRT_ROOT/include/NvInfer.h然后确认PATH里的TensorRT Python包是否来自同一个tar包解压目录。最后看CMake缓存清掉build/CMakeCache.txt重新configure。这里有个诀窍如果系统里有多个TensorRT版本直接在CMake命令里指定-DTensorRT_ROOT/opt/TensorRT-8.6.1可以避免find_package去找系统默认路径。4.2 链接阶段出现一堆libtorch相关未定义符号这个问题多数是因为CMAKE_PREFIX_PATH没指对。你本地可能有多个Python环境编译器找到了一个分支的PyTorch头文件但链接时用的是另一个分支的libtorch.so。最好是开着conda环境然后config cmake时打印确认python -c import torch; print(torch.utils.cmake_prefix_path); print(torch.__version__)然后确保-DCMAKE_PREFIX_PATH指向这个路径。另外如果系统的libstdc.so版本太老也会报一堆乱七八糟的符号错误建议用较新的GCC和libstdc。4.3 运行时提示“Unable to parse .ts file”或engine不兼容反序列化TorchScript时Torch-TensorRT会加载engine数据。如果你跨TensorRT大版本反序列化最常见的是Error: EnginePtr is null。这种问题很难靠代码绕过去因为engine二进制格式本身不保证跨版本兼容。解决方案就是统一环境的TensorRT版本并在加载前打印Torch-TensorRT和TRT版本import torch_tensorrt as trt print(trt.__version__) print(trt.compiler.engine.get_tensorrt_version())4.4 模型编译速度极慢或内存暴涨TensoRT编译会把图中每个候选子图都经过规划、张量推断和层选择遇到超大模型或动态shape维度过多时编译期内存可能涨到十几GB。我遇到过YOLO大模型动态shape配置了4个profile编译到一半被杀。这种场景可以减少OptimizationProfile只保留一个常驻尺寸关闭部分插件的复杂合并路径比如将torch_tensorrt.CompileSpec下的max_workspace_size调低比如1 301GB分段编译把模型拆成多个子模块分别转换再串联。4.5 常见问题速查表现象可能原因解决方向CMake找不到PyTorchCMAKE_PREFIX_PATH未指定设置到torch.utils.cmake_prefix_path输出路径编译报NVInfer.h缺失TensorRT_ROOT没设置设置TensorRT_ROOT并验证头文件存在链接报libtorch符号缺失多个环境混用用统一conda环境并清理CMakeCache重编编译后Python import失败扩展模块ABI不匹配重新安装torch、检查GCC版本、重编whlengine加载失败版本不统一对齐TensorRT版本或重新编译推理延迟异常高输入dtype/device不一致检查输入张量是否FP32、是否在GPU上批量shape变化报错动态shape配置覆盖不全设置合理的OptimizationProfile5. 影响范围从PyTorch到TensorRT的编译之路5.1 静态编译vs PyTorch动态执行把Torch-TensorRT放入整个模型上线流程里它改变的不只是推理速度而是部署心态。PyTorch动态执行的优势是调试方便但上线时每个算子都有调度开销、显存碎片化和Python GIL等问题。而Torch-TensorRT把大部分计算吞进TensorRT engine内部一个子图就是一次调用省掉大量小算子dispatch开销还能获得TensorRT的layer fusion、kernel auto-tuning、FP16/BF16支持。但这不等于所有模型都适合转。我的经验是模型里卷积、全连接、矩阵乘、归一化、池化这类密集算子占比越高收益越明显。如果模型是大量自定义Python逻辑、稀疏计算、动态shape分支转换后可能大量fallback到PyTorch性能提升有限。所以评估一个模型是否值得走Torch-TensorRT先看可视化计算图里可转换算子的覆盖比例。5.2 TorchScript与动态shape的工程边界Torch-TensorRT本质上是拿TorchScript的图作为交换中间表示所以它对TorchScript的支持度直接决定转换成功率。PyTorch 2.x推荐用torch.export导出更稳定的图表示但Torch-TensorRT的集成层目前主要走torch.jit.trace或script。这意味着如果模型里有高度Python化的控制流trace会展开成固定分支可能影响动态shape能力如果模型包含大量nn.Module子类、动态列表、可变长序列script可能报TracerWarning或直接失败。所以我一般在写完模型后先做torch.jit.trace加载测试一遍再套Torch-TensorRT。尤其要注意输入尺寸不一致的问题最好用trt.Input(min_shape[1,3,224,224], opt_shape[1,3,640,640], max_shape[4,3,640,640])这种方式显式定义profile而不是让编译器猜。5.3 算子覆盖的实际影响Torch-TensorRT对onnx不关心它只关心PyTorch层面的算子。目前它对aten::conv2d、aten::linear、aten::batch_norm、aten::relu、aten::sigmoid、aten::mul、aten::add等常见算子的支持度很高对aten::scaled_dot_product_attention也有了对应转换。但对aten::empty_like、prim::If、某些字符串相关算子转换器就不一定能给TensorRT层了。工程上建议在编译前先看日志里的fallback提示。Torch-TensorRT会打印类似Unable to convert node: prim::If的信息。如果这类节点太多模型可能不适合转。也可以先用torch_tensorrt.ts.embed_engine_in_graph或命令行模式去分析。5.4 部署镜像和运行时依赖Torch-TensorRT的运行时依赖链包括libtorch、cudnn、cublas、TensorRT、CUDA runtime等。生产镜像里即使只用C API也要注意把libtorchtrt_runtime.so、TensorRT相关库、libtorch库一起带上。官方container镜像是个快捷方式但它体积很大。我试过用slim方案把libtorch的so瘦身到只有运行需要的部分再配合TensorRT的静态库链接大概能把基础镜像从3GB压到1.5GB左右。不过static link TensorRT需要获得对应版本的静态库文件而且所有第三方依赖也得静态编译工程复杂度会上去不少。5.5 实际项目中我建议的落地方式如果今天重新给线上项目选型我会这样设计先用TorchScript trace出模型确认无动态控制流问题用Torch-TensorRT的Python API在离线阶段编译FP16 engine把编译后的ts文件作为产物保存连同TensorRT版本号一起登记C服务加载ts文件输入输出张量严格保持一致用Nsight Systems监控是否有H2D/D2H拷贝、不必要同步和CPU算子拖尾。这套流程下模型上下线不需要改Python推理服务只要替换ts产物并做一遍精度回归就行。遇到算子不支持时再根据日志把对应Ops加入torch_executed_ops以最小的代价保留大部分TensorRT加速。6. 扩展思考与后续玩法6.1 自己定制converter的几个入口Torch-TensorRT允许注册自定义converter。如果你想把某个冷门算子转成TensorRT层源码里可以参考conversion/converters/下已有实现然后注册对应的schema。这里有一个小技巧先用ATen的custom_op在PyTorch里定义一个新算子然后在Torch-TensorRT里注册converter把它映射成TensorRT的plugin。这样模型里剩余逻辑可以照常走TensorRT自定义算子也能获得加速。当然这个开发量不小建议只在算子被频繁调用、严重影响性能时才做。6.2 与其他推理框架横向对比很多人会拿Torch-TensorRT和ONNX Runtime TensorRT EP对比。两者都能让PyTorch程序跑在TensorRT上但设计哲学不同ONNX Runtime是先导出ONNX再在ORT里执行中间有ONNX算子的翻译损耗Torch-TensorRT直接作用在TorchScript图没有ONNX这个中间层对PyTorch生态更贴近但和ONNX生态的互通性和工具链支持不如ORT。从评测角度说如果模型是纯CNN、算子简单两者差距不大如果模型有大量自定义模块、torchvision操作Torch-TensorRT通常更简单。反过来如果团队已有成熟ONNX部署管线没有必要为了Torch-TensorRT推倒重来。6.3 后续可以继续拆的方向这5393个源文件拆下来后面还有几个方向值得继续挖DLA支持、INT8校准流程、多GPU多stream的并发推理、插件op的C实现深度剖析以及动态shape下engine的优化策略。我自己打算下一篇专门写INT8量化编译时如何把torch_tensorrt和calibrator接在一起以及在校准时哪些层最容易掉精度。这可以作为这个主题的延续有兴趣的话后面继续更新。从fetch源码到亲手编译出resnet50_trt.ts这套链路走通之后我对Torch-TensorRT的信任度确实上升了一个台阶。它不是一个只会“转模型”的脚本工具本质上是一个以图编译思想为核心的推理编译器框架。遇到诡异问题不要慌先看编译器日志去conversion/converters/里翻对应算子的实现再去compiler目录看分段逻辑基本都能找到答案。我个人体会到的是工具链越深、越要敬畏编译期影响环境一致性是这条路上最大的敌人也是你躲不开的第一道坎。
