新媒网 · 跨境数据社区

各位新媒网的读者朋友们，大家好！

在当今这个数据爆炸的时代，无论是您浏览新闻、畅玩游戏，还是从事深度学习训练，数据都如同水流般涌动。然而，数据量越大，存储和传输就越成为一道难题。为了解决这一挑战，数据压缩技术应运而生，它能有效减少存储空间，加快数据传输效率，在数据库、数据中心通信、高性能计算乃至深度学习等多个领域发挥着举足轻重的作用。

然而，凡事皆有两面。压缩固然好，但随之而来的数据解压过程却常常消耗宝贵的计算资源，引入不必要的延迟，从而拖慢了整体性能。这就像我们打包一个大箱子很方便，但拆箱整理货物却是个耗时耗力的活儿。

为了彻底解决这一痛点，英伟达（NVIDIA）公司带来了创新性的解决方案：在他们的Blackwell架构中集成了全新的硬件解压引擎（Decompression Engine，简称DE），并将其与功能强大的nvCOMP库紧密结合。可以说，这项技术组合的问世，意味着解压任务将不再占用通用计算资源，能够加速处理Snappy等主流压缩格式，并且让开发者无缝接轨、轻松上手。新媒网跨境获悉，这项技术有望为全球数据密集型工作负载带来一场效率革命。

下面，就让我们一起深入了解英伟达的DE和nvCOMP是如何协同工作的，它们的使用指南，以及它们将为数据处理带来的惊人性能提升。

解压引擎：数据处理的“幕后英雄”

Blackwell架构中新加入的解压引擎（DE）可不是普通的硬件，它是一个固定功能的硬件模块，专为加速Snappy、LZ4以及基于Deflate的各类数据流解压而设计。想象一下，有了这个专门的“解压专家”，GPU上那些处理复杂计算的流式多处理器（SM）就不必再分心去处理繁琐的解压任务了。如此一来，宝贵的SM资源得以完全专注于计算本身，而不再将宝贵的周期浪费在数据搬运和解压上。

这项解压引擎被巧妙地整合到了复制引擎（copy engine）中。这意味着什么呢？在过去，我们常常需要先将压缩数据从主机（Host）复制到设备（Device），然后再通过软件进行解压，这个过程不仅冗长，而且效率低下。而现在，有了DE，压缩数据可以直接通过PCIe或C2C接口传输，并在传输过程中同步完成解压。这种“边走边解”的模式，极大缓解了I/O瓶颈，让数据流动更加顺畅。

更令人兴奋的是，DE的加入实现了数据传输和计算的真正并行。对于多流工作负载而言，这意味着它们可以同时发出解压操作和SM内核计算指令。GPU可以因此得到更充分的利用，再也不会因为等待数据解压而“闲置”。在实际应用中，这无疑是一项重大突破。那些数据密集型应用，比如训练大型语言模型（LLMs）、分析海量的基因组数据集，或者运行复杂的高性能计算（HPC）模拟，将能够跟上新一代Blackwell GPU的超高带宽，而不会再因为I/O瓶颈而陷入停滞。可以说，DE的出现，为这些前沿科技的飞速发展提供了坚实的底层支撑。

nvCOMP的强大助力：GPU加速压缩的优势

NVIDIA nvCOMP库本身就是一套实力不俗的GPU加速压缩与解压例程集合。它不仅支持广泛使用的标准压缩格式，还包含英伟达（NVIDIA）专门为GPU性能优化而设计的专属格式。

在处理某些标准格式时，CPU和传统的固定功能硬件由于其架构特性，往往在并行度方面存在局限性，使得它们在某些解压场景下相较于GPU而言，能够展现出一定的优势。而英伟达（NVIDIA）的解压引擎（DE）正是针对这一问题而生，它旨在为一系列特定工作负载提供最佳的解决方案。新媒网跨境了解到，DE的引入，恰恰弥补了传统GPU在某些解压场景中的不足，让整个数据处理链条更加完善高效。

接下来，我们将深入探讨如何利用nvCOMP来充分发挥DE的强大功能。

如何巧妙运用DE和nvCOMP

