核心判断只有一句可并行 算术强度够 → GPU否则 → CPU。全文都是在拆解这一句话背后的原因。① 为什么重要先定动机后面的学习才用得对你打算花几十篇去学 Kernel、内存层级、Roofline、FlashAttention但在写第一行__global__之前必须先回答一个问题GPU 到底凭什么快如果答案是核多、频率高后面的学习会一直被这个错误心智带偏——你会以为所有计算搬上 GPU 都变快于是在根本不适合并行的任务上强行写 kernel最后发现比 CPU 还慢。这一篇要给你的是一个能贯穿整个学习过程的判断框架什么时候该用 GPU什么时候它反而会拖后腿。它的根不在GPU 有什么而在一个不可改变的硬件约束——下面展开。② 一份晶体管预算两种花法一块芯片的晶体管数量是有限的。这笔预算怎么分配决定了它是CPU 性格还是GPU 性格CPU把大量晶体管投在单线程延迟优化上——大容量多级缓存、乱序执行、分支预测。目标是让一个任务尽快完成。GPU把晶体管的大头投向计算单元ALU / CUDA Core控制逻辑相对精简。目标是让一大批相似任务在单位时间内完成得最多。这里说精简是相对 CPU 而言不是没有——H100 这类芯片仍有数十 MB 的 L2 Cache只是它服务的是合并访存和数据复用而不是像 CPU 那样为单线程做深度预测和乱序调度。打个比方如果把芯片比作一家公司CPU 把预算大量花在管理层缓存、预测器、调度器上GPU 则把预算大量拿去招一线工人ALU。GPU 同时干活的人更多但每个人更专一——擅长简单重复运算遇到复杂判断就容易卡壳。物理上芯片面积和功耗都随晶体管数超线性增长——多放一个 ALU就要少放一点缓存和控制逻辑。这不是工程师的偏好是物理约束。由此得到的关键结论GPU 的快是吞吐不是延迟。同一个向量加法GPU 上单个元素的结果可能比 CPU 还晚出来要等 kernel 启动、线程调度但单位时间内它能处理的元素总量是 CPU 的上百倍。只看 TFLOPS 选卡是只见树木——后面你会发现带宽往往才是更常见的瓶颈。也正因为这一点GPU 比 CPU 快这句话在多数场景下是不准确的。GPU 只在可并行 算术强度高的负载上碾压 CPU一旦任务串行、分支多、数据依赖强GPU 精简的控制逻辑反而成了劣势。③ 最小实现把吞吐思维落在一段代码上上图是抽象比喻下面这张是 CUDA Programming Guide 给出的真实硬件结构左侧 CPU 只有几个核加内存控制器右侧 GPU 由 GPC 组织起大量 SM每个 SM 内再含众多功能单元——这正是面积换吞吐的硬件落点。一个最小并行例子向量加法// GPU 思维每个线程只负责一个元素N 个元素被 N 个线程并发处理__global__voidvector_add_kernel(constfloat*a,constfloat*b,float*c,intn){// 用 Block 坐标、Block 尺寸和线程局部坐标计算全局索引intiblockIdx.x*blockDim.xthreadIdx.x;// 线程总数可能大于数据长度必须阻止越界访问if(in){// 当前线程只计算第 i 个元素c[i]a[i]b[i];}}关键差别CPU 版本是一个for (i0; iN; i)挨个算GPU 版本没有循环——循环被线程并行消解了。可以用一句话概括 N100 万个元素时的差异CPU 是一个人跑 100 万步GPU 是100 万个逻辑线程并发跑完各自的 1 步。要注意这100 万个线程不是 100 万个物理执行单元同时点亮——一块 GPU 实际的 CUDA Core 数量是几千到一万多个量级它靠warp 调度器把海量逻辑线程分批、高速切换着送进有限的物理单元执行。这也是为什么核多这个说法本身不够精确GPU 的核和 CPU 的核不是同一量级的概念真正起作用的是调度海量线程覆盖延迟这套机制后续文章会正式拆开。100 万个线程怎么组织CUDA 用层次结构切分blockIdx.x * blockDim.x threadIdx.x就是这套层次算出的全局索引——后面文章会正式拆开 Grid / Block / Thread 与 warp 的关系以及物理 SM 如何承接这些逻辑线程。这是最小实现的意图在学 SM / warp / shared memory 之前先对并行建立一个能跑起来的直觉。正式的第一个可编译程序在后续的《Hello CUDA》入门文章中。④ 工业应用吞吐架构撑起的日常你每天用的 AI 能力底层都是 GPU 的吞吐架构在扛AI 训练 / 推理矩阵乘GEMM是典型海量同构、算术强度高的负载正好是 GPU 的主场科学计算气候模拟、分子动力学本质是大规模网格上的同构更新图形与渲染每个像素独立着色天然并行。反过来如果任务是读配置文件 → 按规则决策 → 串行调用几个 API这类控制流重、并行度低的活GPU 在这里没有用武之地用 CPU 或普通服务更划算。⑤ 一个容易踩的坑Amdahl 陷阱加速比的上限由串行部分占比决定。一个串行占 10% 的任务无论堆多少张 GPU理论加速顶多逼近约 10 倍不少人把这类任务盲目丢上 GPU结果被 kernel 启动开销和显存拷贝反噬反而比 CPU 还慢。GPU 救不了串行。判断一个任务值不值得上 GPU先看它的串行部分占多大比例而不是先看数据规模有多大。⑥ 面试题三道高频题及答题锚点GPU 相比 CPU 的优势和局限是什么优势在大规模同构并行的吞吐局限在单线程延迟、分支处理弱、串行任务反而慢。锚点始终是晶体管预算的延迟/吞吐取舍。为什么 GPU 用大量 CUDA Core而不是像 CPU 那样用少量复杂核心并行负载吃的是总 ALU 数 / 总晶体管精简的控制逻辑无深度乱序、无深度预测能在同一份预算里塞进更多计算单元CPU 式的核心复杂度对并行吞吐是浪费。什么场景 GPU 反而比 CPU 慢低并行度、强分支/控制流、强数据依赖如解析、顺序归约或串行占比高的任务——launch 开销加上数据搬运会抵消并行收益。⑦ 延伸阅读与下一篇Amdahl 定律 vs Gustafson 定律前者说串行部分决定加速上限后者说问题规模随核数放大时并行收益仍可主导。二者合起来解释了为什么大模型训练能靠堆卡堆出接近线性的加速而小任务不行。硬件坐标H100 / A100 / 4090 的 compute capability 与 Tensor Core 差异直接决定你能用哪些编程原语后续文章展开。下一篇《GPU 架构速览SM / SP / Tensor Core 与 AI》——正式打开芯片看 SM 里的 SP 阵列、warp scheduler 和 Tensor Core 到底摆在哪以及它们如何对应你后面要写的每一种 kernel。 收藏CPU vs GPU 决策速查表维度选 CPU选 GPU负载特征串行 / 分支多 / 低并行大规模同构 / 高算术强度优化目标单任务延迟单位时间吞吐数据依赖强依赖、难并行元素独立、可并行典型任务配置解析、调度、控制流矩阵乘、向量化、渲染判断口诀可并行 算术强度够 → GPU否则 CPU。留言区问一句你第一次GPU 比 CPU 慢的坑是在什么场景踩的评论区说说下一篇架构篇我们对照着看根因。