人工智能深度学习机器学习预训练分布式训练微调【免费下载链接】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 官方升级文档docs/source-pytorch/upgrade/sections/1_5_devel.rst编写面向框架内部开发者与深度定制 Trainer/Strategy/Checkpoint 逻辑的高级用户。内容聚焦 Lightning 1.5 到 2.0 之间针对内部 API 的四项破坏性变更CheckpointConnector.hpc_load()的移除、TrainerModelHooksMixin的废弃、Trainer.train_loop属性重命名以及LightningModule.loaded_optimizer_states_dict属性的删除。读完本文你将掌握每项变更的迁移方法、新 API 的底层调用链以及如何在当前仓库源码中定位对应的新实现。一、升级背景为什么要关注 devel 级变更PyTorch Lightning 官方升级文档按受众分为三层1_5_regular.rst普通用户、1_5_advanced.rst进阶用户与1_5_devel.rst开发者。三者共同汇总于 from_1_5.rst 这一总入口覆盖从 1.5 一路升级到 2.0 的全路径。其中develDeveloper级别针对的是那些直接接触框架内部对象的开发者——例如在自定义 Strategy、Callback 或 Plugin 中直接调用CheckpointConnector覆写 Trainer 的内部 Loop 属性在 LightningModule 子类中依赖已过时的状态属性。这类 API 通常没有deprecated装饰器的软提示或提示期较短在 2.0 中直接以移除或更名方式落地因此升级时必须主动对照迁移表逐项检查。1_5_devel.rst共列出 4 项变更本节先给出总览后文逐一展开变更对象迁移动作对应 PRCheckpointConnector.hpc_load()改用CheckpointConnector.restore()PR7652TrainerModelHooksMixin改用pytorch_lightning.utilities.signature_utils中的工具函数PR7422Trainer.train_loop属性改用等价的Trainer.fit_loop属性PR8025LightningModule.loaded_optimizer_states_dict属性已被移除不再提供替代PR8229注以上 PR 编号可在仓库 src/lightning/pytorch/CHANGELOG.md 的版本记录中交叉核对例如 1.5 版本条目中记录了hpc_load()的弃用、train_loop的弃用与loaded_optimizer_states_dict的弃用2.0 版本条目中记录了最终的移除。二、变更一CheckpointConnector.hpc_load()→CheckpointConnector.restore()2.1 为什么要迁移在 1.5 之前CheckpointConnector同时维护了两套恢复入口hpc_load()最初为 HPC高性能计算场景设计用于在集群上从hpc目录下的权重恢复训练restore()通用的断点恢复入口。两套逻辑存在大量重叠且hpc_load功能不完整CHANGELOG 中曾记录 “Fixed feature-lack inhpc_load” 这类修复。因此官方在 PR7652 中弃用hpc_load()统一收敛到restore()并在 2.0 中彻底删除hpc_load属性对应 CHANGELOG 中的 “Removed deprecatedCheckpointConnector.hpc_loadproperty in favor ofCheckpointConnector.restore” 条目。2.2 迁移写法# 1.5 之前已废弃 checkpoint_connector.hpc_load(ckpt_path) # 2.0 之后推荐 checkpoint_connector.restore(ckpt_path)2.3 源码视角新 API 的完整调用链在当前仓库中restore()实现在 src/lightning/pytorch/trainer/connectors/checkpoint_connector.py#L233-L258。其执行流程是resume_start(checkpoint_path, weights_onlyweights_only)解析并加载 checkpoint 文件同时兼容旧版 HPC 恢复路径——注意_hpc_resume_path仍被保留用于内部兼容restore_datamodule()调用LightningDataModule.load_state_dict恢复数据模块状态restore_model()先触发on_load_checkpoint钩子call._call_lightning_module_hook(self.trainer, on_load_checkpoint, ...)再通过strategy.load_model_state_dict()恢复权重restore_callbacks()调用_call_callbacks_on_load_checkpoint与_call_callbacks_load_state_dict恢复回调状态restore_training_state()依次恢复精度插件含 AMP 缩放器状态、Loop 进度、优化器与 LR Scheduler 状态仅TrainerFn.FITTING场景resume_end()释放 checkpoint 内存并执行跨进程 barrier。这套统一入口保证了模型权重、数据模块、回调、Loop 与优化器的状态恢复顺序一致且weights_only参数允许仅恢复权重而跳过训练状态。迁移到restore()后开发者自定义恢复逻辑时无需再区分 HPC 与常规断点两条代码路径。三、变更二TrainerModelHooksMixin废弃改用signature_utils工具函数3.1 变更内容1.5 之前的版本中TrainerModelHooksMixin承担着 Trainer 侧的模型钩子调度逻辑其中包含大量“根据钩子函数签名判断参数是否传入”的运行时检查。PR7422 将该 Mixin 的职责拆分签名相关的能力下沉到独立的工具模块pytorch_lightning.utilities.signature_utilsTrainer 侧不再依赖这个 Mixin。3.2 迁移写法# 1.5 之前已废弃 from pytorch_lightning.trainer.training_tricks import TrainerModelHooksMixin # 2.0 之后推荐 from pytorch_lightning.utilities.signature_utils import is_param_in_hook_signature3.3 源码视角工具函数能做什么当前仓库的 src/lightning/pytorch/utilities/signature_utils.py 提供核心函数def is_param_in_hook_signature( hook_fx: Callable, param: str, explicit: bool False, min_args: Optional[int] None ) - bool:其语义是判断某个 hook 回调函数hook_fx的签名中是否包含名为param的参数。关键实现细节若 hook 被装饰器包装存在__wrapped__会自动解包到原始函数避免装饰器干扰签名解析基于inspect.getfullargspec(hook_fx)解析参数列表并去掉self当explicitFalse时若 hook 声明了*argsvarargs也视为包含该参数传入min_args时只要参数个数达到阈值即判定为包含。这一函数是 Lightning 2.x 中“根据用户是否在钩子签名中显式声明某参数来决定是否传参”的核心判定逻辑广泛用于training_step、validation_step等钩子的兼容性调度。如果你曾依赖TrainerModelHooksMixin做这类检查迁移后应直接调用is_param_in_hook_signature。四、变更三Trainer.train_loop→Trainer.fit_loop4.1 变更内容1.5 中 Trainer 暴露了train_loop属性由于训练循环training loop实际同时包含训练与验证两个阶段官方在 PR8025 中将其重命名为语义更准确的fit_loop并在 2.0 中移除了旧的train_loop属性对应 CHANGELOG 的 “Removed deprecatedTrainer.train_loopproperty in favor ofTrainer.fit_loop” 条目。4.2 迁移写法# 1.5 之前已废弃 trainer.train_loop.max_epochs # 2.0 之后推荐 trainer.fit_loop.max_epochs4.3 源码视角fit_loop在新架构中的位置当前仓库 src/lightning/pytorch/trainer/trainer.py#L441-L442 中fit_loop在 Trainer 初始化时被实例化self.fit_loop _FitLoop(self, min_epochsmin_epochs, max_epochsmax_epochs) self.fit_loop.epoch_loop _TrainingEpochLoop(self, min_stepsmin_steps, max_stepsmax_steps)围绕fit_loop的派生属性贯穿整个 Trainer 内部实现trainer.fit_loop.epoch_loop.val_loop验证循环配置校验器configuration_validator.py与数据连接器data_connector.py都通过它挂载数据源trainer.fit_loop.epoch_progressepoch 级进度跟踪global_step、current_epoch、max_epochs、max_steps等 Trainer 属性见 trainer.py均委托给它fit_loop.state_dict()/fit_loop.load_state_dict()断点恢复时Loop 进度以fit_loop为 key 序列化进 checkpointcheckpoint_connector.py 与 L518。因此任何在自定义回调或循环中需要读写训练进度、最大 epoch/steps 的代码都应改为访问trainer.fit_loop。五、变更四LightningModule.loaded_optimizer_states_dict被移除5.1 变更内容LightningModule.loaded_optimizer_states_dict曾在早期版本中用于在恢复训练后访问从 checkpoint 加载的优化器状态字典。该属性在 PR8229 中被弃用随后在 2.0 中被彻底移除对应 CHANGELOG 的 “Removed deprecatedLightningModule.loaded_optimizer_states_dictproperty” 条目。官方不再提供直接替代属性——恢复优化器状态成为框架内部流程用户层不应再依赖该属性。5.2 迁移写法# 1.5 之前已废弃 optimizer_states self.loaded_optimizer_states_dict # 2.0 之后无需手动获取如需自定义优化器状态恢复 # 请在 on_load_checkpoint / on_save_checkpoint 钩子中自行读写 checkpoint 内容5.3 源码视角优化器状态现在的恢复路径在当前架构中优化器与 LR Scheduler 状态的恢复由CheckpointConnector统一完成见 checkpoint_connector.py 的restore_optimizers_and_schedulers()/restore_optimizers()/restore_lr_schedulers()。其恢复条件位于restore_training_state()仅当trainer.state.fn TrainerFn.FITTING即训练恢复场景时才会恢复优化器与调度器。如果你在自定义 LightningModule 中需要感知或干预优化器状态正确做法是在on_load_checkpoint(ckpt)钩子中读取ckpt[optimizer_states]等字段自行处理而不是依赖已被移除的属性。六、迁移清单与自检建议将四项变更整理为一份可直接对照的检查清单便于在升级到 2.0 前逐一排查自定义代码检查点搜索关键词迁移动作Checkpoint 恢复入口hpc_load全部替换为restore(ckpt_path, weights_only...)Hook 签名工具TrainerModelHooksMixin改为from pytorch_lightning.utilities.signature_utils import is_param_in_hook_signatureTrainer 循环属性trainer.train_loop全部替换为trainer.fit_loop优化器状态访问loaded_optimizer_states_dict删除该访问改在on_load_checkpoint/on_save_checkpoint中自行管理完成迁移后建议重点回归验证以下场景断点续训从 1.5 时代保存的 checkpoint 在 2.0 中恢复时确认权重、Loop 进度与优化器状态均能正确加载可参考restore()的恢复顺序编写集成测试自定义钩子签名若你的training_step等方法依赖签名动态传参用is_param_in_hook_signature重新实现判定逻辑并补充单元测试进度读写任何依赖train_loop获取global_step、current_epoch的代码改为通过fit_loop读取后运行一轮训练验证数值一致。七、延伸阅读开发者级其余版本迁移章节docs/source-pytorch/upgrade/sections/1_6_devel.rst、1_7_devel.rst、1_8_devel.rst、1_9_devel.rst普通用户与进阶用户的 1.5 迁移对照表1_5_regular.rst如trainer.fit(train_dataloaders...)→trainer.fit(dataloaders...)、distributed_backend→strategy、1_5_advanced.rst如self.log(sync_dist_op...)→self.log(reduce_fx...)、DDPPlugin.task_idx→DDPStrategy.local_rank全部升级章节的总入口from_1_5.rst以及更完整的迁移指南 migration_guide.rstCheckpoint 恢复与保存的完整设计checkpoint_connector.py各版本弃用与移除记录的权威出处src/lightning/pytorch/CHANGELOG.md。通过以上四项迁移你的自定义 Trainer 扩展、Checkpoint 恢复逻辑与钩子调度代码即可平滑对齐 Lightning 2.x 的内部架构。赞分享人工智能深度学习机器学习预训练分布式训练微调【免费下载链接】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 2.0 开发者升级指南XLAStrategy 与 SingleTPUStrategy 的 is_distributed 属性移除PyTorch Lightning 2.0 开发者升级指南XLAStrategy 与 SingleTPUStrategy 的 is_distributed 属人工智能深度学习机器学习预训练分布式训练微调PyTorch Lightning 1.8 → 2.0 升级指南开发者篇Logger 与 Profiler 基类迁移全解析PyTorch Lightning 1.8 → 2.0 升级指南开发者篇Logger 与 Profiler 基类迁移全解析 本篇技术指南面向 自定义 Li人工智能深度学习机器学习预训练分布式训练微调PyTorch Lightning 1.5 到 2.0 升级完整指南从 Trainer 参数重构到 Strategy 架构迁移PyTorch Lightning 1.5 到 2.0 升级完整指南从 Trainer 参数重构到 Strategy 架构迁移 本文基于 from_1_5.r人工智能深度学习机器学习预训练分布式训练微调创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PyTorch Lightning 1.5 → 2.0 开发者级升级指南：Checkpoint 恢复、Hook 签名与 Loop 属性迁移
人工智能深度学习机器学习预训练分布式训练微调【免费下载链接】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 官方升级文档docs/source-pytorch/upgrade/sections/1_5_devel.rst编写面向框架内部开发者与深度定制 Trainer/Strategy/Checkpoint 逻辑的高级用户。内容聚焦 Lightning 1.5 到 2.0 之间针对内部 API 的四项破坏性变更CheckpointConnector.hpc_load()的移除、TrainerModelHooksMixin的废弃、Trainer.train_loop属性重命名以及LightningModule.loaded_optimizer_states_dict属性的删除。读完本文你将掌握每项变更的迁移方法、新 API 的底层调用链以及如何在当前仓库源码中定位对应的新实现。一、升级背景为什么要关注 devel 级变更PyTorch Lightning 官方升级文档按受众分为三层1_5_regular.rst普通用户、1_5_advanced.rst进阶用户与1_5_devel.rst开发者。三者共同汇总于 from_1_5.rst 这一总入口覆盖从 1.5 一路升级到 2.0 的全路径。其中develDeveloper级别针对的是那些直接接触框架内部对象的开发者——例如在自定义 Strategy、Callback 或 Plugin 中直接调用CheckpointConnector覆写 Trainer 的内部 Loop 属性在 LightningModule 子类中依赖已过时的状态属性。这类 API 通常没有deprecated装饰器的软提示或提示期较短在 2.0 中直接以移除或更名方式落地因此升级时必须主动对照迁移表逐项检查。1_5_devel.rst共列出 4 项变更本节先给出总览后文逐一展开变更对象迁移动作对应 PRCheckpointConnector.hpc_load()改用CheckpointConnector.restore()PR7652TrainerModelHooksMixin改用pytorch_lightning.utilities.signature_utils中的工具函数PR7422Trainer.train_loop属性改用等价的Trainer.fit_loop属性PR8025LightningModule.loaded_optimizer_states_dict属性已被移除不再提供替代PR8229注以上 PR 编号可在仓库 src/lightning/pytorch/CHANGELOG.md 的版本记录中交叉核对例如 1.5 版本条目中记录了hpc_load()的弃用、train_loop的弃用与loaded_optimizer_states_dict的弃用2.0 版本条目中记录了最终的移除。二、变更一CheckpointConnector.hpc_load()→CheckpointConnector.restore()2.1 为什么要迁移在 1.5 之前CheckpointConnector同时维护了两套恢复入口hpc_load()最初为 HPC高性能计算场景设计用于在集群上从hpc目录下的权重恢复训练restore()通用的断点恢复入口。两套逻辑存在大量重叠且hpc_load功能不完整CHANGELOG 中曾记录 “Fixed feature-lack inhpc_load” 这类修复。因此官方在 PR7652 中弃用hpc_load()统一收敛到restore()并在 2.0 中彻底删除hpc_load属性对应 CHANGELOG 中的 “Removed deprecatedCheckpointConnector.hpc_loadproperty in favor ofCheckpointConnector.restore” 条目。2.2 迁移写法# 1.5 之前已废弃 checkpoint_connector.hpc_load(ckpt_path) # 2.0 之后推荐 checkpoint_connector.restore(ckpt_path)2.3 源码视角新 API 的完整调用链在当前仓库中restore()实现在 src/lightning/pytorch/trainer/connectors/checkpoint_connector.py#L233-L258。其执行流程是resume_start(checkpoint_path, weights_onlyweights_only)解析并加载 checkpoint 文件同时兼容旧版 HPC 恢复路径——注意_hpc_resume_path仍被保留用于内部兼容restore_datamodule()调用LightningDataModule.load_state_dict恢复数据模块状态restore_model()先触发on_load_checkpoint钩子call._call_lightning_module_hook(self.trainer, on_load_checkpoint, ...)再通过strategy.load_model_state_dict()恢复权重restore_callbacks()调用_call_callbacks_on_load_checkpoint与_call_callbacks_load_state_dict恢复回调状态restore_training_state()依次恢复精度插件含 AMP 缩放器状态、Loop 进度、优化器与 LR Scheduler 状态仅TrainerFn.FITTING场景resume_end()释放 checkpoint 内存并执行跨进程 barrier。这套统一入口保证了模型权重、数据模块、回调、Loop 与优化器的状态恢复顺序一致且weights_only参数允许仅恢复权重而跳过训练状态。迁移到restore()后开发者自定义恢复逻辑时无需再区分 HPC 与常规断点两条代码路径。三、变更二TrainerModelHooksMixin废弃改用signature_utils工具函数3.1 变更内容1.5 之前的版本中TrainerModelHooksMixin承担着 Trainer 侧的模型钩子调度逻辑其中包含大量“根据钩子函数签名判断参数是否传入”的运行时检查。PR7422 将该 Mixin 的职责拆分签名相关的能力下沉到独立的工具模块pytorch_lightning.utilities.signature_utilsTrainer 侧不再依赖这个 Mixin。3.2 迁移写法# 1.5 之前已废弃 from pytorch_lightning.trainer.training_tricks import TrainerModelHooksMixin # 2.0 之后推荐 from pytorch_lightning.utilities.signature_utils import is_param_in_hook_signature3.3 源码视角工具函数能做什么当前仓库的 src/lightning/pytorch/utilities/signature_utils.py 提供核心函数def is_param_in_hook_signature( hook_fx: Callable, param: str, explicit: bool False, min_args: Optional[int] None ) - bool:其语义是判断某个 hook 回调函数hook_fx的签名中是否包含名为param的参数。关键实现细节若 hook 被装饰器包装存在__wrapped__会自动解包到原始函数避免装饰器干扰签名解析基于inspect.getfullargspec(hook_fx)解析参数列表并去掉self当explicitFalse时若 hook 声明了*argsvarargs也视为包含该参数传入min_args时只要参数个数达到阈值即判定为包含。这一函数是 Lightning 2.x 中“根据用户是否在钩子签名中显式声明某参数来决定是否传参”的核心判定逻辑广泛用于training_step、validation_step等钩子的兼容性调度。如果你曾依赖TrainerModelHooksMixin做这类检查迁移后应直接调用is_param_in_hook_signature。四、变更三Trainer.train_loop→Trainer.fit_loop4.1 变更内容1.5 中 Trainer 暴露了train_loop属性由于训练循环training loop实际同时包含训练与验证两个阶段官方在 PR8025 中将其重命名为语义更准确的fit_loop并在 2.0 中移除了旧的train_loop属性对应 CHANGELOG 的 “Removed deprecatedTrainer.train_loopproperty in favor ofTrainer.fit_loop” 条目。4.2 迁移写法# 1.5 之前已废弃 trainer.train_loop.max_epochs # 2.0 之后推荐 trainer.fit_loop.max_epochs4.3 源码视角fit_loop在新架构中的位置当前仓库 src/lightning/pytorch/trainer/trainer.py#L441-L442 中fit_loop在 Trainer 初始化时被实例化self.fit_loop _FitLoop(self, min_epochsmin_epochs, max_epochsmax_epochs) self.fit_loop.epoch_loop _TrainingEpochLoop(self, min_stepsmin_steps, max_stepsmax_steps)围绕fit_loop的派生属性贯穿整个 Trainer 内部实现trainer.fit_loop.epoch_loop.val_loop验证循环配置校验器configuration_validator.py与数据连接器data_connector.py都通过它挂载数据源trainer.fit_loop.epoch_progressepoch 级进度跟踪global_step、current_epoch、max_epochs、max_steps等 Trainer 属性见 trainer.py均委托给它fit_loop.state_dict()/fit_loop.load_state_dict()断点恢复时Loop 进度以fit_loop为 key 序列化进 checkpointcheckpoint_connector.py 与 L518。因此任何在自定义回调或循环中需要读写训练进度、最大 epoch/steps 的代码都应改为访问trainer.fit_loop。五、变更四LightningModule.loaded_optimizer_states_dict被移除5.1 变更内容LightningModule.loaded_optimizer_states_dict曾在早期版本中用于在恢复训练后访问从 checkpoint 加载的优化器状态字典。该属性在 PR8229 中被弃用随后在 2.0 中被彻底移除对应 CHANGELOG 的 “Removed deprecatedLightningModule.loaded_optimizer_states_dictproperty” 条目。官方不再提供直接替代属性——恢复优化器状态成为框架内部流程用户层不应再依赖该属性。5.2 迁移写法# 1.5 之前已废弃 optimizer_states self.loaded_optimizer_states_dict # 2.0 之后无需手动获取如需自定义优化器状态恢复 # 请在 on_load_checkpoint / on_save_checkpoint 钩子中自行读写 checkpoint 内容5.3 源码视角优化器状态现在的恢复路径在当前架构中优化器与 LR Scheduler 状态的恢复由CheckpointConnector统一完成见 checkpoint_connector.py 的restore_optimizers_and_schedulers()/restore_optimizers()/restore_lr_schedulers()。其恢复条件位于restore_training_state()仅当trainer.state.fn TrainerFn.FITTING即训练恢复场景时才会恢复优化器与调度器。如果你在自定义 LightningModule 中需要感知或干预优化器状态正确做法是在on_load_checkpoint(ckpt)钩子中读取ckpt[optimizer_states]等字段自行处理而不是依赖已被移除的属性。六、迁移清单与自检建议将四项变更整理为一份可直接对照的检查清单便于在升级到 2.0 前逐一排查自定义代码检查点搜索关键词迁移动作Checkpoint 恢复入口hpc_load全部替换为restore(ckpt_path, weights_only...)Hook 签名工具TrainerModelHooksMixin改为from pytorch_lightning.utilities.signature_utils import is_param_in_hook_signatureTrainer 循环属性trainer.train_loop全部替换为trainer.fit_loop优化器状态访问loaded_optimizer_states_dict删除该访问改在on_load_checkpoint/on_save_checkpoint中自行管理完成迁移后建议重点回归验证以下场景断点续训从 1.5 时代保存的 checkpoint 在 2.0 中恢复时确认权重、Loop 进度与优化器状态均能正确加载可参考restore()的恢复顺序编写集成测试自定义钩子签名若你的training_step等方法依赖签名动态传参用is_param_in_hook_signature重新实现判定逻辑并补充单元测试进度读写任何依赖train_loop获取global_step、current_epoch的代码改为通过fit_loop读取后运行一轮训练验证数值一致。七、延伸阅读开发者级其余版本迁移章节docs/source-pytorch/upgrade/sections/1_6_devel.rst、1_7_devel.rst、1_8_devel.rst、1_9_devel.rst普通用户与进阶用户的 1.5 迁移对照表1_5_regular.rst如trainer.fit(train_dataloaders...)→trainer.fit(dataloaders...)、distributed_backend→strategy、1_5_advanced.rst如self.log(sync_dist_op...)→self.log(reduce_fx...)、DDPPlugin.task_idx→DDPStrategy.local_rank全部升级章节的总入口from_1_5.rst以及更完整的迁移指南 migration_guide.rstCheckpoint 恢复与保存的完整设计checkpoint_connector.py各版本弃用与移除记录的权威出处src/lightning/pytorch/CHANGELOG.md。通过以上四项迁移你的自定义 Trainer 扩展、Checkpoint 恢复逻辑与钩子调度代码即可平滑对齐 Lightning 2.x 的内部架构。赞分享人工智能深度学习机器学习预训练分布式训练微调【免费下载链接】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 2.0 开发者升级指南XLAStrategy 与 SingleTPUStrategy 的 is_distributed 属性移除PyTorch Lightning 2.0 开发者升级指南XLAStrategy 与 SingleTPUStrategy 的 is_distributed 属人工智能深度学习机器学习预训练分布式训练微调PyTorch Lightning 1.8 → 2.0 升级指南开发者篇Logger 与 Profiler 基类迁移全解析PyTorch Lightning 1.8 → 2.0 升级指南开发者篇Logger 与 Profiler 基类迁移全解析 本篇技术指南面向 自定义 Li人工智能深度学习机器学习预训练分布式训练微调PyTorch Lightning 1.5 到 2.0 升级完整指南从 Trainer 参数重构到 Strategy 架构迁移PyTorch Lightning 1.5 到 2.0 升级完整指南从 Trainer 参数重构到 Strategy 架构迁移 本文基于 from_1_5.r人工智能深度学习机器学习预训练分布式训练微调创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考