拓冰网站定制 
人工智能大模型AI 技能/插件分布式训练微调深度学习【免费下载链接】ml-engineeringMachine Learning Engineering Open Book项目地址https://gitcode.com/gh_mirrors/ml/ml-engineering点击查看免费下载导读本文基于 ML Engineering Open Bookml-engineering仓库中的 SLURM Administration 文档面向需要同时承担 SLURM 集群管理职责的机器学习工程师系统讲解多节点批量执行命令、集群配置热加载、节点状态变更、自动重启、作业时限修改与故障日志分析等核心运维操作。结合仓库中的 undrain-good-nodes.sh 脚本源码、用户手册 与 SLURM 性能指南本文会将每条管理命令扩展为可直接落地使用的完整配方帮助读者从会用 SLURM 跑训练进阶到能独立维护一套 ML 训练集群。一、在多个节点上批量执行命令在大规模分布式训练场景中管理员经常需要在几十甚至上百个计算节点上执行同一条命令例如清理残留进程、检查时钟同步。逐节点ssh显然不可行标准做法是使用pdshParallel Distributed Shell配合ssh作为远程执行后端。1.1 关闭首次连接的指纹确认提示首次ssh进入一个未登录过的新节点时会出现如下交互提示阻塞脚本的自动化执行Are you sure you want to continue connecting (yes/no/[fingerprint])?可通过在~/.ssh/config中追加两条配置来禁用该检查echo Host * ~/.ssh/config echo StrictHostKeyChecking no ~/.ssh/config安全边界说明该配置将跳过所有主机密钥校验。原文作者的假设是你已经处于 SLURM 集群内部不会通过 ssh 连接到集群之外的机器如果此前提不成立则应评估风险并保留手动确认流程。这一配置写在你自己的用户目录下仅影响当前用户的 ssh 行为。1.2 安装并验证 pdsh确保管理节点上安装了pdsh。安装后即可使用PDSH_RCMD_TYPEssh指定远程执行方式为 ssh向一批节点发起命令。先从一个简单示例开始——在node-21、node-23、node-24、node-25、node-26上执行date$ PDSH_RCMD_TYPEssh pdsh -w node-[21,23-26] date node-25: Sat Oct 14 02:10:01 UTC 2023 node-21: Sat Oct 14 02:10:02 UTC 2023 node-23: Sat Oct 14 02:10:02 UTC 2023 node-24: Sat Oct 14 02:10:02 UTC 2023 node-26: Sat Oct 14 02:10:02 UTC 2023注意-w参数支持 SLURM 风格的紧凑节点列表表达式node-[21,23-26]输出会为每个节点加上主机名前缀。关于紧凑节点列表的展开可参考 用户手册 中scontrol show hostnames的用法。1.3 实战一键清理任务取消后残留的 GPU 进程训练任务被取消后部分绑定 GPU 的进程可能并未随 SLURM job 一起退出导致节点上的 GPU 一直被占用后续任务无法获得资源。此时可以在所有相关节点上批量定位并强杀这些进程。第一步在单个节点上找出所有占用 GPU 的进程 PIDnvidia-smi --query-compute-appspid --formatcsv,noheader | sort | uniq第二步通过pdsh将这一命令推广到所有节点并把结果通过管道喂给sudo kill -9PDSH_RCMD_TYPEssh pdsh -w node-[21,23-26] nvidia-smi --query-compute-appspid --formatcsv,noheader | sort | uniq | xargs -n1 sudo kill -9这里xargs -n1保证每个 PID 独立调用一次sudo kill -9sort | uniq用于去除重复 PID同一进程可能被多张 GPU 记录。该操作会强制终止进程请确认这些确实是已无主任务的残留进程后再执行。仓库中 undrain-good-nodes.sh 正是基于这一思路实现了检查—清理—恢复节点的完整自动化闭环详见下文 2.3 节。二、节点管理状态查询、恢复与自动重启2.1 查看与重载 SLURM 配置管理员需要了解当前生效的集群配置时可查看 SLURM 运行时配置sudo scontrol show configSLURM 控制器controller的核心配置文件通常位于/etc/slurm/slurm.conf站点可能不同可在scontrol show config | grep -i slurmconf中确认实际加载路径参考 用户手册。修改slurm.conf后无需重启slurmctld守护进程只需在控制器节点上执行热重载sudo scontrol reconfigure2.2 变更节点状态scontrol update节点状态的变更统一通过scontrol update完成。两个最常见的操作将已准备好恢复使用的节点解除 drain即状态改为idlescontrol update nodenamenode-5 stateidle将节点移出 SLURM 资源池例如计划维护scontrol update nodenamenode-5 statedrain reasonmaintenance理解节点状态idle表示空闲可用drain表示因管理原因不可用即使当前有任务运行drain也会在任务结束后拒绝新任务。更完整的状态码alloc、mix、drng以及*、~、#、!、%、$、、^、-等后缀字符可参见 用户手册。用sinfo -s可快速浏览全集群的allocated/idle/other/total概览。2.3 自动化解除因Kill task failed被 drain 的节点一个高频运维场景是任务被取消后进程退出缓慢而 SLURM 被配置为不无限等待进程退出于是这些节点会被自动置为drain。这类节点本身硬件没有问题应当尽快恢复给用户使用。关键识别手段——先获取所有被 drain 的节点及原因sinfo -R | grep Kill task failedsinfo -R列出所有被标记为不可用的节点及其 reason更详细的输出可用sinfo -R -o %50E %12U %19H %6t %N调整%50E的宽度可控制原因字段长度参考 用户手册。仓库配套脚本仓库在 orchestration/slurm/undrain-good-nodes.sh 中提供了完整的自动化方案。其核心流程为提取被 drain 的节点列表第 6 行nodes( $(sinfo -R | grep Kill task failed | perl -lne /(node-.*[\d\]])/ print $1 | xargs -n1 scontrol show hostnames) )先用正则从sinfo -R输出中抓取紧凑节点表达式再用scontrol show hostnames展开成逐台主机名。逐节点检查 GPU 是否已无占用第 16 行output$(PDSH_RCMD_TYPEssh pdsh -w $n nvidia-smi --query-compute-appspid --formatcsv,noheader)若输出为空说明该节点上已无任何 GPU 进程节点健康clean1。若仍有残留进程尝试再清理一次并复核第 24–33 行重发nvidia-smi ... | sort | uniq | xargs -n1 sudo kill -9sleep 3等待进程退出后再次查询仍非空则判定为坏节点加入bad数组提示人工介入。对干净节点执行 undrain第 38 行sudo scontrol update NodeName$n Stateidle Reasonundrained by $USER脚本最后会汇总输出good已恢复与bad需人工 ssh 排查两组节点。该脚本依赖第一节配置好的 ssh 免提示与pdsh环境且kill需要 sudo 权限。2.4 节点安全重启scontrol reboot当节点镜像更新等场景需要重启节点时可用如下命令安全地重启整批节点scontrol reboot ASAP node-[1-64]对每个非空闲节点该命令会等待当前 job 运行结束然后重启节点并最终将其恢复为idle状态——因此它不会打断正在运行的任务。该功能的前提是在/etc/slurm/slurm.conf中配置了重启程序RebootProgram /sbin/reboot若该配置是刚刚添加的需要先执行sudo scontrol reconfigure重载配置参见 2.1 节。此外可结合 用户手册 的sinfo状态后缀了解节点正在执行的行为例如表示 pending reboot、^表示 reboot 已下发。三、作业管理修改运行中任务的时限训练任务运行中发现时间预算不够管理员或有相应权限的用户可以直接修改任务的时间上限。将某任务的时限设置为 2 天scontrol update JobID$SLURM_JOB_ID TimeLimit2-00:00:00在原有时限基础上追加10 小时前缀表示相对增加scontrol update JobID$SLURM_JOB_ID TimeLimit10:00:00需要注意scontrol update对时限的修改能力受站点QOS/MaxTime等配置约束从源码语境看修改pending中的任务节点数、分区等参数也是可行的用户手册 提到scontrol update jobidid numnodesnew number partitionnew partition可调整待运行作业而运行中任务的节点数、分区等资源属性通常不可变更只有时限属于可动态调整项。配合场景若使用作业数组排队训练见 容错指南在发现任务快要超时时及时续时可以避免训练在最后一刻被 SLURM 强杀。四、故障排查SLURM 出问题后如何定位当出现节点上的任务被提前取消、节点被移出资源池等异常时第一手资料是 SLURM 控制守护进程slurmctld的事件日志sudo cat /var/log/slurm/slurmctld.log阅读该日志可以帮助理解为什么某个节点的 job 在时限之前被取消为什么某个节点被完全移除例如持续无响应会被置为 DOWN参见 用户手册 中对*后缀的说明。管理员日常还可以组合使用 用户手册 中的这些命令快速了解集群健康状况sinfo -R查看被排除/故障的节点及其原因scontrol show partition查看所有分区的配置scontrol show -d job $SLURM_JOB_ID查看任务详情如JOB_GRESgpu:N可解析出任务实际占用的 GPU 数sacct -j JOBID查看已完成任务的核算信息状态、起止时间、退出码等。五、管理视角的性能要点不要忘了 CPU 亲和性作为管理员除了维护节点还需要注意一个常见的配置陷阱它直接影响用户训练程序拿到的 CPU 核心数。自 SLURM 22.05 系列起srun不再继承sbatch/salloc中的--cpus-per-task值sbatchmanpage 明确说明必须重新指定或用SRUN_CPUS_PER_TASK环境变量传递。这意味着旧脚本#SBATCH --cpus-per-task48 [...] srun myprogram在 23.x 系列上会让myprogram只拿到 1 个 CPU 核心而 ML 训练中每个 GPU 至少需要 1 个驱动进程核心加上若干 DataLoader worker 核心例如 8 卡 每卡 2 个 worker 就需要约 24 个核心/节点这会导致数据加载瓶颈。详细原理、检测方法与修复写法见 SLURM 性能指南管理员应确保集群文档和模板脚本如仓库中的 example.slurm对srun显式携带--cpus-per-task或设置SRUN_CPUS_PER_TASK$SLURM_CPUS_PER_TASK。同样值得管理员留意的还有超线程HT默认情况下 SLURM 会使用 HT可通过--hintnomultithread关闭。HT 开关对网络/集合通信吞吐的影响因平台而异文中给出的案例是 AWS p4 节点开启 HT 后网络吞吐降低 4 倍应实测对比后再定默认策略详见 性能指南。六、与用户手册、容错体系的衔接本文admin.md与仓库中 SLURM 章节的其他文档互为补充用户手册 users.md面向用户的完整用法包括分区查看、--dependency依赖调度、--begin定时分配、作业数组、环境变量导出--exportALL/NONE/...、节点列表展开等性能指南 performance.md--cpus-per-task继承问题、HT 开关对性能的影响启动脚本 launchers/torchrun、accelerate、lightning、srun四种方式在 SLURM 下的完整启动模板容错指南 fault-tolerance从管理员保证节点健康到训练自动恢复的完整链路包括作业数组排队重跑、看门狗watchdog与 kill-switch 机制。其中 cron-daily.slurm / cron-hourly.slurm 这种自延续调度作业也经常由管理员负责部署。一个典型的运维闭环是训练任务被取消后节点因进程残留被自动 drain现象→ 用sinfo -R | grep Kill task failed定位诊断→ 运行 undrain-good-nodes.sh 清理残留并恢复节点处理→ 用slurmctld.log复盘根因预防。掌握了这条链路就掌握了 SLURM 集群日常维护的核心能力。结语SLURM 集群管理并不需要掌握全部手册抓住多节点命令、配置热加载、节点状态流转、作业时限调整、日志排障这五个核心主题即可覆盖绝大多数日常运维需求。本文给出的所有命令和脚本尤其是仓库内置的 undrain-good-nodes.sh都来自真实 ML 训练集群的实践沉淀配合 用户手册 与 性能指南 使用可以在不打断训练的前提下维持一个健康、高效、可自愈的分布式训练环境。赞分享人工智能大模型AI 技能/插件分布式训练微调深度学习【免费下载链接】ml-engineeringMachine Learning Engineering Open Book项目地址https://gitcode.com/gh_mirrors/ml/ml-engineering点击查看免费下载相关推荐NocoBase 搜索与筛选如何配置入门到进阶完整指南NocoBase 搜索与筛选如何配置入门到进阶完整指南 在 NocoBase 里搭业务页面搜索和筛选是用户最先碰上的功能把上万条列表快速缩小到几条。这篇文低代码后端前端人工智能AI 应用工作流自动化Apache Mesos集群运维实战故障恢复与版本管理完全指南Apache Mesos集群运维实战故障恢复与版本管理完全指南 在现代分布式系统中Mesos集群维护是确保业务连续性的关键环节。本指南将深入解析Mesos集云原生FUPK3核心原理揭秘从修改Android源码到dex文件重建全解析FUPK3核心原理揭秘从修改Android源码到dex文件重建全解析 FUPK3 是一款基于Android系统源码修改的 半自动脱壳机 专门用于破解Andr上一篇【免费下载】 Photoshop图层快速导出脚本提升工作流效率下一篇最全面的Postbird使用指南从安装到高级功能的PostgreSQL GUI客户端全攻略创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ML Engineering SLURM 集群管理实战指南：节点维护、作业管理与故障恢复手册
人工智能大模型AI 技能/插件分布式训练微调深度学习【免费下载链接】ml-engineeringMachine Learning Engineering Open Book项目地址https://gitcode.com/gh_mirrors/ml/ml-engineering点击查看免费下载导读本文基于 ML Engineering Open Bookml-engineering仓库中的 SLURM Administration 文档面向需要同时承担 SLURM 集群管理职责的机器学习工程师系统讲解多节点批量执行命令、集群配置热加载、节点状态变更、自动重启、作业时限修改与故障日志分析等核心运维操作。结合仓库中的 undrain-good-nodes.sh 脚本源码、用户手册 与 SLURM 性能指南本文会将每条管理命令扩展为可直接落地使用的完整配方帮助读者从会用 SLURM 跑训练进阶到能独立维护一套 ML 训练集群。一、在多个节点上批量执行命令在大规模分布式训练场景中管理员经常需要在几十甚至上百个计算节点上执行同一条命令例如清理残留进程、检查时钟同步。逐节点ssh显然不可行标准做法是使用pdshParallel Distributed Shell配合ssh作为远程执行后端。1.1 关闭首次连接的指纹确认提示首次ssh进入一个未登录过的新节点时会出现如下交互提示阻塞脚本的自动化执行Are you sure you want to continue connecting (yes/no/[fingerprint])?可通过在~/.ssh/config中追加两条配置来禁用该检查echo Host * ~/.ssh/config echo StrictHostKeyChecking no ~/.ssh/config安全边界说明该配置将跳过所有主机密钥校验。原文作者的假设是你已经处于 SLURM 集群内部不会通过 ssh 连接到集群之外的机器如果此前提不成立则应评估风险并保留手动确认流程。这一配置写在你自己的用户目录下仅影响当前用户的 ssh 行为。1.2 安装并验证 pdsh确保管理节点上安装了pdsh。安装后即可使用PDSH_RCMD_TYPEssh指定远程执行方式为 ssh向一批节点发起命令。先从一个简单示例开始——在node-21、node-23、node-24、node-25、node-26上执行date$ PDSH_RCMD_TYPEssh pdsh -w node-[21,23-26] date node-25: Sat Oct 14 02:10:01 UTC 2023 node-21: Sat Oct 14 02:10:02 UTC 2023 node-23: Sat Oct 14 02:10:02 UTC 2023 node-24: Sat Oct 14 02:10:02 UTC 2023 node-26: Sat Oct 14 02:10:02 UTC 2023注意-w参数支持 SLURM 风格的紧凑节点列表表达式node-[21,23-26]输出会为每个节点加上主机名前缀。关于紧凑节点列表的展开可参考 用户手册 中scontrol show hostnames的用法。1.3 实战一键清理任务取消后残留的 GPU 进程训练任务被取消后部分绑定 GPU 的进程可能并未随 SLURM job 一起退出导致节点上的 GPU 一直被占用后续任务无法获得资源。此时可以在所有相关节点上批量定位并强杀这些进程。第一步在单个节点上找出所有占用 GPU 的进程 PIDnvidia-smi --query-compute-appspid --formatcsv,noheader | sort | uniq第二步通过pdsh将这一命令推广到所有节点并把结果通过管道喂给sudo kill -9PDSH_RCMD_TYPEssh pdsh -w node-[21,23-26] nvidia-smi --query-compute-appspid --formatcsv,noheader | sort | uniq | xargs -n1 sudo kill -9这里xargs -n1保证每个 PID 独立调用一次sudo kill -9sort | uniq用于去除重复 PID同一进程可能被多张 GPU 记录。该操作会强制终止进程请确认这些确实是已无主任务的残留进程后再执行。仓库中 undrain-good-nodes.sh 正是基于这一思路实现了检查—清理—恢复节点的完整自动化闭环详见下文 2.3 节。二、节点管理状态查询、恢复与自动重启2.1 查看与重载 SLURM 配置管理员需要了解当前生效的集群配置时可查看 SLURM 运行时配置sudo scontrol show configSLURM 控制器controller的核心配置文件通常位于/etc/slurm/slurm.conf站点可能不同可在scontrol show config | grep -i slurmconf中确认实际加载路径参考 用户手册。修改slurm.conf后无需重启slurmctld守护进程只需在控制器节点上执行热重载sudo scontrol reconfigure2.2 变更节点状态scontrol update节点状态的变更统一通过scontrol update完成。两个最常见的操作将已准备好恢复使用的节点解除 drain即状态改为idlescontrol update nodenamenode-5 stateidle将节点移出 SLURM 资源池例如计划维护scontrol update nodenamenode-5 statedrain reasonmaintenance理解节点状态idle表示空闲可用drain表示因管理原因不可用即使当前有任务运行drain也会在任务结束后拒绝新任务。更完整的状态码alloc、mix、drng以及*、~、#、!、%、$、、^、-等后缀字符可参见 用户手册。用sinfo -s可快速浏览全集群的allocated/idle/other/total概览。2.3 自动化解除因Kill task failed被 drain 的节点一个高频运维场景是任务被取消后进程退出缓慢而 SLURM 被配置为不无限等待进程退出于是这些节点会被自动置为drain。这类节点本身硬件没有问题应当尽快恢复给用户使用。关键识别手段——先获取所有被 drain 的节点及原因sinfo -R | grep Kill task failedsinfo -R列出所有被标记为不可用的节点及其 reason更详细的输出可用sinfo -R -o %50E %12U %19H %6t %N调整%50E的宽度可控制原因字段长度参考 用户手册。仓库配套脚本仓库在 orchestration/slurm/undrain-good-nodes.sh 中提供了完整的自动化方案。其核心流程为提取被 drain 的节点列表第 6 行nodes( $(sinfo -R | grep Kill task failed | perl -lne /(node-.*[\d\]])/ print $1 | xargs -n1 scontrol show hostnames) )先用正则从sinfo -R输出中抓取紧凑节点表达式再用scontrol show hostnames展开成逐台主机名。逐节点检查 GPU 是否已无占用第 16 行output$(PDSH_RCMD_TYPEssh pdsh -w $n nvidia-smi --query-compute-appspid --formatcsv,noheader)若输出为空说明该节点上已无任何 GPU 进程节点健康clean1。若仍有残留进程尝试再清理一次并复核第 24–33 行重发nvidia-smi ... | sort | uniq | xargs -n1 sudo kill -9sleep 3等待进程退出后再次查询仍非空则判定为坏节点加入bad数组提示人工介入。对干净节点执行 undrain第 38 行sudo scontrol update NodeName$n Stateidle Reasonundrained by $USER脚本最后会汇总输出good已恢复与bad需人工 ssh 排查两组节点。该脚本依赖第一节配置好的 ssh 免提示与pdsh环境且kill需要 sudo 权限。2.4 节点安全重启scontrol reboot当节点镜像更新等场景需要重启节点时可用如下命令安全地重启整批节点scontrol reboot ASAP node-[1-64]对每个非空闲节点该命令会等待当前 job 运行结束然后重启节点并最终将其恢复为idle状态——因此它不会打断正在运行的任务。该功能的前提是在/etc/slurm/slurm.conf中配置了重启程序RebootProgram /sbin/reboot若该配置是刚刚添加的需要先执行sudo scontrol reconfigure重载配置参见 2.1 节。此外可结合 用户手册 的sinfo状态后缀了解节点正在执行的行为例如表示 pending reboot、^表示 reboot 已下发。三、作业管理修改运行中任务的时限训练任务运行中发现时间预算不够管理员或有相应权限的用户可以直接修改任务的时间上限。将某任务的时限设置为 2 天scontrol update JobID$SLURM_JOB_ID TimeLimit2-00:00:00在原有时限基础上追加10 小时前缀表示相对增加scontrol update JobID$SLURM_JOB_ID TimeLimit10:00:00需要注意scontrol update对时限的修改能力受站点QOS/MaxTime等配置约束从源码语境看修改pending中的任务节点数、分区等参数也是可行的用户手册 提到scontrol update jobidid numnodesnew number partitionnew partition可调整待运行作业而运行中任务的节点数、分区等资源属性通常不可变更只有时限属于可动态调整项。配合场景若使用作业数组排队训练见 容错指南在发现任务快要超时时及时续时可以避免训练在最后一刻被 SLURM 强杀。四、故障排查SLURM 出问题后如何定位当出现节点上的任务被提前取消、节点被移出资源池等异常时第一手资料是 SLURM 控制守护进程slurmctld的事件日志sudo cat /var/log/slurm/slurmctld.log阅读该日志可以帮助理解为什么某个节点的 job 在时限之前被取消为什么某个节点被完全移除例如持续无响应会被置为 DOWN参见 用户手册 中对*后缀的说明。管理员日常还可以组合使用 用户手册 中的这些命令快速了解集群健康状况sinfo -R查看被排除/故障的节点及其原因scontrol show partition查看所有分区的配置scontrol show -d job $SLURM_JOB_ID查看任务详情如JOB_GRESgpu:N可解析出任务实际占用的 GPU 数sacct -j JOBID查看已完成任务的核算信息状态、起止时间、退出码等。五、管理视角的性能要点不要忘了 CPU 亲和性作为管理员除了维护节点还需要注意一个常见的配置陷阱它直接影响用户训练程序拿到的 CPU 核心数。自 SLURM 22.05 系列起srun不再继承sbatch/salloc中的--cpus-per-task值sbatchmanpage 明确说明必须重新指定或用SRUN_CPUS_PER_TASK环境变量传递。这意味着旧脚本#SBATCH --cpus-per-task48 [...] srun myprogram在 23.x 系列上会让myprogram只拿到 1 个 CPU 核心而 ML 训练中每个 GPU 至少需要 1 个驱动进程核心加上若干 DataLoader worker 核心例如 8 卡 每卡 2 个 worker 就需要约 24 个核心/节点这会导致数据加载瓶颈。详细原理、检测方法与修复写法见 SLURM 性能指南管理员应确保集群文档和模板脚本如仓库中的 example.slurm对srun显式携带--cpus-per-task或设置SRUN_CPUS_PER_TASK$SLURM_CPUS_PER_TASK。同样值得管理员留意的还有超线程HT默认情况下 SLURM 会使用 HT可通过--hintnomultithread关闭。HT 开关对网络/集合通信吞吐的影响因平台而异文中给出的案例是 AWS p4 节点开启 HT 后网络吞吐降低 4 倍应实测对比后再定默认策略详见 性能指南。六、与用户手册、容错体系的衔接本文admin.md与仓库中 SLURM 章节的其他文档互为补充用户手册 users.md面向用户的完整用法包括分区查看、--dependency依赖调度、--begin定时分配、作业数组、环境变量导出--exportALL/NONE/...、节点列表展开等性能指南 performance.md--cpus-per-task继承问题、HT 开关对性能的影响启动脚本 launchers/torchrun、accelerate、lightning、srun四种方式在 SLURM 下的完整启动模板容错指南 fault-tolerance从管理员保证节点健康到训练自动恢复的完整链路包括作业数组排队重跑、看门狗watchdog与 kill-switch 机制。其中 cron-daily.slurm / cron-hourly.slurm 这种自延续调度作业也经常由管理员负责部署。一个典型的运维闭环是训练任务被取消后节点因进程残留被自动 drain现象→ 用sinfo -R | grep Kill task failed定位诊断→ 运行 undrain-good-nodes.sh 清理残留并恢复节点处理→ 用slurmctld.log复盘根因预防。掌握了这条链路就掌握了 SLURM 集群日常维护的核心能力。结语SLURM 集群管理并不需要掌握全部手册抓住多节点命令、配置热加载、节点状态流转、作业时限调整、日志排障这五个核心主题即可覆盖绝大多数日常运维需求。本文给出的所有命令和脚本尤其是仓库内置的 undrain-good-nodes.sh都来自真实 ML 训练集群的实践沉淀配合 用户手册 与 性能指南 使用可以在不打断训练的前提下维持一个健康、高效、可自愈的分布式训练环境。赞分享人工智能大模型AI 技能/插件分布式训练微调深度学习【免费下载链接】ml-engineeringMachine Learning Engineering Open Book项目地址https://gitcode.com/gh_mirrors/ml/ml-engineering点击查看免费下载相关推荐NocoBase 搜索与筛选如何配置入门到进阶完整指南NocoBase 搜索与筛选如何配置入门到进阶完整指南 在 NocoBase 里搭业务页面搜索和筛选是用户最先碰上的功能把上万条列表快速缩小到几条。这篇文低代码后端前端人工智能AI 应用工作流自动化Apache Mesos集群运维实战故障恢复与版本管理完全指南Apache Mesos集群运维实战故障恢复与版本管理完全指南 在现代分布式系统中Mesos集群维护是确保业务连续性的关键环节。本指南将深入解析Mesos集云原生FUPK3核心原理揭秘从修改Android源码到dex文件重建全解析FUPK3核心原理揭秘从修改Android源码到dex文件重建全解析 FUPK3 是一款基于Android系统源码修改的 半自动脱壳机 专门用于破解Andr上一篇【免费下载】 Photoshop图层快速导出脚本提升工作流效率下一篇最全面的Postbird使用指南从安装到高级功能的PostgreSQL GUI客户端全攻略创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考