核心概念解析：引擎、计划文件、Builder、Config、Runtime、序列化与反序列化
说实话，刚接触 TensorRT-LLM 那会儿，我也被这些概念绕得有点晕。引擎、计划文件、Builder……每个词都认识，串起来就不知道谁是谁了。后来我花了一周时间，把整个流程亲手跑了一遍，才真正搞明白它们之间的关系。
今天我就用最直白的方式，把这些核心概念给你讲透。你想想看，整个推理加速的过程，其实就两件事：构建和运行。Builder 管构建，Runtime 管运行，就这么简单。
一句话总结：Builder 用 Config 配置好参数，把模型编译成 Plan 文件（序列化），Runtime 再加载这个 Plan 文件（反序列化），生成 Engine 来执行推理。
1. Builder（构建器）—— 模型的“总设计师”
Builder 是 TensorRT-LLM 的入口。它的任务只有一个：把训练好的模型，编译成能在 GPU 上高效运行的格式。
我个人习惯把 Builder 想象成一个高级厨师。你给他食材（模型权重）、菜谱（网络结构）、还有厨房设备信息（GPU 型号），他就能做出一道色香味俱全的菜（推理引擎）。
Builder 的核心工作包括：
- 图优化：合并算子、消除冗余计算
- 精度校准：把 FP32 转成 FP16 或 INT8
- 内存优化：复用中间张量的内存空间
- 内核自动调优：为每个算子选择最快的 CUDA kernel
我的经验：Builder 的构建时间通常很长，尤其是大模型。我遇到过 70B 模型构建一次要 40 分钟。所以，一定要把构建好的 Plan 文件保存下来，下次直接加载，别每次都重新构建。
2. Config（配置）—— Builder 的“施工图纸”
Config 就是 Builder 干活时用的参数集合。没有 Config，Builder 就不知道该怎么优化。
常用的配置项包括：
| 配置项 | 说明 | 我的建议 |
|---|---|---|
| 精度 | FP32、FP16、INT8、FP8 | 生产环境用 FP16，兼顾速度和精度 |
| 最大批次大小 | 一次推理最多处理多少条数据 | 根据业务峰值设置，别设太大浪费显存 |
| 最大序列长度 | 输入文本的最大 token 数 | 设成模型支持的最大值，比如 4096 |
| 工作空间大小 | Builder 可用的显存上限 | 设成显存总量的 80%，留点余量 |
说白了，Config 就是告诉 Builder：“我要在什么条件下跑，你按这个标准来优化。”
3. Plan（计划文件）—— 序列化的“蓝图”
Builder 干完活，输出的是一个文件，这就是 Plan 文件。它包含了：
- 优化后的网络结构
- 算子选择信息
- 权重数据
- 内存分配方案
Plan 文件是序列化后的产物。什么叫序列化？就是把内存里的对象，转成可以存到磁盘上的二进制数据。反过来，从磁盘加载 Plan 文件到内存，就是反序列化。
注意：Plan 文件是硬件绑定的。你在 A100 上构建的 Plan，不能直接拿到 V100 上用。为什么？因为不同 GPU 的架构不同，算子选择、内存布局都不一样。我曾经犯过这个错，把 A100 上构建的 Plan 拷到 T4 上，结果 Runtime 直接报错。
4. Runtime（运行时）—— 真正的“执行者”
Runtime 负责加载 Plan 文件，创建 Engine，然后执行推理。它不关心模型长什么样，只负责按 Plan 的指令干活。
Runtime 的核心接口很简单：
// 伪代码示意
runtime = createRuntime()
engine = runtime.deserializeCudaEngine(planFile) // 反序列化
context = engine.createExecutionContext()
context.executeV2(buffers) // 执行推理嗯，这里要注意：Runtime 本身不参与任何优化，它就是个“执行器”。所有的优化工作，都在 Builder 阶段完成了。
5. Engine（引擎）—— 反序列化后的“活体”
Engine 是 Plan 文件反序列化后在内存中的存在形式。你可以把 Plan 理解成“设计图纸”，Engine 就是按图纸造出来的“机器”。
Engine 包含：
- 可执行的 CUDA kernel
- 权重数据（已经加载到显存）
- 执行上下文（ExecutionContext）
一个 Engine 可以创建多个 ExecutionContext，每个 Context 可以独立执行推理。这意味着你可以用同一个 Engine，同时处理多个请求——这就是多流并发的基础。
6. 序列化与反序列化—— 打通“构建”和“运行”的桥梁
这两个概念其实贯穿了整个流程：
- 序列化：Builder → Plan 文件（内存 → 磁盘）
- 反序列化：Plan 文件 → Engine（磁盘 → 内存）
为什么要序列化？因为构建一次太耗时了。你想想看，每次部署都要等 40 分钟构建，谁受得了？所以，构建一次，序列化保存，部署时反序列化加载，这才是生产环境的正确姿势。
避坑指南：我曾经在序列化时没注意版本号，结果 TensorRT-LLM 升级后，旧的 Plan 文件加载不上了。所以，建议在 Plan 文件名里带上 TensorRT-LLM 版本号和 GPU 型号，比如：llama_70b_a100_fp16_v0.9.0.plan。
7. 完整流程梳理
来，我们把整个流程串起来看：
- 准备阶段：准备好模型权重、Config 配置
- 构建阶段：Builder 读取 Config，加载模型，进行图优化、精度校准、内核调优
- 序列化阶段：Builder 把优化结果写入 Plan 文件
- 部署阶段：Runtime 加载 Plan 文件，反序列化成 Engine
- 推理阶段：Engine 创建 ExecutionContext，执行推理
下面这张图，把整个流程和核心概念的关系画清楚了：
看完这张图，你应该能理解整个流程了。说白了，TensorRT-LLM 的核心思想就是：把复杂的优化工作提前做完（Builder），把简单的执行工作留给运行时（Runtime）。这样，每次推理时就不用再重复优化了，速度自然就上去了。
最后说一句：这些概念虽然多，但只要你亲手跑一遍完整的流程——从 Builder 构建到 Runtime 推理——就全明白了。我当年也是这么过来的，别怕，动手试试。