CUDA Toolkit 13.0 是该工具包的最新版本，具有加速最新 NVIDIA CPU 和 GPU 计算的优势。作为一项重大发布，它为 CUDA 13.X 软件系列的所有未来开发奠定了基础。您可以立即访问这些新功能。

本文重点介绍了此版本中包含的一些新功能和增强功能：

• 为 CUDA 中基于 tile 的编程奠定基础
• Arm 平台上的开发者体验统一，尤其是 DGX Spark 平台
• 更新的操作系统和平台支持，包括红帽企业 Linux 10
• NVIDIA Nsight 开发者工具更新
• 数学库线性代数和 FFT 更新
• NVCC 编译器更新，包括改进的 fatbin 压缩方案，以及对 GCC 15 和 Clang 20 的支持
• 加速 Python cuda.core 版本和开发者友好型软件包
• 功能齐全的架构
• 更新向量类型，支持 32 字节对齐，以提高 Blackwell 的性能
• Jetson Thor 支持服务

支持 CUDA 13.0 的 Blackwell GPU

Blackwell 架构在 CUDA Toolkit 12.8 中首次得到支持，其性能和功能不断提升。CUDA 13.0 支持最新的 Blackwell GPU，包括：

• B200 和 GB200 GPU 服务器
• B300 和 GB300 GPU 服务器
• RTX PRO Blackwell 系列显卡
• RTX 5000 系列 (GeForce)
• Jetson Thor 模组
• DGX Spark AI 超级计算机系统

CUDA 13.0 的新功能和改进之处

每个新版本的 CUDA 都能提高性能并改善整个堆栈的可编程性。从一开始，CUDA 就采用了一种使用单指令多线程 (SIMT) 的线程并行模型。现在，借助 CUDA 13.0，我们为第二个互补模型奠定了基础：基于 tile 的编程。

在许多高级语言中，Tile（或数组）编程模型已经很常见，Python 就是一个典型的例子。在使用 NumPy 时，您可以将简单、表达能力强的命令应用于整个数组或矩阵，系统会处理低级执行。这种抽象化让您专注于“做什么”，而不是“怎么做”，从而无需管理线程级细节即可设计高性能算法，从而提高生产力。

在 GTC 2025 上，NVIDIA 宣布计划将这种编程模型引入 CUDA。这是开发者生产力和硬件效率向前迈出的重要一步。

在 tile 编程模型中，您定义数据 tile 并指定对这些 tile 的操作。编译器和运行时负责在多个线程之间分配工作并优化硬件使用。这种高级抽象使您无需管理低级线程行为，同时仍然可以充分发挥 GPU 的性能。

至关重要的是，Tile 模型可以自然地映射到 Tensor Core 上。编译器处理块显存管理和操作映射，使当前编写的程序能够利用当前和未来的 Tensor Core 架构。这可确保向前兼容：一次编写，即可在当前和未来的 GPU 上快速运行。

该编程模型将提供两个级别：

• 高级 API 和特定领域语言 (DSL) – 程序员可以直接在 Python、C++ 和其他语言中使用 tile。
• 中间表示 (IR) – 编译器和工具开发者可以针对新的 CUDA Tile IR 后端，从而利用 tile 模型的性能和硬件功能。

CUDA 13.0 作为主要版本，引入了支持该模型所需的低级基础设施更改。虽然大多数更改对最终用户来说是看不见的，但它们为一种新的 GPU 编程方式奠定了基础：这种方式兼具易用性和最高性能，并且具有长期可移植性。

统一的 CUDA for Arm：一次构建，随处部署

借助 CUDA 13.0，NVIDIA 通过统一服务器级和嵌入式设备上的 CUDA 工具包，简化了 Arm 平台的开发。今后，您将不再需要为符合服务器基础系统架构 (SBSA) 的服务器和 Thor 等新一代嵌入式系统维护单独的安装或工具链。相反，单个 CUDA 安装将支持所有 Arm 目标，但 Orin (sm_87) 除外，该目标目前将继续沿用当前路径。

这一变化带来了巨大的生产力提升。现在，您可以一次性构建机器人或 AI 应用，在 DGX Spark 等高性能系统上对其进行仿真，然后直接在 Thor 等嵌入式目标上部署完全相同的二进制文件，而无需更改任何代码。模拟和部署之间的障碍已经消失。

传统方式：两个世界，两个工具链

