Nsight Systems无法深度剖析单个CUDA核函数的指令级行为或显存带宽瓶颈，因其不采集硬件计数器、不关联SASS/PTX；需切换至Nsight Compute（ncu）才能获取l1tex__t_bytes.sum、sm__inst_executed_op_ffma_pred_on.sum等细粒度指标。
不能直接用 Nsight Systems 深度剖析单个 CUDA 核函数的指令级行为或显存带宽瓶颈——它不采集硬件计数器，也不关联 SASS/PTX。真要抠到 l1tex__t_bytes.sum 或 sm__inst_executed_op_ffma_pred_on.sum 这种粒度，必须切到 ncu（Nsight Compute）。
为什么 nsight-systems 看不到核函数内部带宽和 IPC
Nsight Systems 是系统级 trace 工具，核心能力是捕获时间线：CPU 调用 cudaLaunchKernel 的时刻、GPU 上 kernel 实际开始/结束的时间、PCIe 数据传输区间、内存拷贝重叠情况等。它不读取 GPU 的硬件性能计数器（PMU），所以无法告诉你这个 kernel 到底用了多少 L2 带宽，或者每个 warp 平均执行了几条 FMA。
常见误判场景：
- 看到 timeline 上 kernel 执行时间长，就以为是“计算慢”——其实可能是
sys__bytes.sum高导致显存墙，但 nsight-systems 不显示这个值 - 发现 kernel 启动延迟大，归因为驱动问题——实际是前一个 kernel 没
cudaStreamSynchronize，被 nsight-systems 误标为“空闲”，而 ncu 能通过gpu__time_duration和sm__cycles_elapsed对比立刻识别 preempt
nsight-systems 能准确定位哪些调度问题
它真正擅长的是跨设备、跨上下文的时序因果分析。当你怀疑 kernel 调度受阻、数据搬运拖累整体吞吐，或想确认 CPU 是否在等 GPU，它就是第一道筛子：
管理和控制 macOS 系统功能。包括查看系统信息、管理进程、控制音量/亮度、 网络管理、电源管理、截图、剪贴板、Finder 操作等。当用户要求查看系统状态、 控制系统设置、管理进程、截图、调节音量亮度、查看网络信息、 关机重启睡眠等 Mac 系统操作时使用。
立即学习“C++免费学习笔记（深入）”；
- 用
nsys profile --trace=cuda,nvtx ./my_app抓全链路 trace，打开 GUI 后重点看 “GPU Trace” 行里 kernel 的 launch gap：如果两个 kernel 之间有 >10μs 空白，大概率是 host 端没发够 launch、stream 依赖未满足，或 driver queue 拥塞 - 对比 “CUDA Memory” 和 “GPU Kernel” 时间线：若 memcpy H2D 后 kernel 立即启动，但 D2H 却卡在 kernel 结束后很久，说明 kernel 内部可能隐式同步了 stream（比如用了
cudaDeviceSynchronize()） - 开启
--stats=true输出摘要报告，检查Avg Kernel Launch Latency和Max Overlap %：前者超过 5μs 就值得查 host 端准备逻辑；后者低于 60% 说明数据搬运没和计算有效重叠
怎么把 nsight-systems 和 ncu 串起来用
典型工作流不是二选一，而是接力：nsight-systems 找出“哪个 kernel 拖了后腿”，ncu 进去拆解“它为啥慢”。关键衔接点有三个：
- 确保 nsight-systems 抓到的 kernel 名称和 ncu 能匹配：编译时加
-lineinfo，运行时用nsys profile --capture-range=cudaProfilerStartStop配合代码里插nvtxRangePush("my_kernel")，这样 ncu 可用-k "my_kernel"精准定位 - nsight-systems 报告里若显示某 kernel 的 duration 异常高，用相同输入参数直接跑
ncu --set full --repeat 3 -k "my_kernel" ./my_app，注意加--target-processes all防止只 profiling 子进程 - 如果 ncu 发现
lts__t_sectors.sum / sm__cycles_elapsed接近 A100 的 1.8 TB/s 理论峰值，但 nsight-systems 显示 PCIe 传输占比却很低——说明瓶颈其实在 L2 到显存之间，得回头检查 memory access pattern 是否连续，而不是怪 PCIe
最易被忽略的一点：nsight-systems 默认不解析 device-side NVTX 标记，必须加 --nvtx-include=".*" 才能在 timeline 上看到 kernel 内部的自定义分段（比如“load data”、“compute loop”、“store result”），否则你永远不知道慢是在访存还是计算阶段——而这一步，恰恰是决定该用 ncu 还是改 kernel 逻辑的关键分水岭。
