TensorRT 动态 Shape：让推理引擎学会“量体裁衣”

可视化演示

展示TensorRT动态Shape机制：变长输入张量、优化Profile定义维度范围、运行时自动选择最优内核，通过交互理解动态Shape兼顾灵活性与推理性能的原理。

动态Shape概念

传统宴席上，每位客人的餐盘大小是统一的，厨房提前把菜分好，盘子端上去就是那个分量——这就是 TensorRT 的静态 Shape 模式。可自助餐厅的客人饭量不一：有人只想尝两口，有人要满满一盘。如果厨房还是按固定的盘子配菜，要么给每桌备上好几套规格的餐具（为每个尺寸单独建引擎），要么干脆把所有人的菜都堆成大份（padding 到最大长度）。前者管理成本爆炸，后者浪费大量算力。动态 Shape 让餐台本身能伸缩：输入数据的尺寸每次都可以不同，同一套厨房流程照常运转。

这个“伸缩的餐台”落到技术上，就是输入张量的 shape 中可以出现动态维度。在 TensorRT 里，我们通常用 -1 标记一个允许变化的维度。例如 NLP 模型处理句子序列时，批量大小固定为 1，隐藏层特征固定为 64，只有序列长度每次请求都不同，于是把输入定义为 (1, -1, 64)。

没有动态 Shape 时，线上句子长度在 8 到 256 之间浮动，你只能选两个方案：按最大长度 padding，GPU 上四分之三的算力在算“空菜”；或者为每个常见长度各建一个引擎，部署文件多到运维崩溃。动态 Shape 让一个引擎通吃整个区间，像一间自助厨房服务所有饭量的客人。

优化Profile

自助餐要想开得顺畅，得先划好“取餐区间”：凉菜区备 3 到 8 种、热菜区备 5 到 12 种。客人少了就少上菜，客人多了就多补货，但总得有个下限和上限。TensorRT 的优化 Profile（Optimization Profile） 干的正是这件事——为每个动态维度声明一段合法区间，并且还要在这段区间里标出一个“黄金档位”。

Profile 用三个值描述一个动态维度：min 是下界，表示引擎接受的最小长度；max 是上界，表示显存和内核设计能支撑的最大长度；opt 是“最常出现的长度”，相当于主厨最拿手的分量。构建引擎时，TensorRT 会重点围绕 opt 调优内核；运行时，每次输入的实际长度只要落在 区间内就能正常运行。

划 Profile 有点像给自助餐线定“餐台容量区间”：下限定得太低、上限定得太高，主厨要兼顾的范围太广，每个尺寸都难做到极致；区间贴合真实客流量分布，才能既灵活又高效。这也是为什么部署前统计线上输入尺寸分布至关重要。

引擎构建流程

自助餐厅开业前要做的不是每天临时摆桌子，而是把整个厨房动线设计成一张蓝图：哪里放灶台、哪里备菜、传菜路径怎么走。TensorRT 构建动态 Shape 引擎同样遵循“先设计、后营业”的思路——构建（Build）阶段把网络结构、Profile 区间、工作空间配置全部固化，产出一个序列化引擎文件，之后部署就靠加载这个“菜谱蓝图”。

构建流程可以拆成四步：先创建 Builder 构建器，它相当于总负责人；再创建 Network 定义模型的计算图，即每道菜的加工步骤；接着创建 Optimization Profile 并绑定到 Builder Config 配置上，相当于把“取餐区间”写进营业手册；最后调用构建接口，产出序列化的引擎字节流。

构建好的引擎像一本“中央厨房手册”：里面的 Profile 区间、内核选择策略、显存规划统统写死。部署时只需加载这本手册，不必重新建厨房——这保证了动态 Shape 引擎在启动后能快速响应不同尺寸的请求。

运行时绑定

客人落座后开始点菜，服务员把具体需求报给后厨。动态 Shape 引擎在运行时也需要这样一次“点菜”：每次推理前，你必须通过执行上下文（Execution Context） 告诉引擎当前这次请求的实际输入形状，这一步叫作维度绑定。

执行上下文可以理解为引擎的“当前工作状态实例”。同一份引擎可以创建多个上下文，就像一本菜谱可以供多个厨师同时照做。每个上下文有自己独立的一组绑定缓冲区：set_input_shape 指定输入张量的实际维度，get_tensor_shape 查询输出张量的形状。关键约束是：实际维度必须落在构建时声明的 Profile 区间内。

绑定维度不是每次都要从零开始——如果下一次请求的长度和上一次相同，引擎会复用现成的内部状态，就像熟客“老样子”一样省事。一旦换了个新长度，引擎内部会自动切换对应的内核与显存布局，整个过程对上层透明。这就是动态 Shape“一个引擎、百变输入”的奥秘所在。

内存池管理

自助餐厅的备料仓库不会按最大客流量给每道菜都备满，而是根据时间段统筹：凉菜区和热菜区的备料高峰错开，同一批食材在不同时段被不同餐台使用。TensorRT 构建动态 Shape 引擎时，对显存的管理也遵循同样的“复用哲学”——Workspace 内存池。

模型推理时会产生大量中间张量，这些张量在计算图中各有各的“存活时间”：有的在层 A 算完就死了，有的要活到层 Z。如果每个张量都独享一块显存，内存占用会随动态 Shape 的最大尺寸爆炸式增长。TensorRT 在构建期做了一次“仓库规划”：把生命周期不重叠的张量安排到同一块显存区域轮流使用。

