C++如何撑起人工智能框架？从内核引擎到工程落地-开发者社区

1. 为什么人工智能框架的内核都由C++主导

这些年只要聊人工智能，大部分人第一反应就是Python、Jupyter Notebook、PyTorch。而"用C++做AI"这个说法，听起来像是上个世纪的古董在念经。但真正上过生产环境的人心里都清楚：Python只是模型的导演，C++才是真正上台表演的演员。

我最早意识到这个问题，是在一次模型上线的时候。Python侧推理延迟只有几毫秒，看起来一切完美，结果一压并发，服务直接卡死。后来把模型推理换到了C++侧的推理引擎，同样的模型、同样的硬件，延迟和内存占用完全是两个档次。也是从那时候开始，我把"C++与人工智能框架"这件事从头梳理了一遍，发现网上资料虽然多，但大多是零散的环境配置教程或者面试八股，真正能把"C++在AI框架里到底起什么作用、怎么落地"讲清楚的很少。

先说一个基本判断：如果你只是想跑个demo验证想法，继续用Python完全没问题。但如果你要做的是服务化部署、端侧推理、高性能计算、对延迟敏感的业务，C++就是避不开的主赛道。这篇文章我会从框架内核讲到一个可复现的C++推理工程完整链路，再把环境搭建、崩溃排查、性能优化这些实操中一定会踩的坑都过一遍，最后聊聊算法功底和C++学习路线的关系。适合刚入门C++但想往AI方向走的同学，也适合已经在用Python做训练、但被迫接手C++部署任务的开发者。

1.1 Python只是外壳，C++才是真正的引擎

打开任意一个主流深度学习框架的源码仓库，你会发现目录结构非常有意思：顶层是Python的包管理文件，往下走全是C++的天下。以PyTorch为例，torch/csrc里是Python绑定层，aten/src/ATen是张量运算的核心库，c10是底层运行时，再往下是通过CUDA、cuDNN、oneDNN这些高性能库调用的算子实现。你用Python写一行tensor.mm(matrix)，背后至少经过了"Python解释器 -> pybind11绑定 -> C++张量分发 -> 底层BLAS/CUDA Kernel"四层跳转。

TensorFlow早期同样如此，核心计算图、Executor、Kernel都跑在C++上，Python只是前端描述语言。后来的TF Lite、TensorRT、ONNX Runtime这些推理引擎，干脆连Python这层皮都不要了，直接用C++ API暴露给上层。为什么？因为推理阶段追求的是确定性和极致性能，Python的动态特性和GIL在这种场景下全是拖累。

所以"C++与人工智能框架"这个命题，本质上不是在讨论"C++能不能做AI"，而是"AI框架的骨架本来就是C++写的，你怎么通过C++去接近计算本质"。理解这一点之后，你再去看那些热门的检索词——vscode配置c/c++环境、c#调用c++出现access violation c0000005、microsoft visual c++ redistributable——就明白了普通开发者在这个领域里真正困扰的其实是工程问题，是"怎么把C++环境弄好、怎么把C++库接进自己的项目"，而不是抽象的算法理论。

1.2 主流框架的C++接口怎么分工

当前要做的第一件事不是急着写代码，而是搞清楚你手头的任务该用哪套C++接口。我按实际生产中的使用频率列一张表：

框架/引擎	C++接口	典型适用场景	上手难度
PyTorch	LibTorch（torch::jit + torch::nn）	Python训练后需要无缝衔接C++推理	中等
ONNX Runtime	Ort C++ API	跨框架模型转换、通用推理、CPU/GPU多后端	低
TensorRT	TensorRT C++ API	英伟达GPU上的极致推理优化	高
OpenVINO	Inference Engine API	Intel CPU/GPU/VPU上的部署	低
OpenCV DNN	dnn模块	纯视觉任务快速集成	最低
TensorFlow	C++ API / TF Lite	老项目迁移、嵌入式端侧	中等

我个人的建议是：如果项目从零开始，优先考虑ONNX Runtime。原因很简单，它把ONNX作为中间表示，意味着你从PyTorch、TensorFlow还是Paddle训练出来的模型，只要导出成ONNX就能统一走一套C++推理逻辑。而LibTorch则是和PyTorch模型绑定最紧密的方案，适合不想做模型转换、只求快速上线的场景。TensorRT属于进阶选项，适合对推理延迟有苛刻要求的GPU服务，后面我会在性能章节单独展开。

