加速器工具箱：GPU和其他协处理器的性能分析和追踪详解

现代计算越来越依赖专用加速器——尤其是GPU、DPU和APU——来处理各种工作负载。*图形处理单元(GPU)*是一种大规模并行处理器，最初用于图形处理，现在在通用计算(HPC)和AI中必不可少。*数据处理单元(DPU)*是一种较新类型的可编程处理器，结合了CPU核心和高性能网络/存储引擎。DPU从CPU卸载网络、安全和存储任务，被认为是继CPU和GPU之后计算的"第三支柱"。同时，*加速处理单元(APU)*在一个芯片上集成了CPU和GPU组件——这一方法由AMD的Fusion架构首创——实现了统一内存和高吞吐量，适用于HPC和AI工作负载。这些加速器运行各种工作负载：GPU在并行数学（HPC模拟、深度学习训练/推理、数据分析）和图形渲染方面表现出色；DPU专注于数据中心任务（网络数据包处理、加密、存储卸载、虚拟化）；而APU针对需要紧密CPU-GPU耦合的异构工作负载（例如共享内存的AI或多媒体应用程序）。

性能分析和追踪工具对于优化这些加速器上的性能至关重要。这些工具收集低级硬件遥测数据（例如利用率、内存吞吐量、SM占用率、缓存未命中等计数器）并可以执行指令或事件级追踪（捕获内核执行、内存复制、网络数据包流等的时间线）。目标是识别通用代码和特定领域流水线（如ML模型训练、网络功能处理或图形渲染）中的瓶颈和低效率。然而，对高度并行、异构系统进行性能分析带来了开销、数据量和跨平台兼容性的挑战。本综述按硬件类型和领域对当前追踪/性能分析工具进行分类，比较开源和商业解决方案，并强调主要项目和最新研究。我们还讨论专门的工具集（包括类似于Linux BCC的基于eBPF的方法）如何适应GPU/DPU/APU，典型工作负载和匹配工具链，以及这一领域的局限和新兴方向。

GPU的性能分析和追踪工具

GPU性能分析经过多年图形和GPGPU开发的成熟，形成了丰富的厂商工具和开源框架生态系统。广义上，GPU性能分析器分为两类：开发时性能分析器，提供细粒度洞察以优化（通常具有高开销和GUI分析），以及轻量级监控器，适用于运行时或生产环境（低开销，专注于高级指标）。

• NVIDIA的性能分析套件： NVIDIA的GPU在HPC/AI中占主导地位，其工具被认为是行业标准。Nsight Systems提供系统范围的时间线追踪——捕获CPU线程、CUDA内核启动、内存复制等——以精确定位CPU-GPU边界上的瓶颈。它使用CUDA性能分析工具接口(CUPTI)收集详细的指标和事件。Nsight Systems对深入分析GPU加速应用程序极其强大，但它必须显式启动性能分析会话，并可能产生显著开销（在性能分析期间通常使程序速度降低2×–10×）。它适用于开发和调优，而非持续使用。另一方面，Nsight Compute专注于逐内核深入分析：它分析单个GPU内核，提供指令级统计（如指令混合、内存事务、warp占用率、执行停滞）甚至可以将性能指标与源代码行或PTX/SASS汇编关联。NVIDIA还提供Visual Profiler（一个较旧的GUI，现在主要被Nsight取代）和通过nvprof/nsys进行命令行性能分析。对于图形工作负载（DirectX、OpenGL、Vulkan），NVIDIA的Nsight Graphics捕获帧渲染管线、着色器计时和GPU状态以辅助游戏开发者。所有这些NVIDIA工具都是免费但专有（闭源）的。它们针对NVIDIA硬件进行严格优化，并支持特定领域的分析模式（图形vs计算vs AI）。

• AMD的GPU性能分析工具： AMD提供开源和专有工具作为ROCm和GPUOpen生态系统的一部分。历史上，CodeXL是AMD的用于CPU、GPU和APU的多合一性能分析器和调试器。CodeXL（现已停止）可以分析AMD APU/GPU上的OpenCL、HIP和HSA应用程序，收集内核执行时间和集成设备上的硬件计数器。近年来，AMD转向基于ROCm的工具：rocProfiler和rocTracer库（类似于NVIDIA的CUPTI）使HIP和OpenCL应用程序能够进行性能分析和追踪。2024年，AMD在ROCm 6.2中引入了新工具：Omniperf和Omnitrace。Omniperf是AMD Instinct GPU上机器学习和HPC工作负载的内核级性能分析器，通过CLI或GUI仪表板提供详细的性能计数器分析。Omnitrace是一个多用途性能分析/追踪工具，用于CPU和GPU，支持动态二进制插桩、调用栈采样，甚至因果性能分析，以精确指出在异构CPU-GPU执行中哪些函数消耗时间。这些工具是开源的，或者是AMD开放ROCm栈的一部分。对于图形和游戏开发，AMD在GPUOpen下提供Radeon GPU Profiler (RGP)和Radeon Developer Panel。RGP为Radeon GPU上的Vulkan/DX12应用程序提供低级时间线和波前占用数据，而Radeon Memory Visualizer帮助跟踪内存使用情况。AMD的工具也可以在他们的APU上使用，受益于统一内存（例如，在APU上进行性能分析意味着可以追踪GPU内核而不需要PCIe传输开销）。总体而言，AMD的方法强调开放接口（例如，GPUPerfAPI库让开发者直接访问GPU性能计数器）和与通用性能分析器的集成。

