编译式部署的思路
TensorRT-LLM 把模型先编译成针对特定 GPU 架构的引擎再运行，风格接近传统软件编译：转换权重、编译引擎、启动服务三个步骤分开。好处是运行期开销低、吞吐上限高；代价是引擎与架构强绑定，换卡或升级版本后通常需要重编，编译产物还要纳入版本管理。
典型流程（概念示例）
典型流程（概念示例）
# 1) 用官方容器进入已配好的环境
docker run --gpus all -it --rm nvcr.io/nvidia/tensorrt-llm/release
# 2) 转换权重（按官方脚本与目标精度）
python convert_checkpoint.py --model_dir <模型目录> --dtype bfloat16 --output_dir ./ckpt
# 3) 编译引擎
trtllm-build --checkpoint_dir ./ckpt --output_dir ./engine
# 4) 启动服务
trtllm-serve <模型或引擎目录>阶段与常见问题
| 阶段 | 产出 | 常见问题 |
|---|---|---|
| 权重转换 | 中间权重目录 | 精度与并行配置不一致，后续编译报错 |
| 引擎编译 | 与架构绑定的引擎文件 | 编译耗时长，参数与显存上限不匹配 |
| 服务启动 | 可调用的接口 | 引擎与当前卡架构不匹配，启动即失败 |
| 版本升级 | 重编后的引擎 | 驱动或库升级后需要重新编译并回归 |
典型使用场景
- 吞吐优先的在线服务：愿意用编译时间换取更低的运行期开销
- 固定硬件与固定模型的场景：架构不常变化时收益最明显
- 需要精细控制精度与并行切分的部署：编译阶段可调参数较多
- 与官方容器配套使用：环境统一，减少工具链版本问题
- 多机型验证：测试机与生产卡尽量同架构，避免引擎不可用
编译产物与 GPU 架构强绑定：在某代架构上编译的引擎不能直接拿到另一代架构上运行，升级驱动或框架后建议重编并回归。
工具链迭代快：命令与参数以官方当前版本文档为准，本条目演示的是「转换、编译、服务」这一固定结构，具体参数名要以实际版本核对。