3、动态Shape的产生原因：模型输入不固定、批处理维度可变、序列长度可变等典型场景
在将深度学习模型部署到边缘设备（如Jetson、RK3588、树莓派或各类NPU/TPU加速器）时，开发者最常遇到的拦路虎之一便是“动态Shape”。ONNX作为模型转换的中间表示，其静态图特性与真实业务场景中灵活多变的输入尺寸之间存在天然矛盾。理解动态Shape为何产生，是制定有效转换策略的前提。本章将深入剖析动态Shape的三大核心来源——模型输入不固定、批处理维度可变、序列长度可变，并结合边缘设备部署的实际约束，帮助您建立系统性的诊断与应对框架。
上图清晰地展示了动态Shape的三大来源及其在ONNX模型中的汇聚效应。在实际部署中，这些来源往往不是孤立存在的，例如一个目标检测模型可能同时具有动态的批处理维度（N）和动态的图像尺寸（H, W），而一个语音识别模型则可能同时涉及动态的序列长度（L）和固定的特征维度。理解这些来源的底层机制，是后续选择“固定输入转换策略”的基础。
3.1 核心原理：静态图与动态Shape的冲突本质
ONNX作为一种中间表示格式，其计算图在导出时通常被定义为静态图。这意味着图中每个张量的形状（Shape）在编译或转换阶段就应被确定或至少被约束。然而，深度学习模型在训练和推理阶段，其输入数据的形状往往具有天然的可变性。这种“静态图定义”与“动态数据形状”之间的矛盾，构成了动态Shape产生的根本原因。
从计算图的角度看，动态Shape意味着图中某些算子的输出张量形状依赖于运行时输入。例如，一个Reshape算子的目标形状可能由另一个张量动态提供，或者一个Conv算子的输出高度和宽度取决于输入图像的尺寸。在ONNX中，这通常表现为维度值被标记为symbolic（符号变量），如batch、height、width，或者直接使用-1表示不确定维度。
对于边缘设备而言，其硬件加速器（如GPU、NPU、DSP）通常针对固定形状的算子进行了深度优化。内存分配、算子调度、流水线设计都基于静态形状进行预计算。一旦遇到动态Shape，加速器往往需要回退到CPU执行，或者进行低效的动态内存分配，导致推理性能急剧下降，甚至直接报错。因此，理解动态Shape的产生，本质上是为了识别哪些维度是“真正动态”的，哪些是“伪动态”的（即虽然标记为动态，但在实际业务中取值范围有限）。
batch=1的固定转换与batch=4的固定转换，其内存占用和计算效率差异巨大。
3.2 判断方法：如何定位模型中的动态Shape来源
在动手转换之前，必须系统性地定位模型中所有动态Shape的具体位置和触发条件。以下是推荐的判断流程，可帮助您快速识别动态Shape的来源。
- 静态分析ONNX图结构：使用
onnx.shape_inference工具或Netron可视化工具加载模型，检查输入张量的维度声明。重点关注dim_param字段（如batch、seq_len）或值为0的维度（表示动态）。 - 追踪动态维度的传播路径：从输入张量出发，沿着计算图追踪动态维度如何通过
Conv、Pool、Reshape、Concat、Gather等算子传播。例如，一个动态的宽度W经过两次步长为2的卷积后，输出宽度变为W/4，这会影响后续所有依赖该尺寸的算子。 - 区分“结构性动态”与“数值性动态”：结构性动态是指维度本身参与计算（如动态的循环次数、动态的Reshape目标），数值性动态是指维度值在有限集合内变化（如batch只能是1、2、4、8）。后者通常可以通过“多档位固定”策略解决。
- 检查控制流算子：ONNX中的
If、Loop、NonMaxSuppression等算子可能引入隐式动态行为。例如，NonMaxSuppression的输出框数量是动态的，这会导致后续处理动态Shape。
| 动态来源 | ONNX中的典型表现 | 常见于哪些模型 | 边缘设备影响程度 |
|---|---|---|---|
| 批处理维度可变 | 输入维度N为symbolic或-1 |
所有模型（在线/离线推理） | 中（可通过固定batch规避） |
| 图像尺寸可变 | 输入维度H/W为symbolic |
目标检测、语义分割、超分 | 高（影响内存布局与算子融合） |
| 序列长度可变 | 输入维度L为symbolic，或存在Loop算子 |
NLP、语音识别、视频理解 | 极高（RNN/Transformer结构复杂） |
onnxruntime的get_inputs()方法查看输入张量的shape属性。如果某个维度值为None或'dynamic_axes'，则说明该维度是动态的。同时，利用onnxruntime的get_provider_options()可以查看当前执行提供程序对动态Shape的支持情况。
3.3 案例拆解：一个多尺度目标检测模型的动态Shape诊断
为了更具体地说明动态Shape的产生与影响，我们以一个典型的YOLOv5s模型部署到瑞芯微RK3588 NPU为例，进行全流程拆解。
背景与约束：项目需要将YOLOv5s模型部署到RK3588平台，使用RKNN-Toolkit2进行模型转换。业务场景要求模型能够处理来自不同分辨率摄像头的输入（1280x720、1920x1080），且推理时batch size固定为1。初始转换时，直接使用PyTorch导出的ONNX模型，输入维度为[1, 3, -1, -1]，其中-1表示动态的H和W。
初始现象：使用RKNN-Toolkit2进行转换时，工具提示“Dynamic shape is not supported in current version, please fix input shape to a static one”。即使强制指定一个固定形状（如640x640）进行转换，在推理其他分辨率输入时，NPU输出结果错误或直接崩溃。
分析判断过程：
- 步骤1：使用Netron打开ONNX模型，确认输入节点
images的shape为[1, 3, -1, -1]，且后续的Conv、Upsample等算子的输出shape均依赖于该动态值。 - 步骤2：检查模型中的
Resize算子（用于FPN特征融合），发现其scales或sizes输入是动态计算的，这导致特征图尺寸在运行时才能确定。 - 步骤3：进一步分析，YOLOv5s的检测头输出特征图尺寸为输入尺寸的1/8、1/16、1/32。如果输入尺寸动态变化，这三个输出特征图的H和W也会动态变化，导致后续的
Decode操作无法静态编译。
实际操作步骤：
- 固定输入分辨率：与业务方协商，将输入图像统一缩放至640x640（保持宽高比并填充灰边）。修改ONNX模型的输入shape为
[1, 3, 640, 640]。 - 修改预处理逻辑：在NPU前处理阶段（CPU上执行），增加letterbox操作，确保送入NPU的tensor始终为640x640。
- 重新导出与转换：在PyTorch中，使用
torch.onnx.export时，设置dynamic_axes=None，并指定input_names和output_names，确保所有维度静态化。 - 验证与调优：转换成功后，使用多组不同分辨率的测试图片，通过letterbox预处理后送入NPU，对比检测精度与延迟。结果显示，mAP下降约0.5%（因分辨率缩放），但推理延迟从CPU回退时的45ms降至NPU的12ms。
结果对比与风险：固定输入分辨率解决了NPU不支持动态Shape的问题，但引入了额外的预处理开销（letterbox）和轻微的精度损失。此外，对于极端宽高比的输入图像，填充灰边会浪费计算资源。后续考虑使用“多档位固定”策略，即预设640x640、1280x1280两档，根据输入分辨率动态选择模型副本，以平衡精度与性能。
Resize、Crop、Pad等算子。这些算子可能隐式依赖输入尺寸。例如，YOLOv5中的Focus层（现已改为Conv）对输入尺寸有偶数倍要求，若固定尺寸不当，会导致维度不匹配错误。
3.4 常见误区与总结复盘
在处理动态Shape问题时，开发者常陷入以下误区，导致转换失败或部署后性能不佳。
- 误区一：认为所有动态Shape都必须消除。实际上，某些边缘设备（如Jetson Orin的GPU）对动态Shape有一定支持，只是性能不如静态Shape。如果动态范围很小（如batch 1~2），可以尝试保留动态性，但需进行详尽的性能压测。
- 误区二：只关注输入层，忽略中间层动态。动态Shape不仅来自输入，还可能来自模型内部的
TensorArray、Loop或NonMaxSuppression等算子。例如，NMS输出的检测框数量是动态的，这会导致后处理部分无法静态化。 - 误区三：固定Shape时未考虑内存对齐。边缘设备的NPU通常要求输入张量的通道数或宽度满足特定对齐要求（如16字节对齐）。若固定Shape时未考虑对齐，可能导致NPU内部内存访问越界。
- 误区四：忽略预处理与后处理的联动。固定输入Shape后，预处理（如归一化、缩放）和后处理（如坐标映射回原图）必须同步调整。否则，即使模型推理正确，最终输出的检测框位置也会偏移。