基础概念：静态Shape与动态Shape的区别、动态Shape的典型应用场景
在正式进入TensorRT Optimization Profile配置之前，必须先厘清一个核心前提：模型输入张量（Input Tensor）的维度信息在推理生命周期内是否可变。这个看似简单的维度问题，实际上决定了TensorRT的整个优化策略、内存分配方式以及序列化引擎的可用范围。本章将从静态Shape与动态Shape的本质差异出发，剖析其底层机制，并结合NLP变长输入、检测多分辨率等典型场景，说明为什么动态Shape是现代生产环境中的刚需，以及它给推理系统带来的额外复杂度。
2.1 静态Shape与动态Shape的本质区别
静态Shape（Static Shape）指的是模型输入张量的每一个维度在编译期（Build Time）就被完全固定下来。例如一个图像分类模型，输入被定义为 [1, 3, 224, 224]，那么在TensorRT构建引擎时，所有层（Layer）的权重布局、卷积核的调度策略、中间激活值的内存偏移量都会基于这个精确的维度进行优化。这种方式的优势在于：编译器可以提前完成所有内存地址计算，选择最合适的CUDA Kernel（例如针对特定通道数展开循环），并且完全消除运行时维度判断的开销。对于批量固定、输入尺寸固定的生产环境，静态Shape通常能获得最佳的延迟和吞吐量。
动态Shape（Dynamic Shape）则允许在运行时（Runtime）指定输入张量的维度，但并非无限制地任意变化，而是必须在构建引擎时预先声明一个合法的维度范围。TensorRT要求用户为每个动态维度提供三个关键值：min（最小值）、opt（优化值）和max（最大值）。例如，一个NLP模型的序列长度维度可以声明为 min=1, opt=128, max=512。引擎在构建时会针对这个范围进行多档优化，运行时根据实际传入的Shape选择最接近的优化分支执行。
| 对比维度 | 静态Shape | 动态Shape |
|---|---|---|
| 维度声明 | 构建期完全固定 | 构建期声明[min, opt, max]范围 |
| 内存分配 | 按精确尺寸一次性分配 | 按max尺寸预留，存在内部碎片 |
| Kernel选择 | 编译期确定最优实现 | 运行时根据Shape查表选择 |
| 性能表现 | 极致延迟与吞吐 | 接近静态，但opt档位外有损耗 |
| 灵活性 | 差，输入尺寸变化需重建引擎 | 好，同一引擎可处理多种尺寸 |
| 序列化引擎 | 单一固定引擎 | 引擎内包含多个优化分支 |
2.2 动态Shape的典型应用场景拆解
动态Shape并非理论上的“锦上添花”，而是许多实际AI业务落地的硬性前提。以下三个场景最具代表性，它们分别从序列长度、空间分辨率和批量维度三个角度展示了动态Shape的必要性。
场景一：NLP变长输入（以BERT为例）
自然语言处理模型（如BERT、）的输入是经过Tokenization后的序列，而不同句子的长度天然不同。例如在线客服系统中，用户提问“你好”可能只有2个，而一个复杂的售后问题可能长达200个。如果采用静态Shape，必须将序列长度固定为最大值（如512），那么短句子在推理时会产生大量无意义的Padding计算，浪费算力。更严重的是，如果实际句子长度超过预设值，模型将直接报错。动态Shape允许将序列长度维度设置为 [1, 64, 512]，运行时按实际长度计算，短句子自动走低计算量分支，长句子也能正常处理。
场景二：目标检测多分辨率输入
在自动驾驶或安防监控场景中，摄像头采集的图像分辨率可能随光照、焦距或场景切换而变化。例如一个检测模型需要同时处理1280x720的广角画面和640x384的细节裁剪区域。静态Shape要求固定输入尺寸，这意味着要么将所有图像resize到统一尺寸（损失信息），要么为每种分辨率单独构建一个引擎（浪费显存）。动态Shape将高和宽分别声明为范围，如 H∈[320, 1280], W∈[320, 1280]，引擎内部会为不同分辨率组合生成多个优化版本，运行时根据实际输入自动选择。
场景三：推荐系统中的动态批量
在线推荐服务通常采用动态批处理（Dynamic Batching）来提升GPU利用率。当请求稀疏时，可能一次只推理1个样本；当流量高峰时，一次推理32个样本。如果使用静态Shape，要么固定batch=1（吞吐低），要么固定batch=32（延迟高）。动态Shape将batch维度设置为 [1, 8, 32]，系统根据当前队列长度动态调整batch大小，在延迟和吞吐之间取得平衡。
2.3 动态Shape带来的工程挑战与误区
动态Shape虽然解决了灵活性问题，但也引入了静态Shape时代不存在的工程复杂度。最核心的挑战在于性能不确定性。TensorRT在构建动态Shape引擎时，会针对opt值进行深度优化，但当实际Shape偏离opt较远时（例如opt=128，实际输入为512），Kernel的执行效率可能下降20%-40%。这是因为TensorRT无法为所有可能的Shape都生成最优代码，只能通过插值或近似策略选择次优实现。
另一个常见误区是将动态Shape等同于无限可变。有些开发者试图将维度范围设置得过大（如 min=1, max=10000），这会导致两个问题：一是构建时间急剧增加（TensorRT需要探索更多Shape组合），二是内存预留过大，可能直接导致显存溢出（OOM）。合理的做法是根据业务统计分布，将opt设置为出现频率最高的Shape，将min和max设置为覆盖95%以上实际场景的边界值。
此外，动态Shape对内存管理提出了更高要求。TensorRT在运行时需要根据实际Shape动态调整中间张量的内存布局，这可能导致额外的内存拷贝（Memory Copy）操作。在性能敏感场景中，建议使用TensorRT的IExecutionContext::setInputShape()方法预先声明输入Shape，并配合setOptimizationProfileAsync()在异步流中切换Profile，以减少同步等待开销。
总结而言，静态Shape与动态Shape的选择本质上是业务需求驱动的架构决策。静态Shape适合尺寸固定、追求极致性能的离线批处理场景；动态Shape适合面向真实世界、输入天然多变的在线推理服务。理解两者的差异，是正确配置Optimization Profile的第一步，也是避免后续“引擎构建成功但运行时崩溃”这类问题的关键认知基础。