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

1. 课程导入

自动驾驶系统本质上是一台在车轮上持续运行的实时计算平台。感知、预测、规划、控制等模块往往由不同团队、不同框架、不同硬件平台分别开发，最终却必须在同一辆车上协同工作。一个在服务器 GPU 上训练得到的 BEV 感知模型，可能需要部署到车端的 Orin、地平线征程、黑芝麻华山或高通 Ride 等芯片上；一个用 PyTorch 导出的检测网络，也可能要同时服务于仿真回放、数据闭环和实车推理三条链路。模型能否"一次训练、多端运行"，直接决定了算法迭代速度与工程成本。

核心挑战：从训练框架到车端芯片的"最后一公里"

训练与部署之间存在一条明显的鸿沟。训练侧追求精度与灵活性，算子可以动态、可以自定义、可以依赖 Python 运行时；部署侧追求确定性、低延迟与低功耗，算子必须静态、内存必须可预算、执行必须可预测。这条鸿沟具体表现为四类问题：

框架碎片化：PyTorch、TensorFlow、PaddlePaddle 等训练框架各有图表示，导出格式互不兼容。
硬件异构：GPU、NPU、DSP、MCU 的指令集、内存层级、量化能力差异巨大，同一算子在不同芯片上的支持程度不同。
算子语义漂移：训练框架中的算子语义与推理引擎实现之间可能存在细微差异，导致精度下降甚至结果错误。
工程链路割裂：模型转换、量化、编译、部署、验证各环节工具链不统一，问题定位困难。

中间表示（Intermediate Representation，IR）正是弥合这条鸿沟的关键抽象层。它把"模型是什么"与"模型跑在哪里"解耦：前端负责把不同训练框架的模型统一到 IR，后端负责把 IR  lowering 到不同硬件。跨平台部署工程，本质上就是围绕 IR 构建一条可验证、可复用、可扩展的编译与部署流水线。

核心价值：IR 作为部署流水线的"通用货币"

可以把 IR 理解为模型部署领域的"通用货币"。训练框架是不同国家的货币，硬件平台是不同国家的商户，而 IR 是大家都认可的中间结算单位。没有 IR 时，N 个框架与 M 个硬件之间需要 N×M 条转换路径；有了 IR，只需要 N 条前端导入路径和 M 条后端导出路径，复杂度从乘积降为求和。

更重要的是，IR 让优化有了统一的落脚点。图级优化（算子融合、常量折叠、死代码消除）、量化（INT8/FP16 校准与转换）、内存规划（张量复用、生命周期分析）、调度（算子切分与流水编排）都可以在 IR 层完成，而不必为每个硬件重复实现。这正是 TVM、TensorRT、ONNX Runtime、OpenVINO、Paddle Lite 等工具链共同遵循的设计哲学。

方法流程：一条可落地的部署链路

把上述抽象落到工程实践，一条典型的自动驾驶模型部署链路包含六个阶段。理解这条链路，是后续所有章节的骨架。

模型导出：从训练框架导出为通用格式（如 ONNX）或框架自定义图，固定输入形状与动态轴。
图导入与规范化：将外部图转换为内部 IR，统一算子命名、数据类型与属性语义。
图优化：执行算子融合、常量折叠、布局转换、死代码消除等与硬件无关的优化。
量化与校准：用校准数据集统计激活分布，生成 INT8/FP16 量化参数，并插入量化/反量化节点。
后端 lowering 与代码生成：将 IR 算子映射到目标硬件指令或厂商算子库，生成可执行模块。
精度与性能验证：对比部署前后输出误差，测量延迟、吞吐、内存占用，形成回归基线。

# 典型部署链路中的关键检查点（伪代码示意）
export  model.pth        -> model.onnx      # 固定 shape，检查算子支持
import  model.onnx       -> ir_module       # 规范化，记录不支持的算子
optimize ir_module       -> ir_optimized    # 融合 + 折叠 + 布局转换
quantize ir_optimized    -> ir_int8         # 校准集统计，生成 scale/zero_point
lower    ir_int8         -> target_module   # 映射到 Orin / 征程 / 华山
verify   target_module   -> report.json     # 精度误差 + 延迟 + 内存

案例场景：BEV 感知模型的多端部署

假设某团队训练了一个 BEV 感知模型，需要同时部署到仿真平台（x86 + GPU）、数据回放车（Orin）和量产车（征程 5）。若没有 IR，团队需要为每个平台单独适配：仿真用 ONNX Runtime，Orin 用 TensorRT，征程用厂商工具链，三套代码、三套量化策略、三套验证流程。引入 IR 后，团队只需维护一份 IR 图与一套优化 pass，后端差异被收敛到 lowering 阶段。当模型结构升级时，只需重新导出并跑一遍流水线，三个平台的部署产物可同步生成。

判断一个部署工具链是否成熟，可以看它是否具备三个特征：IR 是否可读可调试、优化 pass 是否可插拔、后端是否可扩展。这三点决定了团队能否在遇到新算子、新芯片时快速响应，而不是被工具链锁死。

常见误区与复盘

误区	表现	正确做法
把 IR 等同于 ONNX	认为导出 ONNX 就完成了中间表示工作	ONNX 只是交换格式，IR 还包含优化、量化、调度等内部表示
只关注转换成功	模型能转过去就上线，忽略精度对齐	建立逐层误差对比与端到端回归基线
量化一刀切	所有层统一 INT8，导致敏感层精度崩塌	按层敏感度分析，混合精度或保留关键层 FP16
忽视动态形状	训练用动态 batch，部署时未固定导致编译失败	部署前固定输入形状，或显式声明动态轴与范围

部署问题往往不是单点故障，而是链路问题。精度下降可能来自导出、优化、量化、后端 lowering 中的任意一环。因此，可观测性与分阶段验证比"一次转换成功"更重要。后续章节会围绕这条链路逐层展开。

课程目标与整体知识框架

本课程围绕"中间表示"与"跨平台部署"两条主线展开，目标是让学习者能够独立设计并实现一条面向自动驾驶场景的模型部署流水线。整体知识框架分为四个层次：

表示层：理解计算图、IR 类型系统、算子语义与图变换的基本原理。
优化层：掌握图优化、量化、内存规划与调度等关键 pass 的设计与实现。
后端层：了解主流车端芯片的编译流程、算子库与部署约束。
工程层：构建可验证、可回归、可扩展的部署工具链与协作流程。

接下来的章节将沿着这条链路，从 IR 的基本概念出发，逐步深入到图优化、量化、后端 lowering、性能调优与工程实践。掌握这条主线，你就拥有了在自动驾驶模型部署领域持续演进的能力底座。