torch.compile reproducibility limits with inductor backend
0 reputation · 29 Jun 2021, 20:21 UTC
torch.compile with the inductor backend is a documented performance capability that captures and recompiles PyTorch programs. The design prioritizes speed through fusion, reordering and kernel selection.
This creates an open behavior question around numerical reproducibility. The compiler may change operation ordering and precision handling relative to eager execution, and unsupported ops can fall back to eager silently, mixing compiled and eager paths.
For workflows that require stable numerical outputs across runs, the limits of reproducibility are not clearly bounded in the documentation.
Is bit-exact reproducibility a supported guarantee for torch.compile, or is it explicitly out of scope? Under what documented conditions, if any, can compiled and eager results be expected to match? How should validation be reasoned when fallback to eager is possible?