4、构建引擎：trtllm-build 命令详解、关键参数与量化配置
好，引擎构建这一步，是整个推理流程里最核心的环节之一。说白了，trtllm-build 就是 TensorRT-LLM 的“编译前线指挥官”——它把咱们训练好的模型，转换成能在 GPU 上高效运行的推理引擎。
我个人习惯把这一步叫做“模型硬化”。因为一旦引擎构建完成，模型的结构和精度就基本定下来了。你想想看，后面所有的推理性能，都取决于这一步的参数配置。所以，咱们得把每个关键参数都吃透。
4.1 trtllm-build 命令概览
先看个最基本的命令结构：
trtllm-build \
--model_dir ./checkpoint \
--output_dir ./engine_output \
--max_batch_size 64 \
--max_input_len 2048 \
--max_output_len 512 \
--dtype float16 \
--use_fused_mlp \
--workers 4嗯，这里要注意：--model_dir 指向的是咱们上一章转换好的 checkpoint 目录，不是原始模型权重。我刚开始做的时候，就犯过这个错，直接把 HuggingFace 的模型目录扔进去了，结果报错半天。
4.2 关键参数详解
这三个参数——max_batch_size、max_input_len、max_output_len——决定了引擎的“容量”。它们直接影响显存占用和推理吞吐。
4.2.1 max_batch_size
这个参数定义了一次推理能处理的最大请求数。比如你设成 64，那引擎内部就会为最多 64 个并发请求分配显存缓冲区。
核心原则：max_batch_size 设得越大，显存占用越高，但吞吐量也越大。不过，不是越大越好。
我在项目中遇到过，有个团队把 max_batch_size 设成了 512，结果显存直接爆了。后来发现，他们的业务场景里，实际并发请求从来没超过 128。所以，我建议你根据线上流量的 P99 值来设定，留 20% 的余量就够了。
4.2.2 max_input_len 与 max_output_len
这两个参数控制模型能处理的最大序列长度。它们直接影响 KV Cache 的大小。
| 参数 | 作用 | 显存影响 |
|---|---|---|
| max_input_len | 输入 prompt 的最大 token 数 | 决定 prefill 阶段的显存 |
| max_output_len | 生成回复的最大 token 数 | 决定 decode 阶段的显存 |
举个例子，如果你设 max_input_len=2048，max_output_len=512，那引擎会为每个请求预留 2560 个 token 的 KV Cache 空间。你想想看，如果实际请求平均只有 500 个 token，那就有大量显存被浪费了。
我的经验：先分析你的业务数据分布。比如对话场景，输入通常 500-1000 token，输出 100-300 token。那就设 max_input_len=1024，max_output_len=512，既够用又不浪费。
4.3 量化配置
量化，说白了就是用更少的比特数来表示模型权重和激活值。这是提升推理速度、降低显存占用的“杀手锏”。
trtllm-build 支持多种量化方式，我挑几个最常用的说说：
4.3.1 FP8 量化
这是目前最流行的方案，尤其适合 H100 等支持 FP8 计算的 GPU。
trtllm-build \
--model_dir ./checkpoint \
--dtype float16 \
--use_fp8 \
--fp8_kv_cache \
--strongly_typed这里 --use_fp8 对权重和激活做 FP8 量化，--fp8_kv_cache 对 KV Cache 也做 FP8 量化。我曾经在一个 70B 模型上试过，FP8 量化后显存占用直接降了 40%，推理速度提升了 1.8 倍。
注意：FP8 量化对精度有一定影响。如果你的任务对精度极其敏感（比如医疗诊断），建议先做精度对比测试。
4.3.2 INT4 量化
INT4 量化更激进，显存节省更多，但精度损失也更大。
trtllm-build \
--model_dir ./checkpoint \
--dtype float16 \
--use_weight_only \
--weight_only_precision int4嗯，这里要提醒一下：INT4 量化通常只对权重做，激活值还是 FP16。我建议你在显存极度紧张的时候才考虑 INT4，比如要在单张 A100 上跑 70B 模型。
4.3.3 SmoothQuant 量化
SmoothQuant 是一种“平滑”量化技术，它通过调整权重和激活的分布，让量化更友好。
trtllm-build \
--model_dir ./checkpoint \
--dtype float16 \
--smoothquant 0.5参数 0.5 是迁移强度，取值范围 0-1。值越大，量化越激进。我一般从 0.5 开始试，然后根据精度损失情况微调。
4.4 知识体系图
下面这张图，帮你理清 trtllm-build 的核心逻辑：
4.5 避坑指南
最后，分享几个我踩过的坑：
- max_batch_size 设太大：我曾经在一个 8 卡 A100 的机器上，把 max_batch_size 设成 1024，结果引擎构建就花了 2 小时，而且推理时显存直接 OOM。后来改成 256，一切正常。
- 量化后精度下降：有一次我用 INT4 量化一个代码生成模型，结果生成的代码全是语法错误。后来换成 FP8 量化，精度就恢复了。
- 忽略 workers 参数：trtllm-build 默认单线程构建，很慢。我建议加上
--workers 4或--workers 8，能快好几倍。
我的建议：先不加量化，用 FP16 构建一个基础引擎，跑通流程。然后再逐步尝试不同的量化方案，对比精度和性能。这样出了问题，你知道是量化导致的，而不是其他环节。
好了，trtllm-build 的核心内容就这些。记住，引擎构建是“一锤子买卖”——参数设好了，后面推理就稳了。多花点时间在这步，绝对值得。
公众号:蓝海资料掘金营，微信deep3321