尧图网站建设 
GraphTrainer 夜间自我改进哨兵Nightly Scout全解析从发现机会到 AutoDev 交接的自动化闭环【免费下载链接】torchtitanA PyTorch native platform for training generative AI models项目地址: https://gitcode.com/GitHub_Trending/to/torchtitan本篇技术指南系统讲解 torchtitan 仓库中torchtitan/experiments/graph_trainer/.claude/nightly_scout.md所定义的GraphTrainer 夜间自我改进哨兵Nightly Self-Improvement Scout机制。它不是一个 CI 故障检查工具而是一套每天自动运行的机会与风险侦察工作流用于发现核心 torchtitan 上游变更、被阻塞的 TODO、测试覆盖缺口、代码腐化与技术债、文档失实等问题并把发现转化为可执行的 Action Item 交给 AutoDev 代理处理。读完本文你将掌握这套哨兵系统的完整运行流程、每个侦察环节的 CLI 命令与判断标准、报告发布规范以及它与 GitHub Project 看板、AutoDev 代理之间的交接协议并能在自己的 GraphTrainer 开发流程中复现这套发现 — 分诊 — 交接 — 跟踪的闭环。一、Nightly Scout 的定位不是 CI而是尚未行动的机遇与风险该文档开篇即明确了哨兵与 CI 的分工边界Its purpose is NOT to check if things are broken (CI does that). Its purpose is to discoveropportunities and risks we havent acted on yet.也就是说CI 回答现在坏没坏而 Nightly Scout 回答我们有没有错过什么、有没有落后、有没有潜伏的风险。它的目标产物不是通过/失败而是一份优先级分诊清单新发现new findings、顺延项carried forward、机会opportunities、仅供参考项FYI以及文档与全部正常All Clear声明。整份提示词本身就是设计给 Claude Code 以无头模式-p即 print 模式运行的调用方式为claude -p $(cat torchtitan/experiments/graph_trainer/.claude/nightly_scout.md)即把该文件内容作为一次性系统提示喂给 Claude让它在一个会话内完成从侦察到发布报告、再到在看板上创建任务草稿的全部工作。二、运行前置条件基线同步与历史报告加载2.1 同步到最新 main每次运行前先确保工作区处于最新上游状态git checkout main git pull origin main2.2 读取历史报告建立基线报告以评论形式发布在跟踪 issuepytorch/torchtitan#2856上。用gh api抓取最近 7 天的夜间报告# Fetch all comments, filter to nightly reports from the past 7 days gh api repos/pytorch/torchtitan/issues/2856/comments --paginate \ --jq .[] | select(.body | startswith(# Nightly Scout Report)) | {date: .created_at, body: .body}阅读每份报告后需要在头脑中建立三类基线未解决的 Action Items—— 先前报告标记过、但代码库中底层问题依然存在的项后续章节要复核而非从零发现此前一切正常的区域—— 只需轻量核对是否发生变化反复出现的 FYI 项—— 除非情况有实质性变化否则不再重复报告。最关键的是记录最近一份报告的日期它将作为第 1 节git log的--since基线替代写死的窗口若没有历史报告则按首次运行处理。2.3 检查看板已有条目避免重复创建gh project item-list BOARD_NUMBER --owner BOARD_OWNER --format json从条目正文中筛出由历史夜间报告产生的条目按正文中的 Nightly Scout Report 字样识别并记录其状态Done / Abort—— 已解决不得重建In Progress / Need Review—— AutoDev 正在处理Backlog / Ready—— 尚未开始。已有看板条目的问题绝不重复创建对已有条目仅当情况发生实质性变化时才追加状态更新评论。三、核心侦察环节一上游 Delta Review核心 torchtitan 变更审查第 1 节回答的不是上游是否弄坏了我们而是上游有没有我们错过的机会或者我们是否落后了。命令以最近报告日期为基线扫描核心模块git log --sincelast_report_date --oneline -- \ torchtitan/trainer.py \ torchtitan/config/ \ torchtitan/distributed/ \ torchtitan/models/common/ \ torchtitan/models/llama3/ \ torchtitan/models/deepseek_v3/ \ torchtitan/protocols/ \ torchtitan/components/ \ torchtitan/experiments/__init__.py无历史报告时回退到--since1 day ago。对每个 commit 需要回答四类问题是否新增了 GraphTrainer 可以借用的 API例如torchtitan/distributed/下新增了能替代 GraphTrainer 手写实现的工具是否改变了 GraphTrainer 依赖的签名或字段—— 文档明确列出几处易碎表面Trainer.Config字段在configs.py:to_graph_trainer_config中以字典展开方式拷贝BaseModel.preprocess_inputs()的返回元组被内联进Trainer.forward_backward_step/pp_forward_backward_stepCompileConfig字段被GraphTrainerCompileConfig扩展被 monkey-patch 的FlexInnerAttention.forward、MoE.forward签名ParallelDims属性与build_mesh()是否新增了 GraphTrainer 应考虑支持的模型变体是否发生了跨模型代码统一使 GraphTrainer 的按模型封装变得冗余。以仓库源码为证torchtitan/experiments/graph_trainer/configs.py中的to_graph_trainer_config(base_config, model_registry)正是这种脆弱表面的集中体现——它把基座Trainer.Config的所有字段逐个拷贝、用 GraphTrainer 的 model registry 替换model_spec、移除compile字段、并把 eager 的 AC 策略强制替换为SelectiveAC.Config()。因此每当上游Trainer.Config新增字段该函数就是第一个需要检查的落点。输出应给出简要总结与 Action Items或 nothing actionable。四、核心侦察环节二TODO 解除检测动态发现拒绝静态清单GraphTrainer 存在一批依赖上游工作的 TODO。哨兵要求动态发现而非依赖静态列表。4.1 收集全部 TODOgrep -rn TODO\|FIXME\|HACK\|XXX torchtitan/experiments/graph_trainer/ --include*.py对每个 TODO读取其前后几行上下文弄清它被什么阻塞。4.2 与历史报告交叉引用若先前报告已将该 TODO 标记为仍被阻塞且此后无上游活动则快速复核即可仅记录still blocked, no upstream change since YYYY-MM-DD对先前报告未提过的即新增 TODO则必须完整调查。4.3 检查上游进展TODO 引用了 PyTorch PR形如pytorch/pytorch/pull/NNNNN时检查该 PR 是否已合并gh pr view NNNNN --repo pytorch/pytorch --json state,mergedAtTODO 提到具体 API 或特性时在已安装的 torch 包中 grep 验证TODO 指名了 owner 时标记为 owned by X 即可。五、核心侦察环节三测试与 CI 覆盖缺口分析本节回答哪些东西我们应该测却没测、哪些我们本地测了但 CI 没捡起来。执行前提是ghCLI 具备访问 GitHub Actions API 的权限若遇到 api.github.com has not been allowlisted 类错误则跳过 CI 监控部分并在报告中注明 skipped — gh API not allowlisted。5.1 CI 失败监控GraphTrainer 有两条 GitHub Actions 工作流均在仓库.github/workflows/下.github/workflows/integration_test_8gpu_graph_trainer.yamlA10 GPU8 卡集成测试.github/workflows/integration_test_8gpu_graph_trainer_h100.yamlH100 GPU。对每条工作流抓取 main 分支上最近 5 次定时运行gh run list --workflow workflow_name --branch main --event schedule --limit 5最近一次成功则记 CI green 并跳过失败则从 5 次中找出最近一次通过的运行或记录 no recent success in last 5 runs。对每条失败工作流拉取失败任务日志gh run view run_id --log 21从日志中提取(1) 失败的测试——匹配RuntimeError: N integration test(s) failed:之后的测试名或 pytestFAILED汇总行(2) 根因异常如torch._dynamo.exc.UserError、AssertionError、RuntimeError及其消息并附带指向 GraphTrainer 源文件与行号的几行 traceback。5.2 定位 PyTorch nightly 回归区间从失败与上次通过两次运行的日志中搜索Successfully installed.*torch-提取安装的 PyTorch 版本然后下载 wheel 并从torch/version.py提取 git commitpip download torchversion \ --index-url https://download.pytorch.org/whl/nightly/cu130 \ --no-deps -d /tmp/torch_wheel --python-version 3.12 --only-binary :all: unzip -p /tmp/torch_wheel/torch-version-cp312-cp312-manylinux_2_28_x86_64.whl \ torch/version.py | grep git_version报告以表格呈现回归区间NightlyStatusPyTorch Commitdevgood_datePasscommitdevbad_dateFailcommit5.3 生成本地复现命令从失败测试日志中的Command:行剥离TORCH_TRACE...环境变量、--dump_folder ...及其取值、LOG_RANK...环境变量生成最小复现命令NGPUn ./run_train.sh \ --module module \ --config config \ [remaining flags...]5.4 CI 未覆盖的测试Test gap逐一对比torchtitan/experiments/graph_trainer/tests/下每个test_*.py与两条工作流 YAML 中的 pytest/torchrun 调用凡是本地存在但两条工作流都没调用的测试文件即为 CI 缺口需给出建议加入某条工作流的一行式命令。5.5 测试覆盖缺口Coverage gap对比核心 torchtitan 与 GraphTrainer 的并行组合覆盖tests/integration_tests/features.py、tests/integration_tests/h100.pyvstorchtitan/experiments/graph_trainer/tests/integration_tests.py检查torchtitan/experiments/graph_trainer/passes.py中新增的图 pass 是否在torchtitan/experiments/graph_trainer/tests/test_passes.py中有对应测试检查近期 commit 中 GraphTrainer 新增的无测试代码路径检查各config_registry.py注册的模型配置是否有测试或集成测试实际使用。从仓库现状看torchtitan/experiments/graph_trainer/tests/下已有 20 余个测试文件test_passes.py、test_trace_module.py、test_precompile.py、test_numerics.py、test_bitwise_deterministic.py、test_sac_peak_memory.py、test_cpu_offload.py、test_graph_pp_passes.py等而 A10 工作流实际调用的仅是其中一部分这正是本地有、CI 未拾取的天然排查对象。六、核心侦察环节四代码新鲜度与技术债检测 GraphTrainer 偏离核心 torchtitan 现行做法之处。对先前报告标记all clear或signature-stable的项仅当相关上游文件在报告日期后发生变化时才复核对已上报的债务项验证是否已被处理未处理则顺延。6.1 过期的 monkey-patchGraphTrainer 对FlexInnerAttention.forward、MoE.forward、ExpertParallel._token_dispatch/_token_combine打补丁。需检查上游签名是否已变化导致补丁在做无用功或漏掉新参数。仓库中的torchtitan/experiments/graph_trainer/common_utils.py、ep_eager_chunk.py及测试test_passes.py、test_trace_module.py均涉及相关 monkey-patch 逻辑是核查的入口。6.2 私有 API 使用simple_fsdp.py使用DTensorSpec、redistribute_local_tensor、_StridedShard需检查近期 PyTorch 是否出现了公开替代品。6.3 重复实现检查 GraphTrainer 是否在重复实现核心 torchtitan 现已提供的公共工具常见对比区域激活检查点策略passes.pyvstorchtitan/distributed/activation_checkpoint.pyFSDP 包装逻辑simple_fsdp.pyvstorchtitan/distributed/fsdp.py模型并行化模式GraphTrainer 的parallelize.pyvs 核心版本。6.4 配置漂移在脑中运行一遍to_graph_trainer_config()Trainer.Config是否有新增字段没有被拷贝过去、或需要 GraphTrainer 特有的处理。输出应为带严重级别的具体债务项清单blocking阻塞/ should-fix应修/ nice-to-have可优化。七、核心侦察环节五与六文档新鲜度与在途工作跟踪7.1 文档新鲜度核对torchtitan/experiments/graph_trainer/.claude/CLAUDE.md中的文件路径、测试命令、CLI 参数是否仍然有效抽查提到的测试文件是否仍存在、benchmark 命令能否正确解析核对torchtitan/experiments/graph_trainer/README.md是否与当前功能集和受支持模型一致核对 Claude 记忆文件中保存的运行命令是否仍然正确排查是否有新特性或新 pass 没有在任何文档中说明。输出具体失实之处或 docs are current。以仓库为证CLAUDE.md中约定的 graph pass 签名def my_pass(gm, example_inputs, *, other_kwargs) - torch.fx.GraphModule、pass 分层passes.py数值保持型 vsperformance_passes.py数值变更型、--compile.memory_policy的五种取值default/full/eager/min_cut/sac_and_offload等都可作为文档与实际代码的对照基准。7.2 在途工作跟踪以先前报告的 PR/issue 状态为基线只突出变化新 PR、新变 stale 的 PR、最近合并# PRs touching graph_trainer gh pr list --search graph_trainer --state open --repo pytorch/torchtitan # Recent merged PRs (last 7 days) gh pr list --search graph_trainer --state merged --limit 10 --repo pytorch/torchtitan # Issues mentioning graph_trainer gh issue list --search graph_trainer --state open --repo pytorch/torchtitan标记(1) 等待评审超过 5 天的开放 PR(2) 24 小时内合并、可能需要跟进文档更新、新测试的 PR(3) 超过 14 天无活动的 issue。八、报告发布模板、去重规则与保持简短8.1 发布位置与命令报告作为评论发布到跟踪 issuepytorch/torchtitan#2856gh issue comment 2856 --repo pytorch/torchtitan --body $(cat EOF # Nightly Scout Report — YYYY-MM-DD ## CI Failures - **Workflow**: name — status (green / N of last 5 failed) - **Failing test**: test name - **Error**: root-cause exception and message - **Regression range**: devgood (commit) → devbad (commit) - **Repro**: NGPU... ./run_train.sh ... (or CI green, nothing to report) ## Action Items (new findings) - [ ] [P0/P1/P2] Description — why, what file/area ## Carried Forward (from prior reports, re-investigated) - [ ] [Pn] Description — first reported YYYY-MM-DD, status update ## Opportunities (things to consider) - Description — potential benefit ## FYI (awareness, no action needed) - Description ## Docs - Inaccuracies found, or docs are current ## All Clear - Areas with nothing to report EOF )8.2 保持简短与去重规则某节无内容就写 nothing to report 并继续不重复 CI 已经告知的信息聚焦人类开发者不主动看就不会注意到的内容新不在 Step 0a 任何历史报告中的项顺延出现在历史报告且底层问题仍存在需附简短状态更新如 no upstream change、partial fix landed、situation worsened噪音抑制连续 3 份报告无变化的 FYI 项应整体从报告中删除。九、交接协议把 Action Item 移交 AutoDev哨兵不直接实现修复——它只负责发现与分诊。报告发布后需要为每个 Action Item 在看板上创建草稿供 AutoDev 代理见 AutoDev 工作流拾取。9.1 看板配置与 autodev.md 保持一致变量默认值BOARD_NUMBER161BOARD_OWNERpytorchPROJECT_IDPVT_kwDOAUB9vs4BT6Cu9.2 创建前查重gh project item-list BOARD_NUMBER --owner BOARD_OWNER --format json按标题与描述与现有条目逐项比对若已有条目覆盖同一问题则跳过。9.3 创建 Backlog 草稿对报告中每个新Action Item已有看板条目的顺延项不建新草稿创建看板草稿gh project item-create BOARD_NUMBER --owner BOARD_OWNER \ --title [NightlyScout][Pn] Short description \ --body $(cat EOF **Source:** Nightly Scout Report — YYYY-MM-DD **Priority:** P0 / P1 / P2 **Section:** (which report section discovered this) ## Problem What was found and why it matters. ## Suggested Fix Concrete guidance on what to change and where. ## References - Report comment: link to the §7 report comment - Relevant files: list of files involved EOF )规则要点一个 Action Item 一个看板条目不打包合并标题前缀固定为[NightlyScout][Pn]便于在看板上识别与 §8b 查重过滤描述必须可执行让 AutoDev 代理无需重读完整报告即可开工只建新发现已有看板条目的顺延项只更新原条目必须落在 Backlog 状态看板默认列可能不是 Backlog创建后需显式设置状态# Get the Status field ID and Backlog option ID FIELD_ID$(gh project field-list BOARD_NUMBER --owner BOARD_OWNER --format json \ --jq .fields[] | select(.name Status) | .id) BACKLOG_ID$(gh project field-list BOARD_NUMBER --owner BOARD_OWNER --format json \ --jq .fields[] | select(.name Status) | .options[] | select(.name Backlog) | .id) # Set the item to Backlog (replace ITEM_ID with the created items ID) gh project item-edit --project-id PROJECT_ID --id ITEM_ID \ --field-id $FIELD_ID --single-select-option-id $BACKLOG_ID由开发者决定何时把条目移到Ready无论优先级多高包括 P0都不允许直接放到 Ready一律先进 Backlog。9.4 回填报告评论编辑第 7 节发布的报告评论把每个 Action Item 链接到其看板条目使用看板条目 URL 或 ID。先找到今天的报告评论 ID再 PATCH 更新正文# Find the comment ID for todays report COMMENT_ID$(gh api repos/pytorch/torchtitan/issues/2856/comments --paginate \ --jq .[] | select(.body | startswith(# Nightly Scout Report — YYYY-MM-DD)) | .id) # Update the comment body with board item links gh api repos/pytorch/torchtitan/issues/comments/$COMMENT_ID \ --method PATCH --field bodyupdated report body十、与 AutoDev 工作流的协作边界理解哨兵机制还需要看它与兄弟文档的分工。torchtitan/experiments/graph_trainer/.claude/autodev.md定义了 AutoDev 代理的持续循环轮询看板 → 领取可执行条目仅In Progress / Ready且绝不读取 Backlog/Blocked/Done/Abort 条目的评论→ 派生 subagent 实现 → 以[GraphTrainer][AutoDev]前缀创建草稿 PR → 移到Need Review。看板状态机中状态谁负责移动Backlog→Ready仅开发者In Progress / Blocked / Need ReviewAgent或开发者Done / Abort仅开发者哨兵创建的 Backlog 草稿正是该状态机的输入端之一开发者把草稿提升为 Ready 后AutoDev 才可能处理。此外AutoDev 只响应受信任评审人列表定义在autodev.md的TRUSTED数组中的评论并以AutoDev:前缀回复。三者CLAUDE.md 开发指南、nightly_scout.md 侦察、autodev.md 执行共同构成了 GraphTrainer 实验的人机协作开发闭环。十一、在仓库中验证与落地本仓库为该机制提供了完整的工程载体可按下述路径进一步阅读侦察与分诊逻辑本体nightly_scout.md、autodev.md、CLAUDE.md配置脆弱表面与转换逻辑configs.pyto_graph_trainer_config、GraphTrainerCompileConfig、EpOverlapConfig及配套校验函数validate_ep_overlap_config/validate_autoparallel_config被审查的代码区域passes.py、simple_fsdp.py、performance_passes.py、common_utils.py测试覆盖比对对象tests 目录、核心集成测试 与 h100.pyCI 工作流本体integration_test_8gpu_graph_trainer.yaml每 12 小时定时、A10 8 卡与其 H100 变体文档新鲜度核对对象README.md含支持模型、编译优化、EP overlap、预编译、组合性支持矩阵等。实际接入时需注意三点前提其一该机制面向 pytorch/torchtitan 官方仓库与 AutoDev 看板board 161fork 或内部部署需相应替换 issue/board 编号与gh权限其二大量命令依赖ghCLI 且需 GitHub API 白名单受限环境下应按文档约定在报告中显式标记 skipped其三PyTorch nightly 回归定位依赖 cu130 索引与 CPython 3.12 wheel其他 CUDA/Python 组合需调整--index-url与 wheel 文件名。这套CI 之外的第二双眼睛的设计思路——动态发现、基线化去重、分诊交接——同样适用于任何以图编译为核心、且高度依赖上游 nightly 演进的中型分布式训练工程。【免费下载链接】torchtitanA PyTorch native platform for training generative AI models项目地址: https://gitcode.com/GitHub_Trending/to/torchtitan创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 GraphTrainer 夜间自我改进哨兵（Nightly Scout）全解析：从发现机会到 AutoDev 交接的自动化闭环
GraphTrainer 夜间自我改进哨兵Nightly Scout全解析从发现机会到 AutoDev 交接的自动化闭环【免费下载链接】torchtitanA PyTorch native platform for training generative AI models项目地址: https://gitcode.com/GitHub_Trending/to/torchtitan本篇技术指南系统讲解 torchtitan 仓库中torchtitan/experiments/graph_trainer/.claude/nightly_scout.md所定义的GraphTrainer 夜间自我改进哨兵Nightly Self-Improvement Scout机制。它不是一个 CI 故障检查工具而是一套每天自动运行的机会与风险侦察工作流用于发现核心 torchtitan 上游变更、被阻塞的 TODO、测试覆盖缺口、代码腐化与技术债、文档失实等问题并把发现转化为可执行的 Action Item 交给 AutoDev 代理处理。读完本文你将掌握这套哨兵系统的完整运行流程、每个侦察环节的 CLI 命令与判断标准、报告发布规范以及它与 GitHub Project 看板、AutoDev 代理之间的交接协议并能在自己的 GraphTrainer 开发流程中复现这套发现 — 分诊 — 交接 — 跟踪的闭环。一、Nightly Scout 的定位不是 CI而是尚未行动的机遇与风险该文档开篇即明确了哨兵与 CI 的分工边界Its purpose is NOT to check if things are broken (CI does that). Its purpose is to discoveropportunities and risks we havent acted on yet.也就是说CI 回答现在坏没坏而 Nightly Scout 回答我们有没有错过什么、有没有落后、有没有潜伏的风险。它的目标产物不是通过/失败而是一份优先级分诊清单新发现new findings、顺延项carried forward、机会opportunities、仅供参考项FYI以及文档与全部正常All Clear声明。整份提示词本身就是设计给 Claude Code 以无头模式-p即 print 模式运行的调用方式为claude -p $(cat torchtitan/experiments/graph_trainer/.claude/nightly_scout.md)即把该文件内容作为一次性系统提示喂给 Claude让它在一个会话内完成从侦察到发布报告、再到在看板上创建任务草稿的全部工作。二、运行前置条件基线同步与历史报告加载2.1 同步到最新 main每次运行前先确保工作区处于最新上游状态git checkout main git pull origin main2.2 读取历史报告建立基线报告以评论形式发布在跟踪 issuepytorch/torchtitan#2856上。用gh api抓取最近 7 天的夜间报告# Fetch all comments, filter to nightly reports from the past 7 days gh api repos/pytorch/torchtitan/issues/2856/comments --paginate \ --jq .[] | select(.body | startswith(# Nightly Scout Report)) | {date: .created_at, body: .body}阅读每份报告后需要在头脑中建立三类基线未解决的 Action Items—— 先前报告标记过、但代码库中底层问题依然存在的项后续章节要复核而非从零发现此前一切正常的区域—— 只需轻量核对是否发生变化反复出现的 FYI 项—— 除非情况有实质性变化否则不再重复报告。最关键的是记录最近一份报告的日期它将作为第 1 节git log的--since基线替代写死的窗口若没有历史报告则按首次运行处理。2.3 检查看板已有条目避免重复创建gh project item-list BOARD_NUMBER --owner BOARD_OWNER --format json从条目正文中筛出由历史夜间报告产生的条目按正文中的 Nightly Scout Report 字样识别并记录其状态Done / Abort—— 已解决不得重建In Progress / Need Review—— AutoDev 正在处理Backlog / Ready—— 尚未开始。已有看板条目的问题绝不重复创建对已有条目仅当情况发生实质性变化时才追加状态更新评论。三、核心侦察环节一上游 Delta Review核心 torchtitan 变更审查第 1 节回答的不是上游是否弄坏了我们而是上游有没有我们错过的机会或者我们是否落后了。命令以最近报告日期为基线扫描核心模块git log --sincelast_report_date --oneline -- \ torchtitan/trainer.py \ torchtitan/config/ \ torchtitan/distributed/ \ torchtitan/models/common/ \ torchtitan/models/llama3/ \ torchtitan/models/deepseek_v3/ \ torchtitan/protocols/ \ torchtitan/components/ \ torchtitan/experiments/__init__.py无历史报告时回退到--since1 day ago。对每个 commit 需要回答四类问题是否新增了 GraphTrainer 可以借用的 API例如torchtitan/distributed/下新增了能替代 GraphTrainer 手写实现的工具是否改变了 GraphTrainer 依赖的签名或字段—— 文档明确列出几处易碎表面Trainer.Config字段在configs.py:to_graph_trainer_config中以字典展开方式拷贝BaseModel.preprocess_inputs()的返回元组被内联进Trainer.forward_backward_step/pp_forward_backward_stepCompileConfig字段被GraphTrainerCompileConfig扩展被 monkey-patch 的FlexInnerAttention.forward、MoE.forward签名ParallelDims属性与build_mesh()是否新增了 GraphTrainer 应考虑支持的模型变体是否发生了跨模型代码统一使 GraphTrainer 的按模型封装变得冗余。以仓库源码为证torchtitan/experiments/graph_trainer/configs.py中的to_graph_trainer_config(base_config, model_registry)正是这种脆弱表面的集中体现——它把基座Trainer.Config的所有字段逐个拷贝、用 GraphTrainer 的 model registry 替换model_spec、移除compile字段、并把 eager 的 AC 策略强制替换为SelectiveAC.Config()。因此每当上游Trainer.Config新增字段该函数就是第一个需要检查的落点。输出应给出简要总结与 Action Items或 nothing actionable。四、核心侦察环节二TODO 解除检测动态发现拒绝静态清单GraphTrainer 存在一批依赖上游工作的 TODO。哨兵要求动态发现而非依赖静态列表。4.1 收集全部 TODOgrep -rn TODO\|FIXME\|HACK\|XXX torchtitan/experiments/graph_trainer/ --include*.py对每个 TODO读取其前后几行上下文弄清它被什么阻塞。4.2 与历史报告交叉引用若先前报告已将该 TODO 标记为仍被阻塞且此后无上游活动则快速复核即可仅记录still blocked, no upstream change since YYYY-MM-DD对先前报告未提过的即新增 TODO则必须完整调查。4.3 检查上游进展TODO 引用了 PyTorch PR形如pytorch/pytorch/pull/NNNNN时检查该 PR 是否已合并gh pr view NNNNN --repo pytorch/pytorch --json state,mergedAtTODO 提到具体 API 或特性时在已安装的 torch 包中 grep 验证TODO 指名了 owner 时标记为 owned by X 即可。五、核心侦察环节三测试与 CI 覆盖缺口分析本节回答哪些东西我们应该测却没测、哪些我们本地测了但 CI 没捡起来。执行前提是ghCLI 具备访问 GitHub Actions API 的权限若遇到 api.github.com has not been allowlisted 类错误则跳过 CI 监控部分并在报告中注明 skipped — gh API not allowlisted。5.1 CI 失败监控GraphTrainer 有两条 GitHub Actions 工作流均在仓库.github/workflows/下.github/workflows/integration_test_8gpu_graph_trainer.yamlA10 GPU8 卡集成测试.github/workflows/integration_test_8gpu_graph_trainer_h100.yamlH100 GPU。对每条工作流抓取 main 分支上最近 5 次定时运行gh run list --workflow workflow_name --branch main --event schedule --limit 5最近一次成功则记 CI green 并跳过失败则从 5 次中找出最近一次通过的运行或记录 no recent success in last 5 runs。对每条失败工作流拉取失败任务日志gh run view run_id --log 21从日志中提取(1) 失败的测试——匹配RuntimeError: N integration test(s) failed:之后的测试名或 pytestFAILED汇总行(2) 根因异常如torch._dynamo.exc.UserError、AssertionError、RuntimeError及其消息并附带指向 GraphTrainer 源文件与行号的几行 traceback。5.2 定位 PyTorch nightly 回归区间从失败与上次通过两次运行的日志中搜索Successfully installed.*torch-提取安装的 PyTorch 版本然后下载 wheel 并从torch/version.py提取 git commitpip download torchversion \ --index-url https://download.pytorch.org/whl/nightly/cu130 \ --no-deps -d /tmp/torch_wheel --python-version 3.12 --only-binary :all: unzip -p /tmp/torch_wheel/torch-version-cp312-cp312-manylinux_2_28_x86_64.whl \ torch/version.py | grep git_version报告以表格呈现回归区间NightlyStatusPyTorch Commitdevgood_datePasscommitdevbad_dateFailcommit5.3 生成本地复现命令从失败测试日志中的Command:行剥离TORCH_TRACE...环境变量、--dump_folder ...及其取值、LOG_RANK...环境变量生成最小复现命令NGPUn ./run_train.sh \ --module module \ --config config \ [remaining flags...]5.4 CI 未覆盖的测试Test gap逐一对比torchtitan/experiments/graph_trainer/tests/下每个test_*.py与两条工作流 YAML 中的 pytest/torchrun 调用凡是本地存在但两条工作流都没调用的测试文件即为 CI 缺口需给出建议加入某条工作流的一行式命令。5.5 测试覆盖缺口Coverage gap对比核心 torchtitan 与 GraphTrainer 的并行组合覆盖tests/integration_tests/features.py、tests/integration_tests/h100.pyvstorchtitan/experiments/graph_trainer/tests/integration_tests.py检查torchtitan/experiments/graph_trainer/passes.py中新增的图 pass 是否在torchtitan/experiments/graph_trainer/tests/test_passes.py中有对应测试检查近期 commit 中 GraphTrainer 新增的无测试代码路径检查各config_registry.py注册的模型配置是否有测试或集成测试实际使用。从仓库现状看torchtitan/experiments/graph_trainer/tests/下已有 20 余个测试文件test_passes.py、test_trace_module.py、test_precompile.py、test_numerics.py、test_bitwise_deterministic.py、test_sac_peak_memory.py、test_cpu_offload.py、test_graph_pp_passes.py等而 A10 工作流实际调用的仅是其中一部分这正是本地有、CI 未拾取的天然排查对象。六、核心侦察环节四代码新鲜度与技术债检测 GraphTrainer 偏离核心 torchtitan 现行做法之处。对先前报告标记all clear或signature-stable的项仅当相关上游文件在报告日期后发生变化时才复核对已上报的债务项验证是否已被处理未处理则顺延。6.1 过期的 monkey-patchGraphTrainer 对FlexInnerAttention.forward、MoE.forward、ExpertParallel._token_dispatch/_token_combine打补丁。需检查上游签名是否已变化导致补丁在做无用功或漏掉新参数。仓库中的torchtitan/experiments/graph_trainer/common_utils.py、ep_eager_chunk.py及测试test_passes.py、test_trace_module.py均涉及相关 monkey-patch 逻辑是核查的入口。6.2 私有 API 使用simple_fsdp.py使用DTensorSpec、redistribute_local_tensor、_StridedShard需检查近期 PyTorch 是否出现了公开替代品。6.3 重复实现检查 GraphTrainer 是否在重复实现核心 torchtitan 现已提供的公共工具常见对比区域激活检查点策略passes.pyvstorchtitan/distributed/activation_checkpoint.pyFSDP 包装逻辑simple_fsdp.pyvstorchtitan/distributed/fsdp.py模型并行化模式GraphTrainer 的parallelize.pyvs 核心版本。6.4 配置漂移在脑中运行一遍to_graph_trainer_config()Trainer.Config是否有新增字段没有被拷贝过去、或需要 GraphTrainer 特有的处理。输出应为带严重级别的具体债务项清单blocking阻塞/ should-fix应修/ nice-to-have可优化。七、核心侦察环节五与六文档新鲜度与在途工作跟踪7.1 文档新鲜度核对torchtitan/experiments/graph_trainer/.claude/CLAUDE.md中的文件路径、测试命令、CLI 参数是否仍然有效抽查提到的测试文件是否仍存在、benchmark 命令能否正确解析核对torchtitan/experiments/graph_trainer/README.md是否与当前功能集和受支持模型一致核对 Claude 记忆文件中保存的运行命令是否仍然正确排查是否有新特性或新 pass 没有在任何文档中说明。输出具体失实之处或 docs are current。以仓库为证CLAUDE.md中约定的 graph pass 签名def my_pass(gm, example_inputs, *, other_kwargs) - torch.fx.GraphModule、pass 分层passes.py数值保持型 vsperformance_passes.py数值变更型、--compile.memory_policy的五种取值default/full/eager/min_cut/sac_and_offload等都可作为文档与实际代码的对照基准。7.2 在途工作跟踪以先前报告的 PR/issue 状态为基线只突出变化新 PR、新变 stale 的 PR、最近合并# PRs touching graph_trainer gh pr list --search graph_trainer --state open --repo pytorch/torchtitan # Recent merged PRs (last 7 days) gh pr list --search graph_trainer --state merged --limit 10 --repo pytorch/torchtitan # Issues mentioning graph_trainer gh issue list --search graph_trainer --state open --repo pytorch/torchtitan标记(1) 等待评审超过 5 天的开放 PR(2) 24 小时内合并、可能需要跟进文档更新、新测试的 PR(3) 超过 14 天无活动的 issue。八、报告发布模板、去重规则与保持简短8.1 发布位置与命令报告作为评论发布到跟踪 issuepytorch/torchtitan#2856gh issue comment 2856 --repo pytorch/torchtitan --body $(cat EOF # Nightly Scout Report — YYYY-MM-DD ## CI Failures - **Workflow**: name — status (green / N of last 5 failed) - **Failing test**: test name - **Error**: root-cause exception and message - **Regression range**: devgood (commit) → devbad (commit) - **Repro**: NGPU... ./run_train.sh ... (or CI green, nothing to report) ## Action Items (new findings) - [ ] [P0/P1/P2] Description — why, what file/area ## Carried Forward (from prior reports, re-investigated) - [ ] [Pn] Description — first reported YYYY-MM-DD, status update ## Opportunities (things to consider) - Description — potential benefit ## FYI (awareness, no action needed) - Description ## Docs - Inaccuracies found, or docs are current ## All Clear - Areas with nothing to report EOF )8.2 保持简短与去重规则某节无内容就写 nothing to report 并继续不重复 CI 已经告知的信息聚焦人类开发者不主动看就不会注意到的内容新不在 Step 0a 任何历史报告中的项顺延出现在历史报告且底层问题仍存在需附简短状态更新如 no upstream change、partial fix landed、situation worsened噪音抑制连续 3 份报告无变化的 FYI 项应整体从报告中删除。九、交接协议把 Action Item 移交 AutoDev哨兵不直接实现修复——它只负责发现与分诊。报告发布后需要为每个 Action Item 在看板上创建草稿供 AutoDev 代理见 AutoDev 工作流拾取。9.1 看板配置与 autodev.md 保持一致变量默认值BOARD_NUMBER161BOARD_OWNERpytorchPROJECT_IDPVT_kwDOAUB9vs4BT6Cu9.2 创建前查重gh project item-list BOARD_NUMBER --owner BOARD_OWNER --format json按标题与描述与现有条目逐项比对若已有条目覆盖同一问题则跳过。9.3 创建 Backlog 草稿对报告中每个新Action Item已有看板条目的顺延项不建新草稿创建看板草稿gh project item-create BOARD_NUMBER --owner BOARD_OWNER \ --title [NightlyScout][Pn] Short description \ --body $(cat EOF **Source:** Nightly Scout Report — YYYY-MM-DD **Priority:** P0 / P1 / P2 **Section:** (which report section discovered this) ## Problem What was found and why it matters. ## Suggested Fix Concrete guidance on what to change and where. ## References - Report comment: link to the §7 report comment - Relevant files: list of files involved EOF )规则要点一个 Action Item 一个看板条目不打包合并标题前缀固定为[NightlyScout][Pn]便于在看板上识别与 §8b 查重过滤描述必须可执行让 AutoDev 代理无需重读完整报告即可开工只建新发现已有看板条目的顺延项只更新原条目必须落在 Backlog 状态看板默认列可能不是 Backlog创建后需显式设置状态# Get the Status field ID and Backlog option ID FIELD_ID$(gh project field-list BOARD_NUMBER --owner BOARD_OWNER --format json \ --jq .fields[] | select(.name Status) | .id) BACKLOG_ID$(gh project field-list BOARD_NUMBER --owner BOARD_OWNER --format json \ --jq .fields[] | select(.name Status) | .options[] | select(.name Backlog) | .id) # Set the item to Backlog (replace ITEM_ID with the created items ID) gh project item-edit --project-id PROJECT_ID --id ITEM_ID \ --field-id $FIELD_ID --single-select-option-id $BACKLOG_ID由开发者决定何时把条目移到Ready无论优先级多高包括 P0都不允许直接放到 Ready一律先进 Backlog。9.4 回填报告评论编辑第 7 节发布的报告评论把每个 Action Item 链接到其看板条目使用看板条目 URL 或 ID。先找到今天的报告评论 ID再 PATCH 更新正文# Find the comment ID for todays report COMMENT_ID$(gh api repos/pytorch/torchtitan/issues/2856/comments --paginate \ --jq .[] | select(.body | startswith(# Nightly Scout Report — YYYY-MM-DD)) | .id) # Update the comment body with board item links gh api repos/pytorch/torchtitan/issues/comments/$COMMENT_ID \ --method PATCH --field bodyupdated report body十、与 AutoDev 工作流的协作边界理解哨兵机制还需要看它与兄弟文档的分工。torchtitan/experiments/graph_trainer/.claude/autodev.md定义了 AutoDev 代理的持续循环轮询看板 → 领取可执行条目仅In Progress / Ready且绝不读取 Backlog/Blocked/Done/Abort 条目的评论→ 派生 subagent 实现 → 以[GraphTrainer][AutoDev]前缀创建草稿 PR → 移到Need Review。看板状态机中状态谁负责移动Backlog→Ready仅开发者In Progress / Blocked / Need ReviewAgent或开发者Done / Abort仅开发者哨兵创建的 Backlog 草稿正是该状态机的输入端之一开发者把草稿提升为 Ready 后AutoDev 才可能处理。此外AutoDev 只响应受信任评审人列表定义在autodev.md的TRUSTED数组中的评论并以AutoDev:前缀回复。三者CLAUDE.md 开发指南、nightly_scout.md 侦察、autodev.md 执行共同构成了 GraphTrainer 实验的人机协作开发闭环。十一、在仓库中验证与落地本仓库为该机制提供了完整的工程载体可按下述路径进一步阅读侦察与分诊逻辑本体nightly_scout.md、autodev.md、CLAUDE.md配置脆弱表面与转换逻辑configs.pyto_graph_trainer_config、GraphTrainerCompileConfig、EpOverlapConfig及配套校验函数validate_ep_overlap_config/validate_autoparallel_config被审查的代码区域passes.py、simple_fsdp.py、performance_passes.py、common_utils.py测试覆盖比对对象tests 目录、核心集成测试 与 h100.pyCI 工作流本体integration_test_8gpu_graph_trainer.yaml每 12 小时定时、A10 8 卡与其 H100 变体文档新鲜度核对对象README.md含支持模型、编译优化、EP overlap、预编译、组合性支持矩阵等。实际接入时需注意三点前提其一该机制面向 pytorch/torchtitan 官方仓库与 AutoDev 看板board 161fork 或内部部署需相应替换 issue/board 编号与gh权限其二大量命令依赖ghCLI 且需 GitHub API 白名单受限环境下应按文档约定在报告中显式标记 skipped其三PyTorch nightly 回归定位依赖 cu130 索引与 CPython 3.12 wheel其他 CUDA/Python 组合需调整--index-url与 wheel 文件名。这套CI 之外的第二双眼睛的设计思路——动态发现、基线化去重、分诊交接——同样适用于任何以图编译为核心、且高度依赖上游 nightly 演进的中型分布式训练工程。【免费下载链接】torchtitanA PyTorch native platform for training generative AI models项目地址: https://gitcode.com/GitHub_Trending/to/torchtitan创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考