3、Shape规范：张量形状（Shape）的定义、维度顺序（NHWC/NCHW）、动态形状与静态形状、批量维度处理
在TFLite Micro的模型部署流程中，张量形状（Shape）是解释器与内核算子之间最基础的契约。一个形状定义错误，往往不会在模型转换阶段暴露，而是在运行时触发内存越界、算子崩溃或输出数据错位。与桌面端TFLite不同，TFLite Micro运行在资源受限的MCU上，没有动态内存分配器兜底，也没有操作系统保护进程，因此形状规范必须做到“静态可验证、逐字节精确”。本章将围绕形状的定义方式、维度顺序约定、静态与动态形状的取舍，以及批量维度的处理策略展开，帮助你在模型转换和C++代码编写阶段就消除形状隐患。
3.1 张量形状的核心定义与存储结构
在TFLite Micro中，张量形状由TfLiteTensor结构体中的dims字段描述。该字段是一个TfLiteIntArray类型的指针，其内部包含两个关键成员：size表示维度数量（即张量的秩），data[]数组按从外到内的顺序存储每一维的大小。例如，一个形状为[1, 32, 32, 3]的四维张量，其size=4，data[0]=1（批量维度），data[1]=32（高度），data[2]=32（宽度），data[3]=3（通道数）。
理解这个存储结构至关重要，因为所有TFLite Micro内置算子（如卷积、全连接、池化）在实现时都直接通过dims->data[i]来索引维度大小，而不是像Python端那样使用元组。这意味着在C++代码中，你无法依赖Python风格的负索引或切片操作，必须显式地通过索引访问每一维。此外，TfLiteIntArray是扁平化的内存结构，其实际分配大小等于sizeof(TfLiteIntArray) + size * sizeof(int)，在内存规划时必须精确计算。
[1, 40, 20]），4维则是卷积神经网络的标准输入输出格式。超过4维的张量在转换时会被拒绝或降维处理，因为MCU上的算子内核极少支持高维张量。
3.2 维度顺序：NHWC与NCHW的工程抉择
TensorFlow模型默认使用NHWC（Batch, Height, Width, Channels）作为图像张量的维度顺序，这也是TFLite Micro内部唯一原生支持的布局。然而，许多训练框架（如PyTorch）或硬件加速器（如某些NPU、DSP）使用NCHW（Batch, Channels, Height, Width）布局。当模型从这些框架转换到TFLite时，转换器通常会在模型中插入转置（Transpose）节点，将NCHW转换为NHWC。但TFLite Micro的转换工具（如tfliteconvert）并不会自动完成这一操作，需要你在转换前手动调整模型输入输出的维度顺序。
| 布局 | 维度含义 | 内存访问模式 | TFLite Micro支持 | 典型场景 |
|---|---|---|---|---|
| NHWC | [Batch, Height, Width, Channels] | 通道维连续存储，空间维跨步 | 原生支持 | 标准CNN、图像分类、目标检测 |
| NCHW | [Batch, Channels, Height, Width] | 空间维连续存储，通道维跨步 | 需转换或插入转置 | PyTorch导出、部分NPU加速器 |
| HWC（无批量） | [Height, Width, Channels] | 与NHWC相同，仅去掉批量维 | 支持（3维） | 单帧图像处理、传感器数据 |
| CHW（无批量） | [Channels, Height, Width] | 与NCHW相同，仅去掉批量维 | 需转换 | 医学影像、科学计算 |
在实际部署中，建议在模型训练阶段就统一使用NHWC布局，避免在转换时引入额外的转置算子。如果必须处理NCHW模型，可以在转换命令中通过--input-format和--output-format参数指定布局转换，或者在模型输入层之前手动添加一个Reshape+Transpose的组合。但需要注意，每增加一个转置算子，都会增加推理延迟和内存占用，在MCU上尤其明显。
3.3 静态形状与动态形状：MCU上的唯一选择
TFLite Micro严格遵循“静态形状”原则，即所有张量的形状必须在模型转换时完全确定，并且在推理过程中不可改变。这与桌面端TFLite支持动态形状（如set_shape或resize_input）形成鲜明对比。原因在于MCU的内存管理机制：TFLite Micro在初始化阶段会一次性分配所有张量的内存（包括中间激活张量），如果形状在运行时变化，内存规划将无法进行。
动态形状在以下场景中会出现：
- 模型输入尺寸可变（如不同分辨率的图像）
- 循环神经网络的时间步长不固定
- 使用了
tf.shape或tf.reshape等动态维度操作
解决策略是：在转换前将所有动态维度固定为最大值，或者将模型拆分为多个静态子图。例如，对于可变分辨率输入，可以固定为[1, 224, 224, 3]，在预处理阶段将图像缩放或填充到该尺寸。对于变长时间步的RNN，可以固定为最大序列长度，并在推理时用掩码忽略无效部分。
dims数组，解释器在内存分配时仍会按照原始FlatBuffer中的形状进行规划，导致内存越界或数据错位。正确的做法是回到模型定义阶段，用None替换所有动态维度，并指定具体数值。
3.4 批量维度处理：从训练到推理的降维
批量维度（Batch）是形状规范中最容易被忽视的环节。在训练阶段，批量大小通常为32、64或128，以充分利用GPU并行能力。但在MCU推理阶段，批量大小必须固定为1，因为设备通常只处理单帧数据。TFLite Micro的转换器会自动将批量维度压缩为1，但前提是模型在导出时没有将批量维度设置为None。
批量维度处理有三种常见模式：
- 固定批量=1：在模型定义时直接使用
tf.keras.Input(shape=(224,224,3), batch_size=1)，这是最推荐的方式，转换后形状为[1, 224, 224, 3]。 - 动态批量转固定：训练时使用
batch_size=None，转换时通过--input-shape=1,224,224,3参数指定固定批量。 - 多批量循环推理：如果确实需要处理多帧数据（如连续音频帧），可以在C++代码中循环调用
Invoke()，每次处理一个样本，而不是一次性输入整个批量。
在内存规划时，批量维度直接影响中间张量的大小。例如，一个卷积层输出形状为[1, 112, 112, 32]，如果批量变为2，则输出张量大小翻倍，可能导致内存不足。因此，在arena_size计算时，必须确保批量维度为1。
3.5 案例拆解：一个图像分类模型的形状排查
假设我们有一个MobileNetV2图像分类模型，训练时输入形状为(None, 224, 224, 3)，批量维度为None。在转换为TFLite Micro格式后，我们使用tflite::MicroInterpreter加载模型，但在调用Invoke()时出现内存访问冲突。
初始现象：程序在第一个卷积层执行时崩溃，错误信息指向dims->data[0]的值为0。
分析过程：通过打印输入张量的dims信息，发现形状为[0, 224, 224, 3]，批量维度被错误地设置为0。进一步检查转换命令，发现使用了--input-shape=1,224,224,3，但模型输入层定义的是batch_size=None，导致转换器将批量维度推断为0。
解决步骤：
- 在模型定义中显式指定
batch_size=1，重新导出SavedModel。 - 使用
tfliteconvert --input-shape=1,224,224,3重新转换。 - 在C++代码中增加形状断言：
if (input->dims->data[0] != 1) { error(); }
结果对比：修复后，输入形状正确为[1, 224, 224, 3]，推理正常完成，内存占用从预期的320KB降至实际规划的280KB。
复盘经验：批量维度为0的问题在桌面端TFLite中不会出现（因为桌面端允许动态批量），但在TFLite Micro中会直接导致内存分配失败。建议在模型转换后立即打印所有张量的形状，并与模型定义进行比对。
3.6 常见误区与总结复盘
在形状规范方面，开发者常犯以下错误：
- 混淆维度顺序：将PyTorch的NCHW模型直接转换，忘记调整布局，导致通道维与空间维错位。
- 忽略标量张量：某些算子（如偏置加法）的偏置张量是1维或0维，在内存规划时容易遗漏。
- 手动修改dims数组：在运行时尝试通过
tensor->dims->data[0] = 2来改变形状，这会导致内存越界。 - 未检查维度乘积溢出：当形状为
[1, 512, 512, 256]时，元素总数超过2^31，在计算字节数时需要使用size_t类型。