Make the CUDA docs agree with the TensorRT page

The CUDA backend page and the getting started page said several things
that the TensorRT page, and the code, contradict:

- The CUDA page said the Python runtime allocates host memory for an
  unplanned output, so a method that keeps its outputs on the GPU could not
  run from Python. The Python runtime allocates a new device buffer for each
  call.
- It said a planned input fed with GPU memory makes an undefined host
  memcpy and crashes. The runtime refuses that copy and the call fails with
  NotSupported.
- It asked for a CUDA 11.x or later toolkit to run a model. The prebuilt
  packages use CUDA 13 and bring the CUDA runtime with them on Linux, a
  build from source also supports CUDA 12.6, and the toolkit is needed for
  export, where nvcc compiles the kernels. It also gave no minimum GPU,
  while the packages are built for compute capability 8.0 and newer, and it
  asked for Python 3.8+, while the package needs 3.11 to 3.15.
- It listed Windows without saying that programs for Windows are exported
  on Linux. It now links to the C++ guide section that shows how. Its link
  to the getting started page was also broken.
- The getting started page said to use the CPU packages on Windows, while
  CUDA packages are built for Windows too, and it called CUDA 13.4 nightly
  only.

Author: shoumikhin

docs/source/backends/cuda/cuda-overview.md

@@ -7,24 +7,27 @@ The CUDA backend is the ExecuTorch solution for running models on NVIDIA GPUs. I
 - **Optimized GPU Execution**: Uses AOTInductor to generate highly optimized CUDA kernels for model operators
 - **Triton Kernel Support**: Leverages Triton for GEMM (General Matrix Multiply), convolution, and SDPA (Scaled Dot-Product Attention) kernels.
 - **Quantization Support**: INT4 weight quantization with tile-packed format for improved performance and reduced memory footprint
-- **Cross-Platform**: Supports both Linux and Windows platforms
+- **Cross-Platform**: Runs on Linux and Windows. Programs for Windows are exported on Linux.
 - **Multiple Model Support**: Works with various models including LLMs, vision-language models, and audio models
 
 ## Target Requirements
 
 Below are the requirements for running a CUDA-delegated ExecuTorch model:
 
