[ashhart]

Opt-in pinned staging for DeviceBuffer.download (#2102). With TF_CUDA_PINNED_DOWNLOAD=1, a download copies into one reused pinned buffer per driver and context, then into the caller's slice. Copies over 64 MiB go in 64 MiB pieces. A failed copy hands its buffer to the existing copy_source quarantine. With the switch unset, or any value but exactly 1, the call is main's unchanged line.

This doesn't claim to fix the fault. The issue has no deterministic reproducer, so the host tests prove the path, not the cure. The fake-driver tests cover the destination pointer, reuse, growth, the pieces, one buffer per context and quarantine after a failed copy.

Limits

• With the switch on, if pinned memory can't be allocated the download fails instead of falling back.
• downloadAsync and 27 direct cuMemcpyDtoH_v2 calls in 20 family files don't go through download, so the switch doesn't reach them.
• Not run: any CUDA device check or speed measurement. Whether it could default on for GB10 is a speed question for CUDA on integrated GPUs (GB10): keep prompt states and weights in place instead of copying them through pinned host memory #2043.

The reporter's fork saw 10 misses in 60 runs with pageable memory and 0 in 100 with a pinned bounce; a run on a GB10 with this switch would be the real check.

[ashhart]

Closing this: it duplicates @shuuul's #2103, which was open first and is the better fix. It stages only on integrated devices, so discrete cards keep their direct copies, and it counts the bounce in memory.usage. I should have checked for an open PR before starting this one. #2102 goes forward through #2103.