此前，为 Arm 服务器和 NVIDIA 嵌入式平台开发意味着要同时处理多个并行生态系统。针对 SBSA 平台（如基于 Grace 的服务器或 Arm 工作站）的开发者使用标准 aarch64 CUDA 工具套件。它自带系统根目录、库、容器镜像等。

与此同时，Jetson 等嵌入式平台的开发依赖于 JetPack 和 L4T 软件堆栈，其中还包括其自己的定制 CUDA 组件、标头布局和板级支持包，并且通常需要从 x86 或 Grace 系统进行交叉编译。许多团队不得不维护单独的构建脚本、持续集成 (CI) 作业和容器注册表，而这些往往只是为了支持相同的应用逻辑。将项目从开发阶段转移到仿真和部署阶段需要重复工作、自定义粘合代码，而且版本和配置之间难免会出现不匹配。

新方式：一个工具包，所有目标

CUDA 13.0 是一次转折点。借助统一的工具包，开发者可以从单个 CUDA 安装中定位 SBSA 服务器和未来的嵌入式平台。现在，相同的编译器、头文件和库可广泛应用，而切换目标只是针对正确的计算架构（例如 sm_XX）进行构建的问题，无需更换 SDK。

这也延伸到了容器。NVIDIA 正在整合其图像生态系统，以便仿真、测试和部署工作流能够依赖于共享容器谱系。这意味着更少的重建、更少的 CI 开销，以及从代码到硬件的更平滑的路径。

重要的是，所有这些功能都不会牺牲性能或灵活性。编译器和运行时仍然会为目标 GPU 架构生成优化代码；您只需管理两个工具链即可实现这一目标。

为什么这一点很重要

对于开发者而言，这种统一性极大地提高了生产力。它减少了 CI 流程中的重复，简化了容器管理，并消除了因使用不同 SDK 而导致的细微错误和不一致性。团队现在可以专注于他们所关心的内容，即算法、性能和部署，而不是工具链连接。

对于企业而言，其价值甚至更广泛。在仿真和边缘平台上，单一事实来源意味着减少了在基础设施上花费的工程时间，从而可以更多地专注于创新。这款新模型的内置可移植性可使应用程序在不断发展的 GPU 世代和平台中经久不衰。

操作系统和平台支持

CUDA Toolkit 13.0 已针对以下新操作系统进行认证和测试。请注意，这不是完整的支持矩阵。请参阅发行说明或 Windows 或 Linux 版 CUDA 安装指南，了解完整列表。

• 红帽企业 Linux 10.0 和 9.6
• Debian 12.10（测试版）
• Fedora 42（Fedora 42）
• Rocky Linux 10.0 和 9.6

开发者工具

NVIDIA Nsight Compute 2025.3 在源视图中添加了指令混合和记分板依赖关系表。这使用户能够准确地确定受长期依赖性停滞影响的源代码行，并更高效地识别输入和输出依赖性位置。这些表格还细分了源代码行中的指令类型（浮点、整数、数据移动等）提供有关依赖项卡死根本原因的更多详细信息。

此外，指标详情窗口中新增了“吞吐量细分”部分，用于显示各个单位的吞吐量指标。这些单元中的任何一个都可能成为吞吐量的限制因素，因此此窗口可帮助用户了解每个单元的性能。

数学库

我们为 CUDA Toolkit 数学库添加了以下新功能：

• cuBLAS：在 NVIDIA Blackwell GPU 上，提高了 BLAS L3 (非 GEMM) 内核 (SYRK、HERK、TRMM 和 SYMM) 的性能 (FP32 和 CF32 精度)
• cuSPARSE：现在支持 SpGEMM 计算中的 64 位索引矩阵
• cuSOLVER：一种新的数学模式，利用了 Blackwell GPU 上模拟 FP32 算术的性能提升。使用新 API 控制此功能：cusolverDnSetMathMode、cusolverDnGetMathMode()、cusolverDnSetEmulationStrategy 和 cusolverDnGetEmulationStrategy。此外，由于内部算法切换，cusolverDnXsyevBatched 现在可为 Blackwell GPU 上的 n<=32 矩阵提供性能提升。您可以使用 cusolverDnSetAdvOptions 将所有问题大小恢复为旧算法。有关更多详细信息，请参阅 cusolverDnXsyevBatched 文档。
• cuFFT：提高了单精度 C2C 多维 FFT 和某些大型 2 的幂 FFT 的性能

NVCC 更新信息

新的编译器更新包括：

