5.1 动态形状（Dynamic Shapes）处理

5.1 动态形状（Dynamic Shapes）处理

本节摘要：SOURCE 5.1：传统部署管线中，“输入尺寸固定”是一条铁律，如同工业流水线上严丝合缝的模具——它保障效率，却也悄然筑起一道高墙：墙内是极致吞吐，墙外是千变万化的现实场景——可变…

从"尺寸即常量"到"尺寸即变量空间"

静态推理中，模型输入被声明为类似 input: [1, 3, 224, 224] 的四维张量，全部维度是编译期已知的整型常量。TensorRT 据此完成三件关键工作：内存规划（为输入、输出及所有中间激活分配固定显存块）、内核特化（为特定尺寸生成高度优化的 CUDA kernel）、计算图优化（执行依赖尺寸信息的常量折叠与冗余节点消除）。动态形状则从根本上松动了这一前提，允许将某一维度甚至多个维度声明为符号化维度，由一个运行时绑定的 OptimizationProfile 所定义的区间变量约束。

但 -1 并非"任意值"的同义词，它是受约束的占位符。TensorRT 通过双阶段契约保证可行性：编译期契约要求用户为每个符号维度显式提供闭区间 [min, opt, max]，该契约在构建引擎时被固化进引擎元数据；运行时契约要求实际推理时传入的具体形状对每个符号维度满足 d_i ∈ [min_i, max_i]，否则 setBindingDimensions() 返回 false、引擎拒绝执行。这个双阶段契约将一个不可判定的"全空间优化"问题转化为可验证的"有限区间覆盖"问题——TensorRT 用有限个优化剖面去覆盖无限连续的形状空间。

// C++ 端声明动态输入与优化剖面
nvinfer1::IBuilder* builder = nvinfer1::createInferBuilder(logger);
nvinfer1::INetworkDefinition* network = builder->createNetworkV2(0);

nvinfer1::ITensor* input = network->addInput(
    "input", nvinfer1::DataType::kFLOAT,
    nvinfer1::Dims4{-1, 3, -1, -1});  // batch/channel/height/width 中非 -1 维度固定

// 注册优化剖面：min/opt/max 三段式
nvinfer1::IOptimizationProfile* profile = builder->createOptimizationProfile();
profile->setDimensions("input", nvinfer1::OptProfileSelector::kMIN, nvinfer1::Dims4{1, 3, 128, 128});
profile->setDimensions("input", nvinfer1::OptProfileSelector::kOPT, nvinfer1::Dims4{4, 3, 256, 256});
profile->setDimensions("input", nvinfer1::OptProfileSelector::kMAX, nvinfer1::Dims4{16, 3, 1024, 1024});

nvinfer1::IBuilderConfig* config = builder->createBuilderConfig();
config->addOptimizationProfile(profile);
nvinfer1::ICudaEngine* engine = builder->buildEngineWithConfig(*network, *config);
​

# trtexec 命令行同样支持动态形状：通过 --shapes 指定具体尺寸
trtexec --onnx=model.onnx \
        --minShapes=input:1x3x128x128 \
        --optShapes=input:4x3x256x256 \
        --maxShapes=input:16x3x1024x1024 \
        --shapes=input:8x3x512x512 \
        --saveEngine=model_dynamic.engine
​

OptimizationProfile：形状空间的战略要塞

min 和 max 构成一个超矩形，划定引擎承诺服务的绝对边界。此边界必须基于真实业务负载的统计分布设定，而非拍脑袋的"保险起见"——若盲目把 max 设得过大，内存分配按最大值预留会造成严重浪费，编译时间指数级增长，某些算子还可能因超出硬件寄存器容量而降级为低效实现。opt 则是最具智慧的参数，它并非"最常用尺寸"，而是 TensorRT 编译时成本建模的基准点：引擎围绕 opt 生成最激进的内核特化，计算从 opt 到其他尺寸的性能衰减梯度，并据此决定哪些算子需保留多版本内核。

