如果你在 C++ 服务端里写过音视频流水线，大概率干过这样的事：为了拯救被滤镜占满的 CPU core，顺手起一个cudaStream_t，把解出来的 YUV 像素 buffer 用cudaMemcpyAsync推进显存，跑完一段看似完美的网格调度，再顺理成章地捞回std::vector或自定义的AVFrame包装类里。这看似是一次教科书级的异构算力加速，但在真实的 4K60p 生产线路上，它是一场彻头彻尾的吞吐灾难。问题根本不在于你的 PTX 寄存器分配是否溢出，也不在于共享内存有没有发生 bank conflict。当一帧 12.4 MB 的 4K NV12 图像在 PCIe 3.0/4.0 总线上来回颠簸时，哪怕你的 GPU kernel 执行耗时是纯粹的 0 毫秒，单帧超过 2ms 的 DMA 阻塞就已经将整条链路的帧率死死钉在了理论天花板之下。把一段 C++ 逻辑扔上 GPU，是一门关于“数据重力”与“算术强度”的算术题。本文以 FFmpeg 生产环境中的.cu算子为切片，穿透 C++ 抽象外壳，从线程束（warp）的硬件拓扑、32 字节对齐的事务合并，一路剖析到 PTX 运行时的 JIT 开销；再拉回音视频全链路——拆解 CABAC 熵解码为何注定是 CPU 指令分支的领地，以及 NVDEC 硬件表面（Surfaces）在显存池化管理下的生命周期争夺。两个数：过总线的字节，和算术强度先把这篇的范围划出来。这里讲的是一条已经在 CPU 上跑通的流水线，要不要搬、搬哪一段到 G