• CUDA Toolkit 13.0 版本引入了对 GCC 15 和 Clang 20 的支持，作为主机端编译器，并取消了对 ICC 和 MSVC 2017 的支持。
• NVIDIA CUDA 编译器驱动 (NVCC) 的两项重大更改将影响 __global__ functions 和设备变量的 ELF 可见性和链接。更多详情请参阅此详细技术博客。
• 在 13.0 中，我们为 NVIDIA CUDA 编译器驱动程序 (NVCC) 和 NVIDIA 并行线程执行 ISA 引入了一项新的语言功能，以增强单独编译。这些更改使程序员能够在单独编译的任何 __device__ 函数上指定高性能的自定义 ABI（应用程序二进制接口）。

CUDA 13.0 提高了 ZStandard (ZStd) 的默认压缩率

CUDA Toolkit 13.0 将 fatbin 的默认压缩方案更改为依赖于 Zstandard，这是一种先进的压缩算法，与基于 LZ4 的旧压缩方案相比，可实现更好的压缩率。Fatbin（也称为 NVIDIA 设备代码 Fat 二进制文件）是用于存储不同架构的多个版本代码的容器。在 NVIDIA，我们使用它们来捆绑适用于多个架构（例如 sm_89 和 sm_100）的 GPU 代码，通过确保为我们针对的每个架构提供优化的代码版本，从而最大限度地提高兼容性和运行时性能。

每次使用 CUDA（无论是通过 NVCC 还是我们的 HPC 编译器 NVC++）创建可执行文件时，设备代码都会打包到 fatbin 中。由于我们有多个相同代码的副本，因此我们在编译时压缩每个副本，并在运行时只解压缩相关条目，从而节省二进制文件的大小。

我们认识到二进制文件大小是一个重要问题。在 CUDA Toolkit 12.8 中，我们为 NVCC 引入了 --compress-mode 选项（以及 fatbinary 和 nvFatbin 中的类似选项），允许您选择各种压缩模式来帮助解决这个问题。但是，由于其开发时间，我们无法保证所有选项都能在与 CUDA 12.X 工具套件兼容的所有驱动版本中正常运行。

在 13.0 版本中，我们现在可以保证这些选项与所有与 13.X 工具包兼容的驱动程序兼容。更重要的是，这使我们有机会切换默认压缩模式，以匹配依赖于 Zstandard 的 balance 压缩模式。这提高了压缩率，同时执行时间几乎没有减慢。

在某些库中，我们注意到使用 ZSTD 和 LZ4 几乎没有区别，即使使用大小压缩也是如此。我们认为，这些库主要由不受此问题影响的数据（例如主机代码）组成。在其他情况下，我们看到尺寸有了更显著的缩小。例如，借助 CUDA Math API，我们通过新的默认值减少了 17% 的大小。如果尝试使用同样使用 ZSTD 的 size compress-mode，则可以实现更显著的改进，例如 CUDA Math API 的大小可缩小 71%。

在库级别，我们没有看到整体尺寸的退化，同样，在测试中，我们也没有看到执行时间出现显著的几何平均值退化。

我们知道，在某些应用中，解压缩时间仍然是一个关键问题。对于这些情况，我们仍然保留 --compress-mode 的 speed 选项。它基于 LZ4 维护 13.0 之前的压缩方案，该方案以解压缩时间优先于压缩比为目标。此外，我们知道压缩率对于某些人来说还可以进一步提高。对于您，我们仍然保留 --compress-mode 的 size 选项，该选项使用基于 Zstandard 的更具侵略性的压缩方案。如果您不想使用任何压缩，我们继续提供 --compress-mode=none 和 --no-compress。

这些默认设置的更改会反映在 NVCC、NVC++、fatbinary 和 nvFatbin 等中。要开始使用这些改进，请立即开始使用 CUDA Toolkit 13.0。

加速 Python

CUDA Python 核心对象模型的早期版本发布

cuda.core 是 cuda-python 项目的一个组件，可通过 Python 访问 NVIDIA 的 CUDA 平台。它专门为核心 CUDA 功能提供直观的 Python API，包括运行时控制、编译器和链接器功能。这使得 Python 开发者无需编写大量 CUDA C++ 代码即可利用 GPU 加速的性能优势。

cuda.core 的主要方面：

• Pythonic API：旨在为 CUDA 的核心功能提供用户友好且符合 Python 语法的接口。
• 核心 CUDA 功能：它提供从 Python 中访问基本 CUDA 运行时和开发工具的功能。
• 互操作性：它旨在与 CUDA 生态系统中的其他 Python GPU 库和框架（例如 Numba 和 CuPy）无缝协作。