-- **Hardware**: NVIDIA GPU with CUDA compute capability
-- **CUDA Toolkit**: CUDA 11.x or later (CUDA 12.x recommended)
-- **Operating System**: Linux or Windows
+- **Hardware**: NVIDIA GPU with compute capability 8.0 (Ampere) or newer
+- **CUDA**: 13 for the prebuilt packages, which bring the CUDA runtime with them on Linux. A build
+  from source also supports CUDA 12.6.
+- **Operating System**: Linux, or Windows for programs exported on Linux (see
+  [CUDA on Windows](../../using-executorch-cpp.md#cuda-on-windows))
 - **Drivers**: PyTorch-Compatible NVIDIA GPU drivers installed
 
 ## Development Requirements
 
 To develop and export models using the CUDA backend:
 
-- **Python**: Python 3.8+
+- **Python**: Python 3.11 to 3.15
 - **PyTorch**: PyTorch with CUDA support
+- **CUDA Toolkit**: export compiles kernels with `nvcc`, the CUDA compiler, so it needs a CUDA toolkit
 - **ExecuTorch**: Install ExecuTorch with CUDA backend support
 
 ## Using the CUDA Backend
@@ -83,7 +86,7 @@ For a complete working example, see the [CUDA export script](https://github.com/
 
 ## Runtime Integration
 
-To run the model on device, use the standard ExecuTorch runtime APIs. See [Running on Device](getting-started.md#running-on-device) for more information.
+To run the model on device, use the standard ExecuTorch runtime APIs. See [Running on Device](../../getting-started.md#running-on-device) for more information.
 
 When building from source, pass `-DEXECUTORCH_BUILD_CUDA=ON` when configuring the CMake build to compile the CUDA backend.
 
@@ -142,8 +145,8 @@ exec_program = et_program.to_executorch(
         enable_non_cpu_memory_planning=True,
         # Required alongside the skips. Memory planning reserves a buffer for graph inputs by
         # default, and the runtime fills a planned input by copying the caller's memory into that
-        # buffer, which reintroduces the copy you just asked to skip. On device memory that copy is
-        # a host memcpy into a device pointer, which is undefined.
+        # buffer, which reintroduces the copy you just asked to skip. For a device tensor the
+        # runtime refuses that copy, so the call fails.
         # Outputs stay planned, so the runtime allocates them on the device and hands back a
         # pointer to its own buffer. See the note below for when to unplan them instead.
         memory_planning_pass=MemoryPlanningPass(alloc_graph_input=False),
@@ -171,23 +174,22 @@ during device-aware memory planning.
 
 **Inputs must be unplanned**, via `MemoryPlanningPass(alloc_graph_input=False)`. Without it the
 program reserves its own input buffer and the runtime copies the caller's memory into it, so the
-copy comes back at run time. On device memory that copy is a host memcpy into a device pointer,
-which is undefined, so the program crashes rather than returning a wrong answer.
+copy comes back at run time. For a device tensor the runtime refuses that copy, so the call fails
+with error `0x10` (`NotSupported`) and the log says `Error copying tensor data at input 0`.
 
-**Outputs have two valid shapes, and which one you want depends on the language.**
+**Outputs have two valid shapes.**
 
-Leave outputs planned, which is the default, when the caller cannot supply device memory itself.
-The planned buffer is allocated on the device because `enable_non_cpu_memory_planning` is on, and
-`skip_d2h_for_method_outputs` means nothing copies it back, so the result stays on the device and
-the caller receives a pointer to the runtime's own buffer. That buffer belongs to the method and is
-reused by the next execution, so read or copy the result before running again. This is the shape
-every Python caller wants, and it is what the exporters in this repository use, for example
+Leave outputs planned, which is the default, in most cases. The planned buffer is allocated on the
+device because `enable_non_cpu_memory_planning` is on, and `skip_d2h_for_method_outputs` means
+nothing copies it back, so the result stays on the device. That buffer belongs to the method and is
+reused by the next execution. A C++ caller gets a pointer to it, so read or copy the result before
+running again. From Python, `execute()` returns a copy on the GPU unless you pass
+`clone_outputs=False`. This is what the exporters in this repository use, for example
 `examples/models/gemma4_31b/export.py`.
 
-Set `alloc_graph_output=False` only when the caller supplies the output memory itself, which today
-means a C++ caller handing the runtime a device tensor through `Module::set_output`. The Python
-bindings allocate host memory for an unplanned output, so a device resident method exported this
-way cannot run from Python.
+Set `alloc_graph_output=False` when the caller should own the output memory instead. A C++ caller
+hands the runtime a device tensor through `Module::set_output`. The Python runtime allocates a new
+device buffer for each call and returns it without a copy.
 
 **Per-method selection is on the outer config, not on the flags.** Pass a dict of
 `PropagateDeviceConfig` keyed by method name:

docs/source/getting-started.md

@@ -37,8 +37,10 @@ pip install executorch torch \
 | NVIDIA GPU, CUDA 13.2 | `cu132` |
 | NVIDIA GPU, CUDA 13.4 | `cu134` |
 
-The CUDA packages are built for Linux, on x86_64 and ARM64. Use the `cpu`
-variant on macOS and on Windows. If your CUDA version is not in the table,
+The CUDA packages are built for Linux, on x86_64 and ARM64, and for Windows on
+x86_64. On Windows they run CUDA programs, but programs for the CUDA backend are
+exported on Linux (see [CUDA on Windows](using-executorch-cpp.md#cuda-on-windows)).
+Use the `cpu` variant on macOS. If your CUDA version is not in the table,
 choose the closest lower one with the same major version, because CUDA works
 across minor versions but not across major ones. There is no package for CUDA 12,
 so on CUDA 12 use the `cpu` variant or build from source. On CUDA 13.0 or 13.1 no
@@ -54,8 +56,7 @@ To get a change that has landed on the `main` branch but is not in a release
 yet, use a nightly build. These are rebuilt every day. Put `nightly/` in front
 of the variant name, for example `nightly/cu132`, and add `--pre` to the
 command, otherwise pip skips development versions. Nightly builds cover the same
-variants. CUDA 13.4 is the newest, and until the next release it is in nightly
-builds only.
+variants.
 
 The second index is needed because a bare `--index-url` replaces PyPI instead of
 adding to it, and some dependencies are published only on PyPI.