这套复用策略让动态 Shape 引擎的显存占用不再随最大维度线性放大：只要中间张量寿命错开，就能共享仓库空间。实际部署中，你可以通过 set_memory_pool_limit 为 workspace 设置上限，TensorRT 会在上限内自动压缩和复用——就像一个贴着预算经营的厨房主厨，用巧妙的排班代替买更多的仓库。

性能优化策略

同样是炒一盘青菜，大厨会用猛火灶快炒，炖汤则换文火炉慢煨。TensorRT 内部维护着大量针对不同形状、不同硬件优化的内核（Kernel），构建动态 Shape 引擎时，它会在 Profile 区间上做的事比你想的更聪明：不是含糊地用一套通用实现凑合，而是针对 opt 维度进行基准测试，为不同尺寸区间挑选不同的内核策略。

当某个输入形状恰好等于 opt 时，引擎直接使用那套精挑细选的最快内核；当形状偏离 opt 时，引擎会退而求其次，从备用内核池中选一个对该尺寸相对高效的选择。这个选择过程被建模为一个最大化问题：从内核集合里，挑出在给定 shape 和硬件下推理速度最快的那个。

实践中的调优秘诀是：把 opt 设成线上出现频率最高的输入形状，让最快内核服务于最常见的场景；同时不要让 Profile 区间过宽，否则引擎需要在“照顾少数派形状”上花费过多优化预算。正如好主厨不会为了偶尔的百人宴把整间厨房都换成大锅。

部署应用场景

自助餐厅开业后，客流高峰时百人排队，闲时三三两两——但厨房只要开一次门，就能服务所有客人。动态 Shape 在真实部署中扮演的正是这个“一次构建、长时服役”的角色。以 NLP 推理服务为例，用户的 query 短则几个 token、长则上千 token，静态引擎要么按上限 padding 浪费显存，要么为各种长度维护一大堆引擎文件。

动态 Shape 让一个引擎覆盖全部长度区间，服务端只需在收到每个请求后调用上下文绑定接口，把实际 seq_len 传进去即可。对于 LLM 这类 token 逐次增长的解码场景，动态 Shape 还能配合 KV Cache 的增量更新，让显存利用率跟随实际序列长度平滑伸缩，而不是永远按最坏情况预留。

在实际推理集群中，动态 Shape 更带来资源调度的灵活性：多个模型的引擎可以共享 GPU 上的显存池，因为每个引擎的内存需求会随输入尺寸动态伸缩；不同租户的请求长短不一，也被自然地平均到了资源曲线上。就像自助餐线根据客流自动补菜，后厨始终忙碌而从容——这就是动态 Shape 从“能用”走向“好用”的工程价值。

AI 应用场景

Python 演示

import tensorrt as trtimport numpy as np LOGGER = trt.Logger(trt.Logger.WARNING)  def build_dynamic_engine(min_len, opt_len, max_len):    builder = trt.Builder(LOGGER)    network = builder.create_network(        1 << int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)    )    profile = builder.create_optimization_profile()     # 输入 x = (batch=1, seq_len=动态, hidden=64),NLP场景的典型布局    x = network.add_input("x", trt.float32, (1, -1, 64))    identity = network.add_identity(x)    out = identity.get_output(0)    network.mark_output(out)     # 关键:为动态维度声明min/opt/max三段区间    profile.set_shape("x", (1, min_len, 64),                           (1, opt_len, 64),                           (1, max_len, 64))    config = builder.create_builder_config()    config.add_optimization_profile(profile)    config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 1 << 30)     return builder.build_serialized_network(network, config)  def infer_with_dynamic_shape(engine_bytes, seq_len):    runtime = trt.Runtime(LOGGER)    engine = runtime.deserialize_cuda_engine(engine_bytes)    context = engine.create_execution_context()    # 运行时按请求实际长度绑定维度,无需重建引擎    context.set_input_shape("x", (1, seq_len, 64))    # 实际项目中还需用pycuda分配device显存并拷贝输入数据    shape = context.get_tensor_shape("x")    return "引擎就绪,当前绑定输入维度:%s" % (shape,)  if __name__ == "__main__":    engine = build_dynamic_engine(min_len=8, opt_len=64, max_len=256)    print("动态引擎构建成功,大小(MB):%.2f" % (len(engine) / 1e6))    print(infer_with_dynamic_shape(engine, seq_len=48))    print(infer_with_dynamic_shape(engine, seq_len=128))

1. network.add_input("x", trt.float32, (1, -1, 64))定义输入张量，用 -1 声明序列长度为动态维度。
2. profile.set_shape("x", (1, min_len, 64), (1, opt_len, 64), (1, max_len, 64))为动态维度指定 min/opt/max 三段区间，这是动态 Shape 的核心配置。
3. config.add_optimization_profile(profile)把 Profile 挂到构建配置上，引擎构建时才会识别动态区间。
4. builder.build_serialized_network(network, config)执行构建并直接产出序列化引擎字节流。
5. context.set_input_shape("x", (1, seq_len, 64))运行时绑定本次请求的实际维度，引擎内部自动切换内核。
6. context.get_tensor_shape("x")查询绑定后的张量形状，确认动态维度生效。

常见误区

面试题