Wheel 软件包更改为 CUDA 13.0

最近，我们确定了 CUDA Toolkit wheels 软件包的消耗方面需要改进的地方。其中包括轮子如何在文件目录结构中解压缩 Toolkit 组件，丢失新 CUDA 版本的轮子标签，以及仅安装 Toolkit 部分内容的新元软件包。

Wheels 是唯一一个将 CUDA 工具套件的每个组件都放在单独文件夹中的平台，例如，cuBLAS 的文件夹名为 site-packages/nvidia/cublas，CCCL 的文件夹名为 site-packages/nvidia/cuda_cccl。这使得链接和发布许多 CUDA Toolkit 依赖项变得困难，因为在创建依赖 CUDA Toolkit 依赖项的 Python 软件包时，必须单独搜索每个组件。从 CUDA Toolkit 13.0 wheels 开始，我们将把所有 CUDA Toolkit 构件都放在同一个文件夹中，以便使 CUDA Toolkit wheels 文件布局更接近其他平台上的文件布局。例如，site-packages/nvidia/cu13/include 将包含 cuBLAS 和 cuFFT（如果已安装）的标头。

版本化的 CUDA Toolkit 子目录（我们在其他平台上使用）也使我们能够更轻松地确保 CUDA Toolkit 版本之间的组件不匹配。NVIDIA 的一些非 CUDA 工具包依赖于 CUDA 工具包，它们也将开始使用新的软件包布局，以提高用户便利性。

为了确保用户能够下载带有工具包组件的正确 CUDA 版本，我们在安装 cccl 的软件包名称 nvidia-cuda-cccl-cu12 上标记了文件，例如“cu12”。今后，CTK 软件包名称将不再带有 CUDA 标签后缀，即。cccl 软件包的名称将为 nvidia-cuda-cccl。这将允许上游库使用该软件包的版本来选择 CUDA 版本。非 CTK 软件包将继续使用文件后缀，以便为多个 CUDA 版本构建。

新的 cuda-toolkit 元软件包可用于安装特定版本的 CUDA 工具包的全部或部分内容。例如，pip install cuda-toolkit[cublas,cudart] == 13.0 将安装 13.0 CUDA 工具套件版本的 nvidia-cublas 和 nvidia-cuda-runtime。 pip install cuda-toolkit[all] 将安装 CUDA 工具套件的所有组件。我们还发布了适用于之前 CUDA 版本的 cuda-toolkit 元软件包版本，以便于迁移到元软件包。

CUDA Core 计算库 (CCCL)

CUDA Toolkit 13.0 包括 CUDA Core Compute Library (CCCL) 3.0 版本。CCCL 是之前独立的 Thrust、CUB 和 libcudacxx 库的统一。它提供简化 CUDA 编程的现代抽象。

此版本的主要变化：

CCCL 头文件在 CUDA 13.0 中已移动位置

从 13.0 开始，CUDA 工具包安装程序中捆绑的 CCCL 头文件已移至 ${CTK_ROOT}/include/cccl/ 下的新顶级目录中。

因此，您可能会看到关于缺少 <thrust/device_vector.h> 或 <cub/cub.cuh> 等标题的错误。为了确保平稳过渡：

• ❌ 请勿写入 #include <cccl/...>，否则会破坏。
• 如果只在使用 nvcc 编译的文件中包含 CCCL 头文件 ✅ 无需采取任何措施。（这是大多数用户的常见情况） 如果在仅使用主机编译器（例如 GCC、Clang、MSVC）编译的文件中使用 CCCL 头文件： 使用 CMake 和 CCCL::CCCL 进行链接 ✅ 无需采取任何措施。（这是推荐的路径。查看示例) 其他构建系统 ⚠️ 将 ${CTK_ROOT}/include/cccl 添加到编译器的 include 搜索路径中（例如，使用 -I）

这些更改可防止在混合使用 CUDA 工具包捆绑的 CCCL 头文件和外部软件包管理器提供的 CCCL 头文件时出现问题。如需了解更多详情，请参阅 CCCL 2.x 到 3.0 迁移指南。

重大更改

CCCL 3.0 包含一些重大更改，但大多数更改都是清理内部细节或删除现在有更高级替代功能的特性。对大多数用户的影响应该很小。请参阅我们的迁移指南，如果您遇到问题，请随时在 GitHub 上联系我们。

