📚 课程目录第1章课程导入

课程导入：学习目标、适用人群、课程结构、环境准备与工具链概览

TVM 作为端侧推理引擎，在嵌入式 Linux、RTOS 甚至裸机环境中部署时，runtime 库的体积往往成为瓶颈。一个完整的 TVM runtime 默认包含图执行器、VM 执行器、算子注册表、内存分配器、模块加载器以及各类后端设备接口，编译后体积通常在 2MB 到 8MB 之间。对于 Flash 容量仅有 1MB 或 RAM 仅有 256KB 的 Micro 控制器而言，这显然是无法接受的。本课程聚焦于 TVM Micro 交叉编译 runtime 库裁剪，通过系统化的方法，将 runtime 体积压缩到 100KB 甚至 50KB 以内，同时保证推理功能的完整性。

上图展示了本课程的整体知识框架。可以看到，学习目标、适用人群、课程结构、环境准备与工具链概览构成了课程的导入部分，而裁剪核心链路则是后续所有章节展开的主线。下面我们将逐一深入剖析每个模块的具体内容。

1.1 学习目标：从“能跑”到“跑得小”

本课程的学习目标不是简单地教会你如何编译一个 TVM runtime，而是帮助你建立一套系统化的裁剪思维。完成本课程后，你将能够：

理解 TVM runtime 的组成架构：包括 GraphExecutor、VMExecutor、算子注册表、内存池、模块加载器等核心组件，以及它们之间的依赖关系。
掌握交叉编译工具链的配置方法：包括 CMake 工具链文件编写、交叉编译器选择、系统库依赖分析等。
熟练运用裁剪手段：包括编译宏控制（如 TVM_MICRO_RUNTIME）、链接器垃圾回收（--gc-sections）、函数级 LTO、手动移除未使用模块等。
建立体积-功能权衡评估体系：能够根据目标硬件的 Flash/RAM 限制，合理选择裁剪策略，并验证裁剪后的 runtime 在目标板上正确运行。

以一个实际案例来说明：某 IoT 设备采用 STM32F412（Flash 1MB，RAM 256KB），需要部署一个包含 3 个卷积层、2 个全连接层和 1 个 Softmax 层的手写数字识别模型。未裁剪的 TVM runtime 编译后体积约为 1.8MB，远超 Flash 容量。通过本课程的方法，我们将其裁剪至 86KB，成功部署并保持推理精度不变。

1.2 适用人群：谁需要这门课程？

本课程面向以下四类人群，每类人群的关注点略有不同：

人群类型	背景特征	核心诉求	课程收益
嵌入式 AI 应用开发者	熟悉 C/C++、嵌入式系统，但对 TVM 内部机制了解有限	将模型部署到资源受限的 MCU 上	掌握 runtime 裁剪的完整流程，减少踩坑
边缘计算框架移植工程师	有 TVM 或类似框架的移植经验，需要适配新硬件	针对特定芯片定制最小化 runtime	深入理解 runtime 模块依赖，实现精准裁剪
物联网设备算法部署人员	主要使用 Python 训练模型，部署经验较少	快速将模型部署到现有设备	获得可复用的裁剪模板和验证方法
对 runtime 原理感兴趣的学生	有操作系统、编译原理基础	理解 TVM runtime 的设计哲学	通过裁剪实践加深对编译时/运行时分离的理解

无论你属于哪类人群，都需要具备以下基础知识：C 语言编程能力（至少能读懂结构体和函数指针）、基本的 Linux 命令行操作（如 make、cmake、gcc）、对神经网络模型的基本概念（如卷积、池化、全连接）。如果你对 TVM 完全陌生，建议先阅读官方文档的 “TVM Overview” 部分，再开始本课程。

1.3 课程结构：30 章递进式学习路径

本课程共 30 章，分为五个阶段，每个阶段都有明确的阶段性产出：