2. 从训练到部署：C++推理链路的完整搭建

说完了框架生态，这块是硬通货。我拿一个实际做过的图像分类项目举例，把从PyTorch训练好的模型到C++完整推理跑通的链路逐步拆开。整个链路一共四步：模型导出、工程创建、推理代码编写、联调验证。这里面每一步都有细节，第四步最常见的崩溃问题我放到下一章专门讲。

2.1 模型导出这一步最容易翻车

很多人在部署环节翻车，根本原因不在C++代码，而在模型导出阶段就没做好。PyTorch导出部署模型有两条路：torch.jit.trace和ONNX导出，两条路我都走过，说几个关键要点。

先说torch.jit.trace，它是通过给模型喂一组样例输入，把执行路径记录下来编译成TorchScript。这个方案速度快，但有个致命弱点：它只会记录走过的数据流，遇到动态分支就废了。比如模型里有if x.shape[0] > 10:这种控制流，trace时只走了其中一个分支，导出来的模型在另一类输入上行为就是错的。应对办法是尽量用torch.jit.script，或者在trace之前把模型的动态逻辑改成静态可解析的形式。

ONNX导出相对友好，torch.onnx.export时会通过torchscript追踪在一起自动拆分，但仍需要手动指定input_names、output_names、dynamic_axes。这里有个容易被忽略的点：ONNX是静态图，动态shape必须显式声明。如果你在模型里的张量运算带有view、reshape这类会改变shape的操作，export时最好先固定输入尺寸，等C++侧验证通过后再打开dynamic_axes，否则排错时你会被一堆"shape mismatch"的报错淹没。

我自己常用的导出脚本骨架大概是这样：

import torch model = torch.load("model_weight.pth", map_location="cpu") model.eval() dummy_input = torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, "model.onnx", input_names=["input"], output_names=["output"], dynamic_axes={"input": {0: "batch"}, "output": {0: "batch"}}, opset_version=17, )

提示：导出时一定要model.eval()，并且关闭梯度。否则模型里若有BatchNorm、Dropout，推理时统计量和随机行为全乱套，但导出阶段不会报错，直到C++端跑出来的结果和Python对不上你才会发现问题。

2.2 CMake工程里如何正确链接推理库

模型文件就位后，进入C++工程搭建。这一步我强烈建议用CMake而不是Visual Studio直接建项目，因为C++推理库的依赖链条普遍很长，CMake的find机制能省太多事。

以ONNX Runtime为例，去GitHub的Release页面下载对应平台的压缩包，解压后目录结构是include/和lib/。在CMakeLists.txt里的配置方式：

cmake_minimum_required(VERSION 3.18) project(ai_infer_demo) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) # ONNX Runtime set(ORT_LIB_DIR "${CMAKE_CURRENT_SOURCE_DIR}/third_party/onnxruntime/lib") set(ORT_INC_DIR "${CMAKE_CURRENT_SOURCE_DIR}/third_party/onnxruntime/include") include_directories(${ORT_INC_DIR}) add_library(onnxruntime SHARED IMPORTED) set_target_properties(onnxruntime PROPERTIES IMPORTED_LOCATION ${ORT_LIB_DIR}/onnxruntime.dll IMPORTED_IMPLIB ${ORT_LIB_DIR}/onnxruntime.lib ) # OpenCV（可选，用于图像预处理） find_package(OpenCV REQUIRED) add_executable(infer_demo main.cpp) target_link_libraries(infer_demo PRIVATE onnxruntime ${OpenCV_LIBS})

这里有个Windows平台特有的坑：链接时必须把onnxruntime.dll放到最终可执行文件旁边，或者加到PATH里。很多人CMake配置看起来一切正常，编译也过了，一运行就报"找不到onnxruntime.dll"，就是这个文件没跟着走。我习惯在CMake里加一条自定义命令，构建完成后自动把dll拷贝到输出目录：

add_custom_command(TARGET infer_demo POST_BUILD COMMAND ${CMAKE_COMMAND} -E copy_if_different ${ORT_LIB_DIR}/onnxruntime.dll $<TARGET_FILE_DIR:infer_demo> )

2.3 完整推理示例：从读图到输出置信度

