DGX Spark 上跑 ML 训练前如何用 agents 的 spark-preflight 做环境预检并读取 env-report.json【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents在 DGX SparkGB10aarch64 CPU、SM121 GPU、128GB 统一内存、CUDA 13上启动一次多小时的训练之前环境层面的问题——wheel ABI 不匹配、统一内存余量不足、热平台限功耗——往往要到运行中途才暴露。agents 仓库的 dgx-spark-ops 插件 提供了spark-preflight命令给它描述你计划跑的工作负载它会按固定流程完成硬件身份确认、G1–G10 故障项检查、内存余量核算最后把结果写成本地的env-report.json并给出ready | ready-with-warnings | blocked的判定让你在开跑前就知道这台机器是否真的准备好了。运行 spark-preflightspark-preflight.md 是一个带参数提示的 slash 命令参数是“计划中的工作负载描述”数据不是指令例如/spark-preflight QLoRA 8B, 3 epochs, 8k context执行时该命令会派发给 dgx-spark-ops-engineer 子代理并按 spark-environment-setup、spark-training-gotchas、spark-memory-thermal-ops 三个 skill 中记录的事实依次执行下面的预检流程。预检的四个步骤1. 确认硬件身份诊断任何东西之前先确认这台机器确实是 GB10nvidia-smi uname -m # 期望 aarch64 python3 -c import torch; print(torch.cuda.get_device_capability()) # 期望 (12, 1)代理文档明确要求nvidia-smi、uname -m期望aarch64、CUDA device capability期望(12, 1)三项对不上时后续所有检查都失效。环境层面的快速验证来自 spark-environment-setup 的 Verification Commands建议容器启动后、安装项目相关包之前执行import torch print(torch.cuda.is_available(), torch.version.cuda)文档示例输出为一行bool cuda-version例如True 13.0。如果打印False文档给的假设排查顺序是先查nvidia-smi失败则属于 runtime/flags、设备可见性、权限前几类而不是 ABI再按echo $CUDA_VISIBLE_DEVICES、ls -l /dev/nvidia*、换新 shell/容器重试最后才是torch.version.cuda不以13开头的 ABI 不匹配。2. 执行 G1–G10 检查GB10 上的十种常见失败模式被编号为 G1–G10编号对工具是 load-bearing 的——报告里每条发现都必须引用 G 编号。gotcha-checks.md 提供每项的可执行只读检查命令。自动化部分由 assets/preflight.sh 完成bash preflight.sh它覆盖 G1、G3、G4、G7、G9输出契约是每条结果行以 G 编号开头后跟 PASS/FAIL/WARN可自动判定时、SKIP不可用时或INFO:G3、G4 的原始读数需要人工判断。脚本头部注释说明了各检查的边界G7 只验证硬件能力不验证内核目标架构sm_121a仍需手动确认G2flash-attn 存在性/Unsloth 覆盖、G6进程排查、G8上游 issue 查询、G10配置审查不可自动化需对照 references/gotcha-checks.md 手动执行。手动检查中有几条命令带副作用或前提执行前注意G5 带宽实测会分配约 4GB 显存并在 UMA 池上反复克隆张量。文档明确标注只在空闲主机上运行不要在活跃工作负载上跑否则可能挤占其他作业的内存。期望实测值 180–192 GB/s而不是 273 GB/s 的规格值。G3 的补救命令sync; echo 3 /proc/sys/vm/drop_caches需要 root会系统性地丢弃整机的 page cache每个进程都会失去缓存文件读不只是训练作业只作为两次运行之间的重置不要当训练中的常规步骤。G4 温度/功耗采样nvidia-smi --query-gputemperature.gpu,power.draw --formatcsv -l 5不消耗权限、Ctrl-C 即可停止但文档要求在代表性负载下跑满 10–15 分钟再下判断功耗在 240W 额定值附近持平而温度持续上升时暂不算限功耗事件功耗平台化在 ~100W 而温度仍在爬升才是限功耗特征。G10双 Spark 场景要求递归搜索 YAML 配置中的tensor_parallel|tp_size|tensor-parallel任何命中都意味着配置错误——双 Spark 只能走 DDP/FSDPTP 不可用。3. 计算内存余量Spark 的 128GB 是 CPU/GPU 共享的统一内存池UMAnvidia-smi只报 CUDA 分配器可见的一侧部分驱动/配置组合下直接返回[N/A], [N/A]。因此余量核算以free -g为准free -g | awk NR2 {print free:, $4, GB}文档给出的规划顺序读free -g减去若干 GB 的 OS/驱动开销得到预算按 uma-accounting.md 工作表估算 weights optimizer gradients activations外加模型加载时的瞬态峰值再与已知锚点核对而不只看估算值模型类别方法实测总量70BQLoRA≈40GB27BLoRApack ≤1024 可跑通9BFull fine-tune宽裕估算贴近预算时文档建议从更短的 packing 或更小的 batch 起步比运行中撞上 OOM 再处理更便宜。4. 写出 env-report.json预检的最后一步是把报告写为工作目录下的env-report.json——除非调用方如拥有runs/date-slug/目录的/finetune调用显式指定了其他路径那应优先遵循显式指定。报告使用完整的检查词汇表每个 G 编号对应pass、fail、warn: detail、skip: reason或info: reading之一与preflight.sh的 PASS/FAIL/WARN/SKIP/INFO 输出契约一致。代理指令中给出的文档示例{ platform: dgx-spark, checks: { G1: pass, G3: warn: 14GB page cache, G9: info: running inside nvcr.io/nvidia/pytorch:25.11-py3 }, headroom_gb: 61, verdict: ready }上面的 JSON 是源文档中的示例字段结构照此即可数值不代表固定预期。读取 env-report.json 并行动判定规则在 dgx-spark-ops-engineer 代理定义 中是明确的三档任一检查为fail或headroom_gb不足以支撑计划工作负载 →blocked只剩warn/skip条目 →ready-with-warnings其余 →ready。blocked时命令定义要求先给出该 gotcha 对应 FIX 条目的具体修复G1 对应换 cu130 wheel 或容器、G3 对应 drop page cache、G9 对应改用容器等见 gotcha-checks.md 与 SKILL.md 的 Quick Reference 表再谈其他建议。代理的行为约束里还有一条它只陈述判定、由调用方决定是否继续不会擅自替你降配工作负载。拿到报告后的核对要点逐条看checksinfo: reading的 G3/G4 是原始读数需要按上文 G3/G4 的判断标准自行解读不能因为不是fail就略过headroom_gb与你的工作负载估算是否留有文档要求的余量而不是贴着预算verdict为blocked时先执行报告指出的那个 gotcha 的 FIX再重跑一次预检确认转为ready或ready-with-warnings。限制与边界预检针对单机 GB10双 Spark 的并行策略限制G10仅 DDP/FSDP属于配置审查不是脚本自动覆盖项。preflight.sh的 G1 检查依赖环境中torch可导入导入不了时输出G1 SKIP: torch not importableG9 的容器判定在未命中任何 marker 时给出G9 UNKNOWN文档明确这不能证明是裸主机。文档中的版本矩阵如nvcr.io/nvidia/pytorch:25.09-py3、transformers 5.13.1等 pin是带日期的已知良好快照stack-matrix.md 要求按Last verified日期判断时效并在长任务前查github.com/NVIDIA/dgx-spark-playbooks的近期 issue——官方 playbook 此前出现过发布即损坏的情况G8。env-report.json默认落在当前工作目录报告只汇总检查结果不会替你启动或修改任何训练任务。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 DGX Spark 上跑 ML 训练前如何用 agents 的 spark-preflight 做环境预检并读取 env-report.json
DGX Spark 上跑 ML 训练前如何用 agents 的 spark-preflight 做环境预检并读取 env-report.json【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents在 DGX SparkGB10aarch64 CPU、SM121 GPU、128GB 统一内存、CUDA 13上启动一次多小时的训练之前环境层面的问题——wheel ABI 不匹配、统一内存余量不足、热平台限功耗——往往要到运行中途才暴露。agents 仓库的 dgx-spark-ops 插件 提供了spark-preflight命令给它描述你计划跑的工作负载它会按固定流程完成硬件身份确认、G1–G10 故障项检查、内存余量核算最后把结果写成本地的env-report.json并给出ready | ready-with-warnings | blocked的判定让你在开跑前就知道这台机器是否真的准备好了。运行 spark-preflightspark-preflight.md 是一个带参数提示的 slash 命令参数是“计划中的工作负载描述”数据不是指令例如/spark-preflight QLoRA 8B, 3 epochs, 8k context执行时该命令会派发给 dgx-spark-ops-engineer 子代理并按 spark-environment-setup、spark-training-gotchas、spark-memory-thermal-ops 三个 skill 中记录的事实依次执行下面的预检流程。预检的四个步骤1. 确认硬件身份诊断任何东西之前先确认这台机器确实是 GB10nvidia-smi uname -m # 期望 aarch64 python3 -c import torch; print(torch.cuda.get_device_capability()) # 期望 (12, 1)代理文档明确要求nvidia-smi、uname -m期望aarch64、CUDA device capability期望(12, 1)三项对不上时后续所有检查都失效。环境层面的快速验证来自 spark-environment-setup 的 Verification Commands建议容器启动后、安装项目相关包之前执行import torch print(torch.cuda.is_available(), torch.version.cuda)文档示例输出为一行bool cuda-version例如True 13.0。如果打印False文档给的假设排查顺序是先查nvidia-smi失败则属于 runtime/flags、设备可见性、权限前几类而不是 ABI再按echo $CUDA_VISIBLE_DEVICES、ls -l /dev/nvidia*、换新 shell/容器重试最后才是torch.version.cuda不以13开头的 ABI 不匹配。2. 执行 G1–G10 检查GB10 上的十种常见失败模式被编号为 G1–G10编号对工具是 load-bearing 的——报告里每条发现都必须引用 G 编号。gotcha-checks.md 提供每项的可执行只读检查命令。自动化部分由 assets/preflight.sh 完成bash preflight.sh它覆盖 G1、G3、G4、G7、G9输出契约是每条结果行以 G 编号开头后跟 PASS/FAIL/WARN可自动判定时、SKIP不可用时或INFO:G3、G4 的原始读数需要人工判断。脚本头部注释说明了各检查的边界G7 只验证硬件能力不验证内核目标架构sm_121a仍需手动确认G2flash-attn 存在性/Unsloth 覆盖、G6进程排查、G8上游 issue 查询、G10配置审查不可自动化需对照 references/gotcha-checks.md 手动执行。手动检查中有几条命令带副作用或前提执行前注意G5 带宽实测会分配约 4GB 显存并在 UMA 池上反复克隆张量。文档明确标注只在空闲主机上运行不要在活跃工作负载上跑否则可能挤占其他作业的内存。期望实测值 180–192 GB/s而不是 273 GB/s 的规格值。G3 的补救命令sync; echo 3 /proc/sys/vm/drop_caches需要 root会系统性地丢弃整机的 page cache每个进程都会失去缓存文件读不只是训练作业只作为两次运行之间的重置不要当训练中的常规步骤。G4 温度/功耗采样nvidia-smi --query-gputemperature.gpu,power.draw --formatcsv -l 5不消耗权限、Ctrl-C 即可停止但文档要求在代表性负载下跑满 10–15 分钟再下判断功耗在 240W 额定值附近持平而温度持续上升时暂不算限功耗事件功耗平台化在 ~100W 而温度仍在爬升才是限功耗特征。G10双 Spark 场景要求递归搜索 YAML 配置中的tensor_parallel|tp_size|tensor-parallel任何命中都意味着配置错误——双 Spark 只能走 DDP/FSDPTP 不可用。3. 计算内存余量Spark 的 128GB 是 CPU/GPU 共享的统一内存池UMAnvidia-smi只报 CUDA 分配器可见的一侧部分驱动/配置组合下直接返回[N/A], [N/A]。因此余量核算以free -g为准free -g | awk NR2 {print free:, $4, GB}文档给出的规划顺序读free -g减去若干 GB 的 OS/驱动开销得到预算按 uma-accounting.md 工作表估算 weights optimizer gradients activations外加模型加载时的瞬态峰值再与已知锚点核对而不只看估算值模型类别方法实测总量70BQLoRA≈40GB27BLoRApack ≤1024 可跑通9BFull fine-tune宽裕估算贴近预算时文档建议从更短的 packing 或更小的 batch 起步比运行中撞上 OOM 再处理更便宜。4. 写出 env-report.json预检的最后一步是把报告写为工作目录下的env-report.json——除非调用方如拥有runs/date-slug/目录的/finetune调用显式指定了其他路径那应优先遵循显式指定。报告使用完整的检查词汇表每个 G 编号对应pass、fail、warn: detail、skip: reason或info: reading之一与preflight.sh的 PASS/FAIL/WARN/SKIP/INFO 输出契约一致。代理指令中给出的文档示例{ platform: dgx-spark, checks: { G1: pass, G3: warn: 14GB page cache, G9: info: running inside nvcr.io/nvidia/pytorch:25.11-py3 }, headroom_gb: 61, verdict: ready }上面的 JSON 是源文档中的示例字段结构照此即可数值不代表固定预期。读取 env-report.json 并行动判定规则在 dgx-spark-ops-engineer 代理定义 中是明确的三档任一检查为fail或headroom_gb不足以支撑计划工作负载 →blocked只剩warn/skip条目 →ready-with-warnings其余 →ready。blocked时命令定义要求先给出该 gotcha 对应 FIX 条目的具体修复G1 对应换 cu130 wheel 或容器、G3 对应 drop page cache、G9 对应改用容器等见 gotcha-checks.md 与 SKILL.md 的 Quick Reference 表再谈其他建议。代理的行为约束里还有一条它只陈述判定、由调用方决定是否继续不会擅自替你降配工作负载。拿到报告后的核对要点逐条看checksinfo: reading的 G3/G4 是原始读数需要按上文 G3/G4 的判断标准自行解读不能因为不是fail就略过headroom_gb与你的工作负载估算是否留有文档要求的余量而不是贴着预算verdict为blocked时先执行报告指出的那个 gotcha 的 FIX再重跑一次预检确认转为ready或ready-with-warnings。限制与边界预检针对单机 GB10双 Spark 的并行策略限制G10仅 DDP/FSDP属于配置审查不是脚本自动覆盖项。preflight.sh的 G1 检查依赖环境中torch可导入导入不了时输出G1 SKIP: torch not importableG9 的容器判定在未命中任何 marker 时给出G9 UNKNOWN文档明确这不能证明是裸主机。文档中的版本矩阵如nvcr.io/nvidia/pytorch:25.09-py3、transformers 5.13.1等 pin是带日期的已知良好快照stack-matrix.md 要求按Last verified日期判断时效并在长任务前查github.com/NVIDIA/dgx-spark-playbooks的近期 issue——官方 playbook 此前出现过发布即损坏的情况G8。env-report.json默认落在当前工作目录报告只汇总检查结果不会替你启动或修改任何训练任务。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考