4、模型文件格式与结构：常见模型格式（ONNX、TensorFlow、PyTorch、TFLite）及其文件内部结构
在设备端解密加载模型之前，我们必须先回答一个根本性问题：我们拿到的加密文件，解密之后到底是什么？ 模型文件的格式决定了加密的粒度、解密后的解析方式、内存中的张量排布以及推理引擎的加载入口。不同格式的模型，其内部结构差异巨大——有的只是一个二进制权重包，有的则是一个包含计算图、算子版本、优化器状态甚至自定义属性的容器。本章将系统拆解四种主流模型格式（ONNX、TensorFlow SavedModel、PyTorch、TFLite）的文件内部结构，并给出在加密解密场景下的关键判断方法和操作要点。
上图展示了四种格式在设备端解密加载链路中的位置。可以看到，无论哪种格式，最终都要经过“解密 → 明文字节流 → 推理引擎解析”这一过程。但不同格式的内部组织方式决定了我们在加密时是整体加密、分片加密还是需要额外处理元数据。下面逐一深入。
4.1 ONNX 格式：Protobuf 序列化的计算图容器
核心原理：ONNX（Open Neural Network Exchange）采用 Google Protobuf 进行序列化，文件后缀为 .onnx。其顶层结构是 ModelProto，内部包含 GraphProto（计算图）、OperatorSetIdProto（算子集版本）、MetadataProps（自定义元数据）等。计算图由 NodeProto（算子节点）、ValueInfoProto（输入输出张量描述）、TensorProto（初始权重）组成。权重以 TensorProto 形式内嵌在 GraphProto 的 initializer 列表中，与算子节点分离存储。
判断方法：在设备端解密后，首先检查文件魔数是否为 Protobuf 的 0x08 起始字段（通常为 08 00 或 08 01 表示 ir_version）。更可靠的方式是使用 ONNX Runtime 的 SessionOptions 加载，若加载失败则说明解密后的字节流损坏或格式不匹配。对于加密设计，ONNX 适合整体文件加密，因为其结构紧凑，无外部依赖。
raw_data 字段，检查前几个字节是否为预期的权重值。但注意，ONNX 的 raw_data 是字节数组，不保证对齐，需按 data_type 解析。
案例拆解：某安防设备部署人脸检测模型，原始模型为 PyTorch，导出为 ONNX 后大小约 120MB。加密时采用 AES-256-GCM 整体加密，解密后直接交给 ONNX Runtime 加载。在调试过程中发现，解密后的文件前 4 字节为 08 00 00 00，但 ONNX Runtime 报错“Invalid protobuf”。进一步排查发现，加密时误将文件头部 16 字节（用于存储 IV）也纳入了密文范围，导致解密后头部被破坏。修正方案：将 IV 存储在密文尾部或单独存储，确保解密后的字节流与原始 ONNX 文件完全一致。
| ONNX 内部结构 | 说明 | 加密影响 |
|---|---|---|
| ModelProto | 顶层容器，含 ir_version、producer_name | 整体加密时无需特殊处理 |
| GraphProto | 计算图定义，含节点和初始权重 | 权重内嵌，适合整体加密 |
| NodeProto | 算子节点，含 op_type、输入输出名 | 解密后需保持节点顺序不变 |
| TensorProto | 权重数据，raw_data 字节流 | 可单独加密权重，但需自定义解析 |
4.2 TensorFlow SavedModel：目录化的多文件格式
核心原理：TensorFlow 的 SavedModel 不是单文件，而是一个目录结构，包含 saved_model.pb（计算图序列化）、variables/ 目录（权重分片，通常为 variables.index + 多个 variables.data-* 分片）、assets/（外部资源文件）以及 fingerprint.pb（指纹信息）。这种设计是为了支持大规模模型的增量保存和分布式训练。
操作流程：在设备端解密时，不能简单地将整个目录加密为一个文件。推荐做法是：先将 SavedModel 目录打包为 tar 或 zip 归档，再对归档文件进行加密。解密后先解包，再加载 saved_model.pb。另一种方案是使用 TensorFlow 的 tf.saved_model.save 时指定 signature，将模型导出为单文件格式（如 TFLite），但这会丢失部分灵活性。
variables/ 目录中的权重分片文件可能非常大（单个分片可达 2GB）。在嵌入式设备上，建议使用 tf.io.gfile 的流式读取，避免一次性加载全部权重到内存。加密时也应考虑分片加密，以便解密后逐片加载。
案例拆解：某车载系统使用 TensorFlow 2.x 训练了语义分割模型，导出为 SavedModel 后包含 3 个权重分片（共 800MB）。设备端存储空间有限，且要求启动时间小于 2 秒。初始方案是整体加密整个目录，但解密后加载耗时 5 秒。优化方案：将 saved_model.pb 单独加密（约 2MB），权重分片使用轻量级 XOR 加密（因为权重本身敏感性较低），解密后使用 tf.compat.v1.saved_model.load_v2 的 experimental_io_device 参数实现分片并行加载。最终启动时间降至 1.2 秒。
| SavedModel 组件 | 文件类型 | 加密策略建议 |
|---|---|---|
| saved_model.pb | Protobuf 二进制 | 强加密（AES-GCM） |
| variables.index | 文本/二进制索引 | 可加密，但需保证与 data 分片一致 |
| variables.data-* | 二进制权重分片 | 可轻量加密或明文（权衡性能） |
| assets/ | 外部文件（词表等） | 按资源敏感性决定 |
fingerprint.pb 包含模型图结构的哈希值。如果解密后修改了任何节点，指纹校验会失败。在调试阶段，可暂时删除 fingerprint.pb，但生产环境必须保留并确保其与计算图一致。
4.3 PyTorch 格式：ZIP 容器与 pickle 序列化
核心原理：PyTorch 的 .pt/.pth 文件本质是一个 ZIP 压缩包，内部包含一个 data.pkl（pickle 序列化的对象）和若干 tensor/ 目录下的权重文件。默认情况下，torch.save 使用 pickle 序列化整个模型对象（包括网络结构定义代码的引用）。这意味着加载时可能需要执行任意 Python 代码，存在安全风险。
判断方法：在设备端解密后，首先检查文件是否为 ZIP 格式（魔数 PK）。使用 unzip -l 查看内部结构。对于纯权重部署，推荐使用 torch.save(model.state_dict(), "model.pt") 只保存权重字典，避免 pickle 执行代码的风险。解密加载时使用 torch.load(..., weights_only=True)（PyTorch 2.0+）或自定义 unpickler 限制允许的类。
state_dict 是一个 OrderedDict，键为层名称（如 conv1.weight），值为张量。在加密场景中，可以只加密张量的原始字节，但需要保留键名和形状信息。推荐做法：将 state_dict 转换为自定义二进制格式（键名表 + 张量数据），再整体加密。
案例拆解：某工业质检设备使用 PyTorch 训练了缺陷检测模型，模型包含自定义 nn.Module 类。最初直接 torch.save(model) 后加密，但在设备端解密加载时，由于设备端 Python 环境缺少训练时的自定义类定义，加载失败。解决方案：改为保存 state_dict，并在设备端定义一个结构相同的 nn.Module 子类，加载时先实例化模型再 load_state_dict。同时，将 state_dict 转换为自定义二进制格式（键名使用哈希表映射），加密后体积减少 15%，加载速度提升 30%。
| PyTorch 保存方式 | 内部结构 | 安全性 | 推荐场景 |
|---|---|---|---|
| torch.save(model) | pickle 完整对象 | 低（可执行任意代码） | 仅限可信环境 |
| torch.save(state_dict) | pickle 字典 | 中（需限制类） | 设备端部署 |
| 自定义二进制 | 键名表+张量数据 | 高（无代码执行） | 高安全要求 |
torch.load 加载来自不可信来源的模型文件，即使文件已解密。pickle 反序列化可以触发 __reduce__ 方法执行系统命令。务必使用 weights_only=True 或自定义 pickle.Unpickler 白名单机制。
4.4 TFLite 格式：FlatBuffers 的零拷贝设计
核心原理：TFLite 文件使用 FlatBuffers 序列化，后缀为 .tflite。FlatBuffers 是一种零拷贝的序列化库，数据在内存中的布局与文件中的布局一致，加载时无需解析即可直接访问。TFLite 文件内部包含 Model 结构，其中有 operator_codes（算子类型表）、subgraphs（计算图，通常只有一个）、buffers（权重数据缓冲区）。权重存储在 buffers 中，通过 tensors 的 buffer 索引引用。
操作流程：TFLite 的加密解密相对简单，因为其结构紧凑且无外部依赖。推荐整体加密。解密后，使用 tflite::FlatBufferModel::BuildFromBuffer 加载。注意，TFLite 的 buffers 中的数据是原始字节，可能包含量化参数（scale/zero_point），这些信息存储在 tensors 的 quantization 字段中。
aligned_alloc 分配解密缓冲区，或使用 memcpy 到对齐地址。
案例拆解：某智能音箱设备使用 TFLite 部署唤醒词检测模型，模型大小 2.3MB。设备端使用硬件安全模块（HSM）存储 AES 密钥，解密在 TrustZone 中完成。初始实现中，解密后的数据直接传递给 BuildFromBuffer，但偶发崩溃。分析发现，TrustZone 返回的缓冲区地址为 0x1000 对齐，但 TFLite 内部某些算子要求 64 字节对齐。解决方案：在解密后增加一次 memcpy 到 64 字节对齐的堆缓冲区，崩溃率降为零。
| TFLite 内部结构 | 作用 | 解密注意事项 |
|---|---|---|
| Model | 顶层容器 | 整体加密即可 |
| operator_codes | 算子类型注册表 | 解密后需保持顺序 |
| subgraphs | 计算图定义 | 包含输入输出张量索引 |
| buffers | 权重数据存储 | 注意对齐要求 |
4.5 格式对比与选型建议
在设备端解密加载场景中，格式选择直接影响加密方案的设计复杂度。下表从多个维度对比四种格式：
| 维度 | ONNX | TF SavedModel | PyTorch | TFLite |
|---|---|---|---|---|
| 文件形态 | 单文件 | 目录（多文件） | 单文件（ZIP） | 单文件 |
| 序列化方式 | Protobuf | Protobuf + 分片 | Pickle + ZIP | FlatBuffers |
| 加密粒度 | 整体加密 | 归档后整体加密 | 整体或自定义 | 整体加密 |
| 加载依赖 | ONNX Runtime | TF Lite/RT | LibTorch | TFLite Runtime |
| 安全风险 | 低 | 中（多文件） | 高（pickle） | 低 |
| 嵌入式适配 | 中 | 差 | 中 | 优 |
选型建议：对于资源受限的嵌入式设备，优先选择 TFLite 或 ONNX；对于需要保留训练细节的调试场景，可使用 PyTorch 但必须处理 pickle 风险；对于已有 TensorFlow 生态的团队，SavedModel 是自然选择，但需注意多文件加密的复杂性。