工程就绪后，核心推理代码其实不长。下面这段是一个完整的ONNX Runtime推理流程，包含图像预处理、前向推理、后处理三部分。我直接贴出关键代码：

#include <onnxruntime_cxx_api.h> #include <opencv2/opencv.hpp> #include <vector> #include <iostream> int main() { // 1. 初始化环境 Ort::Env env(ORT_LOGGING_LEVEL_WARNING, "infer_demo"); Ort::SessionOptions session_options; session_options.SetIntraOpNumThreads(4); // CPU线程数 session_options.SetGraphOptimizationLevel( GraphOptimizationLevel::ORT_ENABLE_ALL); // 开启图优化 // 2. 加载模型 Ort::Session session(env, L"model.onnx", session_options); // 3. 读取并预处理图像 cv::Mat img = cv::imread("test.jpg"); cv::Mat rgb, resized, float_img; cv::cvtColor(img, rgb, cv::COLOR_BGR2RGB); cv::resize(rgb, resized, cv::Size(224, 224)); resized.convertTo(float_img, CV_32FC3, 1.0 / 255.0); // HWC -> CHW，并归一化 std::vector<float> input_tensor_data(1 * 3 * 224 * 224); float mean[3] = {0.485f, 0.456f, 0.406f}; float std[3] = {0.229f, 0.224f, 0.225f}; for (int c = 0; c < 3; c++) { for (int h = 0; h < 224; h++) { for (int w = 0; w < 224; w++) { float val = float_img.at<cv::Vec3f>(h, w)[c]; input_tensor_data[c * 224 * 224 + h * 224 + w] = (val - mean[c]) / std[c]; } } } // 4. 构造输入Tensor并跑推理 std::vector<int64_t> input_shape = {1, 3, 224, 224}; Ort::MemoryInfo memory_info = Ort::MemoryInfo::CreateCpu( OrtArenaAllocator, OrtMemTypeDefault); Ort::Value input_tensor = Ort::Value::CreateTensor<float>( memory_info, input_tensor_data.data(), input_tensor_data.size(), input_shape.data(), input_shape.size()); const char* input_names[] = {"input"}; const char* output_names[] = {"output"}; auto output_tensors = session.Run(Ort::RunOptions{nullptr}, input_names, &input_tensor, 1, output_names, 1); // 5. 后处理：取top5输出 float* output_data = output_tensors[0].GetTensorMutableData<float>(); size_t output_size = output_tensors[0].GetTensorTypeAndShapeInfo() .GetElementCount(); std::vector<std::pair<float, int>> score_index; for (size_t i = 0; i < output_size; i++) { score_index.emplace_back(output_data[i], static_cast<int>(i)); } std::partial_sort(score_index.begin(), score_index.begin() + 5, score_index.end(), std::greater<>()); for (int i = 0; i < 5; i++) { std::cout << "class " << score_index[i].second << " score " << score_index[i].first << std::endl; } return 0; }

这段代码有几个设计上的讲究：预处理把HWC转CHW时，注意内存填充顺序要和训练时一致；归一化用均值标准差而不用简单的除以255，是因为训练侧预处理通常就是这样做的——训练和推理的预处理不一致，是导致推理精度暴跌的第一大原因，而且这种错误没有任何报错，只能自己对比找出。

我用LibTorch做推理时，代码长得很像，只不过把Session换成了torch::jit::load，输入直接构造torch::from_blob指向预处理后的数据。LibTorch的好处是和张量操作无缝衔接，坏处是库本身很大（Release版动辄几百MB），部署时对磁盘和内存都有压力。所以选型没有绝对最优，关键是匹配场景。

3. VSCode + Windows 下C++ AI开发的环境细节与崩溃排查

搜索热词里vscode配置c/c++环境、c#调用c++出现access violation c0000005、microsoft visual c++ redistributable能并列出现，说明大家在高频踩同一个系列的坑。这一章我专门把这些环境坑梳理清楚，因为环境不稳定，后面写多少代码都是白搭。

3.1 编译器、CMake、CUDA版本的三方匹配

Windows下做C++ AI开发，和你日常写业务C++最大的区别是：依赖链多了一层CUDA和GPU库。所以版本匹配就变成了"编译器版本 x CMake版本 x CUDA版本 x 推理库版本"四维矩阵。