• Intel和其他GPU工具： Intel的GPU（集成Iris Xe和数据中心GPU如Ponte Vecchio）可以通过Intel的oneAPI工具集进行性能分析。Intel VTune Profiler支持GPU卸载分析，提供内核时间线、EU（执行单元）占用率和Intel GPU的内存带宽。Intel还提供Graphics Performance Analyzers (GPA)用于在Intel硬件上进行游戏/图形性能分析。值得注意的是，Intel开源了一套名为Profiling Tools Interface (PTI) for GPU的工具，其中包括用于oneAPI Level Zero和OpenCL应用程序的轻量级追踪工具。这些命令行工具（在GitHub上可用）可以在Intel GPU上追踪GPU内核提交、内存操作等，反映了Intel推动开放性能分析生态系统的努力。除了三大供应商之外，还有特定领域的GPU性能分析器：例如，ARM的Mali GPU（用于移动设备）有ARM Mobile Studio，其中包括用于分析移动GPU工作负载的Streamline工具；Qualcomm Adreno GPU可以使用高通的Snapdragon Profiler进行分析。这些更专业化的工具强调，跨供应商的性能分析通常需要特定于每种架构的专有SDK或工具，标准化程度较低——如果需要支持多个GPU供应商，这是一个痛点。

• HPC和跨平台性能分析： 在供应商特定工具之外，HPC社区开发了强大的开源性能分析框架，这些框架可以跨CPU和加速器工作。HPCToolkit是一个突出的例子：它使用统计采样以最小开销（通常<5%）对CPU和GPU执行进行性能分析。HPCToolkit可以在NVIDIA、AMD和Intel GPU上追踪GPU操作（内核、内存复制、同步），并且在NVIDIA上它甚至利用硬件PC采样来测量指令级执行和停滞周期。该工具将GPU活动关联回CPU调用栈，允许一个统一的分析，将GPU成本归因于调用的CPU代码上下文。这对异构应用程序非常宝贵，例如识别哪个CPU端函数启动了一个慢速GPU内核。其他跨平台工具包括TAU和Score-P/Extrae，它们可以对MPI+GPU程序进行插桩并产生集成的追踪。例如，Extrae追踪器（来自BSC）记录CPU事件和CUDA运行时事件，使得在Paraver中可以同时可视化CPU时间线和GPU内核时间线。这些开源工具通常通过插件支持多种加速器（CUDA用CUPTI，AMD用ROCm工具等），提供厂商中立的分析。它们可能不总是公开供应商工具指标的全部深度，但它们在协调多节点、多加速器追踪方面表现出色。学术界的努力如**Paraver/Extrae、Vampir和Allinea MAP (Arm Forge)**已经发展到能够处理GPU加速的HPC代码，表明了向异构系统统一性能分析的趋势。

• 图形和游戏性能分析： 在图形领域，追踪GPU工作负载通常涉及捕获API调用和GPU命令流。开源项目如RenderDoc允许逐帧捕获Vulkan/OpenGL/Direct3D调用，并提供GPU绘制调用计时的内省（有助于图形调试/性能）。虽然RenderDoc更多是一个调试器，但它可以提供关于GPU是否受某些绘制调用或着色器限制的洞察。也存在特定平台的工具：微软的PIX（用于Windows/Xbox上的DirectX）为每个渲染通道提供详细的GPU计时，甚至Linux也有GPUView等工具，可以为图形工作负载追踪内核级GPU调度事件。这些工具高度特定于领域（针对图形管线而非通用计算）。它们通过专注于帧渲染延迟而非内核吞吐量来补充通用GPU性能分析器。

下表表1总结了一系列具有代表性的GPU性能分析/追踪工具，跨供应商和领域，突出显示了它们的可用性和重点：

工具	供应商/来源	开源？	主要重点	支持领域
Nsight Systems	NVIDIA	否（免费）	时间线追踪（CPU和GPU），深度指标	CUDA计算，AI，部分图形
Nsight Compute	NVIDIA	否（免费）	内核微架构性能分析	CUDA/HPC/AI（每内核）
NVIDIA PerfKit/DCGM	NVIDIA	否（免费）	低级硬件计数器（PerfKit）；数据中心GPU监控（DCGM）	系统GPU遥测
Radeon GPU Profiler	AMD (GPUOpen)	是（免费）	低级GPU追踪（波前，ISA）	图形（Vulkan/DX12），GPGPU
ROCm Omniperf	AMD ROCm (Instinct MI GPUs)	是	内核性能分析（计数器和分析）	HPC/AI计算
ROCm Omnitrace	AMD ROCm	是	CPU-GPU追踪，调用栈性能分析	HPC/AI，异构应用
Intel VTune & GPA	Intel oneAPI	部分（VTune闭源，PTI开源）	VTune：GPU卸载分析；GPA：帧分析	计算（oneAPI）和图形
HPCToolkit	莱斯大学（HPC工具）	是	基于采样的性能分析（CPU和GPU）	HPC/AI（CPU+GPU）
RenderDoc	社区/Baldur Karlsson	是	帧捕获和API追踪	图形调试
PyTorch Kineto	FB/Intel（通过PyTorch）	是	框架内性能分析器（CPU+GPU）	AI/ML（深度学习）

来源： GPU供应商文档和工具网站。

如表所示，开源解决方案在研究和HPC中很突出（例如HPCToolkit、Omniperf/Omnitrace、RenderDoc），而商业/供应商工具（Nsight、VTune等）通常提供对专有硬件功能的最优化访问（如NVIDIA的性能分析器使用特权CUPTI API）。开源工具可能会用更广泛的适用性来交换一些低级细节——例如，HPCToolkit可以以统一的方式在NVIDIA、AMD和Intel GPU上进行性能分析，但对于最深入的NVIDIA特定指标（如SM warp停滞原因），开发者仍然依赖于Nsight Compute。相反，供应商工具通常是免费的但闭源，并且每个供应商的工具链都是不同的，导致碎片化。针对多个GPU平台的开发者可能需要处理多个性能分析器（一个用于CUDA，一个用于ROCm，一个用于Intel），因为没有跨供应商的GPU性能计数器单一标准接口。这种标准化缺乏导致了像ARM的HWCPipe库这样的项目，它试图在一个API中抽象多种架构的GPU计数器，但这样的努力仍在发展中。

