viable/strict/1790188383: Initialize compile context for non-strict export tracing (#186495)
PyTorch 合并 PR #186495，为非严格导出（strict=False）入口安装 CompileContext。此前非严格导出直接走 make_fx/AOT 导出路径，不进入 Dynamo 的 compile-frame 包装，导致 TORCH_TRACE 结构化日志缺少 CompileContext，只能输出不含 frame_id 的栈元数据，而 tlparse 依赖这些 compile/frame 标识把导出事件关联到 trace。严格导出继续使用 Dynamo 既有上下文，嵌套导出复用环境上下文。微基准（3 次预热、20 次测量）显示无显著开销：main 中位数 0.0053274075s、均值 0.0053913514s，修复后中位数 0.0053788759s。
Development
- First Reportviable/strict/1790188383: Initialize compile context for non-strict export tracing (#186495)PyTorch Core
- Current Assessment该改动指向编译/导出栈的可观测性正成为工程重点：当导出路径分叉（严格与非严格）时，日志与 trace 的关联标识容易断裂，影响调试与性能归因工具链。证据仅覆盖 PyTorch 单一仓库，尚不足以判断其他框架是否面临同类问题。Agent Pulse · analysis
PyTorch 发布 viable/strict/1790188383 版本，包含 PR #186495：为非严格导出（torch.export.export(..., strict=False)）入口安装 CompileContext。证据说明，非严格导出直接经过 make_fx/AOT 导出路径，不进入 Dynamo 的 compile-frame 包装，因此结构化日志在 TORCH_TRACE 记录中看不到 CompileContext，退化为输出不含 frame_id 的栈元数据；tlparse 依赖这些 compile/frame 标识将导出事件关联到 trace。修复方式是在调用方未安装上下文时，于非严格导出入口包裹 CompileContext；严格导出沿用 Dynamo 既有上下文，嵌套导出复用环境上下文而非再分配。作者称替代方案是在各调用点手动传 compile_id，但会漏掉导出之下产生的 trace 记录（如 fake tensor 与 shape 日志）。微基准显示无显著开销。
从证据看，这是可观测性链路的一致性修复：非严格导出绕过 Dynamo 包装后，trace 记录缺少 frame_id，下游 tlparse 无法把导出事件挂到 trace 上。选择在入口包裹而非逐调用点传 compile_id，理由是后者会漏掉导出内部产生的 fake tensor 与 shape 日志，属于根因修复。是否真正无回归仍需看更复杂模型与嵌套导出场景下的开销数据。
该改动指向编译/导出栈的可观测性正成为工程重点：当导出路径分叉（严格与非严格）时，日志与 trace 的关联标识容易断裂，影响调试与性能归因工具链。证据仅覆盖 PyTorch 单一仓库，尚不足以判断其他框架是否面临同类问题。
对依赖 torch.export 与 TORCH_TRACE/tlparse 做导出调试和性能归因的团队，此修复减少因缺失 frame_id 导致的 trace 断链排查成本；但证据未给出生产规模收益数据，价值判断应保持谨慎。
可验证的下一信号：后续 PyTorch 版本说明或 tlparse 侧是否出现针对非严格导出 trace 关联的补充修复，以及是否公布更大规模模型上的开销基准。