Thanks for pointing this out — it is a good thing to notice. One important engineering habit, though: a deprecation warning does not automatically mean “the docs are wrong” or “this must be fixed immediately.”
With fast-moving tools like PyTorch, documentation and real codebases often stay a little conservative on purpose. A newer API may be recommended, but the older API can remain stable for a long time. Chasing every warning the moment it appears can make learning material and production code less stable, not more stable.
A useful way to classify deprecation warnings is:
- Advisory deprecation: “there is a newer recommended path.” This is usually a signal for the developer to understand and handle when appropriate.
- Removal-path deprecation: “this will be removed or hard-fail in a coming version.” This needs planned migration before the breaking point.
Those two cases should not be treated the same.
In practice, coding rarely works exactly like the docs anyway. You learn by running into edge cases, reading warnings, deciding whether they matter now, and adapting. That practical judgment is part of the skill. So for this one, do not read the warning as an automatic bug report against the site. Read it as a useful signal to classify: is this merely a recommended newer API, or is it a real upcoming breakage we need to plan around?
Deprecation warnings are triggered by torch.cuda.amp.autocast and torch.cuda.amp.GradScaler. PyTorch now recommends using the unified torch.amp API.