低开销和持续监控的GPU追踪

经典的GPU性能分析器（如上所述）在开发过程中非常有用，但它们的开销和侵入性工作流程使其不适合在生产环境中进行持续监控（例如，你不能仅仅为了收集追踪而让一个实时AI推理服务器的速度降低5倍）。为了填补这一空白，最近的工具利用了受Linux eBPF启发的低开销追踪技术。一个值得注意的方法是Meta在eBPF峰会上由Selim (2023)介绍的eBPF用于全队规模的GPU性能分析。Meta的工具不是对GPU代码进行插桩，而是通过eBPF附加到GPU驱动程序事件，使其能够以可忽略的开销在数千台机器上持续收集GPU指标。

这一领域的一个开源项目例子是GPUprobe，一个基于Linux eBPF的GPU可观察性工具。GPUprobe使用uprobes（用户级探针）在内核级别钩入NVIDIA的CUDA运行时库函数。通过这样做，它可以实时监控像GPU内存分配（cudaMalloc/free）和内核启动等事件——无需对目标应用程序代码进行任何修改或插桩。开销非常低（在基准测试中测量低于4%），因此可以在生产环境中持续运行。GPUprobe填补了重型性能分析器和粗粒度监控之间的中间地带：它提供比NVIDIA的数据中心GPU管理器(DCGM)更丰富的、每个应用程序的洞察——例如跟踪每个进程和内核启动频率的内存泄漏——但开销远低于Nsight的完整性能分析。正如GPUprobe作者所指出的，Nsight Systems就像一个"GPU特定调试器"，非常适合深入分析但不适合持续使用，而DCGM提供高级统计数据（利用率、温度、健康状况）但缺少特定于应用程序的详细信息。像GPUprobe这样的工具弥补了这一差距，将指标导出到标准可观察性系统（例如Prometheus/Grafana）以集成到数据中心仪表板中。事实上，GPUprobe的设计允许以OpenMetrics格式抓取其指标（内存使用图、内核启动计数、带宽使用），因此操作员可以在Grafana中与CPU、网络和其他指标一起可视化GPU行为随时间的变化。

这种BCC/eBPF启发的方法是GPU性能分析的一个新兴趋势。它旨在将强大的内核追踪方法（由perf、bcc和eBPF等工具在CPU上开创）引入GPU领域。研究原型甚至探索了在GPU本身上运行eBPF程序（例如，一个学术项目"eGPU"通过PTX注入将BPF字节码卸载到GPU上），尽管这样的技术尚未成为主流。目前，更实用的用途是从CPU端钩入GPU驱动程序或运行时事件。结果是对GPU操作的非侵入性窥视：例如，检测GPU作业是否受启动限制（许多小内核启动）或容易内存泄漏，无需重新编译应用程序。这对云提供商或大规模AI部署特别有价值，持续性能分析可以捕获长时间运行的GPU服务中的性能回归或资源泄漏。

DPU（智能网卡）的性能分析和追踪工具

DPU（数据处理单元），通常以智能网卡的形式出现，结合了通用处理核心和专用数据包处理硬件。它们用于从主CPU卸载网络（数据包交换、虚拟化）、存储（NVMe-oF、加密）和安全任务。DPU的性能分析提出了一个独特的挑战：必须同时考虑板载CPU（通常是运行Linux的Arm SoC）和网络数据面，后者可能涉及网卡上的FPGA逻辑或ASIC加速器。

一般来说，DPU上的性能分析可以利用许多标准Linux工具用于嵌入式CPU部分。例如，NVIDIA的BlueField DPU运行Ubuntu，因此可以使用Linux perf、标准CPU性能分析器，甚至基于eBPF的监视器在DPU的Arm核心上对本地运行的软件（例如，卸载的软件交换机）进行性能分析。如果用户应用程序或代理在DPU的操作系统上运行，它的性能分析方式与在任何Linux服务器上很相似——尽管要意识到有限的核心和独特的任务（通常是数据包处理线程）。事实上，可以在BlueField上运行BCC工具来测量系统调用，或使用perf对DPU代码中的缓存未命中进行采样。这是DPU上的通用工作负载性能分析（类似于任何Linux主机，但资源受限）。

然而，DPU的许多工作负载是特定领域的（网络和存储），由专用硬件块处理。例如，DPU可能在硬件中加速Open vSwitch (OVS)数据路径，或通过专用引擎执行RDMA和NVMe操作。这些方面的性能分析通常依赖于供应商提供的遥测和计数器。像NVIDIA（Mellanox）和Broadcom这样的供应商提供工具来监控其智能网卡上的数据包吞吐量、延迟和卸载引擎统计数据。NVIDIA的DOCA SDK for BlueField包括用于加速功能（例如，加密、RDMA）的性能分析API和性能监视器。BlueField DPU通过标准接口（可能通过DPDK或/sys计数器）暴露每秒数据包数、丢包和队列深度等指标。在DPDK（与智能网卡一起使用的常见用户空间数据包I/O库）的情况下，开发者可以使用Intel VTune或perf对CPU上的数据包处理管道进行性能分析，并使用DPDK的内置事件计数器测量NIC吞吐量。Intel的文档甚至涵盖了使用VTune分析其基础设施处理单元(IPU)上的DPDK事件调度。