对于开发者而言，通过nvCOMP的API接口来调用DE，无疑是最佳实践。目前，解压引擎（DE）仅在特定的GPU型号上可用，例如B200、B300、GB200以及GB300。因此，使用nvCOMP能够让开发者编写出具有良好可移植性的代码。这意味着，随着DE技术在未来GPU产品线中的普及，您的代码无需修改，也能在不同型号的GPU上无缝运行和扩展。

当DE可用时，nvCOMP会智能地选择并利用硬件解压功能，而用户代码则无需进行任何更改。如果DE暂时不可用，nvCOMP也能够自动回退到其基于SM（流式多处理器）的加速实现，确保您的应用性能始终在线。这种“智能适配”机制，极大地简化了开发流程，提升了代码的适应性。

当然，为了确保DE能够在您的GPU上发挥其最大效能，您需要留意一些特定的配置要求。nvCOMP通常允许使用任何可供设备访问的输入和输出缓冲区类型。然而，DE对这些缓冲区有着更为严格的要求。如果您的缓冲区不符合这些特定条件，nvCOMP将不得不回退到在SM上执行解压任务。

对于设备到设备（device-to-device）的解压操作，cudaMalloc分配的内存可以正常使用。而对于主机到设备（host-to-device），甚至是主机到主机（host-to-host）的解压场景，如果使用cudaMallocFromPoolAsync或cuMemCreate进行内存分配，则需要特别注意，确保分配器（allocators）的设置正确无误。

以下部分将通过具体的代码示例，展示如何正确使用这些不同的内存分配器。值得注意的是，在这两种情况下，与标准API使用方式的唯一区别在于新增了cudaMemPoolCreateUsageHwDecompress和CU_MEM_CREATE_USAGE_HW_DECOMPRESS这两个标志。在下面的示例中，这些内存分配都位于第一个CPU NUMA节点上。

（一）使用 cudaMallocFromPoolAsync

下面的代码示例展示了如何使用cudaMemPoolCreateUsageHwDecompress标志来创建一个Pinned Host内存池。通过设置这个标志，您可以确保从中分配的内存与DE兼容，从而让DE能够高效地处理您的数据。

cudaMemPoolProps props = {};
props.location.type = cudaMemLocationTypeHostNuma;
props.location.id = 0;
props.allocType = cudaMemAllocationTypePinned;
props.usage = cudaMemPoolCreateUsageHwDecompress;
cudaMemPool_t mem_pool;
CUDA_CHECK(cudaMemPoolCreate(&mem_pool, &props));
char* mem_pool_ptr;
CUDA_CHECK(cudaMallocFromPoolAsync(&mem_pool_ptr, 1024, mem_pool, stream));

（二）使用 cuMemCreate

这个例子则演示了如何利用底层的CUDA驱动API（cuMemCreate）来分配Pinned Host内存。同样地，通过设置CU_MEM_CREATE_USAGE_HW_DECOMPRESS标志，确保所分配的缓冲区与DE兼容，从而保证解压操作能够顺利高效地进行。

CUdeviceptr mem_create_ptr;
CUmemGenericAllocationHandle allocHandle;
CUmemAllocationProp props = {};
props.location.type = CU_MEM_LOCATION_TYPE_HOST_NUMA;
props.location.id = 0;
props.type = CU_MEM_ALLOCATION_TYPE_PINNED;
props.allocFlags.usage = CU_MEM_CREATE_USAGE_HW_DECOMPRESS;
size_t granularity;
CU_CHECK(cuMemGetAllocationGranularity(&granularity, &props, CU_MEM_ALLOC_GRANULARITY_MINIMUM));
// Create the allocation handle
CU_CHECK(cuMemCreate(&allocHandle, granularity, &props, 0));
// Reserve virtual address space
CU_CHECK(cuMemAddressReserve(&mem_create_ptr, granularity, 0, 0, 0));
// Map the physical memory to the virtual address
CU_CHECK(cuMemMap(mem_create_ptr, granularity, 0, allocHandle, 0));

缓冲区批处理的性能优化秘籍

为了达到最佳性能，用于解压的缓冲区批次（包括输入、输出和大小信息）应当是同一个内存分配中的偏移指针。如果提供了来自不同内存分配的缓冲区批次，那么主机驱动程序的启动开销可能会变得非常显著，从而影响整体效率。

