A PyTorch change can make a Mac video workload use dramatically less driver memory without making its live tensors much smaller. That is the useful detail behind the MPS improvements in PyTorch 2.15, released on October 28: one reported Wan2.2 decode fell from roughly 270 GiB of total driver memory to 8 GiB after constant padding moved from MPSGraph to Metal kernels.
The result concerns a particular tiled VAE decode, not the memory requirement for every stage of video generation. Its value is diagnostic. Looking only at tensor allocations would have hidden most of the difference, which matters when deciding whether a workload needs more hardware or a different implementation.
The allocator barely changed
Contributor Irakli Salia’s upstream pull request identifies repeated padding before three-dimensional convolutions in Wan-AI/Wan2.2-TI2V-5B-Diffusers. A full decode across 28 tiles makes 8,764 padding calls. The replacement supplies Metal kernels for dense and strided layouts instead of using the previous MPSGraph constant-padding path.
| Reported peak | MPSGraph padding | Metal padding |
|---|---|---|
| Current tensor allocations | 4.422 GiB | 4.095 GiB |
| Allocator-reserved memory | 8.070 GiB | 8.070 GiB |
| Total driver memory | 270.135 GiB | 8.108 GiB |
These are the contributor’s measurements, not SekaiTech benchmarks. The unchanged reserved-memory peak is more revealing than the headline reduction: the large extra allocation occurred outside the allocator’s reserved pool. This was not primarily a case of shrinking model weights or reducing the size of tensors the application kept alive.
That difference also limits the purchasing conclusion. The 8.108 GiB figure describes the reported decode’s driver-memory peak. It does not establish that an 8 GB Mac can run the complete pipeline, with its other stages and operating-system demands. Nor does the comparison prove an identical saving for a different resolution, model or application.
Two Python counters answer different questions
PyTorch’s API documentation explains why a tensor counter can miss this kind of pressure. torch.mps.current_allocated_memory() returns GPU memory occupied by tensors, excluding cached allocations in the MPS allocator’s pools. It is useful for tracking the live tensor footprint, but it is not a total for everything the process has asked the GPU driver to allocate.
torch.mps.driver_allocated_memory() has the broader scope. It includes cached allocations in allocator pools and allocations from the MPS and MPSGraph frameworks. A large gap between these readings therefore deserves investigation beyond the tensors still referenced by Python. The gap alone does not identify a leak; it tells the developer that the two measurements cover different allocations.
For someone comparing an older environment with 2.15, the informative comparison is the same decode stage under the same workload, with both counters recorded. A lower tensor reading cannot stand in for a lower driver reading. This is similar to the logical-versus-physical distinction in Hugging Face’s shared model cache: the number must match the resource question being asked, although the underlying mechanisms differ.
The padding fix is one part of a broader release. PyTorch’s official announcement also confirms FP8 support on Apple silicon, a grouped matrix-multiplication decode path and public MPS stream APIs. Those changes address storage, execution and work scheduling respectively. They should not be combined into one blanket performance multiplier for a Mac application.
Hugging Face’s MPS engineering post, first published on October 20, provides the detailed padding example and explicitly separates upcoming 2.16 work from 2.15. Its release-candidate installation wording predates the October 28 final announcement. SekaiTech reviewed those documents and the upstream change without running the workload. The reported memory split gives developers a concrete reason to examine driver allocations before treating a video-decoding failure as proof that the model’s tensors cannot fit.
Sources
- PyTorch Foundation: October 28 PyTorch 2.15 release announcement
- Hugging Face PyTorch team: MPS implementation changes and video-memory comparison
- PyTorch upstream change: constant-padding kernels and reported Wan2.2 measurements
- PyTorch 2.15 API: current tensor allocations
- PyTorch 2.15 API: total Metal driver allocations