3. 混合架构概述：CPU+GPU+NPU异构计算模型

各位同学，今天我们来聊聊混合架构。说白了，就是让CPU、GPU、NPU这三个性格迥异的家伙在一起好好干活。我刚开始接触异构计算时，也觉得不就是把任务分一分嘛，后来踩了不少坑才明白——这里面的门道，远比想象中深。

3.1 为什么需要混合架构？

先看一个现实问题。HDR融合算法，单帧处理就要做多次曝光合成、色调映射、去鬼影。你用CPU跑，精度高但慢；用GPU跑，并行快但有些逻辑分支效率低；用NPU跑，能效比好但灵活性差。

那怎么办？

让它们各干各的擅长的事。我在一个手机影像项目中，就遇到过这样的场景：

• CPU：负责控制流、调度、预处理逻辑
• GPU：负责像素级并行计算、矩阵运算
• NPU：负责固定模式的神经网络推理、去噪

你想想看，如果只用一种处理器，要么性能不够，要么功耗爆炸。混合架构，就是找到那个最优解。

3.2 CPU+GPU+NPU 异构计算模型

我习惯把异构计算模型分成三层来看：

层级	处理器	典型任务	特点
控制层	CPU	任务调度、内存管理、异常处理	灵活、低延迟、单线程强
计算层	GPU	像素处理、矩阵乘法、滤波	高吞吐、SIMT、适合数据并行
推理层	NPU	CNN推理、去噪、超分	高能效、固定流水线、低精度

这里有个关键点：数据流怎么走。我记得第一次做异构流水线时，没注意数据拷贝开销，结果GPU算得飞快，但数据搬运占了60%的时间。嗯，这就是典型的"木桶效应"。

3.3 OpenCL 与 Vulkan 基础

说到异构编程，绕不开两个框架：OpenCL和Vulkan。它们都能让CPU调度GPU/NPU干活，但设计哲学完全不同。

3.3.1 OpenCL：老牌通用计算框架

OpenCL的优点是什么？跨平台。你写一份代码，能在AMD、Intel、ARM上跑。但缺点也很明显——API太啰嗦。我早期做OpenCL开发时，光初始化就要写几十行代码。

一个典型的OpenCL流程：

// 1. 获取平台和设备
cl_platform_id platform;
cl_device_id device;
clGetPlatformIDs(1, &platform, NULL);
clGetDeviceIDs(platform, CL_DEVICE_TYPE_GPU, 1, &device, NULL);

// 2. 创建上下文和命令队列
cl_context context = clCreateContext(NULL, 1, &device, NULL, NULL, NULL);
cl_command_queue queue = clCreateCommandQueue(context, device, 0, NULL);

// 3. 编译内核
const char *kernelSource = "__kernel void hdr_fusion(...) { ... }";
cl_program program = clCreateProgramWithSource(context, 1, &kernelSource, NULL, NULL);
clBuildProgram(program, 1, &device, NULL, NULL, NULL);
cl_kernel kernel = clCreateKernel(program, "hdr_fusion", NULL);

// 4. 设置参数、执行
clSetKernelArg(kernel, 0, sizeof(cl_mem), &input);
clEnqueueNDRangeKernel(queue, kernel, 2, NULL, globalSize, localSize, 0, NULL, NULL);
clFinish(queue);

你看，光是准备工作就这么多。但好处是，一旦跑起来，性能很稳定。

3.3.2 Vulkan：新一代高性能接口

Vulkan最初是为图形设计的，但它的计算管线也很强。相比OpenCL，Vulkan更"薄"——你直接控制GPU的每一步。

我个人的感受：Vulkan的学习曲线更陡，但性能上限更高。尤其是在显存管理和多队列并发上，Vulkan给了开发者更大的自由度。

一个简单的Vulkan计算管线：

// 1. 创建实例、选择物理设备
VkInstance instance;
VkPhysicalDevice physicalDevice;
// ... 初始化代码

// 2. 创建逻辑设备、命令池
VkDevice device;
VkCommandPool commandPool;
// ... 创建设备

// 3. 创建计算管线、描述符集
VkShaderModule shaderModule;
VkPipeline pipeline;
// ... 编译着色器

// 4. 提交命令
VkCommandBuffer commandBuffer;
vkBeginCommandBuffer(commandBuffer, &beginInfo);
vkCmdBindPipeline(commandBuffer, VK_PIPELINE_BIND_POINT_COMPUTE, pipeline);
vkCmdDispatch(commandBuffer, groupCountX, groupCountY, groupCountZ);
vkEndCommandBuffer(commandBuffer);

// 5. 提交到队列
VkSubmitInfo submitInfo = { ... };
vkQueueSubmit(queue, 1, &submitInfo, VK_NULL_HANDLE);
vkQueueWaitIdle(queue);

代码量差不多，但Vulkan让你能精细控制每一帧的提交、同步和内存。

3.4 内存带宽瓶颈分析

这是混合架构里最容易被忽视的问题。你想想看，CPU、GPU、NPU各自有独立的内存空间，数据要来回搬运。而内存带宽，就是这条高速公路的限速。

我做过一个测试：在某个嵌入式平台上，GPU算力是CPU的10倍，但内存带宽只有CPU的3倍。结果呢？GPU大部分时间在等数据，实际加速比只有2倍左右。

带宽瓶颈的几个典型场景：

• 多帧输入：HDR需要3-5帧不同曝光的图像，每帧都是4K分辨率，一次搬运就是几十MB
• 中间结果：融合过程中产生的临时缓冲区，比如权重图、对齐偏移量
• NPU权重：神经网络模型参数，动辄几MB到几十MB

怎么优化？我分享几个实战经验：

1. 尽量复用缓冲区：不要每步都申请新内存，用ping-pong buffer
2. 减少CPU-GPU拷贝：能用GPU直接处理的数据，就别经过CPU
3. 使用异步传输：计算和拷贝重叠，隐藏延迟
4. 考虑内存压缩：有些平台支持硬件压缩，比如ARM的AFBC

3.5 混合架构的典型数据流

下面这张图，是我在项目中常用的HDR融合异构流水线。你可以看到数据是怎么在CPU、GPU、NPU之间流转的。

你看，数据从CPU出发，经过GPU处理，再到NPU做精细化处理，最后回到CPU做校验和输出。每一步都尽量在本地处理，减少跨芯片搬运。

3.6 实战中的选择建议

最后，我根据实际项目经验，给几个选择建议：

场景	推荐方案	理由
快速原型验证	OpenCL	跨平台、调试方便、社区成熟
高性能产品	Vulkan	精细控制、低开销、适合多队列
低功耗设备	NPU + 定制驱动	能效比最高、但灵活性差
混合方案	Vulkan + NPU扩展	兼顾性能与能效、但开发周期长