商业智能网卡供应商提供自己的监控套件。例如，Napatech（一家智能网卡制造商）分发性能分析工具，报告端口吞吐量、数据包计数器（RMON统计数据），甚至主机应用程序交互指标。这些工具通常以命令行监视器或GUI仪表板的形式出现。Napatech的监控CLI（在其文档中显示）可以实时更新线路速率（例如，在100G NIC上约48 Gbps Rx/Tx）和各种数据包大小计数器。这类供应商工具通常是专有的（与NIC捆绑在一起），突显了与GPU领域的相似之处：要获得对DPU上硬件加速器的完全可见性，通常使用供应商的API或实用程序。另一个例子：Broadcom/Pensando DPU（现在是AMD的一部分）有一个SDK，可能包括其数据包处理器的遥测，尽管详细信息通常隐藏在NDA之后。思科和Marvell同样为其智能网卡提供可管理性接口（通常作为网络操作系统或NIC固件的一部分），专注于吞吐量和延迟指标，而非指令级追踪。

话虽如此，开源努力正在为智能网卡性能分析而兴起。用于对某些NIC进行编程的P4语言有调试工具，可以模拟或记录数据包通过管道的流程（尽管不完全是传统意义上的性能分析器）。学术研究已经产生了像Clara和Pipefuse这样的工具，用于分析甚至预测智能网卡上的网络功能性能。这些工具旨在回答"如果我将这个功能卸载到智能网卡，可以预期什么吞吐量？"之类的问题，通过对NIC资源进行建模。虽然不是运行时性能分析器，但它们解决了DPU工作负载更广泛的性能调优问题。另一个研究例子是LogNIC，它为智能网卡管道提供性能模型。这类工具主要是实验性的，但指向未来的高级性能分析器用于网络任务。

总之，今天的DPU性能分析是CPU性能分析和专用网络遥测的拼凑组合。一方面可能使用熟悉的工具对DPU上的软件控制平面进行性能分析（以确保DPU的CPU不是瓶颈），同时使用NIC计数器或合成流量测试对数据平面吞吐量进行性能分析。协调这些通常是手动的。例如，要对卸载到DPU的Open vSwitch进行性能分析，你会测量DPU的CPU使用情况（控制任务、流设置）并收集NIC统计数据以了解数据包速率和延迟，可能通过生成测试流量并测量端到端延迟。网络工作负载的标准性能分析器（例如如何在硬件上追踪P4程序）仍处于起步阶段。我们预计，随着DPU变得更加普遍，厂商中立的性能分析标准可能会出现——可能是eBPF/XDP的扩展，以通过智能网卡进行追踪，或NIC的开放遥测模式——但目前很多内容都是厂商特定的。

APU（CPU-GPU集成平台）的性能分析和追踪工具

加速处理单元（APU）将CPU和GPU集成在单个芯片上，共享内存和互连。AMD最新的Instinct MI300A是一个典型例子：一个数据中心APU，在一个封装中结合了24个Zen4 CPU核心、128 GB的HBM内存和CDNA3 GPU。对APU进行性能分析需要理解片上CPU和GPU之间的交互，这既是一种优势也是一种挑战。一方面，统一内存意味着开发者不需要分析PCIe传输瓶颈——CPU和GPU可以访问同一个HBM池，数据移动通过指针而非显式复制。另一方面，APU的GPU与CPU共享功耗/散热预算，这可能引入性能分析工具应该揭示的争用问题（例如，当CPU满负荷运行时GPU是否被限制）。

APU的工具在很大程度上与上面讨论的CPU和GPU工具重叠，但更强调集成分析。例如，AMD的工具链是APU感知的：AMD uProf是一个覆盖CPU性能（PMU事件、缓存未命中等）的性能分析套件，也可以在支持的APU上与GPU活动关联。AMD uProf和CodeXL历史上允许在APU的集成GPU上分析OpenCL内核，报告每个内核的性能计数器。前面提到的新的ROCm Omnitrace明确支持在一个时间线中同时分析CPU和GPU，这对于CPU线程频繁启动GPU工作的APU来说是理想的。Omnitrace能够在CPU端使用二进制插桩和调用栈采样，同时追踪GPU内核，有助于在APU上"全息"映射性能。这意味着如果APU上的CPU函数调用GPU内核，该工具可以显示CPU函数中的时间和GPU内核中的嵌套时间作为同一调用树的一部分——这对于优化异构代码至关重要。

对于消费级APU（如带有Radeon图形的AMD Ryzen处理器），开发者通常使用图形性能分析器（用于游戏用例）或OpenCL/Vulkan性能分析器进行计算。例如，AMD的Radeon GPU Profiler在集成GPU上的工作方式与独立GPU相同。统一内存也允许使用标准操作系统性能计数器：在Linux上，AMD的GPU驱动程序通过drm/sysfs暴露某些GPU利用率指标，因此甚至可以使用系统监视器或自定义脚本来记录GPU活动和CPU活动。使用APU的Windows开发者可能使用Microsoft的PIX或AMD的Radeon Developer工具来分析在集成GPU上运行的DirectX12游戏——这些工具显示CPU和GPU时间线，并可以突出显示CPU是否饿死了GPU或相反。本质上，APU性能分析不需要全新的工具类别，但它受益于能够紧密关联CPU和GPU性能的工具。这类似于在独立GPU系统上进行性能分析，只是CPU-GPU之间的延迟更低，内存是共享的，工具需要考虑这一点（例如，可能出现CPU和GPU在内存上争用的缓存一致性效应）。

值得注意的是，集成架构在2010年代中期促进了HSA（异构系统架构）的发展，AMD的工具有HSA特定的性能分析模式。例如，CodeXL包含一个用于AMD APU的HSA性能分析器，可以追踪HSA内核调度和HSAIL指令。现在这些功能大部分已被吸收到ROCm工具中。本质仍然是：APU需要对整个系统进行性能分析，而不仅仅是孤立地分析"CPU vs GPU"。像Omnitrace、VTune或HPCToolkit（具有异构调用路径分析）这样的工具对基于APU的工作负载特别适用，因为它们自然地混合CPU和GPU指标。

开源与商业解决方案的比较

在加速器性能分析领域，开源（OSS）和商业/专有解决方案各有优缺点。以下是几个关键方面的比较：

