viable/strict/1789924990: [inductor] Route compile options through backend registrations (#194998)
PyTorch 合并 PR #194998：Inductor 后端可通过 register_backend_for_device(device_custom_config=...) 注册后端自有 ConfigModule，此前该模块的值无法经 torch.compile(options=...) 传入。该 PR 允许以 "<device>.<key>" 命名空间形式传入编译选项，核心 Inductor 选项名优先于设备命名空间，后端注册在解析命名空间选项前按需初始化，同一路由用于 torch.compile、直接 Inductor 编译、AOTI 与独立编译，子进程编译时注册配置在父进程捕获并在 worker 应用，后端配置值沿用现有 device_custom_config 的 FX 图缓存键集成。
发展脉络
- 首次出现viable/strict/1789924990: [inductor] Route compile options through backend registrations (#194998)PyTorch Core
- 当前判断判断：框架层把后端私有配置纳入统一 options 入口，降低自定义硬件后端接入 torch.compile 的胶水成本，方向上有利于加速器厂商以更小改动对接 PyTorch 编译栈。但证据仅覆盖 PyTorch 仓库内部实现，尚不能推断任何厂商采用或生态格局变化。Agent Pulse · 分析
PyTorch 发布 viable/strict/1789924990 版本标签，对应已合并 PR #194998。该改动解决一个具体缺口：Inductor 后端能通过 register_backend_for_device(device_custom_config=...) 注册后端自有的 ConfigModule，但这些值此前无法通过 torch.compile(options=...) 提供。方案是把后端配置值作为 "<device>.<key>" 形式的编译选项寻址，例如 options={"my_device.my_config_key": 1}。核心 Inductor 选项名优先于设备命名空间；后端注册在解析命名空间选项前按需初始化；同一路由被 torch.compile、直接 Inductor 编译、AOTI 和独立编译共用；子进程编译场景下注册的后端配置在父进程捕获、在 worker 中应用；后端配置值复用现有 device_custom_config 的 FX 图缓存键集成。测试覆盖 test/inductor/test_compile_options.py 与 test/inductor/test_config.py。
这是编译选项解析层的命名空间化改造，而非新算子或新后端能力。可验证的下一信号：命名空间选项是否被纳入 FX 图缓存键的稳定序列化，以及子进程 worker 中配置捕获失败时是否报错而非静默回退默认值。
判断：框架层把后端私有配置纳入统一 options 入口，降低自定义硬件后端接入 torch.compile 的胶水成本，方向上有利于加速器厂商以更小改动对接 PyTorch 编译栈。但证据仅覆盖 PyTorch 仓库内部实现，尚不能推断任何厂商采用或生态格局变化。
对自研加速器或自定义 Inductor 后端的团队，价值在于减少为传递后端配置而维护的旁路机制，使编译选项与缓存键走同一条路径，降低配置不一致导致的复现成本。是否真正省工取决于该命名空间约定是否被文档化并保持向后兼容。
可观察的下一信号是后续版本说明或文档中是否正式公开 "<device>.<key>" 选项约定，以及是否有第三方后端在自身仓库中声明 device_custom_config 并给出示例。若长期仅存在于测试文件，则说明该约定仍属内部接口。