阶段一（第 1-5 章）：基础与环境——完成工具链安装、交叉编译环境搭建、TVM 源码编译，产出第一个可在目标板上运行的“最小 runtime”。
阶段二（第 6-12 章）：裁剪原理与工具——深入分析 runtime 体积构成，学习使用 nm、size、bloaty 等工具定位体积热点，掌握编译宏和链接脚本的裁剪技巧。
阶段三（第 13-20 章）：模块级裁剪实战——逐一裁剪执行器、算子注册表、内存分配器、模块加载器等组件，每章针对一个模块进行深度裁剪并验证。
阶段四（第 21-26 章）：高级优化与验证——引入 LTO、函数属性优化、自定义内存池、算子融合等高级手段，并建立完整的测试体系（单元测试、集成测试、硬件在环测试）。
阶段五（第 27-30 章）：综合案例与复盘——以三个真实项目（图像分类、语音唤醒、异常检测）为案例，展示从需求分析到最终部署的完整裁剪流程，并总结常见陷阱与最佳实践。

每一章都遵循“原理讲解 → 操作演示 → 案例拆解 → 误区复盘”的结构，确保你不仅知道“怎么做”，更理解“为什么这么做”。

1.4 环境准备：硬件、主机与软件依赖

在开始裁剪之前，必须准备好完整的开发环境。以下是推荐的配置清单：

1.4.1 主机环境（开发机）

操作系统：Ubuntu 20.04 LTS 或更新版本（Windows 用户可使用 WSL2）。
CPU/内存：至少 4 核 CPU、8GB RAM（编译 TVM 需要较多内存）。
磁盘空间：至少 20GB 可用空间（TVM 源码 + 编译产物 + 工具链）。
必备软件：git、cmake（≥3.18）、gcc（≥7.5）、python3（≥3.8）、pip3、ninja-build。

1.4.2 交叉编译工具链

根据目标架构选择对应的工具链。本课程以 ARM Cortex-M 系列和 RISC-V 为主：

# ARM Cortex-M 系列（以 STM32F4 为例）
sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi libnewlib-arm-none-eabi

# RISC-V（以 RV32IMC 为例）
sudo apt install gcc-riscv64-unknown-elf gdb-multiarch

# 验证安装
arm-none-eabi-gcc --version
riscv64-unknown-elf-gcc --version

经验提醒：对于 Cortex-M 系列，建议使用 arm-none-eabi-gcc 10.3 或更高版本，因为新版本对 -flto 的支持更完善，裁剪效果更好。如果使用 STM32CubeIDE 自带的工具链，请确保其版本不低于 9.3。

1.4.3 TVM 源码与依赖

# 克隆 TVM 源码（推荐 v0.14 或最新稳定版）
git clone --recursive https://github.com/apache/tvm.git
cd tvm
git checkout v0.14.0
git submodule update --init --recursive

# 安装 Python 依赖
python3 -m pip install --user numpy decorator attrs typing-extensions psutil

TVM 的 Micro 支持需要额外的 LLVM 后端。推荐使用 LLVM 12 或 13：

sudo apt install llvm-12 clang-12 lld-12
# 设置环境变量
export LLVM_CONFIG=/usr/lib/llvm-12/bin/llvm-config

1.4.4 目标硬件

本课程推荐以下开发板之一（任选其一即可）：

开发板	MCU	Flash/RAM	调试接口	备注
STM32F4DISCOVERY	STM32F407VG (Cortex-M4F)	1MB / 192KB	ST-Link	生态成熟，资料丰富
ESP32-DevKitC	ESP32 (Xtensa LX6)	4MB / 520KB	USB-UART	支持 WiFi，适合 IoT 场景
SiFive HiFive1 Rev B	FE310 (RISC-V RV32IMAC)	16MB / 16KB	OpenOCD	RISC-V 架构代表

如果你手头没有实体开发板，也可以使用 QEMU 模拟器进行验证。本课程后续章节会提供 QEMU 的配置方法，但强烈建议准备一块实体板卡，因为实际硬件上的 Flash 写入、RAM 对齐、外设初始化等问题无法在模拟器中完全复现。

1.5 工具链概览：裁剪工作的“手术刀”

裁剪 runtime 不是盲目地删除代码，而是需要一套精准的工具来定位体积热点、分析依赖关系、验证裁剪结果。以下是本课程中会频繁使用的核心工具：