• 功能深度和硬件访问： 供应商提供的工具（通常闭源，但往往免费）往往对硬件性能计数器和功能有最全面的访问权限。例如，NVIDIA的Nsight可以报告SM warp停滞原因和纹理缓存命中率——这些指标由NVIDIA的专有接口暴露，开源工具通常无法获取。同样，AMD的专有驱动程序可能向RGP暴露通用工具无法获得的GPU波前占用率详情。OSS工具依赖于发布或逆向工程的接口；例如，AMD的GPUPerfAPI（开放库）提供跨平台计数器访问，这就是为什么AMD自己的工具可以开源。开源项目有时缺乏对最新硬件的支持，直到供应商发布文档，而商业工具在新GPU发布第一天就准备就绪（因为供应商负责构建它们）。另一方面，像HPCToolkit这样的开源工具在某些功能上有创新，如完全自动化的调用栈展开和统计GPU指令采样，这些在供应商GUI中不可用，表明OSS在某些功能（特别是集成和低开销方面）可以领先。

• 可扩展性和定制化： 开源性能分析器（HPCToolkit、TAU等）允许用户修改或编写脚本，实现自定义分析或集成到自动化管道中。例如，你可以使用Score-P对代码进行插桩并以开放追踪格式（OTF2）输出追踪，然后使用自定义分析工具进行后处理——这一切都是因为格式和代码是开放的。相比之下，商业工具通常将数据锁定在专有格式中（例如，Nsight的.nsys-rep追踪文件）需要供应商的查看器，尽管存在一些导出选项（如CSV导出）。OSS方法还促进了社区贡献——例如，对新编程模型（OpenMP卸载、Kokkos等）的支持通常首先通过社区补丁出现在TAU或Score-P等工具中。

• 跨供应商支持： 如前所述，开源工具通常更供应商中立。像Vampir或HPCToolkit这样的单一工具可以在一次运行中处理多种加速器类型，而供应商工具是孤立的（Nsight不会分析AMD GPU，AMD的rocprof不会在NVIDIA上工作）。对于异构环境（例如，在一个系统中有Intel CPU、NVIDIA GPU和可能的Xilinx FPGA），你唯一的希望可能是一个通过插件或标准API（OpenCL、oneAPI等）支持所有这些的开源工具来获得统一的追踪。这在研究或多供应商环境中是OSS解决方案的一个优势。缺点是供应商工具通常针对自己的硬件更加优化——它们可能提供更精致的UI，或在该平台上更稳定的数据收集。例如，使用非官方GPU计数器的开源工具如果驱动程序发生变化，可能会变得脆弱或不太准确。

• 成本和支持： 大多数GPU/DPU的供应商工具是免费的（以啤酒的意义），但闭源。HPC中有一些真正的商业（需要购买）性能工具，如Arm Forge套件（包括MAP性能分析器）——这些带有专业支持。开源工具是免费的（以言论/啤酒的意义），但支持来自社区或自我专业知识。具有关键任务需求的公司有时更喜欢由供应商支持的工具（以帮助解释结果或获取bug修复）。话虽如此，大型供应商（NVIDIA、Intel）确实为他们的免费工具提供支持论坛。在网络等特定领域，一些商业分析器（例如，深度数据包检测性能分析器）可能来自专业公司并需要许可证——但这些相对罕见。

在实践中，环境通常使用组合方式：例如，HPC中心可能使用供应商性能分析器来优化特定GPU上的代码，但然后集成HPCToolkit或IPM（一个MPI性能分析器）进行回归测试和跨系统比较。值得注意的是，开源和闭源工具可以相互补充。开发者可能运行OSS追踪工具获取高级概览，并使用供应商的详细性能分析器交叉检查特定内核。GPU领域的一个例子：用户可以运行使用Score-P插桩的程序获取整体MPI+GPU时间线，然后使用Nsight Compute放大特定感兴趣的GPU内核，检查其内存吞吐量。这种分层方法发挥了每种工具的优势。

特定工作负载的工具映射

不同的工作负载以不同方式压力测试加速器，相应地，在每个领域都有特定工具被青睐：

• 通用计算/HPC： 这些工作负载（科学模拟、线性代数、数据分析）使用GPU获取吞吐量。性能分析关注内核效率和GPU利用率。像Nsight Compute（用于计算内核分析）或HPCToolkit/Omniperf这样的工具非常适合。HPC代码也在数千个GPU上并行运行；详细跟踪每一个是不切实际的，因此像HPCToolkit这样仅增加~1-5%开销的工具对于大规模运行的性能分析非常宝贵。HPC工作负载通常使用MPI + GPU，因此可以关联通信和计算的工具（例如，通过Extrae的时间线追踪，或通过mpiP与GPU性能分析相结合的MPI分析）非常适合。在HPC中的DPU（例如，使用智能网卡进行RDMA），"工作负载"通常只是网络——这里关注的是吞吐量和重叠（性能分析确保DPU处理数据传输而GPU计算，例如）。工具：网络基准测试（如用于InfiniBand的IB Profiler）加上GPU性能分析器，查看通信是否与计算重叠。

• 机器学习/AI： ML训练结合了繁重的GPU计算和数据管道开销。分析ML工作负载可能涉及框架级性能分析器：例如，PyTorch Profiler（建立在Kineto上）内部使用CUPTI记录每个操作的GPU时间，或TensorFlow Profiler同样捕获操作和流的时间线。这些产生高级视图（哪个模型层花费时间）以及低级内核详情。NVIDIA有一个DLProf工具，与TensorBoard集成，在神经网络操作的上下文中显示GPU内核指标。对于多GPU训练，Nsight Systems可以跟踪跨GPU的活动（特别是如果使用NCCL进行通信——Nsight可以显示NCCL调用时间线）。一个新兴的挑战是分布式训练的性能分析：像PyTorch Profiler现在有分布式追踪，但无缝分析100多个GPU训练一个模型仍然是一个活跃的开发领域。在DPU方面，AI可能使用DPU进行预处理或移动数据——分析DPU的效果（例如使用它进行数据过滤）涉及监控DPU加速数据摄取的程度（通过吞吐量跟踪）并确保GPU不会饥饿。未来，DPU上的AI加速器（一些DPU可能包括微型ML核心）可能需要新的性能分析器，但目前大多数AI工作侧重于GPU。

