ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

CPU、GPU、TPU怎么选?一文读懂算力芯片的分工与实战

CPU、GPU、TPU怎么选?一文读懂算力芯片的分工与实战 先说明一件事这三个缩写放在一起本身就是在讲算力到底从哪来的问题。无论你是刚装完PyTorch发现安装包还分CPU版和GPU版的新手还是被老板一句租个带GPU的服务器搞得一头雾水的实习生又或者只是好奇为什么老听人说TPU能跑大模型这篇文章都能给你一个相对完整的答案。我尽量用干活的思路来讲而不是从计算机组成原理教科书开始抄。这些年我经手过不少算力相关的项目早期折腾深度学习时也在CPU上硬跑过模型后来逐步接触到GPU集群再后来因为比赛和微调任务白嫖过Google的TPU算是把这三类芯片都踩过一遍。说实话CPU、GPU、TPU之间的区别并不在于谁比谁更强而在于它们各自被设计出来解决什么问题。搞清楚这一点很多选型上的纠结会立刻消失。1. 三种芯片先认识一下很多时候我们把芯片当成一个黑盒子觉得CPU是电脑的大脑GPU是打游戏用的TPU是训练AI专用的这样理解没错但太粗糙了。为了让后面的实操不悬空我们先把这三兄弟的本质分工聊透。1.1 CPU什么都能干的总指挥CPU的核心思路是通用。它要面对的操作极其复杂从操作系统调度、内存管理到数据库查询、压缩解压几乎什么活都得干。为了做到什么都能干CPU里塞了大量控制单元负责指令译码、分支预测、乱序执行还有复杂的分级缓存体系。所以CPU的逻辑控制能力非常强能把乱成一团的任务拆解成一条条有序的指令序列并且每一步都能根据上一步的结果动态决定下一步做什么。你可以把CPU想成一个脑子转得极快、但只有一个人手的总指挥。它手里拿着复杂地图每走一步都能思考下一步怎么走最优问题的关键是一个时间点基本只能处理一条指令流现在消费级CPU也就8个、16个物理核心再算上超线程能同时跑的任务数量依然很有限。对于顺序性强、逻辑复杂、每步都依赖前一步结果的任务CPU是毫无疑问的王者。日常生活中的绝大多数场景比如开浏览器、写文档、跑Node服务、操作数据库都属于这类逻辑密集型的串行任务所以CPU至今仍是电脑里最核心的计算单元这也是CPU是整个PC的大脑这个说法成立的原因。1.2 GPU跑并行计算的劳模GPU的思路和CPU完全不同。它生来就是为了处理大量可以被并行拆分的运算最典型的就是图形渲染屏幕上有几百万个像素点每个像素的颜色计算相互独立这简直是为并行计算量身定做的场景。为了同时处理海量像素GPU把大量计算单元在NVIDIA体系里叫CUDA核心在AMD体系里叫流处理器堆在一起靠数量取胜动不动就是几千个核心。一个很形象的比喻GPU像一个拥有几千号人的流水线工人团队。每个工人的数学计算能力其实不算特别强单个处理速度可能还没有CPU快但架不住人多而且做的是同一种重复劳动几千个人同时开工吞吐量直接爆表。现代GPU除了做图像渲染也被大量应用于矩阵运算、科学计算、机器学习训练等任务。神经网络训练的本质就是大量矩阵乘法和卷积运算这些运算天然可以被拆成非常细的并行子任务GPU正好能满足这种需求。所以GPU从游戏显卡逐渐变成了AI计算的中坚力量。1.3 TPU只认矩阵的专用打工人TPU是Google为了解决自家深度学习推理和训练需求专门设计出来的定制化专用芯片。它的名字Tensor Processing Unit张量处理单元已经说明了一切它的核心任务就是张量运算而这几乎完全围绕矩阵乘法和累加展开。你可以把TPU理解成一条为了做同一道菜而专门改造的流水线。CPU能做的菜很多GPU能做蒸煮炒炸一大类而TPU几乎只会做你给它设定的那一道菜——矩阵运算。但因为这道菜在所有大模型训练里占据了绝对主导的计算量所以TPU可以通过极端的专门化设计在功耗和面积预算内堆出惊人的算力。一个典型的例子是Google TPU v3。单颗芯片的BF16算力高达420 TFLOPS这在同时期的GPU上是难以想象的指标。它能在深度学习任务中表现出色主要归功于两个设计第一脉动阵列Systolic Array结构让数据在计算单元阵列里像流水一样有序流动大幅减少反复搬运数据的开销第二支持低精度计算比如BF16格式既保证了训练精度又大幅提升吞吐量。当然有得必有失。TPU只能在神经网络训练和推理这类任务上发挥巨大威力一旦让它去跑数据库查询或者处理复杂的逻辑分支性能和通用性会非常惨。它是一把专为某个钉子准备的锤子打其他东西基本都不顺手。维度CPUGPUTPU核心设计目标通用逻辑处理并行浮点计算矩阵/张量专用运算核心数量4-64个上千至数万个脉动阵列海量单元单任务处理速度极快主频高单单元一般胜在并行单任务范围极窄算力极高最适合的任务系统调度、逻辑分支、串行计算图形渲染、AI训练、科学计算大规模深度学习训练/推理采购成本模式已包含在电脑里独显几万到几十万基本不零售云上按小时计费典型代表Intel酷睿/至强、AMD锐龙/EPYCNVIDIA RTX/A100/H100Google TPU v5e/v42. 为什么AI大潮把GPU和TPU推上了台面如果你只看规格书可能会觉得GPU核心数多但单个核心能力弱凭什么AI训练就得靠它其实原因可以归结为一句简单的话AI训练里绝大多数时间都花在矩阵乘法上而矩阵乘法是天然可以大规模并行的任务。但要让这种并行真正发挥效率还牵扯到硬件架构、软件生态、内存带宽等多个层面。2.1 从渲染、挖矿到大模型GPU的逆袭路径GPU最早只是为图形而生的但在发展过程中硬件厂商发现图形渲染需要的矩阵运算、SIMT并行模型和通用科学计算中的需求高度重合。于是NVIDIA在2007年推出了CUDA直接打开了一个新世界的大门。从那时起GPU不再是单纯的显卡而成了通用计算卡。后来的剧情大家都很熟悉比特币挖矿潮让GPU全网一卡难求深度学习热潮更是让GPU成为训练AI模型的标配。每次大模型发布背后都是几千张A100/H100在跑。为什么会这样因为Transformer架构的无论是自注意力机制还是MLP层本质上都是在做大规模的矩阵乘法和通道之间的张量变换。GPU强大的并行吞吐能力恰好能把训练时间从几年压到几周。GPU也不只解决了算力问题还解决了谁来写代码的问题。CUDA生态的成熟度是其他任何计算平台都难以企及的从PyTorch、TensorFlow到各类推理引擎几乎都有一个默认的CUDA后端。开发者写一套代码只要机器上有NVIDIA显卡就可以无缝跑起来这种生态优势非常重要。很多人觉得GPU只是硬件比较强实际上它真正的护城河在于CUDA软件生态。2.2 TPU的登场它不是在跟GPU比而是在跟矩阵运算比Google在2016年发布第一代TPU的时候目标很明确降低运行自己服务所需的算力成本。当时的阶段TPU主要是用来做推理2017年之后推出的TPU v2、v3则进一步支持训练并且做成Pod形式可以让多个TPU卡通过高速互联组成大规模集群。有一个很有意思的细节TPU并不直接支持所有神经网络算子它将整个算子图编译成可以在脉动阵列上运行的矩阵乘法序列。所以当你用PyTorch或JAX写一个模型时需要专门针对TPU做一些适配比如避免某些GPU上常见的动态形状算子、自定义kernel等。很多人第一次在Kaggle上免费使用TPU跑模型失败就是因为代码里混入了GPU特有的逻辑。为什么Google愿意花大钱做TPU因为在大规模神经网络训练中矩阵乘法占的比例实在太高了。用TPU这种专用芯片在相同功耗和成本的条件下能获得远超通用GPU的算力这对Google这种超大规模AI业务的成本控制至关重要。TPU的成功也带动了一批NPU、AI ASIC加速卡的繁荣本质逻辑都一样放弃通用性追求单一目标的最大化性能。2.3 三者怎么分工预算有限时怎么选很多人在买电脑、租服务器时都会纠结到底该把钱花在CPU上还是GPU上我的建议是不要只看单一维度而是看你日常运行的负载是什么类型。只是想跑轻量级推理、处理数据、做代码开发普通CPU完全够用GPU更多是锦上添花。要训练中小型模型或者做科学计算、渲染GPU才是核心算力来源CPU只需要保证数据喂得够快、不会拖后腿就行。考虑在云端大规模训练大模型这时候CPU往往也要跟着升级因为数据预处理、分布式数据加载都依赖CPU。需要特别提醒一点不要为了省预算买很老的服务器CPU配一张很新的高端GPU。因为CPU性能太弱处理不了数据加载GPU会在每个step之间长时间空转。很多人说GPU占用率上不去排查半天发现瓶颈在CPU数据加载上这种案例太常见了。如果要租用或选购GPU服务器别只盯着显存大小还要关注显存带宽、GPU架构代数、卡间互联比如NVLink、内存通道数。比如同样是24GB显存的卡专业计算卡和游戏卡在训练上的表现差距极大因为专业计算卡在ECC内存、显存带宽、低精度算力上往往有硬优势。天梯图可以当参考但最好还是拿你真实要跑的模型去实测一下。3. 从PyTorch到深度学习一套代码怎么在三种芯片上跑起来理论聊再多不如实际跑一次。这章我带大家从深度学习最常用的框架PyTorch出发看看同一份代码切换CPU、GPU、TPU的完整过程和踩坑点。3.1 装PyTorch时CPU版和GPU版到底差在哪如果你上PyTorch官网安装页面会看到安装命令里有一行--index-url https://download.pytorch.org/whl/cu118之类的参数也有纯CPU版命令。很多新手不理解我机器上没NVIDIA显卡但为什么官方默认命令下载的安装包会那么大因为默认安装包从头到尾都是为CUDA环境准备的它打包了和CUDA运行时相关的各种库即使你机器上只有一个CPU安装后也会提示CUDA不可用但整个包会白白占用大量磁盘空间。如果你确定自己一辈子用不上CUDA只想在CPU上跑PyTorch建议直接装CPU版本体积小启动加载也更快。不过要说明的是CPU版和GPU版的代码是同源的API接口完全一致只是后端是否有CUDA算子的区别。如果你不确定以后会不会换GPU机器装默认的CUDA版也没有问题只要检测到GPU就能自动切换。再说一个特别常见的追问在GPU上训练的代码和CPU上训练的代码有没有区别答案是没有本质区别。PyTorch已经封装好了设备转换import torch if torch.cuda.is_available(): device torch.device(cuda) else: device torch.device(cpu) model MyModel().to(device) data data.to(device)只要保证模型、输入数据都切换到同一个device上逻辑完全一样。很多新手报错CUDA error: device-side assert triggered往往就是因为数据没挪到GPU上或者前向传播输出的张量仍在CPU而在GPU上计算梯度时两个设备对不上。3.2 在Kaggle上白嫖TPU跑一次微调Kaggle上每个账户每周都有几十小时的GPU和TPU免费额度其中TPU是很多打比赛的人最喜欢薅的羊毛。TPU在Kaggle上通常是TPU v3-8也就是8张TPU v3芯片共享同一个主机内存系统算力非常可观远高于免费的GPU。但问题在于TPU并不默认被PyTorch支持需要额外安装PyTorch/XLA这个中间层。装好后代码逻辑就变成了这样import torch import torch_xla import torch_xla.core.xla_model as xm if xm.is_master_ordinal(): print(TPU is available) device xm.xla_device() model MyModel().to(device) # 训练循环里除了常规的loss.backward()还需要增加一步 xm.optimizer_step(optimizer)如果你直接在TPU上跑GPU写好的训练循环会遇到一个很尴尬的现象每个step似乎能跑起来但速度极慢或者直接OOM。深层原因是XLA编译器在编译阶段就要把模型计算图完整整定为能在TPU上运行的指令序列如果图中间混入了一些不支持的算子比如动态shape操作、某些非矩阵化的自定义函数就会触发fallback到CPU逻辑导致整体速度大幅下降。我在一次Kaggle比赛里用TPU微调一个小型Transformer第一版代码几乎和GPU版本一模一样结果发现loss下降极慢。后来逐个排查发现有一个torch.topk算子触发了XLA fallback。把它替换成argmax之后速度立刻恢复了。所以如果你想用TPU跑模型建议把关注点放在算子图是否TPU友好上而不是模型的浮点计算量。3.3 数据加载与设备切换的实战代码一套靠谱的训练脚本应该把设备检测、数据搬移、模型初始化都拆成独立模块方便切换硬件时有清晰的处理位置。分享一个我常用的模板思路import torch from torch.utils.data import DataLoader def get_device(): if torch.cuda.is_available(): return torch.device(cuda) try: import torch_xla return torch_xla.core.xla_model.xla_device() except Exception: return torch.device(cpu) device get_device() def collate_fn(batch): # 在整理batch时就提前把设备切换好减少后续搬运开销 xs torch.stack([x for x, y in batch]).to(device) ys torch.tensor([y for x, y in batch]).to(device) return xs, ys loader DataLoader(dataset, batch_size32, collate_fncollate_fn, num_workers4)这里num_workers4特别值得说。在GPU或TPU训练时数据加载器的多进程可以并行做图片解码、增强、格式化等预处理。否则GPU算完一个batch后要空等CPU把下一个batch准备好这会导致GPU利用率出现明显周期性下降。很多人观察GPU占用率不高但训练很慢问题往往就出在数据加载端。4. 常见的以为坏了其实是正常的排查实录每天都会有人对着任务管理器里的CPU占用率、GPU显存占用数据抓狂也会有人跑着收集任务时看到一堆看起来像报错的信息不知所措。这部分我挑几个搜得最多的实际问题展开讲一下。4.1 CPU占用高dcom、wmic、AVX错误这几个坑先说服务主机DCOM占用CPU高怎么解决。Windows服务主机svchost.exe里的DCOM分布式组件对象模型是一个历史遗留组件负责在不同进程间分发调用。占CPU高通常有几个原因某个废弃的COM组件反复尝试启动权限配置错误导致系统每几秒就要重新校验授权或者某个第三方例程在后台疯狂注册COM对象。排查思路其实不复杂。打开事件查看器在Windows日志-系统里筛选来源为DistributedCOM的记录找到报错消息里的CLSID和APPID然后在注册表HKEY_CLASSES_ROOT\CLSID\{你的CLSID}里看这个组件属于哪个程序把来源程序卸载或修复掉就可以解决。别一上来就关闭DCOM服务那样系统会不稳定。再说一个很多人踩过的新坑Windows 11或部分较新版本的Windows Server里执行wmic cpu get processorid会直接报一个Cannot run program wmic之类的错误。这不是系统坏了而是新版Windows默认不再自带WMIC命令行工具改用PowerShell路径了。替代命令是Get-CimInstance Win32_Processor | Select-Object ProcessorId顺便说一句如果你在用某个自动化脚本直接调wmic在Java里最容易遇到问题。ProcessBuilder虽然接受字符串数组作为命令参数但你传wmic cpu get processorid /value整个字符串进去是没法执行的得拆成new String[]{wmic, cpu, get, processorid, /value}或者干脆换成兼容性更好的PowerShell命令。还有一个高频报错是Cell Ranger error: this CPU does not support AVX, which is required。这跟芯片本身完全没关系是软件编译时假定CPU支持AVX指令集而老CPU不支持。检查一下自己的CPU型号如果实在没有AVX就只能换机器或者找软件作者要旧版编译包。4.2 GPU和CPU内存占用都不高但训练就是卡这是我在很多训练任务里遇到过的经典场景用nvidia-smi看显存没满CPU占用也只有20%但训练loss跑得像乌龟爬。这个现象的核心原因是计算瓶颈根本不在这两块可见的资源上。最常见的隐藏瓶颈是数据加载开销过大。有些模型每个样本需要做大量图像解码、归一化、增强虽然CPU整体占用不高但主线程里单个step的耗时极长。此时哪怕GPU很快也只能干等着。解决办法一是增加num_workers让数据预处理并行化二是检查CPU缓存命中率如果内存只有8GB而数据加载需要大量随机读可能频繁缺页。第二个隐藏瓶颈是GPU kernel启动开销。如果你的模型很小batch size也很小GPU每次执行一个kernel都需要提交、启动这种调度开销可能比kernel本身执行时间还长结果就是GPU几乎都在等调度。解决办法是增大batch size或者用CUDA Graph把多个kernel合并成一个图减少启动次数。第三个容易被忽略的是PCIe带宽。尤其你用外接显卡或者在虚拟机里直通GPU时PCIe通道数不足会导致CPU往GPU搬运参数的延迟大幅升高。可以跑一个小测试把同一份网络在PCIe x1和x16上对比下训练step时间差距会很明显。4.3 看天梯图、跑压力测试如何科学评估算力经常有人拿服务器CPU天梯图来比较不同类型的处理器比如看Intel至强和AMD EPYC怎么选。说实话天梯图只是一个模糊的分数参考它无法反映真实负载下的表现。比较靠谱的做法是直接跑你做实际业务的负载测试。比如你搞编译那就编译同一个项目看时间搞数据库那就跑基准测试搞AI那就用你真实的模型和batch size跑几个epoch看耗时。如果你拿到一台GPU服务器想快速确认GPU是不是正常、散热和频率有没有问题可以跑一下gpu-burn压力测试工具。使用方法很简单git clone https://github.com/wilicc/gpu-burn cd gpu-burn make ./gpu_burn 60这个工具会跑一个持续一分钟的高负载计算把GPU的算力顶满。你能在nvidia-smi里看到显卡温度、功耗、风扇转速迅速拉升。如果跑到中途出现死机、报错、温度过高等说明这块卡或者散热系统有问题。我还常用几个实用命令来快速定位用到了哪块GPU# 列出所有GPU基本信息 nvidia-smi -L # 查看每张GPU的型号、显存、进程占用 nvidia-smi # 更精细地查看占用进程PID nvidia-smi --query-compute-appspid,process_name,used_memory --formatcsv很多人在多卡机器上跑模型发现某张卡占满了另一张卡闲置想确认自己用的是哪张卡可以看环境变量CUDA_VISIBLE_DEVICES。在代码里你也可以随时打印import torch print(torch.cuda.current_device()) print(torch.cuda.get_device_name(torch.cuda.current_device()))4.4 手机CPU虚焊会自愈吗这个问题真的别再信了有一个搜索热词让我有点哭笑不得手机CPU虚焊会自愈吗。虚焊的本质是焊点出现物理断裂芯片和主板之间接触不良。有些场景下温度升高焊点热胀冷缩可能偶尔恢复接触所以机器会表现成有时能开机有时不能开机好像自己好了。但虚焊不会真的自愈它只会随着使用和温度变化反复复发最后彻底断掉。正确的处理方式是补焊专业点叫重植锡球或BGA返修需要加热台、植锡网、锡膏等工具不建议普通人自己动手。如果你手机还在质保期直接送修最好。这个话题虽然不算CPU/GPU/TPU的技术主流但它确实属于芯片硬件故障排查的范畴很多人搜到它才来了解芯片知识所以顺便讲清楚。5. 实际选型与资源规划别再盲目堆配置了聊完硬件原理和排查方法最后说说选型这件事。不管是个人装电脑还是公司采购服务器很多人都会犯参数焦虑的毛病觉得核心数越多越好显存越大越好。但实际干起活来不一定匹配你的任务形态。5.1 个人开发与学习场景的配置建议如果你是学生或者独立开发者主要跑一些中小规模的模型训练与推理我的建议是别一上来就考虑买顶配卡。先把自己的任务需求量化模型参数量、训练数据量、batch size要求。比如你只是想微调一个7B的LoRA模型那么24GB左右的显存已经完全够用再往上追大显存边际收益远低于钱包消耗。CPU方面与其追求顶级核数不如关注单核性能和内存带宽。很多AI场景CPU部分主要在跑数据加载和预处理这类任务对单核性能相对敏感。我自己的经验是一套稳定的AMD锐龙平台配64GB内存再加一张24GB显存的卡能覆盖绝大部分中小型深度学习任务。租用服务器也是同样的逻辑。现在云服务商提供各种GPU云服务器比如租一台带A10或A100的实例来做微调关键要搞清楚它到底允许多大batch size、能否满足分布式训练需求、存储IO是否跟得上。不要只看多少张卡要问清楚卡间互联带宽是多少因为很多微调任务都要频繁同步梯度。5.2 集群规模的规划思路如果你负责的是好几台GPU服务器的集群运维这时候重点就不只是单卡性能了还包括调度、网络、存储这些外围设施。我见过太多团队在买了高配GPU后因为网络带宽不够导致分布式训练效率极低甚至比不上单卡训练。分布式通信每轮同步梯度如果卡间走的是低带宽的普通以太网那你模型同步时间会比计算时间还长。这种场景下要不要加CPU核数要但主要是为了跑数据预处理和分布式调度不是为了参与训练计算。所以集群架构上一般会把存储节点、管理节点、计算节点分开管理节点用中高配CPU加大内存计算节点则尽可能堆GPU和GPU互联带宽。有一个常见的误解是因为“TPU算力比GPU强”所以只要能用Google TPU就比GPU好。但TPU在云上的使用模式非常独特租用价格虽然按小时计费但每个轮次是按TPU Pod为单位租赁的不是一张卡能随便租着玩。Kaggle那种免费TPU更适合固定时长的小规模微调。如果你只是做一次简单的GPU推理服务老老实实租GPU服务器反而是最高效的方案。5.3 重点关注软件栈的适配程度我最后想强调的其实是软件栈的问题。选芯片不只是选硬件更是选生态。CPU的生态自不必说任何操作系统和语言都支持。GPU领域NVIDIA的CUDA生态异常成熟几乎所有AI框架默认支持。TPU、昇腾这些专用加速卡计算能力虽然强大但很多开源软件的支持并不如CUDA那么顺滑。比如华为昇腾芯片它本质上是一款面向AI计算的专用加速芯片和TPU的设计思路有相似之处。虽然现在有一些适配框架但如果你要在上面跑Stable Diffusion或者其他PyTorch生态的模型很可能需要专门写适配代码甚至要等上游框架贡献者慢慢提供官方支持。所以做技术选型时我会优先问一句话我想跑的代码在这个硬件上有没有现成的、稳定的运行路径我自己在本地折腾过一个旧项目代码完全依赖CUDA的某个扩展库换到某NPU加速卡上就完全跑不了。后来只能把这块NPU当作纯推理设备训练还是在GPU上做推理才在NPU上跑。这个折中方案能跑但开发效率和团队协作复杂度高了不少。如果你想省心选NVIDIA是最稳妥的默认选项除非你有明确的特定场景和对应的软件适配能力。6. 写在最后算力选择的本质是匹配问题我常对刚入门的朋友说CPU、GPU、TPU到底哪个更好真的不存在一个通用答案。它们对应的是不同的计算模式、不同的软件生态、不同的成本结构。CPU像一位全能管家什么杂事都能处理好GPU像一个庞大的工人编队特别适合重复性的并行劳动TPU则是一条需要专门设计的、只加工特定半成品的流水线。搞清楚你手头的任务属于哪一类你就知道该向谁求助了。我个人在实际项目中的体会是很多时候项目的瓶颈不在单卡算力而在于数据、网络、软件适配这些看不见的旁边。所以做技术选型时一定把自己真实要跑的负载原封不动地搬上去试一遍别只被参数表和天梯图忽悠。最后再分享一个非常实用的小技巧当你听到别人说这卡能跑多少TFLOPS的时候先问一句这个算力是在什么精度下测的、有没有算稀疏加速。因为不同精度下的算力数字天差地别没有这些前提的算力对比本质上是无效对比。想清楚这一点你在选型时就能少踩不少坑。
返回列表