1. CUDA Samples 13.3：不只是学习示例，更是一份可读的GPU工程手册
我折腾CUDA有些年头了，从上大学那会儿用9800GT跑第一个带宽测试，到现在用H100调内核，每次NVIDIA发布新版CUDA Toolkit，我都会第一时间打开随包附带的Samples目录从头翻一遍。说实话，很多人把CUDA Samples当成“入门小例子”就太把它看轻了。这套代码表面上是教你写kernel，实际上它隐藏了NVIDIA对GPU编程模型的完整理解、对性能边界的最佳实践、对多平台工程化的真实态度。这次拿到CUDA 13.3的Samples包，花了一周多时间做了源码级的梳理，把架构分层、代码组织、工程构建、以及实际开发中能直接借鉴的东西都整理出来，这份评测指南希望能帮你把这套“官方教材”真正用到极致。
适合看这篇文章的人，不止是刚入门想跑通第一个hello_world的新手，也包括已经写了一阵kernel、想看看官方怎么组织大型工程的开发者，甚至做GPU服务器运维、需要给团队搭建CUDA开发环境的朋友。CUDA Samples 13.3能回答的问题比你想的多：怎么安排代码目录才不混乱？怎么在CMake和Makefile之间做选择？怎么用官方示例反推性能瓶颈？13.3这个版本在CUDA 13.x工具链基础上同步更新，覆盖了从CUDA Graph、Tensor Core、NCCL多卡通信到各类优化手段，信息量非常大，值得逐行读一遍。
2. 架构全景：先搞清楚13.3的Samples都在哪、有什么、怎么装
2.1 安装之后的目录结构和关键路径
先解决那个高频搜索词“cuda samples找不到”。Windows系统下，你装完CUDA Toolkit之后，如果选择的是默认安装路径，那么在C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v13.3下面只有开发工具链和库文件，Samples并不在这里。它通常被安装在另一个位置：C:\ProgramData\NVIDIA Corporation\CUDA Samples\v13.3。很多人在C:\Program Files里翻半天找不到，是因为漏掉了ProgramData这个隐藏目录。
Linux下路径相对清爽，CUDA Toolkit装在/usr/local/cuda-13.3，Samples会作为独立文件夹出现，通常是/usr/local/cuda-13.3/samples，同时/usr/local/cuda这个软链接会指向最新版本。老版本CUDA 11.x之前还能在/usr/local/cuda/samples直接看到，新版本在部分发行版的安装体验中已经把samples单独抽了出来，需要额外安装cuda-samples-13-3这个包（Ubuntu/Debian系用apt就能装），CentOS/RHEL用yum或者dnf装对应包名。
装好之后的典型Linux目录结构长这样：
/usr/local/cuda-13.3/samples/ ├── 0_Simple/ ├── 1_Utilities/ ├── 2_Graphics/ ├── 3_Imaging/ ├── 4_Finance/ ├── 5_Simulations/ ├── 6_Advanced/ ├── 7_CUDALibraries/ ├── 8_Android/ ├── 9_Optimization/ ├── 10_Algorithm/ ├── 11_Utilities/ ├── 12_CUDA_Libraries/ ├── 13_LLVM/ # 部分新版本才有 ├── Makefile ├── Makefile.common ├── README.md └── EULA.txt每个数字前缀的目录代表一类主题，编号越大内容越综合。这个编号顺序其实也暗合了学习路径：从最简单的内存操作，到图形互操作、科学计算、库调用、底层调优、再到算法竞赛级的优化。官方虽然没有明说，但从0到9的顺序基本上就是一条从新手到高级工程师的成长曲线。13.3版本沿用了这个编号体系，只是在具体示例数量上做了增删，比如增加了更多Hopper/Blackwell架构相关的Tensor Core示例。
2.2 每个目录的分类逻辑和典型示例
直接列一个分类速查表，方便你按图索骥：
| 目录 | 主题定位 | 典型示例 | 适合开发场景 |
|---|---|---|---|
| 0_Simple | 入门基础，单一概念演示 | simplePrintf、simpleAssert、simpleMultiGPU、simpleCudaGraphs | 新手熟悉CUDA编程模型 |
| 1_Utilities | 硬件信息查询与性能测量 | deviceQuery、bandwidthTest、p2pBandwidthLatencyTest | 环境验证、设备选型 |
| 2_Graphics | 图形API互操作 | simpleGL、simpleD3D11、simpleVulkan | 实时渲染、可视化计算 |
| 3_Imaging | 图像处理与滤波 | bicubicFilter、boxFilter、bilateralFilter | 图像算法加速 |
| 4_Finance | 金融计算模型 | BlackScholes、MonteCarlo、BinomialOptions | 期权定价、风险模拟 |
| 5_Simulations | 物理仿真与粒子系统 | particles、smokeParticles、fluidsD3D9 | 物理引擎、流体模拟 |
| 6_Advanced | 高级特性与底层能力 | threadFenceReduction、concurrentKernels、cdpSimplePrint | 并发调度、内存模型深度掌握 |
| 7_CUDALibraries | 官方库调用示范 | cuFFT、cuBLAS、cuSPARSE、NPP、Thrust | 快速落地工业级计算 |
| 8_Android | 移动端GPU开发 | 各类移动端示例 | Jetson/Android设备 |
| 9_Optimization | 性能优化专题 | transpose、reduction、matrixMul优化版 | 内核调优、访存优化 |
| 10_Algorithm | 经典算法并行实现 | BFS、Dijkstra、MergeSort、Scan | 数据结构与算法加速 |
| 11_Utilities | 辅助工具示例 | cudaCompress、cudaRTC | 运行时编译、压缩工具 |
| 12_CUDA_Libraries | 扩展库生态 | 更多新库用法 | 特定业务模块实现 |
这个分类最有价值的一点是：它不是按“难度”排的，而是按“计算特征”排的。比如4_Finance里的BlackScholes是典型的embarrassingly parallel（高度并行、数据互不依赖）问题，非常适合展示GPU的并行优势；而5_Simulations里的粒子系统则需要处理动态结构和数据竞争，展示的是复杂场景下的工程能力。做实际项目时，你完全可以按图索骥，找到和自己业务特征最像的示例，在此基础上做二次开发，会比从零开始写高效得多。
3. 源码分层：从驱动API到库函数的五层代码结构
3.1 官方示例里隐藏的分层设计
打开任何一个完整的Samples示例，你会发现它的源码组织不是随意的。以6_Advanced/scan为例，目录里包含多个文件：scan_common.h（公共头文件）、scan.cu（主实现）、scan_cuda.cu（CUDA内核）、scan_cpu.cpp（CPU参考实现）、scan_serial.cu（串行版本）、scan_benchmark.cu（性能对比）。这种拆分方式很值得借鉴。
我按自己的理解把13.3版本中的源码分成五层：
第一层是纯工具层，比如1_Utilities/deviceQuery，只通过CUDA Runtime API查询设备属性，不涉及任何性能调优逻辑。它的作用是帮你确认运行环境、验证驱动和工具链是否正确，这一层的代码通常最简单，也是任何开发者在项目开始时应该跑一遍的东西。
第二层是基础算法层，比如0_Simple/simplePrintf、vectorAdd这类，直接通过kernel实现一个具体功能，展示的是一个kernel从启动到结束的完整生命周期。这一层的关键知识点是线程索引计算、内存分配释放、错误检查机制，代码结构普遍是malloc → memcpy → kernel<<<>>> → memcpy → free，看起来平平无奇，但它是所有上层建筑的地基。
第三层是库封装层，对应7_CUDALibraries和12_CUDA_Libraries里的示例，比如cuFFT的示例代码，它会展示如何调用cufftExecC2C这类库函数，而不是自己写FFT的kernel。这一层的重点是理解“什么时候该自己写、什么时候该调库”，NVIDIA提供了大量经过深度优化的库，绝大多数情况下你直接调用比自己实现快得多。
第四层是优化示范层，以9_Optimization/reduction为例，官方直接给出了从串行到并行、再到warp shuffle、最终到多stage的完整优化过程，每一个版本都有注释解释为什么这么改、性能提升了多少。这一层是我认为源码中最具含金量的部分，因为它不只是给你一个正确答案，而是展示了得到答案的过程。
第五层是系统级互操作层，包括2_Graphics里的图形互操作、6_Advanced里的多流多卡协作、CUDA Graph示例等。这一层解决的是GPU在实际系统中如何与其他组件协同工作的问题，比如用cudaGraphicsGLRegisterBuffer让OpenGL和CUDA共享缓冲区，避免不必要的主机-设备拷贝。
3.2 自顶向下读代码的实操方法
这是我个人读Samples源码的一个小技巧，分享出来供参考。不要从第一行开始顺序读，那会陷入细节里出不来。正确的方式是先读每个目录下的README或者main函数入口，了解这个示例解决什么问题、输入输出是什么。然后跳到Makefile或者.sln文件，看看它包含了哪些源码文件，快速建立文件级别的依赖图。第三步才是逐个读关键kernel函数，读的时候带着问题：这个kernel的block尺寸为什么是256？为什么用共享内存不用全局内存？为什么在这里做同步？
举一个具体的例子，0_Simple/simpleCudaGraphs这个示例。第一次读的时候我也觉得不就是把kernel包在一个图里嘛，有什么可看的。但仔细读了之后发现，它演示了从Stream方式到Graph方式的完整迁移路径：先创建普通kernel和依赖关系，再调用cudaGraphAddKernelNode把kernel封装为图节点，接着用cudaGraphInstantiate实例化，最后用cudaGraphLaunch启动。它还演示了如何通过cudaGraphExecUpdate对已实例化的图进行更新，避免了重复实例化的开销。这个示例放在0_Simple目录下，说明NVIDIA认为CUDA Graph已经是一个基础能力，而不是高级技巧。这反过来提醒我：做GPU开发再也不能固守传统的kernel<<<>>>单次启动模式，批量小kernel的场景一定要考虑Graph带来的调度收益。
4. 工程能力：构建系统、Makefile与多平台编译的细节
4.1 官方Makefile逻辑，以及CMake迁移建议
CUDA Samples长期提供两套构建体系：传统的Makefile体系和Windows下的Visual Studio工程体系。新版13.3在Linux/macOS下依然以Makefile为主，但NVIDIA官方文档已经明确推荐新项目迁移到CMake。我实测下来，Samples的Makefile写得非常工程化，值得学习。
Makefile.common是整个构建系统的核心，它定义了所有示例共享的编译规则，包括：
# 常见的Makefile.common关键变量 CUDA_PATH ?= /usr/local/cuda NVCC := $(CUDA_PATH)/bin/nvcc INCLUDES := -I$(CUDA_PATH)/samples/common/inc LDFLAGS := -L$(CUDA_PATH)/lib64 -lcudart -lcuda NVCCFLAGS := -arch=sm_90注意两点：INCLUDES里的common/inc目录包含了很多公共头文件，比如helper_cuda.h和helper_string.h。这两个头文件是Samples里的隐藏武器，helper_cuda.h封装了所有CUDA API调用的错误检查宏，比如checkCudaErrors(cudaMemcpy(...))，一旦出错会打印文件和行号并退出；helper_string.h则提供了命令行参数解析功能。你在自己的项目里可以直接拷贝这两个头文件，它们能极大减少错误检查的样板代码量。
另一个值得注意的细节是，Samples的Makefile对架构参数的处理非常灵活。每个示例的Makefile顶部都有一个默认的NVCCFLAGS，但Makefile.common会用ifeq之类的条件判断根据GPU架构动态追加参数，部分示例会自动检测当前设备并选择对应架构。这种设计在实际项目中反而容易踩坑——如果你把示例拷到自己项目里，没有Makefile.common的自动检测逻辑，可能导致编译出来的二进制无法在目标机器上运行。我建议个人项目直接使用CMake，把架构参数显式配置，比如：
set(CMAKE_CUDA_ARCHITECTURES "89;90")这里的89对应Ada Lovelace架构RTX 4090，90对应Hopper架构H100。CMake从CUDA 11.0开始支持CMAKE_CUDA_ARCHITECTURES变量，比手动拼-gencode参数清爽得多，而且能自动处理PTX和SASS的打包问题。
4.2 Windows和Linux下编译的差异化配置
Windows下编译Samples最简单的方式是打开NVIDIA_CUDA-13.3_Samples.sln，用Visual Studio加载。但实际工程中，我发现VS方案在13.x版本里默认会加载全部示例，编译时间非常久，而且有些示例需要额外依赖比如DirectX SDK或者OpenGL库，如果没有安装对应环境就会编译失败。建议只右键你要的单个项目，选择“生成”，不要整个解决方案一起编译。另外VS 2022的v143工具集与老示例的兼容性偶尔会出问题，如果遇到“无法解析的外部符号”之类的错误，检查一下项目属性里的“CUDA C/C++ → Device → Code Generation”，把compute_86,sm_86之类的参数改成你显卡对应的架构。
Linux下的Makefile就直白得多：
cd /usr/local/cuda-13.3/samples/0_Simple/simplePrintf make ./simplePrintf这里有个小坑，新装好的Samples目录通常属于root用户，直接用普通用户运行make会提示权限不足。我推荐的做法是先把整个Samples目录拷贝到自己的家目录下再编译，不然每次都要sudo改权限，非常麻烦。另外很多教程会让你执行make -j$(nproc)编译所有示例，这一步往往耗时15到20分钟而且可能因为某个图形示例缺少X11库直接报错。稳妥的做法是先跑make -C 0_Simple/simplePrintf这种单目录构建，确认工具链没问题再按需编译。
5. 实战指南：从示例代码到自有GPU项目的迁移路径
5.1 先用deviceQuery和bandwidthTest做环境体检
在动任何复杂代码之前，我强烈建议先编译并运行1_Utilities/deviceQuery和bandwidthTest。这两组工具就是GPU环境的“体检报告”，能一次性暴露驱动、CUDA工具链、权限、硬件识别等绝大多数问题。
deviceQuery输出最重要的三项：设备名称、计算能力（Compute Capability）、显存容量。计算能力直接决定了你可以用哪个CUDA架构参数去编译代码，比如计算能力8.6的设备对应sm_86，计算能力9.0的设备对应sm_90。如果设备查询都失败，那就别折腾后续任何CUDA代码了，先回头查驱动是否装好、nvidia-smi是否正常输出，或者是不是权限不够——有些精简版Linux不会自动创建/dev/nvidia*设备节点，需要手动配置udev规则。
bandwidthTest测的是主机与设备之间的拷贝带宽，以及设备显存的读写带宽。很多人会忽略这个测试，但它其实是衡量GPU实际性能的一个关键指标。如果测出来的带宽远低于理论值，比如RTX 4090的理论显存带宽是1008 GB/s，实测只有400多GB/s，要么是PCIe链路速率降级了，要么是ECC内存开启了，要么是GPU被其他进程占用导致频率偏低。这类问题在做GPU服务器运维时经常遇到，bandwidthTest是快速定位的老工具。
5.2 选择学习路径和迁移路线的建议
拿到Samples套件之后，最常见的困惑是“我该从哪里看起”。我的建议是：如果你的业务目标是通用并行计算，直接按0_Simple → 1_Utilities → 9_Optimization → 6_Advanced这个顺序走；如果你的重点是高性能计算和科学计算，那就重点看7_CUDALibraries和12_CUDA_Libraries，把cuFFT、cuBLAS这些库的调用方式吃透；如果你的方向是AI推理或训练优化，那Tensor Core相关示例、以及矩阵乘法的优化变体才是你的主战场。
从Samples到自己项目，我总结了一套“三步迁移法”。第一步是跑通最小复现——把官方示例完整编译运行一遍，确认所有接口行为符合预期。第二步是替换业务内核——把你自己的算法逻辑填进__global__函数里，保留官方的内存分配、错误检查、性能计时框架。第三步是参数调优——根据你的数据规模调整block尺寸、grid尺寸、共享内存大小，参考官方示例中类似场景的参数选择。这三步走完，你的项目至少已经具备了一个正确的起点，后续优化可以在这个基础上逐步展开。
5.3 常用性能分析工具与Samples的结合使用
NVIDIA官方性能分析工具NVIDIA Nsight系列和Samples配合使用效果很好。跑9_Optimization里的示例时，我习惯用ncu（Nsight Compute）逐个kernel分析，看它的内存吞吐、计算吞吐、occupancy等指标，然后对照源码优化思路验证。比如reduction示例，官方从reduce0到reduce7提供了多个版本，我用ncu --section MemoryWorkloadAnalysis对每个版本做对比，就能清楚看到每次优化到底改进了哪个瓶颈。
如果你的机器上安装了Nsight Systems，可以配合1_Utilities里的bandwidthTest做整机性能画像，看看数据从文件读入到显存再到算完写回的完整链路中，瓶颈到底在CPU读取、PCIe传输、还是GPU计算。这种“整链路分析”的能力，是我认为CUDA Samples作为工程教材最有价值的地方——它不是教你记住某个kernel怎么写，而是教你怎么系统地评估一个GPU系统的性能边界。
6. 常见问题与排查技巧实录
6.1 “cuda samples找不到”的完整排查路线
这个问题搜索量很高，我之前在社区里也回答过很多次。整理下来无非是四种情况：
第一种，安装CUDA时没有勾选Samples组件。Windows下的CUDA安装向导里，“CUDA Samples for Visual Studio”是一个可选组件，默认可能不勾选，或者被安全软件拦截掉了。解决方案是重新运行安装向导，选择“修改”，勾选Samples相关项。
第二种，装了Samples但路径不对。正如前面说的，Windows默认路径是C:\ProgramData\NVIDIA Corporation\CUDA Samples\v13.3，而不是C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v13.3。ProgramData是隐藏目录，需要在资源管理器地址栏手动输入完整路径。
第三种，Linux下没装独立的samples包。新版CUDA Toolkit在部分发行版里把samples拆成了单独包，Ubuntu/Debian系用sudo apt install cuda-samples-13-3，RHEL/CentOS系用sudo yum install cuda-samples-13-3。装完还要确认/usr/local/cuda/samples软链接是否存在，有些版本需要手动创建。
第四种，只想用部分示例但整个包太大。可以去NVIDIA官网的CUDA Samples GitHub仓库单独下载某个示例目录，这个方式最灵活。你去GitHub搜NVIDIA/cuda-samples就能找到官方镜像仓库，v13.3对应标签下能直接获取某个子目录的最新版本。
6.2 编译错误的三类高频问题和处理方式
Samples编译错误场景，我根据经验总结了三大类。
第一类是架构不匹配错误，典型报错是nvcc fatal : Unsupported gpu architecture 'compute_86'。这是因为示例的Makefile默认带了一些-arch参数，而你的显卡架构不在支持列表里。解决办法是覆盖NVCCFLAGS变量，比如：
make NVCCFLAGS="-arch=sm_89" # 用你设备对应架构或者干脆去Makefile里把GENCODE_FLAGS改成自己的架构参数。这类问题在旧显卡跑新版Samples时特别常见，因为新版本默认参数往往已经升级到较新的架构。
第二类是缺少依赖库错误，典型报错是cannot find -lGL或者cannot find -lX11。2_Graphics和部分仿真示例会依赖OpenGL、X11库，服务器最小化安装时默认不装。解决办法是安装对应依赖，Ubuntu下执行：
sudo apt install libgl-dev libx11-dev mesa-common-dev freeglut3-dev如果你根本不需要图形示例，直接跳过2_Graphics目录即可，避免为编译浪费时间。
第三类是动态链接错误，典型表现是编译通过但运行时报error while loading shared libraries: libcudart.so.13: cannot open shared object file。这是因为程序运行时找不到CUDA的lib64目录，需要设置环境变量：
export LD_LIBRARY_PATH=/usr/local/cuda-13.3/lib64:$LD_LIBRARY_PATH建议把这行写到~/.bashrc里，因为不止是Samples，日常开发中编译的CUDA程序也都需要这个环境变量。另外一个常见问题是多个CUDA版本共存时/usr/local/cuda软链接指向了旧版本，导致库版本冲突。排查时执行ls -l /usr/local/cuda，如果指向不对，用sudo rm /usr/local/cuda && sudo ln -s /usr/local/cuda-13.3 /usr/local/cuda重新链接。
6.3 运行时性能异常的几个排查经验分享
在实际用Samples做性能测试时，我遇到过几次比较典型的“性能异常”案例，这里也一并分享一下排查思路。
有一次在一台双路服务器上跑bandwidthTest，结果带宽只有理论值的四成。一开始我以为是驱动问题，重装了好几次都没用。后来用nvidia-smi -q -d CLOCK一看，发现GPU运行在较低的显存频率下，原来这台服务器是机房旧机器，供电模块老化导致GPU无法提升到最高频率。这个案例说明性能问题不一定是软件层面的，硬件供电、散热、PCIe链路完整性都可能成为瓶颈。
另一次是在虚拟化环境中跑Samples，deviceQuery能识别设备但bandwidthTest极慢。排查后发现虚拟机没有开启GPU直通（Passthrough），而是走的半虚拟化共享路径，IO性能严重受损。如果你的GPU环境是虚拟机，务必确认是否启用了GPU直通功能，否则CUDA程序跑起来会非常吃力。
还有一次是simpleMultiGPU示例在四卡机器上跑，发现只有两张卡能正常工作。用nvidia-smi topo -m查看拓扑发现，四张卡分布在不同PCIe Switch下，且没有启用NVLink，卡间通信走的是PCIe。这种拓扑下做多卡通信，性能自然受限。遇到这种情况，要么调整代码减少跨卡通信，要么考虑硬件层面加上NVLink互联。Samples里p2pBandwidthLatencyTest这个示例就是为了测这种场景准备的，跑一遍就大概能清楚卡间P2P通信的上限。
7. 从零到一：用Samples搭建一个最小可用的GPU计算模板
7.1 我的个人GPU项目模板骨架
基于多年对Samples源码的拆解，我沉淀了一套自己的GPU项目最小模板。每次新启动一个CUDA项目，我都会从这个骨架开始填充业务代码，它保证了工程结构清晰、错误处理完整、性能测试方便。
project_root/ ├── CMakeLists.txt ├── src/ │ ├── main.cpp │ ├── kernels/ │ │ └── my_kernel.cu │ └── utils/ │ ├── check_cuda.h │ └── arg_parser.h ├── data/ └── scripts/ └── build.sh其中CMakeLists.txt的核心配置并不复杂，但有几个关键点值得注意。一是必须开启CMAKE_CUDA_ARCHITECTURES，不能让它默认空着；二是需要显式指定CUDA标准版本，set(CMAKE_CUDA_STANDARD 17)；三是建议开启CUDA_FAST_MATH和CUDA_SEPARABLE_COMPILATION选项。
cmake_minimum_required(VERSION 3.20) project(gpu_template LANGUAGES CXX CUDA) set(CMAKE_CUDA_ARCHITECTURES "89" CACHE STRING "GPU architectures") set(CMAKE_CUDA_STANDARD 17) find_package(CUDAToolkit REQUIRED) add_executable(gpu_template src/main.cpp src/kernels/my_kernel.cu ) target_link_libraries(gpu_template PRIVATE CUDA::cudart CUDA::cuda_driver ) target_compile_options(gpu_template PRIVATE $<$<COMPILE_LANGUAGE:CUDA>:--extra-device-vectorization> )check_cuda.h这个头文件我直接改自Samples的helper_cuda.h，保留了checkCudaErrors宏，它会捕获所有CUDA Runtime调用错误并定位到文件和行号。这是我从Samples中收益最大的一个习惯，所有CUDA调用必须做错误检查。你永远不想在一个没检查错误的状态下调试神秘的数据错误，因为大部分时候错误源头就在最早的几个API调用处。
7.2 从模板到业务验证的完整示例
以图像boxFilter为例（3_Imaging/boxFilter的简化版），业务验证流程是这样的。第一步，准备输入图像，读取灰度图，分配主机内存和设备显存，把图拷贝到设备端。第二步，写boxFilter的kernel，用共享内存做Tiling缓存，避免重复读取全局内存。第三步，做单元验证，先用CPU实现一个朴素版本，对比输出图像每个像素的差异，确保GPU版本逻辑正确。第四步，把CPU和GPU版本的耗时用cudaEvent计时，打印性能对比结果。
这个流程的核心是第3步的验证。Samples源码中几乎每个示例都有*.cpp文件实现一个CPU参考版本，用意非常清楚：没有基准答案之前，任何性能优化都是盲目的。很多新手一上来就把算法搬到GPU上然后直接看速度，结果算错了都不知道。先做CPU版本、再对比正确性、最后才看性能，这是最稳妥的路径。
7.3 如何在Jetson系列嵌入式平台上复用这些示例
热词里出现不少Jetson Orin相关的内容，这里也多说一句。Jetson平台（比如Jetson Orin NX、AGX Orin）用的是ARM架构CPU加集成GPU，它和桌面级GPU在CUDA编程模型上是完全一致的，但有几个差异点要注意。
第一个差异是架构名，Jetson Orin系列对应的是sm_87（Ampere架构的嵌入式变体），这意味着你用-arch=sm_87编译的代码才能在Jetson上跑，桌面上编译的sm_89二进制不能直接跑到Jetson上。第二个差异是显存统一管理，Jetson的内存就是GPU显存，不需要单独分配，cudaMallocManaged这类统一内存API在Jetson上效率非常高，这也是嵌入式平台上编制代码时的一个重要权衡。第三个差异是功耗墙，Jetson在默认模式下GPU频率可能被限制，跑Samples性能测试前先检查nvpmodel和jetson_clocks设置，否则测出来的数据会误导你。
从实际体验来看，8_Android目录里的部分代码和Jetson的开发模式有些类似，也可以用make直接在Jetson的本机Ubuntu系统上编译运行，这一点比桌面平台还方便，省去了交叉编译的麻烦。手头有Jetson设备的朋友，建议直接把Samples整个clone到板子上编译一遍，这是一个很好的稳定性测试，也能验证你的刷机环境是否完整。
8. 最后再分享一点我的个人习惯
每次拿到新版本CUDA，除了跑一遍Samples自带的示例之外，我还会做一件额外的事——用doxygen给Samples源码生成一份离线文档，然后重点关注那些我平时不太碰的目录，比如4_Finance和10_Algorithm。原因很简单，这些领域的经典算法往往涵盖了通用计算的关键模式，比如BlackScholes涨幅过的数据并行、MonteCarlo里的随机数生成和归约、MergeSort里的动态规划和任务调度。这些模式在AI推理、数据处理、图像识别各种业务里都会反复出现。
还有一个我一直坚持的细节：在Samples源码里搜索TODO和FIXME注释。官方示例虽然总体质量很高，但也会留下一些未完成的探索过程，这些痕迹有时候比最终代码更有启发——它展示了NVIDIA工程师在踩坑过程中的思考路径。比如在9_Optimization/transpose示例里，你就能看到多个版本的代码存在，官方直接保留了对角线优化、pad优化、shared memory tile优化等多个尝试，这种“把过程也写给你看”的做法，在别的开源项目里很难见到。
坦白说，CUDA Samples这棵“摇钱树”在很多开发者手里只被用到了十分之一的价值。它不仅能帮你验证环境、学习语法，还能教你构建项目的工程规范、理解性能分析的完整流程、找到业务算法落GPU的捷径。与其在网上零散地搜各种教程，不如静下心把这份官方教材啃完。至少在CUDA这个领域，NVIDIA给出的Sample代码，始终是最接近“标准答案”的可用参考。希望这篇深度评测能帮你把这套资源真正用起来，也欢迎你把自己的使用心得分享到社区里，大家一起讨论进步。