• 网络和I/O工作负载： 对于DPU或GPU上的纯网络任务（是的，GPU在某些情况下也可以使用CUDA或OpenCL进行数据包处理），性能分析关注延迟和吞吐量。这里的工具包括数据包生成器（测量管道可以处理多少Mpps）和代码路径的追踪工具。例如，如果使用GPU加速数据包加密，可能使用Nsight确保内核启动与数据传输重叠。如果使用DPU在软件中运行IDS（入侵检测），可能使用perf分析它是否受CPU限制，并使用NIC计数器查看丢包。网络工作负载通常需要实时追踪（捕获抖动峰值），因此可能使用基于eBPF的监视器甚至硬件遥测（如P4运行时日志）。也有人对使用GPU进行网络（通过CUDA管道的GPU加速NIC卸载）感兴趣，这将涉及GPU和网络性能分析——但这相当小众和实验性。

• 图形和可视化： 对于GPU（特别是游戏机或笔记本电脑中的APU）上的游戏引擎或VR应用，RenderDoc、Nsight Graphics和平台性能分析器（例如用于Metal的Apple的Xcode Instruments）专为测量帧时间、GPU管线阶段和CPU-GPU同步而设计。图形工作负载通常受GPU着色器吞吐量或CPU绘制调用提交率的限制。性能分析映射到检查GPU的帧时间预算是否被超出以及原因（哪个阶段——顶点着色？片段？内存？）。这些工具通常提供专门的可视化（HUD叠加层、帧刮刀）是一般计算性能分析器不提供的。对于处理图形的APU，还必须考虑CPU和GPU共享内存带宽——图形调试器可以显示CPU内存流量（例如，更新纹理）是否影响GPU。此外，在专业可视化（CAD等）中，GPU内存使用可能是限制因素；像NVIDIA的Nsight或AMD的RGPA这样的工具可以分析VRAM使用情况和缓存行为，以优化大型模型。

本质上，每种处理单元类型在特定领域都有使用，性能分析解决方案相应地发展——但也存在趋同。现代AI应用可能涉及GPU用于计算，CPU用于编排，DPU用于数据加载，所有这些都在一个管道中。这提出了对多加速器性能分析的需求——跟踪一个操作在CPU、DPU和GPU之间移动的能力。今天这通常意味着运行多个工具并手动关联时间戳。例如，可能使用Nsight跟踪GPU，同时在网络端运行tcpdump或NIC计数器，然后对齐日志。这种多组件工作流程很麻烦，表明有机会对异构工作流程进行更集成的性能分析。

现有工具链的局限和挑战

尽管有众多已讨论的工具，但在对GPU、DPU和APU进行性能分析时，从业者面临几个持续存在的挑战：

• 碎片化和供应商锁定： 如前所述，每个供应商的加速器通常带有一个孤立的工具链。这意味着在一种工具中的专业知识不容易转移到另一种，混合硬件会导致多个工具。它还有锁定风险：使用专有工具进行的优化可能依赖于供应商特定的功能。没有像"perf"这样的通用标准可以普遍覆盖所有加速器类型（尽管在CPU上，perf本身仅限于Linux）。GPU供应商之间缺乏通用性能计数器接口就是一个典型例子——开发者必须使用CUDA特定或ROCm特定的API，这使得可移植的性能分析变得困难。对于DPU，它们相对较新，甚至没有广泛采用的第三方性能分析器——你使用DPU供应商提供的任何工具。这种碎片化不仅使开发者的生活复杂化，也使试图公平比较平台的研究者复杂化。

• 有限的可见性（"黑盒"问题）： 加速器性能的某些方面对当前的性能分析器来说实际上是黑盒。例如，GPU内部调度（warp如何调度，L2缓存行如何驱逐）可能不会通过计数器完全暴露。同样，如果DPU的数据包加速器是FPGA或ASIC，外部工具可能只看到吞吐量数字，而不是为什么它在X Gbps饱和（例如，NIC内部的微架构细节）。即使使用NVIDIA的计数器，也经常有未记录的指标或难以解释的指标。这种有限的可见性通常是设计上的（IP保护），但阻碍了优化。另一个可见性问题出现在闭源工作负载中：如果你在GPU上分析第三方库，你可能会看到内核名称和时间，但不知道它内部做了什么。像HPCToolkit这样的工具通过将成本归因于指令（即使没有源代码）来提供帮助，但通常很难优化你无法检查的内容。

• 开销与侵入性： 许多精确的追踪工具扰动它们所测量的性能。基于插桩的追踪（在每个内核启动或每个数据包上插入钩子）可能导致海森堡效应，即测量行为改变时序。虽然基于采样的方法缓解了这一点，但它们用较低的开销换取细节。总是存在一个挑战，即找到正确的平衡：收集多少数据和以什么频率，以获得代表性概况而不会淹没在开销或数据量中。高开销工具必须限于测试环境，意味着你可能无法捕获只在规模或生产环境中显现的问题。相反，超轻量级监视器可能只标记"GPU利用率低"，但不解释原因。弥合这一差距仍然是一个持续的挑战。

