第四章：显存与内存的协同：CPU-GPU数据传输路径，PCIe带宽对推理延迟的影响

好，咱们进入第四章。这一章聊的话题，说白了就是「数据怎么从CPU手里交到GPU手里」。你想想看，模型再牛逼，参数在显存里，输入数据在内存里，这俩不打通，推理根本跑不起来。

我刚开始做部署的时候，总觉得这步没啥技术含量。不就是把数据拷过去吗？结果第一次上线，延迟直接炸了。排查了半天，发现瓶颈根本不在模型计算，而在PCIe这条「独木桥」上。

4.1 CPU-GPU之间的「高速公路」

CPU和GPU是两套独立的系统。CPU有自己的内存（DDR），GPU有自己的显存（VRAM）。它们之间通过PCIe总线连接。

PCIe的全称是Peripheral Component Interconnect Express。你可以把它想象成一条高速公路。数据从CPU内存出发，经过PCIe控制器，到达GPU显存。反过来也一样。

这条高速公路有几个关键指标：

  • 带宽：每秒能传多少GB数据。PCIe 3.0 x16的理论带宽是16 GB/s，PCIe 4.0 x16是32 GB/s，PCIe 5.0 x16是64 GB/s。
  • 延迟：一次传输的往返时间。通常在几微秒到几十微秒之间。
  • 通道数：x1、x4、x8、x16。通道越多，带宽越大。

实际带宽 vs 理论带宽

别被理论值骗了。实际有效带宽通常只有理论值的60%-80%。协议开销、数据对齐、中断处理都会吃掉一部分。我实测过PCIe 3.0 x16，稳定传输也就10-12 GB/s。

4.2 数据传输路径：一次推理的「物流」过程

一次典型的推理，数据是怎么走的？我给你拆解一下：

  1. 输入准备：CPU从磁盘或网络读取输入数据（比如一张图片），放到内存中。
  2. 预处理：CPU对数据进行缩放、归一化、格式转换。这一步在内存里完成。
  3. 传输到GPU：CPU调用cudaMemcpy（或类似API），把数据从内存拷贝到显存。
  4. GPU推理：GPU从显存读取数据，执行模型计算。
  5. 结果回传：GPU把推理结果从显存拷贝回内存。
  6. 后处理：CPU对结果进行解析、过滤、输出。

你看，一次推理至少涉及两次PCIe传输：输入进去，结果出来。如果模型很大，或者输入是批量数据，传输量会非常可观。

我的经验：对于小模型（比如MobileNet），计算时间可能只有1-2毫秒，但PCIe传输就要花3-5毫秒。这时候传输延迟反而成了瓶颈。我曾经优化过一个OCR服务，把输入从JPEG解码后直接传，省掉了内存中的一次拷贝，延迟降了30%。

4.3 PCIe带宽对推理延迟的影响

咱们来算一笔账。假设你的模型输入是一张1920x1080的RGB图片，每个像素3个字节，总共大约6 MB。如果使用PCIe 3.0 x16，理论带宽16 GB/s，传输时间大约是：

6 MB / 16 GB/s = 0.375 毫秒

看起来很快对吧？但这是理想情况。实际传输要考虑：

  • 数据对齐：GPU要求内存对齐，不对齐会触发额外的拷贝。
  • DMA引擎：CPU和GPU之间的DMA传输有启动开销，小数据包尤其明显。
  • PCIe拥塞：如果多个设备共享PCIe总线（比如两块GPU），带宽会被瓜分。

我遇到过最坑的情况：一台服务器插了两块GPU，但PCIe通道分配不均。一块跑在x16，另一块只能跑x4。结果x4那块推理延迟比x16高了整整一倍。查了半天才发现是主板插槽的问题。

PCIe版本 通道数 理论带宽 6MB传输时间（理论） 实际典型时间
3.0 x16 16 GB/s 0.375 ms 0.5-0.8 ms
4.0 x16 32 GB/s 0.188 ms 0.3-0.5 ms
5.0 x16 64 GB/s 0.094 ms 0.15-0.3 ms

