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

Direct answer

Save Version does not preserve GPU random seed state across independent commits. Each Save Version runs in a fresh background session. The seed is not carried over; it must be set explicitly in notebook code on every run. Hardware revision differences between sessions can affect seed-driven reproducibility, and the read-only dataset cache does not change GPU initialization or seed handling.

Confirmed facts

• Save Version executes the notebook in a new background run to create a permanent snapshot of output and logs. Quick Save does not execute.
• Save & Run All is intended as a clean-slate execution. /kaggle/working is described as a temporary writable directory that persists across versions of the same notebook, while attached datasets are read-only mounts.
• Random seed state is process-local. A new container means a new Python process, new CUDA context, and new RNG state.

Likely explanation, with uncertainty

Identical seed settings can still produce different numerical results across Save Version commits because reproducibility on GPU is not guaranteed by seed alone. Floating-point non-determinism, kernel selection, and driver/CUDA/cuDNN behavior can vary with hardware revision and software stack updates in Kaggle’s shared GPU pool. This is a well-established property of GPU training, not a Kaggle-specific bug.

Dataset cache is unlikely to modify GPU initialization or seed handling. It affects data loading order and timing. If shuffling, worker initialization, or data-dependent randomness is not seeded, cached reads can indirectly change effective randomness between runs.

Assumption: Kaggle does not pin GPU model, driver, and CUDA/cuDNN versions per user across time. If that assumption is wrong, hardware-induced variance would be lower.

Minimal verification for this case

1. Set seed deterministically at top of notebook for all libraries you use, and log the seed value.
2. Enable deterministic behavior where supported, e.g., torch.backends.cudnn.deterministic and torch.backends.cudnn.benchmark controls, or TensorFlow deterministic ops. Note performance impact.
3. Log environment identifiers in each Save Version run, e.g.:

   !nvidia-smi

   and a short print of the framework and device name.
4. Run two separate Save Version commits with unchanged code and compare a stable scalar such as final loss or a hash of final model weights.
5. Control data randomness: fixed worker seed, deterministic sampler, and no non-seeded shuffling.

Missing diagnostic detail that changes recommendation: which deep learning framework and version you are using. Deterministic flags and seed APIs differ between PyTorch, TensorFlow, JAX, and NumPy, so the exact commands to enforce determinism depend on that.