[misc] say why the collective entry was dropped, not just that it was

The replaced set's _c10d_functional::reduce_scatter_tensor is correct where it
came from: torchtitan runs Megatron-style sequence parallelism, which
reduce-scatters inside the forward, and compiles, which is what puts collectives
in the _c10d_functional namespace. FastVideo redistributes with Ulysses
all-to-all and cannot compile the training path, so neither condition holds.

Verified against FSDP2 with the trainer's wrapping order: re-adding both
collective names leaves every op's MUST_SAVE/PREFER_RECOMPUTE decision unchanged
and the loss bitwise identical, so the removal is a no-op.

Author: shaoxiongduan

fastvideo/train/utils/activation_checkpoint.py

@@ -53,11 +53,14 @@ class CheckpointType(str, Enum):
     "fastvideo_kernel::block_sparse_attn_triton",
 }
 
-# The replaced set also named _c10d_functional::reduce_scatter_tensor, which
-# never fires: under FSDP2 the reduce-scatter runs in the post-backward hook,
-# outside the region. What does appear inside it is the parameter all-gather
-# (c10d::_allgather_base_), and retaining that would hold every checkpointed
-# block's unsharded weights at once, so it is deliberately not listed.
+# No collective is listed. The replaced set named
+# _c10d_functional::reduce_scatter_tensor, which is correct in torchtitan, where
+# Megatron-style sequence parallelism reduce-scatters inside the forward. Ulysses
+# redistributes with all-to-all instead, so FastVideo has no forward
+# reduce-scatter to retain; FSDP2's runs in the post-backward hook, outside the
+# region. The one collective that does appear inside a block is the parameter
+# all-gather, and retaining that would keep every checkpointed block's unsharded
+# weights resident at once, which is what FSDP exists to avoid.
 
 # VMoBA and the FA3 training path go through torch.autograd.Function rather than
 # the dispatcher, so no policy can reach them; they get full recomputation.