下面的代码片段展示了如何高效地组织缓冲区批次，以减少不必要的开销：

uint8_t* d_decompressed_buffer;
CUDA_CHECK(cudaMalloc(&d_decompressed_buffer, total_decompressed_size));
// Create pinned host arrays for device decompression pointers
uint8_t** h_d_decompressed_ptrs;
CUDA_CHECK(cudaHostAlloc(&h_d_decompressed_ptrs, actual_num_buffers * sizeof(uint8_t*), cudaHostAllocDefault));
// Fill the pinned host pointer arrays for device decompression using offsets
size_t decompressed_offset = 0;
for (int i = 0; i < actual_num_buffers; ++i) {
h_d_decompressed_ptrs[i] = d_decompressed_buffer + decompressed_offset;
decompressed_offset += input_sizes[i];
}

值得注意的是，由于DE相关的同步要求，nvCOMP的异步API会与调用流进行同步。通常情况下，nvCOMP会在API完成之前返回，因此如果解压到主机，您仍然需要在结果可用之前再次同步调用流。对于设备端访问，解压结果在正常的流排序中即可获得，使用起来更为便捷。

此外，在B200 GPU上，如果任何一个缓冲区的大小超过4MB，nvCOMP将不得不回退到基于SM的实现。不过，这个限制未来可能会有所调整。开发者可以通过以下代码查询当前设备支持的最大解压长度，以便更好地优化自己的应用：

int max_supported_size = 0; res = CudaDriver::cuDeviceGetAttribute(&max_supported_size, CU_DEVICE_ATTRIBUTE_MEM_DECOMPRESS_MAXIMUM_LENGTH, device_id);

SM与DE性能对比：谁是解压王者？

解压引擎（DE）的诞生，旨在提供更快的解压速度，同时解放流式多处理器（SM）去处理其他更为复杂的计算任务。我们知道，DE提供了数十个专门的执行单元，而SM则拥有数千个warp（线程束）。从单个执行单元来看，DE在执行解压任务时的速度远超SM。但在某些特定工作负载中，如果SM资源能够被充分饱和利用，其解压速度也可能接近DE的水平。无论是SM还是DE，都可以使用主机固定内存（host pinned data）作为输入进行解压，从而实现零拷贝解压，进一步提升效率。

下面的图表将直观地展示在Silesia基准测试中，LZ4、Deflate和Snappy算法在SM与DE上的性能对比。这里需要特别指出的是，Snappy算法在nvCOMP 5.0版本中得到了全新的优化，而Deflate和LZ4算法在未来还有进一步软件优化的潜力。

性能测量分别针对64 KiB和512 KiB的块大小进行，并使用了“小数据集”和“大数据集”进行测试。其中，“大数据集”是完整的Silesia数据集，而“小数据集”则是Silesia.tar文件的前约50 MB数据。从图中我们可以清晰地看到，DE在各种情况下都展现出了强大的性能优势，尤其是在处理特定解压任务时，其专有硬件的效能得到了充分体现。

开启数据处理的新篇章

总结来看，Blackwell架构中引入的解压引擎（Decompression Engine）极大地简化了处理数据密集型工作负载中最大的挑战之一：如何实现快速、高效的数据解压。通过将这项关键任务转移到专门的硬件上进行处理，不仅让应用程序获得了显著的加速，更重要的是，它将宝贵的GPU计算资源解放出来，可以投入到其他更为核心的计算任务中去。

有了nvCOMP库的无缝集成，开发者无需修改现有代码，就能自动享受到这些性能提升带来的好处。这意味着，您的数据处理流程将变得更加顺畅，整体性能也将迈上一个全新的台阶。新媒网跨境认为，这项技术的普及，必将为AI、大数据分析、科学计算等诸多领域注入新的活力，推动数据时代继续向前发展。

新媒网（公号: 新媒网跨境发布），是一个专业的跨境电商、游戏、支付、贸易和广告社区平台，为百万跨境人传递最新的海外淘金精准资讯情报。

本文来源：新媒网 https://nmedialink.com/posts/nvidia-blackwell-de-unleashes-gpu-power.html