size：查看编译产物的 text/data/bss 段大小，快速评估整体体积。
nm：列出目标文件中的符号表，用于分析哪些函数/变量被保留，哪些可以被移除。
bloaty：Google 开发的二进制体积分析工具，可以按符号、源文件、段等维度生成体积报告。
readelf：查看 ELF 文件的段信息、重定位表、依赖库等。
objdump：反汇编目标文件，用于检查裁剪后代码是否包含不必要的分支或数据。
CMake 的 --gc-sections 与 -ffunction-sections：配合使用，让链接器丢弃未引用的函数和数据段。

下面是一个典型的体积分析命令组合：

# 查看编译产物总体积
arm-none-eabi-size build/libtvm_runtime.a

# 按符号大小排序，找出体积最大的前 20 个符号
arm-none-eabi-nm --size-sort --radix=d build/libtvm_runtime.a | tail -20

# 使用 bloaty 生成详细报告（需要安装 bloaty）
bloaty -d symbols -n 30 build/libtvm_runtime.a

风险提示：在裁剪过程中，最容易犯的错误是“过度裁剪”——删除了某个看似无用的模块，但实际上该模块被其他代码通过函数指针或宏间接引用，导致链接失败或运行时崩溃。因此，每次裁剪后都必须进行完整的链接测试和硬件运行验证，不能只依赖编译器的报错信息。

1.6 案例拆解：从 1.8MB 到 86KB 的裁剪之旅

为了让你对裁剪的潜力有一个直观认识，这里展示一个真实案例的完整过程。该案例来自某工业视觉检测项目，目标硬件为 STM32F412（Flash 1MB）。

初始状态：使用 TVM v0.12 默认配置编译 runtime，未做任何裁剪。编译产物体积分布如下：

模块	体积（KB）	占比
GraphExecutor	412	22.9%
算子注册表（所有算子）	680	37.8%
内存分配器（默认 dlmalloc）	156	8.7%
模块加载器（支持所有格式）	198	11.0%
其他（日志、调试、类型系统）	354	19.6%
总计	1800	100%

裁剪过程：按照本课程的方法，我们依次执行了以下操作：

启用 TVM_MICRO_RUNTIME 宏，移除所有与 Micro 无关的代码路径（节省约 300KB）。
将执行器从 GraphExecutor 切换为 VMExecutor，并裁剪掉不支持的算子（节省约 200KB）。
手动编辑 op_registry.cc，仅保留模型所需的 5 个算子（节省约 500KB）。
将内存分配器替换为轻量级静态分配器（节省约 100KB）。
使用 -ffunction-sections -fdata-sections -Wl,--gc-sections 进行链接级裁剪（节省约 80KB）。
启用 -flto 进行跨模块优化（节省约 60KB）。

最终结果：裁剪后 runtime 体积为 86KB，其中 text 段 72KB，data 段 8KB，bss 段 6KB。模型推理时间从裁剪前的 45ms 略微增加到 48ms（增加 6.7%），但仍在实时性要求范围内。Flash 占用率从 180% 降至 8.6%，为后续功能扩展留出了充足空间。

  复盘经验：这个案例中最关键的一步是“算子注册表裁剪”。默认的 TVM runtime 会注册所有内置算子（约 200 个），但实际模型只用到 5 个。通过修改 op_registry.cc 中的条件编译宏，可以大幅减少代码体积。但需要注意的是，算子裁剪必须与模型编译时的算子选择保持一致，否则运行时会出现“找不到算子”的错误。

1.7 常见误区与总结复盘

在课程开始之前，有必要先了解初学者最容易犯的错误，避免你在后续学习中走弯路：

误区一：只关注编译宏，不关注链接器行为。编译宏可以移除源码级别的代码，但链接器仍然可能保留未引用的段。必须配合 --gc-sections 才能彻底清除。
误区二：忽略 C++ 异常和 RTTI。TVM runtime 默认启用了 C++ 异常和 RTTI，这会引入大量额外代码。在 Micro 场景下，应通过 -fno-exceptions -fno-rtti 禁用它们。
误区三：裁剪后不做回归测试。很多开发者只关注编译是否通过，却忽略了运行时行为。建议建立一套自动化测试脚本，在每次裁剪后自动运行模型推理并比对输出。
误区四：盲目追求最小体积。裁剪到极致可能会导致代码可读性差、维护困难，甚至引入难以排查的 bug。建议设定一个合理的体积目标（如 Flash 的 60%），留出安全余量。