PyTorch Lightning 1.7 升级指南常规变更篇Logger、学习率调度器与检查点钩子的全面迁移【免费下载链接】pytorch-lightningPretrain, finetune ANY AI model of ANY size on 1 or 10,000 GPUs with zero code changes.项目地址: https://gitcode.com/gh_mirrors/py/pytorch-lightning本篇指南聚焦 PyTorch Lightning 从 1.6 升级到 1.7 过程中面向常规用户regular users的破坏性变更覆盖多 Logger 管理、学习率调度器访问方式、NeptuneLogger API、DataModule 与 LightningModule 的检查点钩子重命名以及weights_save_path的移除等 8 项改动。读完本文你将掌握每个变更的旧写法与新写法对照、替换后代码的真实行为差异以及底层源码与测试对迁移结果的具体验证方式可据此快速完成现有训练脚本的升级。升级背景为什么需要单独关注 1.7 常规变更PyTorch Lightning 在 CHANGELOG.md 中按版本记录了全部 API 变化。1.7 版本有一批面向常规用户的接口调整它们不像高级特性那样需要重写训练逻辑但如果不加迁移升级后会出现AttributeError、TypeError或静默行为变化例如钩子不再被调用。本指南依据官方升级文档 1_7_regular.rst 的旧用法 → 新用法对照表逐项展开说明并结合当前仓库源码给出验证依据。下面按变更类型分四组讲解多 Logger、学习率调度器、检查点钩子、权重保存路径。一、多 Logger告别LoggerCollection拥抱trainer.loggers旧写法与问题在 1.7 之前如果希望同时使用多个 Logger例如同时写 TensorBoard 和 CSV常见的做法是手动把它们包装进LoggerCollectionfrom lightning.pytorch.loggers import LoggerCollection, TensorBoardLogger, CSVLogger logger LoggerCollection([TensorBoardLogger(logs/tb), CSVLogger(logs/csv)]) trainer Trainer(loggerlogger)这种方式的问题在于LoggerCollection是一个额外包装层访问具体 Logger 时需要解包而且历史上它只返回唯一的 logger 名称与版本见 CHANGELOG 中 PR10976 的说明语义不够直观。新写法从 1.7 开始Trainer直接接受 Logger 列表并通过trainer.loggers属性访问完整列表from lightning.pytorch.loggers import TensorBoardLogger, CSVLogger trainer Trainer(loggers[TensorBoardLogger(logs/tb), CSVLogger(logs/csv)]) # 遍历所有 logger for logger in trainer.loggers: logger.log_metrics({loss: 0.5}, step1)LoggerCollection在 1.7 中被彻底移除PR14283并且语义调整为Trainer.logger与LightningModule.logger在传入多个 Logger 时返回第一个 LoggerPR14283。源码验证trainer.loggers的实现在 trainer.py 中loggers是一个带 setter 的 propertyproperty def loggers(self) - list[Logger]: The list of :class:~lightning.pytorch.loggers.logger.Logger used. return self._loggers loggers.setter def loggers(self, loggers: Optional[list[Logger]]) - None: self._loggers loggers if loggers else []可以看到返回类型是list[Logger]可以直接用列表语义遍历、索引setter 会将None归一为空列表因此Trainer(loggersNone)依然合法内部_loggers始终是列表。仓库中的 test_loggers.py 专门覆盖了trainer.loggers这一属性的行为可作为迁移后行为正确性的参考测试。二、学习率调度器Trainer.lr_schedulers→trainer.lr_scheduler_configs变更内容Trainer.lr_schedulers属性在 1.7 中被移除PR14408替代品是trainer.lr_scheduler_configs。关键差异在于返回值类型新接口返回的是LRSchedulerConfigdataclass 列表而不是字典列表PR11443。旧写法字典列表for config in trainer.lr_schedulers: scheduler config[scheduler] interval config[interval]新写法dataclass 列表属性访问for config in trainer.lr_scheduler_configs: scheduler config.scheduler interval config.interval源码验证LRSchedulerConfig的完整字段在 types.py 中LRSchedulerConfig定义如下dataclass class LRSchedulerConfig: scheduler: Union[LRScheduler, ReduceLROnPlateau] name: Optional[str] None # 自定义调度器名称 interval: str epoch # 更新时机epoch 或 step frequency: int 1 # 每 N 个 interval 更新一次 reduce_on_plateau: bool False # 是否为 ReduceLROnPlateau 型 monitor: Optional[str] None # ReduceLROnPlateau 监控的指标 strict: bool True # 是否强制要求 monitor 指标存在字段说明interval默认epoch可设为step实现按 batch 更新reduce_on_plateauTrue时必须配合monitor指定被监控的验证指标且strictTrue会强制要求该指标确实存在否则报错frequency控制每隔多少个 interval 才更新一次。同时Trainer.lr_scheduler_configs属性在 trainer.py 中直接透传策略层的配置列表property def lr_scheduler_configs(self) - list[LRSchedulerConfig]: return self.strategy.lr_scheduler_configs因此该接口对 DDP、DeepSpeed、FSDP 等不同策略均生效。仓库中 test_optimizers.py、test_lr_monitor.py 等测试均基于新接口编写迁移后这些测试即为行为基准。三、NeptuneLogger升级到最新neptune-clientAPI1.7 中NeptuneLogger移除了对旧版neptune-clientAPI 的支持PR14727。如果此前在NeptuneLogger中使用的是旧版 Neptune SDK 的调用方式升级后需要同步升级到 Neptune 最新 API。迁移要点将项目依赖中的neptune-client升级到支持新 API 的版本并按 Neptune 官方迁移说明调整 Logger 的初始化参数与指标上传方式仓库 CHANGELOG 中后续版本也持续修复过NeptuneLogger相关问题例如 PR19126 恢复step参数、PR19130 支持 Remote Stop/Abort、PR20581 修复检查点文件扩展名说明该 Logger 与 Neptune 服务端 API 的版本绑定较紧升级时建议同时核对当前 Lightning 版本对应的 Neptune 集成行为。从当前仓库看NeptuneLogger的实现在 src/lightning/pytorch/loggers 目录下随版本演进升级代码时以该版本实际导出的NeptuneLogger签名为准。四、检查点钩子重命名DataModule 与 LightningModule 的统一步伐4.1 DataModuleon_save→on_save_checkpoint旧钩子LightningDataModule.on_save在 1.7 中被重命名为on_save_checkpointPR11887class MyDataModule(LightningDataModule): # 旧写法1.7 起失效 def on_save(self, checkpoint): checkpoint[dm_state] self.my_state # 新写法 def on_save_checkpoint(self, checkpoint): checkpoint[dm_state] self.my_state4.2 DataModuleon_load_checkpoint保持名称语义不变LightningDataModule.on_load_checkpoint钩子本身没有改名仍叫on_load_checkpoint迁移时只需确认实现与on_save_checkpoint对称成对即可def on_load_checkpoint(self, checkpoint): self.my_state checkpoint.get(dm_state)注意升级文档中该行对照的旧写法实际上也是on_load_checkpoint它强调的是与on_save→on_save_checkpoint重命名配套后DataModule 检查点读写两侧钩子名称的统一。4.3 LightningModuleon_hpc_load/on_hpc_save迁移到通用钩子1.7 移除了LightningModule.on_hpc_load与LightningModule.on_hpc_save两个专属钩子PR14315统一迁移到通用的检查点钩子class MyModel(LightningModule): # 旧写法on_hpc_save / on_hpc_load def on_hpc_save(self, checkpoint): checkpoint[model_extra] self.extra # 新写法通用钩子 def on_save_checkpoint(self, checkpoint): checkpoint[model_extra] self.extra def on_load_checkpoint(self, checkpoint): self.extra checkpoint.get(model_extra)源码验证CheckpointHooks与钩子语义on_save_checkpoint/on_load_checkpoint的定义位于 hooks.py 的CheckpointHooks类中on_save_checkpoint(checkpoint)在保存检查点时被调用允许你向checkpoint字典中插入任何额外内容最终随整个检查点一起落盘on_load_checkpoint(checkpoint)在恢复模型时被调用用于从checkpoint中还原此前保存的状态。Lightning 会自动恢复 global step、epoch、训练状态及 AMP 缩放无需在此手动处理训练相关状态。这两个钩子同时被LightningModule通过CheckpointHooks与LightningDataModule通过 datamodule.py 中LightningDataModule(DataHooks, HyperparametersMixin)的继承链所使用这正是 1.7 将 HPC 专属钩子合并进通用检查点钩子的原因——统一入口、统一语义。迁移核对建议在LightningModule与LightningDataModule中搜索on_hpc_save/on_hpc_load/on_save全部替换为上述通用钩子确认on_save_checkpoint与on_load_checkpoint成对出现且写入与读取的 key 一致通过 test_restore.py 等恢复相关测试验证保存/加载闭环。五、权重保存路径weights_save_path移除改用ModelCheckpoint(dirpath...)变更内容Trainer构造参数weights_save_path在 1.7 中被移除PR14424同时Trainer.weights_save_path属性也被删除。这一改动的原因是检查点保存路径本质上属于ModelCheckpoint回调的职责放在 Trainer 上会造成职责重叠与路径拼接歧义例如日志目录与权重目录的耦合。新写法旧写法trainer Trainer(weights_save_pathmy/weights)新写法在ModelCheckpoint回调中指定dirpathfrom lightning.pytorch.callbacks import ModelCheckpoint checkpoint_callback ModelCheckpoint(dirpathmy/weights, filename{epoch}-{step}) trainer Trainer(callbacks[checkpoint_callback])源码验证ModelCheckpoint.dirpath的参数语义在 model_checkpoint.py 中dirpath参数说明如下指定检查点保存目录例如dirpathmy/path/支持远程文件系统路径如s3://mybucket/path/或hdfs://path/默认None时只把最优的 k 个检查点保存在内存中不落盘filename支持格式化占位符例如filename{epoch}-{val_loss:.2f}-{other_metric:.2f}会生成my/path/epoch2-val_loss0.02-other_metric0.03.ckpt这样的文件在 DDP 等分布式环境下文档明确建议提供dirpath以避免多个进程竞争写同一个默认路径导致竞态条件。一个值得注意的历史行为变化在弃用过渡期1.5/1.6当用户同时传入weights_save_path与 Logger 时检查点路径曾被拼接为weights_save_path/name/version/checkpoints或weights_save_path/name1_name2/version1_version2/checkpointsPR123721.7 移除该参数后路径完全由ModelCheckpoint.dirpath决定不再受 Logger 目录影响路径更加可预期。迁移核对建议搜索代码中的weights_save_path将其迁移到ModelCheckpoint(dirpath...)若原来依赖权重与日志同目录的行为迁移后需显式将dirpath指向你想要的路径用 test_model_checkpoint.py 覆盖的路径生成逻辑验证最终文件落点。六、迁移检查清单1.6 → 1.7对照下表逐项检查你的代码库可一次性完成全部常规变更迁移检查项旧写法新写法多 LoggerLoggerCollection([...])包装后传入Trainer(loggers[...])trainer.loggers访问学习率调度器trainer.lr_schedulers字典列表trainer.lr_scheduler_configsLRSchedulerConfigdataclass 列表NeptuneLogger旧版neptune-clientAPI升级到最新 Neptune APIDataModule 保存钩子on_saveon_save_checkpointDataModule 加载钩子on_load_checkpoint名称不变保持on_load_checkpoint与保存钩子成对Module HPC 保存钩子on_hpc_saveon_save_checkpointModule HPC 加载钩子on_hpc_loadon_load_checkpoint权重保存路径Trainer(weights_save_path...)ModelCheckpoint(dirpath...)Trainer.weights_save_path属性读取该属性已删除改用回调的dirpath七、升级后的验证方法完成代码替换后建议从三个层面验证迁移正确性属性级验证确认trainer.loggers返回list[Logger]可遍历、可索引trainer.lr_scheduler_configs返回list[LRSchedulerConfig]字段用点号访问。这两个属性的行为分别由 test_loggers.py 与 test_optimizers.py、test_lr_monitor.py 等测试保证可作为回归参照。钩子级验证在LightningModule/LightningDataModule的on_save_checkpoint/on_load_checkpoint中打印或断言写入的键值跑一个极短训练后确认保存与恢复闭环。参考 test_restore.py 中模型状态恢复的测试模式。路径级验证训练完成后检查dirpath指向的目录下是否生成了预期格式的.ckpt文件并确认分布式如 DDP环境下没有因默认路径竞争而产生的异常相关逻辑可对照 model_checkpoint.py 的实现与检查点测试套件 test_model_checkpoint.py。需要说明的是以上变更在 1.7 中属于移除级别而非仅弃用告警因此升级后旧写法会直接报错或不再生效不存在过渡窗口若你仍在使用 1.6 及更早版本可在 CHANGELOG 对应版本段落找到各 API 首次弃用的时间点提前规划迁移。【免费下载链接】pytorch-lightningPretrain, finetune ANY AI model of ANY size on 1 or 10,000 GPUs with zero code changes.项目地址: https://gitcode.com/gh_mirrors/py/pytorch-lightning创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PyTorch Lightning 1.7 升级指南（常规变更篇）：Logger、学习率调度器与检查点钩子的全面迁移
PyTorch Lightning 1.7 升级指南常规变更篇Logger、学习率调度器与检查点钩子的全面迁移【免费下载链接】pytorch-lightningPretrain, finetune ANY AI model of ANY size on 1 or 10,000 GPUs with zero code changes.项目地址: https://gitcode.com/gh_mirrors/py/pytorch-lightning本篇指南聚焦 PyTorch Lightning 从 1.6 升级到 1.7 过程中面向常规用户regular users的破坏性变更覆盖多 Logger 管理、学习率调度器访问方式、NeptuneLogger API、DataModule 与 LightningModule 的检查点钩子重命名以及weights_save_path的移除等 8 项改动。读完本文你将掌握每个变更的旧写法与新写法对照、替换后代码的真实行为差异以及底层源码与测试对迁移结果的具体验证方式可据此快速完成现有训练脚本的升级。升级背景为什么需要单独关注 1.7 常规变更PyTorch Lightning 在 CHANGELOG.md 中按版本记录了全部 API 变化。1.7 版本有一批面向常规用户的接口调整它们不像高级特性那样需要重写训练逻辑但如果不加迁移升级后会出现AttributeError、TypeError或静默行为变化例如钩子不再被调用。本指南依据官方升级文档 1_7_regular.rst 的旧用法 → 新用法对照表逐项展开说明并结合当前仓库源码给出验证依据。下面按变更类型分四组讲解多 Logger、学习率调度器、检查点钩子、权重保存路径。一、多 Logger告别LoggerCollection拥抱trainer.loggers旧写法与问题在 1.7 之前如果希望同时使用多个 Logger例如同时写 TensorBoard 和 CSV常见的做法是手动把它们包装进LoggerCollectionfrom lightning.pytorch.loggers import LoggerCollection, TensorBoardLogger, CSVLogger logger LoggerCollection([TensorBoardLogger(logs/tb), CSVLogger(logs/csv)]) trainer Trainer(loggerlogger)这种方式的问题在于LoggerCollection是一个额外包装层访问具体 Logger 时需要解包而且历史上它只返回唯一的 logger 名称与版本见 CHANGELOG 中 PR10976 的说明语义不够直观。新写法从 1.7 开始Trainer直接接受 Logger 列表并通过trainer.loggers属性访问完整列表from lightning.pytorch.loggers import TensorBoardLogger, CSVLogger trainer Trainer(loggers[TensorBoardLogger(logs/tb), CSVLogger(logs/csv)]) # 遍历所有 logger for logger in trainer.loggers: logger.log_metrics({loss: 0.5}, step1)LoggerCollection在 1.7 中被彻底移除PR14283并且语义调整为Trainer.logger与LightningModule.logger在传入多个 Logger 时返回第一个 LoggerPR14283。源码验证trainer.loggers的实现在 trainer.py 中loggers是一个带 setter 的 propertyproperty def loggers(self) - list[Logger]: The list of :class:~lightning.pytorch.loggers.logger.Logger used. return self._loggers loggers.setter def loggers(self, loggers: Optional[list[Logger]]) - None: self._loggers loggers if loggers else []可以看到返回类型是list[Logger]可以直接用列表语义遍历、索引setter 会将None归一为空列表因此Trainer(loggersNone)依然合法内部_loggers始终是列表。仓库中的 test_loggers.py 专门覆盖了trainer.loggers这一属性的行为可作为迁移后行为正确性的参考测试。二、学习率调度器Trainer.lr_schedulers→trainer.lr_scheduler_configs变更内容Trainer.lr_schedulers属性在 1.7 中被移除PR14408替代品是trainer.lr_scheduler_configs。关键差异在于返回值类型新接口返回的是LRSchedulerConfigdataclass 列表而不是字典列表PR11443。旧写法字典列表for config in trainer.lr_schedulers: scheduler config[scheduler] interval config[interval]新写法dataclass 列表属性访问for config in trainer.lr_scheduler_configs: scheduler config.scheduler interval config.interval源码验证LRSchedulerConfig的完整字段在 types.py 中LRSchedulerConfig定义如下dataclass class LRSchedulerConfig: scheduler: Union[LRScheduler, ReduceLROnPlateau] name: Optional[str] None # 自定义调度器名称 interval: str epoch # 更新时机epoch 或 step frequency: int 1 # 每 N 个 interval 更新一次 reduce_on_plateau: bool False # 是否为 ReduceLROnPlateau 型 monitor: Optional[str] None # ReduceLROnPlateau 监控的指标 strict: bool True # 是否强制要求 monitor 指标存在字段说明interval默认epoch可设为step实现按 batch 更新reduce_on_plateauTrue时必须配合monitor指定被监控的验证指标且strictTrue会强制要求该指标确实存在否则报错frequency控制每隔多少个 interval 才更新一次。同时Trainer.lr_scheduler_configs属性在 trainer.py 中直接透传策略层的配置列表property def lr_scheduler_configs(self) - list[LRSchedulerConfig]: return self.strategy.lr_scheduler_configs因此该接口对 DDP、DeepSpeed、FSDP 等不同策略均生效。仓库中 test_optimizers.py、test_lr_monitor.py 等测试均基于新接口编写迁移后这些测试即为行为基准。三、NeptuneLogger升级到最新neptune-clientAPI1.7 中NeptuneLogger移除了对旧版neptune-clientAPI 的支持PR14727。如果此前在NeptuneLogger中使用的是旧版 Neptune SDK 的调用方式升级后需要同步升级到 Neptune 最新 API。迁移要点将项目依赖中的neptune-client升级到支持新 API 的版本并按 Neptune 官方迁移说明调整 Logger 的初始化参数与指标上传方式仓库 CHANGELOG 中后续版本也持续修复过NeptuneLogger相关问题例如 PR19126 恢复step参数、PR19130 支持 Remote Stop/Abort、PR20581 修复检查点文件扩展名说明该 Logger 与 Neptune 服务端 API 的版本绑定较紧升级时建议同时核对当前 Lightning 版本对应的 Neptune 集成行为。从当前仓库看NeptuneLogger的实现在 src/lightning/pytorch/loggers 目录下随版本演进升级代码时以该版本实际导出的NeptuneLogger签名为准。四、检查点钩子重命名DataModule 与 LightningModule 的统一步伐4.1 DataModuleon_save→on_save_checkpoint旧钩子LightningDataModule.on_save在 1.7 中被重命名为on_save_checkpointPR11887class MyDataModule(LightningDataModule): # 旧写法1.7 起失效 def on_save(self, checkpoint): checkpoint[dm_state] self.my_state # 新写法 def on_save_checkpoint(self, checkpoint): checkpoint[dm_state] self.my_state4.2 DataModuleon_load_checkpoint保持名称语义不变LightningDataModule.on_load_checkpoint钩子本身没有改名仍叫on_load_checkpoint迁移时只需确认实现与on_save_checkpoint对称成对即可def on_load_checkpoint(self, checkpoint): self.my_state checkpoint.get(dm_state)注意升级文档中该行对照的旧写法实际上也是on_load_checkpoint它强调的是与on_save→on_save_checkpoint重命名配套后DataModule 检查点读写两侧钩子名称的统一。4.3 LightningModuleon_hpc_load/on_hpc_save迁移到通用钩子1.7 移除了LightningModule.on_hpc_load与LightningModule.on_hpc_save两个专属钩子PR14315统一迁移到通用的检查点钩子class MyModel(LightningModule): # 旧写法on_hpc_save / on_hpc_load def on_hpc_save(self, checkpoint): checkpoint[model_extra] self.extra # 新写法通用钩子 def on_save_checkpoint(self, checkpoint): checkpoint[model_extra] self.extra def on_load_checkpoint(self, checkpoint): self.extra checkpoint.get(model_extra)源码验证CheckpointHooks与钩子语义on_save_checkpoint/on_load_checkpoint的定义位于 hooks.py 的CheckpointHooks类中on_save_checkpoint(checkpoint)在保存检查点时被调用允许你向checkpoint字典中插入任何额外内容最终随整个检查点一起落盘on_load_checkpoint(checkpoint)在恢复模型时被调用用于从checkpoint中还原此前保存的状态。Lightning 会自动恢复 global step、epoch、训练状态及 AMP 缩放无需在此手动处理训练相关状态。这两个钩子同时被LightningModule通过CheckpointHooks与LightningDataModule通过 datamodule.py 中LightningDataModule(DataHooks, HyperparametersMixin)的继承链所使用这正是 1.7 将 HPC 专属钩子合并进通用检查点钩子的原因——统一入口、统一语义。迁移核对建议在LightningModule与LightningDataModule中搜索on_hpc_save/on_hpc_load/on_save全部替换为上述通用钩子确认on_save_checkpoint与on_load_checkpoint成对出现且写入与读取的 key 一致通过 test_restore.py 等恢复相关测试验证保存/加载闭环。五、权重保存路径weights_save_path移除改用ModelCheckpoint(dirpath...)变更内容Trainer构造参数weights_save_path在 1.7 中被移除PR14424同时Trainer.weights_save_path属性也被删除。这一改动的原因是检查点保存路径本质上属于ModelCheckpoint回调的职责放在 Trainer 上会造成职责重叠与路径拼接歧义例如日志目录与权重目录的耦合。新写法旧写法trainer Trainer(weights_save_pathmy/weights)新写法在ModelCheckpoint回调中指定dirpathfrom lightning.pytorch.callbacks import ModelCheckpoint checkpoint_callback ModelCheckpoint(dirpathmy/weights, filename{epoch}-{step}) trainer Trainer(callbacks[checkpoint_callback])源码验证ModelCheckpoint.dirpath的参数语义在 model_checkpoint.py 中dirpath参数说明如下指定检查点保存目录例如dirpathmy/path/支持远程文件系统路径如s3://mybucket/path/或hdfs://path/默认None时只把最优的 k 个检查点保存在内存中不落盘filename支持格式化占位符例如filename{epoch}-{val_loss:.2f}-{other_metric:.2f}会生成my/path/epoch2-val_loss0.02-other_metric0.03.ckpt这样的文件在 DDP 等分布式环境下文档明确建议提供dirpath以避免多个进程竞争写同一个默认路径导致竞态条件。一个值得注意的历史行为变化在弃用过渡期1.5/1.6当用户同时传入weights_save_path与 Logger 时检查点路径曾被拼接为weights_save_path/name/version/checkpoints或weights_save_path/name1_name2/version1_version2/checkpointsPR123721.7 移除该参数后路径完全由ModelCheckpoint.dirpath决定不再受 Logger 目录影响路径更加可预期。迁移核对建议搜索代码中的weights_save_path将其迁移到ModelCheckpoint(dirpath...)若原来依赖权重与日志同目录的行为迁移后需显式将dirpath指向你想要的路径用 test_model_checkpoint.py 覆盖的路径生成逻辑验证最终文件落点。六、迁移检查清单1.6 → 1.7对照下表逐项检查你的代码库可一次性完成全部常规变更迁移检查项旧写法新写法多 LoggerLoggerCollection([...])包装后传入Trainer(loggers[...])trainer.loggers访问学习率调度器trainer.lr_schedulers字典列表trainer.lr_scheduler_configsLRSchedulerConfigdataclass 列表NeptuneLogger旧版neptune-clientAPI升级到最新 Neptune APIDataModule 保存钩子on_saveon_save_checkpointDataModule 加载钩子on_load_checkpoint名称不变保持on_load_checkpoint与保存钩子成对Module HPC 保存钩子on_hpc_saveon_save_checkpointModule HPC 加载钩子on_hpc_loadon_load_checkpoint权重保存路径Trainer(weights_save_path...)ModelCheckpoint(dirpath...)Trainer.weights_save_path属性读取该属性已删除改用回调的dirpath七、升级后的验证方法完成代码替换后建议从三个层面验证迁移正确性属性级验证确认trainer.loggers返回list[Logger]可遍历、可索引trainer.lr_scheduler_configs返回list[LRSchedulerConfig]字段用点号访问。这两个属性的行为分别由 test_loggers.py 与 test_optimizers.py、test_lr_monitor.py 等测试保证可作为回归参照。钩子级验证在LightningModule/LightningDataModule的on_save_checkpoint/on_load_checkpoint中打印或断言写入的键值跑一个极短训练后确认保存与恢复闭环。参考 test_restore.py 中模型状态恢复的测试模式。路径级验证训练完成后检查dirpath指向的目录下是否生成了预期格式的.ckpt文件并确认分布式如 DDP环境下没有因默认路径竞争而产生的异常相关逻辑可对照 model_checkpoint.py 的实现与检查点测试套件 test_model_checkpoint.py。需要说明的是以上变更在 1.7 中属于移除级别而非仅弃用告警因此升级后旧写法会直接报错或不再生效不存在过渡窗口若你仍在使用 1.6 及更早版本可在 CHANGELOG 对应版本段落找到各 API 首次弃用的时间点提前规划迁移。【免费下载链接】pytorch-lightningPretrain, finetune ANY AI model of ANY size on 1 or 10,000 GPUs with zero code changes.项目地址: https://gitcode.com/gh_mirrors/py/pytorch-lightning创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考