更新后的要求

• CCCL 3.0 现在需要 C++17 或更高版本
• 支持的主机编译器：GCC 7+、Clang 14+、MSVC 2019+

Jetson

CUDA 13 引入了对 Jetson 开源 GPU 驱动程序的支持，我们从 Thor SoC 开始，从传统的移动 RM 迁移到开源 GPU 驱动程序。这一统一将使 Jetson 和 IGX 平台能够在未来同时使用集成 GPU (iGPU) 和独立 GPU (dGPU) ，从而提供无缝、高效的计算体验。

从 CUDA 13.0 开始，基于 Thor 的 Jetson 平台将支持统一虚拟内存 (UVM) 和完全一致性。这还使设备能够通过主机的页面表访问可分页的主机内存。GPU 对此 CPU 缓存内存的访问也在 GPU 上进行缓存，并由硬件互连来管理完全一致性。这意味着通过 mmap () 或 malloc () 分配的系统内存可以直接在 GPU 上使用。

CUDA 13.0 为 Jetson 引入了绿色上下文。绿色上下文是轻量级上下文，通过预先分配 GPU 资源给上下文来提高确定性。此功能提供一定程度的资源隔离，使每个上下文都能在不受其他上下文干扰的情况下运行。

CUDA 13 还为 Jetson 开发者工具带来了增强功能，包括对 NVML 和 nv-smi 等库的支持。这些工具可为开发者提供更好的洞察力和对 GPU 资源的控制，从而实现更高效、更有效的开发。

所有这些功能以及更多功能将在 JetPack 7.0 版本中提供。敬请关注即将发布的“JetPack 7 上的 CUDA”博客文章，以了解详情。

功能齐全的架构

Turing 之前的 GPU 架构（计算能力 7.5）被视为功能齐全，因此，我们在 CUDA 13.0 中取消了对计算能力 7.5 之前的 GPU 的离线编译支持。此外，NVIDIA 驱动程序的 R580 分支将是支持这些架构的最后一个驱动程序分支。

这意味着，希望支持 7.5 之前的架构的应用开发者需要使用 CUDA 12.9 或更早版本来构建应用，而这些应用的用户需要使用 580 驱动分支。所有之前发布的 CUDA 工具套件均可在我们的 CUDA 下载存档页面上获取。请注意，580 分支是长期支持分支，将维护和支持三年。我们将在博客文章中更详细地讨论这些更改。

更新的向量类型

double4、 long4、 ulong4、 longlong4 和 ulonglong4 是最初以 16 字节对齐方式引入的向量数据类型。Blackwell 架构引入了对 256 位加载/存储的新支持。对这些类型使用 32 字节对齐可以为内存受限的应用提供性能提升。

为了便于无缝使用这些具有 32 字节对齐界限的向量类型，我们添加了其他向量类型，这些类型明确指定了对齐方式。如果您希望使用这些向量类型并对齐 32 字节，请将 double4 替换为 double4_32a 等。如果您希望继续使用这些 16 字节对齐的向量类型，请将 double4 替换为 double4_16a 等。

从 CUDA 13.0 开始，使用向量类型 double4、long4、ulong4、longlong4 和 ulonglong4 将会显示弃用警告，鼓励您根据对齐要求使用 _16a 或 _32a 变体替换这些类型。

cudaDeviceProp 的更改

CUDA 13.0 对 cudaDeviceProperties 结构的成员进行了更改。开发者通常会使用此结构来查询 GPU 的功能，然后做出运行时决策。下表列出了该结构中已删除的成员，以及应替换为的 API 或字段（如果存在）。如需了解更多信息，请参阅 CUDA Runtime API 中的版本说明和 cudaDeviceProp 信息。

总结

作为一项重大发布，CUDA Toolkit 13.0 为新的基于 tile 的编程模型奠定了基础，该模型将提高程序员在最新（和未来）硬件上的生产力和性能。CUDA 13.0 继续为最新的 NVIDIA GPU 提供增强的支持，包括加速库、编译器和开发者工具。

想要了解更多信息？查看 CUDA 文档、浏览最新的 NVIDIA 深度学习培训中心 (DLI) 产品，并访问 NGC 目录。在 CUDA 开发者论坛中提问并加入对话。

致谢

感谢以下 NVIDIA 贡献者：Andy Terrel、Jake Hemstad、Becca Zandstein、Mridula Prakash、Jackson Marusarz、Emma Smith 和 Rekha Mukund。