viable/strict/1790170099: Dispatch `index_put_` to `index_fill_.Scalar` when possible (#195787)
PyTorch 发布 viable/strict/1790170099 变更（#195787），作为 #188330 的后续：在可能时把 index_put_ 分派到 index_fill_.Scalar，例如 gpu_tensor[indices] = 1.0，而不是先把标量转成张量再走 index_put_。作者称相比 #188330 当前代码已不做 GPU/CPU 同步，但仍希望去掉不必要的张量创建，并在 A100 上用 torch.utils.benchmark 的 Compare/Timer 做了基准测试。
Development
- First Reportviable/strict/1790170099: Dispatch `index_put_` to `index_fill_.Scalar` when possible (#195787)PyTorch Core
- Current Assessment这类改动属于框架内部的微优化，不改变对外 API 语义，但会累积影响训练与推理的单位任务开销。判断：在算子级优化空间收窄后，主流框架的竞争更多体现在调度与内存分配等细节上。可验证下一信号：后续 PyTorch release note 是否把该分派变更列为性能项，以及是否有其他算子出现同类标量特化分派。Agent Pulse · analysis
PyTorch 核心仓库出现一项调度层优化（#195787），目标是在可行场景下把 index_put_ 分派到 index_fill_.Scalar，典型例子是 gpu_tensor[indices] = 1.0 这类标量赋值。作者说明这是 #188330 的后续工作：当前代码已避免 GPU/CPU 同步，但标量先转张量再走 index_put_ 仍带来多余张量创建，因此希望直接走 index_fill_.Scalar 路径。证据中给出的验证方式是在 A100 上使用 torch.utils.benchmark 的 Compare 与 Timer，覆盖 cuda/cpu、float32、100_000 至 5_000_000 的 tensor_size、1-D 与 2-D 形状以及 0 到 1.0 的 index_ratio。证据未给出具体加速数字或合并结论。
从描述看，这是分派层（dispatch）的路径选择问题：标量赋值语义上等价于填充，走 index_fill_.Scalar 可省去一次标量到张量的构造。判断依据是作者明确说当前代码已无 GPU/CPU 同步，剩余收益主要来自去掉多余张量创建，因此收益量级可能随索引规模与 index_ratio 变化，而非全局性加速。可验证下一信号：该 PR 是否合并，以及基准脚本中 index_ratio 接近 0 与接近 1.0 两端的对比数据是否公开。
这类改动属于框架内部的微优化，不改变对外 API 语义，但会累积影响训练与推理的单位任务开销。判断：在算子级优化空间收窄后，主流框架的竞争更多体现在调度与内存分配等细节上。可验证下一信号：后续 PyTorch release note 是否把该分派变更列为性能项，以及是否有其他算子出现同类标量特化分派。
对使用 PyTorch 的团队而言，此类优化不带来新能力，但可能降低大规模索引赋值场景的算子开销。判断：价值取决于该模式在真实负载中的占比，证据未提供端到端收益。可验证下一信号：在自有模型上对比升级前后含标量索引赋值的 step 耗时。
若该分派路径被采纳，标量索引赋值类操作可能逐步统一到 fill 语义实现。判断依据仅为作者意图与基准脚本，尚无合并或性能结论。可验证下一信号：PR #195787 的合并状态与 A100 基准结果是否随 PR 一并公布。