避坑指南：我曾经在生产环境遇到过一个问题——服务器用了PCIe转接卡，但转接卡只支持PCIe 3.0 x4。结果带宽只有不到4 GB/s，传输一张大图要2-3毫秒。后来换成直连x16插槽，问题解决。所以，部署前一定要用nvidia-smi topo -m检查GPU的PCIe拓扑。

4.4 优化策略：让数据「跑」得更快

既然PCIe是瓶颈，那怎么优化？我总结了几条实战经验：

4.4.1 批量传输

别一次传一张图。攒一批，一次性传。PCIe的启动开销是固定的，传1张图和传32张图，启动时间差不多。批量越大，均摊到每张图上的传输时间就越小。

// 不推荐：逐张传输
for (int i = 0; i < batch_size; i++) {
    cudaMemcpy(d_input + i * img_size, h_input + i * img_size, img_size, cudaMemcpyHostToDevice);
}

// 推荐：一次性传输
cudaMemcpy(d_input, h_input, batch_size * img_size, cudaMemcpyHostToDevice);

4.4.2 异步传输与计算重叠

GPU计算和PCIe传输可以同时进行。使用CUDA流（Stream），把传输和计算放到不同的流里。GPU在计算当前批次时，后台已经在传输下一批次的数据了。

cudaStream_t stream1, stream2;
cudaStreamCreate(&stream1);
cudaStreamCreate(&stream2);

// 流1：传输数据
cudaMemcpyAsync(d_input, h_input, batch_size * img_size, cudaMemcpyHostToDevice, stream1);

// 流2：执行推理（与传输重叠）
inference_kernel<<<grid, block, 0, stream2>>>(d_input, d_output);

cudaStreamSynchronize(stream1);
cudaStreamSynchronize(stream2);

我的习惯：我会用3-4个流做流水线。一个流传数据，一个流算，一个流传结果回来。这样PCIe带宽和GPU算力都能跑满。但要注意，流太多会增加显存占用，得权衡。

4.4.3 使用固定内存（Pinned Memory）

默认的malloc分配的内存是分页的，GPU访问时需要先锁定页面。用cudaHostAlloc分配固定内存，可以跳过这个步骤，传输速度能提升2-3倍。

float* h_input;
cudaHostAlloc(&h_input, batch_size * img_size, cudaHostAllocDefault);
// 使用固定内存传输
cudaMemcpy(d_input, h_input, batch_size * img_size, cudaMemcpyHostToDevice);

注意：固定内存不能分配太多。系统物理内存是有限的，分配太多会导致其他进程内存不足。我一般控制在总内存的10%-20%以内。

4.4.4 零拷贝（Zero-Copy）

对于某些场景，可以让GPU直接访问CPU内存，省掉显式拷贝。但零拷贝的访问速度比显存慢很多，只适合数据量小、访问次数少的场景。

float* h_input;
cudaHostAlloc(&h_input, img_size, cudaHostAllocMapped);
// GPU直接访问h_input，无需拷贝

4.5 实战案例：一个OCR服务的优化

我记得有一次优化一个OCR服务。原始实现是：CPU读取图片 -> 预处理 -> cudaMemcpy -> GPU推理 -> cudaMemcpy回 -> CPU后处理。延迟大约50毫秒。

我做了三件事：

  • 把输入从JPEG解码后直接放到固定内存，省掉一次内存拷贝。
  • 使用异步传输，让GPU计算和PCIe传输重叠。
  • 把后处理也搬到GPU上，省掉结果回传。

最终延迟降到了18毫秒。其中PCIe传输从原来的8毫秒降到了不到2毫秒。

嗯，这就是PCIe优化的威力。说白了，你算力再强，数据送不进去也是白搭。下一章咱们聊聊显存碎片化的问题，那又是一个大坑。

← 上一章 📖 返回目录 下一章 →