• 并发和排序问题： 分析多线程、多流工作负载可能遇到对齐事件的问题。例如，来自不同GPU或不同设备的时间线追踪可能有时钟偏差，使得确定事件的真实顺序变得棘手。即使在一个GPU上，硬件也可以并发执行许多内核（在不同的SM上或使用异步流），可视化或理解重叠活动很复杂。工具尝试（例如，Nsight Systems在时间线上显示重叠内核），但随着系统扩展，人们面临我们可能称之为"事件爆炸"问题：需要推理的事件太多。过滤和专注于正确的子集很困难。工具才刚开始引入更智能的过滤（例如，只追踪长于X微秒的内核，或仅在GPU利用率下降时追踪GPU活动等）。

• 缺乏多加速器协调： 今天的工具在很大程度上是按设备孤立运行的。如果你有一个带有CPU、GPU、DPU、FPGA的异构节点，每个可能单独分析，产生用户必须关联的单独报告。假设一个性能问题是由于GPU吞吐量和NIC吞吐量不匹配导致的——GPU性能分析器可能只显示GPU空闲20%的时间（等待数据），而NIC监视器显示队列100%利用率——由工程师来关联这些并推断原因（网络绑定）。理想情况下，性能分析器会自动捕获此类跨设备依赖性（例如，视觉提示表明GPU空闲与NIC饱和相关）。实现这一点需要全面视图，也许是可以跨设备链接的标准化追踪事件（例如，NIC上的"帧传递"事件可以与"GPU上处理的帧"事件关联）。没有通用标准，这种关联主要是手动的或通过临时插桩（在应用代码中插入时间戳）。

• 缩放和大数据问题： 在分析大规模工作负载时（想想1000个GPU或处理每秒数百万数据包的DPU），性能分析数据量可能非常庞大。存储和分析即使是几秒钟操作的追踪日志可能都是非常重要的。数据减少是一个挑战——如何有意义地总结性能数据。当前工具提供一些总结（如平均内核时间、前10大内存消费者等），但需要更多自动化总结，可能采用分层或统计技术来压缩追踪。HPC中心通过选择性追踪（仅在少数等级上捕获等）或使用采样来处理这个问题。未来的工具可能包含在线分析，工具本身在收集数据时进行一些处理（例如，计算分布而不是记录每个事件）。

• 教育和可用性： 最后，值得注意的是一个实际挑战：学习曲线。每个工具通常都有自己的GUI或输出格式，理解"warp序列化"或"bank冲突"或"DPU缓存命中"等指标需要一些架构知识。这些加速器上的性能分析在某种程度上是一门黑魔法，虽然工具提供数据，但理解它并不总是直接的。屋顶线模型等努力试图简化解释，但用户仍然很难从性能分析器输出转变为具体优化。这部分是教育挑战——文档和培训需要伴随工具。这也是工具构建者的设计挑战，以直观的方式呈现数据（例如，Nvidia现在通常直接集成AI性能指标，如"Tensor Cores的利用率"，告诉ML工程师他们如何利用GPU）。

总之，虽然当前用于GPU、DPU和APU的追踪和性能分析工具强大且必不可少，但它们在一个高度专业化和碎片化的环境中运作，存在可见性差距和集成缺陷。克服这些局限需要协作努力——硬件供应商（开放接口）、工具开发者（创建更智能、标准的工具）和研究社区（开创低开销和组合追踪的新技术）之间的协作。

当前研究方向和新兴趋势

加速器追踪/性能分析领域正在积极发展。以下是几个关键的研究和开发方向：

• 低开销、常时开启的性能分析： 如前所述，借鉴操作系统遥测（eBPF、硬件性能监视器）的技术正在适应加速器。Meta的连续GPU性能分析器和GPUprobe等工具表明，可以在生产环境中以最小的开销收集有用的数据。我们预计这一领域会有更多工作：例如，连续DPU监控集成到数据中心可观察性栈中（类似于GPU的DCGM）——可能使用eBPF监控DPU NIC驱动程序或使用硬件内置遥测（许多NIC有用于数据包调度、队列占用等的遥测流，可以利用这些）。对于GPU，研究人员正在探索基于采样的性能分析以进一步减少开销。NVIDIA的最新架构支持PC采样，GPU定期采样其程序计数器并报告正在执行哪些指令以及它们是否停滞。这可以在后台进行，几乎不会干扰。HPCToolkit已经在NVIDIA GPU上利用这一点来采样指令并推导停滞分析。未来的工具可能扩展此类采样，以获取GPU活动的统计跟踪，而无需对每个内核启动进行插桩。

• 统一和标准化接口： 一个反复出现的主题是跨供应商缺乏标准化。有人呼吁建立供应商中立的GPU性能分析API——例如，OpenGL社区过去曾建议一个跨供应商统一的GPU性能计数器API。在计算领域，类似于CPU的PAPI（性能API）的GPU版本将是有价值的。我们看到早期步骤：Khronos Group的OpenCL和Vulkan API有性能查询扩展（如Vulkan的VK_KHR_performance_query）允许应用程序以标准化方式收集一些计数器。此外，Intel的oneAPI旨在为加速器提供统一接口（Level Zero），包括工具支持。虽然oneAPI以Intel为中心，但它为抽象性能分析设立了先例：理论上，应用程序可以使用oneAPI在CPU、GPU和FPGA上使用单一工具进行性能分析——但前提是其他供应商采用或适应它。另一个推动力是硬件的OpenTelemetry——目前OpenTelemetry（在云中流行用于追踪请求）不涵盖内部硬件事件，但可以设想将其扩展到CPU、加速器和网络事件，用于异构工作负载的分布式追踪。

• AI在性能分析中的集成： 随着性能数据的复杂性（特别是来自细粒度追踪），有兴趣使用机器学习辅助性能分析。研究项目已经研究了从部分追踪预测性能或从计数器特征自动分类瓶颈的学习模型。例如，ML模型可能学习计数器模式，表明内存带宽瓶颈与计算绑定，自动化人类专家手动使用屋顶线模型做的事情。虽然在工具中尚未主流化，但一些性能分析器（如Intel Advisor的自动屋顶线分析，或NVIDIA在Nsight Compute中的引导分析）纳入了启发式指导，可能发展为ML驱动的建议。目标是帮助开发者更容易解释性能分析数据的洪流。