先说编译器和CUDA的关系。CUDA toolkit里的nvcc编译器对不同MSVC版本有严格的支持范围，比如CUDA 11.x通常对应VS2019（MSVC v142），CUDA 12.x才开始原生支持VS2022（MSVC v143）。如果你用VS2022去编译一个需要CUDA 11的库，大概率会报unsupported Microsoft Visual Studio version。解决办法不是硬调CUDA版本，而是先确定推理库（TensorRT、LibTorch）要求哪个CUDA版本，再倒推编译器和VS版本。

CMake版本看似无关紧要，实则不然。老版本CMake的IMPORTED目标、BUILD_RPATH支持都有差异，而新版推理库的CMake配置文件经常使用较新的语法。我的建议是直接用最新稳定版CMake（3.27以上），同时配合Ninja生成器，比默认的Visual Studio生成器快不少，且路径处理更规范。

一个我踩过最深的坑：Debug和Release配置混用会导致链接错误或运行期内存崩溃。C++推理库的Release版依赖release版本的C运行时（/MD），而Visual Studio默认的Debug配置会链接到/MDd。两者混在一起，轻则链接报错LNK2038: mismatch detected for "RuntimeLibrary"，重则因为堆管理方式不同直接出现堆损坏。所以项目配置里Debug就统一用Debug版库（如果有的话），没有就全部走Release。

3.2 Access Violation C0000005 的根因与排查链路

c#调用c++出现access violation c0000005这个热词我太有共鸣了。C0000005就是Windows上的访问违规异常，翻译成人话就是"程序试图读写了没有权限的内存"。这个错误在C++调用链上出现的频率之高，几乎每个做跨语言集成的必遇一次。

以C#调用C++ DLL出现C0000005为例，我的排查链路是固定四步走：

第一步，确认平台的位数一致性。C#项目是AnyCPU（在64位系统上实际以64位跑），而C++ DLL是32位编译——这是C0000005最常见的来源。检查方式很简单，项目属性里看目标平台，DLL用dumpbin /headers查看机器类型。

第二步，确认调用约定一致。C++ DLL导出函数如果用__cdecl（默认），C#侧的DllImport里没有显式声明CallingConvention，默认会按StdCall去调用。参数出栈方式不一致，局部变量和返回地址全乱套，第一句访问就是崩溃。解决办法是在C++导出时统一加上__declspec(dllexport)并明确约定为__cdecl或StdCall，C#侧对应声明。

第三步，检查缓冲区边界。最常见的场景是C++函数内对传入的char*或字节数组越界写，比如代码里这么写：

