PyTorch为何推荐保存state dict而非直接序列化模型、优化器对象

你当前直接序列化对象没遇到问题，本质是序列化和加载的运行环境、项目代码结构、PyTorch版本、模型类定义完全一致，但这种方式存在很多隐性问题，官方推荐state dict方案的核心原因如下：

• 跨环境兼容性更强
  直接用pickle/dill序列化的对象和模型类的定义位置、类结构、PyTorch版本强绑定。比如后续你调整了模型类的存放路径、修改了类初始化参数、升级了PyTorch版本，反序列化时会直接报错。而state dict是纯Python字典结构，只存储参数的键值对，只要模型结构和参数维度匹配，不管类定义怎么调整、用什么版本的PyTorch，都可以正常加载，适合长期存储、跨设备跨环境共享checkpoint。
• 存储体积更小更干净
  直接序列化对象会把大量冗余信息一同存储，包括模型运行时的临时梯度缓存、中间变量、优化器绑定的上下文，甚至你运行时的无关参数、进程状态都会被写入，导致checkpoint体积异常膨胀。而state dict仅存储必要的模型参数、优化器状态等核心训练数据，体积要小很多，也不会携带无关的运行时信息。
• 安全性更高
  pickle/dill反序列化时会自动执行存储对象的构造代码，如果checkpoint被恶意篡改，加载时会直接执行植入的恶意代码，存在严重的安全风险。而加载state dict只是给现有对象赋值纯数据，不会执行任意代码，安全性更高。
• 使用灵活性更高
  存state dict支持非常灵活的参数复用场景：比如做迁移学习时，可以只加载匹配层的参数，剩下的层随机初始化；调整优化器类型时，可以直接复用旧优化器里的参数状态；甚至可以方便地提取部分参数做分析、finetune。直接序列化的对象和原类强绑定，几乎无法支持这些灵活的操作。

如果你是个人小项目、仅在自己的固定环境下使用，直接序列化对象确实可以减少代码量，但如果是需要长期维护、跨团队共享、后续还要迭代模型的项目，还是更推荐使用官方的state dict存储方案。

内容的提问来源于stack exchange，提问作者Charlie Parker