Kaggle Notebook 'Save Version' GPU Random Seed Determinism Across Hardware Revisions

Kaggle Notebooks provide a 'Save Version' feature that executes the entire script in a background session to create a permanent snapshot of output and logs. The environment offers a temporary writable directory (/kaggle/working) that persists across different versions of the same notebook, and external datasets can be attached as read-only mounts that are cached on the backend to optimize loading times across user sessions. A 'Quick Save' captures the current editor state without executing code, whereas 'Save & Run All' ensures a clean-slate execution environment.

When using GPU accelerators for stochastic models, a fixed random seed is typically expected to yield reproducible results across runs. However, the shared pool's hardware revisions between separate 'Save Version' commits may introduce non-deterministic variations that are not explicitly controlled by the seed setting, affecting reproducibility for research workflows that depend on consistent stochastic behavior.

Does the 'Save Version' mechanism preserve GPU random seed state across independent commits? Does hardware revision differences between sessions affect seed-driven reproducibility? Can the read-only dataset cache interact with in-notebook GPU initialization in ways that seed settings do not fully account for?