• 因果追踪和因果性能分析： 传统性能分析被动观察性能。一个较新的研究方向是因果性能分析，性能分析器通过扰动执行来实验，以测量对性能的影响（例如，人为减慢一个组件，看看其他组件是否空闲，确定瓶颈的因果关系）。Omnitrace提到对因果性能分析的支持暗示这类技术正在为GPU/CPU组合实施。因果追踪可以识别，例如，GPU内核X完成延迟是导致CPU任务Y延迟的原因，通过观察如果X更快或更慢，时间如何变化。这是一种高级功能，有潜力解开异步管道中的复杂依赖关系。

• 多加速器和分布式协调： 随着系统集成CPU + 各种加速器（GPU、DPU、FPGA、TPU等），一个研究挑战是在它们之间协调性能分析。当工作的部分发生在不同的芯片上，每个都有自己的时钟和追踪缓冲区时，我们如何获得一个连贯的时间线或概况？HPC中的Extrae/Paraver等工具可以通过对齐时间戳（假设时钟同步）合并来自CPU和GPU的追踪，并允许一起分析它们。我们期待在这方面的进一步发展，可能使用标准时间戳（可以使用PTP——精密时间协议——同步主机和DPU之间的时间，例如）。此外，正在探索跨工具协调触发器——例如，当网络事件发生时启动GPU性能分析器。一些当前工具允许触发器（Nsight可以基于CUDA API调用或标记启动/停止）；将其扩展到跨设备（当DPU的数据包队列溢出时启动GPU追踪）对于诊断跨栈性能问题（如缓慢的GPU导致智能网卡上的数据包积压）可能非常有用。

• 新型加速器的更好性能分析： 虽然本报告主要关注GPU、DPU和APU，但加速器世界还包括FPGA、AI ASIC（例如Google的TPU）等。每一种都在孵化自己的工具——Xilinx（AMD）FPGA有用于硬件内核的Vivado和Vitis分析器，Google TPU在TensorBoard中有性能分析器等。一个明确的方向是将这些整合在一起。如果一个云有CPU、GPU、DPU、TPU一起工作，理想情况是有一个单一窗口来观察它们。行业联盟最终可能在加速器遥测方面合作制定开放标准（类似于OpenCL是计算的标准）。在此之前，研究通常会介入：例如，关于通过结构内监视器监控数据中心FPGA的学术工作，或在其他设备上使用类似eBPF的技术。

总之，性能分析/追踪研究正朝着使这些工具更普遍、智能和统一的方向发展。目标是减轻开发者手动插桩和关联来自不同来源的性能数据的负担，而是提供更智能的工具，适用于当今数据中心复杂的异构系统。

结论

加速器的追踪和性能分析已经变得与早期对CPU进行性能分析一样关键。我们现在拥有针对不同硬件和用例的广泛工具：从NVIDIA的Nsight套件和AMD的ROCm工具进行深度GPU分析，到像HPCToolkit这样用于整体性能分析的开源框架，再到基于eBPF的新兴方法，实现连续监控。GPU享有最成熟的工具支持（反映了它们在计算中的较长历史），而DPU和其他领域特定加速器正在赶上，拥有自己的新兴性能分析器和遥测系统。APU说明了需要能够无缝地跨越传统处理器边界进行性能分析的工具，因为计算正朝着紧密集成的异构设计发展。

本综述强调了开源和商业解决方案都扮演着重要角色：开源工具促进跨平台敏捷性和创新，而供应商工具利用专有知识为其硬件提供最大洞察。最佳结果通常来自于将它们结合使用。在ML、网络和图形等专业领域，领域特定的性能分析能力增强了通用工具，提供所需的视角（例如，从神经网络层的角度查看GPU时间线，或在CPU周期上下文中的网络吞吐量）。

展望未来，趋势指向更多集成（跨加速器的统一时间线）、自动化（智能分析）和低开销可观察性成为标准。研究正在积极解决许多当前差距，从标准化性能指标到使用因果性能分析和ML驱动分析等新技术来解释性能数据。同时，供应商锁定和黑盒硬件等挑战将需要行业合作，也许需要推动更开放的硬件遥测接口。

总结起来，旨在优化加速器驱动系统的开发者和工程师应采取混合方法：利用供应商特定性能分析器的丰富功能进行详细分析，使用开源和跨平台工具获取跨多样化硬件的"大图景"，并关注可以采用的新兴工具，以改进连续性能监控。通过结合这些工具和技术，可以获得对任何工作负载上GPU、DPU和APU性能的全面理解——从单个GPU内核的指令停滞到整个异构管道的端到端行为。这种深入而广泛的性能分析能力对于充分利用现代加速器在通用和领域特定应用中的计算能力至关重要。

参考文献

• NVIDIA博客 - "什么是DPU？"
• AMD - "AMD Instinct™ MI300A加速器"
• ADMIN杂志 - "性能分析是生存的关键"
• DEV社区 - "窥探你的GPU：使用eBPF构建零插桩CUDA监控"
• CodeXL文档 - "使用GPU性能分析器"
• AMD社区 - "CodeXL 2.6 GA发布说明"
• ROCm文档 - "ROCm 6.2.0发布说明"
• 高性能计算 - "开发AI和HPC解决方案？看看新的AMD ROCm"
• Lei.Chat - "从移动GPU驱动程序采样性能计数器"
• AMD GPUOpen - "GPUPerfAPI"
• BizTech杂志 - "什么是DPU（数据处理单元）？它如何工作？"
• LinkedIn - eBPF峰会 - "Meta的GPU使用BPF进行性能分析 - Riham Selim"
• GitHub - "GPUprobe/gpuprobe-daemon"