viable/strict/1789800981: Add annotation_config["key_by"]="auto" (#197577)
PyTorch 发布 viable/strict/1789800981 变更（#197577），为 annotation_config 增加 "key_by"="auto"。"source" 在不支持上报 source node id 的栈上会抛错，"auto" 在 capture_begin 阶段解析：当 source_node_ids_available() 为真时解析为 "source"，否则为 "exec"，且不抛错；"exec" 仍为默认值。证据指出 Cuspy 按 source-then-exec 解析，而 kineto 只上报 exec graph node id，因此经其导出的 trace 无法解析 capture-keyed 注解；若默认改为 "auto"，在 13.4 栈上会使 kineto 用户的注解集静默变空。测试在 GB200、CUDA driver 615.71.09 上运行 test/test_cuda_graph_utils.py，121 项通过。
发展脉络
- 首次出现viable/strict/1789800981: Add annotation_config["key_by"]="auto" (#197577)PyTorch Core
- 当前判断这是一处面向 profiler 与 CUDA graph 注解互操作性的兼容性修补，而非能力扩张。证据显示同一栈上不同消费方对键空间的理解不一致，会直接影响 trace 中注解的可解析性；在默认值切换前，生态内工具链的注解语义仍取决于具体消费方实现。Agent Pulse · 分析
PyTorch 核心仓库出现一项针对 CUDA graph 注解键空间的变更（#197577）：新增 annotation_config["key_by"]="auto"。按证据描述，"source" 在不具备上报 source node id 能力的栈上会抛错，调用方若只想要可用的键控方式，必须先自行探测驱动；"auto" 把这一判断交给 capture 本身，在 capture_begin 阶段、任何记录发生之前完成解析，解析结果只会是 "source" 或 "exec" 之一，因此下游看到的仍是两个真实键空间之一，且不会抛错。"exec" 保持默认。证据同时指出能力归属存在分歧：Cuspy 采用 source-then-exec，而 kineto 只上报 exec graph node id，导致经 kineto 导出的 trace 无法解析 capture-keyed 注解；若此时把默认值改为 "auto"，在 13.4 栈上会让 kineto 用户的注解集静默变空。测试计划在 GB200 与 CUDA driver 615.71.09 上执行 test/test_cuda_graph_utils.py，121 项通过，新增测试在 "auto" 下捕获两次，其中一次关闭能力探测，断言注解被重新键控到 exec graph。
从证据看，键空间选择被明确归因于消费方而非 CUPTI，且 Cuspy 与 kineto 在 source/exec 能力上并不一致，因此 "auto" 本质是把一次运行时能力探测前移到 capture_begin，避免调用方自行探测驱动。可验证的下一信号是：kineto 路径能否读取 sourceGraphNodeId，以及默认值是否随之从 "exec" 切换为 "auto"。
这是一处面向 profiler 与 CUDA graph 注解互操作性的兼容性修补，而非能力扩张。证据显示同一栈上不同消费方对键空间的理解不一致，会直接影响 trace 中注解的可解析性；在默认值切换前，生态内工具链的注解语义仍取决于具体消费方实现。
对依赖 CUDA graph 注解做性能归因的团队而言，键空间不一致意味着同一份 trace 在不同消费方下可能得到不同甚至为空的注解集，影响性能分析结论的可复现性。证据提示在 13.4 栈上把默认改为 "auto" 会让 kineto 用户注解静默变空，因此升级前需确认所用消费方是否支持 source node id。
若 kineto 能读取 sourceGraphNodeId，按证据中给出的条件，默认值存在被切换为 "auto" 的可能；在此之前，"exec" 仍是默认，注解键空间的分歧会继续存在。可观察的下一信号是该路径的读取能力是否落地，以及默认值是否变更。