一个经典的反直觉案例：某 OCR 模型输入为可变长文本行图像，min=[1,3,32,32]，max=[1,3,32,2048]，opt 却取 [1,3,32,512] 而非最常见的 256——因为实测表明 512 宽度下卷积层的内存带宽利用率与计算吞吐达到最佳平衡点，小于它寄存器压力小但 ALU 闲置，大于它共享内存溢出导致频繁全局访存。单个剖面只能覆盖一个连通区域，现实场景常需注册多个 OptimizationProfile。TensorRT 并非为每个剖面构建独立引擎，而是在单引擎内维护剖面索引表，运行时 setBindingDimensions(D) 执行一次 O(n) 搜索找到首个满足条件的剖面，然后加载对应内存布局描述符与内核函数指针数组——多剖面带来的开销是常数级的几微秒索引查找，而非线性级的重建引擎。

动态形状下的内存模型与工程取舍

动态引擎的内存管理呈现鲜明的分层弹性。引擎元数据层大小固定，包含网络拓扑、所有剖面的 min/opt/max 元组集合与内存布局模板；运行时内存池层创建一个统一内存池，其总大小为所有剖面各自 max 尺寸所需内存的最大值，实际执行时按当前形状按需映射——切换剖面只需更新虚拟地址映射表，实现零拷贝切换与内存复用；临时工作区层通过 setMaxWorkspaceSize() 设定全局上限，运行时按当前形状动态分配、用毕立即释放。这种"虚拟地址+按需映射"的模式与现代操作系统的虚拟内存管理如出一辙。

工程上最常犯的错误是"剖面焦虑"：为每个观测到的尺寸都建一个 profile，导致编译时间爆炸、引擎体积膨胀、运行时索引延迟增加。最佳实践是聚类——对历史请求的形状做统计分析，用 K-means 找出几个有代表性的质心作为 opt，再设定合理的 min/max 边界。经验法则是 3-5 个精心设计的剖面通常能覆盖 95% 以上的实际流量。此外，动态 batch 需确保 LayerNorm、Dropout 等算子正确处理变长 batch，动态序列长度需配合 Packed Sequence 或 Padding Mask，跨剖面切换时还需注意 RNN 隐藏状态张量的尺寸兼容性。TensorRT 本身不解决这些语义问题，它只保证：在你声明的契约内，计算是正确且高效的。

核心锚点

故障场景切入 5.1 动态形状（Dynamic Shapes）处理：先固定输入与硬件环境，再定位瓶颈属于图优化、量化还是 I/O。

• 传统部署管线中，“输入尺寸固定”是一条铁律，如同工业流水线上严丝合缝的模具——它保障效率，却也悄然筑起一道高墙：墙内是极致吞吐，墙外是千变万化的现实场景——可变长文本、任意裁剪图像、多尺度目标检测、实时视频流中动态缩放的ROI、医学影像中因设备差异而浮动的体素分辨率……这些不是边缘用例，而是AI落地的真实毛细血管。
• 深入这一机制的肌理——不满足于罗列API调用，而致力于揭示其背后的设计哲学、约束逻辑与工程权衡；不将其视为一组配置开关，而视作TensorRT推理架构中承上启下的核心契约层（Contract Layer）：向上承接模型语义的多样性，向下锚定硬件执行的确定性。
• 当您的模型第一次成功接收一个从未在训练中见过的、却完美契合 Profile_MedRes 的 768×1024 图像，并在毫秒级内返回结果时——那不仅是TensorRT的胜利，更是这种新范式的无声宣言：AI推理，终将挣脱静态模具的桎梏，在流动的现实中，舒展其本应有的弹性与生机。

⚠️ 常见坑：只记结论不记适用边界——超出 SOURCE 所述浓度、尺度或版本范围，规律可能失效。

💡 关键直觉：5.1 动态形状（Dynamic Shapes）处理 应能对应至少一项可复现实验或算例。

要点速记

• 主干：5.1 动态形状（Dynamic Shapes）处理 连接「输入—过程—输出」
• 边界：对照 SOURCE 中的参数与版本条件
• 方法：用表格对齐假设与观测