有用的构建时标志#
此页面介绍了几种构建时标志，这些标志通过 LLM-API 的 BuildConfig 类设置，您可以启用它们以提高基线性能。 构建时是指这些标志会影响 TensorRT-LLM 引擎的构建方式，并且必须重建引擎才能更改它们。 对于每个标志，都有对其作用的解释、有关如何启用它的描述，然后是通过 基准测试默认性能中描述的基准测试流程运行它的示例，以展示其对性能的影响。 可以在文档的命令行参考部分中找到与 trtllm-build 兼容的所有选项。
免责声明：虽然此处显示的性能数字是真实的，但仅用于演示目的。 环境、SKU、互连和工作负载的差异都会显着影响性能，并导致您的结果与此处显示的结果不同。
多个 Profile#
TensorRT-LLM 构建于 TensorRT 之上，TensorRT 通过“优化 Profile”处理引擎构建，这些 Profile 定义了最小、最佳和最大输入张量形状。 TensorRT 针对最佳形状进行优化，同时支持最小和最大之间的范围。
TensorRT-LLM 抽象掉了创建优化 Profile 的需求，尽管像 max_batch_size 和 max_num_tokens（稍后介绍）这样的标志会影响它们的创建方式。 默认情况下，仅创建一个 Profile。
在推理服务期间，不同的请求负载可能会向引擎呈现不同的张量形状。 TensorRT 通过允许多个 Profile 来解决这个问题，TensorRT-LLM 通过 LLM-API 中的 BuildConfig 选项来支持这一点。 启用多个 Profile 会增加构建时间，但没有性能方面的缺点，因此建议用于生产构建。
唯一需要注意的是，启用此功能可能会导致多次运行同一提示时产生略有不同的输出，因为根据请求负载，可能会使用不同的 Profile 和内核。 但是，这种差异不应影响输出质量，因此只要您不需要完全确定性的输出，就可以安全地启用此标志。
启用使用多个 Profile 构建#
以下是如何修改基线示例以启用多个 Profile 的示例。
from tensorrt_llm import LLM, BuildConfig
def main():
build_config = BuildConfig()
build_config.plugin_config.multiple_profiles = True
llm = LLM(
model="/scratch/Llama-3.3-70B-Instruct",
tensor_parallel_size=4,
build_config=build_config
)
llm.save("build_flags_multiple_profiles")
if __name__ == '__main__':
main()
如果您使用的是用于构建引擎的 CLI 流程，请将 --multiple_profiles 传递给 trtllm-build 以启用该功能。
使用多个 Profile 的性能#
基线是指在上一个基准测试默认性能页面中进行基准测试的引擎。
指标 |
基线 |
多个 Profile 开启 |
|---|---|---|
Token 吞吐量（token/秒） |
1564.3040 |
1861.0881 |
请求吞吐量（req/秒） |
0.7638 |
0.9087 |
平均首个 Token 时间（毫秒） |
147.6976 |
145.8958 |
平均 Token 间延迟（毫秒） |
31.3276 |
19.6452 |
如您所见，启用多个 Profile 显着提高了各个方面的指标。
分页上下文注意力#
默认情况下，新请求的提示的所有 Token 都在一次迭代中作为上下文阶段处理。 启用分页上下文注意力允许 TensorRT-LLM 将上下文阶段分解为块，并通过多次迭代处理提示。 这对于具有大输入长度的工作负载特别有用。 在最坏的情况下，此功能可能会在基准测试运行中产生很小的性能损失（<2%），因此可以安全地启用它。 本指南的下一页将进一步讨论此功能。
启用分页上下文注意力#
将以下行添加到上面多个 Profile 的示例中以启用分页上下文注意力
build_config.plugin_config.use_paged_context_fmha=True
如果您使用的是用于构建引擎的 CLI 流程，请将 --use_paged_context_fmha 传递给 trtllm-build 以启用该功能。
性能#
分页上下文关闭是指与先前示例中显示的多个 Profile 开启相同的引擎。
指标 |
分页上下文关闭 |
分页上下文开启 |
|---|---|---|
Token 吞吐量（token/秒） |
1861.0881 |
1866.6684 |
请求吞吐量（req/秒） |
0.9087 |
0.9115 |
平均首个 Token 时间（毫秒） |
145.8958 |
145.4089 |
平均 Token 间延迟（毫秒） |
19.6452 |
19.6523 |
在这种情况下，启用分页上下文注意力可以略微提高性能，但是我们的测试的重新运行发现这在运行到运行的差异范围内，对于 token 吞吐量约为 10 tok/s，对于平均首个 token 时间约为 2 毫秒（ITL 是稳定的，小于 <1 毫秒，并且请求吞吐量与 token 吞吐量直接对应）。 在其他情况下，简单地启用它实际上可能会对性能产生很小的影响。 但是，有关如何推理此标志以及为什么我们建议启用它的进一步指导将在下一页中讨论，因为它与 TensorRT-LLM 如何调度请求以及最大 token 数标志密切相关。
GEMM 插件#
TensorRT 允许您添加“插件”或自定义内核，这些内核可以代替 TensorRT 为特定操作选择的内核来使用。 TensorRT-LLM 具有大量专门用于加速受支持模块的自定义插件。 GEMM 插件利用 NVIDIA cuBLASLt 和一些自定义内核来执行 GEMM 操作。 在 FP16 和 BF16 上，建议启用它以获得更好的性能和更小的 GPU 内存使用量。 在 FP8 上，建议禁用它。
启用 GEMM 插件#
将以下行添加到上面多个 Profile 的示例中以启用分页上下文注意力。
build_config.plugin_config.gemm_plugin = 'auto'
如果您使用的是用于构建引擎的 CLI 流程，请将 --gemm_plugin auto 传递给 trtllm-build 以启用该功能。 'auto' 告诉 GEMM 插件具有与模型相同的类型（fp16、bf16 等）。 除非您尝试进行混合精度，否则可以将其保留为自动。
使用 GEMM 插件的性能#
GEMM 插件关闭是指与先前示例中显示的分页上下文开启相同的引擎。
指标 |
GEMM 插件关闭 |
GEMM 插件开启 |
|---|---|---|
Token 吞吐量（token/秒） |
1866.6684 |
2033.2640 |
请求吞吐量（req/秒） |
0.9115 |
0.9928 |
平均首个 Token 时间（毫秒） |
145.4089 |
147.8307 |
平均 Token 间延迟（毫秒） |
19.6523 |
15.4133 |
在这种情况下，GEMM 插件大大提高了吞吐量和 ITL，但略微降低了 TTFT。
Llama 模型的 Reduce Norm Fusion 插件：#
TensorRT-LLM 具有默认启用的 AllReduce 操作的自定义内核。此功能通过将 AllReduce 之后运行的 ResidualAdd 和 LayerNorm 内核融合到 AllReduce 内核中来扩展此功能，从而生成一个处理这些操作的内核并提高端到端性能。此功能目前仅适用于 Llama 模型。它在生成阶段繁重的 workloads 中最有利。对于上下文阶段极其繁重的 workloads，值得检查启用和禁用此功能时的性能。此外，由于这是 AllReduce 的优化，因此它仅适用于具有张量并行性的情况。对于仅使用流水线并行性的情况，应保持禁用状态，因为流水线并行性不需要任何 AllReduce 操作。
启用 Reduce Norm Fusion 插件#
将以下行添加到上面多个 Profile 的示例中以启用分页上下文注意力。
build_config.plugin_config.reduce_fusion = True
如果您使用 CLI 流程构建引擎，请将 --reduce_fusion enable 传递给 trtllm-build 以启用该功能。
Reduce Norm Fusion 的性能#
Reduce Fusion OFF 指的是与先前示例中 GEMM 插件 ON 所示的相同引擎。
指标 |
REDUCE FUSION OFF (Reduce Fusion 关闭) |
REDUCE FUSION ON (Reduce Fusion 开启) |
|---|---|---|
Token 吞吐量（token/秒） |
2033.2640 |
2044.2628 |
请求吞吐量（req/秒） |
0.9928 |
0.9982 |
平均首个 Token 时间（毫秒） |
147.8307 |
146.6628 |
平均 Token 间延迟（毫秒） |
15.4133 |
14.4493 |
对于 2048/2048 的 ISL/OSL 对，启用 reduce norm fusion 插件可以略微提高整体性能。然而，测试重运行发现，在运行到运行的差异中，在最坏的情况下，它们的性能相当。同样，此标志的有效性取决于 workload，因此用户应检查它是否在他们的情况下提供有意义的性能提升。
流水线并行 Reduce Scatter 优化#
此功能添加了流水线并行优化，带有 ReduceScatter + AllGather，针对大型混合专家模型。可以通过 LLM-API 启用，如下所示
build_config.plugin_config.pp_reduce_scatter = True
如果您使用 CLI 流程构建引擎，您可以通过将 --pp_reduce_scatter 添加到 trtllm-build 来启用此功能。
由于 Llama 模型不是 MoE 模型，因此该标志未包含在案例研究中。
结论#
总的来说，启用这些标志可以大大提高性能。但是，它们的有效程度因 workload 而异，建议您在 workload 上运行健全性检查以验证性能。
案例研究示例表明，启用这些标志可以从基线数字中提供以下性能提升。这包括 Token Throughput、Request Throughput 和 Average Inter-Token Latency 的显着提升。TTFT 基本上没有改变。
指标 |
基线 |
构建时标志 ON (Build-Time Flags ON) |
% 提升 (% Improvement) |
|---|---|---|---|
Token 吞吐量（token/秒） |
1564.3040 |
2044.2628 |
30.68 |
请求吞吐量（req/秒） |
0.7638 |
0.9982 |
30.69 |
平均首个 Token 时间（毫秒） |
147.6976 |
146.6628 |
0.70 |
平均 Token 间延迟（毫秒） |
31.3276 |
14.4493 |
53.88 |
配置选项建议摘要:#
多个 profiles：始终启用。它可能会稍微增加构建时间，但只会帮助提高性能。启用可能会导致引擎在多次运行同一提示时产生略有不同的输出，具体取决于请求负载，但它不应影响输出质量，有关说明，请参见 Multiple Profiles section（多个 Profiles 部分）。
分页上下文注意力（Paged Context Attention）：在最坏的情况下，它最初可能会略微降低性能，但通常有助于请求调度，并在进一步调整最大批大小和最大 token 数量后提高性能。有关此主题的更多信息将在下一页讨论。
GEMM 插件：建议为 FP16 和 BF16 模型启用它，因为它通常有帮助。但是，最好对您的 workload 进行基准测试，并仔细检查它是否有帮助。
Reduce Fusion：此功能仅在 Llama 和 Mistral/Mixtral 模型上受支持。有效性取决于 workload，建议您在使用和不使用它的情况下对您的 workload 进行基准测试，并比较结果。