extern "C" __declspec(dllexport) void ProcessData(const char* input) { char buf[64]; strcpy(buf, input); // input超过63个字节就爆了 }

C#侧的StringBuilder或byte[]没有预留足够空间，C++侧又没做边界检查，一越界就触发C0000005。这种问题编译期根本发现不了，只能靠代码审查或者给C++侧加防御性检查，strncpy_s是好习惯。

第四步，检查句柄跟对象的生命周期。C++ DLL内部缓存了一个指针或对象，C#侧反复调用时第一次正常第二次崩溃，基本就是C++侧的对象在第一次调用后已经被释放了。这种问题我见过不少人排查到怀疑人生，最后发现是自己在C++里delete了一个静态对象。

注意：遇到C0000005不要一上来就怀疑编译器或者库版本，先从位数、约定、边界、生命周期四个维度查，绝大多数问题都出在这四个地方。

3.3 Visual C++ Redistributable 到底该装哪个版本

再来说microsoft visual c++ redistributable。很多人不明白为什么明明代码编过了，换个电脑一跑就提示缺少VCRUNTIME140.dll或者MSVCP140.dll。这是因为C++程序编译时默认动态链接到VC运行时库，目标机器上必须装有对应版本的Redistributable。

Redistributable有版本和架构之分：VS2015-2022共用14.x系列运行库，安装包名字叫"Visual C++ 2015-2022 Redistributable"，分为x86和x64。我强烈建议开发机上x86和x64都装，否则x86的DLL和x64的DLL缺哪个都有可能冒出来。另外，不要用绿色版或者精简版运行库，直接去微软官方下载中心拿原版。有些机器装了多个版本，比如2013和2015-2022共存，这是正常的，它们互不覆盖。

如果你想确认一个DLL到底依赖了哪些运行库，可以打开"Developer Command Prompt"，用dumpbin /dependents your.dll查看。如果依赖列表里出现VCRUNTIME140D.dll，说明这个DLL是Debug版，需要装Debug CRT（一般开发机自带，目标部署机器上没有也正常）。部署机上永远不要放Debug版运行库，这是业内默认规矩。

4. 性能与稳定性：让推理框架在业务代码里真正跑得稳

环境通了、代码能跑了，这只是万里长征第一步。真实业务里你很快会面对三个问题：为什么我的推理延迟比Python还高？为什么内存一直在涨？为什么并发一上去就挂？这一章把这三件事一次讲透。

4.1 推理性能的四个关键瓶颈

先说一个最常见的误区：很多人以为把模型换成C++推理引擎，速度就自动起飞了。实际上，推理引擎本身的算子执行速度可能只占整个管线的一半时间，另一半全在预处理、张量拷贝、后处理这些"外围工作"上。

我实测过一个分类模型，单次推理的耗时分布大概是：图像解码与缩放（约30%）、HWC转CHW和归一化（约20%）、模型前向（约35%）、后处理top-k（约15%）。所以优化性能时先做profile，把时间花在最长的那一段上。

四个关键瓶颈依次是：

预处理并行度：OpenCV的cv::resize默认单线程，图像大时极慢。可以换成cv::resize+cv::parallel_for_，或者直接用IPP加速版。另外，一次处理多张图时，用cv::dnn::blobFromImages批量做预处理，比逐张循环快很多。
输入数据放置：ONNX Runtime里，如果CPU推理，输入Tensor要创建在CPU的arena分配器上；如果GPU推理，尽量把预处理也放到GPU上，避免CPU和GPU之间反复拷贝。这个拷贝的开销在小图模型上甚至比推理本身还大。
Batch配置：推理引擎内部基本都做了算子融合和内存复用，但batch size的变化会显著影响吞吐。在线服务建议固定batch=1并开启session_options.SetIntraOpNumThreads调整线程数；离线批处理任务根据显存把batch撑到最大。
后处理不要用STL痛殴：std::partial_sort、std::vector在每次推理时都分配内存，高频调用下要么耗时要么触发内存碎片。后处理尽量复用预分配的内存块，只更新数据不重新分配。

4.2 内存管理：Tensor的生命周期与拷贝

C++推理的内存问题和Python完全不是一个量级。Python有GC帮你兜底，C++里每个Ort::Value或者torch::Tensor都要你心里有数。

以LibTorch为例，torch::from_blob可以从外部内存直接构造Tensor而不拷贝，但这块内存的生命周期必须由你保证长于Tensor。否则Tensor还在用，你提前free了那块buffer，后面任何一次访问都是未定义行为。这是C++推理代码里第二常见的崩溃来源。

还有一个隐蔽的坑：把GPU Tensor通过cpu()转回CPU时，会产生一次同步拷贝。很多人为了取最终结果，会在循环里反复执行GPU推理 +cpu()转换，导致GPU流水线反复被打断。正确做法是：如果后续只是取结果后处理，可以每N次推理批量同步一次；或者在GPU上做后处理（比如top-k直接在GPU上用torch::topk）。

在ONNX Runtime里，也尽量复用Ort::Value对象，而不是每帧新建。尤其当你在循环里用同一个shape跑推理时，预先创建好输入Tensor、只更新里面的数据，能明显降低分配开销。

4.3 线程安全与并发推理

AI推理服务很少有单发单收的，并发场景下C++的线程模型直接决定稳定性。

ONNX Runtime的Ort::Session默认不是线程安全的，多个线程同时调用同一个Session的Run方法，轻则结果错乱，重则直接崩溃。解决办法有两个：一是给Session加锁，缺点是把并发退化成串行；二是创建多个Session实例，每个线程或每几条线程持有一个独立Session。后者是生产环境的常规操作，成本主要是内存——每个Session会加载一份模型权重，模型几个GB时这个开销不小。

LibTorch的情况类似，torch::jit::Module的forward在同一实例上并发调用也不安全。不过LibTorch官网明确支持：先调用module.to(at::kCUDA)并module.eval()，然后用module.clone()复制多个模块实例，分发给不同线程。某些算子如torch::NoGradGuard还必须放在线程内，不能跨线程共享。

还有session_options.SetIntraOpNumThreads和SetInterOpNumThreads这两个参数。前者控制单个算子内部的并行线程数，后者控制不同算子之间的并行数。在并发场景下，每个Session内部线程数设得太大会导致线程过度订阅，CPU上下文切换反而降低总吞吐。我一般经验是：部署机物理核心数为N，单实例内部线程数设为N除以实例数，再配合压测微调。

5. 算法硬功底：那些搜索热词背后的C++ AI成长路径

我不打算把这篇变成面试题整理，但搜索热词里出现了大量c++面试题、c++八股、冒泡排序算法c++、前缀和、快速幂算法c++、单调栈算法c++、卢卡斯定理c++怎么写这类内容，这说明很多人正在走C++学习和刷题路线。这跟AI框架有什么关系？关系非常大，至少有两层：一层是面试筛选的硬通货，另一层是实际性能调优必备的思维工具。

5.1 从基础语法到框架源码：面试八股其实有迹可循

先看八股部分。c++基础、c++八股、c++回调函数例子、c++结构体链表基本语法、c++字符串转数组、c++流i/o、c++ if语句、c++ 比较运算符、c++ 有员（应该是"友元"）这些热词指向的是同一个事实：C++的知识点特别碎，没人带着学很容易陷在语法细节里出不来。

我的建议是把八股分三条线穿起来：

对象生命周期线：构造、析构、拷贝构造、移动语义、RAII、智能指针。这条线决定了你能不能写好不泄漏的代码。
抽象与多态线：虚函数、纯虚函数、抽象类、接口设计。这条线是理解框架源码里大量interface和base class的钥匙。
模板与泛型线：模板实例化、类型萃取、SFINAE、可变参数模板。这条线是读Eigen、pybind11这类库绕不开的。

c++回调函数例子背后其实是函数指针、std::function和绑定器的问题，这在推理引擎里太常见了——算子注册机制就是一张巨大的回调函数表。c++结构体链表基本语法则是所有容器实现的起点，理解了链表你才能理解为何Tensor的连续内存布局那么重要。

5.2 算法能力就是性能分析能力

再聊算法。冒泡排序算法c++、前缀和、快速幂算法c++、单调栈算法c++、分治算法、判断质数c++优化、广搜模板、卢卡斯定理c++怎么写这些热词，表面上是竞赛内容，但放到AI框架的背景下，它们实际上是性能分析的基本功。

举个具体的例子：前缀和。你在做图像处理时，如果需要在多个窗口内快速求和（比如滑动窗口特征统计），操作复杂度是O(HWK)，用前缀和矩阵可以把每次窗口查询降到O(1)。这不需要什么高深技巧，就是把二维前缀和的公式写对。再比如快速幂，你在C++里做矩阵快速幂优化某些序列预测模型时，它就是把复杂度从O(n)降到O(logn)的工具。

而判断质数c++优化这类看似和AI八竿子打不着的问题，背后是预计算与空间换时间的思想。推理引擎里的内存池设计、算子融合、shape推导缓存，本质上都是这个思路。我常说，刷题不是目的，刷题练的是"把问题抽象成数据结构和算法模型"的能力，这个能力在剖析框架源码时会转化为阅读效率和分析深度。

5.3 给入门者一条不太卷的成长路径

如果你现在还在看c++入门、c++学习、c++基础，我给你一条相对平滑的路线，也是我当年走通的路线：

阶段一（2-3周）：过一遍C++基础语法，控制住自己不要碰多继承和模板元编程，先用vector、string、map写点小程序，比如小游戏、链表操作。
阶段二（4-6周）：掌握RAII和智能指针，把new/delete完全交给管理类。能读懂std::unique_ptr和std::shared_ptr的区别就算过关。
阶段三（6-8周）：基于CMake搭一个带第三方库的项目，把OpenCV跑起来，做图像读取、缩放、显示，再尝试封装一个简单C++ DLL供C#调用。这一步可以同步把环境配置和DLL调试学了。
阶段四（持续）：选一个小方向切入AI框架，ONNX Runtime或LibTorch都行，按本章的示例写一个端到端推理Demo。跑通之后，去读框架源码里的examples，再尝试自己改一个算子或者挂一个profiler。