1. 这不是“谁更强”的问题而是“谁该干啥”的分工逻辑CPU和GPU的区别网上太多人用“CPU是总经理GPU是流水线工人”这类比喻听起来生动但实际操作中反而容易误导。我带过不少刚转行的开发者一上来就问“我该换CPU还是换GPU”结果发现连自己跑的是什么任务都分不清——这恰恰说明问题根本不在于参数对比表而在于任务类型与硬件基因的匹配逻辑。核心关键词就三个串行调度能力、并行计算密度、内存带宽拓扑结构。这三个词不是术语堆砌而是你每次选型时真正要掰开揉碎去算的账。比如你训练一个轻量级图像分类模型用RTX 4090可能比用EPYC 9654快3倍但如果你在做高频交易策略回测同样的RTX 4090可能连i9-14900K的一半性能都发挥不出来——不是显卡不行是它的硬件设计压根没为低延迟、强确定性的串行任务优化。这个区别背后是过去二十年芯片设计哲学的根本分野CPU追求的是单线程极致响应哪怕牺牲10%的峰值算力也要把分支预测准确率提上去0.3%GPU追求的是千核协同吞吐效率宁可让单个计算单元闲置20%也要保证90%的ALU单元在同一时刻被喂饱数据。这不是性能高低的问题是设计目标的不可调和。所以这篇文章不列“CPU vs GPU参数对比表”因为那张表对真实项目毫无指导意义。我要带你拆解的是当你面对一个具体任务比如实时视频抠像、三维点云重建、金融风险蒙特卡洛模拟如何从任务特征反推硬件需求再从芯片物理结构验证这个选择是否成立。所有结论都来自我亲手调试过的27个跨领域项目包括某高校实验室的激光雷达SLAM实时建图系统、某工业质检平台的微米级缺陷识别流水线以及三个已上线的边缘AI盒子产品。下面进入正题。2. 架构根源为什么CPU的“大脑”和GPU的“蜂群”天生不同2.1 CPU的“精密钟表”式设计哲学先看一个常被忽略的事实现代主流桌面CPU如Intel Core i9或AMD Ryzen 9的晶体管数量约70%以上被用于构建缓存系统、分支预测器、乱序执行引擎和内存管理单元真正留给ALU算术逻辑单元的面积不到15%。这意味着什么意味着CPU工程师把绝大部分精力花在了“如何让一条指令尽可能快地被执行完”而不是“如何让一万条指令同时跑起来”。举个具体例子当CPU执行if (x 0) { y x * 2; } else { y x 1; }这样的分支代码时它会在x值真正计算出来之前就基于历史模式预测x大概率是正数并提前把y x * 2这条指令的后续步骤加载进流水线。如果预测对了省下至少8个时钟周期如果错了就要清空整个流水线重来——所以CPU的分支预测准确率必须稳定在99%以上否则性能直接腰斩。提示这就是为什么CPU在处理数据库索引查询、编译器语法解析、实时音视频编码中的B帧参考链决策等强分支逻辑任务时GPU永远追不上。GPU没有分支预测器它遇到if-else只能让一半计算单元空转等条件判断结果出来再唤醒——这种“等结果”的行为在GPU架构里叫“warp divergence”是性能杀手。再看缓存设计主流CPU的L3缓存普遍采用inclusive策略即L1/L2缓存内容必须包含在L3中且L3被所有核心共享延迟控制在40ns以内。这种设计让多线程协作时线程A改了一个变量线程B几乎立刻能感知到。但代价是缓存一致性协议如MESIF极其复杂一旦出现缓存行争用性能下降会非常陡峭。2.2 GPU的“蜂群协作”式物理实现GPU的设计思路完全相反。以NVIDIA Ada Lovelace架构为例其GA102核心拥有16384个CUDA核心但只有128KB的L1缓存每个SM单元独享 96MB的L2缓存全芯片共享。注意单位CPU的L3缓存动辄100MB起步而GPU的L2才96MB且访问延迟高达200ns以上。为什么敢这么设计因为GPU默认假设你要处理的数据90%以上是能被提前预取、顺序访问的大块连续内存。比如渲染一帧4K画面GPU知道接下来要读取的像素数据就在显存下一个地址于是提前把整块显存页通常是4KB加载进L2缓存。这种“空间局部性预取”在图形渲染、矩阵乘法、卷积运算中效果极佳但在处理链表遍历、哈希表查找这类随机访存任务时缓存命中率会暴跌到30%以下。更关键的是GPU的线程调度机制。CPU的超线程Hyper-Threading是在单个物理核心上虚拟出2个逻辑核心靠时间片轮转切换而GPU的warp调度是硬件级并发每个SM单元一次加载32个线程一个warp只要这32个线程中有一个准备好执行调度器就立即把指令发下去其他线程继续等数据。这种“有活就干、没活就等”的机制让GPU在面对大量等待显存带宽的任务时依然能保持80%以上的计算单元利用率。注意很多人以为“GPU核心多算得快”这是最大误区。实测过用RTX 4090跑一个纯递归斐波那契数列n45耗时是i9-14900K的7倍。因为GPU根本没有为深度递归优化的栈管理单元所有函数调用都要走全局内存延迟爆炸。而CPU的每个核心都有独立的高速寄存器堆和私有L1缓存递归深度500层都不怕。2.3 内存带宽决定谁能“喂饱”计算单元的咽喉要道这才是区分CPU/GPU真实能力的终极标尺。我们来看一组实测数据来源某工业视觉检测设备实测报告设备显存/内存容量带宽GB/s典型延迟ns适用场景AMD EPYC 96542TB DDR5-480046085大规模内存数据库、虚拟机集群NVIDIA H100 SXM580GB HBM33,95012大语言模型训练、分子动力学模拟Intel Core i9-14900K128GB DDR5-560089.672高频交易、实时音视频编码看到差距了吗H100的带宽是i9的44倍但延迟只高了不到1.5倍。这意味着什么意味着GPU可以容忍更高的访问延迟只要带宽够大就能用“吞吐量”把延迟劣势抹平。就像高速公路CPU是城市快速路路口多、红绿灯密、但每辆车都能精准到达目的地GPU是货运专线没有红绿灯但所有车必须按固定路线、固定批次出发。实际项目中我曾帮某医疗影像公司优化CT图像重建算法。原方案用CPU做FDK算法单帧重建需12秒换成GPU后降到0.8秒提升15倍。但当我们把算法改成更精确的迭代重建SART时GPU加速比骤降到3.2倍——因为SART需要频繁读写中间结果矩阵而GPU的HBM3虽然带宽大但随机访问延迟高导致大量线程在等数据。最终解决方案是用CPU做外层迭代控制保证低延迟响应GPU只负责内层矩阵向量乘发挥高带宽优势混合架构下整体耗时降至0.45秒。3. 实操指南从任务特征反推硬件选型的三步验证法3.1 第一步诊断你的任务“计算密度”与“访存模式”不要一上来就查GPU型号参数先回答这三个问题你的核心计算单元是单次处理1个数据点如判断一个像素是否为边缘还是必须同时处理N×N邻域如3×3卷积→ 如果是前者属于低计算密度任务CPU更合适后者属于高计算密度任务GPU有天然优势。数据访问是顺序的如遍历数组、跳跃的如稀疏矩阵乘法、还是完全随机的如图神经网络中的邻居采样→ 顺序访问GPU带宽优势最大化跳跃访问需看跳距是否在缓存行内64字节完全随机CPU缓存局部性更好。任务是否有强依赖链即后一步计算是否必须等前一步输出才能开始→ 如编译器词法分析、区块链PoW哈希计算、实时PID控制这种长依赖链任务GPU的并行调度反而成累赘。我整理了一个快速决策表基于27个真实项目经验任务类型计算密度访存模式依赖链长度推荐首选关键原因视频H.265编码高顺序局部跳跃中B帧参考GPU90%计算为4×4整数DCT量化完美匹配warp调度MySQL慢查询优化低完全随机B树遍历长逐层下探CPU缓存命中率决定性能GPU随机访存延迟太高激光雷达点云配准ICP中跳跃KD树搜索中迭代收敛混合CPU控迭代GPU算距离矩阵实测提速5.3倍LLM推理7B模型极高顺序KV Cache流式读短单token生成GPUHBM3带宽喂饱Attention计算CPU内存带宽成瓶颈工业PLC逻辑扫描极低顺序IO映射区极长循环扫描CPU微秒级确定性响应GPU驱动栈无法满足实操心得很多团队在做AI推理部署时盲目追求GPU吞吐量却忽略了“首token延迟”。实测发现用CPU运行量化后的Phi-3模型3.8B参数首token生成仅需18ms而同配置GPU需42ms——因为GPU要先加载整个模型权重到显存这个PCIe传输过程就占了25ms。如果你的应用场景是客服对话用户不能等50msCPU反而是更优解。3.2 第二步验证硬件“数据搬运能力”是否匹配很多人忽略了一个致命细节CPU和GPU之间的数据搬运往往比计算本身还耗时。PCIe带宽就是那道看不见的墙。以PCIe 5.0 x16为例理论带宽是128GB/s但实测持续传输速率通常只有95GB/s左右。而H100的HBM3带宽是3950GB/s——这意味着如果你要把10GB模型权重从CPU内存拷贝到GPU显存理论最短耗时是105ms实际往往要130ms以上。而在这130ms里GPU是完全空闲的。解决方案不是换更快的PCIe而是重构数据流方案A零拷贝内存映射适用于Linux系统使用cudaHostAlloc()分配页锁定内存pinned memory让GPU DMA控制器直接访问CPU内存。实测拷贝1GB数据从130ms降至18ms。但代价是这部分内存无法被操作系统交换到磁盘必须预留足够物理内存。方案B计算-搬运重叠适用于长序列任务把任务切分为多个子块GPU计算第1块时CPU后台预取第2块数据。NVIDIA的CUDA Stream机制原生支持但要求任务能明确划分边界。方案C模型分片卸载适用于超大模型不把整个模型放GPU而是把计算密集层如FFN放GPU控制密集层如Embedding Lookup留CPU。HuggingFace的Accelerate库已内置此模式实测在A100上运行Llama-2-13B显存占用从24GB降至16GB总耗时仅增加7%。我在某金融风控平台落地时客户要求实时处理每秒5000笔交易。原始方案是CPU解析报文GPU做图神经网络欺诈检测结果端到端延迟波动极大23~180ms。排查发现GPU每次只处理100笔但CPU送数据的间隔不均匀。最终改为CPU用环形缓冲区攒够200笔再触发GPU计算同时启用CUDA Graph固化计算图延迟稳定在31±2ms。3.3 第三步压力测试必须覆盖“最差路径”别只测理想情况。我见过太多团队用合成数据全零矩阵、有序数组测出GPU 20倍加速一上生产环境就崩盘。必须做三类压力测试冷启动压力首次加载模型时的延迟峰值。GPU的显存初始化、CUDA上下文创建、TensorRT引擎编译这些都是一次性开销。某电商推荐系统上线时因未预热GPU首请求耗时达2.3秒被业务方直接否决。缓存污染压力在GPU计算过程中突然插入一个大内存分配如日志写入、监控数据采集观察计算延迟是否飙升。这暴露的是GPU驱动与CPU内存管理器的协同缺陷。中断干扰压力模拟系统级中断如定时器中断、网卡软中断对GPU计算的影响。实测发现在开启irqbalance服务的服务器上GPU计算延迟标准差比关闭时高47%——因为中断被动态分配到不同CPU核心导致GPU与CPU通信路径不稳定。我的标准测试模板已开源在GitHub# 冷启动测试重复10次取第1次和后9次均值 ./benchmark --mode cold --iter 10 # 缓存污染测试计算中注入1GB内存分配 ./benchmark --mode pollution --alloc-size 1073741824 # 中断干扰测试绑定到特定CPU core taskset -c 0-3 ./benchmark --mode interrupt4. 场景化实战五个典型项目的技术选型复盘4.1 项目A4K HDR实时视频调色系统影视后期需求在25fps下对4K10bit视频流做ACES色彩空间转换自定义LUT映射动态范围压缩端到端延迟40ms。初选方案用RTX 4090做全GPU流水线。实测发现单帧处理耗时32ms看似达标但第3帧开始出现丢帧。抓取GPU利用率曲线发现每帧处理中有8ms处于“等待输入”状态——因为CPU从采集卡读取4K帧需12ms而GPU处理只需32ms但GPU必须等整帧数据到齐才能启动。根本问题GPU的“批处理”天性与视频流的“流式”特性冲突。最终方案CPUi9-14900K负责帧采集初步降噪用AVX-512指令集GPURTX 4090只做核心调色将4K帧切分为16个256×256区块用CUDA流并行处理用CUDA Event实现CPU-GPU流水线同步确保GPU处理第n帧时CPU已在采集第n2帧结果端到端延迟稳定在38.2±0.7msGPU利用率从52%提升至89%。关键技巧区块大小必须是GPU warp size32的整数倍否则最后一个warp会因数据不足而空转。我们试过128×1284096像素但warp内线程数324096/32128刚好整除若用256×25665536像素65536/322048也是整除。但128×128导致区块过多CPU调度开销增大256×256则单区块计算量过大warp间负载不均衡。最终选定192×19236864像素36864/321152虽非整数但通过padding补零__syncthreads()同步实测负载均衡度最佳。4.2 项目B毫米波雷达点云实时聚类自动驾驶需求从64线毫米波雷达获取点云每秒10万点在100ms内完成DBSCAN聚类输出障碍物列表位置、速度、类别。技术陷阱DBSCAN算法本身有O(n²)复杂度但实际中点云具有强空间局部性。传统CPU实现用KD树优化到O(n log n)但GPU实现若直接暴力两两计算距离会因显存带宽瓶颈卡死。破局点利用雷达点云的物理特性——有效探测距离通常150米且点云在距离维上高度稀疏近处密、远处疏。最终架构CPUARM Cortex-A78做前端滤波用距离门限剔除150m的点剩余点按距离分桶0-30m, 30-70m, 70-150mGPUJetson Orin AGX对每个桶内点云单独聚类桶内点数少则用共享内存加速距离计算桶内点数多则启用HDBSCAN的近似算法聚类结果通过DMA通道直传给MCU做轨迹预测结果平均处理耗时83ms最差情况暴雨天气点云噪声激增112ms仍满足功能安全ASIL-B要求。注意事项GPU的shared memory是有限资源Orin每个SM 96KB必须严格计算每个桶的最大点数。我们按最密的0-30m桶设计实测该桶最多含842个点842×(3×float32)10.1KB远低于96KB留足余量应对突发噪声。4.3 项目C跨境电商商品图版权检测SaaS服务需求每天处理200万张商品图检测是否盗用某品牌官网图片要求召回率99.2%单图平均耗时1.5秒。误区警示很多团队直接上ResNet-50提取特征FAISS检索结果发现FAISS在CPU上单图检索需0.8秒但特征提取占了1.2秒总耗时超2秒换GPU做特征提取又因小批量batch1导致GPU利用率不足30%。创新解法特征提取层用TensorRT优化ONNX模型启用FP16精度层融合单图特征提取降至0.35秒检索层放弃FAISS改用CPU原生的AnnoyApproximate Nearest Neighbors Oh Yeah因其内存映射特性1000万向量库可常驻内存单次检索仅0.12秒关键优化将200万张图的特征向量按品牌分片存储每个品牌一个Annoy索引文件避免全库扫描结果单图平均耗时0.47秒QPS达2100服务器成本降低63%无需GPU服务器。实操心得Annoy的build参数n_trees100和search_k1000需根据数据分布调优。我们发现当查询向量与库中向量余弦相似度集中在0.7~0.9区间时n_trees50比100更快因为树越少构建时I/O越少但search_k必须设为1500否则低相似度样本召回率暴跌。这个结论是通过在测试集上跑网格搜索得到的。4.4 项目D智能工厂设备振动频谱分析工业物联网需求从1000台电机传感器采样率25.6kHz实时采集振动信号每秒做一次FFT4096点检测轴承故障特征频率如BPFO、BPFI。核心矛盾FFT计算本身GPU极快但传感器数据是通过RS-485总线串行上传CPU必须先做协议解析时间戳对齐这部分占了总耗时70%。分层卸载方案边缘网关ARM Cortex-A53运行轻量级Modbus TCP解析将原始ADC数据打包为固定格式二进制流主控服务器Xeon Silver 4310用DPDK绕过内核协议栈直接从网卡DMA缓冲区读取数据包解析耗时从18ms降至2.3msGPUTesla T4只做FFT计算输入为已对齐的4096点浮点数组用cuFFT库单次FFT仅0.15ms结果单台电机分析耗时稳定在2.8ms1000台并发总延迟3.1ms因GPU流式处理满足实时预警要求。关键细节cuFFT要求输入数组地址16字节对齐而DPDK从网卡读取的数据包地址不保证对齐。我们用posix_memalign()分配对齐内存再用cudaMemcpyAsync()异步拷贝避免CPU等待。实测若用普通malloc拷贝耗时增加0.08ms累积1000台就是80ms直接超限。4.5 项目E元宇宙虚拟人实时表情驱动直播场景需求通过单目RGB摄像头1080p30fps实时驱动虚拟人面部200骨骼点端到端延迟120ms表情自然度评分4.25分制。技术深坑表面看是纯AI推理但实际瓶颈在数据预处理。OpenCV的face detectionYOLOv5s在CPU上需15mslandmark detectionMediaPipe需8ms而GPU推理TensorRT优化的FAN模型仅需3ms。破局设计CPURyzen 7 5800H用OpenVINO加速YOLOv5s耗时降至6msMediaPipe改用CPU版但启用TBB线程池landmark耗时降至4msGPURTX 3060只运行FAN模型输入为裁剪后的ROI图像256×256用CUDA流预处理NVENC硬编码加速resize关键创新将face detection与landmark detection合并为单次推理——修改YOLOv5s输出头直接回归68个关键点坐标省去二次ROI裁剪结果端到端延迟89ms表情自然度4.5分评测方法邀请20名观众盲测打分均值。避坑提醒合并检测头后模型精度下降12%但我们发现直播场景中用户脸部基本正对镜头且光照稳定。于是用GAN做数据增强生成10万张侧脸/逆光/模糊样本加入训练集最终精度恢复至原水平且泛化性更强。这个技巧后来被某直播平台采购为SDK。5. 常见问题与硬核排查技巧实录5.1 “GPU利用率只有10%但任务很慢”——九成是数据搬运瓶颈这是最常被误判的问题。新手看到nvidia-smi显示GPU利用率个位数第一反应是“GPU没跑起来”其实真相往往是GPU在等CPU送数据。排查四步法用nsys profile抓取完整执行轨迹必须加--tracecuda,nvtx,osrt查看Timeline中GPU计算块绿色与数据拷贝块蓝色的时间占比若拷贝块总时长 计算块总时长确认是搬运瓶颈进一步看拷贝块是否分散说明小批量频繁传输还是集中说明单次大数据量真实案例某团队做语音分离用PyTorch DataLoader加载音频batch_size16。nsys显示每次GPU计算前都有3个连续的cudaMemcpyAsync调用总耗时42ms而计算仅18ms。原因是DataLoader的num_workers4但每个worker都在往同一块GPU内存写触发了隐式同步。解决方案改用torch.utils.data.IterableDataset实现流式加载在DataLoader中设置pin_memoryTrue启用页锁定内存将batch_size从16提升至64减少拷贝次数实测耗时从42ms降至11ms提示pin_memoryTrue不是万能的。若系统物理内存不足页锁定会导致OOM。我们有个项目在32GB内存服务器上设pin_memoryTrue后第7个epoch直接崩溃。解决方案是监控nvidia-smi -q -d MEMORY | grep Used当显存使用率85%时自动切回普通内存模式。5.2 “CPU和GPU结果不一致”——浮点精度与舍入误差的幽灵当CPU用double精度计算GPU用FP16推理时结果差异可能超出预期。这不是bug是硬件设计使然。精度差异来源CPU的FMAFused Multiply-Add指令对a*bc做单次舍入GPU的Tensor Core对a*bc做两次舍入先算a*b再加cCUDA的__fma_rn()与fmaf()函数行为不同实测数据100万次累加1e-6平台数据类型结果相对误差CPU (AVX2)double1.00000000000000022e-16GPU (A100)FP160.99998474121093751.5e-5GPU (A100)TF321.00000011920928961.2e-7业务影响某金融风控模型用TF32训练但生产环境用FP16推理导致0.3%的坏账预测偏差被合规部门叫停。规避策略训练与推理必须用相同精度TF32训练→TF32推理关键业务层如损失函数、梯度更新强制用FP32计算层用TF32用torch.cuda.amp.GradScaler自动管理混合精度而非手动cast5.3 “GPU温度正常但性能断崖下跌”——功耗墙与电压墙的双重绞杀GPU厂商标称的TDP如RTX 4090的450W是“理想散热条件下的持续功耗”。实际机箱风道不良时GPU可能在70℃就触发功耗限制。诊断命令# 查看实时功耗限制状态 nvidia-smi -q -d POWER | grep Power Draw\|Power Limit # 查看电压频率曲线需root nvidia-settings -q [gpu:0]/GPUGraphicsClockOffset[3] -q [gpu:0]/GPUMemoryTransferRateOffset[3]真实故障某AI训练集群16台服务器中3台训练速度慢50%。nvidia-smi显示GPU温度65℃正常但power.draw始终卡在280W标称450W。拆机发现这3台服务器的机箱风扇被灰尘堵死GPU供电模块温度达92℃触发了VRMVoltage Regulator Module保护降频。解决方案在训练脚本开头加入健康检查import pynvml pynvml.nvmlInit() handle pynvml.nvmlDeviceGetHandleByIndex(0) power_limit pynvml.nvmlDeviceGetPowerManagementLimit(handle) power_draw pynvml.nvmlDeviceGetPowerUsage(handle) if power_draw 0.7 * power_limit: raise RuntimeError(fGPU power throttling: {power_draw}/{power_limit})机箱内加装温度传感器当VRM温度85℃时自动降低GPU功耗限制至350W换取稳定性5.4 “多进程GPU程序显存占用翻倍”——CUDA上下文的隐形开销Python多进程multiprocessing中每个子进程都会创建独立CUDA上下文即使不调用GPU也会占用200MB显存。验证方法# 启动空进程观察显存占用 python -c import multiprocessing as mp; [mp.Process(targetlambda:None).start() for _ in range(4)] nvidia-smi # 查看显存占用是否增加解决方案用torch.multiprocessing.spawn替代原生multiprocessing它会复用主进程CUDA上下文或在子进程启动时显式销毁无用上下文import torch if torch.cuda.is_available(): torch.cuda.empty_cache() # 清理未使用的缓存 # 强制销毁当前上下文慎用 # torch.cuda._lazy_init() # 此行会重置CUDA状态注意torch.cuda.empty_cache()只是释放缓存不释放已分配的显存。真正释放需用del tensor; gc.collect()但Python的GC不保证立即执行。我们的做法是在子进程结束前显式调用torch.cuda.synchronize()再del所有tensor最后gc.collect()实测显存回收率98%。5.5 “CPU和GPU协同延迟忽高忽低”——NUMA节点与PCIe拓扑的暗战在多路服务器如双路EPYC上CPU核心、内存插槽、PCIe插槽分属不同NUMA节点。若GPU插在CPU1的PCIe插槽但程序在CPU0上运行数据就得跨NUMA节点搬运延迟飙升。诊断工具# 查看NUMA拓扑 numactl --hardware # 查看GPU所属NUMA节点 nvidia-smi -q -d PCI | grep NUMA Node # 绑定进程到指定NUMA节点 numactl --cpunodebind0 --membind0 python train.py真实案例某HPC中心双路EPYC 7763服务器GPU插在CPU0的PCIe插槽但Slurm作业调度器默认把任务分到CPU1。nvidia-smi显示GPU利用率95%但perf stat -e cycles,instructions,cache-misses显示cache-misses率高达32%正常应5%。绑定到CPU0后cache-misses降至4.1%训练速度提升2.3倍。终极建议在服务器BIOS中启用“PCIe ACS Enable”强制PCIe设备归属最近CPU节点或采购主板时选择“GPU直连CPU”的型号如Supermicro H13DSH。6. 我的实际体会别迷信参数要信物理定律做了十多年底层系统优化我越来越确信所有“为什么GPU在这里慢”的问题答案都藏在芯片的物理实现里。不是GPU不行是你没摸清它的脾气。比如GPU的HBM显存本质上是一堆堆叠在GPU芯片上的DRAM颗粒通过硅通孔TSV连接。这意味着HBM的带宽再高也受限于TSV的物理宽度和数量。NVIDIA H100的HBM3有6144-bit总线宽度而消费级RTX 4090只有384-bit——这6144-bit不是凭空来的是靠堆叠更多DRAM颗粒实现的。所以H100的显存带宽是RTX 4090的10倍但成本是30倍功耗是5倍。再比如CPU的L3缓存用的是SRAM而GPU的L2缓存用的是DRAM。SRAM速度快但面积大1bit需6个晶体管DRAM速度慢但密度高1bit只需1个晶体管1个